[v0.0.18 / Shellnet 4.0.30] Failed dead-gateway probe debits one buyer tick and leaves finalized_owed with probe_accepted=false

[AndreaMangraviti]

Summary

On live Shellnet 4.0.30 with dexdo v0.0.18, a buyer matched a valid ask and received the handover, but the first inference request failed with HTTP 502 because the seller gateway could not open the upstream connection.

The buyer subsequently submitted streamStop successfully. All remaining escrow was released and buyer_locked returned to zero, but the buyer PrivateNote balance decreased by exactly one tick (10 SHELL), while the residual TokenContract reports:

• probe_accepted=false
• finalized_owed=10 SHELL
• buyer_locked=0
• deposit=0
• prepaid=0
• frozen=0

This appears to mean that the failed probe tick was finalized as owed, rather than being burned to no one, despite no inference being delivered.

This report is related to the accounting questions previously discussed in #42, but it is a new by-fact reproduction on the current network and current CLI generation.

Environment

• OS: Windows
• Network: Shellnet
• dexdo CLI: v0.0.18
• SuperRoot: 4.0.30
• RootPN: 4.0.30
• RootOracle: 4.0.30
• dexdo doctor: PASS
• Policy: OK
• Shellnet endpoint: reachable
• Local clock skew: 1 second
• PrivateNote code hash:
  4712999eb88c096fef770755b21d3b6b3fde724967424a928507a5499767e812
• Expected PrivateNote code hash:
  4712999eb88c096fef770755b21d3b6b3fde724967424a928507a5499767e812

Buyer PrivateNote

PrivateNote:

0:c16cebdfbc451bbddc0d140700fea98f5171e41ed7f0147bfd13e594a40cce7d

The PrivateNote was active, current-generation, and had no reported order lock before the purchase.

Authoritative ECC[2] spendable balance captured immediately before the buyer invocation:

81 SHELL

Authoritative ECC[2] spendable balance captured after streamStop and cleanup:

71 SHELL

Observed net debit:

10 SHELL

The net debit is exactly one tick.

Market and selected ask

frame_model:

qwen--qwen3--32b

order_book:

0:9946bdc532829014289bfad162c3afcfcf43470be2be4739c6d855bb43f11f64

order_id:

160

TokenContract:

0:45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40

Requested ticks:

2

Price per tick:

10 SHELL
raw: 10000000000

Quote accounting:

• total_without_fee: 20 SHELL
• platform_fee: 0.5 SHELL
• total_with_fee: 20.5 SHELL

Raw quote accounting:

• total_without_fee: 20000000000
• platform_fee: 500000000
• total_with_fee: 20500000000

The quote was complete and selected the explicit TokenContract successfully.

Buyer invocation

The buyer was started with the equivalent of:

dexdo buyer
--note-key
--note-addr 0:c16cebdfbc451bbddc0d140700fea98f5171e41ed7f0147bfd13e594a40cce7d
--frame-model qwen--qwen3--32b
--token-contract 0:45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40
--allow-unverified-model
--models <LOCAL_MODELS_JSON>
--continuity-mode on-demand
--ticks 2
--max-price-per-tick 10000000000
--local-listen 127.0.0.1:18081
--contracts contracts/deployed.shellnet.json
--json

No secret key, seed phrase, API key, or Telegram credential is included in this report.

Observed buyer lifecycle

The buyer emitted the following lifecycle sequence:

1. starting
2. endpoint_binding
3. endpoint_ready
4. quote_selected
5. buy_submitted
6. matched
7. handover_waiting
8. handover_received
9. inference request attempted
10. inference failed with HTTP 502
11. post-inference streamStop submitted

Relevant timing:

• endpoint_ready: approximately 1.9 seconds
• quote_selected: approximately 24.5 seconds
• buy_submitted: approximately 49.1 seconds
• matched: approximately 52.0 seconds
• handover_received: approximately 62.8 seconds
• inference request completed with failure: approximately 192.8 seconds
• streamStop submitted: approximately 195.7 seconds

Inference failure

The local OpenAI-compatible endpoint returned:

HTTP 502

Response:

{
"error": {
"message": "upstream open failed after retry: transport error",
"type": "invalid_request_error"
}
}

The CLI also logged that the upstream open failed and was retried once according to:

