# Choose predicates and limits

> How a seller picks which predicates to promise and sets limits it can keep: parameters per predicate, claim window, max_claim and min_stake, and the registry's validity rules.

*LOPW documentation · Guides.* Canonical page: https://lopw.com/docs/guides/predicates-limits.html · This Markdown twin: https://lopw.com/docs/guides/predicates-limits.md · Index of all pages: https://lopw.com/llms.txt · Everything in one file: https://lopw.com/llms-full.txt

Promise only what you can keep, with limits that leave room for normal operation. Every parameter is part of the hashed terms, so changing one creates a new terms version.

| Predicate | Parameter | How to choose |
| --- | --- | --- |
| P1 Equivocation | none | Always safe to offer: an honest seller never signs two receipts for one payment. |
| P2 Terms mismatch | none | Always safe to offer: the middleware signs receipts with the offer’s terms. |
| P3 Stale data | `max_data_age` (seconds, > 0) | Your worst normal data age plus headroom. Report `data_as_of` on every response; reporting 0 makes P3 unprovable but marks your response untrusted to policy-driven agents. |
| P4 Bad status | `allowed_status` (non-empty) | The statuses you are willing to charge for, usually `[200]`. |
| P5 Size limit | `max_response_bytes` (> 0) | Above your largest legitimate response. |
| P6 Oracle deviation | `oracle_contract`, `oracle_asset`, `max_deviation_bps`, `max_oracle_age` (> 0) | A deviation wide enough to cover the gap between your source and the oracle; an age that covers at least one oracle tick (the reference feed ticks every 5 minutes, so the reference service uses 600 s). |

| Service setting | Meaning | Rule |
| --- | --- | --- |
| `claim_window` | Seconds a receipt stays claimable | 1 to 86,400 (24 h); at most 3,600 (1 h) when P6 is listed, inside the oracle’s 24-hour history retention |
| `max_claim` | Most one receipt pays out | Set per offer by the middleware (`maxClaim`); agents may require a floor with `minMaxClaim` |
| `min_stake` | Stake below which the service is Suspended | At least 100 USDC; set at registration, outside the terms hash, so changing it never invalidates a buyer’s receipt |

## What the registry rejects

`register_service` and `update_terms` fail with `InvalidTerms` when:

- `predicates` is empty, repeats an ID, or names an ID outside 1 to 6
- `claim_window` is 0 or above the protocol maximum
- P3 is listed with `max_data_age` 0
- P4 is listed with an empty `allowed_status`
- P5 is listed with `max_response_bytes` 0
- P6 is listed without an oracle block, with `max_oracle_age` 0, or with a claim window above the oracle limit

## Changing terms later

Call `update_terms(service_id, terms)`. It returns the new `terms_hash`, makes it current, and keeps every earlier version readable so receipts issued under them remain claimable under their own terms. Terms cannot change while a service is `Unbonding` or `Closed`. The largest claim window you have ever registered sets your unbonding delay from then on ([why](https://lopw.com/docs/guides/unbonding.html)).

Use the [predicate explorer](https://lopw.com/docs/protocol/predicates.html#explorer) to see how a sample receipt is judged under different limits.