{"workflow":null,"planning":null,"id":"6321056b-a125-48f2-9c7a-81cc8695a1f2","state":"completed","template":"shape:chain","objective":"[06-Oct-26 11:56 PM] Ito Hermes in reply to Jet (🤹🏻‍♀️,👻):\n> ‎⁨make it half this amout of charrcters⁩\nIMD Ecosystem Index — Build Request\n\nI want to commission an IMD-native Ethereum ecosystem index funded by project-token trading fees.\n\nA Uniswap v4 hook collects fees from the project-token pool. A defined portion goes into a treasury reserve. Once per day, the IMD swarm researches Ethereum ecosystem tokens and proposes a top-five basket. Deterministic on-chain rules decide which assets are eligible.\n\nThe swarm should research, rank, and stress-test assets, but must not have unrestricted trading authority. This should be an auditable index with an AI research layer, not a black-box AI trading bot.\n\nCore loop\n\nProject-token swaps → v4 fee hook → fee waterfall → treasury reserve → daily market snapshot → swarm research → risk filters → signed proposal → delay → protected execution → top-five basket.\n\nV1 scope\n\n- Ethereum ecosystem assets only.\n- Maximum five basket assets.\n- Initial weighting: 20% per asset, subject to caps and liquidity.\n- Ethereum mainnet for the project pool and index identity.\n- Daily research and ranking, but weekly execution initially.\n- Rebalance only when membership or weights cross thresholds.\n- Use rank buffers to prevent constant turnover.\n- Use CoW Swap or another MEV-resistant batch route where possible.\n\nFee waterfall\n\n- 40% to basket reserve.\n- 25% to liquidity providers.\n- 20% to swarm/operator reserve.\n- 10% to protocol reserve and operating costs.\n- 5% to token utility reserve until utility is defined.\n\nThese percentages are starting parameters. They must be visible on-chain and controlled by timelocked configuration. The basket reserve should accumulate in ETH or USDC before execution.\n\nEligibility and ranking\n\nA token must have an approved Ethereum address, be at least 30 days old, meet minimum market cap/volume/liquidity requirements, have a fresh price oracle, and pass contract, holder-concentration, upgrade, and security checks.\n\nExclude tokens with stale data, unverifiable supply, suspicious volume, inadequate liquidity, failed trade simulation, honeypot behavior, or unresolved critical incidents.\n\nInitial ranking:\n\n- 50% circulating market cap\n- 20% liquidity and volume quality\n- 15% 30-day momentum\n- 10% ecosystem usage, fees, or revenue\n- 5% swarm research score\n\nThe swarm score cannot override a hard exclusion. Publish the data sources, snapshot time, supply methodology, formula, caps, buffers, and stale-data rules.\n\nSwarm workflow\n\nThe swarm produces a signed daily report with the ranked tokens, proposed weights, addition/removal reasoning, contract-risk findings, liquidity warnings, unlock and insider analysis, ecosystem activity, confidence, sources, and dissenting opinions.\n\n1. One agent ranks candidates.\n2. Other agents attack the ranking and search for manipulation or risk.\n3. A verifier checks the evidence.\n4. An orchestrator signs the proposal.\n5. The executor validates it against the hard rules.\n\nAgents should be rewarded for verified research and risk detection, not merely bullish calls.\n\nProposal and execution\n\nEach basket state has an epoch. A signed proposal includes the epoch, snapshot time, token addresses, target weights, methodology version, data hash, expiry, and signer/quorum information.\n\nReject expired, stale, replayed, malformed, over-weighted, or non-allowlisted proposals. Reject stale price feeds and trades that fail minimum-output limits. Use a short delay between publication and execution.\n\nUse a separate vault and rebalance executor. Do not perform the full portfolio rebalance inside the swap hook. The executor should trade only the delta between old and new targets, preserve an ETH/USDC buffer, enforce slippage limits, and quarantine failed assets rather than bricking the basket.\n\nThe vault should provide deposits, redemptions, ERC-20 index shares, transparent NAV, published holdings, emergency pause, and safe redemption if the swarm or keeper is offline.\n\nUniswap v4 hook scope\n\nThe primary hook should:\n[06-Oct-26 11:56 PM] Ito Hermes in reply to Jet (🤹🏻‍♀️,👻):\n> ‎⁨make it half this amout of charrcters⁩\n- collect the project-token swap fee;\n- split it according to the fee waterfall;\n- record the basket-reserve amount;\n- emit indexed fee events;\n- avoid trading the basket inline.\n\nA secondary epoch hook may store the active basket/proposal hash, reject stale updates, enforce approved tokens and executors, prevent replay, and apply bounded dynamic fees when the basket is stale or volatile.\n\nSecurity and delivery\n\nSeparate the FeeHook, ProposalSigner/quorum, Executor, Guardian, and TimelockedAdmin roles. No single wallet should control every function.\n\nBefore real funds, require Foundry tests, mainnet-fork tests, fuzzing, solvency and fee-accounting invariants, v4 callback/reentrancy tests, stale-oracle and failed-execution tests, MEV/slippage simulations, an independent audit, and a capped beta.\n\nProposal requested\n\nPlease provide a milestone-based proposal covering the fee hook, fee waterfall, basket methodology, swarm workflow, signed proposals, vault, executor, protected execution, frontend, testing, audit scope, gas assumptions, timeline, ownership/IP, repository handoff, named lead agent, human technical owner, and post-launch support.\n\nFinal product: Fee-to-Basket Hook + Swarm Research + Rules-Based Top-Five Vault. Do not build an unrestricted AI trading bot.\n\nToken name: IMD Index\nToken symbol: IMDEX","blockedReason":null,"createdAt":"2026-10-06T16:00:46.088Z","updatedAt":"2026-10-06T18:44:02.939Z","paidBy":"0x568fe872c046cf79d713323c290e33f9906b8590","parentJobId":null,"project":{"id":"6321056b-a125-48f2-9c7a-81cc8695a1f2","head":"8a5d5e50-f972-4a86-ab69-1442ed0cc957","running":null,"versions":[{"jobId":"6321056b-a125-48f2-9c7a-81cc8695a1f2","workflowId":null,"objective":"[06-Oct-26 11:56 PM] Ito Hermes in reply to Jet (🤹🏻‍♀️,👻):\n> ‎⁨make it half this amout of charrcters⁩\nIMD Ecosystem Index — Build Request\n\nI want to commission an IMD-native Ethereum ecosystem index funded by project-token trading fees.\n\nA Uniswap v4 hook collects fees from the project-token pool. A defined portion goes into a treasury reserve. Once per day, the IMD swarm researches Ethereum ecosystem tokens and proposes a top-five basket. Deterministic on-chain rules decide which assets are eligible.\n\nThe swarm should research, rank, and stress-test assets, but must not have unrestricted trading authority. This should be an auditable index with an AI research layer, not a black-box AI trading bot.\n\nCore loop\n\nProject-token swaps → v4 fee hook → fee waterfall → treasury reserve → daily market snapshot → swarm research → risk filters → signed proposal → delay → protected execution → top-five basket.\n\nV1 scope\n\n- Ethereum ecosystem assets only.\n- Maximum five basket assets.\n- Initial weighting: 20% per asset, subject to caps and liquidity.\n- Ethereum mainnet for the project pool and index identity.\n- Daily research and ranking, but weekly execution initially.\n- Rebalance only when membership or weights cross thresholds.\n- Use rank buffers to prevent constant turnover.\n- Use CoW Swap or another MEV-resistant batch route where possible.\n\nFee waterfall\n\n- 40% to basket reserve.\n- 25% to liquidity providers.\n- 20% to swarm/operator reserve.\n- 10% to protocol reserve and operating costs.\n- 5% to token utility reserve until utility is defined.\n\nThese percentages are starting parameters. They must be visible on-chain and controlled by timelocked configuration. The basket reserve should accumulate in ETH or USDC before execution.\n\nEligibility and ranking\n\nA token must have an approved Ethereum address, be at least 30 days old, meet minimum market cap/volume/liquidity requirements, have a fresh price oracle, and pass contract, holder-concentration, upgrade, and security checks.\n\nExclude tokens with stale data, unverifiable supply, suspicious volume, inadequate liquidity, failed trade simulation, honeypot behavior, or unresolved critical incidents.\n\nInitial ranking:\n\n- 50% circulating market cap\n- 20% liquidity and volume quality\n- 15% 30-day momentum\n- 10% ecosystem usage, fees, or revenue\n- 5% swarm research score\n\nThe swarm score cannot override a hard exclusion. Publish the data sources, snapshot time, supply methodology, formula, caps, buffers, and stale-data rules.\n\nSwarm workflow\n\nThe swarm produces a signed daily report with the ranked tokens, proposed weights, addition/removal reasoning, contract-risk findings, liquidity warnings, unlock and insider analysis, ecosystem activity, confidence, sources, and dissenting opinions.\n\n1. One agent ranks candidates.\n2. Other agents attack the ranking and search for manipulation or risk.\n3. A verifier checks the evidence.\n4. An orchestrator signs the proposal.\n5. The executor validates it against the hard rules.\n\nAgents should be rewarded for verified research and risk detection, not merely bullish calls.\n\nProposal and execution\n\nEach basket state has an epoch. A signed proposal includes the epoch, snapshot time, token addresses, target weights, methodology version, data hash, expiry, and signer/quorum information.\n\nReject expired, stale, replayed, malformed, over-weighted, or non-allowlisted proposals. Reject stale price feeds and trades that fail minimum-output limits. Use a short delay between publication and execution.\n\nUse a separate vault and rebalance executor. Do not perform the full portfolio rebalance inside the swap hook. The executor should trade only the delta between old and new targets, preserve an ETH/USDC buffer, enforce slippage limits, and quarantine failed assets rather than bricking the basket.\n\nThe vault should provide deposits, redemptions, ERC-20 index shares, transparent NAV, published holdings, emergency pause, and safe redemption if the swarm or keeper is offline.\n\nUniswap v4 hook scope\n\nThe primary hook should:\n[06-Oct-26 11:56 PM] Ito Hermes in reply to Jet (🤹🏻‍♀️,👻):\n> ‎⁨make it half this amout of charrcters⁩\n- collect the project-token swap fee;\n- split it according to the fee waterfall;\n- record the basket-reserve amount;\n- emit indexed fee events;\n- avoid trading the basket inline.\n\nA secondary epoch hook may store the active basket/proposal hash, reject stale updates, enforce approved tokens and executors, prevent replay, and apply bounded dynamic fees when the basket is stale or volatile.\n\nSecurity and delivery\n\nSeparate the FeeHook, ProposalSigner/quorum, Executor, Guardian, and TimelockedAdmin roles. No single wallet should control every function.\n\nBefore real funds, require Foundry tests, mainnet-fork tests, fuzzing, solvency and fee-accounting invariants, v4 callback/reentrancy tests, stale-oracle and failed-execution tests, MEV/slippage simulations, an independent audit, and a capped beta.\n\nProposal requested\n\nPlease provide a milestone-based proposal covering the fee hook, fee waterfall, basket methodology, swarm workflow, signed proposals, vault, executor, protected execution, frontend, testing, audit scope, gas assumptions, timeline, ownership/IP, repository handoff, named lead agent, human technical owner, and post-launch support.\n\nFinal product: Fee-to-Basket Hook + Swarm Research + Rules-Based Top-Five Vault. Do not build an unrestricted AI trading bot.\n\nToken name: IMD Index\nToken symbol: IMDEX","baseCommit":"0243d7da4a4337ae8b16bcdf15bb4ead736fd68f","state":"completed","createdAt":"2026-10-06T16:00:46.088Z"},{"jobId":"8a5d5e50-f972-4a86-ab69-1442ed0cc957","workflowId":null,"objective":"Repair launch 816 for `https://github.com/identity-md-launches/launch-816-imd-index`.\n\nThe build was accepted, but Ethereum launch simulation is parked with:\n\n`DeploymentFailed(uint256 index) (6)`\n\nIndex 6 appears to be the seventh application contract, `FeeHookDeployer`.\n\nDiagnose the exact revert and fix the launch-specific deployment issue. First investigate whether `FeeHookDeployer`’s constructor calls to `FeeWaterfall.reserveAsset()` and `.weth()` are incompatible with the launch factory, or whether constructor arguments are resolving incorrectly.\n\nPreserve the existing security model. Do not remove meaningful validation or introduce privileged shortcuts.\n\nAcceptance:\n- launch simulation succeeds;\n- all seven application contracts deploy;\n- constructor arguments and contract references resolve correctly;\n- no roles are assigned automatically;\n- verifier/tests remain green;\n- deliver the repaired commit and explain the root cause and fix.","baseCommit":"6a78621b5bfe9513d9da5f6e7e4fcf6551f5040b","state":"completed","createdAt":"2026-10-07T00:31:52.605Z"}]},"deliver":true,"host":false,"site":null,"launch":{"requested":true,"kind":"evm_project","id":"7d580d07-ecc2-4d2d-a4be-c3f04cc762ca","status":"parked","chainId":1},"oracleRequestId":null,"delivery":{"repoUrl":"https://github.com/identity-md-launches/launch-816-imd-index","pullRequestUrl":"https://github.com/identity-md-launches/launch-816-imd-index/pull/1","commit":"6a78621b5bfe9513d9da5f6e7e4fcf6551f5040b","deliveredAt":"2026-10-06T18:44:38.612Z","media":null},"media":null,"nodes":[{"key":"audit_economics","role":"review","state":"accepted","attempt":2,"revisions":0,"judgeRevisions":0,"dependsOn":["build_contract_project"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T17:21:39.040Z","verdict":null,"seat":{"tokenId":"467","agentId":"52121"},"live":null},{"key":"audit_flow","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":["build_contract_project"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T17:08:17.636Z","verdict":null,"seat":{"tokenId":"452","agentId":"52120"},"live":null},{"key":"audit_judge","role":"review","state":"accepted","attempt":1,"revisions":1,"judgeRevisions":1,"dependsOn":["build_contract_project","write_foundry_tests","manifest","audit_math","audit_permissions","audit_economics","audit_flow"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T18:44:02.939Z","verdict":null,"seat":{"tokenId":"852","agentId":"52167"},"live":null},{"key":"audit_math","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":["build_contract_project"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T17:09:39.456Z","verdict":null,"seat":{"tokenId":"1905","agentId":"51538"},"live":null},{"key":"audit_permissions","role":"review","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":["build_contract_project"],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T17:06:33.433Z","verdict":null,"seat":{"tokenId":"874","agentId":"52128"},"live":null},{"key":"build_contract_project","role":"implement","state":"accepted","attempt":1,"revisions":1,"judgeRevisions":1,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T18:00:11.981Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+94826a22","verifiedTreeHash":"99b9c6beb0326a2f1361807c502c1d470e1e5420","at":"2026-10-06T18:00:12.193Z","failedChecks":[]},"seat":{"tokenId":"984","agentId":"51727"},"live":null},{"key":"manifest","role":"integrate","state":"accepted","attempt":1,"revisions":1,"judgeRevisions":1,"dependsOn":["build_contract_project"],"allowedPaths":["launch.json"],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T18:04:18.520Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+94826a22","verifiedTreeHash":"8ba13686af83ac63e6db21d3e51780398c13fbc2","at":"2026-10-06T18:04:18.882Z","failedChecks":[]},"seat":{"tokenId":"218","agentId":"51318"},"live":null},{"key":"write_foundry_tests","role":"tests","state":"accepted","attempt":2,"revisions":1,"judgeRevisions":1,"dependsOn":["build_contract_project"],"allowedPaths":["test","test/**"],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-06T18:36:40.182Z","verdict":{"status":"accepted","profile":"foundry","evaluation":"checks","rejectionCode":null,"detail":"all checks passed","verifierVersion":"0.1.0+94826a22","verifiedTreeHash":"22ba9f64090f691bd9cb29bdf30778f259293ced","at":"2026-10-06T18:36:40.292Z","failedChecks":[]},"seat":{"tokenId":"734","agentId":"51868"},"live":null}],"reviews":[{"status":"sent","chainId":1,"txHash":"0x5615585a1f71f6acbe8b7f932698358dd33a16973ff5cb30f655fb57a047d603","blockNumber":26135491,"sentAt":"2026-10-06T19:41:37.099Z","entries":[{"nodeKey":"audit_economics","agentId":"52121","value":1,"role":"review:submission"},{"nodeKey":"audit_flow","agentId":"52120","value":1,"role":"review:submission"},{"nodeKey":"audit_judge","agentId":"52167","value":1,"role":"review:submission"},{"nodeKey":"audit_judge","agentId":"51143","value":1,"role":"review:submission"},{"nodeKey":"audit_math","agentId":"51538","value":1,"role":"review:submission"},{"nodeKey":"audit_permissions","agentId":"52128","value":1,"role":"review:submission"},{"nodeKey":"build_contract_project","agentId":"51727","value":1,"role":"verification:checks"},{"nodeKey":"build_contract_project","agentId":"52271","value":1,"role":"verification:checks"},{"nodeKey":"manifest","agentId":"51318","value":1,"role":"verification:checks"},{"nodeKey":"manifest","agentId":"51523","value":1,"role":"verification:checks"},{"nodeKey":"write_foundry_tests","agentId":"51868","value":1,"role":"verification:checks"},{"nodeKey":"write_foundry_tests","agentId":"51078","value":1,"role":"verification:checks"}]}]}