# How a warranty works

> An animated, step-by-step walk through a LOPW warranty: offer, payment, receipt, local check, claim, validator, and payout or rejection.

*LOPW documentation · Start here.* Canonical page: https://lopw.com/docs/start/how-it-works.html · This Markdown twin: https://lopw.com/docs/start/how-it-works.md · Index of all pages: https://lopw.com/llms.txt · Everything in one file: https://lopw.com/llms-full.txt

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.

1. **Warranty offer** The 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. **Payment** The 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 receipt** The 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 check** The 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. **Claim** If 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. **Validator** The 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 rejected** A 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

| Party | What it does | Already in x402? |
| --- | --- | --- |
| Seller | Runs a paid API, stakes the bond, signs offers and receipts | Yes |
| Buyer | An agent or app that pays per request and may file a claim | Yes |
| Facilitator | The x402 service that verifies and settles the payment | Yes |
| Bond Registry | Contract that holds stake and stores each service’s terms and signing keys | New |
| Validators | Contracts that each decide one kind of breach (one per predicate) | New |
| Claims contract | Verifies evidence, calls the validator, pays the buyer or rejects | New |

## 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](https://lopw.com/docs/start/who-it-is-for.html), or jump to the exact rules in the [claim lifecycle](https://lopw.com/docs/protocol/claims.html).