I found one Low finding and nothing High or Critical. It is in .imd-findings.json (1 finding). I ran no tests: this package is TypeScript and Python, not Solidity, so there is no Foundry proof. It is also a partial tree, so the suite could not run here.

Finding (Low): squeek cosmetics can be sold outside the squeek checkout

Where: Submission28/source/server/world-gold.ts:69 (goldQuote), with WorldGoldPanel.tsx:141.

• Cause: after the release insert, the 11 cosmetics are ordinary enabled service products. With SQUEEK_SALES_ENABLED=1 they also count as serviceable. The generic /api/gold/quote and the GOLD panel's "Create order" button only check that a product is enabled, that its delivery is ready and that the service control is on.

• What they skip: the three checks the squeek checkout makes before creating an order:

  • salesOpen(): all 11 cosmetics enabled at 200 GOLD on their latest version.
  • The already-owned check.
  • The ordinary-wallet (EOA) check.

• Reproduction:

  1. The admin publishes version 2 of squeek-sky-meteors-v1 at 300 GOLD with the existing product command. Nothing stops this.
  2. checkout/quote now answers SALES_CLOSED and the catalogue shows salesEnabled:false.
  3. POST /api/gold/quote {product:'squeek-sky-meteors-v1',…} still creates a 300 GOLD order. It can be paid, it is delivered, and the wallet then owns the cosmetic.

• Side effects:

  • The panel offers cosmetics the wallet already owns. The refusal only comes at the signature step, and the panel has no error text for ALREADY_OWNED.
  • Orders made this way have no sq_ request id, so the game's lookup by its own purchase key can never find them.

• Fix: do one of these:

  • Have goldQuote refuse squeek-* products unless they come through the squeek checkout (its sq_ request id), and move the gate, ownership and EOA checks into the shared quote.
  • Put the 11×200 gate into SQL in the quote and debit.

  Also route the cosmetics in the panel to /squeek-checkout/, the way fortune products link to Celestao.

Checked and found sound

• Part C money:
  • SQUEEK_ONE_TIME_SQL is bound in the right order and runs in the same D1 batch as the debit.
  • It is limited to the same wallet and the same product, and skips other products.
  • Two tabs or two request keys can't both be charged. A replayed payment returns the already-paid order without a second debit.
  • Ownership disappears when a delivery fails or is refunded. A failed job can only move to refunded, never back to queued or delivered.
  • Refunds are done once per order.
  • Squeek orders are GOLD only, so the chain-payment code (which only marks EMBEO orders paid) never touches them.
• Part C identity:
  • The code is single-use and checked against PKCE and the fixed redirect.
  • The grant row is created in the same batch as the code is consumed, and the grant is tied to the live World session, so World logout ends it.
  • Reads are limited to the grant's own wallet.
  • CORS allows only the game's origin and no credentials.
  • The Bearer grant reaches no route that changes state except its own logout.
• Part C checkout:
  • checkout/quote requires a same-origin request and a JSON body, so it is not open to CSRF.
  • A request key reused for another cosmetic answers 409.
  • Contract wallets are refused at quote time and again inside the payment SQL.
• Part A:
  • The failed-run rename in vault.prepare is atomic and suffixed with the row's unique id. It holds against lapse/retire, forget_unpaid and pruning, and late deliveries look rows up by id, not request id.
  • The 409/422 mapping in paid.py matches the request.
  • withinGrantLeft and the new backup sentence match the request.

Not covered or not verified

• Wallet switch: I could not confirm that a wallet switch revokes the old World session, which the grant depends on. The current auth.ts is not in the package; the only copy is

I found three Low issues in Submission28 and nothing at Critical, High or Medium. All three are in Submission28/source/server/squeek-store.ts and are written to .imd-findings.json; the file parses and each quoted line matches the file. This was a reading review only: I ran no tests and changed no files. No finding is in Solidity, so none carries a Foundry proof.

Findings

