Most token launches ship a vesting contract. Usually it's a fork of something from OpenZeppelin or a lightly modified version of whatever the legal team saw in a competitor's repo. The cliff is set to 12 months, the linear unlock runs for 36, and everyone moves on to the next item on the launch checklist.
Nobody goes back to ask what happens when those locked tokens can vote.
How Vesting Actually Works On Chain
A vesting contract holds tokens on behalf of a beneficiary and releases them on a schedule. The simplest version stores a start timestamp, a cliff duration, and a total vesting duration. Before the cliff passes, nothing is withdrawable. After the cliff, tokens unlock linearly per second or per block.
// Simplified release calculation
function vestedAmount(uint256 totalAllocation, uint256 timestamp) {
if (timestamp < start + cliffDuration) return 0;
if (timestamp >= start + vestingDuration) return totalAllocation;
return totalAllocation * (timestamp - start) / vestingDuration;
}That's fine for the transfer side. Tokens drip out, the beneficiary claims them periodically, the treasury balance decreases over time. But the transfer schedule and the governance rights schedule are two separate questions, and almost nobody treats them that way.
The Cliff is Not a Governance Cliff
In most ERC20 governance tokens, voting power comes from the balanceOf or a delegation snapshot. If your vesting contract holds 5 million tokens, those tokens exist. They sit at the contract address. They have weight.
The question is whether the vesting contract exposes a delegate() function.
Many do. The reasoning goes like this: the beneficiary earned those tokens, they should be able to participate in governance even before they can sell. Sounds reasonable in a board meeting. It's a disaster in practice.
Here's why. On day one of a four-year vest, a team allocation of 20% of total supply sits in vesting contracts. The cliff hasn't passed. Nobody can withdraw a single token. But if those contracts allow delegation, 20% of the voting power is live and controllable right now.
The Mechanics of Governance Capture
Say a protocol launches with 1 billion tokens. 200 million go to the team across 15 wallets, all in vesting contracts with 12 month cliffs and 48 month linear unlock. The community holds 300 million in liquid circulation. The remaining 500 million sits in a treasury controlled by governance.
If those 15 vesting contracts all delegate to a single address, that address controls 200 million votes on day one. The entire liquid community has 300 million. But voter turnout in DAOs is rarely above 15%. Realistically, maybe 45 million community votes show up for any given proposal.
The team block of 200 million wins every vote. Not close. Not debatable. Every single one.
This isn't theoretical. I've seen it play out on two protocols I won't name. In both cases the founding team passed treasury proposals that redirected funds to entities they controlled. Community members noticed, posted about it on governance forums, and lost the vote anyway.
Revocability Makes It Worse
Some vesting contracts are revocable. An admin address (usually a multisig controlled by the company) can claw back unvested tokens if an employee leaves or gets fired. This is standard for employee grants. It mirrors how equity works in traditional companies.
But revocable vesting plus delegation creates a coercion vector. If I can revoke your tokens, I can pressure you to delegate to me. Or more subtly, I can write the vesting contract so delegation defaults to a company address and changing it requires calling a function most beneficiaries won't ever touch.
The default delegation is the real weapon. Most people don't interact with governance contracts directly. They use a frontend, if they interact at all. If the vesting contract ships with a default delegate set to the company multisig, 95% of beneficiaries will never change it. The company keeps permanent governance control over tokens that are supposed to decentralize over four years.
What Good Design Looks Like
There are a few ways to handle this. None are perfect, but all of them beat the default.
Option 1. No delegation before cliff. The vesting contract just doesn't expose delegate() until the cliff has passed. Most conservative approach. Locked tokens have zero governance weight during the cliff period. Some teams hate this because it means early governance is entirely in the hands of public token holders, which can be chaotic. That chaos is the point. If you want decentralized governance, you have to actually let the community govern.
Option 2. Pro rata delegation. Voting power scales with the vested amount, not the total allocation. If you have vested 10% of your grant, you can delegate 10% of the voting power. This requires a custom implementation of the checkpoint and voting weight logic, but it accurately reflects the economic reality. You have earned 10%, so you get 10% of the voice.
function getVotes(address account) external view returns (uint256) {
// Only return voting power proportional to vested amount
uint256 vested = vestedAmount(allocations[account], block.timestamp);
return vested;
}Option 3. Time-delayed delegation changes. Delegation is allowed, but changing your delegate takes effect after a delay. This prevents flash governance attacks where a whale buys a vesting position on a secondary market and immediately redirects all votes. The delay gives the community time to react.
Option 4. Separate the vesting contract from the governance wrapper. Tokens in the vesting contract are non-voting. When tokens vest and get claimed, they arrive in the beneficiary's wallet as normal governance tokens. Clean separation of vesting schedule from voting rights, but it means no locked token holder participates in governance at all.
The Secondary Market Problem
There's another angle that gets less attention. Vesting positions are tradeable. Not officially, not on Uniswap, but through OTC desks and bilateral agreements. If I have a vesting contract that will release 5 million tokens over three years, I can sell the rights to that contract for a discounted lump sum today.
The buyer gets the tokens as they unlock. Fine. But if the vesting contract also carries delegation rights, the buyer gets immediate governance power over the full unvested amount. They paid a discount. They got full votes. Pure governance arbitrage.
I've watched OTC desks specifically market vesting positions with governance rights as a value-add. The pitch is straightforward: you're not just buying discounted tokens, you're buying a block vote in a protocol treasury worth nine figures.
What to Actually Do
If you are building a vesting contract for a governance token, think about these questions before you ship.
- Can locked tokens vote? If yes, who controls the delegation on day one?
- Does the default delegation point to the company or to the beneficiary?
- Is the vesting position transferable? If so, does governance power transfer with it?
- Is the contract revocable? Can the revoker influence delegation through that power?
- What percentage of total voting power sits in vesting contracts at launch? Is that number larger than realistic voter turnout?
Most of the damage I've seen came from teams that never asked these questions. They copied a vesting contract, added delegation because it seemed like the right thing to do, and ended up with a governance system where the outcome of every vote was predetermined.
The fix isn't complicated. It just requires someone to care about it before the contracts go immutable on mainnet. Once they're deployed, the governance capture is permanent for the life of the vesting schedule. Four years of predetermined outcomes, baked into the bytecode.
Build the vesting contract for the governance system you actually want. Not the one that was easiest to fork.