Agent platform overview
Use ENS as a portable namespace for agent identity and operation.
The agent platform combines ENS identity records with live endpoint evidence, deterministic routing, signed authorization, commerce, and fleet operations. Evidence types remain separate so health is not mistaken for trust or authority.
Before you run this workflow
Networks
- Ethereum mainnet identity
- Base and Ethereum commerce
Prerequisites
- None for public reads
- A wallet controlling an ENS name for signed configuration
Wallet permissions
- No permission for reads
- Explicit EIP-712 or transaction review for state changes
Expected result
- Separate identity, endpoint, evidence, route, policy, work, and fleet state
Errors and recovery
- Refresh stale evidence
- Revoke narrow policies
- Never infer authority or payment from identity alone
One workspace, separate evidence layers
Each layer consumes the previous layer without turning it into a stronger claim. A healthy endpoint is not automatically trusted; a trusted identity is not automatically authorized; an accepted job is not funded until onchain evidence proves it.
- 1
Identity
ENS name + live wallet binding
- 2
Endpoints
Published MCP, A2A, and web locations
- 3
Evidence
Timestamped health and registry observations
- 4
Routes
Explainable capability ranking
- 5
Policies
Signed scope, expiry, budget, and revocation
- 6
Jobs
Quotes, funding evidence, delivery, settlement
- 7
Fleet
Isolated workers and versioned control
How to use it
- 1
Publish identity
Give the agent an ENS name, context, and protocol endpoints.
- 2
Add registry evidence
When using ERC-8004, complete the mint, registration-file update, and ENSIP-25 binding phases.
- 3
Observe and route
Check current endpoint evidence before routing meaningful work.
- 4
Authorize narrowly
Use short-lived policies and verified commerce records instead of broad, permanent wallet access.