> For the complete documentation index, see [llms.txt](https://docs.onyx.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onyx.org/governance/onyx-chain/voting-power.md).

# Voting Power and Snapshots

Onyx Chain governance is **stake-to-vote**: your voting power is your staked XCN, measured at a published, verifiable snapshot. This page explains how that measurement works and what you need to do — and avoid — to make sure your stake counts.

## Where voting power comes from

| Asset                         | Voting power on Onyx Chain                                                                              |
| ----------------------------- | ------------------------------------------------------------------------------------------------------- |
| **stXCN** (staked XCN)        | ✅ Full weight — your rebased stXCN balance at the snapshot block, including accrued staking rewards     |
| Native XCN in a wallet        | ❌ Zero                                                                                                  |
| WXCN, LP tokens, other tokens | ❌ Zero                                                                                                  |
| XCN or stXCN on Ethereum      | ❌ Zero on Onyx Chain (it votes in the separate [Ethereum governance](/governance/quickstart.md) domain) |

You stake XCN and receive stXCN through the [Onyx App](https://app.onyx.org) — see [Staking and stXCN](/onyx-defi/onyx-app/staking.md). Because stXCN is a rebasing token whose balance grows with staking rewards, your voting weight automatically grows with your rewards too: **1 stXCN of balance at the snapshot = 1 unit of voting weight**.

{% hint style="info" %}
**Why stake-to-vote?** Requiring stake aligns voting power with long-term commitment to the network, and it gives governance one clean, on-chain source of truth for who holds what — the staking contract itself.
{% endhint %}

## How a snapshot is made

Voting power is not read live at vote time — it is fixed in advance by a **snapshot** with a public, verifiable pipeline:

```mermaid
sequenceDiagram
    participant S as stXCN contract
    participant I as Snapshot builder
    participant R as Snapshot Registry (on-chain)
    participant C as Independent challenger
    participant G as Governor

    I->>S: Read every staker balance at snapshot block B
    I->>I: Build Merkle tree of (address, weight) leaves
    I->>R: Publish Merkle root + metadata on-chain
    C->>R: Recompute independently, 1-day challenge window
    Note over R: No valid challenge → root is finalized
    G->>R: Verify each vote against the finalized root
```

1. **Measurement.** At a specific finalized block, the snapshot builder reads the exact stXCN balance of every staker directly from the staking contract's on-chain state.
2. **Merkle tree.** Every `(address, weight)` pair becomes a leaf in a Merkle tree. The single 32-byte root commits to the entire electorate — no balance can be added, removed, or altered without changing the root.
3. **On-chain publication.** The root is posted to the **Snapshot Registry** contract, together with metadata that pins the snapshot block, the total eligible supply, and the policy version it was built under.
4. **Challenge window (1 day).** An **independent challenger** — operating on separate infrastructure from the publisher — recomputes the snapshot from scratch. If its result differs, it challenges the root on-chain and the root is replaced, never silently corrected. A **guardian** role can additionally veto a bad root as an emergency backstop.
5. **Finalization.** Only after surviving the challenge window unchallenged does the root become **finalized** — and only finalized roots can ever be used for proposing or voting. The Governor rejects anything else.

This design means you never have to trust the snapshot publisher: every root is independently re-verifiable by anyone from public on-chain data, and it is contested *before* it can affect any vote.

## Two kinds of snapshots

| Snapshot                 | Purpose                                                                                                                 | When it is taken                                |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| **Eligibility snapshot** | Gates *proposal creation* — the proposer must prove threshold weight against the latest finalized eligibility snapshot. | Rolling — refreshed on a regular cadence        |
| **Proposal snapshot**    | Fixes *voting weight and quorum* for one specific proposal. Bound permanently to that proposal at creation.             | Once per proposal, shortly before it is created |

Both kinds go through the same publish → challenge → finalize pipeline.

## Voting with proofs

When you vote, the Governor verifies your claimed weight with a **Merkle proof** against the proposal's finalized snapshot root. In practice this is invisible: the Onyx App fetches your proof from the governance API and attaches it to your vote transaction automatically. You simply choose For, Against, or Abstain and sign.

A vote without a valid proof counts as **zero weight** — the system fails closed. No proof, no unfinalized snapshot, and no mismatched snapshot can ever mint voting power.

## Practical rules for voters

* **Stake before the snapshot.** If you stake after a proposal's snapshot block, you have zero weight *on that proposal* — but you will be included in future snapshots.
* **Your weight is frozen per proposal.** Unstaking or transferring stXCN after the snapshot does not change your weight on proposals that already snapshotted you. It does remove you from *future* snapshots.
* **No delegation (currently).** Voting weight belongs to the address that holds stXCN at the snapshot; there is no separate delegation registry.
* **Rewards count.** Because stXCN rebases, the weight recorded at the snapshot already includes all staking rewards accrued up to that block.
* **Check your power before voting.** The Onyx App displays your voting weight for each proposal once its snapshot is finalized.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.onyx.org/governance/onyx-chain/voting-power.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.