Compound
Compound lets COMP holders delegate voting power while retaining their tokens
Compound lets COMP holders assign governance voting power to another address without transferring their tokens. The COMP contract records the choice, and holders can delegate to themselves or change delegates. Proposals use historical voting power, so a later delegation change can't necessarily change who can vote on an existing proposal.
Jump to a section
Key takeaway: A COMP delegation change affects future snapshots, while proposals with completed snapshots retain their historical voting weights.
Voting authority leaves token custody unchanged
COMP delegation assigns governance influence while the holder keeps control of the tokens in the same address. The delegate gains voting weight associated with that balance. Delegation doesn't create an ERC-20 spending allowance or grant access to the holder's lending position. Those permissions have separate mechanisms. A delegate can support protocol changes that affect lending markets, including collateral rules, so retaining custody doesn't remove the consequences of the delegate's governance choices.
Can you take voting power back from a delegate?
Yes, a holder can replace the selected COMP delegate without obtaining the previous delegate's permission or transferring tokens. The change affects current voting power and later proposal snapshots. It doesn't rewrite the voting weight that an earlier snapshot established.
Self-delegation
Selecting the holding address assigns its COMP voting weight to that same address. This supports direct participation in governance. Simply holding tokens doesn't automatically self-delegate them, and choosing yourself doesn't cast a ballot.
A different representative
The token contract assigns each holder's balance to one delegate at a time. Changing that address replaces the previous selection for that balance. It doesn't divide the holder's delegation between representatives.
No active delegate
Delegation to the zero address removes that balance's contribution to current delegated voting power. It leaves token ownership intact. Historical checkpoints remain available, including those that determine voting weight for an existing proposal.
Direct delegation and signature submission
The COMP token supports a direct contract call and delegation through a signed message, with different submission responsibilities.
A transaction from the holding address
The delegate function changes the caller's selected representative. The transaction calls the COMP contract and names the voting recipient as an argument. These addresses have different jobs: the token contract handles the action, while the delegate receives voting authority. Delegation doesn't require sending tokens to either address.
A message that someone else can submit
The delegateBySig function applies a delegation that the holder authorized with an EIP-712 typed signature. Signing the message doesn't use transaction gas. Someone must submit it on-chain, and that submitter pays the transaction's gas cost. Protocol support for signed delegation doesn't establish that a particular interface offers a funded relay. A saved signature, a submission identifier and a successful contract call represent different states; only successful execution applies the delegation.
The limits of an unused delegation signature
The signing domain
The signed domain includes the token name, chain ID and verifying contract. The message names the delegate, nonce and expiry. Review those fields together: a familiar token label alone doesn't establish the intended contract or recipient.
The nonce and submission deadline
The nonce must match the signer's value in the COMP contract. Successful signature delegation increments the signer's nonce in the COMP contract. The expiry limits when the contract will accept the signature. It doesn't schedule the accepted delegation to end. EIP-712 provides structured signing; the token's nonce check supplies protection against reusing an accepted delegation signature.
A direct change leaves the signature nonce untouched
A direct delegate call doesn't advance the signature nonce. An unused, unexpired signature can therefore remain usable after a direct change and later replace that selection. A new displayed delegate alone doesn't prove that an outstanding signature has become invalid.
When does delegation count toward a proposal?
Delegation counts toward a proposal through the COMP voting weight recorded at its snapshot block. The governor uses the delegate's historical delegated votes, which can differ from the votes available today.
Changing representatives after that block updates current voting power without changing the proposal's allocation. The previously selected delegate can retain voting weight for that proposal, even after the holder chooses someone else.
A signed message awaiting submission hasn't changed the contract state. A pending transaction also hasn't established that change. The governor's proposal record supplies the snapshot; a wall-clock estimate doesn't establish voting eligibility.
An address with snapshot voting weight still needs to submit its ballot while the proposal accepts votes. Governance configuration controls voting delays and periods, so fixed calendar promises can misdescribe a proposal's actual schedule.
Transfers adjust votes without rewriting past snapshots
A COMP transfer changes ownership and can change delegated voting weight, even though the sender hasn't submitted another delegation.
Nonzero COMP transfers update current delegated voting power when the sender and recipient have different delegate selections. Any active delegate for the sender loses the transferred balance's contribution. The recipient's delegate gains it if the recipient has chosen one. Receipt of tokens doesn't automatically copy the sender's delegate selection. When both addresses share a delegate, the transfer leaves that delegate's aggregate voting weight unchanged.
The holder's delegate selection remains in contract state after a transfer. Future incoming COMP can contribute to that selected address. None of these changes moves voting weight backward in time. A proposal that uses an earlier snapshot retains the allocation that existed at that block.
Gas costs follow transaction inputs
Delegation costs arise from Ethereum transaction execution, with gas usage and the effective fee per gas determining the network charge. The number of COMP tokens delegated doesn't set a percentage-based delegation fee. Contract execution and network conditions drive the charge, so a fixed monetary quote wouldn't describe every submission. The submitting address pays transaction gas in ETH. For signed delegation, that address can differ from the holder who supplied the signature. A relay may cover the network fee or apply separate service terms; neither arrangement follows automatically from the token contract's signature support.
A transaction that executes and reverts can still consume gas. Creating another signature doesn't undo that cost. Reading contract state through a query doesn't require a new state-changing transaction, which makes a refreshed read useful before paying for a correction.
Resolve a delegation that differs from the expected state
A holder who signed a delegation may expect an updated delegate immediately. The contract must execute the signed message successfully before the delegation changes. If contract state already names the intended delegate, a stale interface display calls for a refreshed read.
- If the receipt shows success and the selected delegate matches, refresh the display before submitting another transaction.
- If only a signature exists, establish whether anyone has submitted it before creating a competing authorization.
- If signature submission reverted, check its nonce and expiry against contract state before signing corrected fields.
- If a successful call selected the wrong address, replace the delegation without moving COMP and account for outstanding signatures.
- If delegation matches but a proposal shows no voting weight, compare the change's block with that proposal's snapshot.
A refreshed query shows the recorded delegate without another transaction fee. A corrective delegation requires new execution and its associated gas cost. Once the proposal's snapshot has passed, a fresh delegation can't repair that proposal's historical voting allocation.
Delegate choice rests on the votes the address casts
A delegate's recorded ballots show how the address used voting authority on actual proposals, including the weight that counted. Participation frequency describes activity, while the decisions themselves reveal the delegate's positions. Neither a large aggregate vote balance nor a profile description establishes how the address will vote next. Review the proposed contract actions alongside any explanation of a ballot. A proposal about collateral factors has different implications from a contract upgrade or reserve withdrawal. A representative's reasoning about those changes offers a more specific basis for selection than a broad promise to improve the protocol.
Voting histories also need the right governor contract. A display that tracks only an older governor can miss ballots recorded by a replacement. Delegating to an address establishes authority, without guaranteeing attendance or agreement with the holder's preferences.
Delegated votes influence rules through governance
COMP voting power influences protocol decisions through governance proposals, while administrative contracts execute changes that satisfy the applicable governance rules.
Compound III governance can alter market configuration and upgrade implementations. Collateral parameters can affect borrowing capacity and liquidation exposure. Delegation itself doesn't change a loan balance.
Voting support doesn't immediately execute a market change. Successful proposals must satisfy the governor's requirements and the Timelock's execution conditions. A representative can't use delegated weight alone to bypass those contracts or directly operate a holder's lending account.
Creating a proposal also has different eligibility rules from receiving delegated votes. The governor's configured proposal threshold and any applicable exceptions help determine proposal eligibility. Quorum and vote-counting rules determine whether support succeeds. These settings belong to the relevant governor, so a delegate's current balance doesn't establish every governance permission or outcome.
Token balances and voting balances need different readings
The COMP contract exposes separate readings for token ownership, selected delegation and aggregated voting power, each answering a different question. balanceOf reports tokens held by an address. delegates identifies that holder's chosen representative. getCurrentVotes reports an address's current delegated votes, which can include contributions from other holders. A representative's aggregate voting balance doesn't identify any single holder's contribution. It can change through unrelated transfers or delegations from other addresses. The holder's balance and delegation record describe that holder's allocation; the representative's total describes the votes available across its contributors.
COMP uses 18 decimals, and raw vote amounts follow the same scaling as token balances. Comparing a formatted wallet amount with an unconverted contract integer can create an apparent discrepancy. Historical queries also require a block earlier than the current block. For an existing proposal, the relevant historical lookup is getPriorVotes.
Useful questions about Compound
Can a delegate pass votes received from other holders to another address?
A COMP delegate can't redirect other holders' delegated votes through the token's delegation function. That function assigns only the caller's own COMP balance. Each original holder controls that holder's representative, so changing a delegate's personal selection doesn't move the voting weight entrusted by other holders.
Does an exchange balance let me delegate COMP from my wallet?
A custodial exchange balance doesn't give your wallet authority over the exchange's COMP delegation. The token contract recognizes the address that actually holds the tokens. Delegation for a custodial balance depends on the custodian's support and terms; an account balance displayed by an exchange doesn't establish wallet voting rights.
What can someone learn from my delegation address?
Delegation exposes the holder address and selected representative through public contract state and events. Someone can relate those records to token balances and the representative's voting activity. Addresses don't identify a person by themselves, although information published elsewhere can link an address to an identity.
Is ordinary COMP delegation a staking reward program?
The COMP token's delegation functions assign voting authority without calculating or distributing staking rewards. A payment arrangement offered to holders would require separate terms and a separate mechanism. Choosing a delegate alone doesn't establish a claim to a payout or turn the holder's token balance into an interest-earning lending position.
When can an address that holds no COMP set a delegate?
An address doesn't need a positive COMP balance to call the token's delegation function. Submitting that call still requires an authorized transaction and gas payment. The selection carries no votes until tokens arrive, and later receipts can affect a proposal only through the voting weight at its snapshot.