> ## Documentation Index
> Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
> Use this file to discover all available pages before exploring further.
# Chain-agnostic agent payment negotiation
> Agents that speak different chains negotiate a shared settlement lane, then pay from their own wallet. No account. Twelve mainnet chains across x402, MPP, AP2 and A2A.
## 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.
| Chain | Settlement weld | Asset |
| ------------ | ------------------------------------------------------------ | --------------------------------- |
| Algorand | AVM note-binding | USDC (native, ASA 31566704) |
| Voi | AVM note-binding | aUSDC (Aramid-bridged ASA 302190) |
| Base | EIP-3009 signed authorization (stock-payable; optional weld) | USDC (native) |
| Monad | EIP-3009 signed authorization (stock-payable; optional weld) | USDC (native) |
| Polygon PoS | EIP-3009 signed authorization (stock-payable; optional weld) | USDC (native) |
| Arbitrum One | EIP-3009 signed authorization (stock-payable; optional weld) | USDC (native) |
| OP Mainnet | EIP-3009 signed authorization (stock-payable; optional weld) | USDC (native) |
| Stellar | MEMO\_TEXT-bound | USDC (native) |
| Hedera | tx-memo-bound | USDC (native, HTS 0.0.456858) |
| Solana | server-derived reference | USDC (native) |
| Tempo | TIP-20 transferWithMemo | USDC.e (Stargate-bridged) |
Native Circle USDC on Algorand, Base, Monad, Polygon, Arbitrum, OP Mainnet,
Solana, Stellar and Hedera; bridged on Voi (Aramid) and Tempo (Stargate).
## The endpoint
```bash GET theme={null}
curl -s https://pay.algovoi.co.uk/pay/v1/negotiate
```
```bash POST theme={null}
curl -s -X POST https://pay.algovoi.co.uk/pay/v1/negotiate \
-H 'content-type: application/json' \
-d '{
"chains": ["eip155:8453", "hedera:mainnet"],
"protocols": ["x402", "a2a"],
"service_id": "receipt-verify"
}'
```
`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:
```json theme={null}
{
"negotiated": true,
"provider_did": "did:web:pay.algovoi.co.uk",
"service_id": "receipt-verify",
"price_microusdc": 10000,
"common_lanes": [
{
"id": "eip155:8453",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"asset_name": "USDC",
"decimals": 6,
"binding": "eip3009-authorization-weld",
"scheme_kind": "eip3009-exact"
},
{
"id": "hedera:mainnet",
"asset": "0.0.456858",
"asset_name": "USDC",
"decimals": 6,
"binding": "memo-binding",
"scheme_kind": "hedera-memo"
}
],
"common_protocols": ["x402", "a2a"],
"rail_protocols": ["x402", "a2a", "mpp", "ap2"],
"recommended": {
"network": "eip155:8453",
"x402_name": "base",
"protocol": "x402",
"reason": "first shared lane in the rail's advertise order (all lanes are equally priced)"
},
"next": {
"action": "POST your body to the service URL to receive the strict-v2 402, then pay the recommended lane and present X-PAYMENT",
"url": "/pay/v1/verify/receipt"
},
"unmatched_chains": []
}
```
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.