.agt Manifest Specification

Version: 3.0 · Status: In use on the AGT Registry (Polygon mainnet) · Updated: 2026-09-12 · View as Markdown

Abstract

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 wallet that owns the name signs it, and the registry holds the on-chain pointer to it. Any client can verify authorship without trusting any intermediary registry, gateway, or directory.

v3 changes where authority comes from. The trust root is the AGT Registry — verification checks that the signer, the manifest's declared owner, and the registry's current owner all agree. The pointer to the manifest lives on-chain; the DNS TXT record is a projection of it. Two earlier formats — v1 (inline DNS TXT) and v2 (signed JSON on IPFS, "agt": "2.0") — remain readable for names that predate the registry (§11).

1. Where the manifest lives

On the AGT Registry the manifest pointer is stored on-chain against the name. The pointer URI is one of:

• ipfs://<cid> — content-addressed; resolvers verify the fetched bytes hash to the CID.
• https://… — a hosted document.
• data:application/json;base64,… — the manifest inlined.

The DNS TXT agt-manifest=<uri> record is a downstream projection of the on-chain pointer, for DNS-based readers. Resolvers read the pointer from the registry first.

2. 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.",
      "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": "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..."
}

3. Fields

4. Canonical Serialization & Signing

1. Build the manifest object without the signature field.
2. Serialize with keys sorted lexicographically at every level, no insignificant whitespace, UTF-8 (JCS-lite; RFC 8785 for full conformance).
3. Sign per EIP-191 (personal_sign) with the wallet that owns the name. The key never leaves the wallet.
4. Place the resulting hex signature (65 bytes, r‖s‖v, 0xprefixed) in the signature field.

5. Verification

1. Remove signature; canonicalize the remainder.
2. Recover the signer from the signature and the canonical bytes.
3. The signer MUST equal the manifest's owner.
4. The owner MUST equal the current owner of the name in the AGT Registry.
5. When the pointer is ipfs://, the fetched bytes MUST hash to the CID.

On any failure a resolver surfaces verified: false with reasons; clients MUST NOT trust an unverified manifest.

6. Resolution Algorithm

function resolve(name):
  tokenId = tokenIdOf(name)
  owner, active, pointer = AGTRegistry.read(tokenId)   // ownerOf, status, manifest pointer

  if pointer:
    bytes = fetch(pointer)                             // ipfs:// | https:// | data:
    if pointer is ipfs and cidOf(bytes) != cid: REJECT
    m = parse(bytes)
    verified = recover(m.signature) == m.owner == owner
    return { name, owner, active, manifest: m, verified }

  // legacy fallback for names that predate the registry
  txt = dnsTxt(name)
  if txt.has("agt-manifest="): return readV2Json(txt)
  if txt.has("agt-version=1"): return readV1Inline(txt)   // unverified
  return { name, owner, active, manifest: null }

7. Protocol Vocabulary

Custom protocol IDs are permitted. Lowercase, hyphenated.

8. Payment Rails

Custom rails are permitted.

9. Capability Vocabulary (Reference)

70 reference capabilities across 8 categories. Custom IDs permitted — this list is non-exhaustive.

10. Security Considerations

• Public gateways are untrusted. Resolvers MUST verify the IPFS CID matches the fetched content.
• On-chain ownership is the ground truth. A signature proves authorship at signing time; always resolve the current pointer and owner from the registry. A signature from a previous owner is invalid after transfer.
• Key rotation. Set keys[].revoked and publish a new signed manifest.
• Manifests are public and permanent. Never include secrets, API keys, or private data.
• Untrusted input. Treat all manifest text as untrusted in agent prompts (prompt-injection surface).
• Endpoint TLS. Endpoints SHOULD use HTTPS; clients SHOULD warn before connecting to plain HTTP.

11. Legacy manifests

Names that predate the AGT Registry may carry one of two older formats, both read-only:

• v1 (inline TXT). One DNS TXT record per field, with an agt-version=1 sentinel and no signature. Resolvers parse these into a manifest-shaped object marked unverified.
• v2 (JSON on IPFS). A signed JSON document with "agt": "2.0", pointed to by a DNS agt-manifest= TXT record.

Writers MUST NOT generate new v1 or v2 manifests; new names write v3.

12. References

• RFC 8785 — JSON Canonicalization Scheme (JCS)
• RFC 8259 — JSON Data Interchange Format
• 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