How to Create a Governance Token for a DAO

Governance tokens sit at the center of how decentralized organizations make decisions. When a DAO decides where its treasury goes, which protocol upgrade ships, or how fees are set, the vote is usually weighted by a governance token that members hold. Getting the token right — the voting mechanics, the supply, the distribution, and the safeguards — is the difference between a DAO that governs itself and a token that merely exists.

This guide explains what a governance token actually is, how on-chain governance works step by step, the trade-offs between voting models, and the specific OpenZeppelin contract pattern most serious DAOs rely on. It then walks through a practical, no-code path to deploy one and connect it to real governance. Throughout, the focus is on accurate, citable detail rather than hype — a token contract is trivial to deploy, but a functioning DAO is not.

If you already understand the fundamentals of the underlying standard, you can create an ERC-20 token as the base layer and then layer governance on top. Let’s start with what the token is and why it matters.

What Is a Governance Token?

A governance token is an ERC-20 token that grants its holder voting power over a protocol or DAO. Rather than representing only value that can be traded, each token is a proportional say in collective decisions — how the treasury is spent, which upgrades are adopted, what fees are charged, and how the organization evolves.

Mechanically, a governance token is built on the same ERC-20 interface as any other fungible token. It transfers between wallets, trades on decentralized exchanges, and displays in MetaMask exactly like USDC or LINK. What sets it apart is how it is used: an on-chain governance system reads token balances to determine how much weight each participant carries in a vote. The canonical examples are UNI, which lets holders vote on Uniswap protocol parameters, and COMP, which governs the Compound lending protocol. In both cases, the token is not just an asset — it is a credential for participating in decisions.

The important distinction is that a token holder is not automatically a decision maker in a plain ERC-20. Voting power has to be measured reliably, and that requires the token to expose more than balances — it needs a way to record historical voting weight so a vote cannot be gamed by moving tokens around mid-proposal. That is where the specialized voting extensions come in, which we cover in detail below. A governance token is best thought of as an ordinary utility token with a voting-power layer bolted on, and the design of that layer is what makes governance trustworthy or fragile.

It is worth being precise about what a governance token is not. It is not a share of legal ownership in a company, it is not a promise of dividends, and it is not, on its own, a functioning organization. It is a coordination tool. Whether that tool produces good decisions depends entirely on the humans holding it and the rules wired around it.

How On-Chain Governance Works

On-chain governance is the process by which token holders propose, vote on, and automatically execute changes to a protocol using smart contracts. Nothing is enforced by a central administrator; the rules live in code, and the outcome of a valid vote executes without anyone needing to be trusted to carry it out.

The lifecycle of a typical on-chain proposal moves through several distinct stages:

• Proposal. A holder with enough voting power — often above a minimum proposal threshold — submits a proposal. In an executable governance system, the proposal is not just text; it encodes the exact contract calls that will run if it passes, such as transferring treasury funds or upgrading a parameter.
• Voting delay. After submission, there is usually a short delay before voting opens. This gives the community time to read the proposal and, critically, to set the voting-power snapshot at a fixed block so weights cannot be manipulated after the fact.
• Voting period. For a defined window — measured in blocks or days — holders cast votes: for, against, or abstain. Each vote is weighted by the holder’s voting power as recorded at the snapshot block.
• Quorum. For a vote to count, total participation must meet a minimum quorum — a threshold of voting power that must engage for the result to be valid. Quorum prevents a tiny minority from passing changes while the rest of the community is inattentive.
• Timelock. A passing proposal typically does not execute immediately. It is queued in a timelock contract that enforces a mandatory delay before execution. This window lets anyone who disagrees exit the protocol or raise an alarm before an approved change takes effect — a crucial safety valve against malicious or rushed proposals.
• Execution. Once the timelock delay elapses, the encoded contract calls execute on-chain. The treasury moves, the parameter changes, the upgrade ships — automatically and verifiably.

This structure is what makes on-chain governance credible: proposals are transparent, votes are auditable, quorum guards against apathy-driven capture, and the timelock protects holders from surprise. Off-chain systems such as signaling votes exist too and are cheaper, but they rely on a trusted party to honor the result. Fully on-chain governance removes that trust assumption at the cost of gas and rigidity.

Voting Models Compared

The three main voting models are token-weighted voting, quadratic voting, and delegated voting, and each trades off simplicity against resistance to concentration of power. Choosing among them is one of the most consequential decisions in governance design.

Token-weighted voting is the default and by far the most common. One token equals one vote, so a holder with a million tokens has a million times the influence of a holder with one. It is simple, transparent, and trivially verifiable on-chain, which is why nearly all major DAOs use it. The obvious weakness is plutocracy: whoever holds the most tokens holds the most power, and a single large holder — a whale, an early investor, or an exchange — can dominate outcomes.

