The deep verifier is redeployed after an audit found the gate under-bound: it
read the balance of whichever account signed without requiring that to be the
account the witness attests to, and the marker it left on chain recorded that a
gate ran without recording what it demanded.
Updates the superseded identifiers, states the four bindings the gate now
enforces instead of the anchoring claim that did not hold, documents the
deployed 3xxx error codes, corrects the test count to 90 and separates user
cycles from proving cycles. Also removes a truncated transaction hash that no
longer resolves.
Corrects claims that no longer held, and records the work done since the original
submission.
The dead transaction: the write-up still cited 262bbe95...6babfd5e twice with
explorer links. That transaction was wiped by the testnet reset, so both links
were dead. This is the same problem raised in review, still present in the
submission document itself.
The on-chain claim: the write-up said the v3 verifier 'validated a real
Risc0-receipt-bound ECDSA signature' and presented that as the on-chain path. The
v3 gate verifies no zero-knowledge proof, and no program on the LEZ public path
could, since the sequencer re-executes rather than proves. The document now
describes the deep gate on the privacy-preserving path, where LEZ's privacy
circuit discharges a chained call with a real env::verify and the sequencer
verifies the receipt against the pinned PRIVACY_PRESERVING_CIRCUIT_ID, and where
the threshold is checked against the balance LEZ itself anchors rather than the
caller-supplied witness.
Also corrected: the transaction table (4 rows to 7), 'Eight on-chain
transactions', the superseded outside-party criterion, E2E tests described as
being in CI while pointing at ignored tests, 57 tests (now 76), 7 CLI subcommands
(now 8), and the off-chain path described as an in-memory backend with a stubbed
Qt bridge rather than the Waku transport that now exists.
Every transaction hash in the document resolves, and every link was opened.