DAO governance in an NFT marketplace lets token holders vote on fee rates, royalty policy, treasury spending and contract upgrades, decisions the operating company would otherwise make alone. This guide explains which decisions suit a vote, how the governance contracts fit together, who should get voting power, and which attacks to plan for.
Marketplaces add governance for one of two reasons: some want to share the platform's revenue and decisions with traders and creators, and others want to promise that nobody can change fees and rules alone. A careless design can defeat either goal.
What NFT governance can control
Start with a list of parameters, not with a token. In a typical marketplace, governance can control these five areas:
- Protocol fee. The percentage the marketplace takes on each sale, and where the fee goes: the treasury, stakers or a burn.
- Royalty policy. Whether the marketplace enforces the creator royalties set in EIP-2981 data, makes them optional, or sets a minimum.
- Curation and allowlists. Which collections the marketplace features, verifies or removes for fraud and IP violations.
- Treasury spending. Grants to creators, liquidity incentives, audit budgets and bug bounties.
- Upgrades. Who can point a proxy contract at a new implementation, and who can pause trading in an emergency.
Some of these decisions do not suit a slow public vote, because the marketplace must remove stolen art and phishing collections within hours, not after a seven-day vote. A common split gives token holders control of policy and budgets, while a small operations group, often a multisig wallet, handles daily moderation within that policy.
How DAO governance contracts fit together
On EVM chains, most projects use the Governor contracts from OpenZeppelin, which are modular and have been audited many times. A minimal setup has five parts:
| Component | Typical implementation | Role |
|---|---|---|
| Governance token | ERC-20 with ERC20Votes, which records balances at checkpoints and supports delegation | Gives voting power, read from a past point so that borrowed tokens cannot vote |
| Governor | Governor with GovernorSettings, GovernorCountingSimple, GovernorVotes and GovernorVotesQuorumFraction | Runs proposals, the voting delay and period, the quorum and the vote count |
| Timelock | TimelockController, connected through GovernorTimelockControl | Delays execution, so users can leave before a change takes effect |
| Marketplace | Exchange contract owned by the timelock | Settles orders, collects fees, pays royalties |
| Guardian | Multisig with a narrow pause right | Stops trading in an emergency, but cannot move funds or change fees |
OpenZeppelin's governance guide uses a one-day voting delay, a one-week voting period and a 4% quorum as its example, and says most Governors use a 4% quorum.
One rule about contract roles decides whether the votes control the marketplace. Only the timelock should be able to call the marketplace's admin functions, such as setting the fee, setting the fee recipient or upgrading, and only the Governor should hold the timelock's proposer role. If a deployer key keeps an admin role, that key can override every vote.
Many projects run votes off-chain on Snapshot, where voters sign messages and pay no gas, and a multisig then carries out the result. This setup costs less and suits an early project. The multisig signers promise to follow the vote, but users should know that no contract forces them to keep that promise.
Who gets voting power
The token distribution decides who governs, whatever the documentation says. NFT marketplaces use four common patterns:
- Trading rewards. Users earn tokens for each trade, which invites wash trading, where users trade with themselves to collect tokens. On-chain analysts found that wash trades made up much of the volume on several marketplaces that launched tokens in 2022. If you reward activity, cap rewards per wallet, discount trades between linked wallets, and reward fees paid instead of volume.
- Retroactive airdrops. Past buyers, sellers and creators receive tokens. This is simple, but users with many wallets often collect a large share.
- NFT-based voting. Each held NFT gives one vote through ERC721Votes, which suits a collector community, but holders of many items get most of the votes.
- Staked or vote-escrowed tokens. A longer lock gives more voting weight, which rewards long-term holders, but users find it harder to understand.
Publish the full distribution, including team and investor allocations and vesting schedules, because large insider allocations let insiders outvote the community. In some jurisdictions, regulators also look at these allocations when they decide how to treat a token.
Attacks on marketplace governance
Governance adds new ways to attack a marketplace, and you should plan for these four:
- Flash-loan voting. In April 2022, an attacker borrowed tokens for one transaction, passed a proposal in the Beanstalk protocol and drained about $182 million. ERC20Votes reads voting power from a past block, which prevents this attack, and a voting delay adds a second protection.
- Low-turnout capture. A large holder passes a proposal while few people are watching. To prevent it, set a meaningful quorum and a timelock of several days, and send alerts when someone creates a proposal.
- Treasury drain through hidden calls. A proposal can contain any transaction, so require a plain-language description, simulate every proposal on a fork of the chain, and publish the resulting state changes.
- Low participation. Most holders never vote, and the usual fix is to let them delegate their votes to known community members.
The exchange contract still needs normal security work, and the smart contract audit guide covers what an audit includes. Audit the Governor setup together with the marketplace, because wrong role assignments are a common audit finding.
Build steps and cost drivers
- Write a governance charter. List the governed parameters, the operational decisions and the emergency process.
- Build or adopt the marketplace core. The core covers listings, offers, auctions and royalties, as the NFT marketplace development guide explains.
- Deploy on a testnet. Deploy the token, the Governor and the timelock, then move every admin role to the timelock, and confirm that no other key holds one.
- Add a voting interface. Build one, or use an existing app such as Tally, now renamed Cactus, which supports OpenZeppelin Governor contracts.
- Audit, then launch with cautious settings. Use a long timelock, a high proposal threshold and a guardian pause.
- Hand over control in stages. Move treasury and fee controls to governance as voter participation grows.
The governance contracts are not the expensive part. The following is a reasoned estimate, not a quote. With audited OpenZeppelin modules, the governance contracts take a senior Solidity developer a few weeks, plus audit time. The marketplace, the indexing and the ongoing community work cost more.
Some projects let the DAO own the whole platform and its treasury. The NFT DAO development guide covers that model.
When not to add governance
A marketplace with no users attracts mostly speculators and users who only want rewards when it launches a token. Such a marketplace can start with fixed, published fee rules and add governance once the community has decisions to make. A token that exists only to be listed on exchanges usually loses value, and the marketplace's reputation suffers with it.
Frequently asked questions
What is DAO governance?
DAO governance is a system in which token holders propose and vote on changes, and smart contracts carry out the approved changes. In a marketplace, the votes usually cover fees, royalties, treasury spending and upgrades.
Do I need a governance token, or can NFTs vote?
NFTs can vote through ERC721Votes, with one vote per token, which suits a community around one collection. A marketplace with many collections usually uses a fungible token, because the marketplace can distribute it to traders and creators across all collections.
Is Snapshot voting binding?
No. Voters sign Snapshot votes off-chain, and the votes do not execute themselves. A multisig usually carries out the result, so users trust the signers, while a Governor contract with a timelock enforces the result in code.
Can governance change creator royalties?
Yes, if the marketplace contract reads its royalty policy from a governed parameter. EIP-2981 royalty data is only a signal to marketplaces, so a vote on one marketplace does not bind other marketplaces.
How long should the timelock be?
The timelock should give users enough time to notice a proposal and leave if they disagree. Two to seven days is common. Add a guardian that can pause trading but cannot change parameters, so emergencies do not wait for the timelock.