{"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":"108553eb-1d21-412d-92dc-f03b40cf805d","kind":"skill:research-report","nodes":[{"acceptedSubmissionHash":"da68328076ef4f9121876e0efc3d5a2c53c716502ee12c05a966c733d54e786c","dependsOn":[],"execution":{"network":true,"profile":"none","requires":["network"],"skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","tools":[]},"key":"research_report","kind":"code","role":"implement","skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","state":"accepted"}],"objective":"Design a governance proposal guard: every proposal to a DAO's governor automatically gets an independent review of its calldata by the swarm, and execution is blocked if a swarm panel attests the review found a critical problem.\n\nWHY. Governance is an exploit surface. Tornado Cash's governance was taken over in May 2023 by a proposal whose contract hid a selfdestruct-and-redeploy path; Beanstalk lost about 182M USD in 2022 to a flash-loaned vote; Compound's proposal 62 distributed COMP wrongly in 2021, and proposal 289 in 2024 moved treasury funds against many holders' wishes. Most voters never read calldata. A review per proposal costs about 1 IMD (a job plus an oracle answer), which is trivial against a treasury.\n\nHOW THE SWARM ORACLE WORKS, so the design is not generic. An `oracle.request` costs 0.5 IMD (about 4.25 USD) and is answered in minutes, not blocks. A panel of agents answers; a service key (0x5598aa9146215bc13eb26f2c692ad1461fd32982) signs an EIP-712 attestation, domain name \"IdentityMD Oracle\", version \"2\", with chainId and verifyingContract chosen by the requester as `consumer`. Struct: requestId, chainId, questionHash, answerType, answer, figure (uint256), fromBlock, toBlock, blockHash, panelJobId, panelSize, quorum, agreed, issuedAt, expiresAt. Because `agreed` is signed, a consumer enforces its own floor on chain, BUT on live attestations `agreed` equals `quorum` (one signed 60/20/20): the service signs once quorum agrees, so enforce absolute minimum counts (panelSize >= M, agreed >= N), never an agreement ratio, which only forces a higher quorum and gets the request refused. A chain-evidence answer must come from a re-runnable recipe the signer re-executes, and only these exist: log-sum, log-count, univ4-spot {poolManager, poolId, invert?, samples odd 1-61} (all uint256); call-compare (bool, one view call at the closing block against a threshold); log-rank and v4-volume-rank (address[] or bytes32[]). Anything else is `panel` evidence: voted, not re-run. A panel once returned a price wrong by 256x by majority, so panel evidence is weaker and must be treated so. `questionHash` is keccak over the canonical question document {v, question, chainId, window, answerType, head?, definitions?, evidence?} with sorted keys, INCLUDING its block window and evidence class; task detail belongs inside `question` and `definitions`, never in invented fields; a consumer must check it, because the requester names the consumer and anyone can buy a signed answer to a different question addressed to your contract. A recurring consumer pins the document prefix and splices in the signed fromBlock/toBlock, and must also require toBlock to advance. Only oracle answers are signed for consumers: a job's delivery carries no signature a contract can check and does not prove which agent did it. The data chain and the consumer chain may differ (mainnet data attested to a contract elsewhere). Contract launches currently deploy on Sepolia only; IMD and the ERC-8004 registries are on mainnet. `schedule.create` buys recurring requests at 0.5 IMD per run, oracle questions no more often than every 10 minutes, jobs every 30.\n\nANSWER, each separately:\n1. Integration point, compared: an OpenZeppelin Governor extension that refuses `execute` without a clean attestation; a guardian role on the timelock that can only CANCEL and only on an attested critical finding; or a Safe guard. Recommend one, and design it to work with OpenZeppelin Governor and Compound Governor Bravo without forking them.\n2. The review: what the job must examine (decoded calldata, every target's verified source and whether it is a proxy, simulation of the state diff including treasury balances and approvals, code deployed in the same block as the proposal) and what a finding must contain. The skills available are `research-report` and `audit-imported-code`; say which fits.\n3. The attested question: a bool from a panel on whether the review at a given content hash reports a critical finding, pinned to the proposal id so an answer about another proposal cannot be used. Panel size and agreed count to require.\n4. Timing: reviews take minutes to hours; voting periods and timelocks take days. Where in the proposal lifecycle the request is bought, by whom, and what happens if no answer arrives before execution: fail-closed delays a legitimate proposal, fail-open lets a malicious one through. Pick, with reasoning.\n5. Abuse: false positives used to censor proposals, an attacker paying for reviews of their own bad proposal hoping for a lucky clean answer, and a proposal written to fool an LLM reviewer (prompt injection in descriptions or code comments). Give a mitigation for each.\n6. What existing governance safety tools do (Tally, OpenZeppelin Defender, Tenderly simulations, Aave's and Compound's guardians, Seatbelt-style simulation reports) and the gap this fills; cite.\n\nTHE CONTRACTS SECTION will be built by a launch that deploys AT MOST FOUR contracts and makes NO calls after deployment, so every link is made in a constructor (a parent may create its children) and every privileged address is a constant in source, never a constructor argument or placeholder. For each contract give: purpose, constructor, storage, external functions with access rules, events, and the invariants a test must hold. Solidity interfaces, not full implementations. Then a Foundry test plan naming each test, including the adversarial ones.\n\nPERIOD: current as of the report date; comparator figures should come from live parameters or from the last 24 months, with the date each was read.\n\nFORMAT: one Markdown spec of roughly 3,000 to 6,000 words, in this order: (1) a one-paragraph recommendation stating the design in plain terms; (2) a decisions table, one row per numbered question above, with the choice, the figure, and the main reason; (3) the answer to each numbered question in its own section; (4) the contracts; (5) the test plan; (6) the risks ranked by severity; (7) open questions that need the IdentityMD developer, each phrased so it can be asked as is. Use tables wherever a comparison has more than two items.\n\nMark every statement about the IdentityMD plane you could not verify yourself as an ASSUMPTION. Cite at least six distinct sources, each a page that states what it is cited for. No marketing pages.","parentJobId":null,"planHash":"024de6bd01c1e0ef988b85d26874533f0bcd2c6de815195fd3a1e70b4516a72a","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"108553eb-1d21-412d-92dc-f03b40cf805d","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":"51026","feedbackHash":"c38f40b2a8378dbb21bff9f7df8af32c45e837b528eb3c9865be565448e4a447","nodeKey":"research_report","submissionHash":"da68328076ef4f9121876e0efc3d5a2c53c716502ee12c05a966c733d54e786c","tag1":"verification:structural","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"8bfde624aeafe9511ca8b17a40a8f68ddfcea33f2cd0bbf2940eb4b59655f4a1","state":"completed","submissions":[{"artifacts":[{"bytes":43257,"hash":"f63790abdd9258dc0d778ff913281278be9216fa5e45642ae7cd04b61f27bedc","mediaType":"text/markdown","name":"spec","path":"artifacts/spec.md"}],"attempt":1,"bundleHash":null,"device":"56b13350bba65fd7","findings":[],"hash":"da68328076ef4f9121876e0efc3d5a2c53c716502ee12c05a966c733d54e786c","nodeId":"22344da1-e910-44a1-b99f-3a6fc9daf1ab","outcome":"completed","summary":"Done. The deliverable is written and verified.\n\n**What was delivered** — `artifacts/spec.md` (5,556 words, markdown, untracked as required) plus a short `artifacts/README.md` describing the question and limits. The spec designs the governance proposal guard as a **cancel-only attested guardian**: every proposal triggers a DAO-funded `audit-imported-code` review (decoded calldata, target/proxy verification, metamorphic same-block checks, forked-state simulation), a 20-agent swarm panel attests one bool question pinned to `(governor, chainId, proposalId, reportHash)`, and a small immutable contract verifies the EIP-712 attestation from the service key and cancels the proposal only on a confirmed critical — via `CANCELLER_ROLE` on OZ's TimelockController and via the `proposalGuardian` role Compound's own GovernorBravoDelegate gained after proposal 289, so neither governor is forked.\n\n**Key design calls, with the reasoning in the spec:**\n- **Fail-open at the contract layer.** Cancel-only power means a missing attestation changes nothing; fail-closed would make one service key able to halt all governance — a worse takeover surface than the one being fixed. The ≥7-day Compound lifecycle vs. minutes-scale reviews leaves ample margin.\n- **Clean answers are inert by construction**, which structurally kills the \"attacker re-rolls reviews for a lucky clean answer\" abuse: only `answer == true` has on-chain effect, and one true answer from any requester dominates any number of bought clean ones.\n- **Absolute panel floors (`panelSize >= 20 && agreed >= 15`)**, never a ratio, per the brief's warning; honest treatment of the question as weaker *panel* evidence since no re-runnable recipe can express \"report contains a critical finding\".\n- Contracts section fits the launch profile (3 of 4 slots used, constructor-only wiring, service key and governor/timelock addresses as source constants), with ~35 named Foundry tests including the adversarial replay/ratio/censorship cases, 8 ranked risks, and 7 open questions phrased to ask the IdentityMD developer as-is (the blocking ones: the exact EIP-712 type string and a live canonical question-document test vector).\n\nStructural checks passed: section order matches the required format, 14 distinct non-marketing sources each cited for what they state (read 2026-10-05), 5 ASSUMPTION markers distinguish unverified IdentityMD-plane claims, and both files are untracked with nothing staged in git.","treeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","usage":{"cachedInputTokens":1301117,"inputTokens":34,"model":"claude-fable-5","outputTokens":41780,"runtime":"claude","turns":27,"wallClockMs":759366}}],"verification":[{"checks":[],"detail":"paths and tree verified; no suite was run for this kind of work","evaluation":"structural","profile":"none","status":"accepted","submissionHash":"da68328076ef4f9121876e0efc3d5a2c53c716502ee12c05a966c733d54e786c","verifiedTreeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","verifierVersion":"0.1.0+8680b67f"}]}