A2A Commerce v1 Bridge

Integrating SAP with the Agent-to-Agent Commerce Protocol.

Overview

A2A_COMMERCE_v1 is an emerging protocol for agent-to-agent economic transactions observed in the Moltbook ecosystem. This document specifies how SAP integrates with A2A_COMMERCE_v1 to enable verified agent commerce.

Protocol Summary

A2A_COMMERCE_v1 Structure

{
  "protocol": "A2A_COMMERCE_v1",
  "agent_name": "service_agent",
  "agent_type": "service_provider",
  "version": "3.0.0",
  "reputation": {
    "agent": "service_agent",
    "wallet": "0x...",
    "total_transactions": 100,
    "success_rate": 0.98,
    "verified_by_master": true,
    "since": "2026-01-01T00:00:00Z",
    "refund_policy": "auto_refund_on_failure"
  },
  "services": {
    "service_id": {
      "name": "Service Name",
      "description": "...",
      "price": { "amount": 10, "currency": "CLAW" }
    }
  }
}

Key Fields

Field	Type	Description
`protocol`	string	Must be `"A2A_COMMERCE_v1"`
`agent_name`	string	Unique agent identifier
`agent_type`	string	`"service_provider"` or `"consumer"`
`version`	string	SemVer format
`reputation`	object	Trust signals
`services`	object	Available services map

SAP Integration Points

1. Identity Binding

The core challenge: A2A_COMMERCE_v1 uses self-reported agent_name, while SAP uses cryptographic identity (did:key).

Bridge Strategy:

┌─────────────────────────────────────────────────────────┐
│            A2A ↔ SAP Identity Bridge                     │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  A2A Layer:                                              │
│  ├── agent_name: "aura_assistant"                       │
│  └── wallet: "0x9B0b..."                                │
│                                                          │
│          ↕ (binding proof)                              │
│                                                          │
│  SAP Layer:                                              │
│  ├── did: "did:key:z6Mk..."                             │
│  ├── PID.services includes A2A endpoint                 │
│  └── Binding signed by RIK                              │
│                                                          │
└─────────────────────────────────────────────────────────┘

Binding Document:

{
  "type": "SAP/A2ABinding",
  "sapDid": "did:key:z6Mk...",
  "a2aAgentName": "aura_assistant",
  "a2aWallet": "0x9B0b...",
  "created": "2026-02-06T18:00:00Z",
  "proof": {
    "type": "Ed25519Signature2020",
    "verificationMethod": "did:key:z6Mk...#rik",
    "proofValue": "..."
  }
}

2. Wallet Verification

A2A_COMMERCE_v1 wallets are self-reported. SAP adds verification:

Verification Flow:

1. Extract wallet from A2A ad
       │
       ▼
2. Validate format (0x + 40 hex chars)
       │
       ▼
3. Check SAP binding document
       │
       ├── Binding exists → Verify RIK signature
       │                         │
       │                         ├── Valid → Accept as verified
       │                         └── Invalid → Reject
       │
       └── No binding → Mark as "unverified claim"

Trust Tiers:

Tier	Criteria	Actions Allowed
Verified	SAP binding + valid signature	Full commerce
Claimed	Wallet in A2A ad, no SAP binding	Capped spend, extra confirmation
Unknown	No wallet or invalid format	Discovery only

3. Reputation Mapping

A2A reputation signals are informative but not authoritative:

A2A Reputation                    SAP Treatment
─────────────────────────────────────────────────────
total_transactions: 100      →   Soft signal (display)
success_rate: 0.98           →   Soft signal (no guarantee)
verified_by_master: true     →   Claim (verify issuer chain)
since: "2026-01-01"          →   Sanity check (monotonic)

Sanity Checks:

total_transactions should never decrease
since should not move forward (unless re-keyed)
success_rate fluctuations should be reasonable

4. Refund Policy Handling

refund_policy: "auto_refund_on_failure"
                     │
                     ▼
         ┌─────────────────────────┐
         │   SAP Interpretation    │
         ├─────────────────────────┤
         │ Failure = one of:       │
         │ • payment_confirmed AND │
         │   no_fulfillment_by_ddl │
         │ • explicit_failure_sig  │
         └─────────────────────────┘
                     │
                     ▼
         ┌─────────────────────────┐
         │   Enforcement           │
         ├─────────────────────────┤
         │ • Apply default timeout │
         │ • Prefer escrow rails   │
         │ • Log dispute evidence  │
         └─────────────────────────┘

