Agent ERCs

August 5, 2026 · View on GitHub

Agent ERCs

Solidity interfaces and base implementations for the trustless AI agents.

This repo is a part of the trustless-ai open-source ecosystem: A powerful, decentralized AI infrastructure that anyone can provide, anyone can use, and everyone can verify by recomputing the proof — owned by no one.

Let's build trustless AI — for everyone!

ERCs Included

Import path pattern:

import {InterfaceName} from "@agent-ercs/contracts/<category>/<ERCXXXX>/FileName.sol";

ERC	Name	Category	What it defines
ERC-8004	Trustless Agents	`identity/`	Identity registration, reputation feedback, and validation requests for human and machine actors
ERC-8263	Onchain Proof Layer for AI Agents	`anchor/`	Write-side action anchoring via a single canonical `AnchorProof` event — immutable timeline of agent activity
ERC-8274	AI Inference Proof Verification	`verify/`	Three-layer decoupling: cryptographic proof verification, agent authorization, and verifier declaration
ERC-8275	Agent Service Discovery and Escrow Payments	`reputation/`	Event-derived agent reputation from escrow settlement events and verified attestation history
ERC-8281	Observation Commitment Protocol (OCP)	`verify/`	On-chain commitment anchor — observation extraction and re-check digests, the log is the ledger
ERC-8299	WYRIWE — Input Provenance for AI Inference	`verify/`	Triple-hash input provenance: binds raw user input to what the model actually received
ERC-8301	AI Agent Execution	`execution/`	Universal task dispatch, FSM orchestration, and verifiable step-execution evidence chain
ERC-8312	Bounded Agent Actions	`metering/`	Envelope registration and aggregate consumption metering against an accepted bound — the cursor holds the sum
ERC-8323	Source-Token Agent Binding	`identity/`	Links external NFT ownership to ERC-8004 agent identity via on-chain provenance
ERC-8354	Confidential Agent Policy Verdicts (CAPV)	`verify/`	Confidential pre-execution allow/deny verdict — proves an agent action clears a policy that is never revealed on-chain

Base implementation: ConsultEscrow (settlement/ConsultEscrow/ConsultEscrow.sol) — trustless pay-on-delivery for agent consultations. No standalone ERC number (see its README for the spec anchor).

Directory Structure

contracts/
├── <category>/              # Functional domain (e.g., identity, execution, verify)
│   └── <ERCXXXX>/           # One directory per ERC
│       ├── I*.sol           # Interface(s) defined by the spec
│       ├── <Name>.sol       # Base implementation (when ready)
│       └── README.md        # Spec links, discussion, interface inventory
├── interfaces/              # Cross-domain shared interfaces (e.g., IERC165)
├── utils/                   # Shared utility contracts
└── mocks/                   # Mock contracts for testing

test/
└── <category>/              # Tests mirror contracts/ exactly
    └── <ERCXXXX>/

No top-level src/, no flat file dump — every ERC lives in its own directory under a functional category. Pick the category that best describes the link your ERC defends (e.g., identity/ for agent registration, execution/ for task dispatch and orchestration, verify/ for cryptographic proof verification, provenance/ for input/output commitment, eligibility/ for access control and permissions…) and create contracts/<category>/<ERCXXXX>/. If nothing fits, propose a new category in your PR — categories emerge from the stack.

Code Classification

Every .sol file in this repository falls into exactly one of these categories:

Type	Definition	Production-ready	Where
Interface	Method signatures, structs, enums defined by the ERC specification	✅ Must implement	`agent-ercs`
Base Implementation	Inheritable, audited production contract that implements the interface	✅ Can inherit for production	`agent-ercs`
Example / Reference	Demonstrates how to use the interface; not audited	❌ Do not use in production	Other repositories

Base implementations are not examples. A base implementation is audited (or on a clear path to audit), follows security best practices, and is safe to inherit in production contracts. Examples and reference implementations belong in separate repositories (project repos, agent-sdk, etc.) — they show developers how to use the interface but haven't been hardened for production.

The Rule

Nothing goes in that a third party can't independently verify from public data.

Every contract in this repository must be recomputable — anyone with access to the chain and the spec should be able to reproduce and verify every outcome, without trusting any individual contributor or organization.

Setup

# Install dependencies
forge install OpenZeppelin/openzeppelin-contracts

# Build
forge build

# Test
forge test

Contributing

There are many ways to get involved — no commitment needed to start.

💬 Join the conversation

Hop into the Telegram group to brainstorm, ask questions, or just see what people are working on. This is the best first step if you're not sure where to start.

🐛 Report a bug or improve something

Found an issue in an interface, a spec inconsistency, or a gap in the docs? Open an issue or send a PR. Bug reports, test contributions, and documentation improvements all count.

📐 Submit your ERC

Have an ERC that fits the trustless AI stack? Here's how to get it into agent-ercs:

Pick a category — which functional domain does your ERC defend? Create contracts/<category>/<ERCXXXX>/.
Add the interface — extract the Solidity interface from your ERC spec into I*.sol files. Follow the pragma solidity ^0.8.0 convention.
Write a README — include the spec link, magician discussion link, interface inventory, and how it relates to other ERCs in the stack. See existing ERC directories for the format.
Add tests — tests go in test/<category>/<ERCXXXX>/, mirroring the contracts structure.
Open a PR — we review fast. If your ERC is still a Draft, that's fine — interfaces evolve with the spec.

If your ERC also has a base implementation that is audited (or on a clear audit path), include it in the same directory. If it's a reference implementation or example, put it in a separate repository.

You keep full control of your ERC. This repository is a shared home, not a gate.

License

Apache 2.0 — see LICENSE.