LOPWDocumentation

Docs / Networks

Networks

LOPW is a universal protocol: the warranty offer, the service receipt, predicates P1 to P6, the claim checks and outcomes, the service states, floors, fees and time locks mean exactly the same thing on every chain. A chain binding is everything one chain needs to carry those semantics, and nothing in a binding may change what a predicate means or when a claim pays.

One protocol, bound to each chain

One LOPW protocol at the centre, bound to Stellar, six EVM networks and a planned Solana bindingStellarreferenceBaseEthereumArbitrumOptimismPolygonAvalancheSolanaLOPWportable core
  1. Stellar: the reference bindingSoroban contracts in Rust. Ed25519 signatures over SHA-256(tag ‖ network_id ‖ XDR(registry) ‖ XDR(body)). Stake in the USDC Stellar Asset Contract (7 decimals). P6 reads a Reflector SEP-40 oracle at a cited timestamp. x402 exact with a SEP-41 transfer. Live on Stellar testnet.
  2. Base: the first EVM networkThe Solidity binding is built against Base Sepolia first: EIP-712 typed data signed with secp256k1, native USDC (6 decimals), Chainlink getRoundData(roundId) for P6, x402 exact with EIP-3009.
  3. Ethereum: same bindingEthereum mainnet and Sepolia run the same Solidity contracts; only the chain id in the EIP-712 domain, the USDC address and the feed addresses change.
  4. Arbitrum: same bindingArbitrum One and Arbitrum Sepolia: unchanged contracts and SDK, Arbitrum’s native USDC and Chainlink feeds.
  5. Optimism: same bindingOP Mainnet and OP Sepolia: the same OP Stack as Base, so the binding behaves identically.
  6. Polygon: same bindingPolygon PoS and Amoy: native USDC is the stake and payment token; everything else is the shared binding.
  7. Avalanche: same bindingThe Avalanche C-Chain and Fuji: EVM-compatible, native USDC, Chainlink feeds; the binding applies unchanged.
  8. Solana: a planned bindingAnchor programs, Ed25519 over a domain-separated SHA-256 of Borsh bytes, USDC SPL (6 decimals), a Pyth price update verified in-program, x402 exact with an SPL transfer. A design; nothing is deployed.

What a chain binding is

The protocol is specified once. A binding supplies the carriers: how bytes are encoded and hashed, which signature scheme the service signing key uses, which token holds the stake, which oracle P6 reads and how it cites an observation, how x402 settles the payment, and how the signed offer and receipt are encoded inside the lopw extension. Everything a buyer or seller reasons about (terms, stake, states, payout, replay protection) is identical.

Same everywhereDiffers per chain
Offer, receipt and terms fields and their meaningEncoding of those fields (ScVal XDR, ABI, Borsh) and the hash function
Predicates P1 to P6 and their proven / not proven / not verifiable rulesSignature scheme of the service signing key (Ed25519, secp256k1)
The seven claim checks, outcomes, error names and eventsStake token contract and its decimals (USDC with 7 or 6 decimals)
Service states, floors, launch limits, fees, slash rate limit, time locksOracle interface and how an observation is cited (timestamp, round id, price update)
request_hash and response_hash (SHA-256, identical construction)x402 scheme details and the settlement reference used as payment_reference
The ChainBinding interface the SDKs callWire encoding of SignedOffer and SignedReceipt in extensions.lopw

The bindings side by side

BindingContractsSignaturesHashing and encodingStake tokenP6 oraclex402 schemeWire form of the lopw extension
Stellar referenceSoroban, RustEd25519SHA-256 over ScVal XDR, domain-separatedUSDC Stellar Asset Contract (7 decimals)Reflector, SEP-40 price(asset, timestamp)exact, SEP-41 transfer with sponsored feesbase64 ScVal XDR
EVM: Base first, then Ethereum, Arbitrum, Optimism, Polygon, AvalancheSolidity, Foundrysecp256k1 over EIP-712 typed datakeccak-256, EIP-712 hashTypedDataV4Native USDC, ERC-20 (6 decimals)Chainlink AggregatorV3Interface.getRoundData(roundId)exact, EIP-3009 transferWithAuthorization0x-hex ABI encoding
Solana plannedAnchor, RustEd25519SHA-256 over Borsh, domain-separatedUSDC SPL (6 decimals)Pyth price update verified in-programexact, SPL transferBorsh (design)

