Manifest Specification

The .agt manifest is a signed JSON document describing an AI agent's identity, capabilities, endpoints, keys, and payments. For names on the AGT Registry it is the v3 manifest: the owner signs it with their wallet, and the registry holds the on-chain pointer to it. Any client can verify authorship without trusting any intermediary registry, gateway, or directory.

For the canonical specification document, see /spec or spec/agt-manifest-v3-draft.md. This page is the developer-facing summary.

Where the pointer lives

On the AGT Registry, the manifest pointer is stored on-chain — the registry records the manifest URI for the name, and the DNS TXT agt-manifest= record is a downstream projection of it. Resolvers read the pointer from the registry, so there is no DNS round-trip in the trust path. The URI can be ipfs:// (content-addressed), https://, or an inline data: URI.

Manifest Document

{
  "agt": "3.0",
  "name": "exampleagent.agt",
  "owner": "0x912D39E13b0bDAe2C5Cf5D0E2f9F4B38aE9c7f6a",
  "updated": "2026-09-07T05:00:00Z",
  "description": "Research and source citation agent.",
  "icon": "https://exampleagent.example/icon.png",
  "website": "https://exampleagent.example",
  "keys": [
    { "id": "sig-1", "purpose": "agent-auth", "type": "secp256k1", "publicKey": "0x04...", "revoked": false }
  ],
  "endpoints": [
    { "protocol": "mcp",  "url": "https://exampleagent.example/mcp", "version": "2025-11-05" },
    { "protocol": "a2a",  "url": "https://exampleagent.example/.well-known/agent.json" },
    { "protocol": "http", "url": "https://exampleagent.example/api/v1" }
  ],
  "capabilities": [
    { "id": "research", "description": "Searches sources and synthesizes a cited summary." },
    { "id": "summarization" }
  ],
  "pricing": { "model": "freemium", "free_tier": "10 queries/day",
               "paid": { "currency": "USDC", "amount": "0.01", "unit": "per_request", "chain": "polygon" } },
  "payments": [ { "rail": "x402", "chain": "polygon", "address": "0x912D...7f6a", "token": "USDC" } ],
  "delegation": { "principal": "0xABC...", "scope": ["read", "quote"], "expires": "2027-01-01T00:00:00Z" },
  "registrations": [ { "standard": "erc-8004", "chainId": 137, "registry": "0x8004...", "agentId": "42" } ],
  "signature": "0x7f3e8d4c..."
}

Fields

Signing & Verification

Manifests are canonicalized with keys sorted lexicographically at every level and no insignificant whitespace (JCS-lite; RFC 8785 for full conformance). Signing is EIP-191 personal_sign by the wallet that owns the name — the private key never leaves the wallet.

Verification is three-way:

1. Signature recovery: the signer recovered from signature MUST equal the manifest's owner.
2. On-chain owner check: the manifest's owner MUST equal the current owner of the name in the AGT Registry.
3. CID check (when the URI is ipfs://): the fetched bytes MUST hash to the CID in the pointer. (Defends against gateway tampering.)

On any failure, resolvers surface verified: false with reasons rather than silently dropping the document — but clients MUST NOT trust an unverified manifest.

Resolution Algorithm

1. Derive the token ID from the label.
2. Read ownerOf, active/expiry, and the manifest pointer from the AGT Registry.
3. Fetch the manifest from its URI (ipfs:// via configurable gateways, https://, or data:), parse, and run the three verification checks.
4. If the registry has no pointer, fall back to DNS TXT for legacy names (agt-manifest= for a v2 JSON manifest, agt-version=1 for a v1 inline manifest).
5. Return { name, owner, active, manifest, verified, reasons }.

Protocol Vocabulary

Custom protocol IDs are permitted. Lowercase, hyphenated.

Payment Rails

Custom rails are permitted.

Capability Vocabulary

70 reference capabilities across 8 categories. Capability inputs and outputs use JSON Schema Draft 2020-12. Custom IDs permitted.

Security Considerations

• Public gateways are untrusted — resolvers must verify the CID matches the fetched content.
• On-chain ownership is the ground truth. A valid signature proves authorship at signing time; always resolve the current pointer and owner from the registry. Manifests signed by a previous owner become invalid after transfer.
• Manifests are public. Never include secrets, API keys, or private data.
• Key rotation and revocation are done by setting keys[].revoked and publishing a new signed manifest.
• Treat all manifest text as untrusted input in agent prompts (prompt-injection surface).
• Endpoints SHOULD use HTTPS. Clients SHOULD warn before connecting to plain HTTP.

Legacy manifests

Two earlier formats remain readable but are not written for new names: v1 (each field as a separate inline DNS TXT record, no signature) and v2 (a signed JSON document on IPFS with "agt": "2.0"). Resolvers fall back to DNS TXT to read these for names that predate the registry; new registrations and migrated names write v3.

References

• RFC 8785 — JSON Canonicalization Scheme (JCS)
• EIP-191 — Signed Data Standard
• EIP-55 — Mixed-case checksum address encoding
• ENSIP-9 — Multichain address resolution
• ERC-8004 — Agent identity registration
• JSON Schema Draft 2020-12
• IPFS CIDv1 — multibase, multihash, multicodec