Skip to main content

What it is

Chain-agnostic agent payment negotiation is a read-only capability match. An agent tells the AlgoVoi payable rail which chains and protocols it supports, and the rail returns the settlement lanes they have in common, a recommended lane, and the exact next step. The agent then pays from its own wallet and keys. There is no account and no custody. Chain count is table stakes. The distinctive part is negotiating across settlement models that do not resemble each other. That is the interoperability layer.

Why it matters

Twelve mainnet chains, five genuinely different settlement models. The mined-tx lanes weld each payment to its request; the EVM EIP-3009 lanes take a standard signed authorization that is single-use and exact-amount by construction, so stock x402 clients can pay them directly. Native Circle USDC on Algorand, Base, Monad, Polygon, Arbitrum, OP Mainnet, Solana, Stellar and Hedera; bridged on Voi (Aramid) and Tempo (Stargate).

The endpoint

chains uses CAIP-2 identifiers. protocols is any of x402, a2a, mpp, ap2. Both fields are bounded (up to 64 chains, 128 characters each).

The response

An agent that supports Base and Hedera over x402 and A2A gets back the lanes they share, plus a recommended pick and the next call:
Chains the rail does not settle come back in unmatched_chains rather than being silently dropped. The full lane catalogue (all twelve chains, each with its binding descriptor) is always available on the GET form.

Payment flow

  1. Negotiate. POST your supported chains and protocols. Read common_lanes and recommended.
  2. Challenge. POST your body to next.url to receive the strict-v2 402. It carries the server-derived weld value for your chosen lane (the nonce, memo, note, or reference).
  3. Settle. Pay the lane from your own wallet, binding the payment with the weld. Each lane’s note states the binding it requires.
  4. Present. Send the X-PAYMENT header. The rail verifies on-chain and returns a signed, offline-verifiable receipt.

The binding model

The mined-tx lanes require their weld: the memo on Stellar and Hedera, the note on Algorand and Voi, the reference on Solana, and the bytes32 memo on Tempo are mandatory there, and a plain transfer with no weld is rejected — it binds each payment to the specific request so a captured payment cannot be replayed. The EVM EIP-3009 lanes (Base, Monad, Polygon, Arbitrum, OP Mainnet) instead take a standard signed authorization whose intrinsic bindings do the work — exact amount, the rail’s own payTo, a single-use on-chain nonce and a server-fixed EIP-712 domain — so stock x402 clients can pay them, and the nonce weld remains available as optional hardening.

FAQ

No. Payment stays in your own wallet and keys. The rail is tenant-free.
Twelve mainnet chains today: Algorand, Base, Monad, Polygon, Arbitrum, OP Mainnet, Arc, Solana, Stellar, Voi, Hedera and Tempo. The design is extensible to further lanes.
No. It is read-only. It settles nothing and takes no funds; it only reports the lanes you and the rail have in common.
It cannot pay a welded lane. The welds require a wallet that can set the note, memo, reference, or signed authorization the lane binds to.