Added value: +{
+  "description": "Query parameters to add to the catalogue address, e.g. `{\"txid\": \"4a5e…\"}` for an endpoint whose 402 document declares `?txid=`. `inputs` on the unpaid answer names what the SELLER declares; a seller may need one it does not declare, so undeclared names are accepted too. The origin and path stay the catalogue’s and are verified unchanged, a parameter already in the catalogue address is never replaced, values are bounded and refused rather than trimmed, at most ten. Send the SAME values with the paid knock: paying for a call without its input usually buys an error.",
+  "type": "object"
+}

Added value: +{
+  "description": "The query parameters we added, read back. Null where you sent none.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

Added value: +{
+  "description": "WHAT THE SELLER SAYS THE CALL TAKES, from their own 402 document (bazaar `info.input` and its schema in v2, `outputSchema.input` in v1): `method`, and `query` / `body` as `{ name, required, description, example }`. `required` is true only where they say so. NULL WHERE THEY DECLARE NOTHING, which is not “it needs nothing”: some sellers need a value they never declare. Theirs and a claim.",
+  "type": [
+    "object",
+    "null"
+  ]
+}

Previous value: -"A finished x402 `exact` payment, base64, as YOUR wallet produced it. Sent to the seller under both `X-PAYMENT` and `PAYMENT-SIGNATURE`, because v1 and v2 sellers read different names. A v2 seller matches on the `accepted` field, which must echo the entry of `accepts` you chose VERBATIM — omit it and the answer is “No matching payment requirements”, which reads like a refusal and is an envelope fault. Omit `payment` entirely to read the terms first."New value: +"A finished x402 `exact` payment, base64, as YOUR wallet produced it. Sent to the seller under both `X-PAYMENT` and `PAYMENT-SIGNATURE`, because v1 and v2 sellers read different names. A v2 seller matches on the `accepted` field, which must echo the entry of `accepts` you chose VERBATIM — omit it and the answer is “No matching payment requirements”, which reads like a refusal and is an envelope fault. Omit `payment` entirely to read the terms first. WE NEVER HOLD YOUR KEY and this path cannot: it takes a finished authorisation and carries it, because a seller’s host sends no CORS headers and that failure is indistinguishable from the endpoint being down."

Previous value: -"`served` is an answer in hand. `quoting` is 402 with terms we could read and `charging` 402 without. `rejected` is 402 on a knock that CARRIED a payment, which is the seller refusing what you signed and a different fact from the first 402. `refused` is 401 or 403, where payment is not what is being asked for."New value: +"`served` is an answer in hand. `quoting` is 402 with terms we could read and `charging` 402 without. `rejected` is 402 on a knock that CARRIED a payment, which is the seller refusing what you signed and a different fact from the first 402. `refused` is 401 or 403, where payment is not what is being asked for. On `rejected`, `sellerSays` carries their reason in their words, and the answer DOES NOT ESTABLISH THAT NOTHING WAS SPENT: the seller held your authorisation before answering, and a status code does not report what they did with it."

Previous value: -"The seller’s settlement receipt, verbatim. THEIR claim that the authorisation reached a chain, carried as theirs and never restated as a reading of ours."New value: +"The seller’s settlement receipt, verbatim. THEIR claim that the authorisation reached a chain, carried as theirs and never restated as a reading of ours. A served answer means the seller accepted the authorisation, not that money settled: somebody still has to submit it on chain, and this is the seller saying so rather than us."

Previous value: -"The legs an `exact` EVM wallet can sign, in the seller’s own order, each flattened to what signing needs. `amountRaw` is a STRING in the asset’s smallest unit; `approxUsd` is present ONLY where the seller’s own catalogue entry publishes both figures for the SAME token, since nothing in a payment-requirements document names a token’s decimals. `terms` is their entry VERBATIM, to echo back as `accepted`."New value: +"The legs an `exact` EVM wallet can sign, in the seller’s own order, each flattened to what signing needs. `amountRaw` is a STRING in the asset’s smallest unit; `approxUsd` is present ONLY where the seller’s own catalogue entry publishes both figures for the SAME token, since nothing in a payment-requirements document names a token’s decimals. `terms` is their entry VERBATIM, to echo back as `accepted`. A real offer has several (agent402.tools publishes nine), and WHICH ONE TO PAY ON IS YOURS TO CHOOSE because the chain is inside the signed message and a signature made on a chain you hold nothing on is valid and fails at the transfer."

Added value: +{
+  "description": "WHAT MAY STILL BE DONE WITH WHAT THE CALLER SIGNED. `none-signed`: nothing was signed, so nothing can be submitted. `presented-may-still-be-usable`: it was handed over and a valid authorisation stays usable until it expires or its nonce is spent — so signing again with a fresh nonce can be a SECOND payment. Check the previous transaction before you do.",
+  "enum": [
+    "none-signed",
+    "presented-may-still-be-usable"
+  ],
+  "type": "string"
+}

Previous value: -"What happened, in one sentence. On a `rejected` knock it states that nothing was spent, because an authorisation moves no money until somebody submits it."New value: +"What happened, in one sentence. On a `rejected` knock it says the seller refused the authorisation AND that this answer does not establish on-chain settlement either way; read `settlementState` for that."

Added value: +{
+  "description": "WHAT THIS ANSWER ESTABLISHES ABOUT THE MONEY, which is less than the status code suggests. `none-presented`: no authorisation was handed over, so there is nothing that could settle. `claimed-by-seller`: they returned a receipt — THEIR claim, carried, never verified by us. `unknown`: an authorisation WAS presented and this answer says nothing about its fate. A 402 or a timeout after a payment reads `unknown`: it does NOT establish that the money is safe.",
+  "enum": [
+    "none-presented",
+    "claimed-by-seller",
+    "unknown"
+  ],
+  "type": "string"
+}