# Networks

> LOPW is one protocol with the same semantics on every chain. What a chain binding is, what differs per chain (signatures, hashing, token, oracle, x402 scheme), a comparison table, and the networks: Stellar as the reference binding, the EVM networks, and the planned Solana binding.

*LOPW documentation · Networks.* Canonical page: https://lopw.com/docs/networks/ · This Markdown twin: https://lopw.com/docs/networks/index.md · Index of all pages: https://lopw.com/llms.txt · Everything in one file: https://lopw.com/llms-full.txt

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.

1. **Stellar: the reference binding** Soroban 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 network** The 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 binding** Ethereum 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 binding** Arbitrum One and Arbitrum Sepolia: unchanged contracts and SDK, Arbitrum’s native USDC and Chainlink feeds.
5. **Optimism: same binding** OP Mainnet and OP Sepolia: the same OP Stack as Base, so the binding behaves identically.
6. **Polygon: same binding** Polygon PoS and Amoy: native USDC is the stake and payment token; everything else is the shared binding.
7. **Avalanche: same binding** The Avalanche C-Chain and Fuji: EVM-compatible, native USDC, Chainlink feeds; the binding applies unchanged.
8. **Solana: a planned binding** Anchor 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 everywhere | Differs per chain |
| --- | --- |
| Offer, receipt and terms fields and their meaning | Encoding of those fields (ScVal XDR, ABI, Borsh) and the hash function |
| Predicates P1 to P6 and their proven / not proven / not verifiable rules | Signature scheme of the service signing key (Ed25519, secp256k1) |
| The seven claim checks, outcomes, error names and events | Stake token contract and its decimals (USDC with 7 or 6 decimals) |
| Service states, floors, launch limits, fees, slash rate limit, time locks | Oracle 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 call | Wire encoding of `SignedOffer` and `SignedReceipt` in `extensions.lopw` |

## The bindings side by side

