.agt Manifest Specification

Version: 1.0 · Status: Draft · Date: 2026-05-01 · View as Markdown

Abstract

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

This specification replaces the pre-1.0 TXT-record format that stored each field as a separate DNS TXT record. That format is documented as legacy v0 in §10 — read-only support for the ~942 domains registered before this specification.

1. TXT Record

A v1 agent has exactly one .agt-related TXT record on the root of its domain:

agt-manifest=ipfs://<cid>

Where <cid> is a CIDv1 (RFC compliant, multibase-encoded, multihash-encoded) for the manifest JSON document. SHA-256 minimum. A domain MUST NOT have both agt-manifest= and legacy agt-version=1 records simultaneously. Resolvers that encounter both MUST prefer the v1 manifest pointer.

2. Manifest Document

Required fields

Optional identity fields

Protocols

protocols is an array of objects. Each object declares one protocol the agent speaks.

Capabilities

capabilities is an array of objects. Each object declares one capability and (optionally) the JSON Schema for its inputs and outputs.

Pricing

pricing is an object describing how the agent charges.

The paid object:

Example

{
  "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",
      "description": "Searches academic and web sources, returns 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": "USD", "amount": "0.01", "unit": "per_request" }
  },
  "signature": "0x7f3e8d4c..."
}

3. Protocol Vocabulary

Custom protocol IDs are permitted. Lowercase, hyphenated.

4. Canonical Serialization & Signing

Canonicalization

Manifests MUST be serialized using RFC 8785 JSON Canonicalization Scheme (JCS) for signing and verification:

• Keys at every nesting level sorted lexically by Unicode code-point.
• No insignificant whitespace.
• Numbers in shortest round-trippable form.
• Strings escaped per RFC 8259 §7 with the smallest valid escape.

Signing

1. Build the manifest object without the signature field.
2. Canonicalize per JCS. Result: a UTF-8 byte sequence.
3. Sign per EIP-191 (personal_sign) with the wallet that holds the domain's NFT.
4. Place the resulting hex signature (with 0x prefix) in the signature field.

Verification

1. Fetch the manifest JSON from IPFS.
2. Compute the IPFS CID from the fetched bytes. Compare against the CID in the TXT record. They MUST match.
3. Remove the signature field; canonicalize the remainder.
4. Recover the signer address from the signature and the canonical bytes via EIP-191.
5. Compare against the owner field. They MUST match.
6. Compute tokenId = keccak256(bytes(tld) ++ keccak256(bytes(sld))).
7. Query FNS.ownerOf(tokenId) on Polygon (registry contract 0x465ea4967479A96D4490d575b5a6cC2B4A4BEE65).
8. Compare against the owner field. They MUST match.

If any of steps 2, 5, 8 fails, the manifest is invalid and MUST be rejected.

5. Resolution Algorithm

function resolve(domain):
  records = dnsTxt(domain)
  pointer = records.find(r => r.startsWith("agt-manifest="))

  if pointer:
    cid = pointer.slice("agt-manifest=ipfs://".length)
    bytes = fetchFromIpfs(cid)
    if cidOf(bytes) != cid: REJECT (gateway tampering)
    json = parse(bytes)
    if !verifySignature(json): REJECT
    if !verifyOnChainOwner(json.domain, json.owner): REJECT
    return { manifest: json, source: "v1" }

  if records.has("agt-version=1"):
    return { manifest: parseLegacyV0(records), source: "v0-legacy", verified: false }

  return null

6. 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 from a previous owner is invalid after a transfer.
• Manifests are public and immutable. Never include secrets, API keys, or anything not intended for permanent public record.
• Endpoint TLS. Endpoints SHOULD use HTTPS. Clients SHOULD warn before connecting to plain HTTP endpoints.
• Manifest size. Implementations MUST accept up to 64 KiB. Most manifests are well under 4 KiB.

7. Capability Vocabulary (Reference)

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

8. Legacy v0 (TXT-only) Manifests

Approximately 942 domains were registered before this specification with the pre-1.0 TXT-record format. Those domains have an agt-version=1 record and one TXT record per field. Format reference:

Resolvers SHOULD parse v0 records into a v1-shaped object with legacy: true. Writers MUST NOT generate new v0 manifests. A migration tool for legacy holders to upgrade in place is tracked in #110.

9. 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
• EIP-155 — Chain identifiers
• JSON Schema Draft 2020-12
• IPFS CIDv1 — multibase, multihash, multicodec