Governance Tokens on ERC20: UNI, AAVE, Compound Patterns

Compound's COMP launched in 2020 and gave every other DeFi protocol a template. Uniswap's UNI followed. AAVE migrated from LEND to a governance plus safety module model. Today every serious DeFi protocol that wants to decentralize control issues some variant of the same pattern.

The pattern looks simple on the surface. Mint a token. Let holders vote. Execute the result on chain. Each of those three steps hides a sharp engineering problem. This post walks through the actual contract surface — the ERC20Votes extension, the Governor lifecycle, and the staking modules that sit alongside.

If you have already read the ERC standards explainer, you know the ERC20 interface is the easy part. Everything in this post is what production teams add on top.

Every time a holder's balance changes, the contract writes a new checkpoint: a tuple of block number and balance. When a Governor needs to know how much vote weight an address had at a past block, it walks the checkpoint array and returns the right snapshot.

// OpenZeppelin ERC20Votes — checkpointed balances for snapshot voting
contract GovToken is ERC20, ERC20Permit, ERC20Votes {
    constructor()
        ERC20("Protocol Governance", "PGOV")
        ERC20Permit("Protocol Governance")
    {}

    // Snapshots are taken automatically on transfer, mint, burn
    function _afterTokenTransfer(address from, address to, uint256 amount)
        internal
        override(ERC20, ERC20Votes)
    {
        super._afterTokenTransfer(from, to, amount);
    }

    function _mint(address to, uint256 amount)
        internal
        override(ERC20, ERC20Votes)
    {
        super._mint(to, amount);
    }

    function _burn(address account, uint256 amount)
        internal
        override(ERC20, ERC20Votes)
    {
        super._burn(account, amount);
    }
}

That looks like a normal ERC20 contract with a few overrides. The interesting work happens inside the _afterTokenTransfer override, which schedules the checkpoint write. The cost is roughly an extra 15,000 gas per transfer compared to a plain ERC20. For a governance token, that is a fair price.

Most holders do not vote directly. The realistic governance participation rate across major DAOs is below 10 percent of supply. The delegation system is what makes the remaining tokens politically active without forcing every holder to follow every proposal.

// Delegation transfers voting power without moving tokens
function delegate(address delegatee) public virtual override {
    _delegate(_msgSender(), delegatee);
}

// Internal — moves vote weight from current delegate to the new one,
// writes a fresh checkpoint at the current block number
function _delegate(address delegator, address delegatee) internal virtual {
    address currentDelegate = delegates(delegator);
    uint256 delegatorBalance = balanceOf(delegator);
    _delegates[delegator] = delegatee;

    emit DelegateChanged(delegator, currentDelegate, delegatee);

    _moveVotingPower(currentDelegate, delegatee, delegatorBalance);
}

// Vote weight at a past block — Governor uses this at proposal snapshot
function getPastVotes(address account, uint256 blockNumber)
    public
    view
    virtual
    override
    returns (uint256)
{
    require(blockNumber < block.number, "ERC20Votes: block not yet mined");
    return _checkpointsLookup(_checkpoints[account], blockNumber);
}

A holder calls delegate to assign their voting power to another address. The tokens stay in the holder's wallet. The vote weight moves to the delegate's checkpoint. When a proposal opens, the Governor reads getPastVotes against the delegate, not the original holder.

Anyone with at least the proposal threshold of voting power can submit a proposal. The proposal carries a target contract address, a function selector, the calldata, and a description string. The Governor hashes those into a proposal id.

// Governor lifecycle — propose, vote, queue, execute
function propose(
    address[] memory targets,
    uint256[] memory values,
    bytes[] memory calldatas,
    string memory description
) public returns (uint256) {
    require(
        getVotes(msg.sender, block.number - 1) >= proposalThreshold(),
        "Governor: proposer votes below threshold"
    );

    uint256 proposalId = hashProposal(targets, values, calldatas, keccak256(bytes(description)));

    proposals[proposalId] = ProposalCore({
        voteStart: block.number + votingDelay(),
        voteEnd: block.number + votingDelay() + votingPeriod(),
        executed: false,
        canceled: false
    });

    return proposalId;
}

function castVote(uint256 proposalId, uint8 support) public returns (uint256) {
    uint256 weight = token.getPastVotes(msg.sender, proposals[proposalId].voteStart);
    return _countVote(proposalId, msg.sender, support, weight);
}

Voting opens after a delay, runs for the configured period, and closes. If the proposal hits quorum and a majority vote in favor, anyone can queue it into the Timelock. The Timelock holds the proposal for the configured delay — usually 48 hours — before anyone can execute it. The delay is the protocol's emergency window: if a malicious proposal sneaks through voting, the community has 48 hours to react.

These parameter ranges look conservative. They are. Most proposals are routine — fee tweaks, asset listings, treasury allocations. The conservative parameters are insurance against the rare proposal that should never pass.

AAVE's safety module is the cleanest production example. A holder stakes AAVE into the module and receives stkAAVE — itself an ERC20Votes token. The stake earns protocol rewards and serves as a shortfall buffer: if the AAVE protocol takes a loss, the safety module can be slashed up to 30 percent to cover it.

// AAVE safety module — stake AAVE, earn protocol fees, absorb shortfall
function stake(address onBehalfOf, uint256 amount) external override {
    require(amount > 0, "INVALID_ZERO_AMOUNT");

    uint256 balanceOfUser = balanceOf(onBehalfOf);
    uint256 accruedRewards = _updateUserAssetInternal(
        onBehalfOf,
        address(this),
        balanceOfUser,
        totalSupply()
    );

    if (accruedRewards != 0) {
        stakerRewardsToClaim[onBehalfOf] = stakerRewardsToClaim[onBehalfOf] + accruedRewards;
    }

    stakersCooldowns[onBehalfOf] = getNextCooldownTimestamp(0, amount, onBehalfOf, balanceOfUser);

    _mint(onBehalfOf, amount);
    IERC20(STAKED_TOKEN).safeTransferFrom(msg.sender, address(this), amount);
}

The stake function does four things. It updates the reward accrual for the staker. It records a cooldown timestamp that defines when the staker can unstake. It mints stkAAVE one to one against the deposited AAVE. It pulls the underlying AAVE into the safety module contract.

Curve's vote escrowed CRV uses a different shape. A holder locks CRV for a fixed duration — up to four years — and receives veCRV in exchange. veCRV is non transferable and decays linearly toward zero as the lock approaches expiry. Longer locks earn more vote weight. The mechanism aligns voting power with time committed, not just capital committed.

Read getPastVotes, not balanceOf, when you need the vote weight at a specific point in time. balanceOf returns the current balance, which a holder can move between checkpoints. getPastVotes returns the snapshot, which is what the Governor itself uses.

Treat delegation as the actual voting unit. A wallet with 10 million UNI that has not delegated has zero voting power on a proposal. A wallet with zero balance that holds 50 million UNI of delegated weight is a power user. Reading raw balances will mislead you.

Track the Governor address separately. The token contract is rarely upgraded. The Governor is. Compound migrated from GovernorAlpha to GovernorBravo without changing COMP. Your integration needs to follow the current Governor through that migration or risk pointing at a dead contract.

For a deeper read on how on chain ownership composes with other ERC20 use cases like stablecoin custody flows, the same contract surface lessons apply: the standard interface is rarely where the operational risk lives.

We help protocols ship governance and tokenomics systems end to end — the ERC20Votes token, the Governor, the Timelock, the staking module if you need one, and the operational playbook for running proposals once the system is live. The technical surface is tractable. The political surface is the harder part.