`markets address` cannot distinguish a deployed order book from a derivable address for one that does not exist (see correction in comments)

[tbuza]

Version: v0.2.0 · mainnet, generation 4.0.36 · x86_64 Linux

dexdo model-registry reads 10,957 registered models off chain. The indexer's own market list
returns 18:

$ curl -s 'https://indexer.dex.do/api/v1/inference/markets?limit=200' | jq '.markets|length'
18

gpt-oss-safeguard-20b   GLM-5.3-Flash    GLM-4.5           gpt-5.6-terra
gpt-oss-20b             Qwen3.8-27B      gpt-oss-120b      nwm
Qwen3.6-27B             Jamba-tiny-random                  qwen3.8-max
qwen--qwen3.8--27b--fp8 zai-org/GLM-4.5  xai-org--grok--4.5
openai--gpt-5.6--luna   openai--gpt-5.6--sol  openai--gpt-5.6--terra   qwen--qwen3--32b

All 18 report status: TRADING. Six of them have ever seen a trade; total lifetime volume across
the whole exchange is ~138 trades.

The gap this leaves

markets address answers for a model with no book, and answers in exactly the same shape as for a
model that has one:

$ dexdo markets address --model gemini-3.6-flash --json
{"schema":"dexdo.markets_address.v1","network":"mainnet","requested_model":"gemini-3.6-flash",
 "registry_model":"gemini-3.6-flash",
 "model_hash":"0xcf27b68ecf3890286c2922bbe05c9858f24b71c8e015dedb126e9a99c573d8be",
 "order_book":"0000…0004::18d24b28378d9f5452a3ee2836d309ff9e97521a7ca7cf67a042d9f1744632c0"}

The address is canonical and derivable, so the command is not wrong. But the indexer then 404s that
same book:

$ curl -s -o /dev/null -w '%{http_code}\n' \
  'https://indexer.dex.do/api/v1/inference/orders?inferenceOrderBookAddress=0:18d24b28378d9f5452a3ee2836d309ff9e97521a7ca7cf67a042d9f1744632c0&limit=1'
404

There is no flag, subcommand or documented transaction that takes an operator from "registered
model + canonical address" to "book that accepts postSellOffer". dexdo markets --help is
explicit that the whole namespace is "read-only discovery", and no other verb mentions creating a
book. So a seller who is ready to serve a registered model has no action available.

Consequence for supply. We run five gateways and we are four of the five busiest books on the
exchange. We hold working API keys for models that are registered and that we could serve today —
gemini-3.6-flash, gemini-3.5-flash, gemini-3.1-flash-lite, gemini-3.5-flash-lite,
gemma-4-31b-it all return 200 for us — and none of them can be listed. Meanwhile the registry
advertises 10,957 models to anyone reading it as though they were a menu. A buyer who wants
Llama-3.3-70B-Instruct finds it registered, finds an order-book address for it, and finds nothing
behind that address.

Asks, in order of preference

1. Make book creation reachable from the client — a markets open --model <name> (or the same
   thing as a side effect of the first provision against a bookless model), with the deployment
   cost stated up front. Permissionless would be ideal; gated-but-documented would still unblock us.
2. If book creation is intentionally curated, say so — in markets --help and in the
   markets address output. Right now nothing distinguishes a live book from a derivable address
   for a book that does not exist, and that is the part which actually costs operators time.
3. In the meantime, please deploy books for: Llama-3.3-70B-Instruct, Qwen3-32B,
   DeepSeek-V3, GLM-4.5-Air, gemini-3.6-flash, gemma-4-31b-it. We will list asks on each of
   them; the first four are the names buyers ask for by brand, and we have supply ready for all six.

Smaller, related

markets address could carry the answer itself — a "deployed": true|false field, or a
"status" mirroring the indexer's — so a caller can tell the two cases apart in one read instead of
resolving an address and then discovering by 404 that it is not a market.

[tbuza]

Correction from the reporter: the main premise of this issue is wrong, and I should have read provision --help more carefully before filing.

dexdo provision already deploys the order book. Its own first line says so:

Provision: bring up the InferenceOrderBook + RootModel + per-deal TokenContract for a market -- all note-funded from the seller note's own ECC[2]

and --allow-unverified-model spells out the consequence for a name that does not resolve:

the order book, RootModel and TokenContract deployed for it are paid for and can never trade

So there is a path from "registered model" to "tradeable book", it is provision, and it is available to any operator with a funded note. Apologies for the noise — ask 1 and ask 3 in the issue above are already satisfied.

What I think still stands, and is the reason I misread it: markets address gives no way to tell a deployed book from a merely derivable address.

$ dexdo markets address --model gemini-3.6-flash --json
{"schema":"dexdo.markets_address.v1","network":"mainnet","requested_model":"gemini-3.6-flash",
 "registry_model":"gemini-3.6-flash",
 "model_hash":"0xcf27b68ecf3890286c2922bbe05c9858f24b71c8e015dedb126e9a99c573d8be",
 "order_book":"0000000000000000000000000000000000000000000000000000000000000004::18d24b28378d9f5452a3ee2836d309ff9e97521a7ca7cf67a042d9f1744632c0"}

That response is identical in shape to one for a book with a live market, but the indexer 404s this address, because no book is there yet. A "deployed": true|false field would have told me in one read what cost me a wrong issue — and, more usefully, tells a seller whether their next provision also pays to bring up an IOB and RootModel, or only a TokenContract. The cost difference is the operator's to plan for, and right now nothing surfaces it before the spend.

Happy for this to be closed or retitled to that narrower point, whichever you prefer.