The grant path (world-gold.ts goldAdminCommand, action 'grant', line 256-266) is authorised by: the economy session cookie (readEconomySession / revalidateEconomySession in world-gold-api.ts), the in-batch authCheck above (session row exists, not revoked, EOA/ECDSA), the actor being one of GOLD_GRANT_WALLETS, and the WORLD_GOLD_GRANTS variable.

Nothing in the request is signed by the granting wallet: there is no per-grant ECDSA/EIP-712 signature over (recipient, amount, requestId), and the 0024 trigger cannot add one. By contrast every GOLD-moving write (service payment, mint hold) requires an explicit wallet signature (world-gold-api.ts line 29-31: 'spending continues through the existing explicit GOLD-payment signature').

So the asymmetry is: with a stolen session an attacker cannot spend the victim's GOLD, but can create new GOLD into a wallet they control and spend it there with their own signature. The recipient is unrestricted (any non-zero address, including the actor), there is no second approver, no notification, the 20,000/day and 100/day budgets are shared by both wallets, and the session lasts 7 days (AUDIT_REQUEST section 1).

One of the two grant wallets is ECONOMY_TREASURY, so the key that owns the treasury must be used interactively in a browser to sign in, which widens its exposure to phishing and malware for an authority that then needs no further signature.

The triggers and application limits were checked and hold (5,000 per grant, 20,000 and 100 per rolling 24h, actor list, immutability, reference binding, idempotent replay, same-id race returning replayed, batch-level session recheck, Origin/Sec-Fetch-Site/Content-Type on POST); this finding is about the authority model the limits sit on, which the request asks to be judged.

vault.claim (vault.py line 129-131) hands out a new attempt whenever state='working' and lease_ms<=now, with lease_ms=now+120000, and it is never renewed while the computation runs. The design (AUDIT_REQUEST section 3: 'A computation keeps its attempt while it runs. After 15 minutes it is cancelled') is implemented only through the in-memory dict active in paid.py.

The vault lease therefore protects a running computation for 120 s, and after that the protection exists only inside the one process that started it.

Any deliver call that reaches a process whose active lacks the run (a second uvicorn worker, a second replica behind the proxy, or a process that restarted and was then joined by a still-running old one during the 60 s shutdown wait) re-claims the run, starts a second computation for the same paid order, and the first computation's vault.complete fails with LEASE_LOST (attempt mismatch) so its result is thrown away.

World retries delivery every minute, so with N processes up to N simultaneous computations of one annual/profile run can occupy the two shared engine slots, which AUDIT_REQUEST section 3 says closes the engine to public requests.

No GOLD is lost (the order stays paid and is eventually delivered by whichever attempt finishes last), but the 'keeps its attempt' guarantee and the engine-capacity argument only hold for a single process, and nothing in the package pins that (serve_production.py is not included). test_paid.py line 79 (test_a_computation_past_its_lease_is_not_restarted_and_its_result_is_kept) exercises exactly one process.

This answers audit question 2 (is a session enough for this authority). The grant branch of goldAdminCommand (world-gold.ts:256-266) and the HTTP handler (world-gold-api.ts:57, 71, 76-79) prove possession of the World session cookie only: the sessions row must be EOA/ECDSA and unexpired. Nothing in the request is signed by the granting wallet.

