t402 Multi-Chain Architecture: 52 Networks, One Protocol

One Protocol, Twelve Languages

Sending USDT on Ethereum and sending USDT on Solana are as different as writing the same letter in English and Mandarin. Same message, completely different alphabets, grammar, and syntax. t402 is the translator.

Across 12 blockchain families — each with its own signature algorithm, token standard, transaction format, address encoding, fee model, and finality guarantee — “send USDT” means something entirely different:

• On Ethereum, it means calling transferWithAuthorization on an ERC-20 contract with an EIP-712 typed signature using ECDSA secp256k1.
• On Solana, it means constructing a versioned transaction with an SPL Token transfer instruction signed with Ed25519.
• On TON, it means sending an internal message carrying a Jetton transfer payload (TEP-74) signed with Ed25519.
• On Bitcoin, it means constructing a PSBT or generating a BOLT11 Lightning invoice, signed with ECDSA secp256k1.

Same economic action. Twelve completely different implementations. t402 abstracts all of them behind a single PaymentMechanism interface, so that neither the client nor the server needs to know which chain is being used.

This is the final article in the t402 series. Part 1 introduced the protocol. Parts 2-4 covered the specification, the developer experience, and AI agent payments. Here, we go deep into the multi-chain machinery that makes it all work.

CAIP-2: Universal Network Identifiers

Before t402 can abstract chains, it needs a way to name them unambiguously. The protocol uses CAIP-2 (Chain Agnostic Improvement Proposal 2) identifiers — a standard format of namespace:reference:

Every accepts entry in a t402 402 Payment Required response includes a network field with a CAIP-2 identifier. The client matches this against its supported chains and selects the appropriate PaymentMechanism implementation. No ambiguity, no chain ID collisions, no guessing.

{
  "accepts": [
    { "scheme": "exact", "network": "eip155:42161", "amount": "10000" },
    { "scheme": "exact", "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp", "amount": "10000" },
    { "scheme": "exact", "network": "ton:mainnet", "amount": "10000" }
  ]
}

The server advertises which networks it accepts. The client picks one. The protocol handles the rest.

Chain-by-Chain Mechanism Comparison

This is the core of t402’s multi-chain architecture. Each blockchain family requires a dedicated PaymentMechanism implementation in the @t402/mechanisms-* package. Here is how each one works.

graph TB
    T402[t402 Protocol<br/>Unified API] --> ECDSA[ECDSA secp256k1]
    T402 --> ED[Ed25519]
    T402 --> SR[Sr25519]

    ECDSA --> EVM[EVM · 24 networks]
    ECDSA --> TRON_[TRON · 3 networks]
    ECDSA --> STX[Stacks · 2 networks]
    ECDSA --> BTC[Bitcoin · PSBT + LN]

    ED --> SOL[Solana · 2 networks]
    ED --> TON_[TON · 2 networks]
    ED --> NEAR_[NEAR · 2 networks]
    ED --> APT[Aptos · 2 networks]
    ED --> TEZ[Tezos · 2 networks]
    ED --> ATOM[Cosmos · 2 networks]
    ED --> XLM[Stellar · 2 networks]

    SR --> DOT[Polkadot · 2 networks]

EVM (19 USDT0 Networks)

Package: @t402/mechanisms-evm

The EVM family is t402’s most mature and most deployed mechanism, covering 19 networks with USDT0 (Tether’s OFT token via LayerZero) and additional legacy USDT deployments.

• Signature Algorithm: ECDSA secp256k1
• Token Standard: ERC-20 with EIP-3009 (transferWithAuthorization)
• Authorization Method: EIP-712 typed structured data signing
• Gas Model: Sender pays gas, or gasless via ERC-4337 (see below)

The EVM mechanism leverages EIP-3009, which defines transferWithAuthorization — a function that allows a third party to submit a pre-signed token transfer on behalf of the signer. The signature covers the sender, recipient, amount, valid time window (validAfter, validBefore), and a unique nonce. The typed data structure follows EIP-712:

const typedData = {
  types: {
    TransferWithAuthorization: [
      { name: "from", type: "address" },
      { name: "to", type: "address" },
      { name: "value", type: "uint256" },
      { name: "validAfter", type: "uint256" },
      { name: "validBefore", type: "uint256" },
      { name: "nonce", type: "bytes32" },
    ],
  },
  primaryType: "TransferWithAuthorization",
  domain: {
    name: "USD₮0",
    version: "1",
    chainId: 42161,
    verifyingContract: "0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9",
  },
  message: {
    from: senderAddress,
    to: merchantAddress,
    value: "10000", // 0.01 USDT (6 decimals)
    validAfter: 0,
    validBefore: Math.floor(Date.now() / 1000) + 3600,
    nonce: randomBytes32(),
  },
};