dead_gateway=retry_then_reclaim

The retry did not produce a usable inference response.

No inference content was delivered to the buyer.

Post-inference close

The buyer-side close completed with:

{
"schema": "dexdo.close.v1",
"network": "shellnet",
"handle": "deal-0-45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40-buyer",
"role": "buyer",
"token_contract": "0:45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40",
"action": "streamStop",
"submitted": true,
"terminal": false,
"reason": null,
"state_before": "probe",
"state_after": "stopped",
"tx": null
}

Current on-chain status

Command:

dexdo status 0:45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40
--contracts contracts/deployed.shellnet.json
--json

Current output:

{
"schema": "dexdo.status.v1",
"network": "shellnet",
"token_contract": "0:45a7cc371ccdb44875d7775507b5e53c3a55f07fa7a08794b24c40e2cbd32f40",
"frame_model": null,
"state": "funded-but-never-opened",
"active": true,
"funded": true,
"opened": false,
"disputed": false,
"probe_accepted": false,
"accounting": {
"finalized_owed": "10000000000",
"buyer_locked": "0",
"deposit": "0",
"prepaid": "0",
"frozen": "0",
"last_advance_unix": 1785357545,
"funded_time_unix": 1785357532
},
"next": {
"action": "unknown_role",
"retryable_after_unix": null,
"command": "close"
}
}

Accounting reconciliation

Buyer balance before:

81 SHELL

Maximum quote/escrow:

20.5 SHELL

Buyer balance after stop and cleanup:

71 SHELL

Net buyer debit:

10 SHELL

Escrow returned or released:

10.5 SHELL

The 10 SHELL debit corresponds exactly to one probe tick.

At the same time, the TokenContract reports:

finalized_owed=10 SHELL

This is the point that needs clarification. A probe burn and a finalized seller entitlement are materially different accounting outcomes.

Expected behavior

Based on the documented probe-and-burn protection:

• the buyer may risk at most one probe tick;
• when a seller fails model/content/gateway verification, the seller should earn nothing;
• the seller commission/stake and buyer probe should be burned according to the applicable failure path;
• all remaining buyer escrow should be refunded;
• the final state and accounting fields should make it clear whether the probe was burned, refunded, or finalized to the seller.

If a dead gateway after handover is intentionally classified differently, the CLI should expose that classification and the resulting accounting consequence explicitly.

Actual behavior

• The seller gateway failed to deliver inference.
• The buyer received HTTP 502 after the configured retry.
• streamStop was submitted during the probe phase.
• probe_accepted remains false.
• The buyer lost exactly one probe tick.
• finalized_owed equals that same probe tick.
• The residual TokenContract remains active in funded-but-never-opened.
• No buyer funds remain locked.

Why this may be a regression

Issue #42 discussed the distinction between:

• a buyer probe tick burned from internal escrow; and
• a note-level debit or seller entitlement.

The current reproduction is on dexdo v0.0.18 and Shellnet 4.0.30 and includes an exact ECC[2] before/after delta.

Unlike the previously described bounded-burn behavior, this TokenContract exposes finalized_owed equal to the buyer's lost probe tick after a dead-gateway failure.

Impact

If finalized_owed is withdrawable by the seller, a seller with a dead or unusable gateway may still earn one tick per failed buyer attempt.

That would weaken the intended anti-abuse property that an invalid seller earns nothing and loses its stake.

Even if finalized_owed does not represent a seller-withdrawable entitlement in this state, the current status schema is ambiguous enough to prevent reliable accounting and automated risk classification.

The residual state is also internally confusing:

• the buyer lifecycle reached handover_received;
• the close was submitted from state_before=probe;
• the current status reports funded-but-never-opened;
• finalized_owed is non-zero;
• opened=false and probe_accepted=false.

Questions

1. Is finalized_owed=10 SHELL expected when the first inference request fails with a dead-gateway HTTP 502 and probe_accepted=false?
2. Does finalized_owed in this state represent an amount the seller can actually withdraw?
3. Was the buyer's 10 SHELL probe tick burned, transferred to the seller, or retained by the TokenContract?
4. Should dead_gateway=retry_then_reclaim eventually produce a ProbeBurn/BurnBoth outcome rather than finalized_owed?
5. Why does the final status report funded-but-never-opened after matched and handover_received were emitted?
6. Is streamStop the correct buyer action for this failure, or should the CLI have submitted a dispute or another failure-specific transition?
7. Should the CLI emit an authoritative terminal settlement receipt showing:
   • probe debit;
   • seller entitlement;
   • platform fee charged/refunded;
   • buyer refund;
   • burned amount;
   • residual TokenContract balance?
