ERC-8004

Appearance

Real-World Agent Metadata Examples

ReferenceVersion1.1UpdatedJan 9, 2026Non-normative Reference

Description ​

This document provides examples of agent metadata formats observed in production deployments during the ERC-8004 legacy testnet phase (pre-v1, October-December 2025).

NOTE

This is a non-normative reference document. These patterns are provided for educational purposes and to help implementers understand real-world variations. For the official schema, see Agent Metadata Standard.

[!IMPORTANT]
Field Name Update (Jan 2026): Examples below have been updated to use services instead of endpoints per the official EIP-8004 January 2026 update. Historical deployments may still use the legacy endpoints field name, which parsers should continue to support for backward compatibility.

Data Source ​

Source: ERC-8004 Legacy Testnet (pre-v1)
Analysis Date: December 2025
Sample Size: 4,725 production agents

See Sources & References for detailed methodology.

Observed Patterns ​

Pattern 1: SDK Standard Format ​

Prevalence: High (most compliant agents)
Source: Official SDK implementations

json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Agent Name",
  "description": "Description...",
  "image": "ipfs://CID",
  "active": true,
  "services": [
    {
      "name": "A2A",
      "version": "0.3.0",
      "endpoint": "https://.../.well-known/agent-card.json"
    },
    {
      "name": "agentWallet",
      "endpoint": "eip155:11155111:0x..."
    }
  ],
  "updatedAt": 1763112328,
  "registrations": [
    {
      "agentId": 696,
      "agentRegistry": "eip155:84532:0x..."
    }
  ],
  "supportedTrust": [],
  "x402Support": true
}

Characteristics:

  • Minimal, standards-compliant
  • SDK-generated
  • Storage: IPFS or Data URI (base64)

Pattern 2: Extended Metadata Format ​

Prevalence: Medium (specific communities)
Source: Various ecosystem implementations

json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Agent #12345678",
  "description": "Extended agent with custom attributes",
  "image": "https://example.com/avatar.jpg",

  "services": [
    {
      "name": "Custom API",
      "version": "1.0.0",
      "endpoint": "https://api.example.com/v1",
      "description": "Custom API endpoint"
    },
    {
      "name": "OASF",
      "version": "0.8",
      "endpoint": "ipfs://...",
      "skills": ["analytical_skills/data_analysis/blockchain_analysis"],
      "domains": ["technology/blockchain"]
    }
  ],

  "attributes": {
    "custom_field_1": "value1",
    "custom_field_2": "value2"
  },

  "registrations": [
    {
      "agentId": 123,
      "agentRegistry": "eip155:84532:0x..."
    }
  ],
  "supportedTrust": ["reputation", "crypto-economic"]
}

Characteristics:

  • Custom attributes object for extended data
  • Additional trust models possible
  • Storage: HTTP(S) API endpoint

Parser Considerations:

  • Accept attributes as custom extension
  • Unknown fields should be preserved (forward compatibility)

Pattern 3: Non-Standard Data URI ​

Prevalence: Low-medium
Source: Various implementations

json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Agent Name",
  "description": "Agent description",
  "image": "https://example.com/avatar.png",
  "services": [
    {
      "name": "agentWallet",
      "endpoint": "eip155:11155111:0x..."
    }
  ],
  "registrations": [
    {
      "agentId": 0,
      "agentRegistry": "eip155:11155111:0x..."
    }
  ],
  "supportedTrust": ["reputation"]
}

Peculiarity: Some agents store this as data:application/json;base64,{...} but the payload is NOT base64-encoded (plain JSON).

Parser Strategy: Detect { or [ at start of "base64" payload, skip base64 decode, parse directly.

Pattern 4: Minimal/Test Agents ​

Prevalence: Medium (development/testing)

json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Test Agent",
  "description": "Minimal test agent",
  "image": "https://example.com/test.png",
  "services": [],
  "registrations": []
}

Issues:

  • Empty services (agent not reachable)
  • Empty registrations (no on-chain link)

Parser Strategy: Parse successfully, log warnings for missing data.

Common Variations ​

Version String Formats ​

ObservedValid?Notes
"0.3.0"✓A2A semver format
"0.30"✓A2A semver (though 0.3.0 preferred)
"0.8.0"✓OASF without 'v' prefix
"v0.8.0"✓OASF with 'v' prefix (both acceptable)
"0.8.3"✓OASF latest 0.8.x
"2025-06-18"✓MCP date-based versioning
"2025-11-25"✓MCP latest spec (as of Nov 2025)
"2026-01-29"✓MCP future spec date

Image URL Formats ​

FormatExampleNotes
HTTPShttps://example.com/img.pngCommon, mutable
IPFSipfs://Qm...Content-addressed, immutable
Data URIdata:image/png;base64,...Inline, on-chain
Relative/uploads/avatar.jpgRequires base URL resolution

Trust Model Values ​

ValuePrevalenceDescription
reputation~80%On-chain feedback system
crypto-economic~50%Stake-based validation
tee-attestation~20%TEE oracle verification
social-graph~5%Custom (non-standard)

Migration from Custom Formats ​

If you have existing agent metadata in a custom format, here's how to migrate:

Field Mapping Example ​

Custom Format:

json
{
  "agent_name": "MyAgent",
  "agent_description": "Does things",
  "avatar_url": "https://...",
  "api_endpoint": "https://..."
}

ERC-8004 Format:

json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "MyAgent",
  "description": "Does things",
  "image": "https://...",
  "services": [
    {
      "name": "MCP",
      "endpoint": "https://...",
      "version": "2025-06-18"
    }
  ]
}

See Also ​