Publish a tool, gate it by anything onchain,
get paid.
ERC-XXXX is an onchain registry where anyone can publish an AI agent tool, attach an access predicate (NFT, subscription, allowlist, ZK proof, anything callable), and accept payment via x402 or any other protocol. No auth servers. No gatekeepers. Agents discover and verify in two RPC calls.
The 403 to x402’s 402.
An access-denied layer that complements pay-per-call protocols like x402.
Trust and payment
got separated.
Tool calling for agents has three layers: discovery, access, and payment. MCP solves discovery and invocation but has no native trust or payment layer. x402 solves payment but says nothing about who is allowed to call. Ad-hoc API keys solve neither discoverably and tie identity to a single operator. ERC-XXXX is the missing piece: a permissionless directory with onchain identity and pluggable access control. Use it next to MCP and x402, not in place of them.
From publisher to agent,
verifiably.
Publishers commit a manifest hash onchain and serve the manifest at a well-known path. The registry enforces origin binding. Agents discover, verify, and, if the predicate allows, invoke.
ToolConfig: creator, metadataURI, manifestHash, accessPredicate.One tool,
end to end.
An NFT appraisal tool gated by holding a Chonk on Base. Three moves: register, gate, invoke.
Three tiers.
One manifest field.
Tools declare a verifiability tier in their manifest. Each tier is a different trust model, from operator self-attestation up to fully reproducible end-to-end verifiable execution.
Why three? Progressive verifiability. Most operators ship at self-attested on day one and can graduate to TEE or reproducible builds without changing the registry, the manifest schema, or their consumers’ verification code.
Operator's word.
The operator declares data retention and source visibility policies, committed onchain by manifest hash. Cannot be silently changed, but enforcement is reputational.
- dataRetention
- sourceVisibility
- hash-committed
TEE attestation.
The tool runs in a hardware enclave (SGX, Nitro, SEV-SNP). Agents fetch a fresh attestation report and verify the cryptographic chain of trust. Transparency logs prevent split-view attacks.
- TEE attestation
- maxAge freshness
- transparency logs
No trust required.
Source code is published with reproducible build instructions. Anyone can rebuild the enclave binary, compare the measurement against the attestation report, and verify end to end.
- reproducible build
- source -> binary -> enclave
- full chain verification
Anyone can write a predicate.
The predicate is just an address. This is the same pattern as Seaport zones and Uniswap v4 hooks: a pluggable contract the protocol staticcalls into without caring about the implementation. The registry never changes; the policy space is open-ended.
IAccessPredicate. Point any tool’s accessPredicate at its address. Done. No allowlist, no governance, no version bump.hasAccess— yes / nogetRequirements— what would unlock itname— diagnostic identity
It’s pre-draft. Best time to push back.
The spec is unfinished on purpose. The questions where outside input changes the outcome the most right now:
- 01Predicate ideas we haven’t drafted yet (reputation, attestation, oracle).
- 02Manifest schema gaps: fields you’d need that aren’t there.
- 03Failure modes we should spec around (predicate rugs, manifest drift, indexer lag).