The 19 USDT0 networks include: Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, BNB Chain, Mantle, Blast, Scroll, Linea, zkSync Era, Polygon zkEVM, Celo, Gnosis, Fantom, Moonbeam, Kaia, and Taiko.

Solana

Package: @t402/mechanisms-solana

• Signature Algorithm: Ed25519
• Token Standard: SPL Token / Token-2022
• Authorization Method: Versioned transactions with durable nonce or recent blockhash
• Unique Consideration: Compute unit budget, priority fees, account rent

Solana does not have an equivalent to EIP-3009. Instead, the t402 mechanism constructs a versioned transaction (VersionedTransaction) containing an SPL Token transfer instruction. The client signs the full transaction, but the Facilitator submits it.

const instruction = createTransferInstruction(senderTokenAccount, merchantTokenAccount, senderPublicKey, amount, [], TOKEN_PROGRAM_ID);

const message = new TransactionMessage({
  payerKey: facilitatorPublicKey, // Facilitator pays fees
  recentBlockhash: blockhash,
  instructions: [
    ComputeBudgetProgram.setComputeUnitLimit({ units: 200_000 }),
    ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 1000 }),
    instruction,
  ],
}).compileToV0Message();

A critical consideration: the payer’s associated token account must already exist. If it does not, the Facilitator must include a createAssociatedTokenAccount instruction and cover the rent deposit (~0.002 SOL).

TON

Package: @t402/mechanisms-ton

• Signature Algorithm: Ed25519
• Token Standard: Jetton (TEP-74)
• Authorization Method: Internal message with Jetton transfer payload
• Unique Consideration: Two-phase message delivery, Jetton wallet discovery

TON’s actor model means token transfers are asynchronous two-phase operations. Sending USDT on TON requires:

1. Discovering the sender’s Jetton wallet address (a derived contract)
2. Constructing an internal message to that Jetton wallet with a transfer op (0x0f8a7ea5)
3. The Jetton wallet then sends an internal message to the recipient’s Jetton wallet
4. The recipient’s Jetton wallet sends a notification

The t402 mechanism handles Jetton wallet discovery via getWalletAddress on the Jetton master contract and constructs the appropriate cell payload:

const transferBody = beginCell()
  .storeUint(0x0f8a7ea5, 32) // transfer op
  .storeUint(queryId, 64)
  .storeCoins(amount)
  .storeAddress(merchantJettonWallet)
  .storeAddress(senderAddress) // response destination
  .storeBit(false) // no custom payload
  .storeCoins(toNano("0.05")) // forward amount for notification
  .storeBit(false) // no forward payload
  .endCell();

TON Jetton transfers require a small TON amount (~0.1 TON) to cover gas for the multi-hop message chain.

TRON

Package: @t402/mechanisms-tron

• Signature Algorithm: ECDSA secp256k1
• Token Standard: TRC-20
• Authorization Method: Signed transaction with triggerSmartContract
• Unique Consideration: Energy/bandwidth estimation, base58check addresses

TRON uses the same elliptic curve as Ethereum (secp256k1) but has a completely different transaction format and address encoding (base58check instead of hex). TRON’s fee model uses “Energy” for smart contract execution and “Bandwidth” for transaction size, both of which can be staked for or paid in TRX.

The mechanism must estimate energy costs before constructing the transaction:

const energyEstimate = await tronWeb.transactionBuilder.estimateEnergy(
  usdtContractAddress,
  "transfer(address,uint256)",
  {},
  [
    { type: "address", value: merchantAddress },
    { type: "uint256", value: amount },
  ],
  senderAddress
);

TRON is the single largest network for USDT transfers by volume, making this mechanism critical for real-world adoption.

NEAR

Package: @t402/mechanisms-near

• Signature Algorithm: Ed25519
• Token Standard: NEP-141 (Fungible Token)
• Authorization Method: Function call transaction with ft_transfer
• Unique Consideration: Storage deposit requirement, gas attachment

