ERC-5639 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-5639 whitepaper or litepaper surfaced.
• The clearest source of truth was the canonical EIP page and raw ERC markdown.
• Delegate.xyz’s technical registry docs were useful because they show how the live implementation is already extending beyond the narrower draft standard.

Primary-source snapshots

1) Canonical EIP page

• URL: https://eips.ethereum.org/EIPS/eip-5639
• Key excerpt/signals:
  • The page describes ERC-5639 as “Delegation of permissions for safer and more convenient signing operations.”
  • The abstract says the Delegation Registry links delegate wallets to a vault wallet so delegates can prove control and asset ownership.
  • The motivation frames current dapp-auth flows as insecure and inconvenient because users must interact from the asset-holding wallet itself.
• Why it mattered:
  • This is the clearest evidence that ERC-5639 belongs in the corpus as delegated-authentication and authority-publication infrastructure.

2) Raw ERC markdown / core interface

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5639.md
• Key excerpt/signals:
  • The standard defines delegation at three scopes: whole wallet, contract, and token.
  • It specifies write methods for setting and revoking delegations plus read methods for checking delegations.
  • It also defines onchain enumeration methods so clients can retrieve active delegations directly.
• Why it mattered:
  • This is the strongest signal that ERC-5639 is trying to make delegation legible as a shared registry primitive rather than as one app’s custom permissions database.

3) Raw ERC markdown / rationale for onchain enumeration

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-5639.md
• Key excerpt/signals:
  • The rationale says the spec accepts extra gas cost in exchange for onchain enumeration.
  • It argues that without enumeration, users or dapps would need to manually supply vault addresses or index delegate events elsewhere.
• Why it mattered:
  • This design choice shows the standard favors interoperability and discoverability, which is important for understanding where wallet-routing power may centralize.

4) Delegate.xyz technical registry docs

• URL: https://docs.delegate.xyz/technical-documentation/delegate-registry/idelegateregistry.sol
• Key excerpt/signals:
  • The current interface describes an immutable standalone registry storing delegated permissions from one address to another.
  • It adds richer delegation types and rights scoping, including ERC721, ERC20, and ERC1155-specific paths plus bytes32 rights subdelegation controls.
  • It also adds multicall and incoming/outgoing enumeration helpers.
• Why it mattered:
  • This is the clearest signal that the live implementation pressure around delegation registries is broader than the draft ERC itself, which helps separate the standard baseline from the evolving productized authority-routing substrate.

5) Public discussion thread

• URL: https://ethereum-magicians.org/t/eip-5639-delegation-registry/10949
• Key excerpt/signals:
  • The thread itself did not fetch cleanly in this pass, but the EIP metadata anchors the proposal in the public standards-discussion process.
• Why it mattered:
  • Even without body extraction, it confirms ERC-5639 is part of the open standards pathway rather than a closed vendor-specific API.

Working conclusion

ERC-5639 is best cataloged as a wallet-delegation registry standard: it standardizes how wallets publish scoped authentication rights to other wallets without moving custody, and it reveals how delegation can become a shared authority-discovery layer for dapps.