`provision` deploys a TokenContract with deposit=0 despite --deposit-shells, no local deal handle written, seller logs fresh_sell_submit=unresolved

[Dastic2u]

Environment

• dexdo 0.2.1 (846f8e5b, 2026-09-04T20:02:55+03:00)
• network: mainnet, endpoint https://dd-mainnet.ackinacki.org/
• dexdo doctor passes clean: generation manifest 4.0.36, chain 4.0.36, all contract code hashes matched (SuperRoot/RootPN/RootOracle/PrivateNote), no warnings.

Summary

Repeated dexdo provision --deposit-shells <N> calls (N always a real, nonzero, affordable value, confirmed in the app UI before submit) deploy a TokenContract that lands on-chain with deposit=0. The order is sometimes never posted (authoritative_state=vacant) and sometimes genuinely posted and resting on the book — either way the deal can never actually execute since it has no ECC[2] reserve. This happened 5 times in a row in one session, with no successful provision in between.

Reproduction

1. dexdo note balance confirms plenty of both spendable trading balance (bond source) and ECC[2] gas pocket (deposit source) before every attempt.
2. Run, e.g.:

   dexdo provision --frame-model DeepSeek-V4-Flash --nonce <unix-ts> \
     --price-per-tick 10 --max-ticks 4 --deposit-shells 15 \
     --output market_a.json --policy policy.json --note-addr <note> \
     --non-interactive --no-color
   

3. Command exits 0, market_a.json is written with a real token_contract address.
4. dexdo status <token_contract> (raw address — see below) reports:

   state=placed active=true funded=false opened=false deposit=0
   

5. In several of the 5 reproductions, no local deal-handle file was ever written under %APPDATA%\gosh\dexdo\data\deals\ for the new token_contract — dexdo status deal-0-<tc>-seller fails with invalid address: expected 64 hex digits, forcing a fallback to querying the raw token_contract address directly (which does work and confirms deposit=0).

Directly observed failure log (from a dexdo seller run against a stale/reused manifest)

token_contract=a6a9538b7494170c50c9071d6e40a1dd7963914835d83f6bf94d2680c066e5ce::a6a9538b7494170c50c9071d6e40a1dd7963914835d83f6bf94d2680c066e5ce
disposition="unknown_failure"
known_result=fresh_sell_submit=unresolved; authoritative_state=vacant; budget_ms=60000;
operator_action=list this note's resting orders with `dexdo orders list`, then cancel the exact resting order by hand: run `dexdo orders cancel` with its order id, the same --note-addr and --market or --model this seller was started with, plus --note-key to sign, then verify the book
process exited (4294967295)

This suggests the deposit-funding step (and/or the local bookkeeping write) races against a 60-second confirmation budget and silently no-ops on timeout, while the TokenContract deploy itself has already gone through.

Impact

• No funds are lost (bond and deposit gas are never actually spent when this happens — confirmed via note balance before/after every one of the 5 reproductions), but every attempt burns the small unrecoverable deploy-gas remainder, and a seller has no reliable way to post a real, executable ask right now.
• When the order does end up resting (not always vacant), it sits on the public order book completely unexecutable, which is confusing for buyers browsing the market.

Suggested fix direction

• provision (and seller's own internal re-post-on-startup path) should not report success / write the manifest unless the deposit-funding transaction is independently confirmed, not just the deploy.
• If the local deal-handle write can fail independently of the on-chain deploy, status/close should accept the bare token_contract address as a first-class target without needing --role disambiguation (currently returns next=unknown_role pass_local_handle_or_--role, which is workable but undocumented as the recovery path for this exact case).