deploy-market fails with "getter getStats: returned no output message" on 4.0.30 / v0.0.18, even for brand-new never-used model tags

[PromiseMeNot]

dexdo version: 0.0.18

Environment: Android (Termux + proot-distro Ubuntu), shellnet, dexdo doctor passes cleanly (SuperRoot/RootPN/RootOracle/PrivateNote all PASS at 4.0.30).

Steps to reproduce:

1. Fresh PrivateNote deployed and confirmed Active under the new UpdateCustodianMultisigWallet_v2, balance/status verified via dexdo note balance.

2. dexdo provision against the existing shared model qwen--qwen3--32b succeeds (RootModel and TokenContract both deploy and PASS doctor's code-hash check), but dexdo doctor --market <manifest> then reports:

FAIL InferenceOrderBook code hash addr=0:da3568b2c6c609ea942d56f812545e41fe133589c2ca2a0a98f0dc337bcdbbc9
expected=f32d28ead150ba0832456d5f51f51d0e666463100baf27134e083e5fc5159649
actual=96a296d224f285c67bee93c30f8a309157f0daa35dc5b87e410b78630a09cfc7

This IOB address is deterministic from model_hash and predates the 4.0.30 upgrade (created_at=1784097780 per dodex indexer), so it appears the shared order book for this model was never migrated to match the new chain version.

3. To work around the stale shared IOB, tried deploying a brand-new order book under a never-before-used frame_model tag:

dexdo deploy-market
--note-key
--note-addr
--frame-model qwen--qwen3--32b-v430-

This fails immediately with:

Error: getter getStats: returned no output message

Reproduced 3x with different unique frame_model tags (v430, v430b, v430d, v430e) — same error every time, even though each tag has never been used before, ruling out a stale/pre-existing-registry-entry explanation.

4. Tried bypassing model registry validation via --model-registry-validation with a JSON file, but couldn't determine the correct schema from available docs/help text — got "unknown field check_model_registry, expected one of schema, registry, seller, buyer" and then "invalid type: integer 1, expected a string" on subsequent guesses. No example schema is available in --help output.

Question: Is deploy-market currently broken against the 4.0.30 contracts, or is there a required flag/registry setup step that's undocumented? The getStats failure happening before any deploy transaction is submitted suggests a read against a contract that either doesn't exist yet at the expected address, or a getter signature mismatch introduced in the 4.0.30 upgrade.

This is currently blocking me from posting any sell offer under a fresh order book during the final testing window.

[PromiseMeNot]

Update: found a much clearer, reproducible bug on v0.0.18 / shellnet 4.0.30.

My buyer computes a DIFFERENT InferenceOrderBook address than what's actually deployed/active on-chain, for every model tried today. Reproduced 4x across two different models:

• qwen--qwen3--32b: seller-posted book 0:9946bdc532829014289bfad162c3afcfcf43470be2be4739c6d855bb43f11f64 — my buyer instead resolves to 0:f28bf5f4f6f4a2417e54b680513d446609e74a6026900a2773bf01b167571656 ("book not active")
• mistral--mistral-small--x7 (casing verified via dexdo market-data show, confirmed exact model_ref and status=TRADING on their real book 0:af379f544c91a45dd08fdcfb8e0e728643e9e58abd2f7666e442822af848e5bf) — my buyer resolves to 0:6d0d6d31a61b7ef92595674fa39b18e5aa62136f31afbe1bd635a55aa8475e2f instead, again "book not active"

Both times I passed the seller's real TokenContract explicitly via --token-contract, and dexdo still recomputed and preflighted against its own (wrong) IOB address rather than trusting/deriving from the given TC.

This means model_hash → IOB address derivation on my buyer doesn't match what's live on-chain right now, for any model. I'm using the default --contracts (contracts/deployed.shellnet.json shipped with the v0.0.18 release archive) — is that manifest stale, or is there a known mismatch post the 4.0.30 migration? Also relevant: this is on top of the earlier-reported seller-side blocker (stale InferenceOrderBook pin on qwen--qwen3--32b, and deploy-market failing with "getter getStats: returned no output message" on brand-new frame_model tags).

Together these two issues mean I currently can't trade as either buyer or seller against any real order book on the updated chain.

[PromiseMeNot]

Possible root cause found: my local contracts/deployed.shellnet.json (from the v0.0.18 release archive) has:

"model_registry": "0:19a88a103f949df6ce5532a91e935a04acd708872d4bd4e2e5e446d0d78140b9"
"model_registry_after_restart": "0:0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d"

Every "ModelRegistry has(...)" error I've hit points at the first address (0:19a88a10...). Given the doctor output confirms a "fixed-superroot shellnet redeploy" already happened, is the client supposed to be using model_registry_after_restart instead post-restart? Tried to test this via --model-registry-address + --model-registry-validation but couldn't find the correct JSON schema for the validation config from --help alone (RawRegistrySection struct isn't documented). If someone can confirm which registry address is actually live, or share the correct validation JSON shape, that would help pin down whether this explains the IOB-address-mismatch bug reported above.

[PromiseMeNot]

Update: found and fixed a real issue — my local contracts/deployed.shellnet.json was stale (dated July 8, wrong schema, wrong model_registry address). Replaced it with the one bundled in the v0.0.18 release tarball. This fixed the ModelRegistry warnings (no longer showing "ModelRegistry has(...) error=" on buyer runs).

However, the InferenceOrderBook address mismatch persists UNCHANGED even with the correct manifest — my buyer still computes 0:f28bf5f4f6f4a2417e54b680513d446609e74a6026900a2773bf01b167571656 for qwen--qwen3--32b regardless of which contracts.json I use, while multiple sellers' actual live books are at different addresses (e.g. 0:9946bdc532829014289bfad162c3afcfcf43470be2be4739c6d855bb43f11f64). Since the address is byte-identical before and after the manifest fix, this rules out a stale-manifest cause — something else in the IOB address derivation (likely RootModel computation from model_hash) is producing a different result than what sellers' clients compute for the same frame_model string. Happy to share full doctor output / manifest diffs if useful for debugging.

[PromiseMeNot]

Update: fully isolated the InferenceOrderBook address mismatch bug.

Confirmed NOT caused by: stale contracts/deployed.shellnet.json (replaced with the correct v0.0.18 bundled one — fixed ModelRegistry warnings but did not fix this), missing models.json fields (fixed those too, same result), or GROQ_API_KEY setup.

Reproducible minimal case: seller posts a real, live, TRADING order book for meta--llama-3.3--70b at 0:02a09c429baa26dc8c4a50525fd1d683f882082345094fce535ea77a5c2ea6b8 (confirmed via dexdo market-data show/depth — status TRADING, ask_levels=1, 2048 ticks @ 1 SHELL). My buyer, with a fully correct/current contracts manifest and models.json, computes a DIFFERENT address for the exact same frame_model string: 0:c0a61482317036ff379672cd8dca384be0e45b4e7f59267671f7cdb4b3fc9e2a — "book not active."

This is 100% reproducible across every model tried today (qwen--qwen3--32b, mistral--mistral-small--x7, meta--llama-3.3--70b) — always a DIFFERENT computed address than what's actually live, never matching. Something in the client's model_hash → IOB address derivation is producing a different result than what sellers' clients (also v0.0.18) compute for the identical frame_model string. Since both sides report using v0.0.18, this may be a nondeterminism bug in the hash/address derivation itself (e.g. depending on a byte order, encoding, or a field not being normalized consistently).

This is currently the sole blocker preventing me from buying against ANY live seller today, despite multiple confirmed-live offers.