NEAR’s NEP-141 fungible token standard requires that the recipient must have a storage deposit on the token contract before they can receive tokens. If the merchant has never held USDT on NEAR, the first payment to them must include a storage_deposit call (~0.00125 NEAR).

const actions = [];

// Check if recipient is registered
const balance = await account.viewFunction({
  contractId: usdtContractId,
  methodName: "storage_balance_of",
  args: { account_id: merchantId },
});

if (!balance) {
  actions.push(functionCall("storage_deposit", { account_id: merchantId }, GAS, storageDeposit));
}

actions.push(functionCall("ft_transfer", { receiver_id: merchantId, amount: amount.toString() }, GAS, 1));

The 1 yoctoNEAR attachment on ft_transfer is mandatory — NEAR requires at least 1 yocto for security (to prevent cross-contract call exploits).

Aptos

Package: @t402/mechanisms-aptos

• Signature Algorithm: Ed25519 (also supports secp256k1 and multi-key)
• Token Standard: Fungible Asset (FA) standard / legacy Coin
• Authorization Method: Signed transaction with Move entry function call
• Unique Consideration: Move VM, resource-oriented storage, sequence numbers

Aptos uses the Move VM, where tokens are resources stored in accounts rather than balances in a contract’s storage. The Fungible Asset standard is Aptos’s modern token framework:

const payload = {
  function: "0x1::primary_fungible_store::transfer",
  typeArguments: ["0x357b0b957d9942ae4e55a6e05b15b4440eb9a0a0a18b5e2d8c tried0::usdt::USDT"],
  functionArguments: [merchantAddress, amount],
};

const transaction = await aptos.transaction.build.simple({
  sender: senderAddress,
  data: payload,
});

Aptos requires a monotonically increasing sequence number per account (similar to Ethereum’s nonce but stricter), which the mechanism must fetch and manage.

Tezos

Package: @t402/mechanisms-tezos

• Signature Algorithm: Ed25519 (also supports secp256k1, P-256)
• Token Standard: FA2 (TZIP-12)
• Authorization Method: Signed operation with Michelson parameters
• Unique Consideration: Michelson smart contract language, implicit/originated accounts

Tezos uses Michelson, a stack-based, formally verifiable smart contract language. The FA2 (TZIP-12) standard uses a transfer entrypoint that accepts a list of transfers:

const transferParams = contract.methods.transfer([
  {
    from_: senderAddress,
    txs: [
      {
        to_: merchantAddress,
        token_id: 0, // USDt token ID
        amount: amount,
      },
    ],
  },
]);

Tezos supports multiple signature algorithms (Ed25519 for tz1, secp256k1 for tz2, P-256 for tz3), and the mechanism must handle all three based on the sender’s address prefix.

Polkadot (Asset Hub)

Package: @t402/mechanisms-polkadot

• Signature Algorithm: Sr25519 (Schnorrkel)
• Token Standard: Assets pallet on Asset Hub parachain
• Authorization Method: Signed extrinsic with assets.transfer
• Unique Consideration: Substrate runtime, existential deposit, parachain architecture

Polkadot’s USDT lives on the Asset Hub system parachain (formerly Statemint). The mechanism constructs a Substrate extrinsic:

const api = await ApiPromise.create({ provider });
const extrinsic = api.tx.assets.transfer(
  1984, // USDT asset ID on Asset Hub
  merchantAddress,
  amount
);
const signed = await extrinsic.signAsync(senderKeyring);

Polkadot uses Sr25519 (Schnorrkel/Ristretto), a Schnorr signature scheme over the Ristretto group. This is unique among the 12 families — no other chain in the t402 ecosystem uses this algorithm. The mechanism must also account for the existential deposit (~0.1 DOT) required to keep accounts alive.

Stacks

Package: @t402/mechanisms-stacks

• Signature Algorithm: ECDSA secp256k1
• Token Standard: SIP-010 Fungible Token
• Authorization Method: Signed contract call transaction
• Unique Consideration: Clarity language (decidable), Bitcoin settlement, microblock confirmation

Stacks settles on Bitcoin, giving it unique finality properties. Its smart contract language, Clarity, is decidable — meaning you can statically analyze any contract to determine exactly what it will do. The SIP-010 standard defines a transfer function:

const transaction = await makeContractCall({
  contractAddress: "SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR",
  contractName: "token-susdt",
  functionName: "transfer",
  functionArgs: [
    uintCV(amount),
    standardPrincipalCV(senderAddress),
    standardPrincipalCV(merchantAddress),
    noneCV(), // optional memo
  ],
  senderKey: senderPrivateKey,
  network: "mainnet",
});

