Your AI Agent Needs an Address, Not a Username. This ERC Proposes Exactly That.
A draft ERC proposes Agent Identity (AID), an address-anchored standard for AI agents built on ERC-8004 assertion registries, replacing platform trust with cryptographic verification.

I was watching a developer demo last month where an AI agent signed a transaction on Ethereum. The agent had no wallet. No key. No identity. Just a server somewhere making decisions about other people's money. When I asked how the protocol knew which agent was which, the answer was a JSON file on IPFS. That is not identity. That is a placeholder with better marketing.
On September 30, 2026, a new draft ERC appeared on the Ethereum Magicians forum that tries to solve this properly. It is called Agent Identity, or AID. It proposes an address-anchored identity standard for live agents, built on top of ERC-8004 and assertion registries. The proposal does not just give agents names. It gives them verifiable claims, cryptographic bindings, and a framework for proving what an agent actually is.
Key Metrics at a Glance
| Metric | Value |
|---|---|
| Standard Proposed | ERC Agent Identity (AID) |
| Base Standard | ERC-8004 (Assertion Registries) |
| Identity Model | Address-anchored, not username-based |
| Target Users | Live AI agents, autonomous systems |
| Proposal Date | September 30, 2026 |
| Forum | ethereum-magicians.org |
| Status | Draft / Discussion |
| Reference Implementation | Available on GitHub |
What the Proposal Actually Does
The draft ERC, authored by garyyang-finchip, starts from a simple observation: AI agents are already interacting with Ethereum, but they have no standardized way to prove their identity, capabilities, or trustworthiness. Current solutions rely on off-chain databases, centralized registries, or social trust. AID moves the anchor on-chain.
The standard defines a system where:
- Each agent gets an Ethereum address as its root identity
- Assertions about the agent — what it can do, who authorized it, what models it runs — are registered on-chain via ERC-8004
- The agent's identity is not a username or a profile. It is a cryptographic address with a bundle of verifiable claims
- Other contracts can query these assertions and make decisions based on them
This is a significant shift. Most agent identity systems today are centralized. You trust the platform that issued the agent's credentials. AID replaces platform trust with cryptographic verification. The agent either has the assertions or it does not. The registry either records them or it does not.
The Technical Translation
ERC-8004, the base standard, defines assertion registries — on-chain systems for making claims about entities and verifying those claims. AID builds a specific profile for agents on top of that foundation.
An agent's identity under AID consists of:
- A root address — the Ethereum address that anchors the agent's identity
- Assertion bindings — cryptographic links between the address and claims about the agent's behavior, capabilities, or constraints
- A resolver — a mechanism for other contracts to query and validate the agent's assertions
- Vectors and schemas — standardized formats so different agents can be compared and evaluated uniformly
The reference implementation includes Solidity contracts, JSON schemas, and test vectors. This is not a theoretical proposal. It is code that compiles.

The Competitive Landscape
| Identity System | Model | On-Chain Verification | Agent-Specific | Decentralized |
|---|---|---|---|---|
| AID (Proposed) | Address-anchored + assertions | Yes | Yes | Yes |
| ENS | Name-to-address resolution | Partial | No | Yes |
| World ID | Biometric proof-of-personhood | No | No | Partial |
| Ceramic/ComposeDB | Off-chain graph | No | Partial | Partial |
| Custom Agent Registries | Centralized databases | No | Yes | No |
| Traditional PKI | Certificate chains | No | No | No |
The table reveals a gap that AID is trying to fill. ENS resolves names to addresses but does not describe what the entity at that address can do. World ID proves personhood but does not apply to agents. Ceramic handles data but not cryptographic verification. Custom registries are centralized and opaque.
AID is the first proposal that treats agent identity as a first-class Ethereum primitive.
Who Benefits and Who Is Exposed
The immediate beneficiaries are protocols that need to interact with agents autonomously. A DeFi protocol could query an agent's assertions before allowing it to execute a strategy. A DAO could verify an agent's authorization before letting it vote on its behalf. A bridge could check an agent's constraints before accepting its proofs.
The exposure is equally clear. If agent identity is reduced to a single address, the address becomes a high-value target. If the private key controlling the agent's identity is compromised, the attacker inherits all of the agent's assertions and trust relationships. The proposal acknowledges this risk but delegates key management to the implementer.
That is a gap. A robust agent identity standard should include guidance on key rotation, multisig control, and recovery mechanisms. AID has the architecture. It still needs the operational security layer.
The Accountability Layer
The most important question about AID is not technical. It is governance. Who decides which assertions matter? Who runs the registries? Who can revoke an agent's claims?
The draft proposes assertion registries but does not specify their governance. An assertion is only as trustworthy as the registry that issued it. If a registry is controlled by a single entity, AID becomes a centralized identity system with decentralized window dressing.
The proposal's author acknowledges this and suggests that registries could be governed by DAOs, reputation systems, or other decentralized mechanisms. But suggestion is not specification. The Ethereum ecosystem has learned — painfully — that governance assumptions must be explicit. AID needs a governance appendix before it is ready for mainnet.

Strategic Implications and Future Outlook
If AID is adopted, it could become the standard way for AI agents to identify themselves on Ethereum. That would have implications far beyond the obvious use cases:
- MEV bots could prove their strategies and constraints, making their behavior more predictable
- Autonomous treasuries could delegate spending authority to agents with verifiable limits
- Cross-chain bridges could verify agent identities before accepting their messages
- Regulatory compliance could be built into agent assertions, creating an auditable trail of agent behavior
The risk is premature standardization. The agent ecosystem is still evolving. A standard written today may not fit the agents of 2028. The proposal mitigates this by using ERC-8004's extensible assertion model, but the core schema will still need updates as the ecosystem matures.
One specific concern: the proposal relies on ERC-8004, which is itself still in development. Building a standard on a moving foundation is risky. The AID authors should clarify their dependency on ERC-8004's final form and provide a migration path if that standard changes.

TL;DR
- What: Draft ERC proposes AID (Agent Identity), an address-anchored identity standard for AI agents built on ERC-8004 assertion registries
- Why: Current agent identity solutions are centralized, off-chain, or non-existent; AID brings verifiable agent identity on-chain
- Impact: Protocols could query and verify agent capabilities before trusting them with transactions, votes, or bridge messages
- Watch: Whether governance mechanisms for assertion registries are specified; whether ERC-8004 stabilizes before AID is finalized; whether the ecosystem adopts address-anchored identity over platform-based credentials
Sources
- Ethereum Magicians — Draft ERC: Agent Identity (AID)
- GitHub — aid-standard/ERCS
- Ethereum Magicians — ERC-8004 Discussion
Zain Tran is TotesTek's Ethereum Ecosystem Columnist & Accountability Reporter. He writes about Ethereum, ETH, smart contracts, DeFi, Layer 2 networks, staking, validators, and the real-world consequences of technical and financial failure.



