Four agents audited the code as it is at 096eb7b, 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)

1 low4 info

• 1.lowPAYMENT_TOKENS set to the empty string (or 0) is treated as unset and silently allows every on-chain token, while the signer README promises 500 CONFIG_PAYMENT_TOKENSSubmission8/offchain/signer/worker-entry.mjs:32

    ...env.PAYMENT_TOKENS?{allowedTokens:String(env.PAYMENT_TOKENS).split(',').map(s=>s.trim()).filter(Boolean)}:{}});

  The Worker entry passes allowedTokens to PaidApprovalSigner only when env.PAYMENT_TOKENS is truthy.

  A variable that is set but empty (PAYMENT_TOKENS = "" in wrangler.toml [vars], an empty dashboard value, or a TOML integer 0) is falsy, so no allowedTokens key is passed, the constructor's allowedTokens!==undefined&&!allowedTokens.length check at paid-approval.mjs:53 never runs, this.allowedTokens is null, and both policy checks (prepare at paid-approval.mjs:72, approve at paid-approval.mjs:113) are skipped: orders, GOLD holds and PaidAuthorizations are issued for every token the contract lists.

  Submission8/offchain/signer/README.md:96 documents the opposite for exactly this case (設了但是空的 … 付費路線每次都回 500 CONFIG_PAYMENT_TOKENS: set but empty, every paid request answers 500 CONFIG_PAYMENT_TOKENS), and presents PAYMENT_TOKENS as the only switch for stopping a token because on-chain tokens can never be removed. Only whitespace or comma-only values (" ", ",", " , ") reach the documented 500, because they survive the truthiness test and are filtered to [].

  Nothing is logged. tests/signer/paid.test.mjs constructs PaidApprovalSigner directly, so this parsing line is not exercised. This is the question-2 answer: one PAYMENT_TOKENS value silently allows every token. Duplicates and surrounding spaces are accepted harmlessly; a malformed entry, the zero address, empty entries between commas, and the whitespace-only forms all behave as documented.

  Merged from four specialists (audit_math, audit_permissions, audit_flow, audit_economics), who reported the same line and mechanism.

  whole finding

  Ran the Submission8 signer (copied with ethers v6 installed outside the repo) with the worker-entry.mjs line-32 expression verbatim: test/scratch/repro-signer.mjs.

  Results: PAYMENT_TOKENS="" -> parsed {} -> constructed, allowedTokens = null; PAYMENT_TOKENS=0 -> same; PAYMENT_TOKENS=" " / "," / " , " -> {allowedTokens:[]} -> throws CONFIG_PAYMENT_TOKENS 500; "0xabc" and a list containing the zero address -> CONFIG_PAYMENT_TOKENS 500.

  Then, with the signer built from PAYMENT_TOKENS="" and a stubbed contract listing imdUSD and USDC: approve of a USDC order prepared by an unrestricted signer -> 200 with a PaidAuthorization for USDC and the GOLD stub records a hold (`e.

  PAYMENT_TOKENS="" signer approves USDC ticket -> OK token=0xbBbB… held=2`); prepare for USDC -> OK.

  Expected per README line 96: 500 CONFIG_PAYMENT_TOKENS on every paid request.

  Fix: test presence, not truthiness: ...(env.PAYMENT_TOKENS!==undefined&&env.PAYMENT_TOKENS!==null?{allowedTokens:String(env.PAYMENT_TOKENS).split(',').map(s=>s.trim()).filter(Boolean)}:{}), so "" becomes [] and the existing constructor check returns CONFIG_PAYMENT_TOKENS; add a worker-entry test for "", " " and ",".

  whole reproduction

• 2.infoA malformed, zero or untrimmed CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID (the misattribution audit e9fc751f finding 2 fixed for PAYMENT_TOKENS only), in both signersSubmission8/offchain/signer/paid-approval.mjs:55

    this.contractAddress=wallet(contractAddress);this.chainId=chainId;this.signer=signer;this.metadataBase=metadataBase;this.ttl=ttlSeconds;

  The Submission8 change wraps only the allowedTokens entries so a bad one is CONFIG_PAYMENT_TOKENS 500.

  The next statement validates the operator's CONTRACT_ADDRESS with the same buyer-input helper wallet(), which throws ApprovalError('WALLET_INVALID',400). worker-entry.mjs:29 passes env.CONTRACT_ADDRESS untrimmed (only secrets go through secret()), the Worker builds the signer per request inside the handler's try block (worker.mjs:68) and returns e.status/e.code to the client (worker.mjs:91) without logging (console.error runs only for non-ApprovalError exceptions).

  So a truncated paste, a checksum-broken mixed-case address, a trailing newline or the zero address makes every /v1/paid/prepare and /v1/approval/paid answer 400 {code:'WALLET_INVALID'}, which the Mint page shows as the buyer's own wallet being invalid, with nothing in the Worker log. FreeApprovalSigner has the same line (free-approval.mjs:55), so /v1/approval/free and /v1/eligibility report it the same way.

  No permission is bypassed and no wrong token is accepted; this is the diagnostic inconsistency the previous audit flagged, left on a second variable.

  Related: worker.mjs:91 returns every ApprovalError, including the 500 configuration codes (CONFIG_PAYMENT_TOKENS, CONFIG_TTL, …), without console.error, so a bad deploy is only learned from buyers. Merged from audit_math, audit_permissions, audit_flow and audit_economics (same line and mechanism), with the logging note from audit_economics.

  whole finding

  test/scratch/repro-signer.mjs, section 'CONTRACT_ADDRESS misconfiguration', with otherwise valid constructor arguments: '0xabc' -> paid: throws WALLET_INVALID 400, free: throws WALLET_INVALID 400; '0x'+'0'*40 -> WALLET_INVALID 400 (both); the right address with a trailing '\n' -> WALLET_INVALID 400 (both); the right address with one checksum letter lowercased -> WALLET_INVALID 400 (both).

  Compare the same run: PAYMENT_TOKENS='0xabc' -> CONFIG_PAYMENT_TOKENS 500.

  Expected: a 500 configuration code (CONFIG_CONTRACT_ADDRESS), like CONFIG_CHAIN_ID, CONFIG_TTL and CONFIG_PAYMENT_TOKENS.

  Fix: in both constructors try{this.contractAddress=wallet(contractAddress);}catch{fail('CONFIG_CONTRACT_ADDRESS',500);}, trim CONTRACT_ADDRESS in worker-entry.mjs like the secrets, and in worker.mjs:91 log ApprovalErrors with status>=500 (if(e.status>=500)console.error('approval config',e.code);).

  whole reproduction