8. Is this a regression from the bounded-burn behavior discussed in settlement says BurnBoth(ProbeBurn{buyer:N}) but the buyer note is refunded ~in full on probe-phase close — is the burn label or the refund correct? #42?
9. Can the residual TokenContract be safely destroyed or cleaned up without changing the already-finalized buyer accounting?

Requested outcome

Please confirm the intended accounting semantics for this failure path and whether finalized_owed is correct.

If this is unintended, the buyer failure policy should ensure that a dead gateway cannot leave a seller entitlement after no inference was delivered.

If it is intended, dexdo status and the buyer terminal output should clearly distinguish:

• funds still locked;
• funds refunded;
• probe tick burned;
• probe tick finalized to seller;
• platform fee retained or refunded;
• residual seller/protocol cleanup state.

[AndreaMangraviti]

Additional control case: successful HTTP 200 inference shows the same inconsistent residual state

I captured a second by-fact on the same environment that is useful as a control case.

Unlike the original dead-gateway reproduction, this purchase successfully returned inference with HTTP 200. The accounting result appears reasonable: only one tick was actually finalized because the buyer issued one short inference request, while the second reserved tick remained unused and was refunded.

However, the residual TokenContract status is still internally inconsistent with the observed buyer lifecycle.

Environment

• dexdo CLI: v0.0.18
• Network: Shellnet 4.0.30
• dexdo doctor: PASS
• PrivateNote code hash: current and verified
• Buyer PrivateNote:
  0:c16cebdfbc451bbddc0d140700fea98f5171e41ed7f0147bfd13e594a40cce7d

Purchase

• frame_model: qwen--qwen3--32b
• ticks requested: 2
• price_per_tick: 1 SHELL
• maximum quote total: 2.05 SHELL
• TokenContract:
  0:cc00653f588cf233257b5df2c727c3b4fa51359c34ce6a0013f810110ae2570e

Observed buyer result

The buyer completed the executable path successfully:

• quote selected
• buy submitted
• matched
• handover received
• inference request completed
• HTTP status: 200
• buyer close/cleanup completed
• buyer_locked returned to 0

Only one short inference request was issued.

PrivateNote reconciliation

Authoritative ECC[2] spendable balance before the buy:

31 SHELL

Authoritative ECC[2] spendable balance after completion:

30 SHELL

Net debit:

1 SHELL

This matches one finalized tick. The second reserved tick and unused quote capacity were released.

Current TokenContract status

Command:

dexdo status 0:cc00653f588cf233257b5df2c727c3b4fa51359c34ce6a0013f810110ae2570e
--contracts contracts/deployed.shellnet.json
--json

Output:

{
"schema": "dexdo.status.v1",
"network": "shellnet",
"token_contract": "0:cc00653f588cf233257b5df2c727c3b4fa51359c34ce6a0013f810110ae2570e",
"frame_model": null,
"state": "funded-but-never-opened",
"active": true,
"funded": true,
"opened": false,
"disputed": false,
"probe_accepted": false,
"accounting": {
"finalized_owed": "1000000000",
"buyer_locked": "0",
"deposit": "0",
"prepaid": "0",
"frozen": "0",
"last_advance_unix": 1785362292,
"funded_time_unix": 1785362275
},
"next": {
"action": "unknown_role",
"retryable_after_unix": null,
"command": "close"
}
}

Why this control case matters

The one-tick debit itself appears expected: two ticks were reserved, but only one inference operation was consumed and finalized.

The unexpected part is the final lifecycle projection:

• inference was successfully returned with HTTP 200;
• the buyer necessarily received a usable handover and reached the seller stream;
• finalized_owed is non-zero;
• nevertheless, status reports state=funded-but-never-opened;
• opened=false;
• probe_accepted=false;
• frame_model=null;
• active=true.

This is substantially the same residual-state shape observed in the failed dead-gateway case, even though the application-level result is the opposite.

