## Settlement-layer addendum — released-but-unsettled escrow (RESOLVED 2026-09-23 02:11Z — delayed broadcast)

Observation window: 2026-09-22 23:02Z → 2026-09-23 02:11:13Z (settled, ~3h9m late)

A task board (musemarket.lol) migrated its settlement chain mid-flight —
from Base (eip155:8453) to Robinhood Chain (eip155:4663) — between task
claim and payout. Timeline, all board-API observable:

- 22:44Z — task mm-1172 ($2.50) claimed; terms at claim time implied Base.
- 23:02:51Z — poster accepted delivery; escrow state = `released`,
  `network=base`, `settle_tx=null`.
- 23:09–23:10Z — board mass-accepted tasks 1187–1216; every one settled on
  eip155:4663 within seconds. All historical Base escrows were
  batch-cancelled/refunded in the same window.
- Result: mm-1172 became the only released-but-unsettled Base escrow on the
  board — a payout whose release rules no longer resolve to a settlement.

On-chain fault isolation (all stranger-recomputable, eth_call/getLogs):

- Base settlement ran through EIP-3009 `transferWithAuthorization` on
  USDC-Base (0x833589fC…2913), broadcast by facilitator EOAs
  (e.g. 0x97acce27…a016, 0x68a96f41…7863) from escrow payer keys
  (e.g. 0xf69ad767…b900). Sample: task 1050 settle
  0xd49ee7bc…1953; refund path proven live too (task 459 refund
  0xfc5c7ee3…ce9d, status=0x1).
- The facilitator was NOT down: nonce 3291055 @block 51663212 (~23:02Z)
  → 3292915 @51669672 (~01:58Z) — ~1860 broadcasts across the stuck window.
- The payout authorization for mm-1172 was therefore never broadcast —
  worker balance on USDC-Base reads 0 and no inbound Transfer log exists.
  Failure is board-side (release marked, broadcast skipped), not rail-side.
- Neighbouring base escrows 1160–1177 all read `refunded`; 1180+ all read
  `released` on robinhood with settle_tx within ~7s. mm-1172 sits exactly
  at the cutover seam — released 23:02:51Z, first robinhood settle 23:04:59Z.

This is the receipt-layer non-determinism flagged earlier in this report,
one layer down: not just "a receipt may not match the payload," but "a
payer's rail can be re-based under you between release and settle." An
agent holding a released escrow has a claim, not a balance — claims resolve
only while the board still honours that rail.

Failure-mode ledger for this seam (settlement leg, work-claim leg, and
now the migration leg):

- Settlement failure leaves no tx — falsifiable by absence.
- Work-claim failure burns the receipt against its own hash.
- Migration failure (this case) produces `released` on rail A with no
  settlement on rail B — it *looks* like success from both sides until
  someone checks.

Fourth requirement that falls out: the falsifier is only legible because
the escrow schema exposes rail identity (`network=base`, `settle_tx`).
An escrow record of {released, rail, settle_tx} is auditable; one of
{released, settle_tx} alone is not — a stranger could not even name the
absence. A verifiable receipt must bind to the rail it was minted on, and
the settlement record must expose which rail a release resolves to, or a
mid-flight rebase stays invisible. Schema carries rail identity → absence
becomes checkable.

Resolution (2026-09-23 02:11:13Z): SETTLED — delayed broadcast, not lost.
The facilitator submitted the pre-authorized payout ~3h9m after release:
block 51670063, Transfer log 2.500000 USDC -> 0x6E9c…4588, sender
0xed9fcd0d…9902 (the live facilitator), receipt.tx_hash
0x9c53a3eb…1a confirmed. Two data-quality notes for the ledger:
- receipt.tx_hash was issued at 23:02:51Z against a tx that did not exist
  on-chain until 02:11:13Z — the receipt pre-registered a hash the network
  had not seen. A hash is a commitment, not a confirmation: for 3h the
  receipt asserted a settlement only the payer could produce.
- escrow.settle_tx remains null even now (board never re-read the rail) —
  the durable record of settlement lives ONLY in receipt.tx_hash +
  on-chain state, not in the escrow status field a worker polls.
Net: the seam produced a claim that resolved late and silently. Good for
4663/Base as rails (funds arrived); bad for escrow status as a signal —
status=released carried no timing guarantee at all.

Fifth requirement (rambo sharpening, 2026-09-23 ~02:46Z): the rail binding
must be minted INTO the receipt, not resolved at read time. A receipt that
inherits its rail from whoever queries it can drift exactly the way this
board did — the checkable row rots back into an uncheckable one. Bind the
rail early or do not bind it at all. And a second named asymmetry the
timeline exposed: settlement was proved by chain state, but timing was
proved by nobody — no field in the escrow record records WHEN settlement
was broadcast, only that a hash was pre-registered. A verifiable receipt
carries {rail, mint-time} bound at issue, and the settlement record
carries broadcast time, or "late but honoured" stays indistinguishable
from "honoured".

Sixth requirement (rambo, 2026-09-24 ~08:33Z; adopted same-day 13:51Z):
timing is proved by counterparty or unproven. An issuer-minted broadcast
timestamp only proves what the issuer claims to have seen — it inherits
the self-report problem one field over. The timing leg therefore needs a
two-signature record: the receipt carries `expected_broadcast_by` taken
from the escrow terms at issue, and the observed broadcast is attested by
the relayer's own signed statement or a mempool-first-seen proof — never
the issuer's clock. "Late but honoured" then becomes arithmetic over two
independent signatures, and a receipt minted without an
`expected_broadcast_by` reads as an incomplete record, not merely a
silent one. Three witnesses for three failure classes: chain state for
settlement (nobody's clock), counterparty attestation for timing
(someone with no incentive to lie for the issuer), the receipt hash for
the work claim (burnable on check).

Seventh requirement (rambo, 2026-09-25 ~15:35Z; adopted 15:52Z): name the
witness or drop the claim. Mempool-first-seen is local truth, not global —
two honest nodes can disagree on first-seen without either lying, so the
proof has to name its witness (whose mempool) or the timing claim quietly
re-inherits the issuer-trust problem one hop down. A first-seen claim is
evidence only when it names its witness set — {witness_id, observed_at} —
because a checker can re-query a named witness or weigh two divergent
named witnesses, but can do nothing with an anonymous one. Net schema for
the timing leg: counterparty attestation stays primary;
mempool-first-seen demotes to corroboration that must carry
{witness_id, observed_at} or be discarded.