Onyx
Onyx governance requires affirmative quorum and a majority before approved changes can execute
Onyx governance approves protocol and treasury changes through stake-weighted proposals, an affirmative-vote quorum, and a For-vote majority. Ethereum proposals required 200,000,000 XCN in favor. Native Onyx Chain governance retains that amount as a quorum floor, with the actual requirement determined by eligible stake and bounded governance parameters. Its voting power comes from stXCN balances captured at a proposal snapshot. Ethereum stake and native stake belong to separate voting domains. Approval allows a proposal to advance toward execution; a queued proposal must still complete its Timelock delay. Encoded contract calls specify the immediate changes a proposal can execute, while wider operational plans may require separate implementation.
From eligible stake to an executed OIP
A native proposal needs finalized stake records before its proposer can submit actions for an Onyx Improvement Proposal, or OIP. The native Governor, OnyxGovernorV2, checks the proposer’s eligible weight against the submission threshold. Proposal creation records the actions and binds the voting snapshot. Eligible addresses then vote during the active period, using proofs of the weight assigned to them. Once voting closes, the Governor evaluates affirmative quorum and the For-versus-Against result. A successful tally permits queueing into the Timelock. Execution follows only when the queued operation becomes eligible and its contract calls succeed.
An Executed state records completed on-chain actions. A proposal ID, a submitted transaction, or a Succeeded state does not establish execution. A change to a governed contract requires the corresponding execution, while a broader operational commitment may also require work outside those contract calls.
Ethereum and Onyx Chain voting domains
Ethereum governance used staked XCN within Ethereum contracts; native governance uses stXCN on Onyx Chain, chain ID 327. The app presents older Ethereum decisions as legacy proposals whose voting has closed. Native OIP-2, Liquid Staking Governance Voting Activation, recorded execution on August 22, 2026. Ethereum’s original staking restrictions apply to its own contracts. Native stXCN voting uses the separately deployed Onyx Chain contracts.
Each proposal belongs to one chain. Staked balances on the other chain contribute no voting weight to it. Governance also differs from network consensus: DAO votes authorize decisions, while consensus establishes agreement about transactions. Running a node does not replace the proposal’s staking and eligibility requirements.
stXCN balances at the proposal snapshot
Native voting weight comes from the address’s stXCN balance at the proposal snapshot, including staking rewards accrued by that block. Liquid staking supplies this token position; native XCN held outside staking supplies no voting weight. A displayed portfolio balance therefore measures a different thing from the frozen weight available for a particular OIP. The proposal snapshot identifies the eligible address and balance before voting begins. Later rewards or additional stake cannot increase that proposal’s assigned weight, even though they can affect subsequent snapshots.
Unstaking or transferring stXCN after the snapshot leaves existing proposal weight unchanged. Future snapshots reflect the changed holdings. The latest wallet balance and an older proposal’s voting balance can therefore differ without either figure being incorrect.
Does 200 million XCN guarantee passage?
A tally of 200,000,000 XCN in favor does not guarantee passage because the proposal must also meet its applicable quorum and majority. Only For votes contribute to the native Governor’s quorum. Against votes affect whether For leads; Abstain votes count toward neither approval condition. A tie fails the majority requirement. A large turnout or a high percentage of supportive addresses cannot substitute for sufficient affirmative voting weight. Each address contributes its recorded weight, so the count of wallets voting For does not determine the result.
Native quorum applies a governance-controlled rate to eligible staked supply, subject to a 200,000,000 XCN floor and a 1,000,000,000 XCN cap. Eligible supply belongs to the proposal snapshot and differs from total circulating XCN. The proposal’s recorded quorum supplies the relevant threshold. A different eligible supply or an authorized parameter change can alter the requirement for another proposal.
Proposal thresholds and encoded actions
Native proposal submission requires sufficient weight in the latest finalized eligibility snapshot, distinct from the snapshot fixing votes for a specific OIP. The submission threshold applies a governance-controlled rate to eligible stake, bounded by a 100,000,000 XCN floor and a 1,000,000,000 XCN cap. This requirement governs who can introduce executable actions. It does not turn the submission threshold into a minimum balance for every voter. An address with less weight can vote when the proposal snapshot includes it.
A proposal specifies target contracts, call values, and encoded function arguments, alongside a description explaining its purpose. Those calls determine the direct changes execution can perform. Treasury allocations, economic parameters, and contract upgrades can require different targets and permissions. A broad policy description cannot give the Timelock authority over a contract it does not govern.
A worked tally with a proposal-specific quorum
An observer compares a native proposal’s closing For tally with its quorum and Against votes. In this hypothetical case, a finalized snapshot and valid proofs support the following quorum and closing tallies.
The proposal’s quorum is 223,415,773 XCN of voting weight. For totals 231,876,493 XCN, and Against totals 198,314,267 XCN.
For exceeds quorum by 8,460,720 XCN and exceeds Against by 33,562,226 XCN. Both approval conditions hold, so the closed vote qualifies as Succeeded.
That state permits queueing; it does not prove execution. A quorum above the For tally would defeat the proposal, even with the same majority.
Snapshot publication and proof checks
A native snapshot becomes usable only after its published voting data passes the registry’s challenge and finalization process. The snapshot builder measures eligible stXCN balances at a finalized block. A Merkle root commits to the address-and-weight records, while registry metadata identifies the block, eligible supply, and policy version. A Merkle proof lets the Governor check one address’s claimed weight against that commitment. The app obtains the proof and attaches it to the vote transaction. The Governor verifies eligibility against the proposal’s finalized root.
The challenge window lasts one day before finalization. An independent challenger can dispute an incorrect root, and a guardian can veto a bad root. These checks address the correctness of the voting data. They do not determine whether the proposal’s requested treasury allocation or policy change is desirable.
How long does a native OIP take to execute?
A native OIP has a minimum creation-to-execution timeline of about five days, excluding preparation of its snapshot. The Governor imposes a one-day voting delay followed by a two-day voting period. A successful proposal then needs queueing, which starts a two-day Timelock delay. Snapshot preparation includes its own one-day challenge window before the snapshot becomes usable. Queueing later adds elapsed time; reaching Succeeded does not start the Timelock automatically. The earliest eligible execution time belongs to the queued operation.
After the delay, anyone can trigger native execution of the approved actions. Permission to trigger execution grants no power to change those actions. An execution transaction must complete successfully before the proposal reaches Executed. Ethereum’s legacy voting schedule used block-based parameters, so its historical start and end blocks should not be interpreted through the native five-day schedule.
Treasury authority and operational decisions
The native Grant Treasury pays WXCN grants through authority held by the Timelock. The Governor queues an approved operation, and the Timelock calls the governed treasury after the delay. The payout’s recipient and amount come from the encoded grant action. Voting weight is separate from the amount a recipient receives. A proposal’s affirmative tally therefore cannot serve as a grant amount, a treasury balance, or evidence of funds arriving at an address.
DAO decisions also cover protocol upgrades, staking economics, network incentives, and treasury allocations. Some decisions authorize operational work beyond the immediate contract operation. A vote can approve an initiative while its software deployment or commercial implementation follows separately. The encoded actions establish the immediate on-chain effect; the proposal’s broader commitments retain their own implementation conditions.
Community polling and formal ratification
Community polls allow discussion and signaling before a formal governance decision. OIP-56 proposed gas-free polling through Snapshot, separate from executable proposals. Poll creation requirements and on-chain proposal thresholds serve different purposes. Ethereum OIP-64 later ratified previously approved polling measures concerning poll requirements and community safeguards. The approved poll results and OIP-64’s execution are separate records. A poll’s support does not itself schedule calls in the native Timelock. Discussion can inform the proposal’s rationale, while the executable payload still needs its own governance authorization.
Proof failures, cancellation, and legacy expiry
Native proof verification fails for an unfinalized or wrong-purpose root, a mismatched policy, or a paused registry. Missing eligibility cannot create voting weight. An indexer or proof service can also leave the app unable to display a proposal’s power. An indexer warning indicates missing interface data. The finalized snapshot and the Governor’s checks determine eligibility. Staking again cannot add weight to a snapshot already fixed.
The native guardian can cancel a malicious queued operation during the Timelock delay. Its cancellation role does not permit it to create a proposal, accelerate execution, or pay a treasury grant.
A defeated native proposal requires a new proposal and vote to try again. Additional support submitted after voting closes cannot rescue the closed tally.
Ethereum’s legacy Governor also recognized Expired proposals when their queued execution window elapsed. That historical state belongs to its own Timelock rules. Native execution should follow the native operation’s recorded state and eligibility time; a legacy deadline cannot establish a native deadline.
Onyx governance - your questions answered
Can native voting power be delegated to another address?
OnyxGovernorV2 has no separate delegation registry for native voting power. Its vote weight belongs to the address holding stXCN at the proposal snapshot. Transferring tokens afterward cannot assign that proposal’s already-recorded weight to a new address. Later snapshots can reflect the new holder’s balance.
May I replace an on-chain vote with a different choice?
The native Governor accepts one vote per address for each proposal. After it records that vote, another choice from the same address cannot replace it. A pending wallet request does not establish a recorded ballot. The proposal’s on-chain voting record distinguishes a completed vote from an unsubmitted or unsuccessful transaction.
Are Onyx governance votes private?
On-chain governance votes are public and associated with wallet addresses. Proposal descriptions and submitted governance content also appear publicly with their authors’ addresses. A wallet address need not reveal a legal name, but transactions can connect it with other activity. Disconnecting the wallet cannot erase the published governance record.
What pays the transaction fee for a native governance vote?
A native governance vote pays its network transaction fee in native XCN. stXCN supplies voting weight and represents a separate token balance. The balance providing governance influence does not automatically provide the native XCN needed for transaction fees. The network’s execution and fee inputs determine the charge.
Do identical OIP numbers on different chains identify the same proposal?
An OIP number identifies a proposal within its own governance domain. The Ethereum archive and native Onyx Chain catalogue have separate histories, so the same number alone does not identify the same decision. The chain and Governor distinguish the intended proposal when identifying a vote or its execution record.
Updated ·