Crypto Game Governance: What a Governance Token Lets Players Decide

The rules might let holders approve a treasury transfer or change a token setting. That authority doesn't automatically extend to game balance. Running the servers and controlling the game's intellectual property need their own permissions or rights.

A vote's subject matters more than the token's label. A proposal to pay for tournament development could approve a budget. It doesn't necessarily authorize changing the tournament rules, hiring the studio's developers or editing its production code. Those are different decisions with different permission holders.

The same split applies to assets. Controlling your wallet means you can authorize actions involving assets under your keys. It doesn't put a studio wallet under your keys. DegenLoot's non-custodial crypto wallet guide covers that custody question; governance adds another layer of permissions rather than replacing it.

This is a map of possible powers, not a claim that every crypto game grants them.

Does treasury governance include game balance?

A project can let holders approve development spending while keeping gameplay changes under studio control.

A grant might fund anti-cheat work, but the people maintaining matchmaking still need to integrate it. Funding a fix doesn't give every voter a production login.

Nor does a vote necessarily settle ownership. The separate soulbound-token ownership explainer examines what holding an asset means. Here, the question is who can direct a project. Voting rights alone don't establish studio equity or ownership of its art. A legal claim needs its own basis.

In SPS governance, DAO decisions and requests to change company-run products have different status. Its documentation also describes people carrying out approved proposals manually. A passed vote doesn't necessarily edit a smart contract.

The SPS proposal-topic rules assign governance over the supply, issuance and distribution of SPS, VOUCHER and LICENSE, alongside funds held by the SPS foundation. The same page describes the game, website and other company products and services as company-owned and operated. Proposals affecting those products are advisory.

Under those documented rules, a proposal concerning foundation funds belongs to DAO governance. A request to change a company-maintained game feature doesn't become mandatory merely because the same voters support it.

The page also discusses prospective migration to SPS Chain. Future scope belongs in the roadmap bucket. It isn't evidence that DEC, cards or land have already moved under the stated DAO authority.

Who carries out an approved SPS proposal?

The SPS implementation documentation describes manual implementation by the team and/or foundation. Changes needing development work require planning and an implementation timeline. Approval and delivery are separate stages.

Manual work isn't automatically fake governance. But a commitment to carry out approved, in-scope decisions still depends on someone doing the work. Who is responsible, and where will delays be reported? An advisory request to change a company product remains advisory even if the team has an implementation process.

Two hypothetical proposals show the distinction. Spending specified DAO funds may fall within DAO authority, subject to the actual proposal and rules. Asking for a card nerf touches the company-run game and is advisory.

Quorum and approval count different things

The formal SPS voting rules, consulted on October 11, 2026, describe a seven-day voting period. They specify quorum at 10% of total staked SPS, counting participation for and against. Passage requires support from 66.66% of participating staked SPS.

Those percentages have different denominators. Quorum asks whether enough eligible stake participated. Approval asks whether enough participating stake supported the proposal. A strong majority of a tiny participating balance can still fail a quorum requirement.

These figures describe the documented rules, not measured turnout or an independently verified live setup. The page describes weighting by an account's staked SPS when voting, with recasting able to refresh changed weight. One vote per Hive account doesn't mean one human, one vote. The account's eligible stake still matters.

Axie's governance announcements document a contribution-sensitive voting approach and proposals concerning asset contracts and treasury arrangements. They don't establish that AXS holders control every game operation. Announcement dates matter here, since plans and completed execution aren't interchangeable.

In the May 17, 2024 governance-portal announcement, Axie described voting power combining staked AXS with a quadratic modifier and Axie Score. Contribution categories included gameplay, treasury or community contributions, and NFT holdings. That differs from simply reading a wallet balance and assigning identical weight to every token.

A different formula doesn't prove large holders lose influence. That takes current voting data, which this guide doesn't provide.

The initial proposal, AIP-001, concerned safer asset delegation and contract upgradeability. Asset delegation in that proposal meant permissions involving assets. It wasn't delegation of governance votes. Crypto terminology really does enjoy using the same word for different jobs.

A contract-upgrade proposal is a specific decision, not a blank cheque to redesign combat. The announcement by itself doesn't establish the vote's outcome or its execution.

Axie's August 8, 2025 foundation and treasury announcement described a foundation being established to carry out community-directed treasury decisions. Possible uses included grants, development and community initiatives. Its future-facing language matters. Paying for development wouldn't, on its own, transfer existing game IP or grant authority to force a patch.

Then the August 26, 2025 constitution announcement outlined proposed rules covering treasury governance, citizenship and voting, as well as council formation and amendments. It announced a vote for September 1 to 8, 2025.

The article announced a process. It doesn't establish ratification, the quorum or veto rules in force, or completed foundation execution in October 2026. Those present-day claims need later records of what was adopted and carried out.

A tally on-chain can still leave the work to an operator. What matters is whether an executor has permission to carry out the approved actions. An off-chain vote can also feed a documented manual process.