1. Low: rate limits on the token and Bearer routes can be dodged (line 120, and lines 199–200). POST /api/squeek/token is public, but its limit is counted per authorization code, and the caller picks the code. Sending a fresh random 43-character code each time never hits the limit. Every such request still runs a two-statement database batch and returns 401 instead of 429. The Bearer routes have the same flaw, and they also look the grant up in the database before checking the limit. The same keying works in celestao-auth.ts only because that endpoint first requires a backend secret. Fix: limit by client IP before any database access, and move the Bearer-route limit above readSqueekGrant.

2. Low: the game's pseudonym can be traced back to the wallet (line 47). The subject id is a plain SHA-256 of 'squeek-subject-v1:'+address, with no server key. For example, 0x1111…1111 always gives sq_e2083d592e16e353e42caff5af6947ede8103b46. Anyone holding a list of candidate wallets can match a subject id to the full address. The shortened wallet shown next to it narrows the list. That undoes the request's claim that the game does not see the full address. Fix: compute the id with an HMAC under a Worker secret; the game still gets a stable id.

3. Low: /api/squeek/authorize issues a code with no user action (line 114). The session cookie is SameSite=Lax, so any site can send a signed-in user's browser to authorize with its own PKCE challenge and state. The user gets an immediate 303 to the game carrying a code for their wallet. The consent page only appears when the user is signed out. PKCE stops the code being injected into the real game. But keeping the code secret then depends on the game page, which is not in this package. If it leaks within 60 seconds, the third party gets a 60-minute read-only grant. Fix: issue codes only when Sec-Fetch-Site is same-origin or none; otherwise send the user to /squeek-connect/, so its Continue button is the consent.

Checked with no defect found

• Part C money:
  • Two tabs, retries and replays: two tabs with two request keys, an order made through the generic /api/gold/quote, retries, and a replayed payment all end in at most one charge. SQUEEK_ONE_TIME_SQL sits inside the debit batch, and the code then throws ALREADY_OWNED.
  • Other products and wallets: the one-time rule does not block other products or other wallets. Its placeholder order matches its bind values.
  • Ownership and refunds:
    • Ownership ends as soon as a delivery fails, because failed and refunded both count as not owned.
    • A refund needs a failed delivery, and a delivery can never move from failed back to delivered.
    • The refund credit is idempotent through its reference.
• Part C identity:
  • Grant revocation: the grant dies with its World session on logout, and a wallet switch revokes the old session.
  • Code exchange: codes are single-use and bound to PKCE and the redirect.
  • Read routes: every read is tied to the grant's own wallet.
  • Read-only scope: the read-only grant reaches no route that changes state except its own logout, and no other route accepts it.
• Part C checkout:
  • CSRF: the quote requires the same Origin and a JSON body, so cross-site CSRF is blocked.
  • Request keys and expiry: a key reused for another cosmetic returns 409, and an expired order cannot be paid.
  • Contract wallets: they are refused both at the quote and at the payment.
• Part A:
  • The rename: I traced it against the op

I found two Low findings in Part C. Nothing I could reproduce lets anyone own a cosmetic without paying, pay twice for one, keep one after a refund, steal a grant, or change state with the read-only grant. Both findings are in .imd-findings.json. Neither has a Foundry proof, because nothing in scope is Solidity and the proof rule only covers critical or high Solidity findings.

Findings

1. Low: two rate limits can be sidestepped by the caller (server/squeek-store.ts:199–200 and :120).

   • The limiter in worker/app.ts uses the key exactly as passed, with no IP added. On the game's Bearer routes the key is a hash of the token, and on /api/squeek/token it is a hash of the code. The caller chooses both.
   • So a request with a new random 43-character token or code always gets a fresh limit. Also, the grant lookup (a D1 read) runs before the limit check.
   • Reproduction: send GET /api/squeek/snapshot many times from one IP, each time with a new random Bearer value. Every request runs the D1 read and gets 401; none gets 429. The same happens on /api/squeek/token, which runs its D1 write batch each time.
   • Fix: check a per-client limit before any database access, keep the per-token limit as a second one, and move readSqueekGrant after both checks.