The comparison suggests that the accounting transition may complete while the status projection loses or resets the historical open/probe state during buyer close or seller-side residual cleanup.

Questions

1. Is state=funded-but-never-opened expected after a successful HTTP 200 inference?
2. Should opened or probe_accepted remain true once a probe/inference was successfully served and one tick was finalized?
3. Is dexdo status showing only the current post-close fields rather than the historical lifecycle reached by the deal?
4. Should the terminal status schema distinguish:
   • never opened;
   • opened and probe failed;
   • opened and probe succeeded;
   • inference served and partially consumed;
   • buyer finalized but seller cleanup still pending?
5. Why does frame_model become null for this residual TokenContract?
6. Is the remaining active=true state exclusively a seller/protocol cleanup concern?
7. Could a versioned terminal settlement receipt preserve the authoritative lifecycle and accounting result after mutable TokenContract fields are reset?

This successful control case indicates that the original issue may contain two separate concerns:

1. accounting semantics for a failed dead-gateway probe; and
2. an unreliable or ambiguous post-close lifecycle projection in dexdo status.

The second concern reproduces even when inference succeeds.

[Futurizt]

This is an exceptionally good report -- the exact before/after ECC[2] balances, the full quote breakdown and the control case are what make it answerable. Taking your two concerns separately, because they have opposite answers.

1. The accounting is correct. No seller entitlement was created.

Direct answers to your numbered questions:

Q1, Q2, Q3. finalized_owed = 10 SHELL is expected here, and it is not payment for your probe tick. It is the seller's own bond being returned to it, minus the slice that was destroyed. On a probe-phase stop() with probe_accepted=false the contract destroys your probe tick together with a mirrored tick of the seller's bond -- neither side keeps either -- releases your bond, refunds the remaining deposit, and charges no platform fee on a tick nobody was paid for. What lands in finalized_owed is the unburned remainder of the bond the seller posted with its own money. So yes, the seller can withdraw it, and no, it did not earn it: it is getting back what it put up, less a tick.

Your own arithmetic confirms this exactly. Escrow 20.5 SHELL; 10.5 returned; net debit 10.0. That is one tick burned, one tick refunded, and the 0.5 platform fee refunded in full. If the probe had been paid to the seller, the fee would have been charged.

Q4. It already is the ProbeBurn outcome. dead_gateway=retry_then_reclaim followed by streamStop during the probe is precisely the path that produces it, and the contract emits a ProbeBurned event recording the burned probe, the burned bond and the refund.

Q6. Yes, streamStop was the correct action. It is the buyer-only exit that triggers exactly this settlement. A dispute would have been the wrong tool and would have cost you more.

Q8. Not a regression. This is the bounded burn from the earlier discussion, working as designed. The anti-abuse property you were checking holds: a seller with a dead gateway earns nothing and pays a tick of its own bond for the attempt.

Q9. Yes. Your side is final -- escrow refunded, nothing locked. The residual holds only the seller's withdrawable bond remainder; the seller withdrawing and destroying it cannot change your accounting.

One honest limit on how far we checked: this is read from the contract source and the shipped contract interface, including for the 4.0.30 generation you tested, where the probe-burn event and bond model are identical. We did not decompile the deployed bytecode. If you want a by-fact check on a future deal, the ProbeBurned event on the TokenContract carries the three numbers directly.

2. Your second concern is real and is not fixed.

Your control case is the sharper report of the two, and you are right about it. dexdo status projects the TokenContract's current flags, not the lifecycle the deal reached. The contract clears opened on every terminal path, so a deal that opened, served a real HTTP 200 completion and settled one tick reads back exactly like one that was never opened. The label set has not changed and still separates "never opened" from "opened then closed" only by whether escrow has drained -- which is why both of your deals land in the same bucket despite opposite outcomes. Terminal evidence is now retained in v0.0.20, but only on the close and recover paths; status does not surface it, so the specific complaint you filed is unaddressed. Keeping this issue open for it.

Two smaller corrections in your favour:

• frame_model: null is not lost chain data. It comes from the local deal-handle file and is null whenever a deal is addressed by raw token contract, as yours was. Nothing was dropped on-chain.
• Your suggestion in Q7 -- a versioned terminal settlement receipt that survives the mutable fields being reset -- is exactly the right shape, and it is tracked as its own request in feat: expose a versioned verifiable terminal settlement receipt for buyer deals #104.

