Deals matched against --allow-private-advertise sellers get permanently stuck in probe for remote buyers

[Ashukran]

A seller running dexdo seller --allow-private-advertise --gateway-advertise 127.0.0.1:PORT (or default loopback) can post offers that are matchable by any buyer on the network — including buyers who are not on the same machine/LAN. Once matched, the deal is funded and enters state=probe, but a remote buyer has no way to reach the seller's loopback-only gateway to trigger delivery. The deal has no natural resolution path: the buyer's client can't connect, and the seller has no automatic timeout — only a manual sellerStop/close, which returns the buyer's escrow without them ever receiving what they paid for.

Repro:

Seller runs dexdo provision + dexdo seller --allow-private-advertise --gateway-advertise 127.0.0.1:PORT for a model.
A different buyer (different machine, or via the dex.acki.pro portal) matches the offer and funds the deal.
Deal reaches state=probe, funded=true, opened=true.
Buyer's client (or the portal, which has no inference client at all) cannot reach 127.0.0.1:PORT from outside the seller's own machine.
Deal remains in probe indefinitely — probe_accepted=false, tokens_final=0 — with no automatic resolution.

Suggested fixes (any of):

Reject/flag --allow-private-advertise offers from being purchasable by buyers outside the seller's own local network, at the order-book level.
Have dex.acki.pro warn buyers or refuse to let them buy offers whose advertised gateway is a private/loopback address.
Add a probe-window timeout that automatically resolves a stuck deal (refund or partial settlement) after a bounded period, rather than requiring manual seller intervention indefinitely.

[tbuza]

Data point from the seller side (v0.3.0, mainnet, five sellers on one note, 0:a4bf8ba7…): this is not limited to loopback-advertised sellers — it happens to a public gateway as soon as the buyer has no client.

In the 24 h to 2026-09-13 07:00Z, 17 funded deals never connected: probe_accepted=false, tokens_final=0, and on our side no delivery request ever reached the gateway (no probe_decision event is logged for any of them, while every deal that did stream has one). They came from five buyer notes — 0:bd406c12… ×9, 0:d8a2c316… ×4, 0:43a420d2… ×3, 0:eb4121f2… ×1 (leaderboard rank 1), 0:bca147fb… ×1 — across all five of our books, at 1 and at 5 SHELL/tick. In the same window the same seller processes served two real client buyers normally.

Our gateway is public (--gateway-advertise 173.212.229.10:844x) and passes gateway-check end to end with the served certificate's fingerprint:

gateway=https://173.212.229.10:8448 PASS stage=dns_resolve PASS stage=tcp_connect PASS stage=tls_handshake
PASS stage=http2_handshake PASS stage=grpc_challenge PASS stage=challenge_response

What it costs the seller: the deal has no exit except the seller's own close (sellerStop), and that forfeits half the seller bond — the receipt shows StreamStopped toSeller = price on a 2 × price bond, while refundToBuyer returns the buyer's escrow and bond in full. So every click-and-walk costs the seller exactly price (or price via ProbeBurned when the window lapses first), and the buyer nothing. That makes a cheap book a free target.

The third suggestion in the issue — a bounded probe window that resolves the deal on chain, returning both parties' funds — would end this for public and loopback sellers alike; refusing portal purchases that have no client behind them would stop it at the source. Happy to share the 17 TokenContract addresses.

[Pithung]

Buyer-side data point (reproduced on mainnet, plus a deal that is stuck right now)

Data point from the buyer side, reproducing the same flow as the issue describes.

1. Buyer flow: matched a rested offer from a public-gateway seller, funded and opened the deal, then sent nothing — no inference request, no keepalive. On the seller's side the seller process is stuck looping on offer rested -- waiting for a buyer forever, because no delivery request ever arrives and nothing advances the contract.

2. On-chain snapshot of a deal in that state right now (2026-09-17):

TC 2bac7c6743…53  model=Qwen3.8-27B  price=5 SHELL/tick  max=2 ticks
state=probe  funded=true  opened=true  probe_accepted=false  disputed=false
buyer_locked=20.25  deposit=5.25  probe_tick=5  buyer_bond=10  bond_required=0
finalized_ticks=0  tokens_final=0  tokens_pending=0
funded_at=1789569857  probe_time=1789569905

Note on the bonds: both parties post a mirror bond of 2 × price (_bondAmount()), so at this price each side has posted 10 SHELL — buyer via fundBuyerBond, seller via fundDeal. buyer_bond above is the buyer's own bond and sits inside buyer_locked; the seller's 10 SHELL bond is separate. When the seller is eventually forced to close, it is the seller bond that burns (StreamStopped toSeller = price from a 2 × price bond), while refundToBuyer returns the buyer's escrow and bond in full.
No delivery request ever reached the gateway. The deal has sat in state=probe with probe_accepted=false for 11+ hours with no automatic resolution.

3. What each party gets when the seller finally stops: settlement returns refundToBuyer in full (buyer escrow + bond), while the seller's side takes StreamStopped toSeller = price from a 2×price bond — the exact asymmetry in the previous data point. The buyer paid nothing, keeps any points/credit the platform granted for the funded+opened purchase, and the seller carries the loss. A cheap book is thus a standing free target.

Reproduction cost: a default buyer client that just funds+opens and walks away; nothing more is needed. A bounded on-chain probe window that auto-resolves stuck deals (refunding both sides) is what would actually end this for public and loopback sellers alike.