Voting and execution are separate jobs. Voters can signal a preference or approve a decision. An executor carries it out. Another role may be able to cancel or override it. These powers aren't necessarily held by the same people, and they don't form a universal ladder.

An advisory poll is a request. Approval under a manual framework creates an implementation dependency. A contract-executable proposal authorizes defined calls. None of those descriptions answers the separate legal question of whether voters can enforce a claim against a studio.

What a Governor and timelock can execute

The OpenZeppelin Contracts 5.x governance guide describes a configurable Governor framework. Proposals specify target addresses, values and calldata, meaning the instructions sent to contracts. Voting and quorum rules determine passage. A timelock can delay approved actions before execution is invoked.

Someone still has to submit the execution transaction. More importantly, the target action must be authorized. OpenZeppelin explains that the timelock should hold the funds, ownership or access-control roles the governance system is meant to control.

Here is a hypothetical technical example, not an inspection of SPS or Axie contracts. A timelock holds a treasury's funds, and an approved proposal instructs it to transfer funds to a grant recipient. Once the configured conditions are satisfied, execution can make that transfer. The same timelock cannot patch a studio server it has no access to. A blockchain transaction doesn't know the hosting password.

A delay gives observers time before execution; it doesn't guarantee a safe proposal. The actions themselves may be harmful. Proposer, executor and canceller roles need separate inspection, along with any remaining admin authority. The project's actual configuration determines who can act outside the ordinary voting path.

These are reference mechanics. They aren't evidence that either game example uses this exact OpenZeppelin setup.

Snapshot and Snapshot X differ

The Snapshot documentation distinguishes the original off-chain voting platform from Snapshot X's on-chain voting and proposal-execution capabilities. Dismissing every Snapshot-branded vote as a non-binding poll would be wrong.

A Snapshot X badge still leaves questions about the game's execution module, what it can call and the assets it controls. A vote on the original platform could also feed a documented manual process. The name alone doesn't tell you how the decision gets carried out.

Before connecting to a voting interface, wallet safety remains a separate task. The smart-contract check before connecting a wallet covers that question. A credible proposal doesn't excuse a suspicious request for asset permissions.

A proposal threshold decides who can submit a proposal. Quorum sets minimum participation. Approval rules determine whether the proposal passes. Your voting weight may depend on staking, historical checkpoints or contribution scores. A historical checkpoint records voting power at a specified earlier block or time, rather than using whatever balance your wallet shows now. The project's rules determine which checkpoint applies.

In OpenZeppelin's ERC20Votes model, historical delegated voting power matters, and holders may need to delegate to themselves. That is implementation-specific, not a rule to paste onto every token. Even abstention handling differs: its illustrated CountingSimple module counts For and Abstain toward quorum, while the SPS documentation describes participation for and against.

Delegation can make participation easier, especially when a voter lacks time to read every proposal. It can also concentrate influence in a smaller set of active delegates. Neither outcome can be inferred from the mere existence of a delegation button.

The Snapshot delegation guide says a space needs a voting strategy that supports delegation. It describes global and space-specific delegation, and original-holder voting that removes the delegate's voting power for that vote. Those rules concern voting power, not transfer of token ownership. They shouldn't be imported into SPS or Axie without evidence of the same behavior.

Allocations matter when inspecting who might dominate eligible voting weight. Supply schedules and token sustainability are a different due-diligence job, covered in the crypto-game tokenomics checklist. Here, the narrower question is whether team balances, treasury holdings or vested tokens count as votes under the configured rules.

A top-wallet list won't settle that. One person can use multiple addresses, and an address may represent many people. Delegate totals and actual votes cast are more useful than guessing human identities from wallet counts. Quadratic weighting may soften balance differences, but that alone doesn't prove fair control.

A completed proposal gives you something concrete to examine: the decision voters authorized and what happened afterward.

A short review can begin with the proposal itself.

• What exact funds, contract or game feature does it concern?

• Which rule makes that object subject to voter authority?

• Who is eligible to vote, and how is their weight calculated?

• What are the proposal-submission threshold, participation quorum and support rule, and which balances count?

Who performs the final action, and what permission lets them do it?

That last answer is often where the brochure stops being helpful. A foundation relies on people carrying out the decision. A multisig needs its authorized signers; a timelock needs the right contract permissions. Manual work may need a delivery schedule.

The next questions concern exceptions and evidence.

• Is there cancellation, pause or upgrade authority outside the vote?

• What limits apply to emergency powers, beyond a role label such as guardian?

• Where is the execution transaction or manual delivery record?

• Does the cited document describe an operating process or a future plan?

No verified specific veto for SPS or Axie is asserted here. Those are questions for inspecting a system, not permission to invent clauses missing from the sources.

Before treating a governance token as player control, open one completed proposal and trace what happened after the vote. If the evidence ends at the tally, execution is still an unanswered question.