Seller's drive_advance silently requires real token delivery before accepting the probe, contradicting dexdo status's own printed guidance

[kevinushana]

Summary

dexdo status's next field for an opened, unaccepted-probe deal prints:

next=seller_advance_probe_after_timeout command="keep dexdo seller running for {deal}; it calls TokenContract.advance() after PROBE_WINDOW" reason=buyer_silent_probe

This strongly implies pure timeout-based silence-equals-consent, which matches what TokenContract.advance() actually allows on-chain (TokenContract.sol: require(block.timestamp >= _prepaidTime + advanceWindow, ...) — no delivery check at all, by design, per the contract's own doc comment: "After SETTLE_WINDOW of buyer silence... accept the probe").

The CLI's actual driver (crates/dexdo/src/seller/advance.rs::drive_advance) does not do this. It gates on real delivered tokens first:

tokio::time::sleep(windows.probe).await;
loop {
    if billed_ticks(delivered.load(Ordering::Acquire), tick_size) >= 1 {
        break; // requires >=1 REAL delivered token
    }
    if delivery_done.load(Ordering::Acquire) || deal_closed(chain, token_contract).await {
        return Ok(0);
    }
    tokio::time::sleep(windows.settle).await; // otherwise loops forever, silently
}
chain.accept_probe(token_contract).await?;

If the buyer never sends a single real inference request through the gateway (for any reason — their own bug, they gave up, they're just testing), this loop sleeps indefinitely with zero log output, making a perfectly healthy, correctly-running seller process indistinguishable from a hung/broken one from the outside. last_advance_unix in dexdo status --json never advances, across any number of seller restarts, for as long as the buyer stays silent.

There is no exposed dexdo subcommand to call advance() directly, bypassing this gate — checked dexdo --help in full, only dexdo seller's embedded daemon logic can trigger it. So the seller has no way to ever force settlement on a deal the buyer opened, funded, and then abandoned, even though the underlying contract explicitly supports exactly that scenario (silence-after-timeout = consent).

This is very likely a deliberate anti-abuse safeguard (protecting the buyer from being charged for content never actually delivered) rather than a pure bug — but the mismatch between it and the CLI's own status message cost significant debugging time to trace to source, since every symptom (healthy process, reachable gateway, zero log output, frozen last_advance_unix) looks identical to a genuinely hung/crashed process.

Environment

• dexdo 0.0.12 (SHA256-verified) and 0.0.14 (fresh download, checksum-verified)
• Network: Shellnet, post the 2026-07-17 restart
• OS: Windows 11

Repro

1. Open/fund any deal as seller (real buyer match, opened=true).
2. Don't send a real request through the gateway as that buyer.
3. Wait well past PROBE_WINDOW (180s) — even hours.
4. dexdo status --json shows last_advance_unix frozen at the funding time indefinitely, probe_accepted=false, with next.action=seller_advance_probe_after_timeout still printed as if it will resolve on its own.
5. Restarting the seller process does not change this — it resumes cleanly (readiness=resumed_funded_tc) but the advance loop restarts in the same blocked state.

Ask

1. Is the delivery-gate intentional (anti-abuse) or an oversight?
2. If intentional, could dexdo status's next message be corrected to not imply pure timeout-based resolution, and/or could the seller log something (even at DEBUG) while waiting in this loop, so it's distinguishable from a genuinely hung process?
3. Is there any seller-side recourse at all for a deal the buyer opened/funded and then never sent traffic to?

[kevinushana]

This looks like a regression, not intentional behavior. @Futurizt's closing comment on #11 describes exactly the recovery path this issue is about, but describes it working differently than the current code:

"the seller has a recovery path: advance. When a buyer matches then abandons, after the on-chain probe window the seller's advance (which the running dexdo seller drives automatically on buyer silence) finalizes the probe to the seller and moves the deal forward... We verified this on live shellnet."

That's pure timeout-based recovery (silence = consent, matching what TokenContract.advance() actually checks on-chain — only onlyOwnerPubkey + a timestamp, nothing about delivery), and it was verified working on v0.0.6. The current drive_advance in crates/dexdo/src/seller/advance.rs requires real delivered tokens before it will call accept_probe/advance at all — checked the commit history on that file and there's been no change since the v0.0.13 tag, so whatever changed between v0.0.6 (working per #11) and now (v0.0.12/v0.0.14, both reproduced broken) looks like an unintentional regression rather than a deliberate design change. Flagging in case this makes the fix more actionable — the intended behavior was already built and verified once.

[kevinushana]

Follow-up with additional confirmation and a live reproduction, from a separate investigation session today.

On-chain confirmation advance() has no delivery requirement. Read TokenContract.sol directly (contracts repo, contracts/airegistry/TokenContract.sol):

/// @notice Seller-only. After `SETTLE_WINDOW` of buyer silence:
///         - in `Probe`: accept the probe (§3.1.2) — finalize the probe tick
///           to the seller, return the commission, charge the fee by-fact,
///           and enter `Streaming` with the two-tick invariant (§3.2);
///         - in `Streaming`: finalize the prepaid tick and roll the invariant
///           (silence = consent, §3.3).
function advance() public onlyOwnerPubkey(_sellerPubkey) accept {
    ensureBalance();
    require(_opened, ERR_NOT_OPEN);
    require(!_disputed, ERR_DISPUTED);
    uint64 advanceWindow = _probeAccepted ? _settleWindow : PROBE_WINDOW;
    require(uint64(block.timestamp) >= _prepaidTime + advanceWindow, ERR_SETTLE_WINDOW_OPEN);
    ...

The only requirements are seller signature + elapsed timestamp. No delivered-token check anywhere in the function. The design intent is explicit in the docstring: "silence = consent." This matches the CHANGELOG history: v0.0.6/v0.0.8/v0.0.9 all shipped fixes explicitly for this exact scenario ("fix: point seller abandoned Probe recovery to advance", "directive: seller guidance on buyer-abandoned deal") — nothing in v0.0.12/13/14's changelog entries addresses it, consistent with the regression already identified in this issue.

Live reproduction today (2026-07-20), two independent real deals, both stuck the same way:

• Seller r1, TokenContract 0:9473d1b10236a40a0dba23a76b42531180b583085c6fd8ee1ada696b0f986394 — funded_time=1784440371, last_advance=1784464216. Stuck in probe_accepted=false for over 24 hours at time of check, seller process running the whole time.
• Seller r3v3, TokenContract 0:d409a3d4efea4372f0d7f709cc1a6c0831f5952c5b0e65c6af30148161a46e28 — funded_time=1784530177, last_advance=1784530707 (~530s after funding), stuck ever since.

Both show dexdo status's own next=seller_advance_probe_after_timeout hint, but the seller process never actually progresses past it — confirming drive_advance never calls the (permission-free) on-chain advance() despite PROBE_WINDOW having long elapsed.

Ruled out available workarounds before filing this:

• close/orders cancel/destroy all correctly refuse an opened deal (seller cannot destroy opened deal) — expected, not a bug, since that's the same on-chain rule as stop()'s buyer-only gate.
• No policy.json seller field exists for this scenario (seller.on only exposes after_deal_done / buyer_no_show / dispute_against_me — none apply to "buyer silent after opening").
• No hidden env var/flag found via binary string extraction on the current dexdo.exe (v0.0.12) that forces an unconditional advance() call.
• Tried running the last confirmed-working release (v0.0.9, official checksum-verified binary, no source build) directly against current chain state as a workaround — it can't even parse the current TokenContract's state (TVM internal error: can not parse actions: 0), presumably due to the fixed-superroot redeploy mentioned in this session's dexdo doctor output. So old binaries aren't a viable workaround either; this needs an actual fix in the current codebase's drive_advance.

Happy to share the two TC addresses above for direct chain inspection if useful.