ERC-8118 primary sources — 2026-05-08

Project status in this pass

  • No standalone ERC-8118 whitepaper or litepaper surfaced.
  • The clearest source of truth was the Ethereum Magicians draft thread plus the ERC pull-request patch.
  • The materials consistently frame ERC-8118 as a bounded delegation interface for autonomous agents, not as a full smart-account system.

Primary-source snapshots

1) Ethereum Magicians draft thread

  • URL: https://ethereum-magicians.org/t/erc-8118-agent-authorization/27402
  • Key excerpt/signals:
    • The thread says ERC-8118 defines a standard interface for authorizing autonomous agents to perform specific on-chain actions on behalf of principals.
    • It highlights time-bound authorizations, usage-limited authorizations, function-level granularity, cryptographic consent, and a single-principal constraint.
    • It presents use cases including automated trading agents, DeFi position management, DAO proposal execution, subscriptions, and cross-chain relayers.
  • Why it mattered:
    • This is the clearest high-level evidence that ERC-8118 belongs in the corpus as delegated agent-authority infrastructure rather than as identity, reputation, or payments plumbing.

2) Draft ERC patch / abstract and motivation

  • URL: https://patch-diff.githubusercontent.com/raw/ethereum/ERCs/pull/1450.patch
  • Key excerpt/signals:
    • The abstract defines the standard around time-bound, usage-limited, selector-scoped authorizations plus agent consent and a single-principal rule.
    • The motivation says existing delegation mechanisms are either too broad, like unlimited approvals, or too narrow, like single-use signatures.
    • The draft frames the goal as a balanced, reusable interface for autonomous agent scenarios.
  • Why it mattered:
    • These details show ERC-8118 is trying to occupy the middle ground between ad hoc approvals and full wallet migration.

3) Draft ERC patch / interface surface

  • URL: https://patch-diff.githubusercontent.com/raw/ethereum/ERCs/pull/1450.patch
  • Key excerpt/signals:
    • The spec requires authorizeAgent, batchAuthorizeAgent, revokeAgent, batchRevokeAgent, isAuthorizedAgent, and getAgentAuthorization.
    • Authorization tuples are scoped by principal, agent, selector, timestamps, and allowed call count.
    • The updatable variant lets implementations support in-place authorization updates.
  • Why it mattered:
    • This confirms the standard is really a capability map for delegated execution, not just a loose signing convention.

4) Draft ERC patch / rationale and comparison class

  • URL: https://patch-diff.githubusercontent.com/raw/ethereum/ERCs/pull/1450.patch
  • Key excerpt/signals:
    • The rationale says agent consent prevents malicious principals from binding agents without their knowledge.
    • It defends the single-principal constraint as a way to avoid conflicting instructions and simplify the security model.
    • It explicitly compares ERC-8118 with ERC-4337 and EIP-7702, arguing that ERC-8118 preserves EOA custody while adding persistent, function-level delegation.
  • Why it mattered:
    • This gives the best analytic lens for where ERC-8118 fits in the wallet-and-agent standards map.

5) Draft ERC patch / security and validation claims

  • URL: https://patch-diff.githubusercontent.com/raw/ethereum/ERCs/pull/1450.patch
  • Key excerpt/signals:
    • The security section foregrounds custody preservation, bounded authority, cryptographic attribution, and effective revocation.
    • The draft also claims production validation with more than one million wallets and millions of transactions.
  • Why it mattered:
    • The security framing clarifies the intended guarantees, while the validation claims are useful context even though they remain author assertions in a draft-stage document.

Working conclusion

ERC-8118 is best cataloged as a function-scoped, quota-aware delegation primitive for autonomous agents. The decisive evidence in this pass was the selector-level authorization model, the agent-consent requirement, the single-principal constraint, and the explicit positioning between one-shot signatures and full smart-account migration.