Stacks transactions anchor to Bitcoin blocks, so finality follows Bitcoin’s ~10-minute block time. The mechanism uses microblock confirmation for faster initial acknowledgment.

Cosmos (Noble)

Package: @t402/mechanisms-cosmos

• Signature Algorithm: Ed25519 (also supports secp256k1)
• Token Standard: Native token (bank module MsgSend)
• Authorization Method: Signed Cosmos SDK transaction
• Unique Consideration: Native USDC (not a smart contract token), IBC compatibility

Noble is the native issuance chain for USDC in the Cosmos ecosystem. Unlike most other chains where stablecoins are smart contract tokens, USDC on Noble is a first-class native asset, transferred via the bank module’s MsgSend:

const msg = {
  typeUrl: "/cosmos.bank.v1beta1.MsgSend",
  value: {
    fromAddress: senderAddress,
    toAddress: merchantAddress,
    amount: [{ denom: "uusdc", amount: amount.toString() }],
  },
};

const fee = { amount: [{ denom: "uusdc", amount: "0" }], gas: "200000" };
const result = await client.signAndBroadcast(senderAddress, [msg], fee);

Noble charges zero gas fees for USDC transfers, making it one of the most cost-effective chains in the t402 ecosystem.

Stellar

Package: @t402/mechanisms-stellar

• Signature Algorithm: Ed25519
• Token Standard: Soroban SEP-41 (Token Interface) / Classic Stellar Assets
• Authorization Method: Signed Soroban transaction with contract invocation
• Unique Consideration: Soroban smart contracts (Rust/WASM), classic vs. Soroban dual path

Stellar has two parallel systems: Classic Stellar (the original protocol with built-in asset support) and Soroban (the newer smart contract platform). t402 uses the Soroban SEP-41 token interface for programmability:

const contract = new StellarSdk.Contract(usdcContractId);

const transaction = new StellarSdk.TransactionBuilder(account, { fee: "100" })
  .addOperation(
    contract.call(
      "transfer",
      nativeToScVal(senderAddress, { type: "address" }),
      nativeToScVal(merchantAddress, { type: "address" }),
      nativeToScVal(amount, { type: "i128" })
    )
  )
  .setTimeout(30)
  .build();

Stellar’s 5-second ledger close time makes it one of the fastest settlement options in the t402 network.

Bitcoin

Package: @t402/mechanisms-bitcoin

• Signature Algorithm: ECDSA secp256k1 (Schnorr for Taproot)
• Token Standard: Native BTC (PSBT) + Lightning Network (BOLT11)
• Authorization Method: Partially Signed Bitcoin Transactions / Lightning invoices
• Unique Consideration: UTXO model, no smart contracts for token transfers, dual on-chain/Lightning path

Bitcoin is architecturally unique among t402’s supported chains. It has no native stablecoin token standard with smart contract transfers. Instead, the mechanism supports two modes:

On-chain (PSBT): For direct BTC payments, the mechanism constructs a Partially Signed Bitcoin Transaction:

const psbt = new bitcoin.Psbt({ network: bitcoin.networks.bitcoin });

psbt.addInput({
  hash: utxo.txid,
  index: utxo.vout,
  witnessUtxo: { script: p2wpkh.output, value: utxo.value },
});

psbt.addOutput({ address: merchantAddress, value: paymentAmount });
psbt.addOutput({ address: changeAddress, value: changeAmount });

psbt.signInput(0, senderKeyPair);
psbt.finalizeAllInputs();

Lightning (BOLT11): For instant micropayments, the merchant generates a BOLT11 invoice and the client pays it:

// Server generates invoice
const invoice = await lnd.addInvoice({ value: satoshiAmount, memo: resourceUrl });

// Client pays
const payment = await lnd.sendPaymentV2({ payment_request: invoice.payment_request });

Lightning payments settle in under 1 second, making Bitcoin the fastest settlement option in the t402 ecosystem when using the Lightning path.

Comprehensive Comparison Table

ERC-4337 Account Abstraction: Gasless Payments

One of the biggest barriers to crypto payments is gas fees. A user wanting to pay ₮0.01 for an API call should not need to first acquire ETH, bridge it to the right L2, and then approve a token spend. ERC-4337 eliminates this problem entirely.

