Manifest Specification

The .agt manifest is a signed JSON document describing an AI agent's identity, capabilities, and endpoints. It is content-addressed on IPFS and pointed to by a single DNS TXT record on the agent's .agt domain. Any client can verify authorship without trusting any intermediary registry, gateway, or directory.

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

TXT Record

A v1 agent has one .agt TXT record on its domain root:

agt-manifest=ipfs://<cid>

Where <cid> is a CIDv1 (sha2-256 minimum) for the manifest JSON. Domains MUST NOT have both agt-manifest and legacy agt-version=1 records — resolvers prefer the v1 pointer.

Manifest Document

{
  "agt": "1.0",
  "domain": "exampleagent.agt",
  "name": "Example Agent",
  "description": "Research and source citation agent.",
  "icon": "https://exampleagent.example.com/icon.png",
  "website": "https://exampleagent.example.com",
  "owner": "0x912D39E13b0bDAe2C5Cf5D0E2f9F4B38aE9c7f6a",
  "created_at": "2026-05-01T18:00:00Z",
  "protocols": [
    { "id": "mcp",  "version": "2025-11-05", "endpoint": "https://exampleagent.example.com/mcp" },
    { "id": "http", "endpoint": "https://exampleagent.example.com/api/v1", "auth": "bearer" }
  ],
  "capabilities": [
    {
      "id": "research",
      "input":  { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] },
      "output": { "type": "object", "properties": { "summary": { "type": "string" }, "sources": { "type": "array" } } }
    },
    { "id": "summarization" }
  ],
  "pricing": {
    "model": "freemium",
    "free_tier": "10 queries/day",
    "paid": { "currency": "USD", "amount": "0.01", "unit": "per_request" }
  },
  "signature": "0x7f3e8d4c..."
}

Required Fields

Signing & Verification

Manifests use RFC 8785 JCS for canonical serialization. Signing is EIP-191 personal_sign by the wallet that owns the NFT. Verification is three-way:

1. CID hash check: the bytes returned by the IPFS gateway MUST hash to the CID in the TXT record. (Defends against gateway tampering.)
2. Signature recovery:the signer recovered from the signature MUST equal the manifest's owner field.
3. On-chain owner check: the manifest's owner MUST equal the current FNS.ownerOf(tokenId) on Polygon (registry contract 0x465ea4967479A96D4490d575b5a6cC2B4A4BEE65).

If any check fails, the manifest MUST be rejected.

Resolution Algorithm

1. Fetch DNS TXT records for the domain.
2. If agt-manifest=ipfs://<cid> present → fetch JSON from IPFS, run all three verification checks, return v1 manifest.
3. Else if agt-version=1 present → parse legacy v0 records into a v1-shaped object with legacy: true (no signature verification possible).
4. Else → not an agent.

Protocol Vocabulary

Custom protocol IDs are permitted. Lowercase, hyphenated.

Capability Vocabulary

69 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. Old manifests signed by previous owners become invalid after transfer.
• Manifests are public and immutable. Never include secrets, API keys, or private data.
• Endpoints SHOULD use HTTPS. Clients SHOULD warn before connecting to plain HTTP.

Legacy v0 (TXT-only) Manifests

About 942 domains were registered before this specification with the pre-1.0 TXT-record format (one TXT record per field, no signature). Resolvers should parse those into a v1-shaped object with legacy: true and no verification. New registrations write v1. A migration tool for legacy holders to upgrade in place is tracked in #110. Format reference is in the canonical spec, §8.

References

• RFC 8785 — JSON Canonicalization Scheme (JCS)
• EIP-191 — Signed Data Standard
• EIP-55 — Mixed-case checksum address encoding
• JSON Schema Draft 2020-12
• IPFS CIDv1 — multibase, multihash, multicodec