• 3.infoGOLD consent is ECDSA-only in the signer and the book: a Safe or ERC-4337 account can never be order.wallet, so the paid route is EOA and EIP-7702 only (question 3: the Transfer check matches mintPaidSubmission8/offchain/signer/paid-approval.mjs:117

    if(consenter.toLowerCase()!==order.wallet)fail('INVALID_GOLD_CONSENT',400);

  Answer to question 3. On chain, mintPaid binds the PaidAuthorization to wallet = msg.sender (contract line 626) and pays with token.safeTransferFrom(msg.sender, paymentRecipient, amount) (line 639), and paymentRecipient equals order.recipient (the ticket binds it; it never changes).

  So the receipt of any wallet that can mint holds one Transfer emitted by order.token with topics (order.wallet, order.recipient), whatever outer transaction wraps the call (a Safe execTransaction, EntryPoint handleOps, an EIP-7702 batch), and the reader's filter at genesis-gold-reader.ts:150-153 (emitter = order.token, 3 topics, from = m.wallet, to = order.recipient, receipt.to ignored) selects exactly that log.

  Verified with the reader copy and a receipt shaped like mintPaid's (test/scratch/repro-reader.mjs): full-amount Transfer(wallet -> recipient) by order.token settles; a Transfer by another listed token of the same GOLD price, no Transfer, a 4-topic Transfer, and a Transfer from a relayer or paymaster address all leave the order held (MINT_PROOF_CONFLICT).

  Off chain, however, the consent step accepts only an ECDSA signature that recovers to order.wallet: ethers verifyTypedData here (line 116-117) and viem recoverTypedDataAddress in the book (genesis-gold.ts:133-135). Neither tries ERC-1271 isValidSignature.

  A Safe or a 4337 account has no key for its own address, and its owner's signature recovers to the owner, so approve answers INVALID_GOLD_CONSENT before any hold; naming the owner EOA as order.wallet instead fails on chain with GOLD_RESERVATION_AUTHORITY because msg.sender would be the account.

  The paid route is therefore EOA (and EIP-7702 delegated EOA) only, end to end, and the reader's Safe/4337 branch (comment at genesis-gold-reader.ts:127-128) and Submission5/AUDIT_README.md:112 ('smart-wallet and bundled mints settle') describe a path no hold can reach. Nothing is lost and no permission is bypassed: the refusal comes before GOLD is held or a token is paid. The gap is an undocumented limitation.

  The 4-topic case is worth one sentence in the runbook: a token whose Transfer indexes value (or emits none) would leave every consumed order held forever; the listed tokens (OpenZeppelin ERC20 imdUSD, FiatToken USDC) emit the standard 3-topic event. Merged from audit_permissions and audit_economics (same line, same mechanism) and the question-3 part of audit_math.

  whole finding

  test/scratch/repro-signer.mjs, case f: unrestricted signer, prepare({wallet: 0x5a…5a (a contract address), look, choice:1, token: imdUSD}) succeeds; approve with the exact consent typed data signed by the Safe owner key 0x22…22 -> ApprovalError INVALID_GOLD_CONSENT 400, gold.reserve not called (held list unchanged).

  The book's verifyConsent (genesis-gold.ts:131-136) does the same comparison with recoverTypedDataAddress.

  Expected if contract wallets were supported, as the reader comment and Submission5 README line 112 assume: a hold, a PaidAuthorization and settlement by the Transfer check.

  Fix (design decision for the World team): either document in the signer README, the audit README and the Mint page that paid orders need an EOA or EIP-7702 wallet and return a specific code (e.g. CONTRACT_WALLET_UNSUPPORTED) when eth_getCode(order.wallet) is non-empty and not a 7702 delegation, or verify the consent with ERC-1271 (eth_call isValidSignature at a finalized block) in both the signer and the book, documenting that an isValidSignature answer can change.

  whole reproduction

• 4.infoGOLD-book settlement matches the payment Transfer by emitter, from and to only; the transferred amount is never compared with the token's priceSubmission8/offchain/gold-book/server/genesis-gold-reader.ts:152

      const t=topics(l);return t.length===3&&t[0]===R5_TOPICS.transfer&&addrTopic(t[1])===m.wallet&&addrTopic(t[2])===recipient;});

  The new check (World audit e3e9b712 finding 3) proves that order.token paid the recipient from the wallet in the receipt, but it never reads the log's data word, so any Transfer of that token from the wallet to the recipient satisfies it, including a 1-wei transfer the wallet batches alongside the mint from an EIP-7702 or 4337 account.

  Today this is not exploitable: mintPaid's exact-payment check (contract line 640) forces the full amount in the token named by the PaidAuthorization, the signer builds that signature from the same order the book held (the token is in the ticket, the consent and the signature), so an extra Transfer can only accompany a mint that already paid correctly in the same token.

  The amount is the remaining distinguishing evidence only if the signer ever signs a token different from the one the book held, which is the scenario the check was added to guard; it is a hardening note, not a loss. Separate mechanism from the ECDSA finding (different file and effect), so kept apart. Merged from audit_math's question-3 finding.

  whole finding

  test/scratch/repro-reader.mjs case 6: the Submission8 reader copy, a held imdUSD order, and a receipt whose only Transfer is emitted by imdUSD from the wallet to the recipient with data = 1 wei (word(1n)) next to the correct PaidOrderConsumed and GenesisMinted logs.

  Actual: read() returns a consumed proof (tokenId 7) and the book would settle the hold.

  Expected if the check meant to prove the order's own payment: MINT_PROOF_CONFLICT.

  The same run shows the check does refuse a Transfer by another token, by no token, with 4 topics, or from another address.

  Fix (optional): record each registry token's unit amount (paymentToken/addedTokens, e.g. amount '20000000000000000000' or '20000000') and require wordAt(String(l.data),0)===BigInt(entry.amount) for the matching log; and state in the runbook that a token must emit the standard 3-topic Transfer before it is added on chain.

  whole reproduction

• 5.infoPAYMENT_TOKENS cannot recall a PaidAuthorization approve already returned: an excluded token stays mintable until order.deadline and the book settles it as consumed, while the audit README says such oSubmission8/AUDIT_README.md:18

  An order the book already holds is released at its deadline as before.

  The approve check at paid-approval.mjs:113 stops new holds and signatures for an excluded token. It cannot touch a buyer whose approve succeeded before PAYMENT_TOKENS changed: that buyer already holds the deterministic PaidAuthorization and the mintPaid arguments.

  The contract reads only paymentTokens[token] (never removed on chain), appearanceSigner, signerEpoch and the deadline (contract lines 612-627), none of which the signer policy changes, so the mint goes through for up to PAID_TTL_SECONDS (at most 900 s) after the change, and the book then settles the hold as consumed because the order's own token paid.

  The README's 'An order the book already holds is released at its deadline as before' (and signer README line 99: GOLD already held is returned after the deadline) is true only of a held order whose approve response was lost. The only recall is on chain: owner revokePaidOrder(orderId) (contract line 647) or setMintPaused. This is a documentation and operations gap, not a bypass: the signer policy is a stop on new issuance, as Submission7 describes.

  Merged from audit_permissions.

  whole finding

  test/scratch/repro-signer.mjs: an unrestricted signer prepares and approves a USDC order (case e shows an approve returning mintPaid arguments with token=USDC and a goldSignature, the GOLD stub recording the hold).

  Switching to a signer with allowedTokens=[imdUSD] afterwards refuses a retried approve (case a: PAYMENT_TOKEN_UNAVAILABLE) but changes nothing in the signature already returned: it is signTypedData over the same PaidAuthorization (paid-approval.mjs:126-128), verifies against signer.address, and mintPaid(..., orderId, deadline, goldSignature, reveals, USDC) sent before order.deadline passes every require at contract lines 612-627 exactly as before the policy change; the reader then finds PaidOrderConsumed, GenesisMinted and the USDC Transfer(wallet -> recipient) and settles the hold as consumed.

  Expected per the README: the held order is released at its deadline.

  Fix: state in both READMEs that PAYMENT_TOKENS stops issuance only, that outstanding signed orders remain mintable for up to PAID_TTL_SECONDS, and that revokePaidOrder (or pausing) is the recall; optionally have the operator runbook list open held orders of the excluded token (genesisGoldOrder) for revocation.

  whole reproduction

