ERC-8118: Agent Authorization

ERCs
1

Abstract

ERC-8118 defines a standard interface for authorizing autonomous agents (bots, AI systems, or automated accounts) to perform specific on-chain actions on behalf of users (principals).

Pull Request:

Key Features

  • Time-bound authorizations: Optional start and end timestamps
  • Usage-limited authorizations: Maximum call count with automatic revocation
  • Function-level granularity: Permissions scoped to specific function selectors
  • Cryptographic consent: Agents must sign consent via EIP-712
  • Single-principal constraint: Each agent serves only one principal at a time

Motivation

As autonomous AI agents become more prevalent in blockchain ecosystems, a standardized interface for delegation is needed. Existing mechanisms are either too broad (unlimited token approvals) or too narrow (single-use signatures). This standard provides a balanced approach for autonomous agent scenarios.

Use Cases

  • Automated trading agents
  • Gaming NPCs
  • DeFi position management
  • DAO proposal execution
  • Subscription services
  • Cross-chain relayers

Production Validation

This standard has been validated through production deployment:

  • 1M+ unique wallets
  • 5.7M+ transactions without custody violations
  • Peer-reviewed at 7th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS 2025), Zurich, Switzerland

We welcome feedback and discussion on the specification.

Authors: WORLD3 Team (@world3-ai)

1 Like
2

interesting to see such features, thinking about error handling and if there is any restrictions to amount of retries.

3

Thanks for raising this ,and we think it’s a good point to clarify.

Error handling

The specification defines explicit custom errors for all failure conditions:

  • InvalidAgentAddress, InvalidSelector, ZeroCallsNotAllowed, ValueExceedsBounds (input validation)
  • SignatureExpired, InvalidSignature (signature verification)
  • AgentAlreadyBound, NoAuthorizationExists, NotAuthorized (state validation)

Per EVM semantics, if a protected call reverts, the entire transaction reverts and any state changes (including a remainingCalls decrement) are rolled back. The remainingCalls counter is only consumed on successful execution.

Retry restrictions

The allowedCalls parameter sets the initial value of remainingCalls. Per the specification:

  • Each successful call through a protected function MUST decrement remainingCalls by one
  • When remainingCalls reaches 0, the authorization MUST be automatically revoked
  • Failed calls (reverts) do not consume this allowance

An agent can therefore retry until:

  1. A call succeeds (consuming one unit)
  2. The validity window ends (endTime)
  3. The principal explicitly revokes the authorization

This is an intentional design choice: principals limit successful completions, not attempted executions.

Thank you again, and we welcome any further feedback.

1 Like
4

thank you for taking your time to clarify. @0xvimer

1 Like