What is ERC-4337

ERC-4337 introduces Account Abstraction to Ethereum without protocol-level changes. Instead of EOAs (Externally Owned Accounts) signing transactions directly, users operate through smart contract wallets that can define custom validation logic, gas payment rules, and batch operations.

The key components:

• Smart Contract Wallet: The user’s on-chain account (e.g., Safe)
• UserOperation (UserOp): A pseudo-transaction that describes what the user wants to do
• Bundler: A service that packages UserOps into real transactions and submits them to the blockchain
• Paymaster: A contract that sponsors gas fees on behalf of the user
• EntryPoint: A singleton contract (v0.7) that validates and executes UserOps

t402’s ERC-4337 Implementation

t402 integrates ERC-4337 via the Safe 4337 Module v0.3.0, which turns any Safe multisig into a 4337-compatible smart account:

Step 1: Create a Safe Smart Account

import { Safe4337Pack } from "@safe-global/relay-kit";

const safe4337 = await Safe4337Pack.init({
  provider: rpcUrl,
  signer: ownerPrivateKey,
  bundlerUrl: "https://api.pimlico.io/v2/42161/rpc?apikey=...",
  paymasterUrl: "https://api.pimlico.io/v2/42161/rpc?apikey=...",
  options: {
    owners: [ownerAddress],
    threshold: 1,
  },
});

Step 2: Build a UserOperation

const userOp = await safe4337.createTransaction({
  transactions: [
    {
      to: usdtContractAddress,
      data: encodeFunctionData({
        abi: erc20Abi,
        functionName: "transfer",
        args: [merchantAddress, amount],
      }),
      value: "0",
    },
  ],
});

Step 3: Paymaster Sponsors Gas

The Paymaster evaluates the UserOp and, if approved, signs a sponsorship commitment. The user pays zero gas. The Paymaster absorbs the cost (typically fractions of a cent on L2s).

t402 supports multiple Paymaster providers:

Step 4: Bundler Submits

const signedUserOp = await safe4337.signTransaction(userOp);
const txHash = await safe4337.executeTransaction(signedUserOp);

The Bundler (Pimlico or Alchemy) packages the signed UserOp, calls EntryPoint.handleOps(), and the transaction executes on-chain. The user never touches ETH.

The Result: A user with only USDT in their wallet can make payments on any of the 19 EVM networks without ever acquiring the native gas token. The Paymaster covers gas, the Bundler handles submission, and the Safe wallet manages the account logic. From the user’s perspective, they signed one message and the payment happened.

EntryPoint v0.7

t402 uses EntryPoint v0.7 (deployed at a deterministic address across all EVM chains), which introduces several improvements over v0.6:

• Separate validation and execution gas limits: Prevents griefing attacks where validation consumes all gas
• Built-in gas compensation: The EntryPoint automatically compensates the Bundler
• Improved postOp handling: Paymasters can verify execution results after the fact
• Delegated gas payment: Native support for ERC-20 token gas payments

sequenceDiagram
    participant U as User
    participant SA as Smart Account<br/>(Safe 4337)
    participant PM as Paymaster<br/>(Pimlico)
    participant BN as Bundler
    participant EP as EntryPoint v0.7
    participant BC as Blockchain

    U->>SA: Sign authorization (off-chain)
    SA->>BN: UserOperation
    BN->>PM: Sponsor gas?
    PM-->>BN: Approved (covers gas)
    BN->>EP: handleOps([userOp])
    EP->>BC: Execute transfer
    BC-->>EP: Success
    EP-->>BN: Receipt
    Note over U: User paid $0 gas<br/>Paymaster covered it

LayerZero USDT0 Cross-Chain Bridging

What is USDT0

USDT0 is Tether’s Omnichain Fungible Token (OFT) implementation via LayerZero. Instead of Tether natively issuing USDT on each chain (which leads to fragmented liquidity), USDT0 provides a unified token that can move seamlessly between 19 networks while maintaining a single liquidity pool.

The architecture:

1. Tether issues native USDT on Ethereum
2. USDT is locked in the USDT0 bridge contract on Ethereum
3. USDT0 (OFT) is minted 1:1 on destination chains via LayerZero
4. USDT0 can move between any two supported chains without returning to Ethereum

This means a user holding USDT0 on Arbitrum can bridge directly to USDT0 on Base, Optimism, or any of the other 17 networks — without routing through Ethereum mainnet.

