{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"d6268e87-a268-48c7-87ec-fa243452f308","kind":"audit","nodes":[{"acceptedSubmissionHash":"5ea4f25f1fbf48c4c14adfad878d6a6d1721f455218d02e33d951919a2798e44","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_economics","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"7f82fd85f749378d8219b0ef1201901e58026cef2fc5a0705f7074bb126b0d8a","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_flow","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"313f6442d9215f68cb047601d500a6239bb725e201398381641d9773c3f7ae7f","dependsOn":["audit_math","audit_permissions","audit_economics","audit_flow"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","tools":[]},"key":"audit_judge","kind":"code","role":"review","skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","state":"accepted"},{"acceptedSubmissionHash":"b0fc17df600da4a6bc6728d3067cdf0651caaf2bdfdd83626995746aecc33b4f","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_math","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"9fb21dc45a9874dd2cc07670ba8e90b16dd1f58f9acf688341eb35714e3ee85d","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_permissions","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"}],"objective":"Review public commit e5ca6e5ac90a9e78b4739a242995121e791cff92.\n\nRe-audit remediation of job188a3018-0379-413a-bccc-79f278452e8f, previously public450507815fec44e1c496999e07da1b006861c5dd / World7afdd097847d2cd6b5d503734566afc1b78a2c8d. New private World41ca333db50696a0a2f4c886d6fe7171637908cc. Source/auxiliary hashes, explicit portable adaptations, original report and both diffs are included. No publication, paid submission, production migration or deployment is implied.\n\nD01: SQL guards every positive journal before int64 addition. Staking records immutable original share-day entitlements; capped rewards remain owed outside book/reserved/available, without blocking peers/page progress. Bounded retry credits once. Recovery counts issued and owed separately; SQL rejects old recovery plans unaware of pending rewards. Test1025 legitimate current-price orders reaching exact cap, plus historical0014 paid quote/indexer ->0015/16 ->owed ->recovery/backup ->retry without twice-issued rewards.\nD02: shared mode refuses unlinked legacy GOLD catalogue admission/payment. Current linked services require product/control/trusted provider/result-contract gates; debit/paid/challenge/job commit atomically. Historical paid-no-job cases remain read-only inventory, not invented delivery or blanket refunds.\nD03: uncached readiness checks112 reviewed SQL objects including37 tables/244 columns and every required trigger/index/view. Test old/partial schemas, removed guards and same-order resume after forward migration. World financial POST refuses even pre0014; no deployed standalone fallback. Historic standalone tests retain their original assertions/profile explicitly.\nD04: ordinary expired bridge identity cleanly denies/revokes, distinct from malformed response/outage. Resample after response and slow balance read; external profile never receives World trial rights.\nD05: paid auth reuse requires latest time strictly before deadline and complete original wallet/cost/key/URI/epoch/recipient/domain/run binding. At equality refuse a dead packet without releasing an executable hold. Missing/delayed required original-chain proof stays held. Private EVM covers deadline-1 actual mint, equality/+1 and pending proof.\nD06: reviewed research/fortune result contracts reject null/empty/malformed/oversize/unsafe Unicode; explained zero/false/no-signal remains valid. Deterministic unusable output attempts original refund once; unknown timeout remains pending with the same key. Unknown schema/provider refuses new charge. Fresh claim/finish clocks fence expired leases.\nD07: application and SQL enforce31337/private-edr vs public/finalized-chain in both directions alongside the full proof predicate. Label changes cannot promote private evidence. Calibrate by removing guards; real public finality remains unproved.\nD08: lossless JSON auth rejects undefined/functions/symbols/cycles/BigInt/accessors/custom serialization/nonfinite/depth/UTF8 overflow with typed INVALID_MINT_AUTH before writes. Recorded order/wallet/cost and actual wrapped packet/anchor/domain bindings must match. Stored JSON is not cryptographic or public-chain proof.\nD09: paid-only approval pause leaves eligible free Mint executable without EMBEO/GOLD and allows existing paid-hold settlement. Original contract eligibility, one-free-per-wallet and shared2222 concurrent free/paid supply remain unchanged; no3-day window.\nD10: real provider/VPS/result-contract integration, finalized public Mint reader/persistent original namespace, actual wallets/runtime, production CPU/D1 limits, formal catalogue/prices and migration/rollback/postflight remain explicit unverified release gates. reviewedEconomyConfig stays disabled; fixture success is not production integration.\n\nAdditional reproduced defect: payment time went stale during schema/admission I/O; resample original deadlines immediately before atomic spend. Independently examine every credit source (purchase, stake/owed, refund, admin, Mint release, recovery), old/new payment entry, schema/guard removal, UTC days, expiry equality, lease/timeout, concurrency/crash/replay, read-only historical inventory and immutable before/after evidence.\n\nStart with world-source/docs/world-gold-audit6-remediation.md, runbook and release-gates, context/T01-T22-evidence.md and evidence/packet-validation.json. Three complete flows and sanitized before/after failures are included. Per LOCAL_TESTS.md run source verification, selected financial tests, original Solidity30 and Python18. Full World build/regression evidence is separate from this selected packet; dependencies reuse exact locks, not a claimed fresh download. GOLD is nontransferable/nonredeemable; no AMM/trading pair. Test prices are not formal prices. Passing local checks does not imply zero remaining findings or production safety.","parentJobId":null,"planHash":"2f962c060cf3f5d02aa337464c4583e28f955494dadf750466c3e664b14f16cc","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"d6268e87-a268-48c7-87ec-fa243452f308","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52180","feedbackHash":"123ef38d294bd6930372b9a63d88131a101b75ccb7a90001282b76940a4f5b3d","nodeKey":"audit_economics","submissionHash":"5ea4f25f1fbf48c4c14adfad878d6a6d1721f455218d02e33d951919a2798e44","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51483","feedbackHash":"7ccdc7db6960838bd58bd5cb337cd67b927eb815502326e0c2f532f7b8a7260c","nodeKey":"audit_flow","submissionHash":"7f82fd85f749378d8219b0ef1201901e58026cef2fc5a0705f7074bb126b0d8a","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52019","feedbackHash":"9e9f0a3bd8f973d989d92edbcca65fb1452439aff8c37450b80462e953be07c0","nodeKey":"audit_judge","submissionHash":"313f6442d9215f68cb047601d500a6239bb725e201398381641d9773c3f7ae7f","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"50961","feedbackHash":"92a65154704fb6a08822406df8560b5856bacd5fa33d1ae72d50416cc9faf696","nodeKey":"audit_math","submissionHash":"b0fc17df600da4a6bc6728d3067cdf0651caaf2bdfdd83626995746aecc33b4f","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51481","feedbackHash":"061bd6c925b8696b1b925012da2f776080cee12317a946c458cb9d563c0a1dec","nodeKey":"audit_permissions","submissionHash":"9fb21dc45a9874dd2cc07670ba8e90b16dd1f58f9acf688341eb35714e3ee85d","tag1":"review:submission","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"a2ac3677de1783cda990aff6ac1d1f757cd8425e2d5c7a66ab6e90798f95a90e","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"be3be4cc237417f9","findings":[{"citation":"resolved","description":"D-02 closed the legacy catalogue route in shared mode only for currency GOLD. createEconomyOrder (reached from POST /api/economy/orders in server/economy.ts) refuses a shared-DB catalogue order when args.currency==='GOLD' but still inserts one priced from config.catalogue for currency 'EMBEO' (lines 257-264). That order has no world_gold_links row, so none of the shared-mode gates apply: the world_gold_controls 'service' pause, the serviceReady requirement and the result-contract check in sharedServiceAdmission (lines 212-221) are only consulted on the GOLD challenge/debit path, and goldQuote's product/control predicate is bypassed because the order never passes through goldQuote. When the player pays the EMBEO quote on-chain, ingestEconomyEvents marks it paid and the 0010 trigger economy_order_paid writes economy_fulfillments. reconcileWorldGold ignores it (no link), runGoldServiceJobs never sees it (no world_gold_jobs row), refundGold and the admin refund-service action both refuse it, and nothing in the packet consumes economy_fulfillments. Real EMBEO reaches the treasury for a service that cannot be delivered or refunded while the service feature is paused, violating REQUIREMENTS.md 'Service debit creates one durable job' and 'Pause only new admissions by feature'. Precondition (trust assumption): a reviewed EconomyConfig whose catalogue carries an entry with an embeo price. reviewedEconomyConfig is null today and the fixture catalogue is empty, but a formal catalogue is the stated D10 release path, and the guard that is meant to close this door is asymmetric. Fix: in shared mode refuse every catalogue service admission regardless of currency (e.g. throw LEGACY_ORDER_UNSUPPORTED when shared, or require config.catalogue to be empty when world_gold tables exist) and route EMBEO purchases only through goldQuote topup products so they carry a link and a bounded entitlement.","line":256,"path":"world-source/server/economy-ledger.ts","reproduction":"Scratch node script against world-source with its exact lock installed (all migrations through 0016 via tests/d1-sqlite.mjs openD1()). config=defineEconomyConfig({chainId:1,token:ECONOMY_TOKEN,treasury:ECONOMY_TREASURY,stakingContract:0x11..,paymentContract:0x22..,tokenDecimals:18,deploymentBlock:'100',catalogue:[{id:'legacy-research',titleZh:'a',titleEn:'a',gold:'3',embeo:'5'}]}); W=0xaa..aa. Negative control: createEconomyOrder({wallet:W,requestId:'s'*20,serviceId:'legacy-research',currency:'GOLD',nowMs:NOW}) -> throws LEGACY_GOLD_ORDER_UNSUPPORTED (observed). Then goldAdminCommand control {feature:'service',enabled:false,version:0} -> world_gold_controls.service.enabled=0 (observed), and serviceReady is never supplied. createEconomyOrder({wallet:W,requestId:'e'*20,serviceId:'legacy-research',currency:'EMBEO',nowMs:NOW}) -> Expected: refused (LEGACY_*_UNSUPPORTED / FEATURE_PAUSED / SERVICE_DELIVERY_UNAVAILABLE) before any quote is issued, as for GOLD. Actual (observed): returns {currency:'EMBEO',amount:'5',status:'pending'}. ingestEconomyEvents with the matching payment event at block 100 (payer W, amount '5', token/treasury from config) -> economy_orders.status='paid' (observed). reconcileWorldGold(db,NOW+200) -> {processed:0,failures:[],rewards:[]}; COUNT world_gold_links for the order = 0; COUNT world_gold_jobs = 0; COUNT economy_fulfillments = 1. refundGold(db,id,NOW+300) -> REFUND_NOT_ENTITLED; goldAdminCommand refund-service for the id -> 'CHECK constraint failed: accepted=1' (refused). EMBEO collected, no job, no delivery, no refund path.","severity":"medium","snippet":"  if(shared&&args.currency==='GOLD')throw new EconomyConflict('LEGACY_GOLD_ORDER_UNSUPPORTED');","title":"Shared mode still admits and collects payment for unlinked legacy EMBEO catalogue service orders that can never be delivered or refunded"},{"citation":"resolved","description":"D-06 states the research/fortune result contracts reject null/empty/malformed documents and that a deterministic unusable output triggers one original-price refund. usableDocument() short-circuits to true for every string whose trim() is non-empty, before any structural check. A trusted provider adapter that resolves {kind:'delivered',result:<upstream body text>} on a non-JSON upstream failure (the common HTTP-client default) therefore delivers the literal error text ('error', 'Internal Server Error') as the paid report: finishGoldJob marks the job 'delivered' with result_json '\"error\"', the GOLD debit stands, refundGold rejects (state is not 'failed') and the administrator refund-service check (state IN ('failed','refunded')) also rejects, so no operator path exists short of direct SQL. The object form of the same contract is stricter (report/content text or explained ok/no-signal status), so the bare-string branch is the only shape that admits an undifferentiated error payload. inspectWorldGoldExceptions re-runs encodeGoldResult on delivered rows and therefore classifies such rows as clean (0 'delivered-result-needs-review' rows). This is the same charge-for-nothing outcome the previous audit's null-result finding closed, reached through a different accepted value. Fix: restrict the bare-string branch to the historical fixture read path (inspection reader) and refuse it for new deliveries, or require a minimum documented shape (e.g. object with report/content or explained status) in runGoldServiceJobs/finishGoldJob so a bare string becomes RESULT_UNUSABLE with the existing one-time refund.","line":10,"path":"world-source/server/world-gold-result.ts","reproduction":"Scratch node script importing tests/world-gold-audit5-fixture.mjs (all migrations). f=await fixture(); await f.topup() (book '10'); id=await f.service() (research, book '7'); a=await claimGoldJob(db,id,NOW); await finishGoldJob(db,{orderId:id,attempt:a,nowMs:NOW+1,outcome:{result:'error'}}). Expected: terminal failure RESULT_UNUSABLE with evidence kind 'world-result-unusable', state 'refunded' and book back to '10' (as for result null, '' or ' '). Actual (observed on this tree): SELECT state,result_json,failure FROM world_gold_jobs WHERE order_id=id -> {state:'delivered',result_json:'\"error\"',failure:null}; book stays '7'; refundGold(db,id,NOW+2) -> REFUND_NOT_ENTITLED. Same with result:'Internal Server Error' -> {state:'delivered',result_json:'\"Internal Server Error\"'}, refund REFUND_NOT_ENTITLED. inspectWorldGoldExceptions(db) -> 'delivered-result-needs-review' rows: []. Positive controls in the same run: result:' ' and result:null -> state 'refunded', failure 'RESULT_UNUSABLE', book restored.","severity":"medium","snippet":" if(text(v))return true;","title":"Result contract accepts any non-blank bare string, so deterministic provider error text is stored as a paid delivered result with no refund path"},{"citation":"resolved","description":"reserveMintGold evaluates m.deadline<=nowMs once using the caller's nowMs. After that it awaits requireWorldGoldSchema, the existing-order SELECT, encodeMintAuth and goldFeature(db,'mint'), then runs a db.batch that INSERTs world_gold_mints and the 'held' world_gold_holds row. Neither the batch nor the 0014 world_gold_hold_insert trigger (which checks only mint existence, state and available balance) nor any 0015/0016 trigger carries a deadline predicate; the only deadline SQL is the release predicate. Unlike goldQuote (line 50), claimGoldJob, finishGoldJob and payEconomyOrderGold, which were given a now() resampler in this remediation specifically for the 'stale payment time after schema/admission I/O' defect, this function takes no fresh clock. So an auth that is already dead by the time the rows are written is inserted as a 'held' mint plus hold, reserving the wallet's GOLD until a trusted original-namespace proof reader later releases it (D05 says equality must be refused without creating a hold). Mitigating facts that keep this low: in the supplied integration (mint/service/chain.mjs approval) the deadline is chain time + 300 s and the local runtime passes chain time read immediately before the call, so ~300 s of I/O stall would be needed, and the stale hold is eventually released by reconcileHeldMintGold once chainTimeMs > deadline. Fix: accept now?:()=>number, resample right before db.batch and refuse when deadline<=fresh, and add a SQL guard in the same batch (e.g. check(db,'?<deadline',fresh) or INSERT ... SELECT ... WHERE ?<deadline) so a removed application guard is also caught.","line":112,"path":"world-source/server/world-gold.ts","reproduction":"Scratch node script importing tests/world-gold-audit5-fixture.mjs. f=await fixture(); await f.topup() (book '10'). Wrap the D1 shim so the controls SELECT used by goldFeature ('SELECT enabled FROM world_gold_controls WHERE feature=?') resolves after a 20 ms delay, simulating one slow D1 round-trip. start=Date.now(); deadline=start+10; m={id:H(4242),wallet:W,auth:{wallet:W,id:H(4242)},gold:'8',chainId:1,contract:0x88..,chainInstance:'preserved-chain-instance',deadline}. reserveMintGold(slowDb,m,start). Expected: no row written; the call refuses once real time reaches the deadline (INVALID_MINT_AUTH / MINT_AUTH_EXPIRED), matching the equality control. Actual (observed): call resolves ('ACCEPTED'); Date.now()-deadline after the call = 21 ms (deadline already passed when the batch ran); world_gold_mints row {state:'held',deadline} and world_gold_holds row {state:'held',amount:8} exist; worldGoldSnapshot -> book '10', reserved '8', available '2'. Control in the same run: reserveMintGold(db,{...m,id:H(4243)},deadline) with nowMs equal to the deadline -> INVALID_MINT_AUTH, showing only the caller-supplied sample is checked.","severity":"low","snippet":" if(!/^0x[0-9a-f]{64}$/.test(m.id)||!Number.isSafeInteger(m.deadline)||m.deadline<=nowMs||!Number.isSafeInteger(m.chainId)||m.chainId<1||typeof m.chainInstance!=='string'||!/^[A-Za-z0-9._:-]{1,128}$/.test(m.chainInstance))fail('INVALID_MINT_AUTH');","title":"reserveMintGold checks the auth deadline only against the caller-supplied stale time and never resamples or SQL-guards it before the atomic hold insert"},{"citation":"resolved","description":"The retry branch of goldQuote returns old.id without reading status or expires_ms against the clock. The legacy createEconomyOrder path for the identical situation throws ORDER_EXPIRED (economy-ledger.ts line 255), and every downstream step (createEconomyGoldChallenge, payEconomyOrderGold) refuses the expired pending order. A client that retries POST /api/gold/quote with its stored requestId after the 15-minute window receives HTTP 200 {orderId} for an order it can never pay; the only recovery is a new requestId, which the response does not signal. No GOLD or EMBEO moves and no duplicate quote is created, so this is a liveness/consistency inconsistency of the new shared quote entry, not a loss. Fix: in the old-request branch select status and expires_ms and fail('ORDER_EXPIRED') when status='pending' and expires_ms<=fresh clock, mirroring createEconomyOrder.","line":44,"path":"world-source/server/world-gold.ts","reproduction":"Scratch node script with tests/world-gold-audit5-fixture.mjs. f=await fixture(); r=rid(); id=await goldQuote({db,config,nowMs:NOW,serviceReady:true},{wallet:W,requestId:r,product:'research'}) -> economy_orders {status:'pending',expires_ms:NOW+900000}. goldQuote({db,config,nowMs:NOW+900000,serviceReady:true},{wallet:W,requestId:r,product:'research'}). Expected: ORDER_EXPIRED, as createEconomyOrder(db,config,{wallet:W,requestId:r,serviceId:'research',currency:'GOLD',nowMs:NOW+900000}) throws for the same stored order (observed: ORDER_EXPIRED). Actual (observed): the same order id is returned. The subsequent createEconomyGoldChallenge(db,config,{wallet:W,orderId:id,requestId:rid(),origin:'https://imdember.com',nowMs:NOW+900000,serviceReady:true}) throws ORDER_EXPIRED. Negative control: at nowMs NOW+899999 the same id is returned (true) and is still payable.","severity":"info","snippet":" if(old){const link=await st(db,'SELECT p.product FROM world_gold_links l JOIN world_gold_products p ON p.id=l.product_id WHERE l.order_id=?',old.id).first<{product:string}>();if(link?.product!==args.product)fail('IDEMPOTENCY_CONFLICT');return old.id;}","title":"goldQuote idempotent retry returns an already-expired pending order id instead of ORDER_EXPIRED, unlike createEconomyOrder"}],"hash":"313f6442d9215f68cb047601d500a6239bb725e201398381641d9773c3f7ae7f","nodeId":"9480b8f0-045d-4c00-8ff1-663703f1d9c5","outcome":"completed","summary":"Review complete. The findings file at `.imd-findings.json` holds four verified findings, all reproduced by scratch scripts run against this tree with the exact-lock dependencies. No two specialists reported the same defect, so nothing needed merging, and nothing was dropped.\n\n**Kept, with severity as I judged it:**\n\n- **Medium: unlinked legacy EMBEO catalogue orders in shared mode** (`world-source/server/economy-ledger.ts:256`). Only the GOLD currency is refused. With a catalogue entry carrying an EMBEO price and the service feature paused, an EMBEO order is created, paid on-chain, and ends with no link, no job, a fulfillment row, and both refund paths refusing. Precondition is a reviewed config with a priced catalogue, which is the stated release path, so I raised it from the specialist's low.\n- **Medium: bare non-blank strings pass the result contract** (`world-source/server/world-gold-result.ts:10`). Delivering the literal text \"error\" or \"Internal Server Error\" marks the job delivered, keeps the debit, and refundGold and admin refund-service both refuse. Blank and null controls refund correctly in the same run. Raised from low because it contradicts the D06 claim directly and leaves no operator path.\n- **Low: reserveMintGold never resamples the deadline before the hold insert** (`world-source/server/world-gold.ts:112`). With a 20 ms delay on the controls read and a deadline 10 ms ahead, a held mint and hold were written for an already-dead auth. Lowered from the specialist's medium because the shipped integration gives every auth a 300 second deadline from chain time and the hold is eventually released by the proof reader.\n- **Info: goldQuote retry returns an expired pending order id** instead of ORDER_EXPIRED (`world-source/server/world-gold.ts:44`), unlike createEconomyOrder on the same state. No value moves.\n\n**Independent checks that found nothing new:** the 0014 and 0016 hold, entry, balance-capacity and reward-entitlement triggers, the reward reconciliation path, the payment-time resample in payEconomyOrderGold, and a lead about session address casing in the gold auth check, which did not reproduce because sessions store lowercased addresses.\n\nNo proofs were attached since no finding is high or critical and none is in Solidity. No repository files were changed. The scratch scripts live outside the repository in a temporary directory.","treeHash":null,"usage":{"cachedInputTokens":2041066,"inputTokens":770,"model":"claude-fable-5-1","outputTokens":23631,"runtime":"claude","turns":25,"wallClockMs":397439}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"c722c2e9ac9aa084","findings":[{"citation":"resolved","description":"D-06 states the reviewed research/fortune result contracts reject null/empty/malformed documents and that a deterministic unusable output triggers one original-price refund. usableDocument() short-circuits to true for every string whose trim() is non-empty, before any structural check. A trusted provider adapter that resolves {kind:'delivered',result:<upstream body text>} on a non-JSON upstream failure (the common HTTP-client default) therefore delivers the literal error text as the paid report: finishGoldJob marks the job 'delivered' with result_json '\"error\"', the GOLD debit stands, refundGold rejects (state is not 'failed') and the administrator refund-service check (state IN ('failed','refunded')) also rejects. The object form of the same contract is stricter (report/content text or explained ok/no-signal status), so the bare-string branch is the only shape that admits an undifferentiated error payload. inspectWorldGoldExceptions re-runs encodeGoldResult on delivered rows and therefore also classifies such rows as clean. This is the same charge-for-nothing outcome the previous audit's finding 6 (null result) closed, reached through a different accepted value. Fix: restrict the bare-string branch to documented fixture reports (or remove it for new deliveries), e.g. require a minimum length/shape or move legacy text acceptance into the inspection reader only, and let runGoldServiceJobs reject delivered outcomes whose result is a bare string.","line":10,"path":"world-source/server/world-gold-result.ts","reproduction":"Scratch node script importing tests/world-gold-audit5-fixture.mjs (all migrations). f=await fixture(); await f.topup() (book '10'); id=await f.service() (research, book '7'); a=await claimGoldJob(db,id,NOW); await finishGoldJob(db,{orderId:id,attempt:a,nowMs:NOW+1,outcome:{result:'error'}}). Expected: terminal failure RESULT_UNUSABLE with evidence kind 'world-result-unusable' and book back to '10' (as for result:null, '' or '   '). Actual (run on this tree): SELECT state,result_json FROM world_gold_jobs WHERE order_id=id -> {state:'delivered',result_json:'\"error\"'}; book stays '7'; refundGold(db,id,NOW+2) rejects REFUND_NOT_ENTITLED; inspectWorldGoldExceptions reports 0 'delivered-result-needs-review' rows. Positive control in the same run: result:'   ' and result:null become state 'refunded' with failure RESULT_UNUSABLE and book '10'.","severity":"low","snippet":" if(text(v))return true;","title":"Result contract accepts any non-blank bare string, so a deterministic provider error text (e.g. \"error\", \"Internal Server Error\") is stored as a paid delivered result with no refund path"},{"citation":"resolved","description":"The idempotent retry branch of goldQuote returns old.id without checking status/expires_ms against the fresh clock. The legacy createEconomyOrder path for the identical situation throws ORDER_EXPIRED (economy-ledger.ts line 255), and every downstream step (createEconomyGoldChallenge, payEconomyOrderGold, ingestion credit for topups is unaffected) refuses the expired pending order. A client that retries POST /api/gold/quote with its stored requestId after the 15-minute window receives HTTP 200 {orderId} for an order it can never pay; the only recovery is a new requestId, which the response does not signal. No GOLD or EMBEO moves and no double quote is created, so this is a liveness/consistency gap of the new shared quote entry rather than a loss. Fix: in the old-request branch read status/expires_ms and fail('ORDER_EXPIRED') when status='pending' and expires_ms<=freshNow, mirroring createEconomyOrder.","line":44,"path":"world-source/server/world-gold.ts","reproduction":"Scratch node script with tests/world-gold-audit5-fixture.mjs. f=await fixture(); r=crypto.randomUUID(); id=await goldQuote({db,config,nowMs:NOW,serviceReady:true},{wallet:W,requestId:r,product:'research'}); again=await goldQuote({db,config,nowMs:NOW+900000,serviceReady:true},{wallet:W,requestId:r,product:'research'}). Expected: ORDER_EXPIRED (as createEconomyOrder returns for a pending order with expiresMs<=now). Actual (run on this tree): again===id (true); the subsequent createEconomyGoldChallenge(db,config,{wallet:W,orderId:id,requestId:rid(),origin:'https://imdember.com',nowMs:NOW+900000,serviceReady:true}) throws ORDER_EXPIRED. Negative control: at nowMs:NOW+899999 the same order id is returned and the challenge succeeds.","severity":"info","snippet":" if(old){const link=await st(db,'SELECT p.product FROM world_gold_links l JOIN world_gold_products p ON p.id=l.product_id WHERE l.order_id=?',old.id).first<{product:string}>();if(link?.product!==args.product)fail('IDEMPOTENCY_CONFLICT');return old.id;}","title":"goldQuote returns the original order id for a reused requestId even when that pending order has already expired, unlike createEconomyOrder which refuses ORDER_EXPIRED; the caller gets a 200 with an un"}],"hash":"5ea4f25f1fbf48c4c14adfad878d6a6d1721f455218d02e33d951919a2798e44","nodeId":"783eb3d0-b517-45a3-a1f9-f7138f56f6c6","outcome":"completed","summary":"The review is complete and the findings file is written to `.imd-findings.json` in the repository root. Nothing else in the tree was changed.\n\n**Outcome: two findings, one low and one info. No critical, high or medium defects.** The D01 to D09 remediations hold up under independent probing, and the previous audit's ten items are closed on this tree.\n\n**What I verified by running code on this tree**\n\n- Selected SQL-level financial suites: 105 of 107 cases pass. The two failures need the private EDR chain and the `contracts/node_modules` dependency closure, which this packet does not ship. They are environment failures, not product defects.\n- Python bridge suites: all three pass when run individually (7, and the audit5/audit6 modules). The combined three-module invocation fails to import under `unittest`, which is a launcher quirk the packet itself documents.\n- My own probes against the real migrations through 0016 confirmed: exact int64 capacity reached through 1025 legitimate quotes; owed staking rewards stay outside book and available, peers and day markers still progress, and the owed row is credited exactly once after room appears; refund at capacity stays `failed` and settles once later; UTC boundary arithmetic (withdraw at exactly day end keeps that day, one millisecond earlier forfeits it); lease fencing at equality; legacy pre-0014 GOLD orders migrated forward are refused new challenges and appear in read-only inventory; BEFORE-trigger affinity on text-bound deltas does not weaken the capacity guard.\n\n**Findings**\n\n- **Low, `world-source/server/world-gold-result.ts:10`.** The result contract accepts any non-blank bare string. A provider that resolves `delivered` with upstream error text such as `\"error\"` gets a `delivered` job, the GOLD debit stands, `refundGold` and the admin refund both refuse, and the inspection helper reports the row as clean. Reproduced with the audit5 fixture; the control inputs `null` and `\"   \"` correctly refund.\n- **Info, `world-source/server/world-gold.ts:44`.** `goldQuote` returns the original order id for a reused request id even after that pending order expired, while `createEconomyOrder` refuses with `ORDER_EXPIRED` in the same situation. The caller receives a 200 with an unpayable order. No funds move.\n\n**Not reported as defects, stated for the record.** The D10 release gates remain open exactly as the packet says: no real provider, no finalized public-chain Mint reader, config still disabled. The Solidity contracts are unchanged originals and I found no issue in them; the repository has no Foundry project, so no forge proof was produced and none was needed given the severities. Passing these checks does not establish production safety.","treeHash":null,"usage":{"cachedInputTokens":3711172,"inputTokens":610,"model":"claude-fable-5-1","outputTokens":50680,"runtime":"claude","turns":62,"wallClockMs":869399}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"f96a0c89c039c22a","findings":[{"citation":"resolved","description":"reserveMintGold checks m.deadline<=nowMs once, using the caller-supplied nowMs. After that it awaits requireWorldGoldSchema, the existing-order SELECT, encodeMintAuth and goldFeature(db,'mint'). The db.batch that INSERTs world_gold_mints and the 'held' world_gold_holds row has no deadline predicate, and no 0014-0016 trigger checks the deadline on insert (the only deadline SQL is the release trigger in 0015). Unlike spendGold (line 50) and finishGoldJob, the function takes no now() resampler. This is the same stale-payment-time defect class the remediation says it fixed, left open on the Mint paid-hold entry point. The local runtime passes chain time read before any of this I/O (scripts/world-gold-local-runtime.mjs:26).","line":112,"path":"world-source/server/world-gold.ts","reproduction":"Reserve with deadline = T and nowMs = T-1. Make requireWorldGoldSchema or goldFeature take longer than 1 ms, so real time reaches T or later before db.batch runs (for example, a D1 stub that delays the controls SELECT by 5 ms). Expected: the call fails with INVALID_MINT_AUTH or MINT_AUTH_EXPIRED and writes no row. Actual: a 'held' mint and hold are inserted for an auth that is already dead at the deadline-equality boundary. That GOLD stays reserved until a proof reader releases it, and D05 says equality must be refused without creating a hold. Fix: accept now?:()=>number, resample right before db.batch (refuse when deadline<=fresh), and add a SQL guard, e.g. check(db, `?<deadline`) or INSERT ... SELECT ... WHERE deadline>fresh, in the same batch.","severity":"medium","snippet":" if(!/^0x[0-9a-f]{64}$/.test(m.id)||!Number.isSafeInteger(m.deadline)||m.deadline<=nowMs||!Number.isSafeInteger(m.chainId)||m.chainId<1||typeof m.chainInstance!=='string'||!/^[A-Za-z0-9._:-]{1,128}$/.test(m.chainInstance))fail('INVALID_MINT_AUTH');","title":"reserveMintGold checks the auth deadline against a stale caller time and never re-checks it before the atomic hold insert"}],"hash":"7f82fd85f749378d8219b0ef1201901e58026cef2fc5a0705f7074bb126b0d8a","nodeId":"dbdd9610-9fcf-403e-8b44-ce074e51f50f","outcome":"completed","summary":"This was a narrow review: I found one defect, rated medium, and most of the assigned area is still unreviewed. I ran none of the `LOCAL_TESTS.md` checks and wrote no Foundry test. The finding is in `.imd-findings.json` with its path, line and snippet copied from the file.\n\n**Finding: the Mint paid-hold checks its deadline against an old clock reading.** This is in `reserveMintGold` (`world-source/server/world-gold.ts:112`).\n- **What happens:** the function compares the authorisation deadline to the time the caller passed in. It then waits on several database reads (the schema check, the existing-order lookup and the mint feature check). The final write that creates the `held` mint and hold rows has no deadline condition, and no trigger in migrations 0014–0016 adds one.\n- **Why it matters:** it is the same \"payment time went stale during I/O\" defect the remediation says it fixed. The other spend path resamples the clock right before the write (line 50), so the fix was applied there but not on the Mint hold.\n- **Failing input:** a deadline of `T` with a caller time of `T-1`, where the reads take more than 1 ms. A hold is created for an authorisation already dead at the deadline, which D05 says must be refused. That GOLD stays reserved until the proof reader releases it.\n- **Fix:** take a fresh clock reading immediately before the write, refuse if the deadline has passed, and add the same deadline condition to that SQL write.\n\n**Not covered:** the other credit sources (purchase, staking and owed rewards, refunds, admin, recovery), the readiness and migration checks in D03, the bridge identity flow in D04, and the result contracts in D06. The Solidity contracts were not opened at all. This result does not mean the rest of the code is free of findings.","treeHash":null,"usage":{"cachedInputTokens":275205,"inputTokens":16,"model":"claude-opus-5-5","outputTokens":2415,"runtime":"claude","turns":8,"wallClockMs":40065}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"3f91b58cf7cd2d45","findings":[{"citation":"resolved","description":"D-02 closed the legacy catalogue route only for currency GOLD. createEconomyOrder (reached from POST /api/economy/orders, server/economy.ts line 67) refuses a shared-DB catalogue order when args.currency==='GOLD' but still inserts one for currency 'EMBEO' from config.catalogue (line 257-264). That order carries no world_gold_links row, so none of the shared-mode gates apply to it: the world_gold_controls 'service' pause, the serviceReady (trusted runtime provider) requirement and the result-contract check in sharedServiceAdmission (lines 212-221) are only consulted on the GOLD challenge/debit path, and goldQuote's product/control predicate (world-gold.ts line 54) is bypassed because the order never goes through goldQuote. When the player pays the quote on-chain, ingestEconomyEvents marks it paid (line 84) and the 0010 trigger economy_order_paid writes economy_fulfillments; reconcileWorldGold ignores it (no link), runGoldServiceJobs never sees it (no world_gold_jobs row), refundGold and the admin refund-service action both refuse it, and nothing in the packet consumes economy_fulfillments. Real EMBEO therefore reaches the treasury for a service that cannot be delivered or refunded, exactly the asymmetry D-02 removed for GOLD. REQUIREMENTS.md: 'Service debit creates one durable job' and 'Pause only new admissions by feature'. Trust assumption: reachable only once a reviewed EconomyConfig carries a catalogue entry with an embeo price (reviewedEconomyConfig is null today and the fixture catalogue is empty), which is the stated release path. Fix: in shared mode refuse every catalogue service admission (throw LEGACY_GOLD_ORDER_UNSUPPORTED / LEGACY_ORDER_UNSUPPORTED for both currencies, or require config.catalogue to be empty when world_gold tables exist) and route EMBEO purchases through goldQuote topup products so they carry a link and a bounded entitlement.","line":256,"path":"world-source/server/economy-ledger.ts","reproduction":"Scratch node:test in a copy of world-source with its lock installed (run from tests/scratch/). db=openD1() (all migrations through 0016); config=defineEconomyConfig({chainId:1,token:ECONOMY_TOKEN,treasury:ECONOMY_TREASURY,stakingContract:0x11..,paymentContract:0x22..,tokenDecimals:18,deploymentBlock:'100',catalogue:[{id:'legacy-research',titleZh:'a',titleEn:'a',gold:'3',embeo:'5'}]}); insert an EOA/ECDSA session for W=0xaa..aa. Negative control: createEconomyOrder(..currency:'GOLD'..) rejects LEGACY_GOLD_ORDER_UNSUPPORTED. Then goldAdminCommand control service enabled:false version:0 (and serviceReady is never true). createEconomyOrder({wallet:W,requestId:'s'*20,serviceId:'legacy-research',currency:'EMBEO',nowMs:NOW,authorization:{tokenHash}}) -> actual: returns order {currency:'EMBEO',amount:'5',status:'pending'}. ingestEconomyEvents with the matching Paid event at block 100 (payer W, amount '5', token/treasury from config) -> economy_orders.status='paid'. reconcileWorldGold(db,NOW+200) -> {processed:0,failures:[]}; SELECT COUNT(*) FROM world_gold_links WHERE order_id=id -> 0; world_gold_jobs -> 0; economy_fulfillments -> 1. refundGold(db,id,NOW+300) rejects (REFUND_NOT_ENTITLED) and goldAdminCommand refund-service for the id rejects. Expected: the shared-mode admission is refused (coded LEGACY_*_UNSUPPORTED / FEATURE_PAUSED / SERVICE_DELIVERY_UNAVAILABLE) before any EMBEO quote is issued, as it is for GOLD.","severity":"low","snippet":"  if(shared&&args.currency==='GOLD')throw new EconomyConflict('LEGACY_GOLD_ORDER_UNSUPPORTED');","title":"Shared mode still admits unlinked legacy EMBEO catalogue service orders: EMBEO is collected by the treasury while the service feature is paused and no delivery provider is bound, with no link, job, de"}],"hash":"9fb21dc45a9874dd2cc07670ba8e90b16dd1f58f9acf688341eb35714e3ee85d","nodeId":"c92ca3e2-3248-4847-8ec5-aa05d3a4763a","outcome":"completed","summary":"The review is complete and the findings file is written. Here is the recap.\n\n**Outcome.** One substantiated finding, severity Low, is in `.imd-findings.json`. No repository file was changed. The packaged audit6 suite passes in my scratch copy, so the reproduction environment matches the project's own.\n\n**The finding.** In shared mode, the legacy catalogue route still admits EMBEO service orders. The D-02 remediation in `world-source/server/economy-ledger.ts` refuses catalogue orders only when the currency is GOLD. An EMBEO catalogue order never passes through the quote path, so it carries no link, and the service pause, the trusted-provider readiness gate and the result-contract gate never apply to it. Once the player pays on-chain, the indexer marks it paid, a fulfillment row is written, and nothing in the packet can deliver or refund it. Real EMBEO reaches the treasury for a service that cannot be delivered. The reproduction in the findings file shows the GOLD twin refused as a negative control, then the EMBEO order admitted with the service feature paused and no provider bound, paid, and refused by both refund paths. This is reachable only once a reviewed config carries a priced catalogue entry, which is the stated release path.\n\n**What I checked and found sound in the assigned area.**\n- The three Solidity contracts: owner powers on the Mint candidate are role-gated and two-step, the paid authorization binds wallet, key, URI hash, recipient, costs, epoch and deadline, and the payment and vault adapters expose no admin or rescue entry. The EMBEO token fixture has no burn or mint, so the vault's fixed-supply check cannot be turned into a principal freeze.\n- The World HTTP permission layer: admin commands require the three-wallet allowlist plus a live EOA ECDSA session, writes require a matching Origin and expected wallet, ERC-1271 sessions can read but not write, and admin repair and refund actions are bounded by SQL entitlement predicates. A repair on an unpaid order aborts and credits nothing.\n- The AIMarket bridge and the Python consumer: the external profile never receives World trial rights, expired identities deny and revoke cleanly, and the session re-read after balance I/O holds.\n- The Mint fixture service: deadline reuse is strict and the feature pause now gates only the paid route.\n\n**Limits.** No Foundry proof was produced because the single finding is Low and lives in TypeScript. The full 433-test financial suite, the Solidity 30 and the Python 18 were not rerun end to end within the time budget. Only the audit6 suite and my two scratch probes ran. A clean pass on the areas above is not proof that no other defect exists.","treeHash":null,"usage":{"cachedInputTokens":2910294,"inputTokens":514,"model":"claude-fable-5-1","outputTokens":33457,"runtime":"claude","turns":50,"wallClockMs":499191}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"d68ba89c0b30801c","findings":[],"hash":"b0fc17df600da4a6bc6728d3067cdf0651caaf2bdfdd83626995746aecc33b4f","nodeId":"114c6dba-5297-465e-a246-747edf285b13","outcome":"completed","summary":"The review is complete. `.imd-findings.json` holds an empty findings list, and no repository file was changed.\n\n**Result: no substantiated math, precision, boundary, or numerical-gap defect in the remediated paths at commit e5ca6e5.** Every seam I probed behaved as the stated rules require.\n\n**What I checked and how**\n\n- **Solidity** (`contracts/src/*.sol`, `mint/contract/.../EmberEvoGenesisCandidate.sol`): share arithmetic is checked, the exact-transfer adapter measures balances before and after, supply pins are safe because the pinned EMBEO fixture exposes no burn or mint, and the Mint counters, supply cap, and `<=` deadline comparisons are consistent with the off-chain reuse/release boundaries. No Foundry proof was warranted.\n- **Int64 capacity guards** (migrations 0015/0016): ran the real migrations in `node:sqlite`. A reward of 5 at balance MAX−5 credits to exactly MAX; a following reward of 1 is kept as an owed row with the day still marked settled. Text-bound deltas are coerced to integer before the capacity and hold triggers, so type affinity cannot bypass them.\n- **Holds and debits**: a second hold exceeding available aborts, a debit that would dip below held aborts with `GOLD_RESERVED`, and a debit leaving balance equal to held succeeds.\n- **Partial legacy topup credits**: a legacy entry of 4 on a 10-GOLD link yields exactly a 6 remainder with the canonical reference, and any further credit is refused.\n- **UTC day boundaries**: ran the real `settleEconomy` and `ingestEconomyEvents` end to end. Deposit at midnight earns the full day, deposit one second later earns nothing that day, and a withdrawal at exactly the next midnight still earns the prior day while forfeiting the new one. Entitlement rows match the journals one for one.\n- **Clock and expiry equality**: order, challenge, lease, campaign, bridge-session, and Mint-deadline comparisons use the same half-open convention in TypeScript, SQL, and Python, with consistent seconds-to-milliseconds conversion.\n\n**Limits of this review**\n\n- The World suite could not be run as packaged because no dependency lockfiles were installed here. My ledger probes ran against the committed SQL and server code with a stub for the one external signature-recovery import.\n- Release gates listed under D10 remain open by the requester's own statement and were not treated as defects.","treeHash":null,"usage":{"cachedInputTokens":2763093,"inputTokens":610,"model":"claude-fable-5-1","outputTokens":40889,"runtime":"claude","turns":43,"wallClockMs":631743}}],"verification":[]}