LOPW Warranty infrastructure
LOPW turns machine-readable promises into bonded, enforceable warranties. A service posts slashable stake against signed terms. When a breach is proven from signed evidence or a named on-chain oracle, the buyer is paid from that stake in a single transaction. No escrow, no arbitration, no human review. One protocol with the same semantics on every chain: Stellar is the reference binding; Base, Ethereum, Arbitrum, Optimism, Polygon and Avalanche share one EVM binding.
Fig. 1 · Illustrative agent network · simulated events
lopw extensionWhat is LOPW?
LOPW is an open protocol that lets service providers back machine-readable promises with on-chain, slashable financial guarantees. AI agents and other autonomous systems can verify what they buy, and are paid automatically when a provable promise is broken. It is one protocol with the same semantics on every chain: Stellar is the reference binding, and each other chain supplies only its own carriers.
Trust for the autonomous economy.
Proof behind every promise.
x402 proves the agent paid. LOPW puts capital behind what the seller promised.
Networks One protocol, every chain
00 In plain English
Software agents now buy data, APIs and compute on their own. LOPW gives them what a careful buyer always wants: a promise in writing, money that backs it, and a refund that arrives by itself when the promise is broken.
Like a security deposit on a rental, a seller locks money behind specific promises: data no older than 30 seconds, never charging for an error, prices that match a public reference.
Like an itemised, signed invoice, the receipt states exactly what was delivered and when. The seller cannot later claim it said something else.
If the receipt itself shows the promise was broken, the buyer is paid from the deposit in one step. No lawyers, no forms, no waiting.
LOPW only pays when a breach can be proven by a contract from evidence alone, so outcomes are never a matter of opinion. It does not judge whether an answer was good. It checks whether a promise was kept.
Core principle
x402 proves the agent paid.LOPW puts capital behind what the seller promised.
01 Term sheet
Every warranted service publishes its terms on-chain and pins them by hash in each signed offer. Before an agent pays, the buyer SDK reads the live bond and refuses to proceed if the agent's policy is not met.
max_claim meets the policy.valid_until and its offer_nonce has not been paid before.terms_hash in every signed offer.02 Settlement schedule
The x402 payment settles normally and is never held. LOPW runs alongside it as an independent accountability layer with exactly one branch, at the end.
Seller answers 402 with x402 terms plus a signed offer pinning its registered terms.
via extensions.lopwBuyer verifies signature, stake and state, then pays through x402. Unchanged.
via x402 exactSeller signs a receipt binding payment, request, response and terms.
via PAYMENT-RESPONSE · extensions.lopwOn a breach, anyone submits offer and receipt inside the claim window.
via Claims contractOne contract per predicate decides from the evidence alone.
via validate()Proven: buyer paid from stake. Otherwise: rejected.
emits ClaimPaid / ClaimRejected03 Stake ledger
Stake is slashable seller capital held per service. It is not per-call insurance: payouts can never exceed it. Follow an example service through claims, the slash rate limit, suspension, top-up and exit.
| # | Event | Δ | Stake |
|---|
max_claim, and never more than the stake left.04 Service states
The seller middleware and the buyer SDK both refuse to proceed unless a service is Active. A service that has never reached its minimum stake issues no offers, so no receipt can exist against it.
Swipe the diagram sideways →
| From | Trigger | To |
|---|---|---|
| — | register_service | Pending |
| Pending | Deposits reach the minimum | Active |
| Pending | withdraw, with no delay | Closed |
| Active | Slash leaves stake below the minimum | Suspended |
| Suspended | Deposit restores the minimum | Active |
| Active or Suspended | request_unbond that would leave stake below the minimum | Unbonding |
| Unbonding | cancel_unbond | Active, or Suspended if below the minimum |
| Unbonding | withdraw after the unbonding delay | Closed |
05 Participants
LOPW adds a registry, validators and a claims contract. Everything else is the commerce agents already do.
Runs a paid API, stakes USDC, signs offers and receipts.
An agent or app that pays per request and may file a claim.
The x402 service that verifies and settles the payment.
Holds stake; stores each service's terms and signing key.
Contracts that each check one kind of breach.
Verifies evidence, calls a validator, pays the buyer or rejects.
06 Chain bindings
The protocol is specified once and bound to each chain. Stellar carries it first and defines the reference: Soroban contracts, Ed25519 over domain-separated XDR, USDC with 7 decimals, Reflector SEP-40 oracles and x402 exact. Every other binding reproduces the same semantics with its own carriers.
Warranty offer, service receipt, validator interface and claim semantics stay the same everywhere.
Encoding, signature scheme, contract functions and the payment-rail binding are specific to each chain.
The Stellar binding in detail, with the live contract addresses on Stellar testnet, and every network: chain ids, CAIP-2 ids, USDC and oracle addresses, deployment status.
Technical reference
Exact predicate conditions, wire format, signing, adjudication and chain bindings. The full reference lives in the documentation.
T1 Predicates
A predicate is one breach condition a contract decides from the evidence alone. Each service's terms list which apply and with what limits. Only deterministic proof pays.
| ID | Breach | Proven when | Evidence |
|---|---|---|---|
| P1 Equivocation | Seller signed two different receipts for one payment | both signatures valid · service_id and payment_reference match · receipt hashes differ | two receipts |
| P2 Terms mismatch | Receipt cites the offer but different terms | receipt.offer_hash = offer hash · receipt.terms_hash ≠ offer.terms_hash | offer + receipt |
| P3 Stale data | Data older than promised | served_at − data_as_of > max_data_age | receipt |
| P4 Bad status | Charged for a status it promised not to charge for | status ∉ allowed_status | receipt |
| P5 Size limit | Response larger than promised | response_bytes > max_response_bytes | receipt |
| P6 Oracle deviation | Served value differs from a named oracle beyond tolerance | oracle_contract and oracle_asset match terms · served_at − oracle_timestamp ≤ max_oracle_age · |reported_value − oracle_price| × 10000 > max_deviation_bps × oracle_price, using price(oracle_asset, oracle_timestamp) | receipt + oracle |
T2 x402 v2 extension
LOPW is an x402 v2 extension under the key lopw. Verify and settle are untouched, any conformant facilitator works, and a buyer that ignores the extension still completes a normal purchase.
extensions.lopw = {
version, service_id,
registry,
terms_hash, // pins on-chain terms
price, asset, max_claim,
valid_until, offer_nonce,
key_version, signature
}// standard x402 "exact" scheme
// facilitator verifies + settles
buyer SDK checks first:
offer signature
service state = Active
stake ≥ policy.minStake
valid_until, offer_nonceextensions.lopw = {
service_id, offer_hash,
terms_hash, buyer,
payment_reference,
request_hash, response_hash,
response_bytes, status,
served_at, data_as_of,
oracle?, key_version,
signature
}T3 Hashing and signatures
Offers and receipts are contract types, serialized as XDR, hashed with SHA-256 and signed with Ed25519, so off-chain code and the contract hash identical bytes. Each service signs with a dedicated key that can sign but never move stake.
(service_id, payment_reference). A second claim is refused whichever receipt it presents.offer_nonce makes every offer hash unique; the buyer SDK refuses an offer it has already paid.valid_until limits how long an offer can be paid.key_version. A rotated key is stamped with a retirement time: receipts it signed before then stay claimable, and it cannot sign new ones.msg = SHA-256(
"LOPW/OFFER/v1" | "LOPW/RECEIPT/v1",
network_id, // no cross-network replay
registry_address, // no cross-deployment replay
XDR(struct without signature)
)
signature = Ed25519(signing_key, msg)
offer_hash = msg // for offers
receipt_hash = msg // for receipts
request_hash = SHA-256(method ⏎
path?query ⏎
SHA-256(body))T4 Claim adjudication
Anyone may submit a claim. The payout always goes to the buyer named in the receipt: min(max_claim, stake remaining), subject to the slash rate limit.
key_version, key not retiredPASSserved_at + claim_windowPASS(service_id, payment_reference)PASSClaimPaid; the registry slashes and transfers the payout.ClaimRejected.| Code | Type | Cause |
|---|---|---|
| NotProven | Rejected | The validator did not find a breach |
| NotVerifiable | Rejected | No usable oracle observation at the cited time |
| UnknownService | Error | No such service, or it is Closed |
| BadSignature | Error | Offer or receipt signature does not verify; no penalty |
| OfferMismatch | Error | Receipt does not cite the supplied offer |
| WindowClosed | Error | Claim window passed, or served_at in the future |
| AlreadyClaimed | Error | A claim was already paid for this payment |
| PredicateNotOffered | Error | The terms do not include this predicate |
| KeyRetired | Error | The key was retired before the receipt was served |
| SlashRateLimited | Error | Epoch cap reached; retry next epoch inside the window |
| NoStake | Error | Stake is zero |
T5 Chain bindings
The offer, receipt, validator interface and claim semantics are portable across networks and machine-payment systems. Each chain binding supplies the encoding, signatures, contracts and payment rail.
| Layer | Stellar · reference binding | EVM · Base, Ethereum, Arbitrum, Optimism, Polygon, Avalanche | Solana · planned |
|---|---|---|---|
| Portable core | |||
| Warranty offer | ● identical | ● identical | ● identical |
| Service receipt | ● identical | ● identical | ● identical |
| Validator interface | ● identical | ● identical | ● identical |
| Claim semantics | ● identical | ● identical | ● identical |
| Binding-specific | |||
| Encoding and hashing | ScVal XDR · SHA-256, domain-separated | ABI · keccak-256 · EIP-712 | Borsh · SHA-256, domain-separated |
| Signatures | Ed25519 | secp256k1 over EIP-712 typed data | Ed25519 |
| Contracts | Soroban (Rust) | Solidity (one binding for all six) | Anchor (Rust) |
| Stake and payment | USDC SAC, 7 decimals · x402 exact, SEP-41 | Native USDC, 6 decimals · x402 exact, EIP-3009 | USDC SPL, 6 decimals · x402 exact, SPL transfer |
| Oracle (P6) | Reflector, SEP-40 price(asset, t) | Chainlink getRoundData(roundId) | Pyth, verified in-program |
Wire form of lopw | base64 ScVal XDR | 0x-hex ABI encoding | Borsh (design) |
| Detail | Stellar binding | EVM binding | Solana (planned) |
Swipe the table sideways →
T6 Architecture and SDKs
Sellers bond USDC behind their promises. Validators check the evidence. Breaches pay out automatically. The SDKs handle signing, verification and claims so integrations stay small.
Holds stake per service; stores terms versions and signing keys; slashes on instruction from Claims.
Verifies signatures and windows, records the claim, calls the validator, pays or rejects.
One per predicate behind an allowlist, so new predicates never touch stake logic.
Applies policy, pays, verifies receipts, evaluates every predicate locally and files claims.
Issues signed offers on 402, settles first, then signs the receipt with the settlement reference.
import { LopwBuyer } from "@lopw/buyer-sdk";
const agent = new LopwBuyer({
secret: process.env.AGENT_SECRET,
policy: {
minStake: 100n * 10_000_000n, // 100 USDC
requiredPredicates: [6],
minMaxClaim: 10_000_000n, // 1 USDC
},
});
const { response, body, warranty } = await agent.fetch(
"https://fx.example.com/v1/quote?pair=EUR-USD"
);
if (warranty?.breaches.length) {
const result = await agent.claim(warranty);
// { outcome: { paid }, transaction }
}import { createLopwExtension, lopwRequestContext, DATA_AS_OF_HEADER }
from "@lopw/seller-middleware";
import { StellarBinding } from "@lopw/protocol";
const lopw = createLopwExtension({
binding: new StellarBinding(), // reference binding; EvmBinding for EVM networks
serviceId, signingSeed, maxClaim,
});
server.registerExtension(lopw); // x402 v2 x402ResourceServer
app.use(lopwRequestContext());
const routes = {
"GET /v1/quote": {
accepts: [{ scheme: "exact", price: "$0.01", network, payTo }],
extensions: { lopw: {} }, // network: CAIP-2 id
},
};
// in the handler, declare data freshness for P3:
res.set(DATA_AS_OF_HEADER, String(asOf));Register the service in the Bond Registry with its terms and a dedicated Ed25519 signing key, deposit at least the minimum stake, then add the middleware.
A tampered receipt is flagged untrusted and no claim is possible. When a slash takes stake below the minimum, the service is suspended and buyer SDKs stop paying it.
Agents can discover the protocol from /llms.txt and /.well-known/lopw.json.