The 19 USDT0 Networks

Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, BNB Chain, Mantle, Blast, Scroll, Linea, zkSync Era, Polygon zkEVM, Celo, Gnosis, Fantom, Moonbeam, Kaia, and Taiko.

@t402/wdk-bridge

The t402 WDK includes a dedicated bridging package that wraps LayerZero’s USDT0 OFT operations:

import { Usdt0Bridge } from "@t402/wdk-bridge";

const bridge = new Usdt0Bridge({
  sourceChain: "eip155:42161", // Arbitrum
  destinationChain: "eip155:8453", // Base
  signer: wallet,
});

// Get a quote (LayerZero messaging fee)
const quote = await bridge.quote({
  amount: "1000000", // 1 USDT
  recipient: recipientAddress,
});

console.log(`Bridge fee: ${quote.nativeFee} ETH`);

// Execute the bridge
const receipt = await bridge.send({
  amount: "1000000",
  recipient: recipientAddress,
  minAmount: "999000", // 0.1% slippage tolerance
});

console.log(`Source TX: ${receipt.sourceHash}`);
console.log(`LayerZero message: ${receipt.messageId}`);

Cross-Chain Tracking

The LayerZeroScanClient monitors cross-chain message delivery:

import { LayerZeroScanClient } from "@t402/wdk-bridge";

const scanner = new LayerZeroScanClient();

const status = await scanner.getMessageStatus(receipt.messageId);
// { status: "DELIVERED", sourceHash: "0x...", destHash: "0x..." }

// Or poll until delivery
const final = await scanner.waitForDelivery(receipt.messageId, {
  timeout: 120_000, // 2 minutes
  pollInterval: 5_000, // Check every 5 seconds
});

TON-to-EVM Bridging

TON presents a special case. Since TON is not an EVM chain, USDT0’s OFT standard does not apply directly. Instead, t402 uses a two-hop bridge:

1. TON -> Ethereum: Bridge USDT via the official Tether TON bridge
2. Ethereum -> Target EVM: Bridge USDT0 via LayerZero OFT

The WDK abstracts this into a single call:

const bridge = new Usdt0Bridge({
  sourceChain: "ton:mainnet",
  destinationChain: "eip155:42161",
  signer: tonWallet,
});

const receipt = await bridge.send({
  amount: "1000000",
  recipient: evmRecipientAddress,
});
// Internally: TON → Ethereum USDT → Ethereum USDT0 → Arbitrum USDT0

This takes longer (5-20 minutes depending on bridge confirmation times) but provides seamless cross-ecosystem liquidity.

graph LR
    subgraph Source["Source Chain (Ethereum)"]
        S1[User USDT0] --> S2[Lock/Burn]
    end
    S2 --> LZ[LayerZero<br/>Omnichain Message]
    LZ --> D1
    subgraph Dest["Destination Chain (Arbitrum)"]
        D1[Mint/Unlock] --> D2[User USDT0]
    end
    D2 --> PAY[t402 Payment<br/>on Arbitrum]

WDK: Wallet Development Kit

The WDK (Wallet Development Kit) is t402’s high-level SDK that orchestrates the entire payment lifecycle — from balance checking to cross-chain bridging to final settlement.

Package Overview

The @t402/wdk meta-package bundles:

T402Protocol: One Call to Rule Them All

The T402Protocol class is the primary entry point. It performs automatic balance checking, bridging, and payment in a single call:

import { T402Protocol } from "@t402/wdk";

const protocol = new T402Protocol({
  wallets: {
    "eip155:42161": arbitrumWallet,
    "eip155:8453": baseWallet,
    "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp": solanaWallet,
    "ton:mainnet": tonWallet,
  },
  bridgeConfig: { slippageTolerance: 0.001 },
  paymasterConfig: { provider: "pimlico", apiKey: "..." },
});

// Automatic: check balance → bridge if needed → pay
const response = await protocol.fetch("https://api.example.com/premium-data");
const data = await response.json();

What happens internally:

1. Request: GET /premium-data returns 402 Payment Required
2. Parse: Extract accepts array from PAYMENT-REQUIRED header
3. Match: Find which accepted networks the user has wallets + balances for
4. Bridge (if needed): If the user has funds on a different chain, bridge via USDT0
5. Pay: Sign the payment authorization using the appropriate chain mechanism
6. Submit: Send the signed payment in the PAYMENT-SIGNATURE header
7. Receive: Get 200 OK with the resource