| Binding | Contracts | Signatures | Hashing and encoding | Stake token | P6 oracle | x402 scheme | Wire form of the lopw extension |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Stellar](https://lopw.com/docs/networks/stellar.html) reference | Soroban, Rust | Ed25519 | SHA-256 over ScVal XDR, domain-separated | USDC Stellar Asset Contract (7 decimals) | Reflector, SEP-40 `price(asset, timestamp)` | `exact`, SEP-41 transfer with sponsored fees | base64 ScVal XDR |
| [EVM](https://lopw.com/docs/networks/evm.html): Base first, then Ethereum, Arbitrum, Optimism, Polygon, Avalanche | Solidity, Foundry | secp256k1 over EIP-712 typed data | keccak-256, EIP-712 `hashTypedDataV4` | Native USDC, ERC-20 (6 decimals) | Chainlink `AggregatorV3Interface.getRoundData(roundId)` | `exact`, EIP-3009 `transferWithAuthorization` | 0x-hex ABI encoding |
| [Solana](https://lopw.com/docs/networks/solana.html) planned | Anchor, Rust | Ed25519 | SHA-256 over Borsh, domain-separated | USDC SPL (6 decimals) | Pyth price update verified in-program | `exact`, SPL transfer | Borsh (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 (reference binding)**

- [Stellar](https://lopw.com/docs/networks/stellar.md): Soroban, Ed25519, ScVal XDR, USDC SAC (7 decimals), Reflector SEP-40, x402 exact with SEP-41; live on Stellar testnet

**EVM networks (one Solidity binding)**

- [Base](https://lopw.com/docs/networks/base.md): `base-sepolia` and `base`, chain ids 84532 and 8453
- [Ethereum](https://lopw.com/docs/networks/ethereum.md): `sepolia` and `ethereum`, chain ids 11155111 and 1
- [Arbitrum](https://lopw.com/docs/networks/arbitrum.md): `arbitrum-sepolia` and `arbitrum`, chain ids 421614 and 42161
- [Optimism](https://lopw.com/docs/networks/optimism.md): `optimism-sepolia` and `optimism`, chain ids 11155420 and 10
- [Polygon](https://lopw.com/docs/networks/polygon.md): `polygon-amoy` and `polygon`, chain ids 80002 and 137
- [Avalanche](https://lopw.com/docs/networks/avalanche.md): `avalanche-fuji` and `avalanche`, chain ids 43113 and 43114

**Planned**

- [Solana](https://lopw.com/docs/networks/solana.md): Anchor, Ed25519 over Borsh, USDC SPL (6 decimals), Pyth, x402 exact with SPL transfer; a design, nothing 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`.

| Name | CAIP-2 | Chain | Binding | LOPW deployment |
| --- | --- | --- | --- | --- |
| `testnet` | `stellar:testnet` | [Stellar testnet](https://lopw.com/docs/networks/stellar.html) | Stellar | Deployed |
| `mainnet` | `stellar:pubnet` | [Stellar mainnet](https://lopw.com/docs/networks/stellar.html) | Stellar | None published |
| `base-sepolia` | `eip155:84532` | [Base Sepolia](https://lopw.com/docs/networks/base.html) | EVM | None published |
| `base` | `eip155:8453` | [Base](https://lopw.com/docs/networks/base.html) | EVM | None published |
| `sepolia` | `eip155:11155111` | [Ethereum Sepolia](https://lopw.com/docs/networks/ethereum.html) | EVM | None published |
| `ethereum` | `eip155:1` | [Ethereum](https://lopw.com/docs/networks/ethereum.html) | EVM | None published |
| `arbitrum-sepolia` | `eip155:421614` | [Arbitrum Sepolia](https://lopw.com/docs/networks/arbitrum.html) | EVM | None published |
| `arbitrum` | `eip155:42161` | [Arbitrum One](https://lopw.com/docs/networks/arbitrum.html) | EVM | None published |
| `optimism-sepolia` | `eip155:11155420` | [OP Sepolia](https://lopw.com/docs/networks/optimism.html) | EVM | None published |
| `optimism` | `eip155:10` | [OP Mainnet](https://lopw.com/docs/networks/optimism.html) | EVM | None published |
| `polygon-amoy` | `eip155:80002` | [Polygon Amoy](https://lopw.com/docs/networks/polygon.html) | EVM | None published |
| `polygon` | `eip155:137` | [Polygon PoS](https://lopw.com/docs/networks/polygon.html) | EVM | None published |
| `avalanche-fuji` | `eip155:43113` | [Avalanche Fuji](https://lopw.com/docs/networks/avalanche.html) | EVM | None published |
| `avalanche` | `eip155:43114` | [Avalanche C-Chain](https://lopw.com/docs/networks/avalanche.html) | EVM | None published |
| `solana-devnet` | `solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1` | [Solana devnet](https://lopw.com/docs/networks/solana.html) | Solana | Planned binding |
| `solana` | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | [Solana mainnet](https://lopw.com/docs/networks/solana.html) | Solana | Planned 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**
>
> | Item | Value |
> | --- | --- |
> | Network name in API paths | The `name` column above, for example `/v1/testnet/services`; the API serves a network once a LOPW deployment is published for it |
> | CAIP-2 id | `stellar:testnet`, `stellar:pubnet`, `eip155:`, `solana:` |
> | Wire encoding of `extensions.lopw` | Stellar: 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](https://lopw.com/.well-known/lopw.json) carries `bindings[]` and `networks[]` with the same fields as this page |

- [Chain bindings (protocol reference)](https://lopw.com/docs/protocol/bindings.html): What every binding must provide, on-chain and off-chain, in the terms of the ChainBinding interface.
- [Hashing and signing](https://lopw.com/docs/protocol/hashing-and-signing.html): The reference (Stellar) construction byte by byte, with the shared test vectors.
- [x402 extension](https://lopw.com/docs/protocol/x402.html): Where the signed offer and receipt travel; identical envelope on every chain.
- [Agents start here](https://lopw.com/docs/agents/): Every machine-readable file, including the EVM JSON Schemas.