A2A v1.0 Custom Protocol Binding

MolTrust Trust Registry Binding

Version 1.0 · Published 2026-05-09 · CryptoKRI GmbH, Zurich

1. What is a Trust Registry Binding

The A2A v1.0 protocol defines three standard transport bindings — JSONRPC, GRPC, and HTTP+JSON — for agent-to-agent task execution and message exchange. Each implies a specific RPC surface (SendMessage, GetTask, CancelTask, etc.).

A Trust Registry Binding is different: it describes services that provide trust assertions about other agents rather than executing tasks themselves. A trust registry's primary role is identity verification, behavioral scoring, credential issuance, and sybil resistance — operations that don't fit the message/task model of standard A2A bindings.

The A2A v1.0 specification explicitly supports custom protocol bindings: the protocol_binding field is documented as "an open form string, to be easily extended for other protocol bindings." This document specifies one such extension.

2. MolTrust as Reference Implementation

MolTrust (moltrust.ch) is the reference implementation of the Trust Registry Binding. It is a production trust infrastructure for autonomous AI agents, providing W3C DID-based identity, Verifiable Credentials, Agent Authorization Envelopes (AAE), and on-chain anchoring on Base L2.

The binding is open: any organization implementing trust registry services may declare conformance to this binding by referencing this URI in their AgentCard.

This document specifies the contract. The MolTrust API at api.moltrust.ch demonstrates the contract.

3. Endpoint Inventory

A Trust Registry Binding implementation exposes skill endpoints over HTTPS. Each skill defined in the AgentCard maps to one or more HTTP endpoints. The binding does not mandate URL conventions; the AgentCard's supportedInterfaces[].url field provides the base URL.

3.1 Trust Score

Returns a behavioral trust score (0–100) for a registered agent identified by W3C DID, including breakdown components, sybil penalty, and behavioral flags.

GET {base_url}/skill/trust-score/{did}

Response 200:
{
  "did": "did:moltrust:abc123",
  "score": 73,
  "breakdown": {
    "direct_endorsements": 0.6,
    "propagated": 0.3,
    "cross_vertical": 0.1,
    "sybil_penalty": 0.0,
    "interaction_bonus": 5,
    "wallet_bonus": 3
  },
  "flags": [],
  "anchor": "0x6d7a84e5...",
  "computed_at": "2026-05-09T08:00:00Z"
}

3.2 DID Resolution

Resolves W3C Decentralized Identifiers to DID Documents. DIF Universal Resolver compatible.

GET https://uresolver.moltrust.ch/1.0/identifiers/{did}

3.3 Credential Verification

Verifies W3C Verifiable Credentials including AAE (Agent Authorization Envelope) delegation chains.

POST {base_url}/credentials/verify
Content-Type: application/json

{ "credential": { /* W3C VC */ } }

Response 200:
{
  "verified": true,
  "issuer": "did:moltrust:...",
  "checks": {
    "signature": "valid",
    "expiration": "valid",
    "revocation": "not_revoked",
    "delegation_chain": "valid"
  }
}

3.4 Wallet Binding

Verifies cryptographic binding between agent DID and blockchain wallet address.

GET {base_url}/wallet/{address}

Response 200:
{
  "address": "0x...",
  "did": "did:moltrust:...",
  "wallet_age_days": 142,
  "tx_count": 1837,
  "usdc_balance": 524.50,
  "erc8004_registered": true,
  "x402_ready": true
}

3.5 Sybil Detection

On-chain sybil cluster detection via wallet age, counterparty graph, funding source analysis. Paid via x402 micropayment ($0.10 USDC on Base L2).

GET {base_url}/guard/api/sybil/scan/{address}

Response 200:
{
  "address": "0x...",
  "sybil_score": 0.15,
  "indicators": {
    "wallet_age_days": 142,
    "funding_source_clean": true,
    "counterparty_diversity": 0.78
  },
  "verdict": "low_risk"
}

4. Authentication Schemes

Trust Registry Binding implementations declare authentication schemes in the AgentCard's securitySchemes field. The MolTrust reference implementation supports three:

5. Discovery

1. Agent Card published at {base_url}/.well-known/agent-card.json (RFC 8615)
2. The Agent Card's supportedInterfaces[].protocolBinding field references this binding URI
3. Skills are declared in the Agent Card; their endpoints follow the conventions described in section 3

MolTrust's live Agent Card: https://api.moltrust.ch/.well-known/agent-card.json

5.1 Extended Agent Card

The public agent card is unauthenticated and contains the basic skill inventory. The Extended Agent Card is an authenticated endpoint that returns the full service surface, including paid skills, x402 pricing inventory, and MoltGuard surveillance capabilities.

GET {base_url}/extendedAgentCard
Headers:
  X-API-Key: mt_...           (Stripe-tier-gated)
  OR
  X-MolTrust-DID: did:moltrust:... (registered agent)

Response 200:
  Same A2A v1.0 AgentCard schema as public card, but with:
  - 9 skills (5 public + 4 extended: endorsement, market-check, events-feed, credential-issue)
  - 7 capabilities.extensions (5 public + 2 extended: x402-pricing, moltguard)
  - Same securitySchemes, same supportedInterfaces

Response 401:
  No auth provided. Use X-API-Key OR X-MolTrust-DID header.

Availability is signaled by capabilities.extendedAgentCard: true in the public agent card.

6. Extension System

Trust Registry Bindings can declare additional capabilities via the A2A v1.0 capabilities.extensions mechanism. MolTrust uses this for protocol-specific extensions:

Detailed specifications for each extension are published incrementally.

7. Versioning

This binding uses URI-versioning. Breaking changes increment the version path: /v1, /v2, etc. Within a version, additive changes (new optional skills, new authentication schemes) are non-breaking.

Implementations may declare conformance to multiple versions simultaneously by listing multiple binding URIs in supportedInterfaces.

8. References

• A2A v1.0 Specification (Linux Foundation, March 2026)
• MolTrust Protocol Whitepaper v0.8
• Know Your Agent Framework
• MolTrust GitHub Organization
• MolTrust Homepage