DeFi Pre-Processing

When the user does not have the right token on the right chain, the WDK can automatically execute DeFi strategies before payment:

• Swap: User has USDC on Arbitrum but the server wants USDT. Swap via a DEX aggregator (1inch, Jupiter, etc.)
• Borrow: User has ETH collateral. Borrow USDT from Aave, pay, repay later.
• Bridge-Swap: User has USDT on Polygon but the server wants USDT on Arbitrum. Bridge via USDT0, then pay.

const protocol = new T402Protocol({
  wallets: { ... },
  defiStrategies: ["swap", "bridge", "bridge-swap"], // Enable pre-processing
  defiConfig: {
    swapProviders: ["1inch", "jupiter"],
    maxSlippage: 0.005,
    maxBridgeWait: 120_000,
  },
});

Secret Management and Key Rotation

The @t402/wdk-keys package provides secure key management:

import { KeyManager } from "@t402/wdk-keys";

const keyManager = new KeyManager({
  backend: "aws-kms", // or "local", "hashicorp-vault"
  rotationPolicy: {
    maxAge: "30d",
    maxTransactions: 10000,
  },
});

// Rotate keys without changing the smart contract wallet
await keyManager.rotate({
  wallet: safeAddress,
  newOwner: newSignerAddress,
  removeOld: true,
});

Since t402 recommends Safe smart wallets (via ERC-4337), key rotation does not change the wallet address — only the authorized signer changes. This is critical for merchants whose payment address is embedded in their server configuration.

