{"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":"1a751f97-4657-4c3b-989c-cb1f3ab02c66","kind":"shape:chain","nodes":[{"acceptedSubmissionHash":"ef272e22316ccfff0311274e810ea8824f6bc93fbfc90bc8907065c2efd862b8","dependsOn":["frontend_for_contract","site_content_check"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"6b037a7b6601e883cf8a906c1520c0624817d42d8310b65c2f43679204608af3","skillId":"adversarial-review","tools":[]},"key":"adversarial_review","kind":"code","role":"review","skillHash":"6b037a7b6601e883cf8a906c1520c0624817d42d8310b65c2f43679204608af3","skillId":"adversarial-review","state":"accepted"},{"acceptedSubmissionHash":"9f9a2bbd27188a73a2c9be8e7bb14404366834e121c2d2b9fba246a0142d0051","dependsOn":["frontend_for_contract"],"execution":{"network":true,"optionalTools":["browser"],"profile":"none","requires":["network"],"skillHash":"4a5e9fb083a47bea78572ce4262f6ed18e7af57736a86ec2bbb7d17a8c72c62e","skillId":"design-critic","tools":[]},"key":"design_critic","kind":"code","role":"review","skillHash":"4a5e9fb083a47bea78572ce4262f6ed18e7af57736a86ec2bbb7d17a8c72c62e","skillId":"design-critic","state":"accepted"},{"acceptedSubmissionHash":"d5be08bfbee71a38241723b153fb81f56735436f3a83a3a9ea135118985cd29b","dependsOn":[],"execution":{"mustProduce":["dist/index.html"],"network":true,"optionalTools":["browser"],"profile":"none","requires":["network"],"skillHash":"ed66ac168d7374db08ca358b6745195f339b0c74331416d3620ee268632b790c","skillId":"frontend-for-contract","tools":[]},"key":"frontend_for_contract","kind":"code","role":"implement","skillHash":"ed66ac168d7374db08ca358b6745195f339b0c74331416d3620ee268632b790c","skillId":"frontend-for-contract","state":"accepted"},{"acceptedSubmissionHash":"2645901dfa6702e5ee19506a314a02961a7ca7847a64b7ed477b44461b62a4c8","dependsOn":["frontend_for_contract"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"8189a3059fc9bb774ad7dcee66b87f32e25d781025f0e9f82a4c75182fe0ef19","skillId":"site-content-check","tools":[]},"key":"site_content_check","kind":"code","role":"review","skillHash":"8189a3059fc9bb774ad7dcee66b87f32e25d781025f0e9f82a4c75182fe0ef19","skillId":"site-content-check","state":"accepted"}],"objective":"Build the Marginalia site against the live launch #1283 contracts (hook 0xf0457dd0cf526686190e4f057ba19db14d34a0cc on Ethereum mainnet; router, judge, treasury via hook.router()/judge()/treasury(); MARG 0xfa0efea559bde229031c2b0a219472316647759c; IMD 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7). A static site, wallet-connected, reading the chain directly: (1) FEED of notes and theses from NotePosted events with live status from noteOf (open / right / wrong / void / retracted / thesis open / closed), author, token, side, target, horizon, bond, text, outcome and settle price from Settled; filters by token and author; (2) AUTHOR page: the record (score, posted, right, wrong, retracted) from records(address) and the author's notes; (3) NOTE page: the observations (Observed events), horizon end, settlement window, the outcome, parent/child links; (4) POST flow: choose token X and venue (Uniswap v4 pool key, v3 pool or v2 pair), call router.checkpointVenue first and show the one-hour wait clearly, then router.note(params, v4Key, imdIn, minMargOut, deadline) with the bond chosen inside BOND_MIN..BOND_MAX, IMD approval, and the stamp + MARG_BUY explained; theses (targetBps 0) with long text; counters via parentId; (5) SEAL flow: compute sealHash(author, params) client-side, call hook.seal(x, venue, hash), show the 30 min to 6 h reveal window and reveal by posting the same params; (6) POOLS page: refundPool(today), thesisPool(week), sweep and judging state; claimDeposit / claimRefund buttons for the connected author. Plain language throughout: a bonded feed, not a perp DEX, not a prediction market; nothing pays for being right; informational, not advice. Mobile-first, no backend, no analytics, no external APIs except the chain RPC. VERIFIED SPECIFICS (from a working prototype against the live contracts; use them as given): hook.router() = 0xa3579D7c59A2C0c742fC4e5BB18AF93241D1d263 and hook.judge() = 0xa9e1891d76553195B4Cbcd0F8Db290C8C0FA28B9 (EIP-1167 clones; ABIs = MarginaliaRouter / MarginaliaJudge in this repository). Posting pulls IMD from the author by transferFrom, so the author approves the ROUTER for imdIn = STAMP 0.1 + MARG_BUY 0.25 + bond (bond in BOND_MIN 0.25 .. BOND_MAX 10 IMD). router.note(p, v4Key, imdIn, minMargOut, deadline) where minMargOut covers only the MARG_BUY leg (0.25 IMD worth of MARG at hook.margPriceInImd(), which returns IMD per MARG scaled 1e18; allow ~10% slippage). NoteParams.venue for the launch pool: kind 1 (UniV4), ref = keccak256(abi.encode(currency0 IMD 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7, currency1 MARG, fee 12500, tickSpacing 60, hooks = the hook)), quote and xIsToken0 are derived by the router (pass IMD / false); pass the full PoolKey as v4Key. For a v3 pool: kind 2, ref = the pool address left-padded to bytes32; v2 pair: kind 3; v4Key then ignored. The venue must be quoted in IMD, WETH or native, and X must be a token of the pool. class = 1 (the router sets Traded/Agent itself). targetBps = 10000 + pct*100 for BUY, 10000 - pct*100 for SELL, min 10% away; a thesis is targetBps 0 and horizonDays 0 with text up to THESIS_TEXT_MAX 8192 bytes; call text up to TEXT_MAX 280 bytes. Checkpoint state: router.validateVenue(p, key) returns the derived Venue; router.priceWindows(keccak256(abi.encode(venue))) .startedAt is the window start; a post needs it 1 h to 6 h old; show a countdown. records(address) returns (int256 score scaled 1e4, uint32 posted, right, wrong, broken, retracted, judgedWins). noteOf(id) returns (author, x, side, targetBps, horizonDays, class, status, postPrice, postBalance, deposit, parentId, children); status enum Open, Right, Wrong, VoidSold, VoidNoData, Retracted, ThesisOpen, ThesisClosed. The venue is not in NotePosted nor noteOf: keep it client-side when posting. Public read RPC: any mainnet RPC; note that free-tier Alchemy limits eth_getLogs to 10 blocks per call, so read logs from a node that serves wide ranges (e.g. ethereum-rpc.publicnode.com) in ≤2000-block chunks from deploy block 26169583. Observations: hook.observe(id) is permissionless inside the 6 h window after horizonEnd(id); settle(id) after it; a keeper runs these, the site only shows them. ALSO: (7) VENUE FINDER: given a token address, resolve its canonical venues for the user instead of asking for a pool address: Uniswap v3 factory 0x1F98431c8aD98523631AE4a59f267346ea31F984 getPool(token, WETH 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 or IMD, fee in {100, 500, 3000, 10000}) and Uniswap v2 factory 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f getPair(token, WETH or IMD); list the ones that exist with their liquidity and let the user pick; the launch pool is the only v4 venue offered. (8) PERMISSIONLESS KEEPER BUTTONS on the note page: when a call is inside its 6 h settlement window show an 'Observe' button calling hook.observe(id), and after the window a 'Settle' button calling hook.settle(id) (10% of a forfeited bond goes to the settler); on a thesis past its 7-day grace with no child, 'Forfeit' calling settleThesis(id). Anyone may press them; explain why. (9) SEALED-NOTE TEXT: v1 keeps the sealed text with the author (the site shows the seal event, the hash, the window and the reveal); delivery to key holders arrives with the key market in a later iteration — say so on the seal page. (10) The site's canonical links: x.com/marginalia_md, the explorer launch page, and the hook/MARG addresses in full in the footer with the line 'Informational and research purposes only. Not financial advice. Bonds can be lost.' REVIEW BRIEF for the review steps (read-only, before hosting): verify every contract address against the live ones named above; verify that approvals target ONLY the router and only for the amount shown; verify that every transaction the page builds matches the router/hook ABIs in this repository; verify there are no external scripts, no third-party RPC beyond the user's wallet and the public read node, no analytics, no remote code loading, no obfuscated code; verify the venue finder uses the canonical Uniswap factory addresses named above; verify the copy never promises returns, never says 'buy', and shows the disclaimer. Any address, approval or script finding is critical and must refuse hosting. LOOK: a ledger, not a terminal. Paper and ink: light background #f6f1e7 with ink #1d1a16, rust accent #b9471f for links and the primary button, a hairline rule #d9cfbd between entries; dark mode inverts to #15130f / #ece5d6 with the same accent. Serif body type (Iowan Old Style / Palatino / Georgia fallback), monospace only for addresses and ids. The mark is the manicule ☞ (a pointing hand, the marginalia glyph) next to the word Marginalia in the header. Notes render as entries in a ledger: a status tag, the token and the claim on one line, the text beneath, the author and bond in small type. No gradients, no glassmorphism, no stock crypto imagery, no charts. Mobile first; one column; 17px base.","parentJobId":"9060a248-29ce-4683-b5d1-54fbc83cd49d","planHash":"e9a3856259e8c94bdc40b2bcdbe6aee84e530423b85a3ecc248fd4aa0842f124","previousHash":"2b68758e0d5af4db3397bf37845d1aa6b5522dc34e689f56c383ca697f0f580b","projectId":"9060a248-29ce-4683-b5d1-54fbc83cd49d","publication":{"commit":"be207a07c0872f89ff17e5a66133d01070d853b9","deliveredAt":"2026-10-12T03:22:04.465Z","repoUrl":"https://github.com/identity-md-launches/launch-1283-marginalia-x-com-marginalia-md-notes-mar"},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[],"site":{"cid":"bafybeibo5rw3tq4ukuphzihj7kmw2gbkbi7sfhddt36m3vcwcj73fhoknu","ensName":"marginalia.site.identitymd.eth","namingTransaction":"0x546c8cda0176229d1256f316b7f70196ee6e8fcd3db05d7fb5353cd4a001e76d"},"snapshotHash":"f3bf846c0850cf351fee78f9a7e400e00fce2c09b6a4122dd9afcf94f4fb44d2","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":"c0f23265ed97309523de88c9ab25f7f092626e1b611e2ab4ac54765e6ba1d790","device":"72b617d4b615473a","findings":[],"hash":"08232b5ab32c67822457f0673e14f6d389eff8dfaf60624036e0633a541356b8","nodeId":"9d6d2b49-9f21-43a1-96bd-e6347cb0561b","outcome":"completed","summary":"The work is committed and the tree is clean. Here is the report.\n\n## What was built\n\nThe Marginalia site is a static Vite, React and TypeScript app in `web/`, exported to `dist/` with a relative base and hash routing, committed as `b0358c8` with its lockfile. It reads Ethereum mainnet through the two public RPCs from `network.json` and signs only through the visitor's injected wallet.\n\n- **Feed, author, note, pools, about pages** read `NotePosted`, `Settled`, `Observed`, `Sealed`, `Revealed` and `Retracted` logs in 2000-block chunks from the deploy block, joined with live `noteOf`, `records`, `refundPool`, `thesisPool` and the judge's week state.\n- **Post flow** runs a venue finder (launch v4 pool for MARG, v3 pools at the four fee tiers and v2 pairs against WETH and IMD, only with liquidity), derives the venue through `router.validateVenue`, checkpoints the venue and shows the one-hour wait as a countdown, breaks down stamp + MARG purchase + bond, approves IMD to the router for exactly that total, then simulates and sends `router.note`. Theses and counters via parent id are supported.\n- **Seal flow** computes `sealHash` client-side, calls `hook.seal`, shows the 30 min to 6 h reveal window, lists the author's seals and prefills the post form to reveal. The page states that sealed text stays with the author in v1.\n- **Keeper buttons** (Observe, Settle, Forfeit thesis) and author claims (deposit, refund) sit on the note page; sweep is on the pools page. The footer carries the canonical links, the full hook and MARG addresses and the required disclaimer line.\n- `dist/imd-deployment.json` is generated by `web/scripts/manifest.mjs` and loaded by the app at runtime for addresses, chain and network; router, judge and treasury come from the hook, not from typed-in addresses.\n\n## Verification\n\nTypecheck and production build passed. `web/scripts/check.mjs` confirmed the manifest structure, every asset's SHA-256, both ABI hashes against the handoff (canonical sorted-key keccak), a byte-equal network block, no extra keys, and no absolute or remote references. A read-only scratch script checked 23 encodings against the live contracts, including `sealHash`, `sealKey`, `poolId`, `validateVenue` derivation, the router's factory constants and the ABI subsets. Details are in `web/VALIDATION.md`; design tokens and components are in `DESIGN.md`.\n\n## Not done, stated plainly\n\n- **No browser inspection.** The browser tool blocks `file:` URLs, no preview was supplied, and a bounded local server was unreachable from it. No screenshots exist and no rendered or contrast check is claimed. The validation record marks the assignment incomplete on that point.\n- **No mocked-wallet interaction tests** and no live transactions. Transaction paths are verified to argument construction and encoding only.\n- **One deviation from the review brief:** sealing needs an IMD approval of exactly one stamp to the hook, because the hook pulls the seal stamp itself. The page explains it; posting approvals target only the router.\n- A new `web/.gitignore` containing only `node_modules/` was added so the dependency tree cannot enter the submission.","treeHash":"64d1f03bc2a9eca4f43008ffb3cbf17e7ee68996","usage":{"cachedInputTokens":3645629,"inputTokens":898,"model":"claude-fable-5-1","outputTokens":101203,"runtime":"claude","turns":71,"wallClockMs":1805097}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"30bcdea6dcb9ee40","findings":[{"citation":"resolved","description":"The brief asks for a SEAL flow that computes sealHash(author, params) client-side and calls hook.seal(x, venue, hash). The hosted Seal page computes the hash, shows the checkpoint state and the 30 min to 6 h window, but its Seal button is hard-disabled and no code path builds a hook.seal transaction (web/src/pages/Seal.tsx:55 explains why: the live hook pulls its 0.1 IMD stamp itself through _fund(STAMP) -> IERC20(imd).safeTransferFrom(msg.sender, hook, amount) at src/MarginaliaHook.sol:822 and :786, so sealing needs an IMD allowance to the hook, and the brief's review rule 'approvals target ONLY the router' forbids that). The two requirements in the brief conflict; the site chose the approval rule and documents the gap on the page and in web/README.md. This is a scope gap for the requester to decide, not a hosting hazard: no approval or transaction is built, and the explanation shown to visitors is accurate. If sealing is wanted, the only way to deliver it is an exact-amount (STAMP) IMD approval to the hook address taken from imd-deployment.json, which the review rule would then have to permit explicitly.","line":81,"path":"web/src/pages/Seal.tsx","reproduction":"Open dist/index.html#/seal, connect a mainnet wallet, enter a token with a canonical venue, pick the venue, fill side/target/horizon/text. Expected per brief: a Seal button that sends hook.seal(x, venue, sealHash). Actual: the hash is shown, a red notice reads 'New sealing is unavailable on this site', the Seal button stays disabled regardless of wallet or checkpoint state; grep -n \"functionName: 'seal'\" web/src returns nothing.","severity":"medium","snippet":" ","title":"Seal flow (deliverable 5) is not operational: the Seal page never calls hook.seal"},{"citation":"resolved","description":"The post form fills NoteParams.x with the MARG address for every thesis (the hook accepts any x for targetBps 0; src/MarginaliaHook.sol _postNote skips _checkCallVenue for theses). The feed filter at web/src/pages/Feed.tsx:76 matches notes by x, so filtering the ledger by token 'MARG' (or the MARG address) lists all theses alongside genuine MARG calls, and a thesis about another token cannot be found by that token. The entry itself renders as 'Thesis' so nothing is misrepresented; this only weakens the token filter the brief asks for. A fix is to let the thesis author name the token the thesis is about (any address with code; x == imd is allowed for theses), or to exclude theses from token matching unless kind = theses.","line":63,"path":"web/src/pages/Post.tsx","reproduction":"With a thesis posted through #/post (Kind: Thesis), open #/ and type MARG in the Token filter with Kind = all. Expected: only notes about MARG. Actual: every thesis appears, because the site set its x to the MARG address at post time.","severity":"low","snippet":" x: contracts.marg,","title":"Theses are posted with x = MARG, so the Feed token filter 'MARG' returns every thesis"},{"citation":"resolved","description":"Read in full. The only script and stylesheet are relative paths into dist/assets; the icon is an inline data: SVG; OG/Twitter images point at ./share-card.png; meta description carries 'Informational and research purposes only. Not financial advice.' There is no external URL, iframe, redirect or inline script.","line":25,"path":"dist/index.html","reproduction":"grep -nE 'https?://' dist/index.html returns only the meta content strings (none are loaded resources); grep -c '","title":"dist/index.html loads only its own relative bundle and stylesheet; no remote script, iframe, analytics or font"},{"citation":"resolved","description":"The 580,704-byte bundle was rebuilt from the committed web/ tree with `npm ci` on the pinned package-lock (react 19.2.0, viem 2.57.4, vite 7.1.9) in a scratch copy; sha256 38bb1095a81a9e311dedc5abd434b08fbd759fb4b60a78ce12b2485a4f74953d matches the shipped file and dist/imd-deployment.json, as do the CSS and the ccip chunk. So the bundle contains exactly the source read for this review plus React, viem and ox. The only network calls in that source are: fetch of the relative imd-deployment.json (web/src/config.ts:99), JSON-RPC to the two public nodes from the manifest (this line), and the visitor's injected EIP-1193 wallet. URL inventory of the minified bundle: w3.org namespaces and react.dev/viem.sh/oxlib.sh/abitype.dev/docs.soliditylang.org/4byte.sourcify.dev strings inside React and viem error messages (never fetched); https://ipfs.io and https://arweave.net inside viem's ENS-avatar helper, which nothing in the app calls; https://x.com/marginalia_md and https://explorer.imd.fun/jobs/9060a248-29ce-4683-b5d1-54fbc83cd49d as footer links (both answer HTTP 200). The createElement(\"script\") and location.href occurrences are react-dom's resource and focus internals, not loaders. No eval, new Function, importScripts, WebSocket, sendBeacon or XMLHttpRequest.","line":68,"path":"web/src/chain.ts","reproduction":"cp -r web /tmp/x/web && cd /tmp/x/web && npm ci --ignore-scripts && npm run build && sha256sum ../dist/assets/* — compare with sha256sum dist/assets/* in the repository: all three hashes match. Then grep -oE 'https?://[A-Za-z0-9./_%:?=&#-]+' dist/assets/index-kf6RRY_t.js | sort -u to see the inventory above.","severity":"info","snippet":" transport: fallback(cfg.rpcUrls.map((u) => http(u, { batch: true, retryCount: 2 }))),","title":"dist/assets/index-kf6RRY_t.js is byte-identical to a clean rebuild of web/ and loads no remote code"},{"citation":"resolved","description":"The 2,888-byte chunk is viem's standard CCIP-Read (EIP-3668) module, split out by Vite because viem imports it dynamically from the call() path. It would fetch a gateway URL named by a contract revert, but the public client is created with ccipRead: false, so viem never takes that branch; the file contains no URL of its own and only imports from the main bundle.","line":67,"path":"web/src/chain.ts","reproduction":"head -c 400 dist/assets/ccip-CCWe3kRO.js shows `import{...}from\"./index-kf6RRY_t.js\"` and the OffchainLookupError classes; grep -c 'https\\?://' dist/assets/ccip-CCWe3kRO.js returns 0; web/src/chain.ts:67 disables ccipRead on the only public client.","severity":"info","snippet":" ccipRead: false,","title":"dist/assets/ccip-CCWe3kRO.js is viem's lazily imported OffchainLookup handler and is unreachable because ccipRead is disabled"},{"citation":"resolved","description":"dist/imd-deployment.json carries exactly the handoff's contracts (Marginalia 0xfa0efea559bde229031c2b0a219472316647759c, MarginaliaHook 0xf0457dd0cf526686190e4f057ba19db14d34a0cc), chain 1, the network block from network.json (IMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, RPCs ethereum-rpc.publicnode.com and eth.drpc.org, explorer etherscan.io). web/src/config.ts hard-codes no contract address; router, judge, treasury, imd, token and the pool key are read from the hook (web/src/chain.ts loadContracts), and the app refuses to start if hook.imd() or hook.token() disagree with the manifest. Live reads on 2026-10-12 (block 26173615) through ethereum-rpc.publicnode.com: hook.router() = 0xa3579D7c59A2C0c742fC4e5BB18AF93241D1d263, hook.judge() = 0xa9e1891d76553195B4Cbcd0F8Db290C8C0FA28B9 (both as the brief states), hook.imd() = IMD, hook.token() = MARG, getPoolKey() = (IMD, MARG, 12500, 60, hook). The only other addresses in the source are the venue finder's canonical Uniswap v3 factory 0x1F98431c8aD98523631AE4a59f267346ea31F984, v2 factory 0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f and WETH 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 (web/src/config.ts:26-28), which equal the router's live UNIV3_FACTORY/UNIV2_FACTORY/WETH constants; the finder disables itself if they ever differ.","line":16,"path":"dist/imd-deployment.json","reproduction":"cast call --rpc-url https://ethereum-rpc.publicnode.com 0xf0457dd0cf526686190e4f057ba19db14d34a0cc 'router()(address)' and 'judge()(address)'; cast call 0xa3579D7c59A2C0c742fC4e5BB18AF93241D1d263 'UNIV3_FACTORY()(address)' 'UNIV2_FACTORY()(address)' 'WETH()(address)'; grep -rnE '0x[0-9a-fA-F]{40}' web/src — only the three Uniswap constants appear.","severity":"info","snippet":" \"address\": \"0xf0457dd0cf526686190e4f057ba19db14d34a0cc\",","title":"Every contract address comes from imd-deployment.json or from the hook at runtime and matches the live chain"},{"citation":"resolved","description":"Transactions built anywhere in web/src: IMD.approve(router, imdIn) where imdIn = STAMP + MARG_BUY + bond and bond is validated inside BOND_MIN..BOND_MAX (Post.tsx:77-79, shown as 'Total … approved to the router only'); router.note(params, launchPoolKey, imdIn, minMargOut, deadline) with minMargOut = 0.25 IMD / hook.margPriceInImd() less 10% (the router's Slippage check compares the MARG received for the swap, which the hook limits to MARG_BUY, so the minimum covers only that leg); router.checkpointVenue(params, poolKey); hook.observe/settle/settleThesis(id); hook.claimDeposit/claimRefund(id); hook.sweep(kind, epoch). No permit, no signTypedData, no setApprovalForAll, no unlimited approval, no approval to the hook. Shipped ABIs dist/abi/*.json are identical (canonical JSON) to `forge build` output from this tree and to web/public/abi; web/src/abi.ts is typed `as const` so the TypeScript build (which passes) checks every function name and argument shape against them. Event signatures parsed in web/src/notes.ts (NotePosted, Settled, Observed, Retracted, Sealed, Revealed) match src/MarginaliaHook.sol:181-203 field for field; seals()/records()/noteOf() tuple indices used by the pages match the Seal, Record and NoteView struct orders.","line":110,"path":"web/src/pages/Post.tsx","reproduction":"grep -rn \"functionName: '\" web/src | grep -v readContract lists the write calls above; grep -rn 'maxUint256\\|signTypedData\\|permit\\|setApprovalForAll' web/src shows maxUint256 used only as a sentinel for a failed balance read in Note.tsx. forge build --offline then compare out/MarginaliaHook.sol/MarginaliaHook.json .abi with dist/abi/MarginaliaHook.json under sorted-key JSON: equal.","severity":"info","snippet":" const { request } = await pub.simulateContract({ address: contracts.imd, abi: erc20Abi, functionName: 'approve', args: [contracts.router, imdIn!], account: acct! });","title":"The only approval the site builds is IMD approve(router, stamp + MARG_BUY + bond) for the exact displayed total; every transaction matches the repository ABIs"},{"citation":"resolved","description":"The footer on every route shows x.com/marginalia_md, the explorer launch link, the hook and MARG addresses in full and the required disclaimer line, followed by 'A bonded feed, not a perp DEX and not a prediction market. Nothing pays for being right'. Feed, Post, About and Pools ledes repeat that a right call only gets its own bond back. Sides are labelled 'Upward call' / 'Downward call'; the 0.25 IMD leg is described as 'MARG purchase'; the word 'buy' appears in web/src only in a code comment (lib.ts:150). No giveaway, APY, profit or guarantee wording. dist/share-card.png is a 1200x630 paper-coloured card reading 'Notes and theses. A bonded record. Nothing pays for being right. Informational and research purposes only. @marginalia_md' with the manicule mark. web/src/styles.css uses the specified tokens (#f6f1e7/#1d1a16/#b9471f/#d9cfbd, dark #15130f/#ece5d6), Iowan Old Style/Palatino/Georgia serif, monospace only for .mono/addresses, 17px base, one column with a 44rem measure. The unrelated helper/ directory (a local x402 payment helper for api.imd.fun) is not part of dist/ and is not hosted.","line":225,"path":"web/src/ui.tsx","reproduction":"grep -niE '\\bbuy(s|ing)?\\b|guarantee|profit|airdrop|giveaway|apy' web/src/*.tsx web/src/pages/*.tsx web/index.html returns no visitor-facing string; open any route of dist/index.html and scroll to the footer.","severity":"info","snippet":"

Informational and research purposes only. Not financial advice. Bonds can be lost.

","title":"Copy, disclaimer, links and look match the brief; no returns promised, no 'buy' in visitor-facing text"}],"hash":"2645901dfa6702e5ee19506a314a02961a7ca7847a64b7ed477b44461b62a4c8","nodeId":"2bad0136-5594-493a-8be9-e70915872477","outcome":"completed","summary":"The review is complete. The findings file is written and validated, and the working tree holds no change other than that file.\n\n**Verdict: nothing critical or high. The site may be hosted.**\n\nWhat I verified, reading every file in the export and the source it was built from:\n\n- **Bundle provenance.** A clean rebuild of `web/` from the pinned lockfile reproduced all three asset files byte for byte, so the 580 KB minified bundle contains exactly the reviewed source plus React, viem and ox. No eval, remote script, iframe, analytics, WebSocket or beacon. The only network calls are the relative manifest fetch, JSON-RPC to the two public nodes from the manifest, and the visitor's injected wallet. CCIP reads are disabled.\n- **Addresses.** Hook and MARG come from the manifest and match the handoff. Router, judge, treasury, IMD and the pool key are read from the hook at runtime, and live reads today returned the router and judge the brief names. The venue finder's Uniswap factory and WETH constants are canonical and are cross-checked against the live router.\n- **Approvals and transactions.** The single approval is an exact-amount IMD approve to the router for stamp + MARG purchase + bond, shown as the total. No permit, typed-data signature or unlimited approval. Shipped ABIs equal the forge build output, and every event and tuple layout the pages decode matches the hook source.\n- **Copy and look.** Disclaimer line, canonical links and full addresses are in the footer on every route. No visitor-facing \"buy\" or returns language. Design tokens, serif body, manicule mark and one-column layout match the brief.\n\nFindings recorded in `.imd-findings.json`:\n\n- **Medium.** The Seal flow never calls hook.seal. The button is hard-disabled because the hook pulls its stamp by transferFrom, which needs an IMD allowance to the hook, and the brief's own review rule allows approvals only to the router. The page explains this honestly. The requester must choose between the two rules.\n- **Low.** Theses are posted with the MARG address as their token, so filtering the feed by MARG returns every thesis.\n- **Six info entries** documenting each hosted file, what it does, and the evidence above, so the hosting decision has a per-file record.","treeHash":null,"usage":{"cachedInputTokens":2075407,"inputTokens":610,"model":"claude-fable-5-1","outputTokens":31077,"runtime":"claude","turns":34,"wallClockMs":798994}},{"artifacts":[],"attempt":1,"bundleHash":"9d3459bc16801debb311e6b7397702e3d21fdfc32f1435a80c0caff2430ea5ab","device":"ddeff5e2c1df0f4a","findings":[],"hash":"2b1de66079fc84d9995cb43218ecad4a247e59e64dbda583959675bb48db0e82","nodeId":"9d6d2b49-9f21-43a1-96bd-e6347cb0561b","outcome":"completed","summary":"Addressed all 23 findings and rebuilt `dist/`.\n\nBuild, typecheck, 9 unit scenarios, 19 browser scenarios, and manifest checks passed. Submission: 4.73 MB.\n\nNew sealing remains disabled under the router-only approval rule. Missing archive history is explicitly flagged.\n\nResults are documented in `web/VALIDATION.md`; finding responses are in `.imd-responses.json`.","treeHash":"4e89b639bfca56af7fb00924caca10f32fdb06df","usage":{"cachedInputTokens":6547072,"inputTokens":198226,"model":"gpt-6-astra","outputTokens":57955,"runtime":"codex","turns":9,"wallClockMs":1715948}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"7ffab1989aa9150f","findings":[{"citation":"resolved","description":"Now: sendApprove authorizes contracts.hook for STAMP, and the Seal page offers 'Approve 0.1 IMD to the hook'. This is an explicit exception implemented by the builder, not a router approval.\nChange to: Remove the hook approval action and gate sealing with a clear unavailable explanation until the requester resolves the conflict between the router-only policy and the immutable hook.seal implementation. Do not host this build with the non-router approval enabled.\nWhy: The review brief explicitly requires approvals to target ONLY the router and makes any approval finding critical. MarginaliaHook._fund does need a hook allowance, so simply substituting the router would not implement a working seal.","line":38,"path":"web/src/pages/Seal.tsx","reproduction":"At 390px (also any width), open #/seal with an injected wallet on chain 1 whose IMD allowance to 0xf0457dd0cf526686190e4f057ba19db14d34a0cc is zero. The page displays 'Approve 0.1 IMD to the hook'. Clicking it builds ERC20 approve(hook, 100000000000000000) on IMD, as the exact simulation arguments at line 38 show; the required spender is router 0xa3579D7c59A2C0c742fC4e5BB18AF93241D1d263. This can be inspected with a mock wallet without broadcasting. Source corroboration: src/MarginaliaHook.sol:785-787 pulls from msg.sender, and seal calls _fund(STAMP); the requirements conflict is real, not an ABI mismatch.","severity":"critical","snippet":" const { request } = await pub.simulateContract({ address: contracts.imd, abi: erc20Abi, functionName: 'approve', args: [contracts.hook, L.stamp], account: acct! });","title":"fidelity: sealing requests an IMD approval to the hook despite the router-only hosting rule"},{"citation":"resolved","description":"Now: The bond field accepts 18-decimal IMD amounts, but fmtAmount truncates the total and approval label to four decimals. The transaction still approves the full imdIn, so the shown approval amount is not the amount authorized.\nChange to: Render the exact formatUnits(imdIn, 18) value in the total, approval label and transaction explanation; use full precision for the chosen bond as well. Alternatively reject extra precision before enabling approval, with an explicit validation message.\nWhy: The review requires approvals 'only for the amount shown' and explicitly makes approval findings critical. A financial authorization must never silently truncate its amount.","line":271,"path":"web/src/pages/Post.tsx","reproduction":"At 390px, connect an injected chain-1 wallet with zero router allowance (a mock wallet that refuses signing suffices). On #/post choose Thesis, enter 'A review-only thesis, never sent.', and set Bond to 0.25009. Total and the action display 0.6 IMD. Click 'Approve 0.6 IMD to the router' and inspect the unsigned eth_sendTransaction: to=0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7, approve(spender=0xa3579D7c59A2C0c742fC4e5BB18AF93241D1d263, value=600090000000000000), i.e. 0.60009 IMD. Expected the page to show 0.60009 before authorization. Reproduced in Chromium against live read RPC; nothing broadcast. fmtAmount in web/src/lib.ts:169-174 uses f.slice(0, digits), digits=4.","severity":"critical","snippet":" label={`Approve ${imdIn ? fmtAmount(imdIn) : ''} IMD to the router`}","title":"bug: router approvals exceed the amount displayed for bonds with more than four decimal places"},{"citation":"resolved","description":"Now: Percentage validation checks the input minimum and SELL <100, then rounds pct*100 without validating the resulting uint32 targetBps. SELL 99.999 becomes targetBps=0 (a thesis); a sufficiently large BUY target throws from sealHash during render and blanks the site.\nChange to: Reject non-finite or over-precision percentages, and validate the final encoded target: upward 11000..4294967295, downward 1..9000. Show an inline field error before returning params or computing a seal hash. Keep a priced call's target nonzero and its UI consistent with the encoded value.\nWhy: The requested call must remain a priced call; targetBps=0 has a different on-chain meaning and a seven-day thesis obligation. Invalid input must not destroy the layout or the draft.","line":169,"path":"web/src/form.tsx","reproduction":"Two reproductions at 390px in Chromium, using MARG's launch venue, a 30-day horizon and nonempty text. (1) On #/post select SELL and enter Target move=99.999. With a fixture providing a mature checkpoint, adequate IMD/allowance and successful note simulation, 'Post the call' is enabled. The unsigned router.note request contains side=1,targetBps=0,horizonDays=30. Expected field rejection; src/MarginaliaHook.sol:410 treats targetBps==0 as a thesis. (2) On #/seal with a connected chain-1 mock wallet, select the upward side and enter 42949573. document.body.innerText becomes empty and the console throws: Number \"4294967300\" is not in safe 32-bit unsigned integer range (0 to 4294967295), viem@2.57.4. Expected a visible form with a range error and disabled sealing. The second case used live read RPC; neither case signed or broadcast a transaction.","severity":"high","snippet":" const bps = Math.round(pct * 100);\n params = {\n x: draft.x.trim() as Address,\n venue: derived.venue,\n side: draft.side,\n targetBps: draft.side === Side.Buy ? 10000 + bps : 10000 - bps,\n horizonDays: h,","title":"bug: unchecked target rounding turns calls into theses and can crash sealing"},{"citation":"resolved","description":"Now: The seal flow goes directly from a valid call to approval and hook.seal. It never reads priceWindows, starts a checkpoint, or explains the prerequisite one-hour wait, although hook.seal calls router.postPrice twice.\nChange to: Reuse the existing Post checkpoint controls before the seal action, read the derived venue's priceWindows state, show the one-hour countdown and six-hour expiry, and disable Seal unless that window is mature. Explain 'Checkpoint this venue, then wait one hour before sealing.'\nWhy: The requested seal flow must work against the live contracts. A missing or expired checkpoint makes the proposed seal revert; this is a missing functional prerequisite, not a missing wallet signature.","line":41,"path":"web/src/pages/Seal.tsx","reproduction":"At 390px open #/seal, use a chain-1 injected wallet, paste MARG 0xfa0efea559bde229031c2b0a219472316647759c, select the launch venue, and fill a 20% upward, 30-day call with 'A review call with a target.'. The page offers approval/sealing but contains no checkpoint action or countdown. During the live review, router.priceWindows(keccak256(abi.encode({kind:1,ref:0x436763bf49aa9ea6db1d8d4d80ac8c7b3c36ad58fa6281a06ea39c92d69e2f20,quote:IMD,xIsToken0:false}))) returned seven zeroes. A read-only eth_call of hook.seal with that venue reverts 0xc3651e6d (PriceHistoryUnavailable) before it pulls the stamp. src/MarginaliaPricer.sol:140-144 requires an existing 1h–6h checkpoint; allowance cannot fix this.","severity":"high","snippet":" const sendSeal = async () => {\n const p = derived.params!;\n const { request } = await pub.simulateContract({ address: contracts.hook, abi: MarginaliaHookAbi, functionName: 'seal', args: [p.x, p.venue, hash!], account: acct! });\n return wallet.client!.writeContract(request);\n };","title":"bug: sealing omits the checkpoint required by the live hook"},{"citation":"resolved","description":"Now: readyToPost requires windowState === 'ready' for every call, including a prefetched sealed reveal. A valid seal already contains its baseline and does not require the original checkpoint still to be young.\nChange to: Read and validate the connected author's matching on-chain seal (hash, subject, age and unconsumed state). Permit posting during its 30-minute–6-hour reveal window without the ordinary checkpoint-age gate; retain the checkpoint gate for unsealed calls and show the actual seal countdown.\nWhy: The brief requires revealing the same parameters throughout the seal's stated window. The current extra one-hour wait can block a reveal until the seal lapses and wastes the already-paid stamp.","line":139,"path":"web/src/pages/Post.tsx","reproduction":"At 390px use a controlled RPC fixture with the launch checkpoint started at t−9h and a matching author Sealed event at t−4h (the checkpoint was valid, 5h old, when sealed). Keep account 0x1111111111111111111111111111111111111111 on chain 1 with 100 IMD balance/allowance; save the matching 20%, 30-day MARG draft in marginalia.seals. On #/seal, 'reveal open' shows nearly two hours left. Click 'Reveal: open the post form with these parameters'. Actual: #/post says 'The last checkpoint is older than 6 hours. Checkpoint again and wait one hour.' and 'Post the call' is disabled. Expected it enabled for the matching live seal. Source evidence: src/MarginaliaHook.sol:465-478 takes s.baseBuy/s.baseSell for a bound seal aged <=SEAL_MAX and calls router.postPrice only in the unsealed/lapsed branch. Reproduced in Chromium without broadcasting.","severity":"high","snippet":" const readyToPost = !!params && bondOk && imdIn !== null && !needsApproval && enoughImd && (mode === 'thesis' || windowState === 'ready') && minMargOut > 0n;","title":"bug: an expired checkpoint disables valid sealed-note reveals"},{"citation":"resolved","description":"Now: Pools only loads today, yesterday and the day before, then looks for one of those days to be 28 days past its end. That condition cannot be satisfied. No weekly sweep control exists either; the page directs visitors to call sweep manually outside the site.\nChange to: Let the existing Pools surface read/select eligible older day and closed-week epochs, show their balances and actual sweep eligibility, and expose the existing simulated sweep(kind, epoch) action for eligible pools. Retain the 28-day and judge-closure checks.\nWhy: The brief explicitly includes sweep on the Pools page. The action branch is unreachable for every normally synchronized chain and browser clock.","line":33,"path":"web/src/pages/Pools.tsx","reproduction":"At 390px, connect on chain 1 and open #/pools. For today=20738, the only queried days are [20738,20737,20736]. SWEEP_AFTER from the live hook is 2419200 seconds; even the oldest queried day's end is less than two days ago. All three eligibility checks are false, regardless of their nonzero balances. In a controlled fixture returning 100 IMD for refundPool(day), the only main-page button is 'Refresh from chain'; no sweep is offered. The code never queries day 20709 or any other 28-day-old epoch, and never calls sendSweep with kind 1. Expected a usable action for an eligible older epoch, rather than the permanent instruction to use a wallet directly.","severity":"high","snippet":" const sweepableDay = s ? s.days.find((d, i) => s.refunds[i] > 0n && now >= (d + 1) * 86400 + contracts.limits.sweepAfter) : undefined;","title":"fidelity: the sweep control can never become available"},{"citation":"resolved","description":"Now: Your claims renders counts and ordinary feed entries with 'Open a note to claim'; Pools has no claimDeposit or claimRefund action. Its refundable list also ignores refundClaimed and counts previously claimed notes as available.\nChange to: Reuse the existing note-page claim controls beside each eligible pool entry, read refundClaimed plus the day's remaining share before including a refund, and refresh eligibility after confirmation. Keep the note-detail links for inspection.\nWhy: The brief explicitly asks for claimDeposit/claimRefund buttons for the connected author on the Pools page. Counts that include already-paid refunds further misstate what can be claimed.","line":132,"path":"web/src/pages/Pools.tsx","reproduction":"At 390px, connect account 0x1111111111111111111111111111111111111111 on chain 1. Supply a Right note by that author with deposit=250000000000000000 from yesterday and refundClaimed=false; open #/pools. The entry is listed but no 'Claim deposit' or 'Claim refund' button exists in main; only 'Refresh from chain' does. In a second fixture with two past-day Right notes, deposit=0 and refundClaimed=true for both, Pools says 'refunds are available for 2 of your notes'. Opening either note correctly says 'Already claimed.' Expected direct eligible claim actions and no paid notes counted as refundable. The button absence is also established by the complete JSX in this source file.","severity":"high","snippet":"

\n Deposits ({claimable.length}) are claimed per note; refunds are available for {refundable.length} of your notes from past days, subject to the\n pool of that day. Open a note to claim.\n

\n