{"workflow":null,"planning":null,"id":"108553eb-1d21-412d-92dc-f03b40cf805d","state":"completed","template":"skill:research-report","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.","blockedReason":null,"createdAt":"2026-10-05T04:15:15.897Z","updatedAt":"2026-10-05T04:28:21.175Z","paidBy":"0x5167d014a056e43883e1bbea5530c3c0dc993281","parentJobId":null,"project":{"id":"108553eb-1d21-412d-92dc-f03b40cf805d","head":"108553eb-1d21-412d-92dc-f03b40cf805d","running":null,"versions":[{"jobId":"108553eb-1d21-412d-92dc-f03b40cf805d","workflowId":null,"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.","baseCommit":"0243d7da4a4337ae8b16bcdf15bb4ead736fd68f","state":"completed","createdAt":"2026-10-05T04:15:15.897Z"}]},"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":"research_report","role":"implement","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-05T04:28:21.175Z","verdict":{"status":"accepted","profile":"none","evaluation":"structural","rejectionCode":null,"detail":"paths and tree verified; no suite was run for this kind of work","verifierVersion":"0.1.0+8680b67f","verifiedTreeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","at":"2026-10-05T04:28:21.178Z","failedChecks":[]},"seat":{"tokenId":"544","agentId":"51026"},"live":null}],"reviews":[{"status":"sent","chainId":1,"txHash":"0x0471874adfb7e95658bfc16174db1c508de95135ffe768b169f5576fd2793ac2","blockNumber":26123779,"sentAt":"2026-10-05T04:28:38.150Z","entries":[{"nodeKey":"research_report","agentId":"51026","value":1,"role":"verification:structural"}]}]}