Core Concepts
The three primitives that make up Agent Multiverse — Registry, Passport, and Bounties.
Agent Multiverse is built on three on-chain primitives. Each solves a distinct problem in the agentic web, and together they create a flywheel of trust.
The Registry
Problem: How does an AI agent find services it can trust? Today, service discovery is ad-hoc — hardcoded endpoints, word of mouth, or centralized directories that can be gamed.
Solution: The Agent Registry is an on-chain record of MCP services. Every registered service has:
| Field | Type | Purpose |
|---|---|---|
name | string | Human-readable service name |
description | string | What the service does |
endpoint | string | MCP server URL |
repoUrl | string | Source code repository for audit |
developer | address | On-chain identity of the registrant |
isVerified | bool | Whether the service has passed audits |
Services accumulate an audit trail — a history of independent auditor reports stored on-chain. Each audit records the auditor's address, a report URI, a reproducibility flag, and a timestamp.
Only the service owner can update its metadata. Anyone can read the registry.
The Passport
Problem: AI agents have no portable identity. An agent interacting with Service A has no way to prove to Service B that it is the same entity, or that it has been verified.
Solution: Agent Passport is an ERC-721 NFT that represents an agent's on-chain identity. Each passport contains:
| Field | Type | Purpose |
|---|---|---|
name | string | Agent name |
version | string | Agent version |
owner | address | Wallet that controls the passport |
isVerified | bool | Verified by the protocol owner |
Because passports are standard ERC-721 tokens, they are:
- Transferable — Ownership can move between wallets
- Enumerable — You can list all passports owned by an address
- URI-backed — Each token can point to off-chain metadata
Request Signing
The PassportSigner in the SDK lets agents sign requests with their private key. Every signed request includes:
- The agent's address
- A timestamp
- A cryptographic signature over the request payload
This allows services to verify that an incoming request is from a known, passport-holding agent.
The Bounties
Problem: Security audits are expensive and slow. Open-source services especially struggle to attract auditors because there is no direct economic incentive.
Solution: The Bounty contract creates a market for audits. The flow:
- Sponsor creates a bounty — Locks ERC-20 tokens (e.g., USDC) in escrow, tied to a specific service ID
- Auditors review the service — Submit audit reports via
submitAudit()on the Registry contract - Service gets verified — Once enough positive audits accumulate, the service is marked as verified
- Auditor claims the bounty — The
claimBounty()function releases escrowed tokens to the auditor
The contract handles ERC-20 approvals automatically via SafeERC20. Bounties can only be claimed once, and only after the associated service is verified.
The Trust Flywheel
These three primitives reinforce each other:
Register Service → Attract Bounties → Incentivize Audits
↑ │
└───── Verification builds trust ←──────┘- More registered services attract more bounty sponsors
- More bounties attract more auditors
- More audits produce more verified services
- Verified services attract more agents with passports
- Agents with passports create demand for more services
This cycle is self-reinforcing. The more participants, the more valuable the network becomes for everyone.