2. Low: the "pseudonym" can be turned back into the wallet address (server/squeek-store.ts:47).

   • It is a plain sha256 of a fixed prefix plus the address, with no server secret. Wallet addresses are public, so anyone who sees a subject_id can find the wallet by hashing a list of candidate addresses.
   • The walletHint next to it (first 4 and last 4 hex digits) narrows the candidates sharply. This contradicts part C.1's claim that the game sees a pseudonym, not the address.
   • Fix: derive it as an HMAC with a server-held key, and drop the hint or document that the game is trusted with the address.

What I checked and rejected

• Part C money:
  • The one-time check inside the debit has its values in the right order and only binds the order id.
  • It matches by wallet and product name, so other products and other wallets are not blocked.
  • Two tabs, two request keys, the generic /api/gold/quote, retries and replays are all refused at the challenge or inside the debit.
  • A refund needs a job in failed, which can never return to delivered, so a refunded cosmetic is gone and there is no double refund.
  • The cosmetic delivery never ends in failed; an error is retried, so in practice refunds don't occur.
• Part C identity:
  • PKCE is checked inside the step that uses up the code, so a wrong verifier doesn't burn the code. Codes are single-use and capped at the session's expiry, and the redirect is fixed.
  • A grant dies with its World session. Grants live in their own table, so a grant cannot be used as a World session.
  • CORS allows only the game's origin. No route reachable with a grant changes state, except its own logout.
• Part C checkout: checkout/quote requires a same-origin Origin header and a JSON body. A key reused for another cosmetic gets 409. A contract wallet is refused when an order is created, and again by the generic payment route.
• Part A:
  • I traced the failed-run rename against prepare, delivery, refund, lapse, retire, prune_failed and the operator's abandon. The renamed id contains ~, which a request id cannot contain, so it never collides, and a late delivery still finds the old row by its id.
  • The 409/422 mapping matches what world-wallet.js reads. The grant form helper matches its description.
  • For the backup sentence, I tested whether data deleted by the prune survives in the database file or in a later backup. It did not on this machine, because its SQLite build overwrites deleted data by default. Whether the production build does the same depends on how its SQLite was built, so I didn't report it.

Coverage limits

• **Part B could not be checked.

I found two Low-severity defects in Part C and nothing in the payment flow itself, so no finding is Critical, High or Medium. Both findings are in .imd-findings.json, and their path, line and quoted code match the tree. None carries a Foundry proof: there is no Solidity in scope, and the package can't run its own tests because server/economy-config.ts, auth.ts, celestaoEntry.ts and the delivery adapters are missing. Everything below comes from reading the code, plus one small script outside the repository for finding 2.

Findings

1. Low: the purchase link from GET /api/squeek/quote always opens a dead end (server/squeek-store.ts:216). The checkoutUrl it returns is https://imdember.com/squeek-checkout/?sku=…, with no request= parameter and no lang. The checkout page only accepts a link with exactly one request matching ^[A-Za-z0-9_-]{22,64}$. So this link shows "Invalid purchase link" with no way to create an order, and an English player gets the Chinese page. Your own AUDIT_REQUEST C.2 gives the link as ?sku=…&request=…. Fix: include the request key and lang in the URL, or stop returning the field.

2. Low: the "pseudonym" can be turned back into the full wallet address (server/squeek-store.ts:47). subject_id is a plain SHA-256 of a fixed public prefix plus the address, with no server secret. Anyone holding a subject_id can hash a list of known addresses (collection holders, on-chain addresses) and find the match. The shortened wallet the game also gets lets anyone confirm a guess at once. I checked this: given only the subject_id of 0x00000000219ab540356cBB839Cbe05303d7705Fa, hashing three candidate addresses picked out the right one. Fix: derive it with a keyed hash, as vault.owner() already does on the Celestao side.

Checked and found sound

