How to Revoke a Governance Delegation

2026-09-03

How to Revoke a Governance Delegation

You delegated your voting power once and now you want it back. There is no separate revoke instruction in the contract, and there does not need to be one, because a delegation is a single field that you overwrite. What you cannot do is take it back retroactively.

How to Revoke a Governance Delegation: key points at a glance

What a delegation actually moved

Holding a governance token is not the same as holding voting power. OpenZeppelin's governance documentation is explicit that it is delegates who carry voting power: a holder who wants to participate can set a trusted representative as their delegate, or become a delegate themselves by self-delegating. Compound's documentation describes the same step, with token holders delegating their voting rights to themselves or to an address of their choice.

Nothing left your wallet when you did that. Compound states the size of what does move: the number of votes added to the delegate's vote count is equivalent to the balance held in the user's account. Your tokens stayed where they were, a destination was recorded beside them, and a vote count at another address rose by your balance.

The design reason is cost. OpenZeppelin notes that by default a token balance does not account for voting power, which makes transfers cheaper, and the stated downside is that it requires users to delegate to themselves in order to activate the tracking at all. Voting power is opt-in machinery attached to the side of a balance, not a property of the balance.

So the thing you are undoing is a pointer, not a transfer. The question is not how to get tokens back, because they never went anywhere. It is what that pointer should say next.

Revoking is another delegation, not a deletion

Compound's documentation states that votes are delegated from the current block onward, until the sender delegates again or transfers their tokens. Read that clause backwards and it is the revocation procedure: you delegate again.

The field holds one destination, so there is no empty slot to return to and no second instruction to send. Writing a new destination overwrites the old one in the same act. An interface that offers you a revoke control and an interface that offers only a delegate control are therefore doing the same thing underneath, and the prompt your wallet asks you to sign will say delegate in both cases.

Two consequences follow. Revoking costs a transaction and a fee, exactly as the original delegation did. And revoking is public: the new destination is written on chain, where anyone reading the delegate register can see it.

Where the weight goes when you act

Undoing a delegation is a choice of destination, and the destinations do not leave you in the same position.

What you do Your former delegate's count Your own voting power
Delegate to yourself Falls by your balance Equal to your balance
Delegate to a different address Falls by your balance Still zero, now carried by someone else
Transfer the tokens away Falls by the balance you moved Gone with the tokens
Do nothing Unchanged Zero

Only the first row makes you a voter. The second is a change of representative rather than a withdrawal from the system. The third works, and it is a poor route to the goal, because it disposes of the asset in order to adjust a field. The fourth deserves naming: a holder who stops trusting a delegate and then does nothing has not registered dissent, since the weight keeps being cast on their behalf.

Why an already open proposal does not move

This is where a revocation feels broken when it is not. OpenZeppelin's governance extension keeps historical balances so that voting power is retrieved from past snapshots rather than from a current balance, which its documentation calls an important protection that prevents double voting. Compound reads weight the same way, with addresses that held voting weight at the start of the proposal being the ones able to submit votes.

A revocation therefore takes effect at the block it is mined in and applies from there onward. If a proposal's snapshot block has already passed, the tally for that proposal reads the register as it stood then, and your former delegate can still cast your weight on it after you have taken the delegation back.

The practical rule is a deadline, not a button. To keep a delegate from voting your weight on a particular proposal, the revocation has to be recorded before that proposal's snapshot. A revocation sent the day after a contested vote opens is correct, in time for everything that follows, and worth nothing on the vote you were reacting to.

What revoking does not do

Revoking a delegation is not the same operation as revoking a token approval, and the shared verb hides a real difference. An approval is standing permission for a contract to move your tokens. A delegation grants no such permission: a delegate can vote your weight and cannot touch your balance. Clearing every approval on your wallet leaves your delegation where it was, and revoking your delegation leaves every approval where it was.

It does not unwind what your delegate already did. Votes already cast stay cast, proposals already decided stay decided, and the record of how your weight was used is not edited by the revocation.

It does not free tokens that a separate contract is holding. If your balance is locked, staked, or wrapped into a vote-escrow position, the delegation attached to that position follows that contract's rules, and a revocation sent to the token contract does not reach it.

Off-chain delegation is revoked somewhere else

Not every vote is settled on chain, and a DAO that runs its ballots off chain keeps its delegation register outside the token contract. Snapshot's documentation describes three routes for delegating: a delegate registry, used when a space has set up a custom delegation contract; Snapshot's own delegation page, which it presents as the quickest solution to delegate to a known address; and direct interaction with the contract.

That plurality is what to check before you assume the job is finished. Snapshot's documentation also notes that a direct delegation to a chosen space has priority over a delegation made across all spaces, so one holder can be delegated in more than one place at once, with a defined order between them.

The audit is simple to state. List every register in which your address appears as a delegator, on chain and off, and clear them one at a time. A revocation in the token contract says nothing about a registry entry that a different system reads.

A worked sequence

Suppose you hold 10,000 tokens and delegated them to an address that carries 250,000 of voting weight in total, so your balance is 4% of what that delegate can cast. Proposal A opens and its snapshot block passes. You then delegate to yourself.

From that block onward, two statements are true at once. On Proposal A, your former delegate still carries 250,000, because that tally reads the snapshot and not the register as it stands now. On the next proposal, the same delegate carries 240,000, and you carry 10,000 that you can cast yourself.

The second line is also where the reporting changes. Your weight moved from a delegate to a holder, which pulls a voter concentration reading down and the headcount of participants up, while a voter participation rate measured against delegated weight improves only if you then cast a vote. Taking your weight back and never using it puts you in the same place as leaving it with a delegate who abstains.

The bottom line

A delegation is one field holding one destination, so revoking it means writing a new destination rather than deleting an old one. Delegate to yourself and you become the voter, delegate elsewhere and you have changed representative, do nothing and your weight keeps being cast without you.

The part that catches people is timing. Voting power is read from a past snapshot, so a revocation binds every proposal whose snapshot comes after it and none of the ones already open. Check the delegate register before a vote you care about rather than after it, and check every register your organisation actually uses. To keep learning the fundamentals, follow more from Bitbase Academy.

Related reading

Other Bitbase articles on this topic:

- Why a Token Migration Asks for a Wallet Approval

- Token Migration Completed but New Tokens Are Not in Your Wallet

- How to Calculate a Token Treasury Runway

- NVT Ratio Explained: Network Value to Transactions

- Airdrop Scams and a Pre-Claim Safety Checklist

Disclaimer: This article is educational content from Bitbase Academy, provided for information only. It does not constitute investment, trading, tax, or financial advice. Crypto assets are volatile; assess your own risk. Written as of September 2026; refer to the latest official information.

References

[1] OpenZeppelin Contracts Documentation 5.x, Governance docs.openzeppelin.com

[2] OpenZeppelin Contracts Documentation 5.x, API, ERC20 (ERC20Votes) docs.openzeppelin.com

[3] Compound Documentation, Governance (Compound v2) docs.compound.finance

[4] Snapshot Documentation, User guides, Delegation docs.snapshot.box

Related Articles

More Recommendations