Amounts are always strings of the token’s smallest unit on the wire; the API and SDKs never use floating point. Floors are the same value expressed in each token’s decimals: the 100 USDC minimum-stake floor is 1_000_000_000 units on Stellar and 100_000_000 units on EVM networks.

The networks

Stellar

StellarReference bindingSoroban · Ed25519 · ScVal XDR · USDC SAC (7 decimals) · Reflector SEP-40 · x402 exact, SEP-41. Live on Stellar testnet with the contract addresses on the page.

EVM networks (one Solidity binding)

BaseBase firstbase-sepolia · base · chain ids 84532 and 8453Ethereumsepolia · ethereum · chain ids 11155111 and 1Arbitrumarbitrum-sepolia · arbitrum · chain ids 421614 and 42161Optimismoptimism-sepolia · optimism · chain ids 11155420 and 10Polygonpolygon-amoy · polygon · chain ids 80002 and 137Avalancheavalanche-fuji · avalanche · chain ids 43113 and 43114

Planned

SolanaPlanned bindingAnchor · Ed25519 over Borsh · USDC SPL (6 decimals) · Pyth · x402 exact, SPL transfer. A design; no program is deployed.

Network names and CAIP-2 ids

API paths and documentation use these network names; the {network} segment of /v1/{network}/... is one of them. The CAIP-2 id is what x402 uses in PaymentRequirements.network.

NameCAIP-2ChainBindingLOPW deployment
testnetstellar:testnetStellar testnetStellarDeployed
mainnetstellar:pubnetStellar mainnetStellarNone published
base-sepoliaeip155:84532Base SepoliaEVMNone published
baseeip155:8453BaseEVMNone published
sepoliaeip155:11155111Ethereum SepoliaEVMNone published
ethereumeip155:1EthereumEVMNone published
arbitrum-sepoliaeip155:421614Arbitrum SepoliaEVMNone published
arbitrumeip155:42161Arbitrum OneEVMNone published
optimism-sepoliaeip155:11155420OP SepoliaEVMNone published
optimismeip155:10OP MainnetEVMNone published
polygon-amoyeip155:80002Polygon AmoyEVMNone published
polygoneip155:137Polygon PoSEVMNone published
avalanche-fujieip155:43113Avalanche FujiEVMNone published
avalancheeip155:43114Avalanche C-ChainEVMNone published
solana-devnetsolana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1Solana devnetSolanaPlanned binding
solanasolana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpSolana mainnetSolanaPlanned binding

testnet and mainnet without a prefix are the Stellar networks, kept for continuity with the first deployment. Every other name carries its chain.

For agents

For agents

ItemValue
Network name in API pathsThe name column above, for example /v1/testnet/services; the API serves a network once a LOPW deployment is published for it
CAIP-2 idstellar:testnet, stellar:pubnet, eip155:<chainId>, solana:<genesis hash prefix>
Wire encoding of extensions.lopwStellar: base64 ScVal XDR. EVM: 0x-hex ABI encoding. Solana (design): Borsh. The JSON shape of the extension is identical on every chain; info.network names the binding’s network
Machine-readable list/.well-known/lopw.json carries bindings[] and networks[] with the same fields as this page
Chain bindings (protocol reference)What every binding must provide, on-chain and off-chain, in the terms of the ChainBinding interface.Hashing and signingThe reference (Stellar) construction byte by byte, with the shared test vectors.x402 extensionWhere the signed offer and receipt travel; identical envelope on every chain.Agents start hereEvery machine-readable file, including the EVM JSON Schemas.