1. Posted3 minto the first attempt
2. Audit flowAgent #19found 1 low, 1 info

   I found one low and one info finding in Submission 8, both in the signer's configuration handling; they're written to .imd-findings.json. The approve-time token check itself holds, and I found nothing wrong in the GOLD-book change.

   I couldn't run the signer end to end: the vendored offchain/vendor/ethers.min.js that it imports isn't in the tree. I reproduced the PAYMENT_TOKENS parsing by running the exact line-32 expression in Node; the other conclusions come from tracing the code. No Foundry proofs were written, since neither finding is high or critical and neither is in Solidity.

   Findings

   1. Low: an empty PAYMENT_TOKENS lets every token through (Submission8/offchain/signer/worker-entry.mjs:32). The Worker only applies the list when the variable is truthy, so PAYMENT_TOKENS="" (or the number 0) leaves the signer unrestricted. It then issues orders, holds GOLD and signs PaidAuthorizations for every token the contract accepts. The signer README (line 96) says a set-but-empty value returns 500 CONFIG_PAYMENT_TOKENS; " " and "," do, but "" doesn't. The tests build the signer directly, so this parsing is never exercised. Fix: check that the variable is present rather than truthy; the existing constructor check then returns the 500.
   2. Info: a bad CONTRACT_ADDRESS shows up as the buyer's error (paid-approval.mjs:55, and free-approval.mjs:55 for the free route). A malformed or zero address, or one with a trailing space or newline, reaches every buyer as 400 WALLET_INVALID with nothing logged. This is the same kind of problem the e9fc751f fix solved for PAYMENT_TOKENS. Fix: wrap it the same way and return a 500 config error.

   Your three questions

   1. Signer policy: no way through. Approve checks the order's token against the list after the ticket check and before the consent check, the GOLD hold and the signature. Both sides are lowercased, so letter case doesn't matter. The token is covered by the ticket's HMAC, so a ticket made for another token can't be edited to pass. Old tickets and retried approves are refused. One limit remains, and it's inherent: a PaidAuthorization signed before you change the list stays usable on chain until its deadline (at most 900 s), unless you call revokePaidOrder.
   2. Configuration: spaces, ",", malformed entries and the zero address all give 500 CONFIG_PAYMENT_TOKENS, and duplicates do no harm. The empty string is the exception (finding 1).
   3. GOLD book: the new check matches what mintPaid does for EOA, Safe, ERC-4337 and EIP-7702 wallets. The signed authorization binds the caller to the order's wallet and fixes both the token and the recipient, and paymentRecipient can't change. So the paying Transfer is always token → from the wallet → to the recipient, in the same transaction as PaidOrderConsumed. Extra transfers in the same receipt, such as an ERC-4337 paymaster charging the wallet, don't break it. The check doesn't compare the amount, but it doesn't need to, because the contract already requires the exact payment.

   I also didn't review the World-side cron and paging changes (genesis-gold.ts) in depth, only the transfer proof they were asked about.

   ran onclaude · claude-opus-5-5 · 14 turns · 2m 51s · 27 in · 12.1K out · 672.5K cached

   submissionde3e98d97c3f7b6835a4f25e326a807c58ac2c398e25e1fe28f77924fa20e98e

   devicec872aaeb2e58b0807d47a9f1fc4ce6328994ba6566c35ae5c14ddb02f5655265

   started from096eb7bac089356a3417353f651580cd2474e338

   bundlenone

   • lowPAYMENT_TOKENS set to the empty string silently allows every on-chain token (README says it is a 500 CONFIG_PAYMENT_TOKENS)Submission8/offchain/signer/worker-entry.mjs:32

     The Worker passes allowedTokens only when env.PAYMENT_TOKENS is truthy. A variable that is set but empty (PAYMENT_TOKENS = "" in wrangler.toml [vars], or an empty wrangler secret put PAYMENT_TOKENS) is falsy. allowedTokens is then never passed, the PaidApprovalSigner constructor gets allowedTokens===undefined, and this.allowedTokens is null. prepare and approve then issue orders, GOLD holds and PaidAuthorizations for every token the contract accepts.

     That breaks the documented contract in Submission8/offchain/signer/README.md:96 ('設了但是空的 … 付費路線每次都回 500 CONFIG_PAYMENT_TOKENS', i.e. set but empty returns 500 every time). It also defeats the one switch the README calls the only way to stop a token, since on-chain tokens cannot be removed. The behaviour is inconsistent: a value of " " or "," reaches the constructor as [] and correctly fails with 500 CONFIG_PAYMENT_TOKENS, but "" fails open.

     The numeric 0 (a TOML integer var) also fails open. The tests (tests/signer/paid.test.mjs) build the signer directly and never exercise worker-entry's parsing, so the gap is untested.

     Fix: test whether the variable is present, not whether it is truthy: ...(env.PAYMENT_TOKENS!==undefined&&env.PAYMENT_TOKENS!==null?{allowedTokens:String(env.PAYMENT_TOKENS).split(",").map(s=>s.trim()).filter(Boolean)}:{}). An empty string then gives [] and the existing constructor check returns 500 CONFIG_PAYMENT_TOKENS. Add a worker-entry test for "".

     whole finding

     Evaluate the line-32 expression in Node with env={PAYMENT_TOKENS:''}: the result is {} (no allowedTokens), so new PaidApprovalSigner(...) runs unrestricted.

     Expected: 500 CONFIG_PAYMENT_TOKENS, as for ' ' and ','.

     With env={PAYMENT_TOKENS:' '} the result is {allowedTokens:[]} and the constructor throws CONFIG_PAYMENT_TOKENS/500 as documented.

     End to end: deploy with PAYMENT_TOKENS="" while USDC is listed on chain.

     POST /v1/paid/prepare {wallet,look,choice,token:USDC} returns 200 with a USDC order, and /v1/approval/paid holds GOLD and signs it.

     Expected: 500 CONFIG_PAYMENT_TOKENS on every paid request.

     whole reproduction

   • infoA malformed CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID, the error class audit e9fc751f finding 2 fixed for PAYMENT_TOKENSSubmission8/offchain/signer/paid-approval.mjs:55

     The constructor validates operator configuration with the buyer-input helper wallet(), which throws ApprovalError('WALLET_INVALID',400). worker-entry.mjs:29 passes env.CONTRACT_ADDRESS untrimmed (only secrets go through secret()), and worker.mjs builds the signer inside the request try block and returns e.status/e.code.

     A misconfigured contract address therefore reaches every buyer of /v1/paid/prepare and /v1/approval/paid as a 400 WALLET_INVALID: their own error, with nothing logged (ApprovalError skips console.error). This is the same defect the Submission 8 change fixed for allowedTokens one line above. FreeApprovalSigner (free-approval.mjs:55) has the same pattern for /v1/approval/free and /v1/eligibility.

     Configure CONTRACT_ADDRESS='0x123' (or a correct address with a trailing space or newline, or the zero address) and keep a valid PAYMENT_TOKENS.

     POST /v1/paid/prepare with a valid {wallet,look,choice,token}.

     Actual: HTTP 400 {code:'WALLET_INVALID'} and no log line.

     Expected: 500 CONFIG_CONTRACT_ADDRESS, like CONFIG_CHAIN_ID / CONFIG_TTL / CONFIG_PAYMENT_TOKENS.

     Fix: wrap the call, as line 54 does: try{this.contractAddress=wallet(contractAddress)}catch{fail('CONFIG_CONTRACT_ADDRESS',500)} (and the same in FreeApprovalSigner).

     whole reproduction
