How T402 Achieves Multi-Chain Payment Settlement

The Multi-Chain Challenge

Supporting 44 networks isn't just about writing separate integrations for each chain. Each chain has its own transaction format, signing algorithm, token standard, and finality model. A naive approach would create an exponential matrix of complexity — every transport times every scheme times every chain.

T402 solves this through strict separation of concerns. The protocol defines clear interfaces at each layer, so adding a new chain doesn't require changes to the transport or scheme layers.

Three-Layer Architecture

Transport Layer

Defines how payment requirements and authorizations are exchanged. HTTP uses the 402 status code and X-Payment header. MCP uses JSON-RPC tool invocations. A2A uses task-based flows. The transport layer is completely chain-agnostic.

Scheme Layer

Defines the payment logic. The exact scheme authorizes a precise amount transfer. The upto scheme authorizes up to a maximum, enabling streaming and metered payments. Schemes define what authorization means, not how it's implemented on-chain.

Network Layer

Implements chain-specific operations. For EVM, this means EIP-3009 TransferWithAuthorization signatures. For Solana, SPL token transfer instructions. For TON, Jetton transfer messages. Each mechanism implements the same interface with chain-native primitives.

Universal Chain Addressing with CAIP-2

Every blockchain in T402 is identified by a CAIP-2 chain ID — a namespace:reference pair that universally identifies any blockchain:

This means a 402 response can offer multiple payment options across different chains, and the client simply picks the one it supports. No chain-specific logic needed in the HTTP layer.

The Facilitator Pattern

The facilitator is the bridge between off-chain authorization and on-chain settlement. It's responsible for:

• Verification: Validates that payment signatures are cryptographically correct and parameters match requirements
• Settlement: Submits the on-chain transaction using the authorized transfer
• Multi-chain routing: Maintains wallets and RPC connections for all supported networks

sequenceDiagram
  participant Client
  participant Server
  participant Facilitator

  Client->>Server: GET /resource
  Server-->>Client: 402 + accepts

  Note over Client: Sign off-chain

  Client->>Server: GET + X-Payment
  Server->>Facilitator: POST /verify
  Facilitator-->>Server: { valid: true }
  Server->>Facilitator: POST /settle
  Facilitator-->>Server: { txHash: "..." }
  Server-->>Client: 200 + resource

Servers never need to know chain-specific details. They send the payment payload to the facilitator and get back a verification result. This keeps server implementations simple regardless of how many chains are supported.

The Mechanism Interface

Every chain mechanism implements three roles:

The Client knows how to sign payment authorizations. The Server knows how to enhance payment requirements with chain-specific data. The Facilitator knows how to verify signatures and execute settlements. This three-role pattern is consistent across all 10 blockchain families.

Adding a New Chain

Adding a new blockchain to T402 requires implementing only the mechanism interface for that chain. The process is:

1. Define the CAIP-2 network identifier
2. Implement the client (signature creation)
3. Implement the server (requirement enhancement)
4. Implement the facilitator (verification + settlement)
5. Register the mechanism in the facilitator's supported list

No changes to the HTTP transport, the scheme logic, or existing mechanisms are required. This is how T402 scaled from 1 chain to 44 networks without protocol changes.