Cowrie Research

erc-5639

3 min read

ERC-5639

  • Name: ERC-5639 (Delegation Registry)
  • URL: https://eips.ethereum.org/EIPS/eip-5639
  • Category: wallet delegation registry standard / cold-to-hot authentication infrastructure / read-only authority publication layer
  • Summary: ERC-5639 is a shared delegation registry. A vault wallet can publish hot-wallet delegates that prove control or asset ownership without getting transfer authority. Useful because apps can read one common authority table; the leverage still sits in which apps trust it and what later execution layers let delegates do.
  • What it does:
    • Standardizes a Delegation Registry interface for linking delegate wallets to a vault wallet
    • Supports whole-wallet, contract-level, and token-level delegation scopes
    • Defines write methods for creating and revoking delegations and read methods for checking and enumerating active delegations
    • Lets dapps and contracts verify whether a delegate can authenticate for a vault, a contract, or a specific token without taking custody
    • Explicitly includes onchain enumeration so frontends and integrators can discover delegations without reconstructing everything from events alone
    • Serves as the standards-track expression of the delegation-registry pattern popularized by Delegate.xyz
  • Key claims:
    • The abstract says ERC-5639 provides a protocol and ABI definition for linking delegate wallets to a vault wallet so delegates can prove control and asset ownership of the vault wallet, which is the clearest reason to catalog it as authority-publication infrastructure
    • The motivation argues that ordinary wallet-authentication flows are insecure and inconvenient because users must sign from the wallet that actually holds assets, often exposing a cold wallet or multisig to unnecessary interaction risk
    • The proposal explicitly says a vault wallet should be able to grant wallet-, contract-, or token-level permissions to a delegate wallet, showing that the standard is about scoped authority routing rather than blanket wallet proxying
    • The interface requires methods like delegateForAll, delegateForContract, delegateForToken, checkDelegateForAll, checkDelegateForContract, and checkDelegateForToken, which makes the registry a common verification surface that many dapps can read from
    • The rationale says the standard intentionally includes onchain enumeration despite the added gas cost because discoverability and UI integration matter for adoption, which is a meaningful design choice: it favors shared legibility over minimal write cost
    • The security framing is notable because the standard does not transfer custody or signing keys; it publishes restricted authentication relationships so risky dapp interactions can migrate to lower-value hot wallets while the vault stays colder
    • Delegate.xyz’s current technical docs show that the live registry implementation has already evolved beyond the ERC draft by adding rights-scoped subdelegations, ERC20 and ERC1155 support, multicall, and richer incoming/outgoing enumeration, which is analytically useful because it reveals where real implementation pressure is pushing the delegation-registry model beyond the narrower draft
    • That implementation drift also matters for corpus reasoning: ERC-5639 is the clean standards baseline, while Delegate.xyz as a live project increasingly looks like a broader authority-routing substrate with finer-grained rights semantics
  • Whitepaper: No standalone ERC-5639 whitepaper or litepaper surfaced in this pass. The strongest current materials were the canonical EIP page, the raw ERC markdown, and Delegate.xyz’s technical registry documentation; see ../../whitepapers/erc-5639-primary-sources-2026-05-07.md.
  • Sources:

Internal linkages

  • Live implementation and ecosystem Schelling point: delegate-xyz

  • Execution-oriented delegation cousin: eip-7710

  • Common production substrate: safe

  • Last reviewed: 2026-06-04 UTC

Graph View

Backlinks