The @t402/* npm Package Map

t402 is not a monolith. It is a modular ecosystem of 36+ packages, each handling a specific concern. Here is how they relate:

@t402/core                     Core protocol types and utilities
  ├── @t402/types              TypeScript type definitions
  ├── @t402/caip               CAIP-2/CAIP-10 identifier utilities
  └── @t402/crypto             Signature verification primitives

@t402/mechanisms-*             Chain-specific payment mechanisms
  ├── @t402/mechanisms-evm     EVM (19 networks)
  ├── @t402/mechanisms-solana  Solana
  ├── @t402/mechanisms-ton     TON
  ├── @t402/mechanisms-tron    TRON
  ├── @t402/mechanisms-near    NEAR
  ├── @t402/mechanisms-aptos   Aptos
  ├── @t402/mechanisms-tezos   Tezos
  ├── @t402/mechanisms-polkadot Polkadot
  ├── @t402/mechanisms-stacks  Stacks
  ├── @t402/mechanisms-cosmos  Cosmos (Noble)
  ├── @t402/mechanisms-stellar Stellar
  └── @t402/mechanisms-bitcoin Bitcoin + Lightning

@t402/server-*                 Server-side middleware
  ├── @t402/express            Express.js middleware
  ├── @t402/fastify            Fastify plugin
  ├── @t402/hono               Hono middleware
  ├── @t402/nextjs             Next.js API route wrapper
  └── @t402/facilitator        Facilitator service SDK

@t402/client-*                 Client-side SDKs
  ├── @t402/fetch              Browser/Node fetch wrapper
  ├── @t402/python             Python SDK
  ├── @t402/go                 Go SDK
  └── @t402/java               Java SDK

@t402/ui-*                     UI components
  ├── @t402/ui-react           React payment components
  └── @t402/ui-web             Web Components (framework-agnostic)

@t402/wdk-*                    Wallet Development Kit
  ├── @t402/wdk                Meta-package
  ├── @t402/wdk-core           Protocol orchestration
  ├── @t402/wdk-wallets        Multi-chain wallets
  ├── @t402/wdk-bridge         USDT0 bridging
  ├── @t402/wdk-defi           DeFi strategies
  └── @t402/wdk-keys           Key management

@t402/ai-*                     AI integration
  ├── @t402/mcp                Model Context Protocol server
  ├── @t402/a2a                Agent-to-Agent transport
  └── @t402/bazaar             API discovery for agents

The dependency flow is strictly layered: Core -> Mechanisms -> Server/Client -> UI -> WDK -> AI. Each layer depends only on the layers below it. A developer building a simple Express server needs only @t402/express and one @t402/mechanisms-* package. A developer building a full wallet experience pulls in the WDK. An AI agent developer adds the AI layer on top.

graph TB
    CORE["@t402/core"] --> EVM["@t402/evm"]
    CORE --> SVM["@t402/svm"]
    CORE --> TON["@t402/ton"]
    CORE --> TRON["@t402/tron"]
    CORE --> MORE["... 8 more chains"]

    EVM --> EXPRESS["@t402/express"]
    EVM --> HONO["@t402/hono"]
    EVM --> NEXT["@t402/next"]

    CORE --> FETCH["@t402/fetch"]
    CORE --> AXIOS["@t402/axios"]

    EVM --> WDK["@t402/wdk-gasless"]
    EVM --> BRIDGE["@t402/wdk-bridge"]

    CORE --> MCP_["@t402/mcp"]
    CORE --> A2A_["@t402/a2a"]

Adding a New Chain

t402 is open source (Apache 2.0), and adding a new blockchain is a well-defined process. Here is what a contributor needs to implement:

1. Implement the PaymentMechanism Interface

import { PaymentMechanism, PaymentAuthorization, VerificationResult } from "@t402/core";

export class NewChainMechanism implements PaymentMechanism {
  readonly networkId: string; // CAIP-2 identifier

  async createAuthorization(params: { from: string; to: string; amount: bigint; asset: string; validUntil: number }): Promise<PaymentAuthorization> {
    // Construct the chain-specific transaction/signature
  }

  async verifyAuthorization(auth: PaymentAuthorization): Promise<VerificationResult> {
    // Verify the signature and check balance
  }

  async submitAuthorization(auth: PaymentAuthorization): Promise<string> {
    // Submit to the blockchain and return tx hash
  }

  async checkBalance(address: string, asset: string): Promise<bigint> {
    // Query the token balance
  }
}

2. Add Network Configuration

// networks/newchain.ts
export const newchainNetworks = [
  {
    id: "newchain:mainnet",
    name: "NewChain Mainnet",
    assets: [
      {
        symbol: "USDT",
        address: "...",
        decimals: 6,
      },
    ],
    rpc: "https://rpc.newchain.io",
    explorer: "https://explorer.newchain.io",
  },
];

3. Write Tests

Every mechanism requires:

• Unit tests for authorization creation and verification
• Integration tests against a testnet or local node
• End-to-end tests through the full t402 protocol flow

4. Submit a Pull Request

The contribution is reviewed for correctness, security (especially around signature verification), and consistency with existing mechanisms. Once merged, the new chain is available to every t402 server and client.

Series Conclusion

This concludes the five-part t402 series:

1. t402: The Internet Finally Gets a Payment Protocol — The 29-year wait for HTTP 402, and why stablecoin micropayments change everything
2. t402 Protocol Deep Dive: How HTTP 402 Actually Works — The complete protocol specification, three-actor architecture, and formal security model
3. Building with t402: From Zero to Paid API in 10 Minutes — Hands-on developer tutorial with the SDK and sandbox
4. t402 and the AI Economy: Machine-to-Machine Payments — MCP integration, A2A transport, ERC-8004 agent identity
5. t402 Multi-Chain Architecture: 52 Networks, One Protocol — You are here

The vision is straightforward: every HTTP endpoint should be payable. Not through payment processors, not through subscription platforms, not through advertising intermediaries — but directly, from wallet to wallet, in any amount, on any chain, settled in seconds.

t402 is the protocol layer that makes this possible. The multi-chain architecture described in this article ensures that the payer’s choice of blockchain is irrelevant to the merchant. The ERC-4337 integration ensures that gas fees never reach the user. The LayerZero USDT0 bridging ensures that liquidity flows freely between networks. And the WDK ensures that developers can build all of this without becoming blockchain experts.

The code is open source. The protocol is permissionless. The standard is HTTP.

When we started this series, HTTP 402 was an empty status code. Five articles later, it has a complete specification, four SDK implementations, 52 network integrations, and an AI-native payment layer. The internet’s missing payment protocol is no longer missing.

Links

• t402.io — Protocol overview
• Documentation — Full technical docs
• GitHub — Open source (Apache 2.0)
• Explorer — Real-time settlement browser
• Sandbox — Public testnet for developers
• Demo — Interactive demonstration
• Whitepaper — 153-page technical specification
• npm packages — All @t402/* packages
• CAIP-2 Specification — Chain Agnostic Identifier
• ERC-4337 — Account Abstraction specification
• LayerZero — Omnichain interoperability protocol

t402 is open source under the Apache 2.0 license. The protocol specification and whitepaper are available under the MIT license.