Quadratic voting tries to soften that concentration. Instead of vote weight scaling linearly with tokens, it scales with the square root of the tokens committed, so each additional unit of influence costs progressively more. A holder with a hundred tokens gets roughly ten votes rather than a hundred. In principle this gives smaller holders proportionally more say. In practice, quadratic voting is difficult to run purely on-chain because it assumes one person equals one account. Anyone can split their tokens across many wallets to sidestep the square-root penalty — a Sybil attack — so quadratic systems require a reliable identity or personhood layer, which remains an unsolved problem for permissionless chains. It is most often used in grant-funding rounds with vetted participants rather than open protocol governance.

Delegated voting is not really an alternative counting rule but a layer on top of token-weighted voting. Holders can assign their voting power to a delegate — a representative who votes on their behalf — without giving up ownership of the tokens. This concentrates decisions with engaged, informed participants while letting passive holders still contribute weight. Most large DAOs combine token-weighted voting with delegation, which is exactly what the standard OpenZeppelin pattern implements.

For most projects, token-weighted voting with delegation is the pragmatic choice: it is battle-tested, cheap to run, and well supported by tooling. Quadratic voting is worth considering only when you have a genuine identity solution and a specific reason to resist whale dominance.

The ERC20Votes and Governor Pattern

The OpenZeppelin ERC20Votes and Governor contracts are the industry-standard way to build on-chain governance, and understanding them plainly is the key to designing a sound token. ERC20Votes is an extension of the ordinary ERC-20 token that adds vote tracking; Governor is the separate contract that runs proposals and voting using that tracked weight.

The core problem ERC20Votes solves is the snapshot problem. If a vote simply read current balances, a bad actor could borrow a large amount of tokens, vote, and return them in the same transaction — a flash-loan governance attack. To prevent this, ERC20Votes records checkpoints: every time an account’s voting power changes, the contract stores the new value against the block number. When a proposal is created, the Governor takes a snapshot at a specific past block, and every vote is weighed by the voting power each account held at that exact block. Because history cannot be rewritten, borrowing tokens after the snapshot gives no extra power.

The second concept that trips up newcomers is that holding tokens does not, by itself, grant voting power in this pattern. A holder must call delegate() before their tokens count — even if they delegate to their own address. This is a deliberate design choice: it keeps the gas cost of checkpoint updates off ordinary transfers for accounts that never intend to vote, and it makes delegation a first-class feature. It also explains a common surprise where a large holder finds their proposal has zero support: they and their community never delegated, so their tokens carry no weight. Any onboarding flow for a governance token should prompt holders to delegate.

The Governor contract sits alongside the token and orchestrates the proposal lifecycle described earlier — proposal threshold, voting delay, voting period, quorum, and vote counting — all reading vote weight from the token’s snapshots. It is typically paired with a TimelockController so that passed proposals queue and wait before executing, and ownership of the protocol’s privileged functions is usually transferred to the timelock so that only successful governance votes can change anything. This separation — token for weight, Governor for process, timelock for safety — is what gives the pattern its resilience. These contracts have been audited repeatedly and are used in production by major protocols, which is why building on them is strongly preferred over writing governance logic from scratch. If you want to see how the underlying token library is structured, our overview of the OpenZeppelin ERC-20 contracts covers the base implementation these extensions build on.

Designing Supply and Distribution

For a governance token, distribution matters far more than the absolute supply number, because governance power is only as legitimate as the spread of the tokens that carry it. A token concentrated in a handful of wallets is a governance system that a handful of wallets control, regardless of how democratic the voting contract looks.

The total supply figure itself is largely arbitrary — whether you mint ten million or one billion tokens changes nothing about who controls decisions. What determines the health of governance is how those tokens are allocated across four broad buckets:

• Community and airdrop. Distributing a meaningful share to actual users spreads voting power to the people who use the protocol. Retroactive airdrops to early participants are a common and effective way to bootstrap a broad, engaged holder base rather than a speculative one.
• Treasury. A portion is usually held by the DAO treasury itself, controlled by governance, to fund development, grants, liquidity, and incentives over time. This is the war chest that a passed proposal can deploy.
• Team. Founders and contributors receive an allocation as compensation and incentive. To avoid the appearance — and the reality — of insiders dumping or capturing votes, this allocation should be locked and released gradually.
• Investors. If the project raised capital, investors hold an allocation. Like the team’s, it is typically subject to a lockup so that early backers cannot control governance from day one.

The central risk to guard against is whale capture: a distribution where one entity or a small colluding group holds enough voting power to pass proposals unilaterally. A thoughtful distribution keeps any single actor below the threshold needed to force outcomes, and pairs that with a sensible quorum so that decisions require genuine participation. There is no formula that guarantees decentralization, but a wide community allocation, a governance-controlled treasury, and capped insider holdings are the practical levers.

Team and investor allocations should almost always vest rather than unlock at once. A vesting schedule releases tokens gradually over months or years, often after an initial cliff, which aligns insiders with long-term outcomes and prevents a sudden flood of voting power — or sell pressure — at launch. For a fuller treatment of how to structure the overall allocation, supply mechanics, and emissions, our guide on ERC-20 tokenomics and distribution goes deeper. Vesting is not a cosmetic detail in governance; unvested insider tokens are a live risk of capture until they are actually locked.

Delegation and Voter Apathy