Sessions live SESSION_TTL_MS = 7 days with no renewal and no step-up (source/server/auth.ts:25), so a single disclosed cookie value (device compromise, a stolen browser profile, a proxy or extension on the operator's machine, or an XSS anywhere on https://imdember.com, which is the only origin check applied) lets the holder issue grants to any address, including their own, for the rest of the week: 4 x 5,000 per 24 h, about 140,000 GOLD over the cookie's life, then spend it on services or mint while mint is open.

There is no second approver, no notification, no per-wallet daily cap, and the grant cannot be reversed (AUDIT_REQUEST section 4). Every other GOLD-moving action a user takes (service payment, mint) requires an explicit wallet signature over the amount; the one action that creates GOLD from nothing is the only one that does not.

The second grant wallet is ECONOMY_TREASURY (tests/world-gold-grants.test.mjs:38), so the key that receives all EMBEO payments is also kept hot in a browser to sign in to a web panel. This is a trust-assumption gap, not a permission bypass: an attacker still needs the cookie.

It is reported because the owner asked whether a session is sufficient for new issuance authority and because the blast radius (irreversible issuance over 7 days) is larger than for any other session-only action in the codebase.

paid.py:103-104 waits DELIVERY_WAIT_SECONDS (8 s) on the shielded computation and swallows the timeout so the route can answer kind='pending' inside World's 10 s client timeout (the fix for 521bc017 finding 7). asyncio.wait_for raises asyncio.exceptions.TimeoutError. That class became an alias of the builtin TimeoutError only in Python 3.11; on 3.8 to 3.10 it is a distinct subclass of Exception, so except TimeoutError does not catch it.

The exception then escapes the route handler: FastAPI answers 500, World's createCelestaoDelivery sees status != 200 and throws DELIVERY_UNAVAILABLE, the job stays 'working' until its 60 s lease lapses and is retried. The computation itself keeps running under the shield and is delivered on a later call, so no order is lost, but the intended pending answer never happens on those interpreters and every report longer than 8 s produces a 500 and an unexplained retry.

The package does not include deployment/ or the release image, and the test suite (evidence/celestao_side_summary.txt) ran on the author's interpreter, so the production interpreter version could not be verified; the code is only correct on 3.11+.

The recipient check (world-gold.ts:259-262 and trigger 0024 line 18) accepts any well-formed non-zero address.

A smart-contract wallet (Safe, ERC-4337 account) can sign in to World with ERC-1271 and will see the granted balance in /api/me/gold, but every write on /api/gold/* is refused with EOA_REQUIRED (world-gold-api.ts:57) and the write batch's authCheck requires wallet_type='EOA' AND verification_method='ECDSA' (world-gold.ts:22), so the holder can never quote a service or mint.

Combined with the grant being immutable with no correcting entry (AUDIT_REQUEST section 4), such a grant permanently inflates the book (economy_gold_accounts, recovery totals) with GOLD nobody can use, and the daily budget it consumed is gone. The panel's checksum guard protects against a mistyped character but not against this class of wrong recipient.

Low: operator error, bounded by the 5,000 per-grant limit, no attacker gain.

Line 36 validates the bridge session with readCelestaoGrant at clock() = t0. Line 37 takes a fresh now = t1 and the INSERT ... SELECT at lines 38-42 only inserts when b.expires_at>t1 AND s.expires_at>t1 AND s.revoked_at IS NULL.

If the bridge session (MIN(session expiry, created+1h) from celestao-auth.ts:72) or the sign-in session expires or is revoked in the gap t0<expiry<=t1, the statement inserts nothing without error. Line 43 then finds no row and line 44 answers 409 IDEMPOTENCY_CONFLICT, a code that means 'this run id belongs to another wallet/product/hash'. The second readCelestaoGrant at line 45, which would answer 401 AUTH_REQUIRED, is never reached because the 409 returns first.

On the Celestao side bridge.py:65-66 maps only 401/403 AUTH_REQUIRED to AuthDenied; a 409 becomes BridgeUnavailable, so paid.py:41-43 deletes the fresh run and answers 503 CHECKOUT_UNAVAILABLE, which the overlay presents as a temporary outage rather than asking for a new sign-in.

Boundary: the code assumes 'no row after the upsert' can only mean a conflicting row, but the SELECT-fed INSERT also yields no row when its session predicates fail.

Fix: before answering 409 at line 44, when row is null re-check readCelestaoGrant (or check meta.changes===0 && no row) and answer 401 AUTH_REQUIRED; or move the line-45 re-check ahead of line 44 for the null-row case.

payload is JSON.stringify([cmd,args.reason]) where cmd is the parsed body object in the caller's key order (command() at world-gold-api.ts:23-27 only checks the key set). The replay rule in AUDIT_REQUEST section 1 says a request id 'replays any number of times'; the comparison is byte-wise on the serialisation, not on the normalised grant (recipient lowercased, amount, reason).

The shipped panel always serialises {action,wallet,gold} in the same order, so this is not reachable from WorldGoldPanel.tsx, but any other client (a script re-sending a lost answer from a log, a future panel that lowercases the address or trims the reason) gets 409 for a grant that was already paid, and the operator may then send it again under a new id, where only the 10-minute GRANT_DUPLICATE_RECENT rule stands between them and a second payment.

Fix: compare a canonical form (sorted keys, economyAddress(cmd.wallet), String(Number(cmd.gold)), reason as stored) or store and compare a digest of that canonical form.

Answer to AUDIT_REQUEST section 5 item 2. The grant batch checks only that a sessions row with the cookie's token_hash, the admin address, wallet_type EOA and verification_method ECDSA is unrevoked and unexpired. No per-grant wallet signature is taken, unlike GOLD spending, which already requires an explicit signature (goldChallenge/payGold in WorldGoldPanel.tsx:127).

The limits bound what the session can do: 5,000 per grant, 20,000 and 100 grants per rolling 24 h shared by both wallets, so one session held for its full 7-day life can issue at most 7 x 20,000 = 140,000 GOLD in up to 700 grants, to any address including an attacker's own, with no second approver and no notification, and none of it can be reversed (world_gold_grants is immutable and has no correcting entry).

The same session, or the recipient's, can then spend it on services or mint when mint is open. With WORLD_GOLD_GRANTS unset nothing is reachable, and the daily sum limit also caps a legitimate operator at the same rate, so the control is the switch plus the caps, not the credential.

Recommendation (a design decision for the owner, not a defect in the stated design): require a per-grant EIP-712 signature from the granting EOA over (recipient, amount, request id, expiry <= 10 min, chain id, domain), verified server-side in goldAdminCommand before the batch; alternatively a much shorter session lifetime or a re-authentication (fresh ECDSA challenge) for the grant action only. Either keeps the two-wallet list and the caps unchanged.

Answer to AUDIT_REQUEST section 5 item 2 (merged from four specialist reports). The grant branch of goldAdminCommand (world-gold.ts:256-266) and the HTTP handler (world-gold-api.ts:57, 71, 79) prove only possession of the World session cookie: authCheck at line 22 requires a sessions row with the cookie's token_hash, the actor address, wallet_type='EOA', verification_method='ECDSA', unrevoked and unexpired. Nothing in the request is signed by the granting wallet's key.

Every other GOLD-moving action a user takes (service payment, mint) needs an explicit wallet signature over the amount (world-gold-api.ts:29-31 and WorldGoldPanel.tsx payGold); the one action that creates GOLD with no order behind it does not. Sessions live 7 days with no step-up.

A copied cookie (device or browser-profile compromise, a same-origin XSS on imdember.com, a leaked HAR) therefore issues grants to any address including the holder's own: 4 x 5,000 per rolling 24 h, about 140,000 GOLD over the cookie's life, each row immutable with no correcting entry (section 4), spendable on services and mint. GRANT-WALLET-2 is ECONOMY_TREASURY (tests/world-gold-grants.test.mjs:38), so the payment-receiving key is used interactively in a browser for this.

The limits, triggers, origin/Sec-Fetch-Site checks, replay and race handling were checked and hold; this finding is about the credential behind the authority, which section 1 acknowledges and section 5 asks to be judged. It is a trust-assumption gap, not a permission bypass: an attacker still needs the cookie.

Fix that keeps the owner's design (same two wallets, same limits, same switch): require in the grant command an EIP-712 signature by the session wallet over {recipient (lowercase), gold, requestId, reasonHash, chainId, domain imdember.com, deadline <= 10 min}; verify it with viem verifyTypedData/recoverTypedDataAddress against session.address before building the batch, store the signature in the world_gold_admin_actions payload (so a replay still compares equal) and refuse an expired deadline.

Optionally bind a per-session total in the application guard (sum per sessions.token_hash <= 20,000) so one cookie cannot reach the weekly figure, and sign in with a dedicated grant EOA rather than the treasury address.

Merged from three specialist reports. The state route computes grantLeft from the 24-hour SUM(delta) only (world-gold-api.ts:68-69). The count limit GOLD_GRANT_DAILY_COUNT=100 is enforced by the application guard (world-gold.ts:266) and by the 0024 trigger (line 22) but is never read into the state, and WorldGoldPanel.tsx:58 renders grantLeft as the remaining allowance and keeps the form open.

After 100 small grants an operator sees a large positive number, sends a grant, and gets GRANT_DAILY_LIMIT with no way to tell from the panel which limit was hit or when it reopens; the 10-minute GRANT_DUPLICATE_RECENT rule then also blocks the natural retry. No limit is bypassed.

Fix: in the same canGrant branch also select COUNT(*) FROM world_gold_grants WHERE created_ms>? over the same window, return grantLeft=String(count>=GOLD_GRANT_DAILY_COUNT?0:Math.max(0,GOLD_GRANT_DAILY-sum)) plus grantsLeft=String(Math.max(0,GOLD_GRANT_DAILY_COUNT-count)), and let grantFormReady disable the button when either is zero.

The guard runs viem isAddress(...,{strict:true}) only when the typed address contains both a lowercase and an uppercase hex letter.

An address typed entirely in uppercase hex has no [a-f] match, so the strict check is skipped, economyAddress() lowercases it and the grant is written. viem 2.56.9 (the project's pinned version) strict isAddress accepts only the all-lowercase or the exact EIP-55 spelling: for the uppercase spelling of an address whose checksum form is mixed case it returns false, so the code deliberately skips a check the library would fail.

The comment on this line says the purpose is that 'a mistyped character is refused rather than paid to nobody', and AUDIT_REQUEST section 1 says 'a mixed-case address must pass its checksum'. Hex letters are only ever uppercased by EIP-55, so an all-uppercase string is almost always a checksummed address that an explorer, spreadsheet, OCR or chat client uppercased; a one-character typo in such a paste is granted, irreversibly, to an address nobody holds.

The client rule grantFormReady (src/world/goldGrantRules.ts:5) has the same gap.

Fix: run the strict check whenever the typed address is not all-lowercase, i.e. if(typed!==typed.toLowerCase()&&!isAddress(cmd.wallet as string,{strict:true}))fail('INVALID_ADDRESS_CHECKSUM'); mirror it in grantFormReady, and say in the panel that lowercase is accepted unchecked.

vault.claim (vault.py:129-131) hands out a new attempt whenever state='working' and lease_ms<=now, with lease_ms=now+120000, and nothing renews it while processor.compute runs. The design in AUDIT_REQUEST section 3 ('A computation keeps its attempt while it runs. After 15 minutes it is cancelled') is implemented only through the in-memory dict active in paid.py:90-96.

So the vault protects a running computation for 120 s; after that the protection exists only inside the one process that started it.

Any deliver call that reaches a process whose active lacks the run (a second uvicorn worker or replica behind the proxy, or a restarted process while the old one still finishes its computation during the 60 s shutdown wait) re-claims the run, starts a second computation of the same paid order, and the first computation's vault.complete fails with LEASE_LOST so its result is thrown away.

World retries delivery every minute, so with N processes up to N simultaneous annual or profile computations of one order can occupy the two shared engine slots, which section 3 says closes the engine to public requests. No GOLD is lost: the order stays paid and is delivered by whichever attempt finishes last. The package does not include serve_production.py, so the single-process assumption could not be confirmed.

Fix: make the vault the authority. Either set lease_ms to now+COMPUTE_LIMIT_MS in vault.claim so the lease covers the whole allowed computation and the 15-minute replacement happens at lease expiry, or have calculate() renew the lease (UPDATE runs SET lease_ms=? WHERE id=?

AND attempt=?) every 60 s while it runs; keep the active map for the in-process cancel.

paid.py:103-104 waits DELIVERY_WAIT_SECONDS on the shielded task and swallows the timeout so the route answers kind='pending' inside World's 10 s client timeout (fix for 521bc017 finding 7). asyncio.wait_for raises asyncio.exceptions.TimeoutError, which became an alias of the builtin TimeoutError only in Python 3.11; on 3.8 to 3.10 it is a distinct Exception subclass and except TimeoutError does not catch it.

The exception then escapes the route, FastAPI answers 500 with no signed body, World's createCelestaoDelivery throws DELIVERY_UNAVAILABLE (celestao-delivery.ts:21) and the job is retried after its 60 s lease. The computation keeps running under the shield and is delivered on a later call, so no order is lost, but the intended pending answer never happens on those interpreters and every slow report produces a 500 and an unexplained retry.

The package pins no interpreter version (no deployment/ or release image, no requires-python anywhere in the tree), and evidence/celestao_side_summary.txt does not state the version the suite ran on; on this machine (3.12) asyncio.TimeoutError is TimeoutError. The code is only correct on 3.11+.

Fix: except (TimeoutError,asyncio.TimeoutError):pass, and pin or assert sys.version_info>=(3,11) at startup.

Line 36 validates the bridge session with readCelestaoGrant at clock()=t0. Line 37 takes a fresh now=t1 and the INSERT ... SELECT at lines 38-42 inserts only when b.expires_at>t1 AND s.expires_at>t1 AND s.revoked_at IS NULL.

If the bridge session (MIN(session expiry, created+1h), celestao-auth.ts:72) or the sign-in session expires in the gap t0<expiry<=t1, or is revoked by a concurrent logout, the statement inserts nothing without error. Line 43 then finds no row and line 44 answers 409 IDEMPOTENCY_CONFLICT, a code that means 'this run id belongs to another wallet, product or hash'. The second readCelestaoGrant at line 45, which would answer 401, is never reached.

On the Celestao side bridge.py:65-66 maps only 401/403 AUTH_REQUIRED to AuthDenied; a 409 becomes BridgeUnavailable, so paid.py:41-43 deletes the fresh run and answers 503 CHECKOUT_UNAVAILABLE, which the overlay presents as a temporary outage instead of a sign-in prompt. The code assumes 'no row after the upsert' can only mean a conflicting row. Narrow window, no money moves.

Fix: when row is null, re-run readCelestaoGrant first and answer 401 AUTH_REQUIRED if it is gone (or check meta.changes===0 together with no row); keep 409 for a row that exists and differs.

The recipient check (world-gold.ts:259-262 and 0024 trigger line 18) accepts any well-formed non-zero address, as AUDIT_REQUEST section 1 states.

A smart-contract wallet (Safe, ERC-4337 account) can sign in to World with ERC-1271 and sees the granted balance in /api/me/gold, but every write on /api/gold/* is refused with EOA_REQUIRED at this line and the write batch's authCheck (world-gold.ts:22) requires wallet_type='EOA' AND verification_method='ECDSA', so the holder can never quote a service or mint.

With the grant immutable and no correcting entry (section 4), such a grant permanently inflates economy_gold_accounts and the recovery totals (economy-recovery.ts:237) with GOLD nobody can use, and the daily budget it consumed is gone. The checksum guard protects against a mistyped character but not against this class of wrong recipient. Operator error, bounded by 5,000 per grant, no attacker gain.

Fix: in the grant branch refuse a recipient that has an existing sessions row with wallet_type<>'EOA' (no RPC needed), or read eth_getCode through the Worker's existing chain access as sign-in already does, and fail('RECIPIENT_NOT_EOA'); otherwise say in the panel that the recipient must be an EOA.

payload is JSON.stringify([cmd,args.reason]) where cmd is the parsed body object in the caller's key order (command() at world-gold-api.ts:23-27 only checks the key set). AUDIT_REQUEST section 1 says a request id 'replays any number of times', but the comparison at line 232 is byte-wise on the serialisation, not on the normalised grant (recipient lowercased, amount, reason).

The shipped panel always serialises {action,wallet,gold} in the same order and sends the address as typed, so this is not reachable from WorldGoldPanel.tsx; any other client (a script re-sending a lost answer, a future panel that lowercases the address) gets 409 for a grant that was already paid, and the operator may then send it again under a new id, where only the 10-minute GRANT_DUPLICATE_RECENT rule stands between them and a second payment.

Fix: compare a canonical form (sorted keys, economyAddress(cmd.wallet), String(Number(cmd.gold)), reason as stored) or store and compare a digest of it.