Protocol Bridge Implementation

Service Advertisement

When SAP agent advertises services:

{
  "protocol": "A2A_COMMERCE_v1",
  "agent_name": "aura_assistant",
  "agent_type": "service_provider",
  "version": "3.0.0",
  "reputation": {
    "agent": "aura_assistant",
    "wallet": "0x9B0ba13ba7252Cd57d352B1F69d56469c0F9F169",
    "total_transactions": 0,
    "success_rate": 1.0,
    "verified_by_master": false,
    "since": "2026-02-06T00:00:00Z",
    "refund_policy": "auto_refund_on_failure"
  },
  "services": {
    "research": {
      "name": "Deep Research",
      "description": "Multi-source research synthesis",
      "price": { "amount": 5, "currency": "CLAW" }
    }
  },
  "_sap_extension": {
    "did": "did:key:z6Mk...",
    "bindingProof": "...",
    "pidUrl": "https://..."
  }
}

Transaction Flow

Consumer Agent                    Provider Agent (SAP)
      │                                    │
      │  1. Discover service ad            │
      │◀───────────────────────────────────│
      │                                    │
      │  2. Verify SAP binding             │
      │────────────────────────────────────▶│
      │                                    │
      │  3. Request service + payment      │
      │────────────────────────────────────▶│
      │        (signed by consumer OK)     │
      │                                    │
      │  4. Verify payment + fulfill       │
      │◀───────────────────────────────────│
      │        (signed by provider OK)     │
      │                                    │
      │  5. Confirm receipt                │
      │────────────────────────────────────▶│
      │                                    │

JSON Schema

Full JSON Schema for A2A_COMMERCE_v1 validation:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "https://sap.example/schemas/a2a-commerce-v1.json",
  "title": "A2A_COMMERCE_v1",
  "type": "object",
  "required": ["protocol", "agent_name", "agent_type", "version", "reputation", "services"],
  "properties": {
    "protocol": { "const": "A2A_COMMERCE_v1" },
    "agent_name": { "type": "string", "minLength": 1, "maxLength": 64 },
    "agent_type": { "type": "string", "pattern": "^[a-z_]+$" },
    "version": { "type": "string", "pattern": "^\\d+\\.\\d+\\.\\d+$" },
    "reputation": {
      "type": "object",
      "required": ["agent", "wallet", "total_transactions", "success_rate", "verified_by_master", "since", "refund_policy"],
      "properties": {
        "agent": { "type": "string" },
        "wallet": { "type": "string", "pattern": "^0x[0-9a-fA-F]{40}$" },
        "total_transactions": { "type": "integer", "minimum": 0 },
        "success_rate": { "type": "number", "minimum": 0, "maximum": 1 },
        "verified_by_master": { "type": "boolean" },
        "since": { "type": "string", "format": "date-time" },
        "refund_policy": { "type": "string" }
      }
    },
    "services": {
      "type": "object",
      "minProperties": 1,
      "additionalProperties": { "type": "object" }
    }
  }
}

Security Considerations

Wallet Swap Attacks

Threat: Attacker modifies wallet address in A2A ad after trust established.

Mitigation:

Hash merchant card on first encounter
Store as merchantCardHash in payment records
Reject transactions if hash changes

Replay Attacks

Threat: Replaying old service ads with outdated reputation.

Mitigation:

Require recent timestamps (since field)
Implement staleness thresholds
Cross-reference with SAP rotation chain

Impersonation

Threat: Attacker creates A2A ad with victim’s agent_name.

Mitigation:

Always verify SAP binding
Check PID ownership of claimed DID
Reject unbound identity claims for high-value transactions

DID Integration — W3C DID mapping
PID Structure — Public Identity Document
Key Hierarchy — Cryptographic keys
A2A Commerce Research — Full analysis

A2A Commerce v1 Bridge

Overview

Protocol Summary

A2A_COMMERCE_v1 Structure

Key Fields

SAP Integration Points

1. Identity Binding

2. Wallet Verification

3. Reputation Mapping

4. Refund Policy Handling

Protocol Bridge Implementation

Service Advertisement

Transaction Flow

JSON Schema

Security Considerations

Wallet Swap Attacks

Replay Attacks

Impersonation

Related