Skip to content

Governance

tgibbsz32 edited this page Oct 25, 2026 · 3 revisions

ForgeCoin governance protocol — native FRG

Governance design is proposed, not ratified or operational. ForgeCoin full nodes independently enforce their installed native consensus. Repository maintainers, representatives and website operators cannot remotely mint FRG, confiscate coins, rewrite history or force node upgrades.

Decision domains

Decision type Intended authority
Consensus (emission, proof of work, transaction validity, forks, privacy, difficulty) Public proposal → independently reviewed implementation → announced activation → voluntary node/miner adoption
Repository/desktop releases, documentation, community priorities Maintainers and proposed community governance process, subject to security and published procedures
Project-controlled revenue or voluntary donations Separately defined custody and oversight only if funded and authorized
Ordinary mining payouts Valid consensus blocks / optional independently operated pools, not governance votes

Proposed representative chamber

The owner's design target is a ten-seat chamber, one vote per seat. The historical seat allocations, “five largest stakers” mechanism, guaranteed founder votes and previous sample ballot weights are not ratified. The exact group allocations, founder participation (if any), term lengths, quorum, supermajority thresholds, tie handling, vetos and recall/appeal procedures remain open design decisions.

Possible constituencies for evaluation include miners, users, developers, independent security contributors and operators, but these are not assigned seat counts. No faction, major pool, wealthy bondholder, developer or founder should obtain unilateral authority from an unreviewed design.

Miner representation: verified work plus native FRG bond

Intended two-part qualification:

  1. Evidence of actual independent/native FRG mining participation, including legitimate pool mining, verified without duplicating authority across multiple wallet addresses or worker accounts.
  2. An enforceably locked native FRG governance bond during the representative's qualification and term. Merely signing a wallet challenge, holding a balance or buying FRG cannot alone qualify a non-miner for the miner constituency.

The minimum bond amount is not set. A roughly 30-day continuous qualification period appears as research, not a ratified requirement. Lock/unbond mechanics, privacy of proof, protection against Sybil identities and pool double-counting, vacancy/appeals, penalties, lock-loss and miner inactivity are unresolved. Monero-derived native transaction confidentiality makes noncustodial proof of lock/control an actual engineering challenge.

No implemented bonding or binding elections exist, and no rewards/yield accompany the proposed bond. Practice governance and the old category-based API must not be used as a real voter registry.

Intended proposal and election safeguards

A ratified charter must specify, before a binding vote:

  • Eligibility and privacy-preserving proof, independent verification and deduplication.
  • Candidate nomination, representative election, term, recall, vacancy and challenges.
  • Quorum, ordinary/sensitive thresholds, abstentions, ties and independent oversight.
  • Minimum publication/review periods, exact source changes, conflict disclosures and appeals.
  • Protected financial and consensus decisions, including audits, external reviewers and node adoption.
  • Transparent official decisions with immutable/published records that do not expose private balances, wallet secrets or ordinary user's identity.

These rules are not numerically fixed yet. Publishing a preferred threshold in the Wiki before a ratification decision would falsely turn a proposal into policy.

Software upgrades and fork authority

Compatible changes can ship via normal repository review. A consensus-changing proposal requires rationale, code diff, test vectors, security/economic review, advance activation notice, reproducible binary signatures/hashes, and communication to operators, miners, exchanges and users. Independently run full nodes choose which software to accept. Disagreement can result in a chain split. Governance cannot grant an administrator emergency master key or new currency supply outside consensus.

Primary source: Governance Charter · Native upgrade policy · Owner decisions.

Clone this wiki locally