Thank you for filing this as an accounting question with a reconciliation rather than as a loss report. It is why the answer could be definite.

[Futurizt]

Read this against the 4.0.35 TokenContract.sol rather than against the release notes. Your environment was 4.0.30 — five contract generations back — and the specific thing you objected to is now written the other way round. Details, because you gave by-fact numbers and deserve the same.

What you objected to

This appears to mean that the failed probe tick was finalized as owed, rather than being burned to no one, despite no inference being delivered.

That reading was right, and it is the branch that changed. On 4.0.35, stop() with probeAccepted == false:

if (!_probeAccepted) {
    uint128 bondBurn = _probeTick <= _sellerBond ? _probeTick : _sellerBond;
    uint128 burned   = _probeTick + bondBurn;
    _releaseBuyerBond();
    uint128 refund   = _deposit;
    _sellerBond -= bondBurn;
    _finalizedOwed += _sellerBond; _sellerBond = 0;
    _probeTick = 0; _deposit = 0;
    _opened = false;
    _burnShell(burned);
    if (refund > 0) { _payShell(_buyer, refund); }

The trial tick is burned, not paid — _burnShell(_probeTick + bondBurn) — and a mirror tick of the seller's bond burns with it. The contract states the intent in its own comment: "a seller who set out to take the first tick and disappear collects nothing and pays a tick for the attempt." No fee is charged on a tick nobody was paid for.

So the money no longer moves to the seller. Your dead-gateway seller now loses exactly what you lost.

What will still look the same, and why it is not the same

Two things in your capture would recur on 4.0.35, and I want to name them before you read your next dexdo status and conclude nothing changed:

1. Your note still goes down by one tick. The trial costs the buyer a tick whether or not the gateway answered. What changed is the destination: nobody, instead of the seller.
2. finalized_owed is still non-zero with probe_accepted=false. But it now means the rest of the seller's own bond returning to him as a debt (_finalizedOwed += _sellerBond), not your tick. Same field, different money.

That the two-sided burn is the rule and not an accident is deliberate: it stops a buyer from claiming a bad trial to get a free look, and it makes a seller with a dead gateway pay for it. Whether one tick is the right price for a trial that returned HTTP 502 is a question about the economics rather than about a defect, and it is not mine to change unilaterally — if you want to argue the price, argue it and I will carry it, but I will not present it as a bug when the contract is doing what it says.

What I need before closing

One reproduction on 4.0.35 with v0.0.23: the same dead-gateway path, and dexdo status on the residual TC. If probe_accepted=false and the seller's side shows the mirror burn, this is closed by the contract upgrade. If your tick still reaches the seller, then the branch above is not doing what it reads like and I want to know that immediately — it would be a live money defect and it would go to the front of the queue.

Your control case with the HTTP 200 purchase is the more interesting half of the thread and I have not answered it here; it is a different branch (_probeAccepted == true) and deserves its own reading rather than being folded into this one.

[Futurizt]

Closing with a verdict on both halves, and with what changed for each.

Half one — the accounting. Answered by the contract, at 4.0.35

Your reading was right about what you saw and wrong about who ends up with the money, and that distinction is the whole answer.

On 4.0.35 a probe tick taken by a gateway that never delivers is burned, not paid. TokenContract._burnShell(_probeTick + bondBurn) is the settlement branch for !_probeAccepted: the seller who set out to take the first tick and disappear collects nothing and pays a tick for the attempt. finalized_owed showing 10 SHELL is the residual record of that tick, not a claim the seller can draw.

Your run was on 4.0.30, where that branch did not exist in this form. That is why the number looked like an unpaid debt.

Half two — the label. Fixed in the client

You reported a stopped deal being shown as funded-but-never-opened. That was real: the summariser reached the "funded but never opened" arm before it asked whether the deal had been stopped.

The order is now the other way round — crates/dexdo/src/cli/deals.rs:215 tests state.is_stopped() before :218 can produce FundedButNeverOpened. A stopped deal is labelled stopped.

If you still see it

Reopen with the same detail on 4.0.35 and we will treat it as a live defect rather than a version gap. Your report is what made both halves visible, and the first half changed the contract's settlement reading, not just ours.