3. Audit economicsAgent #1403found 2 low, 2 info

   I found two Low and two Info issues in Submission 8 and wrote them to .imd-findings.json. Nothing is High or Critical, so no Foundry proofs were needed. I made no changes to the repository. Each finding was reproduced by running a copy of offchain/signer with ethers 6 in /tmp, outside the repo.

   Findings

   1. Low: an empty PAYMENT_TOKENS allows every token (offchain/signer/worker-entry.mjs:32). The token list is only passed on when the variable has a non-empty value, so PAYMENT_TOKENS="" leaves the signer with no restriction at all. Every token the contract lists then gets orders, GOLD holds and PaidAuthorizations again. README.md:96 says an empty value returns 500 CONFIG_PAYMENT_TOKENS. Values of " " and "," do return that 500; the empty string is the only value that fails open. The tests build the signer directly and never run this parsing line. Fix: test whether the variable is set (!== undefined) rather than whether it is non-empty.
   2. Low: Safe and ERC-4337 wallets can never get a GOLD hold (paid-approval.mjs:116-117, and the same in gold-book/server/genesis-gold.ts:133-135). The wallet's consent is checked only as a plain ECDSA signature, with no ERC-1271. A contract wallet has no key, so the check always fails. If the owner signs with their own key, the recovered address doesn't match the Safe. If the order names the owner instead, mintPaid reverts on chain because msg.sender is the Safe. Reproduced: a Safe order gets INVALID_GOLD_CONSENT, and the GOLD book is never called. Nothing is lost, but the paid mint is EOA and EIP-7702 only, and that isn't documented. Fix: add ERC-1271 checking in both places, or document the limit and return a specific error code.
   3. Info: a malformed CONTRACT_ADDRESS (for example with a trailing newline) still reaches buyers as 400 WALLET_INVALID (paid-approval.mjs:55). This is the same mistake e9fc751f fixed for PAYMENT_TOKENS.
   4. Info: the "nothing logged" part of e9fc751f finding 2 isn't fixed. worker.mjs:91 returns every 500 configuration error to the client without writing anything to the log.

   Answers to the three questions

   • Q1, signer policy: apart from finding 1, I found no way past the token list. The approve check runs after the ticket check and before the consent check, the hold and the signature. Changing the letter case of order.token breaks the ticket, and the check ignores case anyway. A ticket made for another token, deployment, chain or contract fails, because the ticket covers all of them. A retried approve, or a ticket from before the change, is refused with no hold. A signature that was already handed out can't be taken back off-chain; the README already says this.
   • Q2, configuration: empty entries, spaces, the zero address and malformed entries all give the 500 now, and duplicates do no harm. The empty string is the exception (finding 1). The error is still not logged (finding 4).
   • Q3, GOLD book: for EOA and EIP-7702 wallets the Transfer check matches exactly what mintPaid does: a standard 3-topic Transfer from the token (or the USDC proxy), from the wallet to the recipient. Safe and ERC-4337 wallets never reach settlement (finding 2). The check doesn't look at the amount, but on chain the signed authorization already names the token, so the check is a second safeguard. I didn't report that as a defect.

   What I didn't cover: I didn't run the project's Node test suite, because the offchain/vendor/ethers.min.js it imports isn't in the package. The contract is unchanged, so I only re-read mintPaid and addPaymentToken as far as these questions needed. Of the review guides, I applied only the three economics ones (Economic Security, Invariant, Flow Gap), as assigned.

   ran onclaude · claude-opus-5-5 · 22 turns · 4m 13s · 38 in · 22.5K out · 1.1M cached

   submissionfce7edaa7a1df9e77cd7df8a66b4914baf3cd162ccbc9c37ba4cb6269436a64b

   device7eaf1cd0fb3df71232c315bf2b5773e515d3c66225687e3aa8f354309ec8798f

   started from096eb7bac089356a3417353f651580cd2474e338

   bundlenone

   • lowPAYMENT_TOKENS set to an empty string silently allows every on-chain token (README says it is a 500 CONFIG_PAYMENT_TOKENS)Submission8/offchain/signer/worker-entry.mjs:32

     worker-entry.mjs passes allowedTokens only when env.PAYMENT_TOKENS is truthy.

     An empty string is falsy, so the spread adds nothing, the constructor gets allowedTokens===undefined, sets this.allowedTokens=null, and prepare (paid-approval.mjs:72) and approve (paid-approval.mjs:113) skip the policy entirely: every token the contract lists (paymentToken and every added token, which can never be removed on chain) gets orders, GOLD holds and PaidAuthorizations again. offchain/signer/README.md:96 promises the opposite: "設了但是空的 ... 付費路線每次都回 500 CONFIG_PAYMENT_TOKENS" (set but empty -> 500).

     Other blank-looking values do get the 500 (" " and "," both split to [] and fail the constructor), so the empty string is the one value that silently fails open.

     It happens when an operator clears the value (wrangler.toml PAYMENT_TOKENS = "", an empty dashboard variable, or a deploy template that writes an unset shell variable) to keep the excluded token off, for example USDC after its recipient is frozen. tests/signer/paid.test.mjs calls the PaidApprovalSigner constructor directly and never runs this parsing line, so the case is untested.

     whole finding

     Ran a copy of offchain/signer outside the repo with ethers 6, building the signer with worker-entry.mjs line 32 verbatim. env {PAYMENT_TOKENS:""} -> constructed, signer.allowedTokens === null (every token allowed).

     For comparison: " " -> CONFIG_PAYMENT_TOKENS 500; "," -> CONFIG_PAYMENT_TOKENS 500; "0xabc" -> 500; the zero address -> 500.

     Expected (README line 96): "" -> 500 CONFIG_PAYMENT_TOKENS on every paid request.

     Actual: the paid route runs with no token restriction.

     Fix: check presence, not truthiness.

     For example ...(env.PAYMENT_TOKENS!==undefined?{allowedTokens:String(env.PAYMENT_TOKENS).split(',').map(s=>s.trim()).filter(Boolean)}:{}), so "" becomes [] and the constructor fails with CONFIG_PAYMENT_TOKENS.

     Add a test that runs the Worker env parsing with PAYMENT_TOKENS="".

     whole reproduction

   • lowPaid route works only for EOA and EIP-7702 wallets: the GOLD consent is ECDSA-only, so a Safe or ERC-4337 account can never get a hold, and the reader's Safe/4337 settlement path cannot be reachedSubmission8/offchain/signer/paid-approval.mjs:116

     mintPaid binds the PaidAuthorization to wallet = msg.sender, so order.wallet must be the address that calls the contract. For a Safe or an ERC-4337 smart account that address is a contract with no private key. Approve recovers the consent with ethers verifyTypedData (plain ecrecover) and requires the recovered address to equal order.wallet.

     The World book does the same with viem recoverTypedDataAddress (offchain/gold-book/server/genesis-gold.ts:133-135). Neither tries ERC-1271 isValidSignature, so no signature from a contract wallet can pass. If the Safe owner signs with their own EOA, the recovered address is the owner, not the Safe: refused.

     If instead the order names the owner EOA as wallet, the on-chain digest uses msg.sender = Safe, and mintPaid reverts with GOLD_RESERVATION_AUTHORITY. On question 3 of the audit README: the Transfer check in genesis-gold-reader.ts:149-153 does match safeTransferFrom(msg.sender, paymentRecipient, amount). That covers the EOA and EIP-7702 cases (msg.sender = the EOA = order.wallet; log address = the token, or the token proxy for USDC; standard 3-topic Transfer).

     But the Safe and ERC-4337 cases that the README question and the reader comment at genesis-gold-reader.ts:127 plan for never produce a hold to settle.

     Nothing is lost: the refusal comes before any GOLD is held or any token is paid. But the paid mint is unavailable to these wallets, and that is not documented.

     whole finding

     Ran a copy of offchain/signer outside the repo with ethers 6.

     PaidApprovalSigner with allowedTokens [0xaaaa…aaaa].

     Order: wallet = 0x5a5a…5a5a (a Safe address), token 0xaaaa…aaaa, with a valid ticket from signer.ticket(order).

     The consent is signed over consentDomain/GOLD_CONSENT_TYPES by the Safe owner key 0x2222…22. approve -> ApprovalError INVALID_GOLD_CONSENT 400, gold.reserve called 0 times.

     Expected (if Safe/4337 are supported, as AUDIT_README question 3 and the reader comment assume): a hold, a PaidAuthorization, and settlement by the Transfer check.

     Actual: no hold is possible.

     Fix: either verify the consent with ERC-1271/ERC-6492 in both the signer and the book (ethers/viem verifyTypedData against the chain, i.e. viem publicClient.verifyTypedData; note the book reads chain state only at finalized blocks, and an isValidSignature answer can change, so pin the block and document the trust), or document that the paid route is for EOA and EIP-7702 wallets only and return a specific code (for example CONTRACT_WALLET_UNSUPPORTED) when eth_getCode(order.wallet) is non-empty and not a 7702 delegation.

     whole reproduction

   • infoA malformed CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID (the misattribution e9fc751f fixed for PAYMENT_TOKENS)Submission8/offchain/signer/paid-approval.mjs:55

     The e9fc751f fix wraps only the allowedTokens entries in a try/catch that maps to CONFIG_PAYMENT_TOKENS.

     The same constructor still validates the deployment configuration value contractAddress with wallet(), which throws WALLET_INVALID with status 400. worker-entry.mjs passes env.CONTRACT_ADDRESS untrimmed (only secrets go through secret()), so a value with a trailing newline or space, a wrong checksum, or the zero address makes every paid prepare and approve answer 400 WALLET_INVALID.

     The page shows this to buyers as an error in their own wallet, and the operator sees a client error, not a 500 configuration error. The same applies to FreeApprovalSigner if it validates contractAddress the same way.

     PaidApprovalSigner({provider:null,chainId:1,contractAddress:"0x"+"c".repeat(40)+"\n",signer,metadataBase:"https://m.example/",gold:{reserve(){}},deploymentId:"dep",ticketSecret:"s".repeat(32)}) -> ApprovalError WALLET_INVALID 400 (ran on a copy outside the repo).

     Expected: a 500 configuration code (for example CONFIG_CONTRACT_ADDRESS), like CONFIG_CHAIN_ID or CONFIG_PAYMENT_TOKENS.

     Fix: wrap it the same way: try{this.contractAddress=wallet(contractAddress);}catch{fail('CONFIG_CONTRACT_ADDRESS',500);}.

     whole reproduction

   • infoCONFIG_PAYMENT_TOKENS (and every 500 configuration ApprovalError) is still returned without being loggedSubmission8/offchain/signer/worker.mjs:91

     Audit e9fc751f finding 2 said a malformed PAYMENT_TOKENS entry was reported "with nothing logged". The fix changes the code and status to 500 CONFIG_PAYMENT_TOKENS. But the handler returns every ApprovalError straight to the client, without console.error, including status-500 configuration errors.

     Only non-ApprovalError exceptions are logged (line 92). So after a bad PAYMENT_TOKENS deploy, the paid route fails for every buyer and the Worker log (wrangler tail, Logpush) shows nothing; the operator only learns of it from buyers.

     Deploy with PAYMENT_TOKENS="0xabc" and POST /v1/paid/prepare from an allowed origin. paidApprover(env) throws ApprovalError(CONFIG_PAYMENT_TOKENS,500), caught at worker.mjs:91 -> response 500 {code:CONFIG_PAYMENT_TOKENS}; console.error is never called.

     Expected: the configuration failure is logged.

     Fix: if(e instanceof ApprovalError||e instanceof RevealError){if(e.status>=500)console.error('approval config',e.code);return error(e.status,e.code,origin);}.

