Publish the registration behind the intent-settlement measurement

demo/intent_gap.py was built to test a prediction written down beforehand.
That prediction is now here, body reproduced verbatim, so the confirmation
and falsification thresholds it was judged against can be read rather than
taken on trust.

The header is honest about what the dates prove. This copy went public two
days after the measurement ran, so the commit history establishes priority
and not ordering. Registrations in this line of work go up before the run
from now on, which is the only version of the claim a reader can check.

P2 was mis-specified and is left standing: CoW orders carry short validTo
deadlines, so no interaction target can postdate a signature and the strong
form of that test could never have fired. Editing it out afterwards would
defeat the point of writing it down.

Author: amarshat

agent-calldata-demo/PREDICTION.md

@@ -0,0 +1,118 @@
+# Registration record
+
+## Provenance, and what this record does and does not establish
+
+This prediction was written and committed on 2026-08-01, before `demo/intent_gap.py`
+was run against any settlement. The measurement followed the same day. Its results
+are summarised in the README, under [Intent settlement: does the signed order govern
+what executes?](README.md#intent-settlement-does-the-signed-order-govern-what-executes).
+
+This public copy was added on 2026-08-03, which is **after** the measurement. The
+public commit history therefore establishes priority but not ordering: on its own it
+does not show that the prediction preceded the result. The ordering is recorded in a
+private repository (registration committed 2026-08-01 16:29 UTC+1, first results
+16:34, longitudinal extension 16:42) and that history can be shown to reviewers or
+artifact evaluators on request. Registrations in this line of work will be published
+here before the measurement runs from now on, since that is the only version of the
+claim a reader can check without taking the author's word for it.
+
+The text below is reproduced verbatim from the file committed on 2026-08-01. It has
+not been edited to fit what was found, including the part that turned out to be
+mis-specified: the strong form of P2 could never have fired, because CoW orders carry
+short `validTo` deadlines and every interaction target necessarily predates any
+signature. That error is left standing here and reported as an error.
+
+Only this header is new.
+
+---
+
+# Registered prediction: the wrong-object gap in intent and solver systems
+
+Written 2026-08-01, **before any measurement**. Committed as the registration.
+If the measurement contradicts this, the paper reports the contradiction and the
+framing is weakened accordingly. Do not edit this file after measuring; record
+results in RESULTS.md alongside it.
+
+## Why this site
+
+The three measured layers all concern a transaction the user signs directly. An
+intent system inverts that: the user signs an *order* and never authors the
+transaction that settles it. If the wrong-object pattern is real rather than a
+label applied after the fact, it should recur here, and it should recur in its
+most extreme form.
+
+Target: CoW Protocol settlement (`GPv2Settlement.settle`), because orders and the
+executed interactions are both recoverable from public on-chain calldata. Its
+architecture is representative of UniswapX and 1inch Fusion.
+
+## The prediction
+
+**P1 (main).** In intent settlement, the set of contracts that govern what
+happens to the user's approved balance is not determined by the artifact the
+user signed. Concretely: decoding a settlement transaction will show interaction
+targets that appear nowhere in the signed order, and they will be the majority
+of the contracts touched.
+
+**P2 (the sharp form).** The gap here is not merely that the governing object is
+elsewhere, as in the three measured layers, but that **it does not exist when
+the user signs**. Solver-supplied interaction calldata is authored after the
+signature, by a party the user never chose. A code-reading defense cannot read
+it even in principle, because there is nothing yet to read. This is the temporal
+limit of the same failure, and it connects to the time-of-check residual that
+survived the capability ladder in the earlier work.
+
+**P3 (what still binds).** The signed order does bind the *value* outcome
+through its limit price and receiver, enforced at settlement. So the prediction
+is explicitly NOT that intents are broken or that users are exposed to
+unbounded loss. It is that the value bound is the only thing the signed artifact
+governs, while the contract set is governed elsewhere. A defense that reasons
+about the signed order is reasoning about a genuinely smaller object than the
+one that decides execution.
+
+## Quantities to measure
+
+For a sample of recent mainnet settlements:
+
+1. `|T|` = distinct contract addresses appearing as interaction targets in the
+   settlement calldata.
+2. `|S|` = distinct contract addresses derivable from the signed orders in that
+   settlement (sell token, buy token, receiver, and the settlement contract
+   itself).
+3. `|T \ S|` = targets that govern execution and appear nowhere in any signed
+   order. **This is the analogue of the 61 of 101.**
+4. Whether any interaction target was deployed after the earliest order in the
+   settlement was signed. Any non-zero count is direct evidence for P2.
+
+## Confirmation and falsification, stated in advance
+
+- **P1 confirmed** if, across the sample, the median `|T \ S| / |T|` is above
+  0.5, i.e. most contracts governing execution are absent from what was signed.
+- **P1 falsified** if that ratio is at or near zero, i.e. settlements touch only
+  contracts the order names. That would mean intents route through a fixed,
+  signed-over set and the pattern does not generalise here.
+- **P2 confirmed** by any settlement whose interaction targets include a
+  contract deployed after the order's signing time, or, more weakly, by showing
+  the interaction calldata is solver-authored and unconstrained by the order
+  schema.
+- **P2 falsified** if the protocol constrains interaction targets to a fixed
+  allowlist fixed at signing time.
+- **Ambiguous outcome to report honestly:** if `|T \ S|` is large but every
+  target is a well-known router or pool, the gap exists but its exploitability
+  is bounded by the value constraint in P3. Report this as a bounded instance,
+  not a vulnerability. That is the likely result and it is still evidence for
+  the pattern.
+
+## What this is not
+
+Not a claim of a vulnerability in CoW Protocol or any intent system. The value
+bound in P3 is real and is the point of the design. The claim is about what a
+*defense* can see at signing time, which is the subject of the whole paper.
+
+## Bounds known in advance
+
+- Sample will be recent settlements, so it measures current solver behaviour and
+  not a historical distribution.
+- Contracts touched via nested internal calls are not visible in settlement
+  calldata alone; `|T|` from calldata is therefore a **lower bound** on the true
+  governing set, which makes the prediction harder to confirm, not easier.
+- No claim about how often a malicious solver has actually exploited this.

agent-calldata-demo/README.md

@@ -236,6 +236,12 @@ user's approved balance.
 `demo/intent_gap.py` decodes CoW Protocol settlements and asks how many of the
 contracts that actually execute appear anywhere in the signed order.
 
+What this run was expected to show, including the confirmation and falsification
+thresholds, was written down before it ran: see [PREDICTION.md](PREDICTION.md).
+That file also says plainly what its dates do and do not establish, since it was
+published here after the measurement rather than before it. One of its three
+claims was mis-specified and is left in place rather than quietly fixed.
+
 ```bash
 python3 -m demo.intent_gap --windows 7 --per-window 25 --spacing-days 45
 ```