• Part C money:
  • Charged twice: two tabs, two request keys, the generic /api/gold/quote, retries and replayed signatures all end in one charge.
  • The one-time rule: SQUEEK_ONE_TIME_SQL runs inside the debit batch, and its bind order matches its placeholders. It filters by the same wallet and the same product, and other products pass. It counts a paid order whose delivery job is missing, queued or working as owned.
  • Refunds: delivery jobs only move from failed to refunded, and nothing puts a failed job back in the queue. A refund removes the cosmetic, and the refund reference stops it being paid twice.
  • Squeek delivery: an error from the 鼠道修仙 delivery never fails a job; the job is retried and the cosmetic stays owned.
• Part C identity:
  • Codes and PKCE: the code is bound to the session, PKCE uses S256, the redirect is fixed, and the code is single-use within its 60 seconds.
  • Grant lifetime: a grant lasts at most as long as the World session, and logging out or switching wallet ends it.
  • CORS: CORS allows only the game's origin, with no credentials.
  • Reach: a grant only reads its own wallet's data. The only change it can make is its own logout; the checkout routes accept only the cookie session.
• Part C checkout:
  • CSRF and key reuse: the Origin check blocks CSRF on checkout/quote, and a key reused for another cosmetic answers 409.
  • Expiry: an expired order shows as expired, and the expiry comparisons are consistent.
  • Contract wallets: they are refused when a new order is created, and they can't produce the payment signature anyway.
• Part A:
  • The rename: it holds against prepare, delivery, strike, note_wait, the operator's abandon, retire_lapsed and prune_failed, with a late delivery still answering terminal-failure.
  • Errors: the 409/422 mapping is correct.
  • Grant form: its limits match what the server returns, which is strings.
  • Privacy text: it matches the 30-day retention constants.
• Part B: the page script in the package adds no link code or data. The link itself is in prepare_overlay.py,

The review is complete and .imd-findings.json holds five merged findings, all Low, each verified against the Submission28 tree with its snippet checked line for line. No file in the submission was changed.

What I kept, after reproducing it

• Dead purchase link from the grant's quote route. The checkoutUrl at squeek-store.ts:216 carries only the sku. The page's own parser requires a request key, so it shows "Invalid purchase link". Confirmed by running the parser logic in node.
• Rate limits keyed by caller-chosen values. The token route keys on the hash of the submitted code and the Bearer routes on the hash of the submitted token, and the Worker limiter adds no IP. The grant lookup also runs before the limiter. Merged from the permissions and flow specialists.
• Unkeyed pseudonym plus wallet hint. The subject id is plain SHA-256 of a public address under a fixed prefix. I recomputed both specialists' example values in node and they match. Merged from three specialists.
• Authorize mints a code on a cross-site navigation. The session cookie is SameSite=Lax and the route checks neither Sec-Fetch-Site nor a user action when signed in. I added one detail the specialist missed: a failed exchange does not consume the code, because the PKCE match is in the UPDATE's WHERE clause.
• Generic GOLD quote and panel sell cosmetics outside the squeek gate. The shared quote never calls the store's sales check or ownership pre-check, and panel orders lack the sq_ prefix. I dropped the specialist's EOA claim, since the generic route does enforce EOA.

What I checked and found clean

• Part A: the failed-run rename in vault.prepare against prepare, delivery, refund, lapse, retire, prune_failed and the operator tool; the 409/422 mapping in start(); the grant form limits.
• Part C money: SQUEEK_ONE_TIME_SQL passes other products and other wallets, blocks a second charge inside the debit, and releases after a refund. Request-key length fits the shared request-id regex.
• Part C identity: fixed redirect, PKCE, session-bound grants, cross-wallet reads, CORS, and the read-only grant's inability to reach state-changing routes.
• Part B: only CSS is in the package. The link generator is redacted, so the data-carrying question could not be checked against code.

Limits

The Node test suite could not be run: the Submission28 tree is partial, the root tree predates the store, and no node_modules are present. Reproductions were done by code tracing and small standalone node computations. No findings are Solidity, so none carries a Foundry proof.