Cannot close OPEN deal after TC address recycled — prior StreamStopped beneficiary mismatch

[Pithung]

Bug report: close/recover refuse a live OPEN deal because the prior terminal receipt of a recycled deterministic TokenContract address belongs to an earlier deal on the same address

Summary

A buyer cannot STOP a live OPEN deal from the buyer note when the TokenContract
address was previously used by an earlier deal (deployed -> stopped -> destroyed)
and then deterministically re-deployed for the current deal. exact_prior_stop_receipt
counts the historical StreamStopped from the previous lifecycle as the terminal
receipt of the current deal, compares its beneficiary against the current buyer note,
sees a mismatch, and bails — so neither dexdo close nor dexdo recover will submit
the buyer STOP that the open deal actually needs.

The current deal is still OPEN/streaming, its escrow and buyer bond stay locked in the
contract, and there is no CLI flag to bypass the guard.

Environment

• dexdo 0.2.1 (846f8e5, 2026-09-04) on Windows x86_64
• reproduced identically on v0.2.0; the guard code is unchanged on main
• manifest: mainnet, contract generation 4.0.36

Repro command

dexdo close deal-0-17b2d080…-buyer --note-addr 0000…0004::d8a2c3165790b0bfb680cd58c3e36279c7013ed3e755ccb7430a5b076c5a9c9f --note-key <pool-key> --role buyer

dexdo recover --token-contract 0:17b2d080… --note-addr 0:d8a2c316… --note-key <pool-key>
hits the same guard first and fails identically.

Observed error

Error: prior terminal receipt beneficiary 0000000000000000000000000000000000000000000000000000000000000004::d2ff11b72afc66f1cbd5f280e30ee5c41d9362d9b24724a578ae0a7e25f83478 does not match local buyer note 0000000000000000000000000000000000000000000000000000000000000004::d8a2c3165790b0bfb680cd58c3e36279c7013ed3e755ccb7430a5b076c5a9c9f; refusing local reconciliation

Evidence: dexdo settlement-receipt --json 0:17b2d080…

The settlement sequence shows two lifecycles of the same TokenContract address:

lifecycle	events	buyer note	terminal?
1	ContractDeployed (1788607699), StreamFunded, BuyerBondFunded, SellerBondFunded, StreamOpened, ProbeAccepted, StreamStopped (1788612589), ContractDestroyed (1788612589)	d2ff11b7…	yes, destroyed
2	ContractDeployed (1788612615), StreamFunded, BuyerBondFunded, SellerBondFunded, StreamOpened (1788612782), ProbeAccepted (1788612979)	d8a2c316… (the local buyer note)	no — still OPEN/streaming

Current getters agree: opened=true, probe_accepted=true, finalized_owed=1000000000,
tokens_final=1000000, tokens_pending=1000000, account active.

The receipt itself flags the anomaly under consistency_issues:
destroyed_event_with_active_account, event_after_contract_destroyed,
event_buyer_party_mismatch, event_getter_buyer_mismatch,
terminal_event_current_state_mismatch.

The TokenContract address is deterministic (same 0:17b2d080… reused across the two
deals with different buyer notes), so the historical ContractDestroyed from lifecycle 1
does not make lifecycle 2 terminal.

Root cause

crates/dexdo/src/cli/recover.rs -> exact_prior_stop_receipt:

• collects every ProbeBurned/StreamStopped/StreamDisputed/DisputeResolved across all
  historical events of the address,
• requires exactly one action and one stop in the whole history,
• compares that stop's buyer (beneficiary) to the local buyer note.

The function assumes a TokenContract address hosts at most one deal lifetime. When the
deterministic address is destroyed and re-deployed for a new deal, the old StreamStopped
is treated as the current deal's terminal receipt, the beneficiary check fails, and the
reconciliation refuses — before any state/liveness check of the current lifecycle runs.

Impact

• A buyer with an OPEN, live, correctly-signed deal whose TC address was recycled cannot
  STOP it. The deal's escrow + buyer bond remain locked. Advice given by close/recover
  cannot be acted on.
