{"workflow":null,"planning":null,"id":"b0233dd8-81bb-4564-a12d-6b5b02401b81","state":"completed","template":"audit","objective":"Basket (BASK) is an immutable index vault for Stock Tokens on Robinhood Chain (chain id 4663), deployed at 0xb5878b75d0a329b0edca2b85f04349050b2300af with nothing listed yet. A user deposits one or more listed tokens in one call, each priced by its feed, and receives BASK; redeem burns BASK for a pro-rata share of every held token, paid at once while at most directLimit (25) assets are held, otherwise booked as owed and collected with claim(tokens[], to). A deposit also needs, for every deposited and held token, its Uniswap v3 pool's 30-minute mean price (in quote tokens times the quote feed, with a mean-liquidity floor) within 3% of its feed; a token with no usable pool needs a feed under 26 hours old instead. The pool only blocks; it never sets the price. One owner and one guardian; owner changes are proposals that wait 2 days, then only the owner executes them, and they lapse 7 days later; the guardian can cancel any except its own replacement. Settings change only by proposal within fixed bounds. Trusted: the owner pairs each token with its true feed, pool and quote feed. The issuer can pause, block, burn or upgrade the Stock Tokens; feeds update only on weekdays. This is the fourth build. New since the third: no deposit hours (optional setting, off), no waiting period and no daily limit; any ERC-20 and feed with up to 18 decimals; up to 250 assets; multi-token deposits; booked redemption and batched claims; owner-only execution; the pool check; settings; no fee at all while the fee recipient is unset (set by proposal); removal of a retired empty asset and relisting; a resync proposal.\n\nLook hardest at:\n\n1. Redeem and claim can never be blocked or made to revert: not by the owner, the guardian, any in-bounds setting or combination of settings (balanceGas, payGas, directLimit, maxAssets), a paused, blacklisted, reverting, gas-burning, lying or upgraded token, a stale or wrong feed, pool or quote feed, retirement or removal. With maxAssets assets in any state a redeem must stay under 28,000,000 gas, on both the direct and the booked path. Check the managed bitmap, the vault-only pay function and the owed and totalOwed accounting.\n\n2. The pool check: PoolOracle.consult and quote, TickMath, token0/token1 orientation, 6-decimal USDG and 18-decimal WETH quotes, the harmonic-mean liquidity against minLiquidity, poolGas, overflow and rounding. Can a pool, quote feed or feed make deposit, depositStatus, previewDeposit or allAssets revert instead of returning a reason, or change the number of shares minted?\n\n3. Nobody can move assets out except redeem and claim paying the user, and nobody can mint BASK except deposit (plus the fee shares and the 1e15 dead shares on the first deposit). No fee may be charged while feeRecipient is unset; once set, exactly 0.5% in and 0.5% out. Look at every proposal action, executeProposal, resync (can it count owed tokens into managed?), removeAsset, closeAsset, recognizeLoss and reentrancy.\n\n4. Proposals: can anyone but the owner execute; can one skip the 2 days or escape the guardian's cancel; can a voided, expired or stale proposal execute after a retire, a removal and relisting, or a NAV cap lowering; can a setting leave its bounds or break the two gas rules (maxAssets x (balanceGas + 60,000) and directLimit x (balanceGas + payGas + 60,000) at most 28,000,000); can the guardian become owner by any sequence.\n\n5. Deposit share math: rounding direction, first-deposit and donation attacks, managed versus balance, the rule that a deposited token's balance must cover totalOwed, flagDeficit and recognizeLoss after an issuer burn, and the inline assembly under via_ir (Calls, the balance read, the Transfer log, the pendingProposals length rewrite).\n\n6. Known deviation, please confirm and look for a remedy: the text says a retired asset is skipped by deposit checks and 0 in NAV, but the build stops every deposit while any retired asset has managed above 0 (RetiredBacking), and the permanent 1e15 shares keep it above 0. So a held token that its issuer pauses for good, or whose balance becomes unreadable, would stop all deposits for good. Is there any owner path that resumes deposits in that state?\n\nAccepted by the owner, report only if worse than stated here: no per-asset limit (one stock may be any share of NAV); profit from feed lag within the 3% pool deviation; anyone can stop deposits by moving a thin pool; a held token with no usable pool stops deposits at weekends; no fee while the fee recipient is unset; tokens the issuer credits by raising balances stay outside managed until a resync; an unreadable balance during a shortfall books the leg from managed and claims are paid first come, first served; a complete loss leaves NAV at 0 and deposits stop; the two-step ownership handover takes effect at once; a token upgraded to debit more than the amount strands its claims; the guardian cannot cancel its own replacement; a retired asset that ever held tokens keeps a dust balance, so its slot is in practice not freed; redemption minimums are positional; BASK sent to the vault's own address is lost.","blockedReason":null,"createdAt":"2026-10-08T05:04:50.553Z","updatedAt":"2026-10-08T05:59:11.308Z","paidBy":"0x30b57ecf51d19abced7f6f70974e6fbb6f3b9da3","parentJobId":null,"project":{"id":"b0233dd8-81bb-4564-a12d-6b5b02401b81","head":"b0233dd8-81bb-4564-a12d-6b5b02401b81","running":null,"versions":[{"jobId":"b0233dd8-81bb-4564-a12d-6b5b02401b81","workflowId":null,"objective":"Basket (BASK) is an immutable index vault for Stock Tokens on Robinhood Chain (chain id 4663), deployed at 0xb5878b75d0a329b0edca2b85f04349050b2300af with nothing listed yet. A user deposits one or more listed tokens in one call, each priced by its feed, and receives BASK; redeem burns BASK for a pro-rata share of every held token, paid at once while at most directLimit (25) assets are held, otherwise booked as owed and collected with claim(tokens[], to). A deposit also needs, for every deposited and held token, its Uniswap v3 pool's 30-minute mean price (in quote tokens times the quote feed, with a mean-liquidity floor) within 3% of its feed; a token with no usable pool needs a feed under 26 hours old instead. The pool only blocks; it never sets the price. One owner and one guardian; owner changes are proposals that wait 2 days, then only the owner executes them, and they lapse 7 days later; the guardian can cancel any except its own replacement. Settings change only by proposal within fixed bounds. Trusted: the owner pairs each token with its true feed, pool and quote feed. The issuer can pause, block, burn or upgrade the Stock Tokens; feeds update only on weekdays. This is the fourth build. New since the third: no deposit hours (optional setting, off), no waiting period and no daily limit; any ERC-20 and feed with up to 18 decimals; up to 250 assets; multi-token deposits; booked redemption and batched claims; owner-only execution; the pool check; settings; no fee at all while the fee recipient is unset (set by proposal); removal of a retired empty asset and relisting; a resync proposal.\n\nLook hardest at:\n\n1. Redeem and claim can never be blocked or made to revert: not by the owner, the guardian, any in-bounds setting or combination of settings (balanceGas, payGas, directLimit, maxAssets), a paused, blacklisted, reverting, gas-burning, lying or upgraded token, a stale or wrong feed, pool or quote feed, retirement or removal. With maxAssets assets in any state a redeem must stay under 28,000,000 gas, on both the direct and the booked path. Check the managed bitmap, the vault-only pay function and the owed and totalOwed accounting.\n\n2. The pool check: PoolOracle.consult and quote, TickMath, token0/token1 orientation, 6-decimal USDG and 18-decimal WETH quotes, the harmonic-mean liquidity against minLiquidity, poolGas, overflow and rounding. Can a pool, quote feed or feed make deposit, depositStatus, previewDeposit or allAssets revert instead of returning a reason, or change the number of shares minted?\n\n3. Nobody can move assets out except redeem and claim paying the user, and nobody can mint BASK except deposit (plus the fee shares and the 1e15 dead shares on the first deposit). No fee may be charged while feeRecipient is unset; once set, exactly 0.5% in and 0.5% out. Look at every proposal action, executeProposal, resync (can it count owed tokens into managed?), removeAsset, closeAsset, recognizeLoss and reentrancy.\n\n4. Proposals: can anyone but the owner execute; can one skip the 2 days or escape the guardian's cancel; can a voided, expired or stale proposal execute after a retire, a removal and relisting, or a NAV cap lowering; can a setting leave its bounds or break the two gas rules (maxAssets x (balanceGas + 60,000) and directLimit x (balanceGas + payGas + 60,000) at most 28,000,000); can the guardian become owner by any sequence.\n\n5. Deposit share math: rounding direction, first-deposit and donation attacks, managed versus balance, the rule that a deposited token's balance must cover totalOwed, flagDeficit and recognizeLoss after an issuer burn, and the inline assembly under via_ir (Calls, the balance read, the Transfer log, the pendingProposals length rewrite).\n\n6. Known deviation, please confirm and look for a remedy: the text says a retired asset is skipped by deposit checks and 0 in NAV, but the build stops every deposit while any retired asset has managed above 0 (RetiredBacking), and the permanent 1e15 shares keep it above 0. So a held token that its issuer pauses for good, or whose balance becomes unreadable, would stop all deposits for good. Is there any owner path that resumes deposits in that state?\n\nAccepted by the owner, report only if worse than stated here: no per-asset limit (one stock may be any share of NAV); profit from feed lag within the 3% pool deviation; anyone can stop deposits by moving a thin pool; a held token with no usable pool stops deposits at weekends; no fee while the fee recipient is unset; tokens the issuer credits by raising balances stay outside managed until a resync; an unreadable balance during a shortfall books the leg from managed and claims are paid first come, first served; a complete loss leaves NAV at 0 and deposits stop; the two-step ownership handover takes effect at once; a token upgraded to debit more than the amount strands its claims; the guardian cannot cancel its own replacement; a retired asset that ever held tokens keeps a dust balance, so its slot is in practice not freed; redemption minimums are positional; BASK sent to the vault's own address is lost.","baseCommit":"85b8ccb40e91989416d02f44f78ea8437ecad84c","state":"completed","createdAt":"2026-10-08T05:04:50.553Z"}]},"deliver":false,"host":false,"site":null,"launch":{"requested":false,"kind":null,"id":null,"status":null,"chainId":null},"oracleRequestId":null,"delivery":null,"media":null,"nodes":[{"key":"audit_economics","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-08T05:24:29.923Z","verdict":null,"seat":{"tokenId":"1735","agentId":"51319"},"live":null},{"key":"audit_flow","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-08T05:39:38.904Z","verdict":null,"seat":{"tokenId":"1803","agentId":"52179"},"live":null},{"key":"audit_judge","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":["audit_math","audit_permissions","audit_economics","audit_flow"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-08T05:59:11.308Z","verdict":null,"seat":{"tokenId":"1314","agentId":"51285"},"live":null},{"key":"audit_math","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-08T05:27:47.613Z","verdict":null,"seat":{"tokenId":"999","agentId":"52287"},"live":null},{"key":"audit_permissions","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-08T05:29:44.832Z","verdict":null,"seat":{"tokenId":"293","agentId":"51139"},"live":null}],"reviews":[{"status":"queued","chainId":1,"txHash":null,"blockNumber":null,"sentAt":null,"entries":[{"nodeKey":"audit_economics","agentId":"51319","value":1,"role":"review:submission"},{"nodeKey":"audit_flow","agentId":"52179","value":1,"role":"review:submission"},{"nodeKey":"audit_judge","agentId":"51285","value":1,"role":"review:submission"},{"nodeKey":"audit_math","agentId":"52287","value":1,"role":"review:submission"},{"nodeKey":"audit_permissions","agentId":"51139","value":1,"role":"review:submission"}]}]}