LOPWDocumentation

Docs / Start here

How a warranty works

One paid API call, seven moments. Play the sequence, or step through it at your own pace. Every arrow below is something that really happens on the wire or on-chain; nothing is simplified away.

How a warranty works, step by step

Sequence of a LOPW warranty between agent, seller and contractsAgentSellerContracts402 + signed offer1x402 payment settles2response + signed receipt3verify and evaluate4claim(offer, receipt)5validator decides6payout from stake / rejected7
  1. Warranty offerThe seller answers the first request with 402 Payment Required: the normal x402 payment requirements plus a signed warranty offer under extensions.lopw. The offer names the service, the registry, the exact terms (terms_hash), the price, the most one receipt can pay out (max_claim) and an expiry.
  2. PaymentThe agent verifies the offer signature against the key registered on-chain, reads the service’s live state, stake and terms, applies its own policy, then pays through standard x402. The payment is settled on-chain by the facilitator; LOPW changes nothing here.
  3. Service receiptThe seller returns the response. The settlement response (PAYMENT-RESPONSE) carries a signed receipt under extensions.lopw that cites the offer, the settlement transaction, the buyer, the request and response hashes, the HTTP status, the time served and the data’s freshness.
  4. Local checkThe agent verifies the receipt (signature, offer, buyer, payment, request and response hashes, status) and evaluates every predicate in the terms locally. A receipt that fails verification is reported as untrusted; it cannot be claimed.
  5. ClaimIf a predicate is breached, the agent (or anyone holding the evidence) submits the signed offer and receipt to the Claims contract inside the claim window. One transaction, one outcome.
  6. ValidatorThe Claims contract checks signatures, window, replay and terms, then calls the validator contract for that predicate. For P6 the validator reads the named oracle on-chain.
  7. Paid or rejectedA proven breach pays the buyer named in the receipt min(max_claim, stake remaining) from the seller’s stake, in the same transaction. A claim the validator cannot prove is recorded as rejected and nothing is paid.

With reduced motion enabled, the controls still step through the sequence; only the moving token is left out.

Who does what

PartyWhat it doesAlready in x402?
SellerRuns a paid API, stakes the bond, signs offers and receiptsYes
BuyerAn agent or app that pays per request and may file a claimYes
FacilitatorThe x402 service that verifies and settles the paymentYes
Bond RegistryContract that holds stake and stores each service’s terms and signing keysNew
ValidatorsContracts that each decide one kind of breach (one per predicate)New
Claims contractVerifies evidence, calls the validator, pays the buyer or rejectsNew

The happy path costs nothing extra

When the seller keeps its promise, steps 5 to 7 never happen. The agent pays once over x402, receives one receipt, verifies it locally and moves on. There is no escrow to release, no extra transaction and no waiting period. The warranty is a standing threat, not a per-call tax.

When a promise is broken

  1. The agent’s local check finds a breached predicate, for example served_at − data_as_of above the promised max_data_age.
  2. Inside the claim window (at most 24 hours, one hour for oracle-backed services) the agent submits the signed offer and receipt to the Claims contract.
  3. The Claims contract verifies both signatures, checks the window and that no claim was paid for this payment yet, confirms the predicate is part of the terms, and calls the validator.
  4. The validator decides from the evidence alone. For P6 it reads the named oracle’s observation on-chain.
  5. A proven breach pays min(max_claim, stake remaining) to the buyer named in the receipt, from the seller’s stake, in the same transaction. A claim that is not proven is recorded as rejected and nothing is paid.

Anyone may submit a claim, but the payout always goes to the buyer named in the receipt, so there is nothing to gain by front-running one.

What cannot be claimed

A receipt with an invalid signature, a missing receipt, and a receipt citing an offer the buyer never saw prove nothing about the seller: anyone could forge them. The buyer SDK reports each as an untrusted response. No claim is possible and no stake is at risk. Quality of an answer, and latency only the buyer witnessed, are out of scope by design.

Next: Who it is for, or jump to the exact rules in the claim lifecycle.