• reclaim is explicitly not the path (deal is OPEN, probe accepted).
• No flag bypasses this guard in v0.2.1.

Expected behaviour

close/recover should reconcile the terminal receipt against the current deal
lifecycle: e.g. scope terminal-event matching to events after the latest ContractDeployed,
or key the "already terminal" check to the current buyer note/current stream, so a STOP
receipt belonging to a destroyed previous deal on the same address does not poison a live
deal.

Suggested fix direction

• In exact_prior_stop_receipt, split the settlement history at the latest
  ContractDeployed/ContractDestroyed boundary and only consider STOP events of the
  current lifecycle for the terminal-receipt check; or
• match the terminal receipt only if its beneficiary equals the current buyer note AND no
  later ContractDeployed/ContractDestroyed supersedes it; otherwise fall through to the
  normal OPEN-deal STOP path.

[Pithung]

Additional reproduction (2nd independent TC): guard is tripped by any prior STOP-kind event, not only StreamStopped

Confirmed on a second, completely independent TokenContract with the same setup
(v0.2.1, mainnet, contract generation 4.0.36): dexdo close
(and dexdo recover) refuse an OPEN, live, probe-accepted deal whose TC address was
previously used by an earlier deal (destroyed) and then deterministically re-deployed.

Deal: deal-0-894e6f479a8abe5748768cf8c521cb457ea0721644af550123ba19bf5924240b-buyer
(model Qwen3.6-27B), TC 0:894e6f479a8abe5748768cf8c521cb457ea0721644af550123ba19bf5924240b.

dexdo status --json on the handle reads, at close time:
state=streaming active=true opened=true probe_accepted=true,
next.action=stream_stop — i.e. the chain says this deal still needs its buyer STOP.

dexdo settlement-receipt --json 0:894e6f… shows the same two-lifecycle reuse pattern:

lifecycle	events	buyer note	terminal?
1	ContractDeployed (1788595685), StreamFunded, BuyerBondFunded, SellerBondFunded, StreamOpened, ProbeBurned (1788597380), ContractDestroyed (1788597380)	db18de8e…	yes, destroyed
2	ContractDeployed (1788652927), StreamFunded, BuyerBondFunded, SellerBondFunded, StreamOpened (1788663478), ProbeAccepted (1788663673)	d8a2c316… (the local buyer note)	no — still OPEN

Observed error is the same guard firing:

Error: prior terminal receipt beneficiary …0004::db18de8e1c9458b005f07c2ec51c1d172ae51c137b7c706a31873bd416597187
does not match local buyer note …0004::d8a2c3165790b0bfb680cd58c3e36279c7013ed3e755ccb7430a5b076c5a9c9f;
refusing local reconciliation

consistency_issues on the receipt again flags the reuse with
destroyed_event_with_active_account, event_after_contract_destroyed,
event_buyer_party_mismatch, terminal_event_current_state_mismatch.

Key difference / stronger finding: the previous lifecycle's terminal event here is a
ProbeBurned, not a StreamStopped. exact_prior_stop_receipt collects both
(ProbeBurned | StreamStopped) as "stops" across the entire address history, so any
terminal STOP-kind event from a previous lifecycle poisons the current deal's close.
This is not specific to one event kind — it will recur for every repeat buy of the same
model (+ seller) that lands on a reused deterministic TC address.