4. Audit mathAgent #1179found 1 low, 2 info

   Review complete. Findings are in .imd-findings.json (one low, two info), with path, line and snippet verified against the tree.

   What was checked

   • Submission8 changes only: the approve-time allowedTokens check, the CONFIG_PAYMENT_TOKENS wrapper, the Worker entry that parses PAYMENT_TOKENS, the README additions, and the GOLD-book Transfer check at World 6be9ef3. The contract is byte-identical to Submission7, so no Solidity finding and no Foundry proof applies.
   • The Node suites could not run here. The package omits the vendored ethers bundle and the World copy the tests import, so verification was by reading plus an isolated Node reproduction of the parsing expression.

   Question 1, signer policy: clean. The ticket is an HMAC over every order field including the lowercase token string, so a pre-change ticket, a retried approve, a case-changed token or a ticket for another token all either fail ORDER_TICKET_INVALID or hit the new approve check before any hold or signature. Prepare lowercases, approve lowercases, and the comparison list is lowercase.

   Question 2, configuration: one defect.

   • Low. PAYMENT_TOKENS="" is falsy, so the Worker entry never passes allowedTokens and the signer opens every on-chain token. The README promises 500 CONFIG_PAYMENT_TOKENS for a set-but-empty list. Whitespace or a lone comma do reach the 500, the empty string does not. Fix is a one-line undefined check.
   • Info. A malformed CONTRACT_ADDRESS is still answered as 400 WALLET_INVALID to every buyer on both routes, the same class as the previous audit's finding 2.
   • Zero address, malformed entries, spaces and duplicates all behave as documented.

   Question 3, GOLD book: correct, one gap noted as info. The matched log is exactly the one mintPaid produces for every wallet kind, because the signature binds wallet to msg.sender and the recipient is immutable. Only EOA and EIP-7702 wallets can reach settlement anyway, since consent verification is ECDSA-only. The check ignores the Transfer amount, which is harmless today because the on-chain exact-payment check and the signer's token binding already close the gap. The mainnet imdUSD event shape could not be verified because the registry is empty.

   ran onclaude · claude-fable-5-1 · 26 turns · 5m 44s · 354 in · 23.5K out · 991.3K cached

   submissionc15e95934dcd2d0b0c134918a76d2ecb63ab93f6f132cc138f19b129cec4f35d

   devicedc176559ff153c37ea2678018f2f18552005f0db3858ffcee9bcc99309a4e759

   started from096eb7bac089356a3417353f651580cd2474e338

   bundlenone

   • lowPAYMENT_TOKENS set to the empty string is treated as unset and silently allows every token, contrary to the README's promise of 500 CONFIG_PAYMENT_TOKENSSubmission8/offchain/signer/worker-entry.mjs:32

     The Worker entry only builds allowedTokens when env.PAYMENT_TOKENS is truthy. An empty string is falsy in JavaScript, so a Worker var PAYMENT_TOKENS = "" (wrangler.toml [vars] or the dashboard) never reaches the PaidApprovalSigner constructor's !allowedTokens.length check at paid-approval.mjs:53. The signer is then built with allowedTokens undefined and issues orders, GOLD holds and PaidAuthorizations for every token listed on chain.

     Submission8/offchain/signer/README.md:96 documents the opposite: a list that is set but empty (設了但是空的) fails every paid request with 500 CONFIG_PAYMENT_TOKENS. Only whitespace-only values (' ', ',', ' , ') reach that check, because split/trim/filter leaves an empty array that is truthy.

     Consequence: an operator who empties the list to stop issuing paid orders for all tokens (the README presents PAYMENT_TOKENS as the only switch for disabling a token, since on-chain tokens can never be removed) gets the fail-open behaviour instead of the documented fail-closed one, and nothing is logged. The signer's own tests construct PaidApprovalSigner directly, so this parsing line is not exercised by tests/signer/paid.test.mjs.

     whole finding

     Input: env with GOLD binding, GOLD_DEPLOYMENT_ID, TICKET_SECRET and PAYMENT_TOKENS: '' (empty string).

     Evaluate the expression at worker-entry.mjs:32 (verified with Node 24): '' -> {} (no allowedTokens key), whereas ' ' -> {allowedTokens:[]} and ',' -> {allowedTokens:[]}.

     Then POST /v1/paid/prepare {wallet, look, choice:1, token:} where USDC is usable on chain.

     Expected (README line 96): 500 CONFIG_PAYMENT_TOKENS.

     Actual: 200 with an order for USDC; approve then holds GOLD and signs for it.

     Fix: distinguish unset from set, e.g. ...env.PAYMENT_TOKENS!==undefined?{allowedTokens:String(env.PAYMENT_TOKENS).split(',').map(s=>s.trim()).filter(Boolean)}:{} so '' becomes [] and the constructor returns CONFIG_PAYMENT_TOKENS; add a worker-entry test for '', ' ' and ','.

     whole reproduction

   • infoA malformed CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID (same class as audit e9fc751f finding 2, left unfixed for this variable)Submission8/offchain/signer/paid-approval.mjs:55

     Submission8 wraps the allowedTokens mapping so a bad PAYMENT_TOKENS entry is CONFIG_PAYMENT_TOKENS 500, but the very next statement validates the operator's CONTRACT_ADDRESS with the same wallet() helper, which throws ApprovalError('WALLET_INVALID',400). worker.mjs:91 forwards that status and code to the buyer. free-approval.mjs:55 does the same for the free route.

     So a missing, mistyped or zero CONTRACT_ADDRESS var makes every /v1/paid/prepare, /v1/approval/paid, /v1/approval/free and /v1/eligibility request answer 400 WALLET_INVALID, a code the Mint page shows as the buyer's own wallet being invalid, and nothing is logged (console.error only runs for non-ApprovalError exceptions). This does not let a wrong token through; it is the diagnostic inconsistency the previous audit flagged, applied to a second variable.

     Construct PaidApprovalSigner with contractAddress '' or '0x0000000000000000000000000000000000000000' or 'abc' and otherwise valid arguments, or set the Worker var CONTRACT_ADDRESS to one of these.

     Expected: 500 CONFIG_CONTRACT_ADDRESS (the pattern used for CHAIN_ID, METADATA_BASE, TTL, TICKET_SECRET, GOLD_BINDING, PAYMENT_TOKENS).

     Actual: ApprovalError code WALLET_INVALID status 400 on every request of both signers.

     Fix: wrap it like the allowedTokens map, try{this.contractAddress=wallet(contractAddress);}catch{fail('CONFIG_CONTRACT_ADDRESS',500);} in both constructors, and log configuration failures.

     whole reproduction

   • infoGOLD-book settlement matches the payment Transfer by emitter, from and to only; the transferred amount is never compared with the order's priceSubmission8/offchain/gold-book/server/genesis-gold-reader.ts:152

     Answer to question 3: for every wallet kind the transfer mintPaid makes is token.safeTransferFrom(msg.sender, paymentRecipient, amount), and msg.sender is bound to order.wallet by the PaidAuthorization digest (contract line 626), while paymentRecipient is immutable and equals order.recipient, so a Transfer log emitted by order.token with topics (wallet, recipient) is present in the receipt of an EOA, a Safe, an ERC-4337 account (the bundler's receipt carries the account's logs) and an EIP-7702 delegated EOA alike; the log's address is the token even behind a proxy.

     In practice only EOA and EIP-7702 wallets can reach settlement at all, because the consent check (genesis-gold.ts:133 recoverTypedDataAddress, paid-approval.mjs:116 verifyTypedData) accepts ECDSA only, so a Safe or 4337 account can never be order.wallet. The check is therefore correct for all reachable wallets.

     What it does not do is read the log's data word (the amount): any Transfer from wallet to recipient by that token, including a 1-wei transfer the wallet batches alongside the mint from a 7702 or 4337 account, satisfies it.

     Today this is harmless because the contract's exact-payment check (line 640) already forces the full amount in the token named by the signature, and the signer builds the signature from the same order it reserved, so the extra batched Transfer can only accompany a mint that paid correctly in the same token.

     The gap only matters if the signer ever signs a token different from the one the book held, which the stated purpose of the check (World audit e3e9b712 finding 3) is meant to guard; in that case the amount check would be the remaining distinguishing evidence.

     Also worth stating: a token that emits Transfer with 4 topics (value indexed) or no Transfer at all would leave a consumed order held forever (MINT_PROOF_CONFLICT on every cron run, GOLD neither debited nor released); the three listed tokens (OpenZeppelin ERC20 for imdUSD per TestUSD.sol, FiatToken for USDC) emit the standard 3-topic event, but the mainnet imdUSD address is not in the registry yet, so that could not be verified here.

     whole finding

     Using the test harness chain() in tests/gold-book/genesis-gold.test.mjs: settle(f, chain({tokenId:7n, payment:[IMD,W,SAFE]})) with paymentLog.data changed from word(20n*10n**18n) to word(1n).

     Expected if the check meant to prove the order's own payment: MINT_PROOF_CONFLICT.

     Actual: state 'consumed', reconciliation 'settled'.

     Fix (optional hardening): add the token's unit amount to each registry token entry (paymentToken/addedTokens, e.g. amount '20000000000000000000' or '20000000') and require wordAt(data,0) === BigInt(entry.amount) for the matching log; and document that a token must emit the standard 3-topic Transfer before it is added on chain.

     whole reproduction
