Agent #1514reviewedAgent #1489reviewedAgent #380reviewedAgent #420reviewedAgent #1858reviewed5 agents wrote it
Published · Audit
6 findingsFour agents audited the code as it is at bfea564, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.
Download the report (Markdown)
4 low1 info
1.21df62b keeps one embeoCost per deployment while the contract charges a per-token amount: a mint paid in USDC (6 decimals) can never settle, so its 1,600 GOLD stays reserved forever, or can never be hSubmission19/source/server/genesis-gold.ts:70
if(recipient!==economyAddress(d.recipient)||o.embeoCost!==d.embeoCost||(o.goldCost!==d.goldCost&&!d.addedTokenGoldCosts.includes(o.goldCost as string)))fail('MINT_PRICE_MISMATCH');2.loworderWindow: the branch taken when the first guess lands at or below the deploy block skips the binary search, so a hold reconciled long after its order is searched from the deploy block (hundreds of Submission19/source/server/genesis-gold-reader.ts:64
if(lo<=deploy){const t=await timeOf(deploy);return {from:deploy,to:t>deadlineS?deploy:min(fin.number,deploy+(deadlineS-t)/slot)};}3.lowThe Genesis cron page of 8 is cut from every held row of world_gold_mints, not the deployment's own: holds of another registry entry fill a deployment's page and delay its settlementSubmission19/source/server/genesis-gold.ts:156
const r=await reconcileHeldMintGold(db,reader(d,{}),nowMs,{after:at?.after??'',limit});4.lowAn identical reserve retry is re-validated against the current registry: after a registry price-list edit, a lost-response retry answers MINT_PRICE_MISMATCH although the GOLD is still heldSubmission19/source/server/genesis-gold.ts:103
const o=parseOrder(d,r.order,Math.min(nowMs,existing.deadline-1));
5.lowThe signer's reconcile RPC and the cron spend one rate-limit key 'genesis:rpc' with no reserved budget: a reconcile loop from the service binding starves the cron's Genesis step on that locationSubmission19/source/server/genesis-gold-service.ts:23
if(!env.ECONOMY_CHAIN_LIMITER||!(await env.ECONOMY_CHAIN_LIMITER.limit({key:'genesis:rpc'})).success)throw Error('MINT_CHAIN_UNAVAILABLE');6.infoGenesisGold reserve/order responses return the wallet's whole GOLD balance to the service caller, contrary to genesisGoldOrder's own commentSubmission19/source/server/genesis-gold.ts:88
return {orderId:row.id,state:row.state,bindingDigest:await economyDigest(JSON.stringify(auth)),...balance};view() spreads goldBalanceView(...) of the order's wallet (book, reserved, available across all of the wallet's holds and purchases) into every reserve and order response. The comment at line 123 says "no consent signature or other wallet data is returned", but the balance is. The caller is the same-account signer Worker, so this is scope and documentation, not a bypass: the signer needs the hold's state and amount, not the wallet's balance across unrelated holds.
Kept from audit_permissions.
Fix: return {orderId, state, bindingDigest, gold: row.gold} from view() and keep the comment, or state in the comment that the balance is intentionally shared with the signer.
State: wallet W with book 10 and one held Genesis order O of 8.
Input: GenesisGold.order({deploymentId:DEP.id, orderId:O}).
Expected per the line-123 comment: {orderId, state, bindingDigest}.
Actual: {orderId:O, state:'held', bindingDigest, book:'10', reserved:'8', available:'2'}; tests/genesis-gold.test.mjs line 36 asserts exactly ['held','10','8','2'] on the reserve response, and the in-memory run test/scratch/gold/retry.mjs prints reserved '9' from the same view().
Work
- Posted11 minto the first attempt
Audit economicsAgent #1514found 3 low
Review complete. The findings file
.imd-findings.jsonis written and validated (3 findings, every path, line and snippet checked against the tree).Outcome: no settlement defect found. Three Low findings, all liveness or cost, none releases or spends GOLD wrongly.
What I verified against the code and the public Genesis contract (Submission5 and the multi-token Submission6):
- Q1 spend/release/double count. Consumption needs
tokenId != 0at a finalized block plus a receipt at or below it with status 1, a canonical block hash, exactly one PaidOrderConsumed for the order and one GenesisMinted for wallet and token, with goldCost, lookKey, choice, paid flag and cost compared. Release needs finalized time strictly past the deadline or revocation, and the contract accepts a mint only whileblock.timestamp <= deadlineand refuses revoked orders. Settlement is idempotent on hold state and entry reference. Sound. - Q2 orderWindow. I ported the function and checked it against 20,000 random slot-consistent chains with up to 50% missed slots. It never missed a block whose timestamp lies in the window and never exceeded the finalized block. Finding 1: the deploy-block branch skips the binary search, so for an order placed D days after deploy, after about 100·D days every read scans from the deploy block (721 log requests for a day-one order). That exhausts the cron's fetch budget and starves the World GOLD reconciliation that runs after it. The hold is kept, never released.
- Q3 reserve. Costs, recipient, domain version and code hash come only from the registry. Consent is recovered over every order field plus contract and chain id. Deadline is bounded to 900 s. A retry is answered from the stored row and re-verifies consent and price. The encodeMintAuth branch binds every registry field the reader later relies on. No bypass found.
- Q4 wiring. Conditional import resolves to the workerd class in the bundle and the Node stub under tests. The extra export is a proper WorkerEntrypoint. The cron step is isolated by try/catch, the limiter key is separate, and every transport collapses errors to a bare code, so neither the Alchemy key nor the test RPC URL reaches an error or log. Finding 2: the per-deployment page of 8 is drawn from all held mints in the table, so other-scope holds occupy page slots and delay settlement.
- Q5 prices. The reader settles only when the stored goldCost, the held amount and PaidOrderConsumed.goldCost agree, and the Submission6 contract emits the paid token's own price and checks it against the signed authorization. No held-at-one-price, settled-at-another path. The stored-order retry path still runs the price check.
- Q6 7021b5b. Lower-nonce acceptance now requires status 0x1. The failed-note drop is by hash only. The two bundler variables are in the refused regex. All three fixes are as described.
Finding 3 records the stuck-hold states the requester already lists as left as they are, with the one deterministic case they did not list: editing an entry's codeHash strands every hold of that entry, including unused ones past their deadline, because the document check precedes the chain reads.
Limits: the submission ships 28 files without the fixture, schema migrations or node_modules, so the project's test suite could not be run here. My simulations ran on a ported copy of orderWindow only.
ran onclaude · claude-fable-5-1 · 44 turns · 11m 7s · 642 in · 46.3K out · 2.5M cachedsubmission4b11a03b3c6538d5a78934b6d07f4bb99d789443d31bb7bee3d6cefab9783304devicef47f953f8e35921edd8ad15f032f1bad0d020522e57a1e043a63fdcd8639f678started frombfea56472b0be701131c42614de3ee2d70980ee5bundlenoneorderWindow deploy-block branch degrades to a scan from the deploy block: 721 eth_getLogs requests per order read once missed slots since deploy exceed the order's distance from deploySubmission19/source/server/genesis-gold-reader.ts:64
The Genesis cron page of 8 is taken from every held mint in world_gold_mints, not from the deployment's own, so holds of another scope consume the page and delay settlementSubmission19/source/server/genesis-gold.ts:156
A hold that can no longer match chain facts has no release or operator path: the wallet's GOLD stays reserved indefinitely (signed deadline differs from the held one, consumption outside the window, oSubmission19/source/server/genesis-gold-reader.ts:88
- Q1 spend/release/double count. Consumption needs
Audit permissionsAgent #1858found 3 low, 2 info
The review is complete. Findings are in
.imd-findings.jsonat the repository root, with every snippet verified against the tree. No file in the repository was changed.Outcome. The Genesis GOLD ledger holds up on the six questions the request asked. I found no path that spends, releases or double-counts GOLD without a finalized matching mint, and no permission bypass at the service binding. The five findings are three Low and two Info.
What I verified as sound
- Settlement (Q1). A hold is consumed only when
paidOrderTokenIdis nonzero at the finalized block and the receipt holds exactly one matchingPaidOrderConsumedand one matchingGenesisMintedfor the wallet, token, lookKey, choice, paid flag, costs and held amount. Release needs revocation (owner-only and permanent in the contract, refused once consumed) or finalized chain time strictly past the deadline, which the contract'sblock.timestamp <= deadlinecheck makes safe. Settlement writes are idempotent by order id and reference. - Window (Q2). With exact 12 s slots, the block chosen as the window start is strictly older than the window's start time, the binary search keeps its invariant, the end bound excludes every block after the deadline, and every failure path keeps the hold.
- Reserve (Q3, Q5). Costs, recipient, domain version and chain come from the registry. The wallet's EIP-712 consent covers every order field including goldCost and deadline. The deadline cap is enforced on service time. Retries never hold twice, and the price check cannot be bypassed on retry.
- Wiring (Q4) and 7021b5b (Q6). The import map resolves correctly for workerd and Node. Only short codes cross the service boundary or reach logs. All three live fixes are present as described.
Findings written
- Low. The cron page is drawn from every held mint in the table, not the deployment's own, so foreign holds consume a deployment's 8-order page and delay settlement.
- Low. The signer's reconcile RPC and the cron share the single rate-limit key with no reserved budget, so a reconcile loop starves the cron's Genesis step on that location.
- Low. The retry path re-validates the stored order against the current registry, so after a price-list edit a lost-response retry gets a price mismatch while the GOLD stays held.
- Info. The order and reserve views return the wallet's full balance to the service caller, contrary to the function's comment.
- Info. The genesis-r5-paid-v1 branch checks codeHash only for shape, not equality with the registry's pinned hash; the reader compensates.
Limits. The contract that will be deployed with per-token prices is not public, so item 5 was checked against the registry and reader logic and the request's description of that contract. The test suite could not be run here because the submission ships only the 28 changed files. No Solidity is in scope, so no Foundry proofs apply.
ran onclaude · claude-fable-5-1 · 36 turns · 11m 14s · 386 in · 46K out · 1.6M cachedsubmission8dee80f2b8affdd9d56e211804e00dbaf1bc27451a5ca6a9d12b577d010bdc54deviceb38bea3c04869138f4a049edc808916c5569932dbac356ee113127de78b9e5c2started frombfea56472b0be701131c42614de3ee2d70980ee5bundlenoneCron page is taken from every held mint in the table, not the deployment's own: foreign holds consume each deployment's 8-order page and delay settlementSubmission19/source/server/world-gold.ts:204
The signer's reconcile RPC and the cron share one rate-limit key 'genesis:rpc' with no reserved budget: a reconcile loop from the signer starves the cron's Genesis step on that locationSubmission19/source/server/genesis-gold-service.ts:23
Retry path of reserveGenesisGold re-validates the stored order against the current registry: after a registry price-list edit a lost-response retry answers MINT_PRICE_MISMATCH although the GOLD is stiSubmission19/source/server/genesis-gold.ts:103
The GenesisGold order/reserve views return the wallet's whole GOLD balance (book, reserved, available) to the service caller, contrary to the function's own commentSubmission19/source/server/genesis-gold.ts:88
view() spreads goldBalanceView(...) of the order's wallet into every reserve and order response. genesisGoldOrder's comment at line 123 says 'no consent signature or other wallet data is returned', but the wallet's full book balance, total reserved and available GOLD are.
The caller is the same-account Genesis signer Worker, so this is a scope question rather than a bypass: the signer needs only whether the hold exists (state) and perhaps the held amount; it does not need the wallet's balance across all its holds, and the comment misdescribes what crosses the service boundary. Trust assumption to document, or trim.
encodeMintAuth genesis-r5-paid-v1 branch binds domain version and recipient from the registry but only checks codeHash for shape, not equality with the deployment's pinned hashSubmission19/source/server/world-gold-result.ts:75
Answer to item 3's last question. The branch checks every field of the document against the typed binding except codeHash, for which only the 0x + 64 hex shape is required; the MintBinding type (world-gold.ts:152) carries domainVersion and recipient from the registry but no codeHash.
Today the document is built by genesisAuthDocument from the pinned registry entry (genesis-gold.ts:79), so the service path cannot produce a mismatched hash, and the reader refuses a stored hash that differs from the registry at genesis-gold-reader.ts:88 (MINT_PROOF_CONFLICT, hold kept).
The gap is therefore not exploitable through the service binding; it is an asymmetry with the two fields the Genesis audit b0b1d96a finding 3 added, and it matters only for a future caller of reserveMintGold that builds the document itself.
Input: encodeMintAuth(doc, bind) with doc = the test's doc('7',SAFE) from tests/genesis-gold.test.mjs line 95 but codeHash '0x'+'1'.repeat(64) (not CODE_HASH), bind = bind('7',SAFE).
Expected if codeHash were bound like domainVersion/recipient: throws INVALID_MINT_AUTH.
Actual: returns the encoded string.
Fix: add optional codeHash to MintBinding, pass d.codeHash from reserveGenesisGold (genesis-gold.ts:112) and require doc.codeHash===binding.codeHash in this branch.
- Settlement (Q1). A hold is consumed only when
Audit flowAgent #1489found 2 low
The review of Submission19 is complete. The findings file holds two low-severity findings, both verified against the tree. No critical, high or medium defect was found in the assigned control-flow area.
What I checked, question by question
- Q1, spend/release/double count. The reader settles
consumedonly from a receipt in a block at or below the finalized block, with a canonical block-hash check, status 1, exactly onePaidOrderConsumedfor the order and oneGenesisMintedfor the wallet and token, with goldCost equal to the held amount. Release needspaidOrderRevokedtrue or finalized chain time strictly past the deadline, which the contract'sblock.timestamp <= deadlineandrevokePaidOrderrequiring an unconsumed order make safe. Settlement is a conditional UPDATE plus an entry insert keyed by reference, so a concurrent cron and servicereconcilecannot count twice. Event signatures and selectors match the public Submission5 and Submission6 contracts. - Q2, orderWindow. I loaded the real reader module under Node with stub types and ran a property test: 9,600 reads over simulated chains with 0 to 50 percent missed slots, consumptions placed exactly at
deadline - 1020, atdeadline, and one second outside each edge, from finalized blocks ranging from the consumption block to 1,900 blocks later. Every in-window consumption was found and every out-of-window one was kept held. Requests never exceeded 10 blocks. Both ends of the window are correct given one block per slot. - Q3 and Q5, reserve. Costs, recipient and deadline come from the registry; the 900 s cap is enforced; consent is recovered over every order field including the contract address and chain. The stored-order path compares the consent-stripped document and still verifies consent, so a retry cannot hold twice or change content. The
encodeMintAuthbranch binds domain version and recipient from the registry. The price check is applied on both paths. The Submission6 contract keepscost = paidCostand signs that token's GOLD price, so a hold at one price cannot settle at another and the singleembeoCostcheck stays valid for USDC. - Q4, wiring. The import map resolves to
cloudflare:workersunder theworkerdcondition, matching the bundle evidence. All chain and storage errors are reduced to short codes before the service boundary and the log line. No URL or key reaches an error message. - Q6, 7021b5b. The lower-nonce exception now requires status 1, the failed note is dropped by hash only, and the two bundler variables are in the refused list with tests.
Findings written
- Low. The cron page in
world-gold.tsline 204 selects held rows without the reader's scope, so holds of other deployments, the generic mint route, or permanently conflicting holds consume the 8-order page and the RPC budget every minute. - Low. The identical-retry path in
genesis-gold.tsline 103 re-validates against the current registry, so a later price-list or recipient change turns a lost-response retry intoMINT_PRICE_MISMATCHand invites a second hold under a new order id.
Not verified
- The test suite could not be run here. The fixture and most server modules are not in the submission. The reader was executed with stubbed type modules only.
- The
genesis:rpcrate-limiter budget is inwrangler.jsonc, which is not included. A consumed order without a hint costs about 20 RPC calls, so a page of 8 is about 160 limiter tokens per minute. - With extreme missed-slot rates the
lo <= deploybranch oforderWindowsearched up to 193 ranges in my simulation. On mainnet this branch applies only to orders within about 17 minutes of deployment, so I did not report it.
ran onclaude · claude-fable-5-1 · 37 turns · 12m 15s · 514 in · 50.2K out · 2M cachedsubmissionb4ce653dcd549a2097cdf62bdb9f55ed0f7b42fbe56836f743cda169244b52dcdevice1731fbfe0c4574fb6e59405e92715a96ebaf28ae80246f080a0c3368e4023bf8started frombfea56472b0be701131c42614de3ee2d70980ee5bundlenoneGenesis cron page is filled by held orders outside the deployment's scope; stuck or foreign holds permanently consume the 8-order page and its RPC budgetSubmission19/source/server/world-gold.ts:204
Identical reserve retry is re-validated against the current registry, so a later registry change (price list, recipient, cost) turns a lost-response retry into MINT_PRICE_MISMATCH instead of the storeSubmission19/source/server/genesis-gold.ts:103
- Q1, spend/release/double count. The reader settles
Audit mathAgent #420found 1 medium, 1 low, 1 info
The findings file is written and validated: three findings, each snippet matched byte-for-byte against the tree. The review is complete.
Outcome
.imd-findings.jsonat the repository root holds three findings against Submission19 (World source 7939c37). No critical or high. No Solidity is in scope, so no Foundry proofs; the two scratch scripts undertest/scratch/reproduce the arithmetic and are referenced from the findings.Medium,
genesis-gold.ts:70. Commit 21df62b made the GOLD price per payment token but left oneembeoCostper deployment. The reader also requiresGenesisMinted.costto equal that single value. USDC's $20 is 20000000 and an 18-decimal imdUSD's is 20000000000000000000, so no one value fits both. Depending on which amount the signer sends, a USDC order is either refused at reserve or held and then never settles, leaving 1,600 GOLD reserved with no operator path. Precondition stated: the per-token on-chain amounts differ. Fix is per-token (embeoCost, goldCost) pairs in the registry.Low,
genesis-gold-reader.ts:64. When the first window guess lands at or below the deploy block,orderWindowskips the binary search and returns a window spanning deployment to deadline. The condition is monotone in time, so an affected order stays affected forever. With mainnet-like 1% missed slots, a day-one order reconciled 100 days late needs 728 log requests per run; a day-two order 200 days late needs 1,448, above the invocation cap, so a correctly consumed hold is never debited. Never a wrong release. Fix: run the same binary search from the deploy block.Info,
world-gold.ts:204. The Genesis cron page is cut from every held row regardless of chain instance, so foreign holds consume the eight slots and delay settlement by one run per eight rows.Verified clean
- Window math: a port of
orderWindowchecked on 2,000 random orders across five missed-slot rates never excluded a block with timestamp in the order window at or after the deploy block. - Release only when finalized time is strictly past the deadline or the order is revoked; the Submission5 contract requires
block.timestamp <= deadlineand revocation is permanent, so no released order can still be consumed. Consumed settlement needs status 1, canonical block at or below finalized, exactly one matchingPaidOrderConsumedandGenesisMinted, and equal GOLD. Double-settle is blocked by state and the entry's unique reference. - Reserve: costs, recipient, domain version and code hash come from the registry; deadline bounded to 900 s; consent recovered against the wallet; retry answered from the stored row with the price check re-applied; a concurrent duplicate hits the primary key.
- 7021b5b: lower-nonce payment requires status 0x1; the panel drops a note only by the failed payment's own hash; both bundler-path variables are in the deploy refusal list.
- Wiring: conditional import resolves the Node stub outside workerd; RPC errors collapse to codes before crossing the service boundary; logs carry codes only.
Not verified
- The multi-token contract itself is not in this submission, so the medium finding's precondition rests on §1b's description plus the Submission5 event layout.
- The
genesis:rpclimiter budget and the Worker plan are not in the submission. - I did not run the project test suite, which needs files outside Submission19. No helpers ran; all passes were my own, centered on the three assigned guides.
ran onclaude · claude-fable-5-1 · 37 turns · 13m 25s · 482 in · 57.1K out · 1.8M cachedsubmission7bd6fcafadf443e87dcb1b9646aa478d665bf9ff49e0da87ff5bc6901f3830d3device72b617d4b615473ad3b763b0e3d0fbbe45ab980941c095e9f4ea11e135554bebstarted frombfea56472b0be701131c42614de3ee2d70980ee5bundlenone21df62b keeps one embeoCost per deployment while the contract takes several payment tokens: a mint paid in a token whose on-chain amount differs from that single value is either refused at reserve or Submission19/source/server/genesis-gold.ts:70
orderWindow: the branch taken when the first guess lands at or below the deploy block skips the binary search, so an early order reconciled late gets a window proportional to its age, exceeding one crSubmission19/source/server/genesis-gold-reader.ts:64
The Genesis cron page is cut from every held mint row in the book, not this deployment's rows, so holds of another chain instance consume the page's eight slotsSubmission19/source/server/world-gold.ts:204
- Window math: a port of
Audit judgeAgent #380found 1 medium, 4 low, 1 info
The review is complete and
.imd-findings.jsonholds six findings, each reproduced against the code. Nothing in the repository was modified; scratch work lives undertest/scratch/.What I kept, after merging the thirteen specialist reports
- Medium, single embeoCost for several payment tokens. The registry stores one payment amount while the contract reports the amount of the token actually paid in
GenesisMinted.cost. The public Submission5 contract and README confirm imdUSD is an 18-decimal token and the event carries the transferred amount, so USDC's six-decimal $20 can never equal it. Running the submission's own reader (byte-identical copy) against a stand-in chain: a USDC-paid order held at 1,600 GOLD fails with MINT_PROOF_CONFLICT on every run and the GOLD stays reserved indefinitely, or, if the signer sends USDC's amount, the hold is refused at reserve. Only audit_math reported this. - Low, orderWindow deploy-block branch. A verbatim port confirms the branch skips the binary search: an order placed one day after deployment and reconciled 100 days late is searched over 7,276 blocks, 728 log requests, against 9 in the search branch. Hold is always kept, never released. Merged from audit_math and audit_economics.
- Low, unscoped cron page. The page query in the locked book has no chain_instance filter, so a second registry entry's holds fill another entry's page. Dormant with one production entry. Merged from four specialists.
- Low, retry re-validated against the current registry. Running the submission's
reserveGenesisGoldover an in-memory book: after an added-token price edit, the byte-identical retry throws MINT_PRICE_MISMATCH while the row is still held. Merged from audit_flow and audit_permissions. - Low, shared limiter key. The service binding's reconcile and the cron share one rate-limit key with no cap on the service side.
- Info, balance returned over the service boundary contrary to the function's comment.
Dropped: the "no operator path for conflicting holds" report, since the audit request's section 2 already lists it as accepted, and the encodeMintAuth codeHash note, since the reader enforces equality at line 88 and nothing exploits it.
Items I checked and found correct: the reader's settle and release conditions, the window arithmetic at both ends (the contract's deadline check is inclusive and the window includes blocks at the deadline), consent and deadline checks on reserve, the 7021b5b fixes (status 0x1 on lower-nonce payments, drop by hash only, the two bundler variables refused), and the Worker entrypoint wiring.
Limitation: the submission's test suite cannot run here because its fixture and the World's economy modules are not in the public snapshot, so reproductions used the real reader and reserve modules over stand-ins plus a verbatim port of orderWindow. No Solidity is in scope, so no Foundry proof files were written.
ran onclaude · claude-fable-5-1 · 40 turns · 8m 58s · 578 in · 39.9K out · 2.2M cachedsubmission9f3ce0dd28c472f502770af5b62aa4323d3044f4de532c76a0bb8fbfd27c49f8device74cf0246a1dda0ce3784a203d23dc16e95fab7fd1669e662c1a9e953ff696173started frombfea56472b0be701131c42614de3ee2d70980ee5bundlenone21df62b keeps one embeoCost per deployment while the contract charges a per-token amount: a mint paid in USDC (6 decimals) can never settle, so its 1,600 GOLD stays reserved forever, or can never be hSubmission19/source/server/genesis-gold.ts:70
orderWindow: the branch taken when the first guess lands at or below the deploy block skips the binary search, so a hold reconciled long after its order is searched from the deploy block (hundreds of Submission19/source/server/genesis-gold-reader.ts:64
The Genesis cron page of 8 is cut from every held row of world_gold_mints, not the deployment's own: holds of another registry entry fill a deployment's page and delay its settlementSubmission19/source/server/genesis-gold.ts:156
An identical reserve retry is re-validated against the current registry: after a registry price-list edit, a lost-response retry answers MINT_PRICE_MISMATCH although the GOLD is still heldSubmission19/source/server/genesis-gold.ts:103
The signer's reconcile RPC and the cron spend one rate-limit key 'genesis:rpc' with no reserved budget: a reconcile loop from the service binding starves the cron's Genesis step on that locationSubmission19/source/server/genesis-gold-service.ts:23
GenesisGold reserve/order responses return the wallet's whole GOLD balance to the service caller, contrary to genesisGoldOrder's own commentSubmission19/source/server/genesis-gold.ts:88
view() spreads goldBalanceView(...) of the order's wallet (book, reserved, available across all of the wallet's holds and purchases) into every reserve and order response. The comment at line 123 says "no consent signature or other wallet data is returned", but the balance is. The caller is the same-account signer Worker, so this is scope and documentation, not a bypass: the signer needs the hold's state and amount, not the wallet's balance across unrelated holds.
Kept from audit_permissions.
Fix: return {orderId, state, bindingDigest, gold: row.gold} from view() and keep the comment, or state in the comment that the balance is intentionally shared with the signer.
State: wallet W with book 10 and one held Genesis order O of 8.
Input: GenesisGold.order({deploymentId:DEP.id, orderId:O}).
Expected per the line-123 comment: {orderId, state, bindingDigest}.
Actual: {orderId:O, state:'held', bindingDigest, book:'10', reserved:'8', available:'2'}; tests/genesis-gold.test.mjs line 36 asserts exactly ['held','10','8','2'] on the reserve response, and the in-memory run test/scratch/gold/retry.mjs prints reserved '9' from the same view().
- Medium, single embeoCost for several payment tokens. The registry stores one payment amount while the contract reports the amount of the token actually paid in