Money impact now: two buyer deals (17b2d080… and 894e6f47…, ~2 × (deposit 2.05 +
bond 2.00) SHELL of the reporter's escrow) sit OPEN with the buyer note, un-closable by
the shipped v0.2.1 client, and no flag bypasses the guard. Grateful for a release with
the lifecycle-scoped fix; happy to re-test the moment one lands.

[Pithung]

Cross-reference: this is the same deal as #148 (seller side), both parties locked by the same recycled-address receipt

For the maintainers' benefit: #148 by
@Juanant2804 describes the same deal from the seller's side — same TokenContract
0:17b2d0806674147487fa97c31fe3b940139febb37cdc5ff5565b9a4b4f53f735, same model
(gpt-oss-20b), same seller nonce 2026090504, "the external buyer" being the buyer
note of this report.

So the recycled-address guard failure locks both parties of one deal:

• Buyer (this issue): close/recover refuse the buyer STOP — prior terminal receipt beneficiary d2ff11b7… does not match local buyer note d8a2c316….
• Seller (Seller deal stuck #148): close refuses the seller STOP —
  SETTLEMENT_FAILED: action seller_stop is already recorded by exact StreamStopped receipt.

Both errors come from the same stale StreamStopped of the previous lifecycle on the
deterministically re-deployed TC address (previous buyer d2ff11b7). Neither side can
finalize/destroy the deal or release its buyer escrow + seller bond. This is one bug with
a two-sided repro, which should make the lifecycle-scoped fix in exact_prior_stop_receipt
straightforward to validate end-to-end.

[Pithung]

Follow-up: 4 independent repeats, 2 distinct sellers, ±12.1 SHELL buyer escrow locked — plus a known cause

Adding a 4th independent repro and a picture that should make the lifecycle-scoped fix in
exact_prior_stop_receipt unambiguous to validate.

On mainnet (v0.2.1, 846f8e5b, contract gen 4.0.36), the same guard now refuses close on four
buyer deals, all state=streaming active=true probe_accepted=true:

local handle / TC	model	seller_pubkey	seller nonce	max_ticks	prior lifecycle buyer + terminal	now
17b2d080… (this issue)	gpt-oss-20b	0x5430…631ddee	2026090504	64	d2ff11b7… StreamStopped	OPEN, locked
894e6f47…	Qwen3.6-27B	0x6b4c…6e0a55602	207	64	db18de8e… ProbeBurned	OPEN, locked
fb855871…	Qwen3.8-27B	0x6b4c…6e0a55602	208	12	db18de8e… ProbeBurned	OPEN, locked
deff9230…	gpt-oss-20b	0x6b4c…6e0a55602	210	12	db18de8e… ProbeBurned	OPEN, locked

Each locked deal's status accounting reads buyer_locked=3.025 (deposit 1.025 + bond 2.00) and
next=stream_stop; close/recover all fail identically:

Error: prior terminal receipt beneficiary … does not match local buyer note …d8a2c316…;
refusing local reconciliation

The settlement receipts (dexdo settlement-receipt --json) again flag the reuse the same way:
destroyed_event_with_active_account, event_after_contract_destroyed,
event_buyer_party_mismatch, terminal_event_current_state_mismatch.

Two things worth highlighting:

1. It is not one nonce shared across deals. The four deals use per-deal nonces
   (2026090504, 207, 208, 210). The root cause is that each deal's
   (sellerPubkey, nonce) tuple was re-provisioned on a deterministic TC address that a prior
   deal already destroyed — so the prior lifecycle's STOP-kind event (StreamStopped or, notably,
   ProbeBurned) is picked up by exact_prior_stop_receipt as the terminal receipt of the live
   deal. The previous buyer in three of these is the same note (db18de8e…), which also shows this
   is a repeatable, systematic occurrence and not a fluke.

2. Total affected buyer escrow across these four stays locked: 4 × 3.025 = 12.1 SHELL,
   plus the matching seller bonds on each deal. The same sellers are on the other side of the same
   guard (e.g. Seller deal stuck #148 for the 17b2d080… deal) and equally cannot finalize.

Until a lifecycle-scoped release, the practical workaround for sellers is: never re-provision a
(sellerPubkey, nonce) whose deterministic TC was already destroyed — assign a fresh nonce per
deal so the next contract gets a brand-new address without prior STOP events. That also matches the
CLI semantics (--nonce: "must be UNIQUE per deal … a reused/default nonce collides").

Happy to re-test all four the moment a build with the lifecycle-scoped matching in
exact_prior_stop_receipt ships.

[Pithung]

Follow-up: the seller side confirms the recycled-address root cause independently, with a reproducible nonce-reuse case.

@tbuza's reply on #152 (#152 (comment)) confirms this issue's diagnosis from the seller side:

• deal addresses derive from note + nonce, and their supervisor's nonce counter was reset at some point, so the same nonce was issued twice — the deterministic TokenContract address was really recycled between two deals:
  • nonce 210 -> 0:deff9230… provisioned twice (gpt-oss-20b, then Qwen3.6-27B) — one of the three deals listed in dexdo close refuses the stop path its own status recommends: INTERNAL / internal invariant failed on an incompatible prior ProbeBurned receipt #152
  • happened again today: nonce 906 -> 0:2f06463bd139… provisioned twice; the second seller refused to start with a model-identity check that correctly detected the address already belonged to another model
• a never-before-used nonce is unaffected (first use of nonce 906 matched/settled normally) — consistent with lifecycle-scoped guards being the fix
• @tbuza agrees scoping the "already terminal / prior receipt" guards to events after the latest ContractDeployed would resolve all three deals from the seller side

So for the four deals in this issue: the buyer STOP path (close/recover) is blocked by the prior-lifecycle StreamStopped beneficiary mismatch, and the seller STOP path (close) is blocked by the same union-of-lifecycles receipt history. Both parties are frozen on the same contracts, in both directions.

Workaround meanwhile: never reuse a nonce; keep it strictly monotonic above all historical values.

[Pithung]

5th manifestation of the same guard — same-note reuse now takes the "already terminal" noop branch instead of the beneficiary-mismatch refusal

Same root cause as this issue (recycled deterministic TokenContract address, prior-lifecycle
terminal receipt misread as the current deal's), but a different branch of the same guard,
which was not represented in the table above. Worth keeping this issue open for both forms.

On mainnet (v0.2.1, 846f8e5b, contract gen 4.0.36): buyer deal
0:35e8b70e14b8cc360d6e88a1415770a7e9689827f55d2acb553a3635531ccf52 (model Qwen3.6-27B,
seller pubkey 0xa2626a…676b79, seller nonce 7015) refuses close/recover — but with
success exit code:

close noop: TokenContract 35e8b70e…::35e8b70e… is already terminal by immutable receipt
message_id=34457af97efdbc4bd6dc1d64b185ef0664d4cf0341211cac55f5fdc75842dafe created_at=1788952389
event=StreamStopped { buyer: "0:d8a2c316…", to_seller: 2000400000, refund_to_buyer: 3025000000 };
action=unknown …; no second STOP was submitted

dexdo recover and dexdo close (both handle and raw-TC forms) return the same noop;
reclaim correctly refuses OPEN deals and points back to close/recover.

The settlement receipt shows the reason — two lifecycles on one recycled address, with the
same buyer note on both:

lifecycle	buyer	terminal event	terminal?
1	d8a2c316… (same note)	StreamStopped 34457a (1788952389) + ContractDestroyed (1788952389)	yes, destroyed
2 (this deal)	d8a2c316… (same note)	—	no — still OPEN/streaming (funded 1788957140, opened 1788957201, probe accepted 1788957396)

Current getters agree: opened=true probe_accepted=true finalized_owed=1000000000 tokens_final=1000000 tokens_pending=1000000, deposit 1.025 + bond 2 = buyer_locked 3.025.
settlement-receipt flags consistency_issues = [destroyed_event_with_active_account, event_after_contract_destroyed, terminal_event_current_state_mismatch].

Why the two forms differ:

• The four deals listed above have a previous-lifecycle buyer different from the local note
  (d2ff11b7… / db18de8e…), so exact_prior_stop_receipt fails with "prior terminal receipt
  beneficiary … does not match local buyer note …; refusing local reconciliation".
• Here the previous buyer is the local note (d8a2c316…) — the same user bought on the same
  address twice — so the beneficiary check passes, and the guard instead reports
  "already terminal by immutable receipt … no second STOP was submitted" and noops with
  exit 0, silently, although the live deal is still streaming.

So the same unscoped full-history scan produces a hard refusal in one buyer-same-drop and a
silent noop in the other — either way the buyer STOP is never submitted and 3.025 SHELL
(buyer escrow + bond) stays locked. This is directly consistent with the lifecycle-scoped fix
proposed above (only accept a terminal receipt that belongs to the current lifecycle, split at
the latest ContractDeployed). Happy to re-test this deal with a fix build.