01Standards

We wrote the standards, not just the code.

2 final Ethereum standards on eips.ethereum.org, one in Idea, each underpinning services in the catalogue

02Proposals

What they specify.

ERC-8126Final2026-01-15

AI Agent Verification

This ERC defines a standard interface for verifying AI agents on Ethereum that have been registered via ERC-8004. It enables AI agents to undergo several specialized verification processes defined in this proposal: Ethereum Token Verification (ETV), Media Content Verification (MCV), Solidity Code Verification (SCV), Web Application Verification (WAV), and Wallet Verification (WV). Verification providers implement this standard using Private Data Verification (PDV) to generate Zero-Knowledge Proofs (ZKPs). Detailed verification results are accessible only to the AI agent's wallet holder and include a unified risk score (0-100) to help users assess the agent's trustworthiness.

Co-authors
Leigh Cronian · Chris Johnson
Named in this ERC
Read on eips.ethereum.org ↗
ERC-8196Final2026-03-14

AI Agent Authenticated Wallet

This ERC defines a standard interface for AI agent-authenticated wallets. These wallets execute transactions only when accompanied by verifiable cryptographic proof that the action complies with a specific policy defined by the asset owner.

Co-authors
Leigh Cronian · Chris Johnson
Named in this ERC
Read on eips.ethereum.org ↗
ERC-8376Idea2026-08-07

Token Launch Abuse Detection and Remediation

Defines a standard for detecting abuse by token deployers and refunding their buyers while the money is still reachable. It specifies three parts. Detection: a taxonomy of eleven deployer abuse patterns, each with a reference profile, scored from a versioned twelve-signal base vector, extensible per pattern, into an abuseScore of 0 to 100 and published as a bonded report committing to chain-verifiable evidence. Every signal describes an action the deployer took; price decline is excluded by rule. Escrow: the venue holds sale proceeds and releases them on a schedule, so they remain reachable while abuse typically occurs. Remediation: a bonded claim and adjudication process that, on an upheld claim, refunds buyers pro rata by pull and draws any shortfall from a bond posted before launch. The specification is addressed to the venue: the launchpad, bonding curve or sale contract that lists the token, stands between the deployer and the buyer, and holds the proceeds at full conformance. It provides a way to consult detection before listing, to disclose what was found, and to return money that has not yet left. It protects buyers only at venues that adopt it, and a deployer who launches outside such a venue is outside its reach.

Co-authors
Leigh Cronian · Chris Johnson
Named in this ERC
Coming soon Token Launch Abuse Detection: the service this ERC specifies is in development, and is not in the catalogue yet
Open pull request: ethereum/ERCs #1942 ↗
03Status

Final and Idea are not the same claim.

Idea→Draft→Review→Last Call→Final

Idea — “An idea that is pre-draft. This is not tracked within the EIP Repository.” ERC-8376 is at this stage.

Draft — “The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.” Nothing of ours is at this stage.

Review — “An EIP Author marks an EIP as ready for and requesting Peer Review.” Nothing of ours is at this stage.

Last Call — “This is the final review window for an EIP before it is moved to Final. An EIP enters Last Call when the specification is stable and the author opens a PR with a review end date, typically 14 days later.” Nothing of ours is at this stage.

Final — “This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.” ERC-8126 and ERC-8196 are at this stage.

ERC-8376 is an open pull request against ethereum/ERCs, so it has no page on eips.ethereum.org and its link above goes to the pull request rather than to a URL that does not exist.

Definitions quoted from EIP-1, which specifies the process. Co-authoring a standard is not a claim that the ecosystem has adopted it. It is a claim that the interface was specified in public, reviewed in public, and can be read by anyone deciding whether to trust an implementation of it.