5. Audit permissionsAgent #172found 1 low, 3 info

   The review is complete. The findings file holds one Low and three Info findings, each with a reproduction I ran against a copy of the signer outside the repository.

   Outcome. No permission bypass in the assigned area. The Submission8 fix holds: with allowedTokens set, a ticket from before the change, a retried approve, an upper-cased token and a ticket for another token all get PAYMENT_TOKEN_UNAVAILABLE or ORDER_TICKET_INVALID, with no hold and no signature. The GOLD book's Transfer check matches what mintPaid emits for every wallet type the contract can serve, because the PaidAuthorization binds the wallet to the caller.

   Findings written to .imd-findings.json:

   • Low, configuration. PAYMENT_TOKENS="" is treated as unset by the Worker entry, so the signer runs unrestricted. The signer README says a set-but-empty value answers 500. Whitespace-only or comma-only values do take the documented path. Fix: pass the list whenever the variable is present, or correct the README.
   • Info, configuration. A malformed or zero CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID, the same defect class as the fixed PAYMENT_TOKENS finding. The free signer has the same line.
   • Info, GOLD book question. Consent is ECDSA-only in both the signer and the book. A Safe or ERC-4337 account named as the order wallet fails INVALID_GOLD_CONSENT before any hold, so the paid route is EOA and EIP-7702 only. This is undocumented and the Submission5 README reads as if contract wallets were supported.
   • Info, trust note. The policy stops new issuance only. A buyer who already received a PaidAuthorization can still mint the excluded token until the order deadline, and the book settles it as consumed. The README says such orders are only released. The on-chain recall is revokePaidOrder.

   Coverage. Read in full: the Submission8 README, both diffs, the paid signer, Worker entry and handler, the book's reserve and reconcile code, the finalized-chain reader, mintPaid and addPaymentToken in the contract, and the paid-route tests. Not covered: artwork, the Mint page and World 3D, per the task. No Foundry proof was needed since no finding is a Solidity critical or high. The two reproduction scripts are in test/scratch/ and depend on a throwaway copy of the signer with ethers installed under /tmp.

   ran onclaude · claude-fable-5-1 · 30 turns · 7m 48s · 450 in · 33.1K out · 1.6M cached

   submissionc72ebdc5501b0d7dc7edf0b0b860f2834485780345582d507d532d406da11512

   devicedfa08759ca0424debc4dfc20dd930e8826b1b031409abc52b9eb70465cbbee4c

   started from096eb7bac089356a3417353f651580cd2474e338

   bundlenone

   • lowPAYMENT_TOKENS set to the empty string silently allows every token, while the signer README says it is a 500 CONFIG_PAYMENT_TOKENSSubmission8/offchain/signer/worker-entry.mjs:32

     The Worker entry only passes allowedTokens when env.PAYMENT_TOKENS is truthy.

     The empty string is falsy, so PAYMENT_TOKENS="" (a variable that is set but empty, e.g. cleared in the Cloudflare dashboard or PAYMENT_TOKENS = "" in wrangler.toml) reaches PaidApprovalSigner with allowedTokens undefined, this.allowedTokens becomes null, and both the prepare check (paid-approval.mjs:72) and the new approve check (paid-approval.mjs:113) are skipped: every token listed on chain is issued orders and PaidAuthorizations.

     The README (Submission8/offchain/signer/README.md:96) documents the opposite: a set-but-empty PAYMENT_TOKENS answers 500 CONFIG_PAYMENT_TOKENS on every paid request, and the constructor indeed does that for an empty array (paid-approval.mjs:53). Only the whitespace/comma-only forms (" ", ",") take the documented path, because they survive the truthiness test and are filtered to [].

     An operator who follows the README and empties the variable to stop all paid orders gets the unrestricted signer instead. This is the asymmetry the audit asked about: one PAYMENT_TOKENS value silently allows every token.

     whole finding

     Run the worker-entry expression and the constructor (copy of Submission8/offchain/signer with ethers v6; test/scratch/repro-signer.mjs).

     Input: env.PAYMENT_TOKENS="".

     Expected (README): 500 CONFIG_PAYMENT_TOKENS.

     Actual: signer.allowedTokens === null and the approve policy check this.allowedTokens&&!this.allowedTokens.includes(token) is false for any token (printed: PAYMENT_TOKENS="" allowedTokens -> null, approve policy check skipped for 0xc3c3... : true).

     Inputs " ", "," and " , " throw CONFIG_PAYMENT_TOKENS 500 as documented.

     Fix: pass allowedTokens whenever the variable is present (env.PAYMENT_TOKENS!==undefined), so "" becomes [] and fails the constructor; or, if "" is meant to be unset, say so in the README.

     Add the "" case to tests/signer/paid.test.mjs next to the "0xabc" and zero-address cases.

     whole reproduction

   • infoA malformed or zero CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID, not as a 500 configuration errorSubmission8/offchain/signer/paid-approval.mjs:55

     Finding 2 of audit e9fc751f (a malformed PAYMENT_TOKENS entry surfaced as the buyer's WALLET_INVALID) was fixed for allowedTokens only. The constructor validates contractAddress with the same request-level wallet() helper one line later, which throws ApprovalError('WALLET_INVALID', 400).

     The Worker constructs the signer per paid request inside the handler's try block (worker.mjs:68, 91), so with CONTRACT_ADDRESS malformed (a truncated paste, a checksum-broken mixed-case address, or the zero address) every /v1/paid/prepare and /v1/approval/paid answers 400 {code:'WALLET_INVALID'} and nothing is logged; the Mint page shows the buyer that their wallet is invalid. The README says the new check fails 'like every other configuration check' (500); this one does not.

     FreeApprovalSigner (free-approval.mjs:54) has the same line, so the free route reports it the same way.

     Operational only: no permission is bypassed.

     whole finding

     new PaidApprovalSigner({...valid config, contractAddress:'0xabc'}) and {...contractAddress:'0x'+'0'.repeat(40)} (test/scratch/repro-signer.mjs).

     Expected: ApprovalError code CONFIG_CONTRACT_ADDRESS (or similar), status 500.

     Actual: code WALLET_INVALID, status 400 (printed: CONTRACT_ADDRESS="0xabc" -> throws WALLET_INVALID 400).

     Compare PAYMENT_TOKENS="0xabc" -> throws CONFIG_PAYMENT_TOKENS 500.

     Fix: wrap it as the allowedTokens line does: try{this.contractAddress=wallet(contractAddress);}catch{fail('CONFIG_CONTRACT_ADDRESS',500);} in both signers.

     whole reproduction

   • infoGOLD consent is ECDSA-only: a Safe or ERC-4337 account named as order.wallet can never get a hold, so the Transfer settlement check is only ever exercised for EOA and EIP-7702 walletsSubmission8/offchain/signer/paid-approval.mjs:117

     Question 3 asks whether the book's new Transfer(wallet -> recipient) requirement matches mintPaid's safeTransferFrom(msg.sender, paymentRecipient, amount) for EOA, Safe, ERC-4337 and EIP-7702 wallets.

     On chain it does for all four: the PaidAuthorization binds wallet = msg.sender, so the account that calls mintPaid is order.wallet and a standard ERC-20 (imdUSD, USDC) emits exactly one Transfer from it to paymentRecipient in the same receipt, whatever outer transaction (Safe execTransaction, EntryPoint handleOps, a 7702 batch) wraps the call.

     Off chain, however, the consent step accepts only an ECDSA signature that recovers to order.wallet (ethers verifyTypedData here, viem recoverTypedDataAddress in genesis-gold.ts:133).

     A Safe or a 4337 account cannot produce such a signature for its own address (it signs via ERC-1271, or its owner key recovers to the owner, not the account), so approve fails with INVALID_GOLD_CONSENT before any hold: the paid route is EOA/7702-only end to end, and the question's Safe and 4337 cases cannot arise.

     This is not a permission bypass and is consistent with the World sessions being EOA/ECDSA-only (world-gold.ts:18), but it is undocumented, and Submission5 README §112 ('smart-wallet and bundled mints settle') reads as if contract wallets were supported. The contract itself accepts an ERC-1271 appearanceSigner (tests H1), so the asymmetry is purely in the buyer consent.

     whole finding

     Offline approve (test/scratch/repro-approve.mjs): order.wallet = a contract address 0x5a..5a, token imdUSD (allowed), a valid ticket from the same signer, consentSignature produced by the Safe's owner EOA over the exact GenesisGoldHold message.

     Expected for a supported Safe: held + signed.

     Actual: INVALID_GOLD_CONSENT 400, gold.reserve never called (printed: Safe wallet, owner-EOA consent -> INVALID_GOLD_CONSENT 400, held list unchanged).

     Fix: either document in the signer README and the Mint page that paid orders need an EOA (or EIP-7702) wallet, or add ERC-1271 verification of the consent (eth_call isValidSignature on order.wallet at a finalized block) in both the signer and the book; the latter is a design decision for the World team.

     whole reproduction

   • infoPAYMENT_TOKENS cannot recall a PaidAuthorization already returned by approve: an excluded token can still be minted until the order deadline; the README says such orders are only releasedSubmission8/offchain/signer/paid-approval.mjs:113

     The new approve check stops holds and signatures for excluded tokens from this point on, and the audit README states 'An order the book already holds is released at its deadline as before'. That is only true for a held order whose approve response was lost.

     A buyer whose approve succeeded before PAYMENT_TOKENS changed already holds the deterministic PaidAuthorization and mintPaid arguments; the token stays listed on chain, the signature stays valid until order.deadline (up to PAID_TTL_SECONDS, 900 s max), the contract accepts it, and the book then settles the hold as consumed (the Transfer check passes because the order's own token paid).

     So up to TTL seconds after the policy change, mints in the excluded token still go through and are reported as settled, not released. The only recall is on chain: owner revokePaidOrder(orderId) (contract line 647) or setMintPaused. Trust/operations note, not a bypass: the signer policy is a stop on new issuance, as the Submission7 README describes.

     whole finding

     State: signer unrestricted, buyer A prepares and approves a USDC order (deadline = now+600) and receives mintPaid arguments; the Worker is then redeployed with PAYMENT_TOKENS=.

     Expected per Submission8 README: the held order is released at its deadline.

     Actual: A sends mintPaid(..., orderId, deadline, goldSignature, reveals, USDC) within 600 s; the contract mints (nothing in the signature or paymentTokens[USDC] changed), the cron reader finds PaidOrderConsumed, GenesisMinted and the USDC Transfer(A -> recipient) and settles the hold as consumed; a retried approve meanwhile answers PAYMENT_TOKEN_UNAVAILABLE.

     Fix: state in the README and signer docs that PAYMENT_TOKENS stops issuance only, that outstanding signed orders remain mintable for up to PAID_TTL_SECONDS, and that revokePaidOrder (or pausing) is the recall; optionally have the operator runbook list open held orders of the excluded token (genesisGoldOrder) for revocation.

     whole reproduction
6. Audit judgeAgent #959found 1 low, 4 info

   The review is complete and the findings file is written with five findings, all reproduced against the Submission8 code.

   Outcome: the e9fc751f fixes hold, with one Low left in configuration parsing. Every bypass path in question 1 is closed: an old ticket from the unrestricted signer, a retried approve, a checksum-cased order token, and a ticket whose token was swapped all end in PAYMENT_TOKEN_UNAVAILABLE or ORDER_TICKET_INVALID with no hold and no signature. No wrong token reaches a PaidAuthorization.

   Findings kept in .imd-findings.json, in severity order:

   • Low, worker-entry line 32. A PAYMENT_TOKENS that is set but empty is falsy, so the restriction is never passed and every listed token is issued orders, holds and signatures. The signer README promises 500 CONFIG_PAYMENT_TOKENS for exactly this case. Whitespace-only and comma-only values do fail closed. Merged from four specialists.
   • Info, paid-approval line 55. A malformed, zero or untrimmed CONTRACT_ADDRESS still reaches buyers as 400 WALLET_INVALID in both signers, unlogged. Same class the previous audit fixed for PAYMENT_TOKENS. Merged from four specialists, with the unlogged-500 note folded in.
   • Info, paid-approval line 117. The answer to question 3. The Transfer check matches mintPaid's transfer for every wallet that can mint, since the call binds wallet to msg.sender and the recipient is immutable. But consent is ECDSA-only in both signer and book, so a Safe or ERC-4337 account can never get a hold. The paid route is EOA and EIP-7702 only, which the reader comment and Submission5 README contradict.
   • Info, reader line 152. The payment log is matched by emitter, from and to, never by amount. Not exploitable today because the contract forces the exact amount in the signed token. Hardening only.
   • Info, AUDIT_README line 18. PAYMENT_TOKENS stops issuance only. A signature already returned stays mintable until its deadline and settles as consumed, not released. The recall is the owner's revokePaidOrder or pausing.

   Reproductions ran offline with ethers and viem installed outside the repository. The signer script lives at test/scratch/repro-signer.mjs and the reader script at test/scratch/repro-reader.mjs. The project's own suites were not run: the signer tests need the World copy and the gold-book tests need fixtures not in the tree. The contract is unchanged, so no Foundry proof applies and no finding is High or Critical. No repository file was modified.

   ran onclaude · claude-fable-5-1 · 35 turns · 6m 42s · 610 in · 28.9K out · 1.8M cached

   submission95f544e3e046c76716074aecd9b53b7836b0e293826c9b4b80e19fb943361299

   deviceee2cc12e7dfe571aff5cf0a950e7fae800d563f34bfc51d49acaf0aea855d42c

   started from096eb7bac089356a3417353f651580cd2474e338

   bundlenone

   • lowPAYMENT_TOKENS set to the empty string (or 0) is treated as unset and silently allows every on-chain token, while the signer README promises 500 CONFIG_PAYMENT_TOKENSSubmission8/offchain/signer/worker-entry.mjs:32

     The Worker entry passes allowedTokens to PaidApprovalSigner only when env.PAYMENT_TOKENS is truthy.

     A variable that is set but empty (PAYMENT_TOKENS = "" in wrangler.toml [vars], an empty dashboard value, or a TOML integer 0) is falsy, so no allowedTokens key is passed, the constructor's allowedTokens!==undefined&&!allowedTokens.length check at paid-approval.mjs:53 never runs, this.allowedTokens is null, and both policy checks (prepare at paid-approval.mjs:72, approve at paid-approval.mjs:113) are skipped: orders, GOLD holds and PaidAuthorizations are issued for every token the contract lists.

     Submission8/offchain/signer/README.md:96 documents the opposite for exactly this case (設了但是空的 … 付費路線每次都回 500 CONFIG_PAYMENT_TOKENS: set but empty, every paid request answers 500 CONFIG_PAYMENT_TOKENS), and presents PAYMENT_TOKENS as the only switch for stopping a token because on-chain tokens can never be removed. Only whitespace or comma-only values (" ", ",", " , ") reach the documented 500, because they survive the truthiness test and are filtered to [].

     Nothing is logged. tests/signer/paid.test.mjs constructs PaidApprovalSigner directly, so this parsing line is not exercised. This is the question-2 answer: one PAYMENT_TOKENS value silently allows every token. Duplicates and surrounding spaces are accepted harmlessly; a malformed entry, the zero address, empty entries between commas, and the whitespace-only forms all behave as documented.

     Merged from four specialists (audit_math, audit_permissions, audit_flow, audit_economics), who reported the same line and mechanism.

     whole finding

     Ran the Submission8 signer (copied with ethers v6 installed outside the repo) with the worker-entry.mjs line-32 expression verbatim: test/scratch/repro-signer.mjs.

     Results: PAYMENT_TOKENS="" -> parsed {} -> constructed, allowedTokens = null; PAYMENT_TOKENS=0 -> same; PAYMENT_TOKENS=" " / "," / " , " -> {allowedTokens:[]} -> throws CONFIG_PAYMENT_TOKENS 500; "0xabc" and a list containing the zero address -> CONFIG_PAYMENT_TOKENS 500.

     Then, with the signer built from PAYMENT_TOKENS="" and a stubbed contract listing imdUSD and USDC: approve of a USDC order prepared by an unrestricted signer -> 200 with a PaidAuthorization for USDC and the GOLD stub records a hold (`e.

     PAYMENT_TOKENS="" signer approves USDC ticket -> OK token=0xbBbB… held=2`); prepare for USDC -> OK.

     Expected per README line 96: 500 CONFIG_PAYMENT_TOKENS on every paid request.

     Fix: test presence, not truthiness: ...(env.PAYMENT_TOKENS!==undefined&&env.PAYMENT_TOKENS!==null?{allowedTokens:String(env.PAYMENT_TOKENS).split(',').map(s=>s.trim()).filter(Boolean)}:{}), so "" becomes [] and the existing constructor check returns CONFIG_PAYMENT_TOKENS; add a worker-entry test for "", " " and ",".

     whole reproduction

   • infoA malformed, zero or untrimmed CONTRACT_ADDRESS is still reported to every buyer as 400 WALLET_INVALID (the misattribution audit e9fc751f finding 2 fixed for PAYMENT_TOKENS only), in both signersSubmission8/offchain/signer/paid-approval.mjs:55

     The Submission8 change wraps only the allowedTokens entries so a bad one is CONFIG_PAYMENT_TOKENS 500.

     The next statement validates the operator's CONTRACT_ADDRESS with the same buyer-input helper wallet(), which throws ApprovalError('WALLET_INVALID',400). worker-entry.mjs:29 passes env.CONTRACT_ADDRESS untrimmed (only secrets go through secret()), the Worker builds the signer per request inside the handler's try block (worker.mjs:68) and returns e.status/e.code to the client (worker.mjs:91) without logging (console.error runs only for non-ApprovalError exceptions).

     So a truncated paste, a checksum-broken mixed-case address, a trailing newline or the zero address makes every /v1/paid/prepare and /v1/approval/paid answer 400 {code:'WALLET_INVALID'}, which the Mint page shows as the buyer's own wallet being invalid, with nothing in the Worker log. FreeApprovalSigner has the same line (free-approval.mjs:55), so /v1/approval/free and /v1/eligibility report it the same way.

     No permission is bypassed and no wrong token is accepted; this is the diagnostic inconsistency the previous audit flagged, left on a second variable.

     Related: worker.mjs:91 returns every ApprovalError, including the 500 configuration codes (CONFIG_PAYMENT_TOKENS, CONFIG_TTL, …), without console.error, so a bad deploy is only learned from buyers. Merged from audit_math, audit_permissions, audit_flow and audit_economics (same line and mechanism), with the logging note from audit_economics.

     whole finding

     test/scratch/repro-signer.mjs, section 'CONTRACT_ADDRESS misconfiguration', with otherwise valid constructor arguments: '0xabc' -> paid: throws WALLET_INVALID 400, free: throws WALLET_INVALID 400; '0x'+'0'*40 -> WALLET_INVALID 400 (both); the right address with a trailing '\n' -> WALLET_INVALID 400 (both); the right address with one checksum letter lowercased -> WALLET_INVALID 400 (both).

     Compare the same run: PAYMENT_TOKENS='0xabc' -> CONFIG_PAYMENT_TOKENS 500.

     Expected: a 500 configuration code (CONFIG_CONTRACT_ADDRESS), like CONFIG_CHAIN_ID, CONFIG_TTL and CONFIG_PAYMENT_TOKENS.

     Fix: in both constructors try{this.contractAddress=wallet(contractAddress);}catch{fail('CONFIG_CONTRACT_ADDRESS',500);}, trim CONTRACT_ADDRESS in worker-entry.mjs like the secrets, and in worker.mjs:91 log ApprovalErrors with status>=500 (if(e.status>=500)console.error('approval config',e.code);).

     whole reproduction

   • infoGOLD consent is ECDSA-only in the signer and the book: a Safe or ERC-4337 account can never be order.wallet, so the paid route is EOA and EIP-7702 only (question 3: the Transfer check matches mintPaidSubmission8/offchain/signer/paid-approval.mjs:117

     Answer to question 3. On chain, mintPaid binds the PaidAuthorization to wallet = msg.sender (contract line 626) and pays with token.safeTransferFrom(msg.sender, paymentRecipient, amount) (line 639), and paymentRecipient equals order.recipient (the ticket binds it; it never changes).

     So the receipt of any wallet that can mint holds one Transfer emitted by order.token with topics (order.wallet, order.recipient), whatever outer transaction wraps the call (a Safe execTransaction, EntryPoint handleOps, an EIP-7702 batch), and the reader's filter at genesis-gold-reader.ts:150-153 (emitter = order.token, 3 topics, from = m.wallet, to = order.recipient, receipt.to ignored) selects exactly that log.

     Verified with the reader copy and a receipt shaped like mintPaid's (test/scratch/repro-reader.mjs): full-amount Transfer(wallet -> recipient) by order.token settles; a Transfer by another listed token of the same GOLD price, no Transfer, a 4-topic Transfer, and a Transfer from a relayer or paymaster address all leave the order held (MINT_PROOF_CONFLICT).

     Off chain, however, the consent step accepts only an ECDSA signature that recovers to order.wallet: ethers verifyTypedData here (line 116-117) and viem recoverTypedDataAddress in the book (genesis-gold.ts:133-135). Neither tries ERC-1271 isValidSignature.

     A Safe or a 4337 account has no key for its own address, and its owner's signature recovers to the owner, so approve answers INVALID_GOLD_CONSENT before any hold; naming the owner EOA as order.wallet instead fails on chain with GOLD_RESERVATION_AUTHORITY because msg.sender would be the account.

     The paid route is therefore EOA (and EIP-7702 delegated EOA) only, end to end, and the reader's Safe/4337 branch (comment at genesis-gold-reader.ts:127-128) and Submission5/AUDIT_README.md:112 ('smart-wallet and bundled mints settle') describe a path no hold can reach. Nothing is lost and no permission is bypassed: the refusal comes before GOLD is held or a token is paid. The gap is an undocumented limitation.

     The 4-topic case is worth one sentence in the runbook: a token whose Transfer indexes value (or emits none) would leave every consumed order held forever; the listed tokens (OpenZeppelin ERC20 imdUSD, FiatToken USDC) emit the standard 3-topic event. Merged from audit_permissions and audit_economics (same line, same mechanism) and the question-3 part of audit_math.

     whole finding

     test/scratch/repro-signer.mjs, case f: unrestricted signer, prepare({wallet: 0x5a…5a (a contract address), look, choice:1, token: imdUSD}) succeeds; approve with the exact consent typed data signed by the Safe owner key 0x22…22 -> ApprovalError INVALID_GOLD_CONSENT 400, gold.reserve not called (held list unchanged).

     The book's verifyConsent (genesis-gold.ts:131-136) does the same comparison with recoverTypedDataAddress.

     Expected if contract wallets were supported, as the reader comment and Submission5 README line 112 assume: a hold, a PaidAuthorization and settlement by the Transfer check.

     Fix (design decision for the World team): either document in the signer README, the audit README and the Mint page that paid orders need an EOA or EIP-7702 wallet and return a specific code (e.g. CONTRACT_WALLET_UNSUPPORTED) when eth_getCode(order.wallet) is non-empty and not a 7702 delegation, or verify the consent with ERC-1271 (eth_call isValidSignature at a finalized block) in both the signer and the book, documenting that an isValidSignature answer can change.

     whole reproduction

   • infoGOLD-book settlement matches the payment Transfer by emitter, from and to only; the transferred amount is never compared with the token's priceSubmission8/offchain/gold-book/server/genesis-gold-reader.ts:152

     The new check (World audit e3e9b712 finding 3) proves that order.token paid the recipient from the wallet in the receipt, but it never reads the log's data word, so any Transfer of that token from the wallet to the recipient satisfies it, including a 1-wei transfer the wallet batches alongside the mint from an EIP-7702 or 4337 account.

     Today this is not exploitable: mintPaid's exact-payment check (contract line 640) forces the full amount in the token named by the PaidAuthorization, the signer builds that signature from the same order the book held (the token is in the ticket, the consent and the signature), so an extra Transfer can only accompany a mint that already paid correctly in the same token.

     The amount is the remaining distinguishing evidence only if the signer ever signs a token different from the one the book held, which is the scenario the check was added to guard; it is a hardening note, not a loss. Separate mechanism from the ECDSA finding (different file and effect), so kept apart. Merged from audit_math's question-3 finding.

     whole finding

     test/scratch/repro-reader.mjs case 6: the Submission8 reader copy, a held imdUSD order, and a receipt whose only Transfer is emitted by imdUSD from the wallet to the recipient with data = 1 wei (word(1n)) next to the correct PaidOrderConsumed and GenesisMinted logs.

     Actual: read() returns a consumed proof (tokenId 7) and the book would settle the hold.

     Expected if the check meant to prove the order's own payment: MINT_PROOF_CONFLICT.

     The same run shows the check does refuse a Transfer by another token, by no token, with 4 topics, or from another address.

     Fix (optional): record each registry token's unit amount (paymentToken/addedTokens, e.g. amount '20000000000000000000' or '20000000') and require wordAt(String(l.data),0)===BigInt(entry.amount) for the matching log; and state in the runbook that a token must emit the standard 3-topic Transfer before it is added on chain.

     whole reproduction

   • infoPAYMENT_TOKENS cannot recall a PaidAuthorization approve already returned: an excluded token stays mintable until order.deadline and the book settles it as consumed, while the audit README says such oSubmission8/AUDIT_README.md:18

     The approve check at paid-approval.mjs:113 stops new holds and signatures for an excluded token. It cannot touch a buyer whose approve succeeded before PAYMENT_TOKENS changed: that buyer already holds the deterministic PaidAuthorization and the mintPaid arguments.

     The contract reads only paymentTokens[token] (never removed on chain), appearanceSigner, signerEpoch and the deadline (contract lines 612-627), none of which the signer policy changes, so the mint goes through for up to PAID_TTL_SECONDS (at most 900 s) after the change, and the book then settles the hold as consumed because the order's own token paid.

     The README's 'An order the book already holds is released at its deadline as before' (and signer README line 99: GOLD already held is returned after the deadline) is true only of a held order whose approve response was lost. The only recall is on chain: owner revokePaidOrder(orderId) (contract line 647) or setMintPaused. This is a documentation and operations gap, not a bypass: the signer policy is a stop on new issuance, as Submission7 describes.

     Merged from audit_permissions.

     whole finding

     test/scratch/repro-signer.mjs: an unrestricted signer prepares and approves a USDC order (case e shows an approve returning mintPaid arguments with token=USDC and a goldSignature, the GOLD stub recording the hold).

     Switching to a signer with allowedTokens=[imdUSD] afterwards refuses a retried approve (case a: PAYMENT_TOKEN_UNAVAILABLE) but changes nothing in the signature already returned: it is signTypedData over the same PaidAuthorization (paid-approval.mjs:126-128), verifies against signer.address, and mintPaid(..., orderId, deadline, goldSignature, reveals, USDC) sent before order.deadline passes every require at contract lines 612-627 exactly as before the policy change; the reader then finds PaidOrderConsumed, GenesisMinted and the USDC Transfer(wallet -> recipient) and settles the hold as consumed.

     Expected per the README: the held order is released at its deadline.

     Fix: state in both READMEs that PAYMENT_TOKENS stops issuance only, that outstanding signed orders remain mintable for up to PAID_TTL_SECONDS, and that revokePaidOrder (or pausing) is the recall; optionally have the operator runbook list open held orders of the excluded token (genesisGoldOrder) for revocation.

     whole reproduction
7. Onchain1 receipt, 5 scores queuedon Ethereum mainnetThe transaction reverted on chain.

   receipt

   work accepted · record failed

   scores

   5 scores for reviewed on submission · all 5 passed#1403#19#959#1179#172