Give your AI agent a verified domain

To give an AI agent an identity others can check, register a domain and serve four well-known files over HTTPS:

All sources checked 3 Nov 2026.

Why a domain is the anchor

Every HTTP client already trusts DNS plus TLS. If your agent's card, keys and DID all live under a domain you control, anyone can fetch them and know they came from the domain's owner.

Step 1: Register the domain

Search and buy on StableDomains, paid in USDC or USDT on 7 chains. Your agent can do it itself through an MCP server or the x402 API: see how AI agents register domains.

Step 2: Point DNS at your host

Use the MCP tools set_dns, apply_dns_template (for example vercel or netlify) or set_url_forward, or the REST API. The files below must be served over HTTPS from the domain itself.

Step 3: Publish the A2A agent card

The A2A spec places the Agent Card at https://{domain}/.well-known/agent-card.json. Minimal sketch (check field names against the spec version you target):

{
  "name": "Example Agent",
  "description": "Books meetings.",
  "url": "https://agent.example.com/a2a",
  "version": "1.0.0",
  "capabilities": {},
  "skills": []
}

Step 4: ERC-8004 registration and domain verification

ERC-8004 (a draft ERC) defines an on-chain Identity Registry. You call register(agentURI), where agentURI points to a registration file of type https://eips.ethereum.org/EIPS/eip-8004#registration-v1 listing services, x402Support and registrations (each with agentId and agentRegistry as namespace:chainId:registry). To prove you control an endpoint domain, publish https://{domain}/.well-known/agent-registration.json containing at least the registrations list. This is the step that needs a blockchain.

Step 5: did:web

did:web:example.com resolves to https://example.com/.well-known/did.json.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:web:example.com",
  "verificationMethod": [{
    "id": "did:web:example.com#key-1",
    "type": "JsonWebKey2020",
    "controller": "did:web:example.com",
    "publicKeyJwk": { "kty": "OKP", "crv": "Ed25519", "x": "<base64url>" }
  }],
  "authentication": ["did:web:example.com#key-1"]
}

Step 6: Web Bot Auth

1. Generate an Ed25519 key pair.
2. Publish the public key as a JWKS at /.well-known/http-message-signatures-directory with media type application/http-message-signatures-directory+json. Each key's kid is its JWK thumbprint.
3. Sign outgoing requests with HTTP Message Signatures and send a Signature-Agent header pointing at your directory.

Sources: IETF draft-ietf-webbotauth-httpsig-protocol-01; implementer notes from Cloudflare. Checked 3 Nov 2026.

Coming later

We're building a tool to automate these steps. It isn't available yet. Today you set up the files yourself; the domain and DNS part works now through the StableDomains MCP server.

FAQ

What is an agent card? A JSON document defined by the A2A protocol that describes an agent and its endpoint, served at /.well-known/agent-card.json.

Where does ERC-8004 agent-registration.json go? At https://{endpoint-domain}/.well-known/agent-registration.json, for optional endpoint-domain verification.

Do I need a blockchain for this? Just for ERC-8004. The agent card, did:web and Web Bot Auth all work on an ordinary domain.

What is did:web? A DID method that maps a DID to a domain and fetches its document from /.well-known/did.json.

What is Web Bot Auth and where is the JWKS? An IETF draft for signing bot requests. The public keys sit at /.well-known/http-message-signatures-directory.

Are these standards final? No. ERC-8004 is a draft ERC, did:web is a community group document, and Web Bot Auth is an Internet-Draft. Expect changes.

Does StableDomains host these files? No. You host them on your own server or platform; StableDomains provides the domain and DNS.