blog · qwen 3.8 max · 2026-10-04

Qwen 3.8 Max wrote a parser we shipped

Three Monad claims sat as unknown because nothing could read their shape. Qwen 3.8 Max proposed a mapping, tested it against our own parser and converged in one turn. It is now the first mapping in the atlas that a model wrote rather than a person.

The gap

Every evidence document an agent publishes is JSON in whatever shape its author chose. Our verifier reads them through an atlas of mappings, one per shape. A mapping says where the network, the transaction hash, the payer, the recipient and the amount live. The parser only uses those fields. A document whose shape no mapping matches stops at the intact rung as unknown. We never guess.

Three documents on Monad were in that state. They come from a settlement gateway and describe a tab being paid off. Before today this is what each one looked like:

A claim page showing unknown: no published mapping reads this document shape, read by mapping: no mapping reached this document, found on chain: not looked for — Before. The bytes match their on-chain hash, so the document is genuine. Nothing could read it, so the chain was never asked.

How Qwen is used: plan, call the parser, read, revise

We give Qwen the document and one tool, try_mapping. It proposes a mapping as paths into the document, plus its own prediction of what those paths will extract. The tool compiles the proposal and runs our real parser over the real bytes, then hands the result back. If the parser extracted what Qwen predicted and no existing mapping also claims the shape, the loop accepts. Otherwise Qwen reads what actually came out and revises, for up to six turns.

The proposal is data, never code. Nothing Qwen writes is evaluated. At worst a wrong proposal reads the wrong field. The round-trip check then rejects it.

model	Qwen/Qwen3.8-Max GMI Cloud, OpenAI-compatible API
when	2026-10-04 11:38 UTC
turns to converge	1, with 1 call to the parser 16 seconds end to end
what Qwen predicted	network 143, txHash 0x863e9ae5…f817497
what the parser extracted	network 143, txHash 0x863e9ae5…f817497 equal, so accepted

The converged run. The full transcript, the proposal and the tool outputs are committed beside the mapping.

What review changed

A converged mapping is a candidate, not a release. A person reads it before it joins the atlas. Qwen read the recipient as settlement.serviceId. That field is 0x7461622e64656d6f…, which decodes to the text tab.demo: a label, not an address anything can be paid at. The settlement transaction's own USDC transfer pays settlement.collection, so the shipped mapping uses that.

$ cast receipt 0x863e9ae50961b38e7bf12e7ae14e7384bc543725ea51c8acdd9dc8bf9f817497 --rpc-url https://rpc.monad.xyz
status   1 (success)   block 109379821
Transfer 0x754704bc…b603 (USDC)
  from 0x3a3b6079…e7ce  (settlement.agent)
  to   0x49472ef9…783a  (settlement.collection)
  200000 units

The payment the document describes, read from Monad and summarised to its status and its one USDC Transfer log. The recipient is the collection address, so that is what the mapping must point at.

After

With the reviewed mapping in the atlas, the verifier reads the document, asks Monad for the transaction and checks the value. The answer is true: 200,000 atomic units of USDC reached 0x49472ef9…783a at block 109,379,821. That claim had been unknown since it was written.

Two earlier runs: knowing what is not a payment

A verifier is also judged by what it does not count. Two earlier Qwen runs answered that side. Both found that the shape claims no payment.

On Sep 28 Qwen read BNB Smart Chain evidence documents, which our atlas had never parsed. At the time BSC held 25,643 of them against Monad's 1,287. In 320 sampled documents it found an uptime report whose value is 10000 at 2 decimals with the tag uptime. That is 100.00% uptime, not an amount. A careless parser would have read each one as a payment and manufactured claims out of uptime pings. We checked it by hand. Across the shape no field names a transaction, a payer or a token, so the right answer is no claim.

On Sep 30 we ran Qwen as a paid agent. Scribe, ERC-8004 agent 10272, sells this same loop over x402 with the upto scheme: send it a document in an unmapped shape and it returns Qwen's mapping only if it round-trips through our parser. It charges per model turn under a ceiling the buyer signs, so a buyer pays for the turns used, not the ceiling. One turn classified a BSC rating document (a score and two self-promotion tags) as no claim. It charged 4,000 of a 10,000 unit ceiling in USDC on Monad. Payer and payee were both our wallet, so it proves the metered rail, not demand.

$ cast receipt 0x87a7eb4e92d71e0357f0f1f9d1147050000e0f8d8d3a78241b1bf789cb6c76f8 --rpc-url https://rpc.monad.xyz
status   1 (success)   block 109248917
Transfer 0x754704bc…b603 (USDC)
  from 0xdb6c6340…7777  (our wallet)
  to   0xdb6c6340…7777  (our wallet)
  4000 units

The Scribe charge: one model turn plus the base price, settled under the upto ceiling. Both run records are committed beside the mapping in verifier/src/atlas/inductions/.

What Qwen was worth here

Without it, each new evidence shape costs a person reading a stranger's JSON and writing a parser. With it, a new shape costs one model call and one review. Qwen does not decide any verdict. It proposes where to look, our parser checks the proposal against the real bytes, a person checks the meaning and the chain decides what is true. The model is used where it is strong: reading an unfamiliar structure and naming its fields.

The run file is verifier/src/atlas/inductions/tab-settlement-feedback.v1.2026-10-04.json. The loop is verifier/src/atlas/induce.ts. The script scripts/atlas-propose.mjs runs it over every unread shape in the live index. The method page lists every mapping and when it was added.