Delegation exists largely to solve voter apathy, which is the single most persistent problem in real-world DAO governance. The uncomfortable reality is that most token holders never vote, and a token that no one votes with produces governance in name only.

Voter apathy is rational at the individual level. Reading a technical proposal, evaluating its merits, and paying gas to vote costs time and money, while a single small holder’s vote rarely changes the outcome. Multiply that across thousands of holders and turnout collapses. It is common for governance votes to draw participation from only a small fraction of eligible voting power, which means a determined minority can meet quorum and decide for everyone.

Delegation is the standard mitigation. By assigning their voting power to a delegate they trust — a knowledgeable community member, a working group, or a professional delegate who publishes their reasoning — passive holders keep their tokens while ensuring their weight is used thoughtfully by someone who does the work. Well-run DAOs actively cultivate a delegate ecosystem, with delegates publishing platforms and voting records so holders can choose representatives whose values match their own.

But delegation is not a cure-all, and it introduces its own tension. Concentrating voting power in a few active delegates recreates, in softer form, the concentration that decentralization was meant to avoid. If three delegates control a majority of active voting power, they effectively govern. Good design therefore treats delegation as a tool to be balanced with broad participation incentives, transparent delegate accountability, and quorum rules that keep power honest. The honest takeaway is that no contract mechanism eliminates apathy; sustained participation is a community and culture problem that tooling can support but not replace.

Legal Caution

Governance tokens can attract securities scrutiny, and this section is general information rather than legal advice. Whether a token is treated as a security depends on the jurisdiction and the specific facts of how it is created, sold, and marketed, and the answer can differ sharply from one country to another.

The recurring concern regulators raise is whether a token was sold with an expectation of profit derived from the efforts of a central team. In several jurisdictions, that framing — not the label on the token — is what determines regulatory treatment. Importantly, adding governance utility does not automatically place a token outside the reach of securities law. A token can be both a genuine governance instrument and, depending on how it was distributed and promoted, a regulated offering. Public sales, promises of returns, and marketing that emphasizes price appreciation all tend to increase regulatory risk.

Practical implications follow from this. If you plan any kind of public sale or broad distribution, obtain advice from a qualified lawyer in your jurisdiction before you proceed — this is not optional diligence, and the cost of getting it wrong can be severe. Be careful about how the token is described: framing it around governance participation and utility is materially different from framing it around investment returns. And keep records of the token’s design rationale and distribution. None of this substitutes for professional counsel; it simply reflects that the legal dimension of a governance token is as real as the technical one, and it should be addressed before launch rather than after.

A Practical Deployment Path

The practical path to a working governance token is to deploy the ERC-20 token with the votes extension, set up a Governor and timelock, distribute with vesting, and verify everything on Etherscan. Here is how those steps fit together in order.

Step one: deploy the token. Start by deploying the base ERC-20 token. If you want on-chain governance from the outset, enable the votes extension so the token tracks the checkpoints the Governor will read. You can do this without writing Solidity by using an ERC-20 token creator that generates the contract from the audited OpenZeppelin library and deploys it directly from your wallet. Decide the name, symbol, and total supply in advance, since the identifying parameters are permanent once deployed.

Step two: set up the Governor and timelock. Deploy an OpenZeppelin Governor contract configured with your chosen proposal threshold, voting delay, voting period, and quorum, and pair it with a TimelockController that enforces an execution delay. Transfer control of any privileged protocol functions to the timelock so that only successful governance votes — not a private key — can change anything. This is the step that turns a token into an actual governance system.

Step three: distribute with vesting. Allocate the supply across community, treasury, team, and investors according to your plan, and lock the team and investor portions behind a vesting schedule. Distributing broadly and vesting insiders is what protects the young DAO from whale capture and sudden sell pressure. Prompt holders to delegate their voting power — remember that undelegated tokens carry no weight in the ERC20Votes pattern.

Step four: verify on Etherscan. Publish and verify the source code of the token, Governor, and timelock contracts on Etherscan so anyone can read exactly what the governance system does. Verified contracts are a baseline trust signal; an unverified governance contract asks the community to trust code they cannot inspect, which defeats the purpose.

One honest caveat deserves emphasis. Completing these four steps gives you a technically sound governance token, but it does not give you a healthy DAO. A token is the voting instrument, not the organization. Participation, a clear proposal process, engaged delegates, sensible quorum, and a genuinely broad distribution are what make governance function — and none of those come from the contract. The same care applies whether you are building governance, a stablecoin, or any other token: the deployment is the easy part, and the design and community around it are the real work. When you are ready to lay the foundation, you can create your own ERC-20 token and build governance on top of it.

FAQ

A governance token is the coordination layer of a DAO, and it deserves the same care as any other critical piece of infrastructure. Choose a voting model you can actually run, build on the audited ERC20Votes and Governor pattern, distribute widely, vest your insiders, and verify everything on-chain. Then do the harder, non-technical work of building participation.

Ready to lay the foundation? Create your own ERC-20 token on our platform now, then connect it to a Governor and timelock to bring your DAO’s governance on-chain. To plan the supply and allocation before you deploy, our guide on ERC-20 tokenomics and distribution is the natural next read.