Skip to content
Financial Context Wiki

Is a governance delegation signature safe?

Learn what a governance delegation signature authorizes, how EIP-712 domain separation, nonces, and expiry reduce replay risk, and what to verify before signing.

Updated

For educational purposes only; not investment advice. Digital-asset transactions and signatures can cause irreversible loss.

Direct answer

A governance delegation signature is safe only when the decoded message matches the exact delegation you intend and the governing contract enforces adequate replay protection. In a typical voting-token design, delegation changes who may exercise the signer’s voting power; it does not transfer the token balance or grant token-spending approval. The deployed contract, however, is the final authority on what the signature does.

An off-chain signature can be submitted by a relayer, so the signer may pay no gas while still authorizing an on-chain state change. Treat the signature as an executable instruction, not as a login or a harmless request to connect a wallet.

How it works

A common delegateBySig flow has four steps:

  1. The application prepares EIP-712 typed data containing a delegate address, a nonce, and an expiry.
  2. The wallet signs a digest bound to the typed message and an EIP-712 domain.
  3. Any account may relay the signature to the token or governance contract.
  4. The contract recovers or validates the signer, checks the nonce and expiry, and records the new delegate.

The EIP-712 domain can include name, version, chainId, and verifyingContract. These fields separate otherwise identical messages between applications, versions, networks, and contracts. EIP-712 itself explicitly does not provide replay protection; the contract must consume a nonce or otherwise make each authorization single-use, and an expiry only limits the time window when the contract actually checks it.

Before signing, verify all of the following against an official governance interface, documentation, or independently verified contract data:

  • primaryType and field names describe delegation, not a permit, token transfer, order, or account-management authorization.
  • verifyingContract is the intended token or governance contract on the active chainId.
  • delegatee is the representative address you selected, checked by full address rather than a display name.
  • nonce matches the contract’s current nonce for the signer, and expiry is short enough for the intended workflow.
  • The wallet displays the complete typed data. Reject blind-signing prompts or raw hashes whose meaning you cannot independently reproduce.

Implementations differ. Compound’s COMP contract, for example, hashes the delegate, nonce, and expiry, requires the nonce to equal the signer’s stored nonce, increments that nonce, and rejects an expired signature. OpenZeppelin’s Votes interface also exposes delegateBySig, nonce handling, and expiry checks. Do not assume a similarly named function in another contract has identical protections.

Example

Mira intends to delegate 10,000 votes to address 0xAB...1234. Her wallet shows primaryType: Delegation, the verified voting-token contract, the active chain ID, delegatee: 0xAB...1234, the current nonce, and an expiry 20 minutes away. After checking the address through a second trusted source, she signs; a relayer submits the message, and the contract emits the delegation event. Her token balance remains in her wallet, while the representative receives the associated voting power under that protocol’s rules.

Now change one detail: the page asks for primaryType: Permit and names a token spender, or the verifyingContract is an unrelated contract. That is not the same delegation instruction. It may authorize token spending instead, even if the page labels the button “Delegate” and the signer pays no gas. Mira should reject it.

Risks and controls

  • Wrong delegate: address poisoning, private messages, and copied display names can substitute an attacker-controlled delegatee. Verify the full address through an official proposal or delegate profile.
  • Wrong action: a malicious interface can request another EIP-712 type such as a permit. Read primaryType, every field, and the verifying contract; the button label has no security value.
  • Replay: weak or missing nonce checks can let a signature be reused. A domain without the intended chain or contract binding can also permit use in an unintended context. Confirm the actual verification code, because EIP-712 alone is not replay protection.
  • Long-lived signature: an unused signed message can remain executable until its expiry or nonce becomes invalid. Prefer a short expiry, do not publish the signature, and use only the protocol’s documented invalidation method if cancellation is needed.
  • Misleading wallet display: truncated fields, an unknown domain, or blind signing prevents meaningful consent. Cancel and inspect the typed-data request with a wallet or decoder that shows the complete message.
  • Contract-account differences: smart contract wallets may validate signatures through ERC-1271, where validity can depend on wallet state and authorization policy. Confirm both wallet and governance-contract support instead of assuming EOA-style recovery.
  • Governance consequences: delegation can concentrate voting power or enable an untrusted delegate to vote contrary to your interests. Review the delegate’s identity, voting history, conflicts, and the protocol’s process for redelegation.

After submission, verify the transaction on the correct chain: check the destination contract, decoded function, signer recovered or reported by the event, new delegate, and nonce. A successful relayer transaction proves only that the contract accepted the call; it does not prove the signed intent was safe.

If you signed but have not seen a submission, stop sharing the signature and consult the protocol’s documented cancellation or nonce-invalidation path. If an unwanted delegation was executed, redelegate through the official contract and verify the new state. Delegation alone normally does not create a token allowance, so do not confuse redelegation with revoking approvals. If you also signed a permit or exposed a seed phrase or private key, treat that as a separate, higher-severity wallet incident.

Common misconceptions

  • “No gas means no authority.” The relayer can pay gas while the signature supplies the signer’s authorization.
  • “EIP-712 makes every signature safe.” It standardizes typed-data hashing and domain separation, but the standard does not include replay protection and cannot verify that a user intended the displayed action.
  • “Delegation transfers my tokens.” Conventional voting delegation moves or assigns voting power, not token ownership, but only the deployed contract and decoded message can establish the actual effect.
  • “I can always revoke an off-chain signature.” There is no universal signature-revocation transaction. Expiry, nonce consumption or invalidation, and redelegation are contract-specific mechanisms.
  • “Changing delegates erases earlier votes.” Redelegation changes future or current voting power according to protocol rules; it may not undo votes already cast or change historical snapshots.

Sources

Navigation

Search the wiki...