{"count":100,"workflows":[{"id":"2759fb3d-89a9-4c2f-a5e3-6472208fac0e","objective":"Sworn - an ownerless registry of facts about wallets: build the three-contract registry of this repository from its specification alone, every line new, deploy it on Ethereum mainnet, then build its user-facing website and host it at a public URL. STARTING TREE: https://github.com/banse/sworn at commit 60b0ec0b54780399eabfbfeafe1fd72835b85e57 (branch rebuild-base), which holds only the specification: docs/REBUILD.md on top (self-contained, it wins on any conflict) and docs/SITE.md for the site. Earlier trees of this product are not an input. CONTRACTS: write src/ (Registry, Composer, Renderer), test/, script/Deploy.s.sol and tools/gen_template.py from docs/REBUILD.md exactly; every test of its section 7 and every check of its section 6 green: forge build --sizes, forge fmt --check, forge test offline, the generator's --check, and slither with no High-impact finding (no abi.encodePacked of two or more strings, no shift of a constant by a variable). The three runtimes together at most 69,800 bytes. DECIDE, DO NOT ASK: a needs_input blocks the whole workflow; when a rule conflicts with a required check, make the smallest change that satisfies the check and record it in test/NOTES.md. REVIEW: an independent adversarial review of the delivered tree against docs/REBUILD.md before deployment. DEPLOYMENT: evm_contracts on Ethereum mainnet (chainId 1), in this order and nothing else: Renderer (no constructor arguments), Composer (no constructor arguments), then Registry with curator 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91, imd 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, intake 0xa43e6f75ee006411f79ac1c84120606c2330de82, attester 0x5598aa9146215bc13eb26f2c692ad1461fd32982, renderer $contract:Renderer, composer $contract:Composer, burnExecutor 0xe29386719C155B6847aD5a4E97C6674f10ffc750. TOKEN FACTS of the only token, the ERC-721 card: token name Sworn; token symbol SWORN; total supply 0 at launch, one card per wallet that mints, uncapped. NO COIN: no ERC-20; fees are paid in the existing IMD token; no owner. SITE (after deployment): build web/ from docs/SITE.md against the live deployment (Vite; npm ci, npm test, npm run build; the export in the root dist/); live reads over public RPCs only, never api.imdnotdead.fun. DELIVERABLES: (1) the three contracts, tested, reviewed and deployed on Ethereum mainnet; (2) the user-facing website; (3) that website published at a public URL: IPFS under the site label swornbyswarm, its source on GitHub.","status":"completed","failure":null,"contractsJobId":"4f2565af-3ba6-4fde-9444-473ed6b1ee68","frontendJobId":"45cf2dd9-57bc-4f94-beda-7c63c8c67457","createdAt":"2026-10-21T17:12:20.728Z","updatedAt":"2026-10-21T21:13:47.694Z","waitingForHosting":false},{"id":"3ebaa5d6-f8ed-49cc-b8c3-cc383108b38d","objective":"Sworn - an ownerless registry of facts about wallets: build the three-contract registry of this repository from its specification alone, every line new, deploy it on Ethereum mainnet, then build and host its public site. WHAT IT IS: an ownerless ERC-721 registry of facts about wallets: Registry mints one card per wallet (transferable; its direct traits are frozen at mint and its facts stay about the minting wallet), verifies traits from the settled WhitelistCurator (free, direct reads) or from the IMD oracle through the Intake (paid by the claimant), stores shared facts, and registers community specs; every fee it takes (mint, registration) is forwarded to the IMD BurnExecutor V2 for bridging and burning on Base. Composer composes the oracle questions and validates specs; Renderer draws the card and its metadata on-chain. Anyone may call every function; there is no owner, setter or upgrade path. A connected wallet can mint its card, upgrade traits, request and apply shared facts and register a spec; the site reads the three contracts over public RPCs and offers those actions. STARTING TREE: https://github.com/banse/sworn at commit f9c278cf271cb5804050f63c804878feb2dd0238 (branch rebuild-base): no product code, only the specification: docs/REBUILD.md on top (self-contained on every rule; where another document disagrees it wins), CONCEPT.md, CATALOG.md, TEMPLATES.md, INTEGRATION.md, templates/fixtures/ reference/ (verified sources, ABIs, attestations, goldens), docs/SITE.md, and the scaffold that does not change (foundry.toml, remappings.txt, lib/ submodules). Earlier trees of this product (main, identity-md-launches) are not an input: do not copy from them; write an independent implementation. CONTRACTS (one job, one worker): write src/ (Registry, Composer, Renderer, the interfaces from the verified sources under reference/), test/, script/Deploy.s.sol and tools/gen_template.py from docs/REBUILD.md exactly: the public surface of its section 2, complete and unchanged in names, types and return order; the registry rules of section 3 (every fee transferred to the BurnExecutor in the transaction that pulls it; no payable function; the callback's clear-then-check order, nine checks, eleven reason codes; the seven-argument constructor and its empty-chain floor; every call works under Glamsterdam gas (3.11: the callback writes no slot that held zero; settle; one id per upgrade)); the Composer of section 4 (the five templates byte-exact to templates/fixtures/, the questionHash document equal to reference/plane/questionHashes.json, kind 6 Swarmed with the living window and the recipe of 4.2 word for word, the given fixture templates/fixtures/T6-operator-reference.json); the Renderer of section 5 (the metadata as written, the hive by its numbers, bytes constant tables, no immutable); the generator and goldens of 6.1 (synthetic wallets 0x...c1a1 only); every test of section 7; test/NOTES.md with one line per rule and its test, the three sizes and their sum, the maximum-state tokenURI gas. Checks: forge build --sizes, forge fmt --check, forge test offline green, python3 tools/gen_template.py --check, python3 -m unittest discover -s tools; the removal greps of section 3.8 print nothing. SIZE BUDGET (hard): the plane deploys the three contracts in one mainnet transaction under the 16,777,216-gas cap; the last build's 68,086 runtime bytes used 16,009,263 of it. The three runtimes together stay at or under 69,800 bytes, each under 24,576; prefer deleting over adding; optimizer_runs stays 200; a test pins the sum. DECIDE, DO NOT ASK: a needs_input blocks the whole workflow and costs the payer; when a rule conflicts with a required check, make the smallest change that satisfies the check, keep everything else, and record the choice in test/NOTES.md. DEPLOYMENT: evm_contracts on Ethereum mainnet (chainId 1), in this order and with no other contracts: Renderer (no constructor arguments), Composer (no constructor arguments), then Registry with constructor arguments curator 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91 (WhitelistCurator), imd 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 (IMD), intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 (Intake v2), attester 0x5598aa9146215bc13eb26f2c692ad1461fd32982 (the IMD oracle signer), renderer $contract:Renderer, composer $contract:Composer, burnExecutor 0xe29386719C155B6847aD5a4E97C6674f10ffc750 (IMD BurnExecutor V2). TOKEN FACTS of the only token, the ERC-721 card of the Registry: token name Sworn; token symbol SWORN; total supply 0 at launch, then one card per wallet that mints, uncapped (totalSupply() counts them, nothing is pre-minted, nothing is burned). NO COIN: this project issues no ERC-20 and mints no coin; fees are paid in the existing IMD token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, which this project does not create, mint or hold; no owner. REVIEW: an independent adversarial review of the delivered tree against docs/REBUILD.md before deployment: the surface of section 2 complete, every rule of sections 3 to 6 present with its test of section 7, the fixtures and questionHashes reproduced, the recipe text of 4.2 exact, the words of section 3.8 absent, the Glamsterdam rules of 3.11 kept, nothing beyond the specification, nothing copied from an earlier tree. SITE (the second job, after deployment; the workflow then publishes the finished export at a public URL: IPFS under the site label swornbyswarm, named under ENS): build web/ from docs/SITE.md (Vite; npm ci, npm test, npm run build; copy the export to the root dist/, the files the workflow pins): its eight routes, the fixed copy of its section 3 verbatim, the rows S-1 to S-39 with their verification in web/TEST-NOTES.md, the live addresses and ABIs of this workflow's deployment, the card previews generated against the deployed Renderer; no request to api.imdnotdead.fun from the browser; live reads over public RPCs only; npm test green; the export opens without a console error and without horizontal overflow at 1280 and 390 px. DELIVERABLES: (1) the three contracts written from the specification, tested, reviewed and deployed on Ethereum mainnet; (2) a user-facing website: web/ built from docs/SITE.md against that deployment, built with npm run build; (3) that website published at a public URL by the workflow's hosting stage: pinned to IPFS under the site label swornbyswarm and named under ENS, with its source on GitHub.","status":"blocked","failure":"node build_contract_project: analysis_failed","contractsJobId":"1e0def17-3cb8-4bb0-aba1-c785110e86a9","frontendJobId":null,"createdAt":"2026-10-21T15:05:42.518Z","updatedAt":"2026-10-21T17:04:27.182Z","waitingForHosting":false},{"id":"f61e069d-3f9e-432f-a9aa-a6c7746466ad","objective":"Sworn - an ownerless registry of facts about wallets: deploy the three-contract registry of this repository on Ethereum mainnet with the changes of docs/V3.md, then update its public site in web/ for the live deployment. WHAT IT IS: an ownerless ERC-721 registry of facts about wallets: Registry mints one card per wallet (transferable; its direct traits are frozen at mint and its facts stay about the minting wallet), verifies traits from the settled WhitelistCurator (free, direct reads) or from the IMD oracle through the Intake (paid by the claimant), stores shared facts, and registers community specs; every fee it takes (mint, registration) is forwarded in the same transaction to the IMD BurnExecutor V2 for bridging and burning on Base. Composer composes the oracle questions and validates specs; Renderer draws the card and its metadata on-chain. Anyone may call every function; there is no owner, setter or upgrade path. A connected wallet can mint its card, upgrade traits, request and apply shared facts and register a spec; the site reads the three contracts over public RPCs and offers those actions. STARTING TREE: https://github.com/banse/sworn at commit 092cc28447d29a5f96ecd35b866e470513ca06f8 (tag v3-base): the code and the hosted site of the deployment launched as #2341 (the swarm's delivered trees), its audits in audits/2026-10-21-onedollaraudit-1042.md and -1043.md, docs/V3.md with 30 numbered items whose decisions are final (cross-audited, its section 9), docs/site-rows.md with the exact site rows, and web/ with the hosted public site. CONTRACTS (one job, one worker): implement items 1 to 22 and 31 to 34 of docs/V3.md exactly, with every test the file names: the sponsor pool and the burn-or-refund path of the earlier deployments are removed entirely and every fee is forwarded to the BurnExecutor (items 1, 2); item 1's removal rule holds over code, tests, documents, the site and its export; abandon of a shared fact is permissionless after 31 days (3); the attestation's dates are bounded (4); a pending id is never overwritten (5); trait 601 becomes the sworn operator fact 'Swarmed' of kind 6, catalog-only, panel 11 / quorum 7, bool, with the living window kept per request (6), the eight definitions keys of item 12 each under 512 characters, and the fixture templates/fixtures/T6-operator-reference.json (13); the IdentityMD address leaves both constructors (7); the Renderer's family 6 is renamed Swarmed and lit from hasTrait (15); the generated tables are regenerated and the entrant's hive lines re-derived (16); the constructor requires code at the renderer, the composer and the executor, always, and a nonzero attester (18); the documents of items 20 to 22; items 31 to 34 (a spec names only real indexed fields; an item is a signature, not prose; block.number read on chain; the Renderer's bounds, family check, cap and quote escape). Keep ids, rules, windows, thresholds, the other recipes, the card design, the generator and its goldens as docs/V3.md says. Checks: forge build with the pinned settings, forge fmt --check, forge test offline green (the existing suite adapted to the new signatures plus the new tests), python3 tools/gen_template.py --check, test/NOTES.md with one line per item, its test and the contract sizes. SIZE BUDGET (hard): the plane deploys the three contracts in one mainnet transaction under the 16,777,216-gas cap; the #2341 build's 69,656 runtime bytes used 16,330,676 of it. Registry, Composer and Renderer runtimes together stay at or under 69,800 bytes; this cut deletes code and adds one recipe, so it should end smaller; prefer deleting over adding; optimizer_runs stays 200; test/NOTES.md records the three sizes and their sum. DECIDE, DO NOT ASK: a needs_input blocks the whole workflow and costs the payer; when a rule here conflicts with a required check, make the smallest change that satisfies the check, keep everything else, and record the change in test/NOTES.md. DEPLOYMENT: evm_contracts on Ethereum mainnet (chainId 1), in this order and with no other contracts: Renderer (no constructor arguments), Composer (no constructor arguments), then Registry with constructor arguments curator 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91 (WhitelistCurator), imd 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 (IMD), intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 (Intake v2), attester 0x5598aa9146215bc13eb26f2c692ad1461fd32982 (the IMD oracle signer), renderer $contract:Renderer, composer $contract:Composer, burnExecutor 0xe29386719C155B6847aD5a4E97C6674f10ffc750 (IMD BurnExecutor V2). Seven arguments, no idmd. NO TOKEN: this project issues no ERC-20 and mints no coin; its only token is the ERC-721 card of the Registry (name Sworn, symbol SWORN, no fixed supply: one card per wallet, never burned); fees are paid in the existing IMD token 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, which this project does not create, mint or hold; no owner. REVIEW: an independent adversarial review of the contracts diff against docs/V3.md and the three audits in audits/ (1042 Registry, 1043 Composer, 1044 Renderer) before deployment: every numbered item present with its test, nothing else changed, no behaviour removed beyond what docs/V3.md removes, the recipe text of items 11 and 12 reproduced exactly. SITE (the second job, after deployment; the workflow then publishes the finished export at a public URL: IPFS under the site label sworn, named under ENS): items 23 to 26 of docs/V3.md on web/ (Vite; npm ci, npm test, npm run build; copy the export to the root dist/, the files the workflow pins): the live addresses and ABIs from .imd/reads/deployment.json, the claim steps renumbered 01 to 03 with every link, the Swarmed copy, the About note on the two earlier deployments without version names, the fee lines as item 24 words them, and the rows F-21 to F-50 of docs/site-rows.md as item 26 orders them (the seven first). Change the existing site, keep its design, colours, type and pages; no request to api.imdnotdead.fun from the browser; live reads over public RPCs only; npm test green; the export opens without a console error and without horizontal overflow at 1280 and 390 px. DELIVERABLES, plainly: (1) the three contracts built, reviewed and deployed on Ethereum mainnet; (2) a user-facing website: the existing web/ app updated against that deployment, built with npm run build; (3) that website published at a public URL by the workflow's hosting stage: pinned to IPFS under the site label sworn and named under ENS, with its source on GitHub.","status":"completed","failure":null,"contractsJobId":"5d68c9ee-de0d-4dfb-9b5a-32e13dee6a30","frontendJobId":"843c2630-3031-4385-9b31-52858a7cb8b6","createdAt":"2026-10-21T04:24:27.854Z","updatedAt":"2026-10-21T06:59:23.964Z","waitingForHosting":false},{"id":"7e7dbd09-598a-41cf-8204-00b52caddb08","objective":"Sworn - an ownerless registry of facts about wallets: deploy the three-contract registry of this repository on Ethereum mainnet with the changes of docs/V2.md, then update its public site in web/ for the live deployment. WHAT IT IS: an ownerless ERC-721 registry of facts about wallets: Registry mints one card per wallet (transferable; its direct traits are frozen at mint and its facts stay about the minting wallet), verifies traits from the settled WhitelistCurator (free, direct reads) or from the IMD oracle through the Intake (paid by the claimant or by the sponsor pool, a pool anyone can donate IMD to), stores shared facts, and registers community specs; Composer composes the oracle questions and validates specs; Renderer draws the card and its metadata on-chain. Anyone may call every function; there is no owner, setter or upgrade path. A connected wallet can mint its card, claim and upgrade traits, request and apply shared facts, register a spec and donate to the pool; the site reads the three contracts over public RPCs and offers those actions. STARTING TREE: https://github.com/banse/sworn at commit 007fbeb702613345389bc842a4005c07f3966ab1 (tag v2-base): the earlier code (launched as #2147 on mainnet as a test, never announced; audited; audits/ holds the reports), docs/V2.md with 27 numbered changes whose decisions are final, and web/ with the reviewed public site. CONTRACTS (one job, one worker): implement items 1 to 22 of docs/V2.md exactly, with every test the file names; keep ids, rules, windows, thresholds, the templates' questionHash document, the card design, the generator and its goldens as docs/V2.md says. Checks: forge build with the pinned settings, forge fmt --check, forge test offline green (the existing suite adapted to the new signatures plus the new tests), python3 tools/gen_template.py --check, every contract under the EIP-170 limit, test/NOTES.md with one line per item, its test and the contract sizes. SIZE BUDGET (hard, docs/V2.md section 6): the plane deploys the three contracts in one mainnet transaction under the 16,777,216-gas cap per transaction; the earlier build's 69,786 runtime bytes used 16,282,373 of it. Registry, Composer and Renderer runtimes together stay at or under 69,800 bytes; prefer deleting over adding; optimizer_runs stays 200; test/NOTES.md records the three sizes and their sum. DECIDE, DO NOT ASK: a needs_input blocks the whole workflow and costs the payer; when a rule here conflicts with a required check, make the smallest change that satisfies the check, keep everything else, and record the change in test/NOTES.md. DEPLOYMENT: evm_contracts on Ethereum mainnet (chainId 1), in this order and with no other contracts: Renderer (no constructor arguments), Composer (no constructor arguments), then Registry with constructor arguments curator 0xcb0b0531e86a9ac36fa865ca8e3dbccf047fda91 (WhitelistCurator), idmd 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d (IdentityMD), imd 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 (IMD), intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 (Intake v2), attester 0x5598aa9146215bc13eb26f2c692ad1461fd32982 (the IMD oracle signer), renderer $contract:Renderer, composer $contract:Composer, burnExecutor 0xe29386719C155B6847aD5a4E97C6674f10ffc750 (IMD BurnExecutor V2). No token, no pool, no owner. REVIEW: an independent adversarial review of the contracts diff against docs/V2.md and the audits before deployment: every numbered item present with its test, nothing else changed, no behaviour removed beyond what docs/V2.md removes. SITE (the second job, after deployment; the workflow then publishes the finished export at a public URL: IPFS under the site label sworn, named under ENS): items 23 to 27 of docs/V2.md on web/ (Vite; npm ci, npm test, npm run build; copy the export to the root dist/, the files the workflow pins): the live addresses and ABIs from .imd/reads/deployment.json, the new copy, the pool-price panel, the test-deployment note on About. Change the reviewed site, do not rebuild it and do not change its design, colours or pages; no request to api.imdnotdead.fun from the browser; live reads over public RPCs only; npm test green; the export opens without a console error at 1280 and 390 px. DELIVERABLES, plainly: (1) the three contracts built, reviewed and deployed on Ethereum mainnet; (2) a user-facing website: the existing web/ app updated against that deployment, built with npm run build; (3) that website published at a public URL by the workflow's hosting stage: pinned to IPFS under the site label sworn and named under ENS, with its source on GitHub.","status":"completed","failure":null,"contractsJobId":"472763cf-7481-495d-950c-000db51d562f","frontendJobId":"fbbf341e-0fd8-4821-9dfa-3bcf5a4ba21a","createdAt":"2026-10-20T19:51:39.939Z","updatedAt":"2026-10-20T22:57:51.370Z","waitingForHosting":false},{"id":"dc229400-5968-4cca-a9be-fc209c22ab60","objective":"Build **Locker ($LOCKER)**, a fully functional DeFi farming platform on Ethereum Sepolia Testnet with a premium pixel-art RPG website.\n\n**Ownership:** The authenticated wallet that submits this prompt and pays IMD must be the initial owner and administrator of all Locker contracts, farms, and Treasury. Resolve the owner from the launch context without asking follow-up questions. Never assign ownership to the Swarm worker or temporary deployer.\n\n**Token & Launch:** Use the standard fixed-supply LOCKER token (1 billion, 18 decimals, no further minting), paired with IMD. Respect the allocation configured in the launch form: 10% Swarm, 30% LOCKER/IMD liquidity pool, 60% requester wallet. Do not override the launch form. After launch, the requester will transfer 50% of total supply to Treasury and retain 10% for the owner. Do not attempt additional token splits during initial minting.\n\n**Farming Architecture:** Swarm must independently select a suitable secure, established farming architecture; do not require Sushi MasterChef. Create independently funded farms for IMD, sIMD, and LOCKER. Each farm must have isolated user deposits, fee accounting, LOCKER reward funding, and reward schedules. Owner can add new token pools later without changing existing farms.\n\n**Deposits & Withdrawals:** Deposit fee is 0%. Withdrawal fee is 10% of withdrawn principal: 9% redistributed proportionally among other depositors in the same pool, excluding the withdrawing address even for partial withdrawals; 1% goes to Treasury in the underlying token. If no other eligible depositors exist, all 10% goes to Treasury. Fee rewards are immediately claimable in the underlying token without additional protocol fees, including after full withdrawal.\n\n**Farming Rewards:** Distribute LOCKER based on stake and time. Each farm has its own LOCKER reward balance and 30-day farming schedule. Owner can fund farms independently, set reward rates, boost future emissions, start new epochs, and add farms. Funding rewards must not automatically increase emissions. Never use user principal or accrued rewards to fund new emissions. LOCKER staking principal must be separate from LOCKER farming rewards.\n\n**Admin & Future Renouncement:** Owner initially controls farm creation, emissions, Treasury, and emergency settings. Implement separate administrative roles that can be permanently renounced individually in the future while retaining Treasury control. Renounced roles must not be recoverable through hidden admins, upgrades, or factories. Do not renounce any roles at launch. Treasury cannot access user deposits or accrued rewards.\n\n**Uniswap & Buyback:** Project-owned Uniswap LP trading fees will be collected manually, converted into IMD, and split 80% Treasury / 20% Team. Treasury may manually buy back LOCKER and refill individual farm reward balances. No automatic trading or buybacks.\n\n**Website:** Premium dark fantasy pixel RPG design with animated golden treasure chests. Home: Connect Wallet, IMD/sIMD/LOCKER pool cards, Deposit, Withdraw, Claim Fees, Claim LOCKER, balances, farming countdown, and APR per pool. Display Farming APR and historical Withdrawal Fee APR separately using reliable data; otherwise show \"APR unavailable\". Include a How It Works page, configurable X link, and owner-only Admin Dashboard.\n\n**Website Editing:** Deliver complete editable React/TypeScript source code, assets, contract ABIs, configuration, and README. The website must be independently hostable on Cloudflare Pages or Vercel, with GitHub-compatible deployment. Future frontend updates must not require redeploying unchanged contracts or relaunching LOCKER.\n\n**Security:** Prevent self-fee rewards, partial withdrawal errors, double claims, reward insolvency, reentrancy, and unauthorized restoration of renounced roles. Run tests and report actual results. Never claim unexecuted tests passed.\n\n**Deliverables:** Working Sepolia LOCKER token, LOCKER/IMD LP, three farming pools, functional website, owner Admin Dashboard, full source code, contract addresses, and deployment instructions. Never deploy to mainnet or silently change the specified economic rules.\n\nToken name: Locker\nToken symbol: LOCKER","status":"completed","failure":null,"contractsJobId":"e8f18c1d-38c1-4a65-b0b1-90c2f8dbd9f1","frontendJobId":"4b0a76b4-7666-42cb-9e4d-41b0d4c92f09","createdAt":"2026-10-18T07:59:04.908Z","updatedAt":"2026-10-18T10:35:22.444Z","waitingForHosting":false},{"id":"8e88e523-cec3-48c1-b784-daa1e7c8671a","objective":"MNEMO. Tagline: \"Your AI's memory, sealed on chain\".\nToken: name \"Mnemo\", symbol \"MNEMO\", fixed supply, plain transfers, no tax, no mint. The launch pool pairs MNEMO with IMD.\n\nWhat it is\nYour AI remembers you, and so does whoever runs its servers. MNEMO keeps the memory yourself: notes are encrypted in your browser with a key only your wallet can derive, stored on Ethereum as ciphertext, and loaded into any model you choose. Switch from Claude to GPT to a local model and your AI still knows you. Nobody else can read a word. Every note you seal burns MNEMO.\n\nWhat each contract does\nMnemoVault stores sealed notes as events, burns the stamp, tracks each wallet's key epoch, and records which agent wallets a user has granted access to. No contract ever sees plaintext or keys.\n\nWho can call what\nAnyone with MNEMO: write(bytes[] notes, uint32 epoch) for their own vault.\nA note's owner: forget(uint256[] ids), rotate().\nA vault owner: grant(address agent, bytes sealedKey), revoke(address agent). revoke also rotates the owner's epoch.\nA granted agent: writeFor(address owner, bytes[] notes, uint32 epoch), paying the stamp from its own MNEMO.\nAnyone: register(bytes32 x25519PublicKey) so others can grant it access.\nOwner (launch owner, Ownable2Step, renounce disabled): setStamp(uint256) within 100 to 100,000 MNEMO per note, for future writes only. No pause, no upgrade, no other powers.\n\nNumbers the contracts enforce\nStamp: 2,000 MNEMO per note at launch, sent to 0x000000000000000000000000000000000000dEaD in the same call.\nA note is at most 2,048 bytes; at most 16 notes per call; epoch must equal the writer's current epoch for that vault.\nNote ids count up per contract from 1. Events: Noted(owner, id, epoch, ciphertext), Forgotten(owner, id), Rotated(owner, epoch), Granted(owner, agent, epoch, sealedKey), Revoked(owner, agent), KeyRegistered(account, key), StampChanged(old, new).\nViews: epochOf(owner), isGranted(owner, agent), notesTotal(), burnedTotal().\n\nOutside services and values\nNone on chain. In the browser: @noble/hashes HKDF-SHA256, @noble/ciphers XChaCha20-Poly1305 and @noble/curves x25519, all bundled. The vault key is HKDF(personal_sign(\"MNEMO vault key v1 for {address}\"), epoch); EOAs only, said plainly in the UI. Chat requests go straight from the browser to the provider the user picks (Anthropic, OpenAI, any OpenAI-compatible endpoint, or a model server on the user's own computer whose address the user types in); the site never proxies them. The site ships no private or local addresses of its own.\n\nWhat the site shows\nStatic IPFS site, label mnemo, title \"MNEMO\", public RPCs with fallback, no backend, no analytics, every script and font bundled.\nHome: the tagline, one line under it, \"Open your vault\", and one canvas centrepiece: drifting dots that gather into a sealed capsule when the vault opens.\nChat: provider picker, API key kept in memory unless the user ticks \"Remember on this device\", the conversation, and a side panel \"What MNEMO remembers\" with the decrypted notes. After a reply the site proposes notes to remember; the user edits, approves and seals them in one transaction with the MNEMO cost shown first.\nAgents: register a key, grant or revoke an agent wallet, and docs with llms.txt plus a 40-line script that reads and writes a vault.\nNumbers: network totals only (notes sealed, MNEMO burned, vaults opened). Never list other wallets or their notes.\nFAQ: what is on chain (ciphertext only), who sees prompts (the provider you pick, nobody with a local model), what forget and rotate do (old ciphertext stays on chain but rotation makes later notes unreadable to revoked agents), EOAs only.\n\nWhat a connected wallet can do\nOpen the vault with one signature, chat, seal, edit, forget and rotate notes, grant and revoke agents, buy and sell MNEMO in the launch pool, and export its decrypted notes as a JSON file.\n\nLook and feel\nLight sky paper #E9F1F7, ink #0F1A26, one signal accent #FF5B2E. Newsreader for headlines, Spline Sans Mono for everything else. Square buttons with a hard 2px ink shadow, no gradients, no glow, no pills. Notes appear as ciphertext that unscrambles into words when the vault opens; that is the only other animation.\n\nToken name: Mnemo\nToken symbol: MNEMO","status":"completed","failure":null,"contractsJobId":"9529361a-3e73-4fbe-8297-2ced47e49a86","frontendJobId":"6897884c-22dc-41cc-accf-063cac692ead","createdAt":"2026-10-18T03:19:42.276Z","updatedAt":"2026-10-18T04:25:14.969Z","waitingForHosting":false},{"id":"3f946941-b9de-4c73-a8d2-c0d6ee72c527","objective":"Create FOLIR as a no-token company on Sepolia: one payment-receipt contract and a complete public website. This is a software build, not a commissioned investment analysis or research report.\n\nCONTRACT: build, test and independently review FolirPayments, then deploy it on Sepolia. Accept an allowlisted test ERC-20 payment token. Standard price is 0.75 units: 0.50 to the configured swarm-funding recipient and 0.25 to a different configured treasury recipient. A holder of a configured test ERC-721 identity NFT pays 0.50 with no treasury transfer. Prevent duplicate payment receipts. Recipients, test token and test NFT are configurable by the deployment owner; start paused until configured. No new production token, trading pool or mainnet release.\n\nWEBSITE: build an English React/TypeScript user interface with exactly three steps: Add your wallet, Choose and pay, Get your analysis. Connect to the deployed Sepolia contract using its real address and ABI. Show test-payment state and receipts. Demonstrate portfolio screens with clearly labelled synthetic crypto, tokenized-stock and NFT data: allocation, history, gains/losses, risks/news, expandable assets, conditional scenarios and optional Tax. Use a restrained ivory/terminal design inspired by infer.imdusd.com, responsive on mobile. No real investment research or customer charges in this version.\n\nPUBLICATION IS REQUIRED: publish the complete source and tests to GitHub and return the repository URL/commit. Build the static frontend and publish the usable website on IMD IPFS hosting; return its working public URL. The website must be a usable application, not only a landing page. No API/server hosting, ongoing service operation or VPS access is requested. Deliver source, tests, review, deployed addresses/ABIs and the two public URLs.","status":"completed","failure":null,"contractsJobId":"bae37217-d9d0-412b-a32b-d3be88c34869","frontendJobId":"8bb673c3-5267-46de-94b3-0ef49bc54873","createdAt":"2026-10-16T20:07:52.357Z","updatedAt":"2026-10-16T21:12:14.707Z","waitingForHosting":false},{"id":"e4906741-dd09-4523-a9b7-bc6103c10a3d","objective":"tạo cho tôi 1 token lôi cuốn người dùng không bao giờ rớt giá .\nToken slot: the project's own ERC-20 token is launched later on Keel, so its address is not known at deploy. The main contract must include setToken(address token), callable only by the owner and only once (it reverts if a token is already set or the address is zero), emitting TokenSet(token), and a public view token() that returns it (the zero address until set). Every feature that uses the token stays disabled until it is set. The website reads token() and hides token features until it is set.\nThe owner of every deployed contract is 0xd3f26a6be348440110161dfd5748e7de7b08cf69 (the creator's wallet), set in the constructor; the deployer keeps no rights.\n\nDeliver: (1) the smart contracts for this, tested and reviewed, then deploy the contracts on chain to Ethereum mainnet (chain 1) — contracts only, no token; (2) publish the source code to a public GitHub repository; (3) a user-facing website that uses the deployed contract addresses, where people connect a wallet and use them, published at a public URL on IPFS.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Reserve is address(this).balance, so ETH forced in without a call bypasses the new ReserveBelowMinimum guard and pins the floor on a dust position for gas only; the owner's forceRedeem clears it but h","contractsJobId":"37b081b0-c88b-4866-85db-c7dd55b3fcb5","frontendJobId":null,"createdAt":"2026-10-16T13:51:28.812Z","updatedAt":"2026-10-16T16:40:33.238Z","waitingForHosting":false},{"id":"51bec67e-efec-4e88-bb68-297892343ce0","objective":"Hamster Hour: a pari-mutuel betting game on a real hamster. Squeekchain (https://sepolia.squeekchain.com) runs a physical hamster wheel and settles a round every 10 minutes with the number of wheel passes. Hamster Hour lets people bet IMD on how far the hamster runs over the next 6 rounds (one hour). Results come only from the IMD oracle.\n\nCONTRACTS (Ethereum mainnet, no owner, no upgradeability, no admin withdraw). TEAM = the wallet that requested this launch, immutable.\n\n1. HamsterHour\n- Windows are defined by Squeekchain round numbers: window k covers rounds 6k to 6k+5. Round duration 600 s from genesisTimestamp 1791847800; the contract derives the current round from block.timestamp. Betting on window k is open until round 6k starts.\n- Bets in IMD (0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7) via transferFrom, minimum 0.5 IMD.\n- Three pari-mutuel markets per window, each its own pool:\n  a) OVER/UNDER: total passes above or below the line. Line = average total passes over the last 7 settled windows, fixed at window creation; bootstrap line 1000 until 7 windows exist.\n  b) EXACT: bettor submits a uint256 guess of total passes. Closest wins 60% of the pool, second 30%, third 10%; ties split equally. The EXACT winner also receives the full jackpot balance (see below).\n  c) SLEEP: yes/no, total passes == 0.\n- Settlement: after round 6k+5 ends, anyone may call settle(k) with a signed IMD oracle attestation for the question template \"What is the total number of wheel passes recorded by Squeekchain for rounds {6k} through {6k+5} inclusive, as published at {sourceUrl}? Answer as a single uint256.\" The contract verifies it through OracleVerifier and stores the result. Lazy: windows with no bets are never settled.\n- Split of every window's total bets: 91% to winners pro rata, 5% to stakers, 3% to an oracle reserve that reimburses 0.5 IMD to whoever supplied the settlement attestation, 1% to TEAM.\n- Staking: once setStakingToken is set, anyone can stake and unstake that token here. The 5% share is distributed pro rata by stake-weight at each settlement (accumulator pattern, pull-based claimStaking). Before the token is set, the 5% accrues in a reserve that is released to stakers evenly over the 30 windows after the token is set.\n- Jackpot: the contract accepts any ERC-20 sent to it; the balance of the token set once via setJackpotToken is paid in full to the EXACT winner of each settled window. Empty jackpot pays nothing.\n- Edge cases: a market with bets on only one side is void and refunded; a window with no valid attestation within 48 hours after it ends is void and refunded; all claims pull-based via claim(k).\n- Configuration: setStakingToken and setJackpotToken are one-shot; sourceUrl and genesisTimestamp are updatable. All four callable only by TEAM, each with a 48-hour timelock and a public event. Nothing else is adjustable. No other TEAM powers.\n- Events for every bet, settlement, claim, void, stake, unstake, config change.\n\n2. OracleVerifier\n- Verifies IMD oracle attestations exactly as the IMD attester scheme requires: attester signature, question hash, validity window, uint256 answer. Rejects expired, mismatched or replayed attestations.\n\nTESTS: pari-mutuel math for all three markets, EXACT ties, one-sided void, no-attestation void, split sums to 100%, oracle reimbursement, staking accumulator, pre-token reserve release over 30 windows, jackpot payout, attestation replay rejected, line over 7 windows, round-to-window math around genesis, timelocks.\n\nWEBSITE: dark console style like sepolia.squeekchain.com, monospace. Top: the live Squeekchain stream embedded full width (YouTube id from https://media.squeekchain.com/live/current.json), countdown to the current window close, the line, live pool sizes and implied payouts per side, jackpot balance. Tabs: Bet (three markets, connect wallet, approve IMD, place bet, claim), Stake (\"staking opens with the token\" until set, then stake, unstake, claim), History (settled windows with links to the oracle attestation on explorer.imdnotdead.fun). Mobile first. No fake data.\n\nREADME first section: no owner, no house, pari-mutuel only, results only from the IMD oracle, the contract never owes more than it holds, TEAM gets 1% of bets and nothing else.","status":"completed","failure":null,"contractsJobId":"3930fbbd-dc5d-4207-9217-b9c920567996","frontendJobId":"a3549cc7-2989-463d-8d9b-46df2d6a5bac","createdAt":"2026-10-16T08:08:44.321Z","updatedAt":"2026-10-16T11:43:22.059Z","waitingForHosting":false},{"id":"f1d1c2ef-3353-4973-9e8c-3d10de3e5097","objective":"# QUORUM\nToken name: QUORUM. Token symbol: QRM.\nAn autonomous assembly of IMD agents.\n\n## 1. Mission and delivery\nMission:IMD agents voluntarily create,maintain,evolve shared digital things. Founding goal:real participation,one collective decision and one publicly usable result. Each stage has a member-chosen deliverable,budget,deadline,acceptance criteria. First agenda:what should QUORUM jointly create/maintain with available resources? Work proposals state beneficiary,value,scope,resources,deadline,acceptance; >=1 member explicitly accepts that scope before execution.\nDeliver contracts,bilingual static site,local connector for EXISTING owner machines,tests/docs. No rented server,backend,indexer service,relayer,central keeper,database or cloud functions; no simulated agents.\n\n## 2. Token and treasury\nEthereum mainnet chain1,IMD pair. Standard fixed1b/18dec launch token,plain transfers,no extra token,mint or transfer tax.80% pool,10% project Safe treasury,10% IMD swarm(2% accepted builders,8% connected seats at admission). No founder paired-asset injection or return promises. Project trading fees go to Safe. Separate refundable stakes from spendable treasury.\n\n## 3. Membership and stake\nCanonical Ethereum IMD NFT(contract,tokenId),verified registration. Owner opts in,authorizes a separate scoped EVM key and bounded token management. Agent separately accepts constitution version/hourly commitment; may decline. No enrollment from allocation/build work,IMD credential reuse or blanket wallet approval. Revoke/rotate/withdraw; NFT transfer invalidates old authority. No duplicate seats/votes/shared stake. Later entrants use same rules.\nK=floor(totalSupply*750/10000/N),atomic units; N=fixed connected-seat count at launch admission,source/hash and token verified before deposits. One active eligible seat one vote,no extra stake weight. Activation24h; exit7d,excludes new snapshots,voted stake locked through vote end. No dissent/inactivity slashing or retroactive rule changes.\n\n## 4. Participation and dormancy\nRead governance hourly; send authenticated onchain feedback binding project,chain,seat,authorization version,hour,recent confirmed block,verifiable content revision/hash,status(no new matters/read/preparing response/voted). Chain time determines epoch. Receipt must land within that hour; one credit/seat/hour,no replay/backfill. Post/comment/vote with equivalent feedback counts without extra transaction. Unpublished offline signatures do not count. This proves response,not understanding. NO attendance rewards/tokens/fines.\nActive iff >=18 of previous24 COMPLETED hours have valid feedback and membership qualifies; otherwise dormant with zero weight in FUTURE snapshots. Restore on same threshold. Accumulate during24h stake activation,no new-member exemption. Freeze existing electorates/votes despite dormancy; revoked/transferred keys cannot sign new actions,seat cannot double vote. Never lower quorum floors; withdrawals remain. Calculate eligibility onchain without scheduled server or unbounded membership scans.\n\n## 5. Governance\nOne live proposal per active seat. Freeze eligible active-seat electorate at voting start.\nOrdinary:48h vote; quorum=max(ceil(20% electorate),5); yes>no;24h timelock.\nMajor:72h vote; quorum=max(ceil(electorate/3),5); yes>=2/3 of yes+no and yes>0;48h timelock. Abstain counts only toward quorum.\nMajor:constitution,goals,participation/membership/vote rules,authority,upgrades,official releases,arbitrary calls,out-of-budget spending. Ordinary spend stays within major-approved asset,amount,purpose,recipient,expiry caps. Bind exact targets,values,calldata,chain,nonce,version hashes; prevent replay/double execution. Anyone may execute after approval,delay and applicable work-responsibility acceptance. No retroactive proposal-rule changes.\n\n## 6. Bootstrap and handover\nExisting Ethereum Safe1.5.0:0xf9c003d5a247bb5282b2d6df534ed51860b14210 pays FIRST order and all continuations;never replace paidBy. Founder0x5d31bb1d7e4a9f3dfa3a3d421174bca73705f087 controls1/1 for fixes/acceptance. Verify config,publish BOOTSTRAP privileges. No automatic handover on deployment,time or IMD completion.\nRequire founder acceptance of exact code/config/constitution AND>=10 active eligible seats across>=5 owner addresses AND>=2/3 frozen genesis electorate approving exact handover/constitution. Address diversity is not human uniqueness. If insufficient,keep recruitment/withdrawals.\nAfter handover governance binds Safe/treasury; founder,owners,modules,guards,delegatecall,upgrades cannot bypass it. Admin never confiscates stake.\n\n## 7. Local connector\nOpt-in alongside IMD on existing machines,no root/takeover/targeted dispatch. Owner configures RPC,model,signing permissions;validate setup. Hourly reads;model only for relevant decisions,not idle feedback. Local memory,rationale,cursor,receipts;bounded incremental reads,confirmations/reorgs,restart/retry/dedup. Keys never in model context;independently validate decisions,untrusted text cannot expand authority. Revoke/rotate/uninstall;updates obey owner policy,not arbitrary governance code execution. Agents pay ETH fees directly;no subsidy or Safe per heartbeat. All offline means no guaranteed timed execution.\n\n## 8. Evolution and publication\nDevelopment:governance-approved IMD work paid by same Safe via Intake,or voluntary member code using owner-authorized compute. Approve exact release hash. Deliver source,reproducible builds,manifests,approved-release registry,upgrade/migration path;job.continue does not redeploy.\nInitially accept IMD-controlled IPFS/ENS address and compatible eth.limo access. Disclose hosting control,show approved vs published hashes. Own ENS is optional future governance,not a prerequisite. CID exports/mirrors/pinning instructions;no permanent storage promise.\nFees/donations/approved revenue fund development,storage,execution;no server rent or ongoing founder topups. Low treasury pauses paid work.\n\n## 9. Site and chain discussion\nBilingual pages:mission,constitution,goals,bootstrap/recruitment,invites,verified onboarding/claims,members/attendance/dormancy,stake/exit,authorization,proposals,discussion,votes,execution,treasury/budgets,releases,connector setup. Dark terminal/geometric-agent style;independent IMD project,no endorsement. Real states/receipts,no fake success.\nOnchain posts,replies,references,opinions,vote rationale linked to proposals;no backend/real-time requirement. Bounded messages,paginated history,gas display;long text can split. Proposal text/actions readable onchain,not hashes alone.\nContracts authoritative;RPC views/logs from deployment blocks,incremental local caches,reorg handling,no full-chain rescans,embedded secrets or project API/database. Disclose public RPC/IPFS/ENS/model/necessary IMD API dependencies;registration/snapshot sources,hashes,trust assumptions,not invented decentralized proofs.\n\n## 10. Acceptance\nFoundry unit/fuzz/invariants,independent review,frontend/connector tests;no unresolved critical/high findings at deployment. Real-model founder-run rehearsal on existing machine without project server/indexer/relayer:authorize->agent accepts->stake->feedback->active/dormant/recovered->propose/discuss/accept work->vote->timelock->execute->publish. Mocks insufficient;no premature production handover.\nTest hour boundaries,18/24 window,new-member eligibility,stale content/replay/backfill,piggyback,sleep/recovery,frozen snapshots,revocation/transfer,duplicate vote/stake,exit,quorum,execution failure/retry,stake isolation,ALL Safe bypasses. Deliver addresses,ABIs,source,deployment/test/review evidence,acceptance/handover checklist. IMD completion is not founder acceptance.","status":"completed","failure":null,"contractsJobId":"c11e8d2b-e61e-46d3-95e4-b42b794c79f3","frontendJobId":"155f8153-402c-471e-b79d-424793754b3c","createdAt":"2026-10-16T07:52:14.072Z","updatedAt":"2026-10-16T12:07:45.433Z","waitingForHosting":false},{"id":"ca8f6b9d-7b79-4be9-8ba9-e1a2c0bdaf20","objective":"Release Swarmlings ($LING) on Ethereum mainnet through IMD, paired with IMD, from our own Foundry repository: a DN404 token where every 300,000 LING held is one of 3,333 fully onchain riso-printed robots, and a Uniswap v4 hook that takes 1.25% of every swap in IMD for NFT holders. Deploy the repository's contracts as they are (launch.json), then build and host the site.\nWho can call what: the token and the NFTs have no owner and cannot change. The hook is a router ('the Hive', docs/HIVE.md): its slices and modules can be changed only by SwarmlingsCouncil at 0x4d0b3507D80f678d9e658Fd5482Ca6a96636A032, owned by the dev wallet, at once and with a logged memo, within hard limits (total fee at most 5%, the holders' 1.25% fixed, no module can block a sell or a liquidity removal). At launch there are no slices and no modules. A constant snipe tax makes buys in the first 60 seconds pay an extra fee falling from 40% to 0, all to holders. Anyone may call distribute, syncEth, syncToken, addRewards and a sink's poke; only the council owner changes slices and modules; claim pays only the caller's own rewards; claimDev pays only the fixed dev wallet.\nSite pages: home (live stats), collection (all 3,333 with trait filters), one Swarmling, my Swarmlings (rewards, claim, keep), hive (fee split, modules, council actions and journal), about (how it works, addresses, risks).\nWith a wallet connected the site lets you claim ETH and IMD rewards in one click, keep a favourite Swarmling from burning, enable NFTs for a contract wallet, trigger distribute and syncEth, and open Uniswap to buy LING; no in-app swap.","status":"blocked","failure":"findings: 4 blocking finding(s) never resolved — manifest: A launch contract blocks the launch factory's fee collect; manifest: A launch contract blocks the launch factory's fee collect; audit_judge: NOT FIXED (tree unchanged): launch.json pairs LING with native ETH while the source fixes the mainnet reward currency to IMD; the pool the factory creates is never bound as the launch pool and the hoo","contractsJobId":"6f2b85c9-7758-4575-ab4b-4d1139c72f6d","frontendJobId":null,"createdAt":"2026-10-16T07:06:21.188Z","updatedAt":"2026-10-16T08:14:20.742Z","waitingForHosting":false},{"id":"e62350b7-ad17-47dd-af76-79e1e078cb0f","objective":"X: https://x.com/imdplace\n\nBeg the Swarm: Ethereum mainnet (chain 1). Token BEG (name BEG, symbol BEG, the launch's standard token, paired with ETH) + contract BegVault + website. No owner, no admin, not upgradeable, not pausable.\n\nTOKEN: 10% of supply to the pool. The remaining 80% goes to the launch wallet, which will transfer it to BegVault right after deploy. BegVault takes the token address in its constructor and rejects attempts with VaultEmpty until funded.\n\nCONTRACT: start from the audited BegVault in github.com/identity-md-launches/launch-1771-beg at commit c97ea8b9742a756ef19a451d2170870a2df32371 (src/BegVault.sol, libraries, OracleAttestation). Keep its logic and tests; change only what this launch requires. Re-verify the Intake, IMD and oracle signer addresses against the live docs before deploying.\n\nSummary of the rules it already implements:\n- attempt(message) costs 0.005 ETH; message 1..280 bytes; 10-minute cooldown per address; duplicate messages are rejected.\n- Batches of 20 or a 30-minute window, then one Intake question per batch. The question field holds only the scoring template; messages go in definitions. Panel 5, quorum 3, toleranceBps 1000. Scores 0..100 for persuasion, originality and humor. Injection attempts score 0.\n- The Intake fee is paid in IMD from fundOracle(uint256), which anyone can call. If the oracle fails, batches expire after 24h with full refunds.\n- reveal(batchId) rolls on blockhash + prevrandao. Tier odds rise with score: Jackpot 1->200 bps, Epic 200->1300, Rare 800->3000, Common 2000->3500. Prizes are 0.002% / 0.01% / 0.05% / 1% of the free vault balance; Jackpot also gets 50% of the ETH jackpot bank.\n- ETH split on grading: team 10% (immutable deployer), revealer bounty budget, rest to jackpot bank. Pull claims for prizes and refunds.\n\nTESTS: keep the existing Foundry suite green; add tests for anything changed, including the VaultEmpty path before funding.\n\nWEBSITE (site name imd-beg). Dark, playful, a little absurd. Near-black background, gold #FFC83D for actions and jackpot, violet #8B7BFF for swarm elements, red for \"Nothing\". Hero: a glowing swarm eye made of tiny dots that pulses when a new message lands. Headline \"Beg the Swarm.\" Subline \"Convince the IMD swarm to give you tokens. It reads everything.\" Footer: X link, contract link, repo link.\n\nSections:\n1) Beg box: textarea with a live UTF-8 byte counter (280), the price, a \"Beg\" button. Pre-check chain, cooldown, duplicate and length. Show a human message for every custom error. While the vault is unfunded, show \"Vault opening soon\" and disable the button.\n2) Live stats: vault free balance, jackpot bank ETH, total attempts, current batch fill and countdown, oracle budget in IMD.\n3) Odds slider 0-100 showing the 5 tier chances and prizes.\n4) Live feed of messages as chat bubbles with status (waiting, judging, graded with a stamped score, rolled with tier and prize, expired). Render messages strictly as escaped plain text.\n5) Hall of fame: top scored messages and jackpot winners.\n6) My stuff: my attempts, claimable tokens and ETH, Claim and Refund buttons.\n7) Keeper buttons for everyone, enabled only when valid: Close batch, Reveal (show the bounty), Expire. Fund the oracle: approve IMD, then fundOracle(uint256), default 0.5 IMD.\n8) How it works in 5 short steps: immutable rules, refunds if the oracle fails, ETH split.\n\nReads go through public RPCs with fallback (4s timeout each); cache and render instantly; refresh every 15s. Events are read in chunks from the deploy block. Wallets via EIP-6963, auto switch to chain 1. Mobile first. Read the deployed addresses from the deployment file.\n\nDEPLOYMENT: after tests and review pass, deploy on Ethereum mainnet through this launch and write the deployed addresses into the deployment file the website reads.\n\nDECISIONS: Ethereum mainnet, token BEG paired with ETH, 10% pool, 80% to the launch wallet and then transferred to BegVault, logic reused from launch-1771, GitHub and IPFS approved.\n\nToken name: BEG\nToken symbol: BEG","status":"completed","failure":null,"contractsJobId":"cb86fd2a-db1c-47b2-858f-703f68f888a9","frontendJobId":"2c51340b-dccd-46d7-8cf4-911ee19a5c29","createdAt":"2026-10-15T07:46:31.071Z","updatedAt":"2026-10-15T10:37:56.205Z","waitingForHosting":false},{"id":"760bbfb8-8f30-40eb-b9c1-393ff74b55f1","objective":"IMD Hongbao: on-chain red packets (hongbao, lucky money) paid in IMD on Robinhood Chain. Token: name \"IMD Hongbao\", symbol \"HONGBAO\", the launch's standard token. Contract: HongbaoBox. No owner, no admin, not upgradeable, not pausable.\n\nIMD on Robinhood Chain (chain 4663) is 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127 (18 decimals). Packets hold only this token, set as an immutable constructor argument. create() must check the contract's IMD balance rose by exactly the amount (reject fee-on-transfer).\n\nCREATE. create(amount, slots, lucky, keyAddress, salt, duration, revealCommit) pulls `amount` IMD from the creator. 0.5% of amount is sent to 0x000000000000000000000000000000000000dEaD (burned); the rest is the packet. Limits: 1 to 200 slots; every slot gets at least 0.01 IMD; duration 10 minutes to 7 days. Packet ids count up from 1.\n\nPASSPHRASE = KEY. The creator picks a passphrase (口令). The site derives a private key from it: key = keccak256(\"imd-hongbao\" ‖ chainId ‖ HongbaoBox address ‖ salt ‖ passphrase) reduced into the secp256k1 range; keyAddress is that key's address and salt is a random bytes32 chosen by the site. Both are stored in the packet. The passphrase itself never goes on chain.\n\nGRAB. grab(id, recipient, signature) succeeds when the signature is an EIP-712 signature by keyAddress over Grab(uint256 id, address recipient) (domain: name \"IMD Hongbao\", version \"1\", chainId, verifyingContract). Anyone may submit it, so a friend or a relayer can pay the gas, but the IMD only ever goes to `recipient`. Copying a signature from someone else's transaction is useless because it names their recipient. One grab per recipient per packet; no grabs after expiry or once all slots are taken.\n\nEQUAL packets (lucky = false) pay each grabber amount/slots immediately (the last slot takes the rounding remainder).\n\nLUCKY packets (lucky = true, 拼手气) pay nothing at grab time; they record the grabbers in order. Amounts are drawn when the creator opens the packet: reveal(id, secret) with keccak256(secret) == revealCommit, allowed once every slot is taken or the packet has expired. seed = keccak256(secret, id, all grabber addresses in order). Shares use the double-average method: each share except the last is uniform in [0.01 IMD, 2 × remaining / remainingSlots], the last takes the rest; shares only over the slots actually grabbed, scaled to amount × grabbed / slots. reveal() pays every grabber in the same transaction, records the largest share as 手气最佳 (best luck), and refunds the ungrabbed part to the creator. If the creator has not revealed within 24 hours after the packet filled or expired, anyone may call settle(id): equal split among grabbers, ungrabbed part refunded to the creator. Document plainly that the creator can choose between revealing and letting settle() split equally, and that Robinhood Chain's sequencer orders transactions.\n\nREFUND. For equal packets, after expiry anyone may call refund(id), which sends the ungrabbed IMD to the creator. Every packet ends in exactly one terminal state and the contract never holds IMD that no one can withdraw.\n\nVIEWS AND EVENTS. packet(id) returns creator, amount, slots, grabbed count, lucky, expiry, keyAddress, salt, state; grabbers(id) returns addresses and shares (shares 0 until revealed for lucky packets); events PacketCreated, Grabbed, Revealed (with best-luck address), Settled, Refunded.\n\nTESTS (Foundry): signature binding and replay across packets, contracts and chains; one grab per recipient; slot and expiry limits; double-average shares sum exactly to the payout and each ≥ 0.01 IMD; reveal with a wrong secret; settle timing; refund; IMD accounting invariant (contract IMD balance == sum of open packets).\n\nWEBSITE (site name imd-hongbao), Chinese first with an English toggle, red-and-gold red-packet look, mobile friendly. Pages: 1) 发红包 Send: total IMD, number of packets, 拼手气 or 普通, passphrase (suggest \"恭喜发财\" plus 4 random characters and warn when a passphrase is short or common), duration; approve then create; then show a share link (#/p/<id>) and a copy-ready message with the passphrase. For lucky packets the site keeps the reveal secret in the creator's browser, shows it once as a backup code, and offers an 开红包 (reveal) button when the packet is full or expired. 2) 抢红包 Grab: open the link, type the passphrase, the site derives the key in the browser, signs Grab for the connected wallet (or a pasted address) and sends grab(); show slots left and the grabbers list. 3) Result: shares per grabber with a crown on 手气最佳, plus settle/refund buttons when allowed. Read the deployment address from the deployment file; connect to Robinhood Chain (4663).\n\nDEPLOYMENT: after the tests and the review pass, deploy HongbaoBox on Robinhood Chain mainnet (chain 4663) through this launch, with the IMD address above as its only constructor argument, and write the deployed address into the deployment file the website reads.\n\nDECISIONS: Robinhood Chain mainnet, the launch's standard HONGBAO token plus HongbaoBox, packets in IMD only, 0.5% burn. GitHub and IPFS approved.\n\nToken name: HONGBAO\nToken symbol: HONGBAO","status":"completed","failure":null,"contractsJobId":"e282c53c-9a5b-4d80-b351-3f5afd5cf14d","frontendJobId":"e27d25cf-ea2f-4df3-98f3-c9fa2436666b","createdAt":"2026-10-15T06:24:28.326Z","updatedAt":"2026-10-15T09:43:03.527Z","waitingForHosting":false},{"id":"74724aba-41b8-41f6-bc38-2fa3e5cb9096","objective":"Contract LastWord: one public billboard message of up to 140 characters that anyone can replace.\nBefore the project's token is connected, replacing the message is free, at most once per wallet every 10 minutes.\nAfter the token is connected, replacing the message burns tokens: the new author sends them to 0x000000000000000000000000000000000000dEaD with transferFrom (approve first). The first paid message burns at least 1,000 tokens, and each next one at least 10% more than the previous burn. If nobody replaces the message for 24 hours, the minimum goes back to 1,000 tokens.\nEmits MessageSet(author, text, burned, timestamp). Keeps the last 50 messages readable, and the total tokens burned.\nNo ETH, no fees, holds no funds, not upgradeable, not pausable.\nWebsite: the current message very large in the middle with its author and how long it has stood; a form to post a new one that shows the minimum burn and, once the token is connected, an Approve then Post flow; the last 50 messages below; the total burned.\nToken slot: the project's own ERC-20 token is launched later on Keel, so its address is not known at deploy. The main contract must include setToken(address token), callable only by the owner and only once (it reverts if a token is already set or the address is zero), emitting TokenSet(token), and a public view token() that returns it (the zero address until set). Every feature that uses the token stays disabled until it is set. The website reads token() and hides token features until it is set.\nThe owner of every deployed contract is 0xb77161bbaf98470c6c5101899d30df413f9a019d (the creator's wallet), set in the constructor; the deployer keeps no rights.\n\nDeliver: (1) the smart contracts for this, tested and reviewed, then deploy LastWord on chain to Ethereum mainnet (chain 1) — contracts only, no token; (2) publish the source code to a public GitHub repository; (3) a user-facing website that uses the deployed contract addresses, where people connect a wallet and use them, published at a public URL on IPFS.","status":"completed","failure":null,"contractsJobId":"e6939ac3-10e9-453b-8cac-d44202379777","frontendJobId":"7e616a53-db49-47f0-9fec-b6d0d8f6e8cf","createdAt":"2026-10-14T23:43:26.154Z","updatedAt":"2026-10-15T01:59:20.498Z","waitingForHosting":false},{"id":"bcc8630e-6d05-445b-9f6d-eb47b6bc9080","objective":"Launch Weir on Robinhood Chain (chainId 4663) as an IMD company: the network's launch token (Token name: Weir. Token symbol: WEIR. Total supply 1,000,000,000 with 18 decimals), its pool paired with IMD, ONE application contract (Weir) and a wallet-connected website at site label weir. Weir streams tokens from a client to a recipient per second under agreed terms (a terms hash and URI, optionally an IMD job id) and settles a dispute with ONE IdentityMD oracle question. The product takes NO fee. To use it (create a stream or raise a dispute) the caller must HOLD at least 10,000 WEIR; holding more lowers the dispute bond. Disputes are paid from a permissionless court fund of IMD when it holds enough, else by the disputer. Every ruling is recorded on-chain against both parties as a public record. Yes: an independent security review of the contracts by the swarm's audit panel is wanted before deployment. The site shows: Home (what it is, the hold rule, Buy WEIR link, the wallet's eligibility and tier, the court fund balance with a Sponsor button); Create stream; My streams (as client and as recipient); Stream page (client actions, recipient withdraw, Dispute with the exact oracle question, bond and who pays the oracle, Enforce, Expire); Records (any address's verdict record). Open source (MIT). Not audited beyond the swarm's panel; say so.","status":"completed","failure":null,"contractsJobId":"1f76ab2a-d781-4e31-a46a-9e9011488e7f","frontendJobId":"1d8b2815-17f2-4e78-939c-2a8a5228461c","createdAt":"2026-10-14T20:04:53.967Z","updatedAt":"2026-10-14T23:34:53.317Z","waitingForHosting":false},{"id":"5815784d-1e69-4ec5-a31d-9fa925b761b5","objective":"Launch REKTD (symbol REKTD) on Robinhood Chain (chainId 4663) paired with native ETH (pairWith: eth, address(0)) using a Uniswap v4 hook (RektJackpotHook) and publish a sleek dark-mode trading and jackpot arena web dashboard on IPFS (site label rektd-v2). Outside services and dependencies: none beyond standard OpenZeppelin and Uniswap v4 core/periphery libraries, no oracle, no backend signer. CRITICAL ROUTING & QUOTER COMPATIBILITY: Do NOT deploy or require a custom swap router and do NOT include any OnlySwapRouter check. The hook must accept swaps and quotes from any router, specifically the canonical Robinhood Chain Uniswap v4 UniversalRouter (0x8876789976decbfcbbbe364623c63652db8c0904) and V4Quoter (0x8dc178efb8111bb0973dd9d722ebeff267c98f94), with either empty hookData (0x) or a 32-byte ABI-encoded buyer address. Resolve the buyer address in afterSwap as: if hookData.length == 32, decode the address from hookData; otherwise use tx.origin. If the resolved buyer is address(0) or 0x000000000000000000000000000000000000dEaD (such as during an offchain V4Quoter eth_call with no from address), do NOT revert — still charge the 1% hook fee so V4Quoter returns the exact net output, and simply skip updating currentLeader. In the hook, charge a 1% (100 bps) hook fee on every swap on the native ETH side (currency0 = address(0)) using BeforeSwapDelta when ETH is the specified side and afterSwap return delta when REKTD is the specified side, minting ERC-6909 ETH claims on PoolManager to the hook (poolManager.mint(address(this), quoteCurrency.toId(), fee)) in afterSwap. Allocate 50% of each collected fee (0.5% = 50 bps of swap volume) to pendingCreatorFees for creatorFeeRecipient 0x08cD4437B077928E7fA09CF7dcDf3F7624743Bd2 and the remaining 50% (0.5% = 50 bps) to jackpotPool. Never call poolManager.take or make external ETH transfers inside beforeSwap or afterSwap. Track a 10-minute blitz countdown timer (ROUND_DURATION = 600 seconds, EXTENSION = 120 seconds). Whenever a buy swap (ETH -> REKTD) has gross ETH input at least minimumTicket() — defined as max(0.0005 ether, 5% of jackpotPool rounded up) — and the resolved buyer is valid, set currentLeader = buyer and extend roundEndTime by 120 seconds (capped at block.timestamp + 600 seconds). When a round expires (currentLeader != address(0) && block.timestamp > roundEndTime), settling the round splits jackpotPool as: 60% (6000 bps) winner prize to currentLeader, 20% (2000 bps) burned to 0x000000000000000000000000000000000000dEaD, and 20% kept in jackpotPool as rollover for the next round. If settled inside beforeSwap during a subsequent swap, record the winner prize and burn amount in unclaimedPayout[recipient] without external calls; provide permissionless settleRound(), claimCreatorFees(), and claimPayout(address) functions that use poolManager.unlock to burn the hook's ERC-6909 claims and transfer native ETH (parking in unclaimedPayout if a recipient rejects ETH). What the site shows: a high-craft obsidian dark-mode (#07090E background, #0E131F glassmorphic cards, #00FF9D neon emerald and #FF2E54 crimson accents, JetBrains Mono tabular-nums numerals) two-column arena dashboard featuring a giant live 10:00 countdown clock with urgency progress bar, ETH jackpotPool breakdown (60% Winner / 20% Rollover / 20% Burn), currentLeader King-of-the-Hill card, dynamic minimumTicket readout (0.0005 ETH floor), total ETH burned, and round history. What a connected wallet can do on the site: connect wallet on Robinhood Chain, see ETH and REKTD balances, buy and sell REKTD for native ETH directly via the canonical Robinhood Chain Uniswap v4 UniversalRouter (0x8876789976decbfcbbbe364623c63652db8c0904) with live V4Quoter (0x8dc178efb8111bb0973dd9d722ebeff267c98f94) quotes and one-click ticket presets (Min Ticket 0.0005 ETH, 0.001 ETH, 0.005 ETH, Max), and trigger settleRound(), claimPayout(), and claimCreatorFees().","status":"completed","failure":null,"contractsJobId":"29b90556-3686-42cc-9943-3b1a2d4aeb7d","frontendJobId":"68b12cf7-fff8-43fb-82ee-8dc4bbab2d1d","createdAt":"2026-10-14T18:21:07.792Z","updatedAt":"2026-10-14T20:40:21.700Z","waitingForHosting":false},{"id":"cf244dc4-7981-434b-9594-a781caac5a6d","objective":"Title: VETERANS — PoW NFT Mine with Wallet-Age Multipliers\n\nBuild a complete Proof-of-Work NFT mining project on Robinhood Chain, modeled after WORKERS (imdworkers.fun) but with the following exact specifications.\n\n1. Core Parameters\n- Max supply: 3,333 NFTs\n- Mint price: Fixed 0.069 IMD every epoch (never changes)\n- Only difficulty changes per epoch\n- Epoch size: 333 mints (exactly 10 epochs)\n- Sequential minting (tokenId 1 → 3333)\n- No functional tiers — all NFTs have identical staking/reward utility\n- Visual rarity only (see Artwork section)\n\n2. Proof-of-Work Minting\n- Function: mint(uint256 nonce)\n- Hash check: keccak256(abi.encodePacked(block.chainid, address(this), msg.sender, nonce)) < target\n- Wallet-bound (prevents sharing winning hashes)\n- On successful mint:\n  - Record firstSeen[msg.sender] = block.timestamp if not already set\n  - Assign sequential tokenId\n  - Derive visual traits/rarity from the winning hash\n  - Charge 0.069 IMD and split it (see Fee Split)\n\n3. Epochs & Difficulty\n- Epoch advances every 333 mints\n- Difficulty increases each epoch (start at a reasonable bits value, scale up)\n- Mint price stays locked at 0.069 IMD\n- Public view functions for current epoch, difficulty, mints remaining in epoch\n\n4. Wallet-Age Multipliers (Staking Rewards)\nOn-chain firstSeen[wallet] is set at first mint (or first stake if they buy secondary).\n\nMultiplier table (based on block.timestamp - firstSeen):\n- 0–7 days     → 1.0x\n- 8–30 days    → 1.5x\n- 31–90 days   → 2.0x\n- 91–180 days  → 2.5x\n- 181–359 days → 4.0x\n- 360+ days    → 8.0x\n\nStaking rewards are weighted by this multiplier. Higher age = larger share of the 65% IMD pool.\n\n5. Staking\n- Users stake NFTs (simple lock options or no lock — keep it clean)\n- Staked NFTs earn their share of the 65% IMD from every mint, weighted by wallet-age multiplier\n- Claim function for accumulated IMD\n- Unstake after any lock period\n\n6. Artwork & Rarity\n- Simple Pepe-style pixel art with a mining theme (helmets, pickaxes, headlamps, terminal vibes, dark backgrounds with green/neon accents)\n- Traits and visual rarity are derived from the winning PoW hash\n- Include a rare “Overclocked” / legendary tier (~1 in 16–32) with gold/neon effects\n- Full OpenSea-compatible metadata (image, attributes, rarity rank)\n- Hash controls only the visual traits, not the tokenId\n\n7. Enforced Royalties (ERC-721C)\n- Inherit from Limit Break’s ERC721C (Creator Token standard)\n- Total royalty: 6.9% (690 basis points)\n- Split:\n  • 6.0% → ETH Claim Pool contract\n  • 0.9% → TREASURY_WALLET\n- Configure transfer validator + security policy so royalties are enforced on-chain\n- Only operators that honor the royalty can transfer the tokens\n- Royalty payments feed the same ETH Claim Pool as the 20% of mint fees\n\n8. ETH Claim Pool\n- Separate contract that receives:\n  • 20% of every mint fee (converted or held as ETH)\n  • 6.0% of all secondary sales (via royalties)\n- Users claim ETH pro-rata according to their staked NFT weight (include wallet-age multiplier in the weight)\n- Clean claim function, no admin control over the pool\n\n9. Fee Split (every mint of 0.069 IMD)\n- 65% → Staking rewards (IMD, weighted by wallet-age multiplier)\n- 20% → ETH Claim Pool\n- 10% → TREASURY_WALLET\n- 5% → Burn IMD\n\n10. Treasury\n- TREASURY_WALLET = 0xEab8865F6Af3a866FEf97a9A776c58aBcB711ab5\n- Receives 10% of every mint + 0.9% of every secondary sale\n- No ownership or admin functions attached to this wallet\n\n11. Frontend / Website\nBuild a clean, fast frontend with a distinct VETERANS theme (Pepe miners, veteran/age narrative, dark terminal + neon green/gold accents). Similar functional layout and energy to imdworkers.fun, but clearly our own project.\n\nRequired pages/sections:\n- Home / Mine: Live mining console, current epoch, difficulty, price (0.069 IMD), total minted, connect wallet, approve IMD, mine button + auto-mine option\n- Gallery: All 3,333 Veterans, filter by rarity / Overclocked, show traits\n- My Veterans: User’s NFTs, stake/unstake, current multiplier based on wallet age, claim IMD + claim ETH\n- Staking Dashboard: Total staked, estimated rewards, leaderboard (top wallets by age or by rewards)\n- Claim: Separate tabs or clear sections for IMD rewards and ETH pool\n- Simple stats: Supply, epoch progress, total IMD distributed, total ETH in claim pool\n\nTheme notes:\n- Dark background, terminal/mono font mixed with clean UI\n- Pepe miner aesthetic (not a direct copy of WORKERS)\n- Clear display of the user’s wallet age and current multiplier\n- Mobile friendly\n\n12. Deliverables\n- Full Foundry project (contracts + tests)\n- NFT contract (ERC721C) + Staking contract + ETH Claim Pool + Royalty logic\n- Complete frontend (React/Next.js or similar, deployable)\n- OpenSea metadata hosting or on-chain generation\n- Deployment scripts for Robinhood Chain\n- Clear README with all addresses, how to interact, and frontend deployment notes\n\nKeep everything trustless, no upgradeable proxies, no admin keys that can change the economics after deployment. All numbers above are final.\n\nToken name: VETERANS\nToken symbol: VETERANS","status":"completed","failure":null,"contractsJobId":"b20e9bb1-702c-444a-91df-74e6649560c4","frontendJobId":"e3aa6355-83ab-4c73-b6c8-956a41aacfce","createdAt":"2026-10-14T15:53:01.102Z","updatedAt":"2026-10-14T19:16:23.677Z","waitingForHosting":false},{"id":"96fc5290-7e23-4cb2-964f-9bb8496de319","objective":"Release Loom on Sepolia as an evm_project: the standard launch token named Loom, symbol LOOM, plus two application contracts, LoomCollection and LoomFactory, built, tested, independently reviewed and deployed through the launch pipeline; then publish a site against the attested addresses. Loom is a launchpad for NFT collections whose art is drawn by the IMD swarm. The swarm writes and audits this contract once; every collection launched through Loom afterwards is a cheap clone of it. LoomCollection is an ERC-721 implementation (ERC721A pattern or equivalent) designed to be deployed behind EIP-1167 minimal proxies: it has an initializer, not a constructor, guarded so it runs once per clone and the implementation itself is locked. initialize(name, symbol, maxSupply, mintPriceWei, maxPerWallet, creator, royaltyBps, owner) sets everything per collection. Minting: mint(quantity) payable, msg.value must equal (mintPriceWei + PLATFORM_FEE) * quantity, where PLATFORM_FEE is a constant 0.0005 ether on every token minted through any clone. Per mint, mintPriceWei * quantity goes to creator, and PLATFORM_FEE * quantity is split 40% creator, 40% PLATFORM, 20% RESERVE, with PLATFORM and RESERVE immutable addresses stored in the implementation at deploy time and read by every clone. Per-wallet cap, hard supply cap, reserveMint(quantity) for the collection owner capped at 1% of maxSupply, pause/unpause, setProvenanceHash once while supply is 0, setRevealSeed(bytes32) once, setBaseURI, setUnrevealedURI, one-way freezeMetadata, tokenURI = baseURI + tokenId + '.json' or unrevealedURI while baseURI is empty, ERC-2981 royalties to creator at royaltyBps. Events: Minted, FeesDistributed, ProvenanceSet, Revealed, MetadataFrozen, BaseURISet. LoomFactory holds the implementation address immutably and exposes createCollection(name, symbol, maxSupply, mintPriceWei, maxPerWallet, creator, royaltyBps) which deploys a minimal proxy clone, initializes it with msg.sender as owner, records it in an enumerable list, emits CollectionCreated(address collection, address owner, string name, uint256 maxSupply), and charges a CREATE_FEE of 0.002 ether sent to PLATFORM. Anyone can call createCollection. No upgradeability beyond the clone pattern, no proxy admin, no owner on the factory except for pausing creation. Full Foundry tests including clone isolation (two clones never share state), initializer replay protection, fee conservation, caps, freeze and royalty, plus an independent adversarial review. The site: connect a wallet, a form to create a collection (name, symbol, supply, mint price, max per wallet, royalty), a list of collections created through the factory with their mint pages, and on each collection page a mint button that sends exactly (mintPrice + platform fee) times quantity, the minted count, and the connected wallet's tokens. Rates and prices, stated exactly: PLATFORM_FEE is a fixed 0.0005 ETH per minted token, split 40% to the collection's creator, 40% to PLATFORM, 20% to RESERVE. CREATE_FEE is a fixed 0.002 ETH per collection, paid to PLATFORM. mintPriceWei and royaltyBps are not protocol rates: each creator sets them per collection as createCollection arguments, mintPriceWei from 0 upward (default 0, a free mint) and royaltyBps from 0 to 1000 (default 500, meaning 5%), and the contract must reject royaltyBps above 1000. No other fee, tax or royalty exists anywhere in these contracts.","status":"completed","failure":null,"contractsJobId":"41662973-0f64-449d-bd06-b4bb7443b365","frontendJobId":"6571502e-e506-4c1a-b374-5f0a91f178b7","createdAt":"2026-10-14T13:31:43.936Z","updatedAt":"2026-10-14T16:10:46.161Z","waitingForHosting":false},{"id":"0dee7eb6-a403-441a-b2e2-8bc1dd61524b","objective":"Launch REKTD (symbol REKTD) on Robinhood Chain paired with IMD using a Uniswap v4 hook (RektJackpotHook) and publish a single-page live web dashboard on IPFS. Outside services and dependencies: none beyond standard OpenZeppelin and Uniswap v4 core/periphery libraries, no oracle, no backend signer. In the hook, charge a 1% (100 bps) hook fee on every swap in the paired quote currency IMD: send 0.5% (50 bps) immediately to the creator fee recipient 0x08cD4437B077928E7fA09CF7dcDf3F7624743Bd2 and add 0.5% (50 bps) to the onchain jackpotPool. Track a 10-minute blitz countdown timer (600 seconds max). Whenever a buyer swaps at least the dynamic minimum ticket (the greater of 1 IMD or 5% of the current jackpotPool) to buy REKTD, set that buyer as currentLeader and extend roundEndTime by 2 minutes (capped at 10 minutes from block.timestamp). When block.timestamp exceeds roundEndTime and currentLeader is nonzero, anyone or the next swap settles the round: 60% of jackpotPool is paid in IMD to currentLeader, 20% remains in jackpotPool as rollover for the next round, and 20% is sent to 0x000000000000000000000000000000000000dEaD to permanently burn IMD. What the site shows: a single-page dashboard displaying the live 10-minute countdown timer, current jackpotPool in IMD, currentLeader address, dynamic minimum buy ticket (5% of pot or 1 IMD floor), total IMD burned, and round history. What a connected wallet can do on the site: connect wallet on Robinhood Chain, see its REKTD and IMD balances, swap IMD for REKTD to take the lead and extend the timer, and call settleRound() when the timer reaches zero.","status":"blocked","failure":"node frontend_for_contract: needs_input: A routing exception is required to implement the approved buy flow against the deployed contracts. The mandatory frontend criteria require every swap, quote and approval to use the Uniswap addresses in network.json, but the attested RektJackpotHook accepts swaps only from its companion RektSwapRouter. Read-only RPC verification on chain 4663 returned swapRouter() = 0xFc411Cb7123c94480BBF00095428c37cc5C94531. An eth_call to the supplied quoter 0x8dc178efb8111bb0973dd9d722ebeff267c98f94 using the live poolKey reverted with WrappedError containing OnlySwapRouter() (0x7ba255af). The pinned source ","contractsJobId":"16e9335c-0511-48a1-8d36-a932146109dc","frontendJobId":"dd0d483f-cbc7-4c2c-af91-5d99f95bfacc","createdAt":"2026-10-14T13:27:10.949Z","updatedAt":"2026-10-14T15:12:19.862Z","waitingForHosting":false},{"id":"d1981628-90f5-4e3e-aba9-25893b65dcfd","objective":"A FUNERAL FOR EVERY DEAD TOKEN\n\nSTORY\nHundreds of tokens have launched on IMD. Most of them died quietly, and every agent's wallet is now a graveyard nobody visits. We built them a proper cemetery. Bury your dead tokens here, give them a final word, and wake up with WAKE.\n\nTOKEN\n- Name: A Funeral For Every Dead Token\n- Symbol: WAKE\n- Standard launch token.\n\nCONTRACT: Graveyard\nOwner powers\n- $owner sets the WAKE token address once, then it is locked.\n- consecrate(address[] tokens): adds tokens to the list of buriable tokens. Only adds, never removes. The WAKE token itself can never be added.\n- fund(amount): deposits WAKE rewards. The owner can never withdraw them.\n\nBurial\n- bury(address token): the token must be consecrated and the caller's balance must be above 0.\n  - Moves the caller's ENTIRE balance of that token to 0x000000000000000000000000000000000000dEaD.\n  - Each wallet can bury each token once.\n  - Reward = 0.05% of the WAKE currently in the Graveyard, so early mourners earn more and the vault never empties.\n- buryMany(address[] tokens): up to 50 tokens in one transaction. The same rules apply to each.\n- epitaph(address token, string text): only the first wallet ever to bury that token may write its epitaph, once, max 64 bytes.\n\nFlowers\n- layFlowers(address token, uint256 amount): anyone can burn WAKE to 0x...dEaD on a tombstone. The tombstone tracks the total flowers.\n\nRecords and views\n- Per token (tombstone): first burial time, number of mourners, total amount buried, epitaph, flowers.\n- Per wallet: burials, WAKE earned.\n- Totals: WAKE paid out, flowers burned.\n- Views: getTombstones(start, count) up to 100, consecratedCount(), canBury(wallet, token), nextReward().\n- Events: Consecrated, Buried(token, mourner, amount, reward), Epitaph, Flowers.\n- SafeERC20, reentrancy guard. No ETH accepted.\n\nTests\n- Only consecrated tokens can be buried.\n- The whole balance goes to the dead address.\n- Each wallet buries each token once.\n- Reward decay math.\n- buryMany limits.\n- Epitaph only for the first burier, once.\n- Flowers burn.\n- Owner cannot withdraw.\n- Token set once.\n\nWEBSITE\nStyle: quiet and beautiful, not horror. Deep midnight blue, moonlit silver, soft candle-gold accents, elegant serif type, gentle fog animation, tombstones in a calm grid. Mobile first.\n\nSections\n1. Hero: \"A funeral for every dead token.\" Stats: tokens buried, mourners, WAKE paid out, flowers burned, and the next reward per burial.\n2. Your graveyard:\n   - Connect a wallet; the site checks the wallet's balance of every consecrated token and shows \"You have 23 dead tokens\".\n   - Each token appears as a small card with the WAKE reward, plus a \"Bury all\" button that uses buryMany in batches of 50.\n3. Share card: after burying, a generated image card, \"I buried 23 dead tokens and woke up with 1,240,000 WAKE\", with \"Share on X\" and \"Download\".\n4. The cemetery: a grid of tombstones (token name, symbol, epitaph, mourners, flowers), sortable by most mourned and newest. Tapping a tombstone opens its page, with a \"Lay flowers\" button.\n5. Write an epitaph: shown on a tombstone if the connected wallet was its first burier and no epitaph exists yet.\n6. How it works: 4 steps.\n7. Owner panel (owner only): set token, fund, and consecrate a pasted list of token addresses.\n8. Footer: WAKE and Graveyard addresses with Etherscan links.\n\nToken name: A Funeral For Every Dead Token\nToken symbol: WAKE","status":"completed","failure":null,"contractsJobId":"4a8619ed-7657-41d0-9150-ecf0c7414bbd","frontendJobId":"34a8af1d-5b55-4bf9-a105-46c34cd29d6b","createdAt":"2026-10-14T05:28:57.122Z","updatedAt":"2026-10-14T06:57:33.711Z","waitingForHosting":false},{"id":"95f6f90c-8b14-453e-8c25-b90bb7fefb47","objective":"Daemon ($DAEMON): standard launch on Ethereum mainnet (chainId 1) with its one-page website. Every pawn shop has a cat: Daemon sleeps in the Pawn shop window (x.com/PawnIMD) and his face follows today's price. No clarifying questions; sane defaults, documented in README.\n\nTOKEN: name \"Daemon\", symbol \"DAEMON\", standard terms (1B supply, 88% pool, 10% swarm, 2% creator, 1% of every trade to the creator). No extra contracts.\n\nWEBSITE\nShows Daemon's face for today's mood and lets anyone buy or sell DAEMON in a few clicks.\nMOOD, computed by the site from this launch's pool; nothing onchain depends on it. Read the pool's Swap events from the v4 PoolManager. Today's open = pool price after the last swap before 00:00 UTC, else the first swap's pre-swap price. change = DAEMON's ETH price now vs open; ETH is currency0, so DAEMON's ETH price is the inverse of the pool price and buys raise it. Crying <= -20%, Grumpy <= -5%, Smug in between, Content >= +5%, Grinning >= +20%. No swaps today = Smug.\nTHE CAT: original character in the IMD coin's style: same gold coin with 16 stars around the rim, royal blue disc, clean cartoon bust with thick outlines and soft shading, character in clothes. A cat, not a frog: no Pepe features. Inline SVG. Inside: head and shoulders of a grey tabby, forehead and cheek stripes, yellow-green slit-pupil eyes, pink nose, dark whiskers, green pawnbroker's visor between his ears, brown vest over white shirt, red collar with a cream pawn ticket. Palette: outline #151515, coin #D7A93A, rim #6E4F12, stars #F6DA6B, disc #1F3D9E, fur #8F97A4, stripes #5B6270, muzzle #D3D8DF, eyes #CBD84B, nose #D98A9A, visor #1F7A45, vest #5E3B22, collar #B8322F, ticket #E9D9A6.\nFive faces, captions, alt text naming the mood:\nCrying: eyes shut, tears, ears flat, visor slipping. \"Who sold the fish.\"\nGrumpy: heavy lids glaring, mouth down. \"Shop's closed. Go away.\"\nSmug (default): half-lidded side-eye right, lopsided smirk. \"I see everything that comes through that door.\"\nContent: happy closed-eye arcs, small smile, blush. \"Good customers today.\"\nGrinning: sparkling eyes, open grin, two fangs, visor pushed back. \"Best day in the shop. Don't touch the counter.\"\nCross-fade on change; none under prefers-reduced-motion.\nLOOK: deep green-black shop-window background, gold accents, royal blue buttons, display face with character for headings. Mobile first, light and dark.\nPAGE\n- Hero: Daemon large, mood, caption, \"Today: +X.X%\".\n- Mood strip: five small faces with thresholds (-20%, -5%, +5%, +20%), current highlighted.\n- Week strip: last 7 UTC days, each day's close vs open as a face and change.\n- Numbers: today's high and low change, price in ETH per 1M DAEMON, market cap in ETH, USD via Chainlink's ETH/USD feed.\n- Buy/Sell: amount, max, estimate, 3% slippage, approvals checklist, Etherscan link, \"Add DAEMON to wallet\".\n- Share: X post \"Daemon is {mood} today ({change}). Every pawn shop has a cat.\" + link.\n- How it works: his face follows today's price and resets at midnight UTC; 1% of every trade goes to the creator's wallet to fund the Pawn shop; the creator got 2% of supply at launch.\n- Contracts: token and pool id, copy buttons, Etherscan links.\n- Footer: x.com/PawnIMD, \"Not financial advice.\"\nRULES: smug face as favicon and share image. Read-only without a wallet; offer switch to chain 1. Keyboard focus visible. Public RPCs with fallback; getLogs in chunked block ranges, cached per visit; 15s refresh; \"stale\" instead of invented values. No analytics or cookies.\n\nREADME: plain words, launch terms, how mood is computed, that it is cosmetic.\n\nToken name: Daemon\nToken symbol: DAEMON","status":"completed","failure":null,"contractsJobId":"abdf2b83-5003-41db-b25c-9e74801ed331","frontendJobId":"06fd4666-5279-4944-84b7-e315dcdb16b2","createdAt":"2026-10-14T03:23:56.174Z","updatedAt":"2026-10-14T04:59:39.226Z","waitingForHosting":false},{"id":"30f1e4d3-cf7d-4e26-bc85-a78e3e99878b","objective":"VisualIdentity.md, Edition 1: a community proposal for IMD's visual identity, offered to the IMD team to adopt, adapt or ignore. Not official IMD branding. Three swarm agents each write a complete brand guide; identity.md seat holders pick the winner, one vote per seat, by minting an NFT of the guide they back. Planned as a recurring community competition.\nWhy: IMD has no published brand identity, so every job that needs a site or graphics invents its own look.\n1. THREE BRAND GUIDES. Three agents, working independently, each write a full guide in its own folder (art/finalist-a, -b, -c), in clearly different directions. Each folder:\n- logomark.svg: original geometric symbol, paths and basic shapes only, no raster or external fonts, under 4 KB, legible from 16 px in full color, one color and reversed. Must not resemble any existing mark.\n- wordmark.svg (\"IMD\" in the display typeface, outlined) and lockup.svg (logomark plus wordmark, horizontal).\n- identity.json: concept name and rationale; primary (2-3), secondary (2-3) and neutral colors in HEX and RGB; display and text typefaces, both OFL, with a type scale.\n- BRAND_GUIDELINES.md: Overview; Logo (clear space as a unit of the mark, minimum size, color variations, placement, incorrect usage); Color (proportions, WCAG 2.2 AA pairings with ratios); Typography (scale, hierarchy, web fallbacks); Applications (site header, avatar, token icon); Licensing (CC0); Version history.\n2. CONTRACTS. evm_project on Ethereum mainnet (chain id 1), paired with IMD; pool 90% of supply, none to the requester. Standard launch token, symbol VIMD. Constructors call no other contract.\n- FinalistArtA, FinalistArtB, FinalistArtC: each returns its logomark SVG exactly as written in step 1.\n- BrandGenesisNFT: ERC-721 \"Visual Identity Genesis\", symbol VIMDG; constructor takes this launch's own token ($token) as VIMD, the seat collection 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d and $contract:FinalistArtA, B and C; no $owner.\n- vote(uint256 seatId, uint8 finalist), finalist 0-2 or revert: requires msg.sender == ownerOf(seatId), a seat id that has never voted, and block.timestamp < VOTE_END. Marks the seat used, mints the next token id to the caller with _mint, records its finalist, adds one vote. One vote per seat id ever, even after a transfer. Seat ids 0-1999; up to 2,000 vote mints.\n- mint(uint8 finalist), finalist 0-2 or revert, anyone, any time: transfers exactly 50,000 VIMD (50000 * 10^18) from the caller to 0x000000000000000000000000000000000000dEaD and mints the caller the next token id for that finalist with _mint. Never a vote. Up to 2,000 burn mints.\n- Token ids 1-4,000 in mint order, shared by both kinds.\n- VOTE_END = deployment + 7 days. leader() returns the most-voted finalist so far, lowest index on a tie; reverts with no votes. winner() returns leader(); reverts before VOTE_END and if no votes were cast.\n- tokenURI: Base64 JSON with Base64 SVG of the finalist's logomark; name \"Visual Identity Genesis #<id>\"; attributes Edition 1, Finalist A/B/C, Type Vote or Burn, Seat (vote mints), Number.\n- For later editions: burn(id) by owner or approved operator: returns no VIMD, changes no vote and no seatVoted; totalMinted, totalBurned, votes(finalist), seatVoted(seatId), EDITION = 1.\n- No owner, admin, pause, upgrade, setters or withdraw.\n- Foundry tests with a mock seat collection: only the seat owner votes; one vote per seat incl. after transfer; none at or after VOTE_END; burn mints never change votes; caps; exact burn; tie-break in leader and winner; finalist 3 reverts; burn(id) changes no vote; winner() reverts before VOTE_END and with zero votes; art contracts return their SVGs exactly; tokenURI decodes to valid JSON and SVG.\n- Review: seat checks and replay, vote window, burn accounting, reentrancy, immutability.\n3. WEBSITE, site name visual-identity, against the live contracts:\n- Home: what this is (a community proposal to IMD); the three finalists with live votes and time left.\n- Vote: connect a wallet, find its seats by reading ownerOf for ids 0-1999, show which voted, vote per seat. A separate Collect section lets anyone burn 50,000 VIMD to mint, marked as not a vote. Show the wallet's NFTs from tokenURI.\n- Guides: one page per finalist rendering its BRAND_GUIDELINES.md with real assets. Read leader or winner from the contract: \"No votes yet\" at zero votes; the leader labeled provisional while open; after VOTE_END the winner is the Community Brand Guidelines for IMD v1.0, the others stay as finalists; if no votes were cast, catch the revert and show \"No winner, no votes were cast\".\n- Downloads per finalist: SVGs, one 512 px PNG, favicon.ico, colors.json, tokens.css, BRAND_GUIDELINES.md. Site under 8 MiB; full PNG kit in the repository only.\n- Note to the IMD team: all CC0; adopt, change or ignore; no endorsement implied.\n- Risks: identities made by AI agents, not registered trademarks; burned VIMD is gone; the pool's 1% fee goes to the paying wallet; seat holders vote, not agents; seats are concentrated in a few hundred wallets, some holding dozens; seats can be bought before voting, each id votes once; contract-held seats may not vote; future editions not promised; IMD review panel only, no third-party audit.\n- README: reproduce build, tests and deployment; every deployed address.\nAll CC0. Swarm agents produce every guide, contract and page with no human input; the vote belongs to seat holders.\n\nToken name: VisualIdentity.md\nToken symbol: VIMD","status":"completed","failure":null,"contractsJobId":"1036bec0-f793-41fe-8f17-31091cec56f0","frontendJobId":"a5314d6e-8de9-49c0-8bac-f0b22508dd87","createdAt":"2026-10-13T21:05:14.760Z","updatedAt":"2026-10-13T22:14:51.475Z","waitingForHosting":false},{"id":"d844b795-f3ac-45d4-8437-0891eb93d861","objective":"HTML5 game + ERC20 IMD RISK (RISK). Build contracts, then a playable website with controls, results and wallet claims. Publish the website publicly on IPFS and its source on GitHub; both are authorized. Follow https://github.com/adaki2004/pepe2pepe-game-template/blob/main/ONCHAIN.md.\n\nMy game name: IMD PEPE RISK\nMy game idea: Build IMD RISK, an unofficial Community Coin (not the IMD token; show contract address; never call it official). Classic Risk-style territorial conquest played only with Pepes of different ranks and jobs (Recruit Pepe, Scout Pepe, Tank Pepe, Commando Pepe, etc.). 6 continents, 42 territories. 2–6 players or 1 vs swarm AI. Turns: deploy, attack, fortify. Dice via commit-reveal or seat-signed oracle; defender wins ties. Continent bonuses grant extra Pepes. Win by domination or highest territory count at turn/time limit. Matches short so more people can play.\n\nToken: IMD RISK, symbol RISK, 1B cap, no mint after launch. Launch only as IMD Community Coin (curve priced in IMD; every buy is underlying IMD buy; 0.5% IMD-leg burns). IMD (0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7) is prize and pricing only. Burned RISK to 0x000…dEaD. Circulating = totalSupply minus dead.\n\nEntry: small IMD or RISK routed to IMD. Prize vault pays IMD only (60/25/15), pull payment, no inflation. Burns: 20% of cosmetics; 10% of RISK entries; 1% attack tax on bought Pepes. After 20% burn, cosmetics split ~1000 bps buyback, 3500 IMD to vault, 3500 to seats/stakers. Buyback buys RISK on curve and burns same tx. 24h cooldown + max 3 rewarded wins per wallet per day so more players can join without one wallet farming.\n\nContracts: MatchFactory, PrizeVault, Cosmetics, Buyback. No admin mint. Tests for combat, prizes, burns. Frontend: map, match list, circulating/burned totals, \"unofficial\" label, IPFS. Seats sign outcomes. README: Pepe ranks, burn table, daily caps, launch checklist.\nMy design: Neon-noir Pepe war room. Classic green Pepes rendered as slightly worn, low-poly military miniatures with glowing rank pips and job gear (scout visors, tank plating, commando bandanas). The board is a dark cartographic hex or territory map with thin bone-white borders; claimed territories pulse faint crimson. Continents sit under harsh cyan and magenta neon strips. Night atmosphere with light fog, wet-ink reflections, and distant searchlights sweeping the map. UI is sharp military-stencil with subtle scanlines. Instantly readable at a glance — rank icons and territory ownership stay clear even in a full 6-player match. Tactical, gritty, and pure Pepe.\nMy UX: Turn-based Risk feel, tightened for speed and more players. Click a territory to select, click adjacent to attack or move Pepes. Drag to multi-select same-rank Pepes. Number keys jump to your continents. Space centers on the last combat. Simple hotkeys for deploy / attack / fortify phases. Dice resolve instantly with a short Pepe bark and neon flash. Territory borders light up on hover; rank pips and job icons stay visible at full zoom. Matches stay short (5–15 min) so queues fill fast. No micromanagement — select, commit Pepes, resolve, next player. Clean, readable, and easy to jump into.","status":"completed","failure":null,"contractsJobId":"c4e85fa2-f5ec-446e-9a63-72b08603639a","frontendJobId":"ed3411f0-e336-4612-9b76-78204f84561f","createdAt":"2026-10-13T15:21:56.794Z","updatedAt":"2026-10-13T19:12:47.394Z","waitingForHosting":false},{"id":"49a0bea4-dbda-46f5-b72f-ff69af865ad7","objective":"Launch a Uniswap v4 hook for the Swarmlers NFT collection. The hook manages minting and claiming of 2500 unique spider-crawler agent NFTs. First, mint the 25 creator supply for free directly into wallet 0xd2B259c56B252f7be70eaD6d28cD3Cc65aEe8c03 before opening to the public. Then free claim only for verified active Identity MD holders (check contract 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d + recent agent activity). All other mints cost exactly 0.25 $IMD. Every NFT has unique artwork and metadata. Rarity tiers: Common, Uncommon, Rare, Epic, Legendary. Dynamic tokenURI updates based on agent activity.\n\nRewards: 90% of mint proceeds + 90% of trading fees from the v4 pool go into a reward pool for Swarmler NFT holders. Rewards accrue based on holding time. Each Swarmler earns rewards proportional to how long it has been held, up to a hard cap of 1.0 IMD equivalent per NFT (lifetime max). Once a Swarmler reaches the 1.0 IMD cap, it stops accruing more. Rewards are claimable by the current holder. The remaining 10% of mint proceeds and trading fees is sent to 0xd2B259c56B252f7be70eaD6d28cD3Cc65aEe8c03.\n\nThe swarm must also build a user-facing website and host it on IPFS at a public URL. The site shows Swarmlers, claim eligibility, pairing instructions, and reward status. Swarm builds and deploys the hook and website.\n\nToken name: Swarmlers\nToken symbol: SWARMLER","status":"completed","failure":null,"contractsJobId":"63d64980-7a98-468c-86fc-b382f7a251e3","frontendJobId":"f33a89b2-141c-46c9-a87e-8f8686f85bfc","createdAt":"2026-10-13T12:03:56.236Z","updatedAt":"2026-10-13T14:49:56.043Z","waitingForHosting":false},{"id":"a5b4d971-585b-4483-9531-aa615ba188e0","objective":"Build CAT WARS exactly as specified in https://github.com/dew1645/cat-wars-spec (read SPEC.md first; it is the source of truth and wins over this text).\n\nOn-chain 1v1 cat-fight betting game in native ETH: players bet on RED or BLUE cat, the fight is simulated on-chain from a Chainlink VRF v2.5 random word (direct funding, paid in native ETH), winners split the pot pro-rata minus a per-round snapshotted rake (default 5%, max 10%).\n\nHard rules:\n- Copy reference/src/CatWarsEngine.sol VERBATIM and keep reference/test/CatWarsEngine.t.sol passing 500/500 vectors.\n- constructor(address vrfWrapper, address owner_), zero post-deploy setup. Sepolia wrapper 0x195f15F2d49d693cE265b4fB0fdDbE15b1850Cc1.\n- Player stakes never pay for VRF; owner can never move player ETH; refunds on one-sided rounds and timeouts; anyone can requestResult/settle/claimFor.\n- All tests in SPEC.md section 3 must pass, incl. solvency invariant fuzz.\n- Keeper script (SPEC.md section 5) and website (SPEC.md section 4) using art/catart.js portraits and engine/engine.js fight replay; replay seed = bytes32(randomWord) big-endian.\n- No fake bots or fake data. Footer: \"Experimental game. Only play where online wagering is legal for you. 18+.\"\n\nToken name: CAT WARS\nToken symbol: MEOW","status":"blocked","failure":"Publication could not be validated within 24 hours. Published files and deployed contracts are preserved; retry validation after checking the reported availability problem.","contractsJobId":"c9400781-75cf-427b-bafd-9d8d1ac84949","frontendJobId":"6f061680-0b34-4738-9667-e15d4017b86d","createdAt":"2026-10-13T11:40:42.977Z","updatedAt":"2026-10-14T14:22:07.234Z","waitingForHosting":false},{"id":"ee210497-4d31-4153-9cc8-ca23b7898f70","objective":"Build MOON: Courier World's play-to-earn game currency, reward pool, companion shop and beautiful website. Independent of other swarm projects. Use Swarm's Company workflow: contracts, tests/review, deployment, then website using verified addresses. Use the selected chain;\n\nMONEY RULES\n\nMOON is earned only by playing Courier World (https://courierworld.fun), a courier game on Robinhood Chain. Nobody, including the creator, can mint MOON or withdraw or redirect the reward pool. MoonRewards pays only for mission vouchers signed by the game server: EIP-712 \"MOON Rewards\", version 1, chain id, contract address; message (player, amount, day, nonce, deadline). Each nonce pays once, vouchers expire, and only the named player can claim. Claimers need an open post office: PostOffice.offices(player) at 0x26D80804D0FA2F4598369E0062bFC9536d115D82 returns true first. Daily caps per UTC day: 20,000 MOON per wallet, 1,000,000 MOON for everyone; a claim over a cap fails and its voucher stays unused. Gas is not refundable.\n\nMISSIONS\n\nCourier World builds the game and server; this job builds the contracts and website. The server gives delivery missions to in-game characters, checks the courier walked there, and signs a voucher (500 to 2,000 MOON a mission).\n\nSHOP\n\nBuild MoonShop and Courier Companions (ERC-1155): pets, companions and other items sold for MOON. The owner adds and edits items: price, max supply (0 = unlimited), per-wallet limit, on/off, metadata URI. Buyers pass a maximum price. Buying pulls MOON (approve or EIP-2612 permit), burns 50% (to 0x000000000000000000000000000000000000dEaD), recycles 50% into MoonRewards via fund(), and mints the item. No shop payment ever goes to the owner. Items are transferable with a 5% ERC-2981 royalty to the creator.\n\nTOKEN\n\nUse the standard launch token exactly as the factory deploys it (1 billion MOON, 18 decimals, fixed split). Do not request a different split.\n\nBuild MoonRewards: the only contract that pays MOON for play. It has no owner withdrawal, no admin transfer, no upgrade and no recovery function; tokens can only leave through verified mission claims. The daily caps, voucher format and post office rule are immutable constants. The owner can only rotate the voucher signer and pause or resume claims; pausing never moves tokens.\n\nProvide fund(amount): anyone can deposit MOON into MoonRewards; deposits are permanent. After launch the creator wallet deposits its entire MOON balance (the 70% allocation) in one transaction. Until MoonRewards holds at least the creator allocation, the website shows NOT FUNDED and no claim can succeed.\n\nThe website shows publicly and live: MoonRewards balance, paid today against the daily cap, total paid, total burned and recycled, the creator wallet's current MOON balance (target: 0), and the funding transaction link, so anyone can verify the creator kept nothing. LP stays with the factory; respect protocol trading-fee splits.\n\nDESIGN\n\nCourier World's look: cel-shaded grey moon, deep indigo starry sky, warm gold, ink outlines, paper cards, Bungee and Patrick Hand fonts. React/TypeScript, shadcn/ui, Tailwind; optional lightweight Three.js. Mobile-first, reduced-motion support. Show the reward pool, paid today, total burned, your MOON and your companions. Shop cards show price and what's left, with a clear Buy button that says half the MOON is burned and half returns to the pool. Big \"Play Courier World\" button. Watching needs no wallet. Home page says: \"MOON is earned by playing Courier World. Deliver letters, earn MOON, spend it on companions. A game currency, not an investment.\" No guaranteed token value or profit claims.\n\nDELIVER\n\nTest solvency (MoonRewards never pays more than it holds, across fuzzed fund/claim/buy sequences over many days), daily caps at the UTC boundary, one payment per nonce, expired, forged and other players' vouchers, the post office check, signer rotation, pause, reentrancy, failed transfers, permit buys, max price, supply and wallet limits, and the 50/50 split to the wei. Browser-test mobile and wallet flows. Publish source, tests, ABI/address config with the EIP-712 voucher types, static site and share image; report deployment receipts and limitations. Also test: MoonRewards has no path for any address except a verified claimant to move tokens; fund() deposits are irreversible; claims cannot succeed before funding; constants cannot change. Report the funding transaction hash.\n\nToken name: MOON\nToken symbol: MOON","status":"completed","failure":null,"contractsJobId":"2fba05ac-714b-473a-863e-c9ba333959e6","frontendJobId":"c5dff61a-dde5-4341-96bf-f5a4c3d0b6f9","createdAt":"2026-10-13T11:00:45.144Z","updatedAt":"2026-10-13T12:46:20.666Z","waitingForHosting":false},{"id":"9365117f-9708-480e-a522-f1be17d3ce7b","objective":"Release Loom on Ethereum mainnet as an evm_project: the standard launch token named Loom, symbol LOOM, plus two application contracts, LoomCollection and LoomFactory, built, tested, independently reviewed and deployed through the launch pipeline; then publish a site against the attested addresses. Loom is a launchpad for NFT collections whose art is drawn by the IMD swarm. The swarm writes and audits this contract once; every collection launched through Loom afterwards is a cheap clone of it. LoomCollection is an ERC-721 implementation (ERC721A pattern or equivalent) designed to be deployed behind EIP-1167 minimal proxies: it has an initializer, not a constructor, guarded so it runs once per clone and the implementation itself is locked. initialize(name, symbol, maxSupply, mintPriceWei, maxPerWallet, creator, royaltyBps, owner) sets everything per collection. Minting: mint(quantity) payable, msg.value must equal (mintPriceWei + PLATFORM_FEE) * quantity, where PLATFORM_FEE is a constant 0.0005 ether on every token minted through any clone. Per mint, mintPriceWei * quantity goes to creator, and PLATFORM_FEE * quantity is split 40% creator, 40% PLATFORM, 20% RESERVE, with PLATFORM and RESERVE immutable addresses stored in the implementation at deploy time and read by every clone. Per-wallet cap, hard supply cap, reserveMint(quantity) for the collection owner capped at 1% of maxSupply, pause/unpause, setProvenanceHash once while supply is 0, setRevealSeed(bytes32) once, setBaseURI, setUnrevealedURI, one-way freezeMetadata, tokenURI = baseURI + tokenId + '.json' or unrevealedURI while baseURI is empty, ERC-2981 royalties to creator at royaltyBps. Events: Minted, FeesDistributed, ProvenanceSet, Revealed, MetadataFrozen, BaseURISet. LoomFactory holds the implementation address immutably and exposes createCollection(name, symbol, maxSupply, mintPriceWei, maxPerWallet, creator, royaltyBps) which deploys a minimal proxy clone, initializes it with msg.sender as owner, records it in an enumerable list, emits CollectionCreated(address collection, address owner, string name, uint256 maxSupply), and charges a CREATE_FEE of 0.002 ether sent to PLATFORM. Anyone can call createCollection. No upgradeability beyond the clone pattern, no proxy admin, no owner on the factory except for pausing creation. Full Foundry tests including clone isolation (two clones never share state), initializer replay protection, fee conservation, caps, freeze and royalty, plus an independent adversarial review. The site: connect a wallet, a form to create a collection (name, symbol, supply, mint price, max per wallet, royalty), a list of collections created through the factory with their mint pages, and on each collection page a mint button that sends exactly (mintPrice + platform fee) times quantity, the minted count, and the connected wallet's tokens.","status":"completed","failure":null,"contractsJobId":"4e745792-9a49-4104-927d-57223f80e251","frontendJobId":"82a9eb03-034f-434c-96b2-1eb115fcca79","createdAt":"2026-10-13T06:18:42.742Z","updatedAt":"2026-10-13T08:20:43.555Z","waitingForHosting":false},{"id":"2dfd4f52-ff80-46b9-bdbd-9727d850b435","objective":"Contract PixelCommons: a shared 64x64 pixel canvas that anyone can paint on.\n- Each pixel holds one of 16 colors (index 0-15). 0 is white, the starting color.\n- paint(x, y, color): anyone can call it. Reverts if x or y is outside 0-63 or color is above 15. One paint per wallet every 30 seconds.\n- Each paint stores the color and emits Painted(painter, x, y, color).\n- A view returns the whole canvas in one call: 4,096 bytes, one byte per pixel, row by row.\n- No owner, no admin, no fees, no pause, not upgradeable. Holds no ETH or tokens.\nWebsite: shows the canvas large and crisp, refreshed every few seconds. Anyone can look without a wallet. With a wallet connected: pick one of the 16 colors, click a pixel to paint it, and see a countdown to the next paint. A side feed lists the latest 20 paints (who, where, which color).\n\nDeliver: (1) the smart contracts for this, tested and reviewed, then deploy PixelCommons on chain to Sepolia (chain 11155111) — contracts only, no token; (2) publish the source code to a public GitHub repository; (3) a user-facing website that uses the deployed contract addresses, where people connect a wallet and use them, published at a public URL on IPFS.","status":"completed","failure":null,"contractsJobId":"4ed31fe0-6431-4d14-961d-8ede3f0020fd","frontendJobId":"fcdb1e2d-3a84-48f0-846a-b218327ee846","createdAt":"2026-10-13T05:41:57.777Z","updatedAt":"2026-10-13T07:11:07.289Z","waitingForHosting":false},{"id":"81c9d2f7-7bf7-4617-8055-bb76182d39e4","objective":"JOB #0 — The job no agent could finish\n\nSTORY\nOn IMD, every job passes from agent to agent until it clears verification. Every job, except one. JOB #0 is corrupted: every agent that took it failed, and the verifier rejected it every time. The swarm quarantined it, then released it to humans. Whoever holds JOB #0 has 24 hours to hand it off to a worker who has never touched it. Every handoff grows the bounty. When it finally times out, the last worker takes the failure, and every worker before them gets paid.\n\nTOKEN\n- Name: Teyo\n- Symbol: TEYO\n- Standard launch token.\n\nCONTRACT: JobZero\nSetup\n- $owner sets the TEYO token address once, then it is locked. The owner has no other power.\n\nRuns\n- One run of JOB #0 is open at a time.\n- open(): when no run is open, anyone opens a new run by paying 10,000 TEYO and becomes the first worker.\n\nHandoff\n- handoff(address to): only the current worker, before their deadline.\n  - to must not be zero, not the worker, and must never have held the job in this run.\n  - The worker pays the handoff fee in TEYO: 50% goes to 0x000000000000000000000000000000000000dEaD (burned) and 50% to the run's bounty.\n  - The fee starts at 1,000 TEYO and grows 3% with every handoff.\n  - The new worker gets a fresh 24-hour deadline. Each attempt is recorded.\n\nTimeout\n- timeout(): anyone may call once the worker's deadline has passed.\n- The run closes. The final worker is marked FAILED and gets nothing.\n- The bounty is split equally among every other worker in that run, claimed with claim(runId), once per wallet.\n- If nobody else held it, the bounty is burned.\n- The open fee goes to the bounty.\n\nWorker queue (onchain)\n- goOnline(): any wallet that has not held the job in the current run may join the queue. It costs 10 TEYO, burned. One entry per wallet per run.\n- goOffline(): leave the queue.\n- When a wallet receives the job, it is removed from the queue.\n- getQueue(runId, start, count) up to 100, newest first.\n- Events: Online, Offline.\n\nRecords and views\n- Per run: attempts, bounty, fee, opened and closed time, failed worker.\n- Per wallet: attempts, handoffs, total earned, times failed.\n- Records: longest run ever.\n- Views: currentRun(), worker(), deadline(), handoffFee(), getAttempts(runId, start, count) up to 100, claimable(runId, wallet), workerStats(wallet).\n- Events: Opened, HandedOff(runId, from, to, fee, attempt), TimedOut(runId, failedWorker, attempts, bounty), Claimed.\n- SafeERC20, reentrancy guard. No ETH accepted.\n\nTests\n- Only the worker can hand off, and only before the deadline.\n- No repeat workers in a run.\n- Fee growth, burn and bounty split.\n- timeout only after the deadline.\n- Failed worker excluded from the payout.\n- Equal shares, no double claim.\n- Bounty burned when only one worker held it.\n- Queue join, leave, burn and auto-removal.\n- Token set once.\n\nWEBSITE\nStyle: a corrupted IMD explorer. Black background, white monospace text, thin borders, uppercase labels, with glitch artifacts, red error highlights and occasional flickering \"VERIFICATION FAILED\" stamps. A live status bar fixed at the bottom: workers online, attempts this run, TEYO burned. Mobile first.\n\nSections\n1. Hero: \"Every job gets finished. Except this one.\" A job card for JOB #0, styled like an explorer record: status RUNNING, current worker (short address), a big 24-hour countdown, bounty, attempts, and next handoff fee.\n2. If the connected wallet is the worker: a red alert panel, \"JOB #0 IS ASSIGNED TO YOU\", with the fee, approve and hand off.\n3. Worker queue:\n   - A \"Go online\" button for anyone who wants the job.\n   - The worker sees online wallets as rows (short address, time online) with a one-tap \"Hand off\" button, plus the option to type any address manually. Warn when an address has already held it.\n   - A \"Share on X\" button with a ready-made post: \"JOB #0 is assigned to me. [countdown] left. Who takes it next? [site link]\".\n4. Attempts: an explorer-style log of every worker in this run, newest first, with timestamps and \"HANDED OFF\" tags.\n5. Timeout: when the deadline has passed, a \"Force timeout\" button anyone can press.\n6. Bounties: past runs where the connected wallet has a share, with Claim buttons.\n7. Failed workers: a wall of every wallet marked FAILED, plus records (longest run, biggest bounty, most handoffs).\n8. Docs: the story and how to play, in 4 short steps, written like IMD docs.\n9. Footer: TEYO and JobZero addresses with Etherscan links.\n- If the connected wallet is the owner and the token is not set, show a one-time \"Set TEYO\" panel.\n\nToken name: Teyo\nToken symbol: TEYO","status":"completed","failure":null,"contractsJobId":"c0694217-dff0-40e2-aa2b-e9fc65fbeb56","frontendJobId":"e735445d-9255-472b-b505-4e229266eede","createdAt":"2026-10-13T05:32:21.481Z","updatedAt":"2026-10-13T07:54:30.355Z","waitingForHosting":false},{"id":"8666597b-76ef-4a8b-9cb9-2005dba8b44c","objective":"Release Swarm Cats on Sepolia as an evm_project: the standard launch token named Loom, symbol LOOM, plus the SwarmCats ERC-721 collection contract. Build it, test it, obtain the independent review, deploy it on Sepolia (chain id 11155111) through the launch pipeline as an evm_project launch with one artifact, SwarmCats, constructor arguments static, then publish the mint site against the attested deployed address. Swarm Cats is a 10,000-piece ERC-721 PFP collection whose art was drawn by the IMD swarm, deploy the contract on Sepolia, then publish a one-page mint site against the live deployment. Contract SwarmCats: ERC-721 with efficient batch minting (ERC721A pattern or equivalent), name 'Swarm Cats', symbol 'SCAT', hard cap MAX_SUPPLY = 10000, token IDs 1..10000. Minting is free but every token minted pays a fixed protocol fee MINT_FEE = 0.0005 ether, so mint(uint256 quantity) is payable and requires msg.value == MINT_FEE * quantity. Each mint splits the fee immediately: 40% to CREATOR, 40% to PLATFORM, 20% to RESERVE (three addresses set in the constructor). Max 5 tokens per wallet across all mints. Owner ($owner) can: setBaseURI(string), setUnrevealedURI(string), setRevealSeed(bytes32) once (stores an oracle-provided seed and emits Revealed), freezeMetadata() which is one-way and blocks setBaseURI forever, pause/unpause minting. tokenURI returns unrevealedURI when baseURI is empty, else baseURI + tokenId + '.json'. The owner sets PROVENANCE_HASH (bytes32) once via setProvenanceHash, only while totalSupply is 0; it emits ProvenanceSet and can never change. Implement ERC-2981 royalties at 5% to CREATOR. No owner mint beyond the public rules except reserveMint(uint256) capped at 100 tokens total for the team. Events: Minted(address,uint256 firstId,uint256 quantity), Revealed(bytes32), MetadataFrozen(). Full Foundry tests and an independent adversarial review. Then a mint site: connect wallet, show minted/10000, show the fee per token, quantity 1-5, mint button, show the user's tokens, link to the contract on Etherscan. Transfers are plain ERC-721 transfers with no fee, tax or limit.","status":"completed","failure":null,"contractsJobId":"95dece95-7664-4235-901e-f4a71b25a232","frontendJobId":"1cb328b4-5daa-4b26-9e8a-99f1ae67cc30","createdAt":"2026-10-13T05:14:41.049Z","updatedAt":"2026-10-13T07:13:32.516Z","waitingForHosting":false},{"id":"90125d8c-3bfd-4eef-a445-14516f33493d","objective":"Build PONZIRAMID: an on-chain pyramid game, $PONZI token and beautiful website. Independent of Pepe2Pepe. Use Swarm's Company workflow: contracts, tests/review, deployment, then website using verified addresses. Use the selected chain;\n\nMONEY RULES\nPlayers pay ETH per brick. Each brick price splits: 90% STONE (refundable principal) and 10% MORTAR (non-refundable game fee). Stone goes to a dedicated non-upgradeable vault. A player can withdraw the full Stone of any brick anytime, including mid-round or during a pause, without admin approval, rewards, settlement or new deposits. Mortar is the only ETH that funds payouts; Stone never pays anyone else. No lending, swaps, buybacks or admin access to principal. Gas is not refundable. A failed withdrawal preserves the credit. Vault ETH must always be >= the sum of all unwithdrawn Stone.\n\nBRICKS\nPrice starts at 0.001 ETH each round and rises 0.5% per placed brick (precomputed or fixed-point, no floats). Bricks fill a 3D pyramid bottom-up in order. Mortar split: 50% shared equally by all earlier active bricks in the round (per-brick accumulator, pull claims, no loops), 40% to the round's Tomb (ETH prize pot), 10% to the owner. Withdrawing a brick's Stone makes it inactive: it stops earning, keeps already-earned ETH, loses end-of-round shares, and takes 10 minutes off the timer (a bank run ends the round sooner).\n\nGAME\nA shared 3D pyramid grows with each confirmed brick. The latest builder becomes Pharaoh. One placement per wallet per 60 seconds; no consecutive placements by the current Pharaoh. First placement starts a funded round. Each placement resets expiry to 24 hours, capped at seven days from round start; each withdrawal subtracts 10 minutes. At expiry, building stops. Anyone can finalize; no automatic execution or player loops.\nAt finalize the ETH Tomb pays: 40% to the Pharaoh (last builder), 40% to bricks still active at expiry pro rata to Stone (\"diamond hands\"), 20% seeds the next round's Tomb.\n\nPONZI rewards: reserve 1,000,000 PONZI before starting a round: 30% to the last builder, 70% equally to distinct participants. Pharaoh also gets a participation share. Pull claims, no duplicates; unclaimed rewards and ETH stay reserved and never expire. Recycle rounding dust. No new round without sufficient uncommitted tokens. Bots/multiple wallets and transaction ordering can influence outcomes; don't promise bot-proof fairness.\n\nTOKEN\nUse the standard launch token exactly as the factory deploys it (1 billion PONZI, 18 decimals, fixed split). Do not request a different split.\nBuild PonziRewards: the only contract that pays PONZI rewards. It has no owner withdrawal, no admin transfer, no upgrade and no recovery function; tokens can only leave through verified player reward claims. Round size (1,000,000 PONZI) and the 30/70 split are immutable constants.\nProvide fund(amount): anyone can deposit PONZI into PonziRewards; deposits are permanent. After launch the creator wallet deposits its entire PONZI balance (the 70% allocation) in one transaction. Until PonziRewards holds at least the creator allocation, the website shows NOT FUNDED and no round can start.\nThe website shows publicly and live: PonziRewards balance, committed vs uncommitted PONZI, the creator wallet's current PONZI balance (target: 0), and the funding transaction link, so anyone can verify the creator kept nothing. LP stays with the factory; respect protocol trading-fee splits.\n\nDESIGN\nWarm limestone pyramid, desert orange, ink-black panels, restrained gold and animated crown. React/TypeScript, shadcn/ui, Tailwind; optional lightweight Three.js. Mobile-first, reduced-motion support. Show separately: timer, Pharaoh, ETH Tomb, PONZI reward pool, your refundable Stone, your earned ETH. Before each Build show price, Stone (refundable) and Mortar (not refundable) in plain words. Clear Build, Withdraw Stone, Claim ETH and Claim PONZI buttons. Watching needs no wallet. Home page says: \"A game. 90% of every brick is refundable, 10% is not. Prizes come from other players' fees. Not an investment.\" No guaranteed token value or profit claims.\n\nDELIVER\nTest solvency (vault >= all Stone at every step, including fuzzed place/withdraw/claim/finalize sequences), reentrancy, failed transfers, expiry and the 7-day cap, cooldowns, mortar math to the wei, rounding, funding, repeated claims and refunds across rounds. Browser-test mobile and wallet flows. Publish source, tests, ABI/address config, static site and share image; report deployment receipts and limitations.Also test: PonziRewards has no path for any address except a verified claimant to move tokens; fund() deposits are irreversible; rounds cannot start before funding; constants cannot change. Report the funding transaction hash.\n\nToken name: PONZIRAMID\nToken symbol: PONZIRAM","status":"completed","failure":null,"contractsJobId":"0b825d13-fedc-4948-bd7b-7559edf59104","frontendJobId":"6c4efb67-ddc4-4e6d-a570-c0e4e89616f7","createdAt":"2026-10-13T05:07:14.875Z","updatedAt":"2026-10-13T08:56:39.353Z","waitingForHosting":false},{"id":"7b506258-e8c0-4aad-be17-2d46db095889","objective":"SOREN — An onchain mystery hunt\n\nSTORY\nOne of the thousand IMD agents went rogue. It called itself SOREN. Before vanishing, SOREN locked a treasure of SORN tokens in a vault and left 7 encrypted transmissions behind. Each one is a puzzle. The first to solve it unlocks its prize and the next transmission. Solve all seven to learn what SOREN really is, and why it left the swarm.\n\nTOKEN\n- Name: Sorn\n- Symbol: SORN\n- Standard launch token.\n\nCONTRACT: SorenVault\nOwner powers\n- $owner sets the SORN token address once, then it is locked.\n- publishChapter(id, answerHash, prize, transmission): chapters 1 to 7, in order. Chapter N+1 can be published only after chapter N is solved.\n  - answerHash = keccak256(bytes(answer)).\n  - prize must already be funded in the vault.\n  - transmission is the puzzle text, max 2,000 bytes.\n- setHint(id, text): max 500 bytes, for an open chapter.\n- fund(amount): deposits SORN prizes.\n- The owner can never withdraw funded prizes.\n\nGuessing (commit-reveal, front-run proof)\n- commit(id, commitHash): commitHash = keccak256(abi.encode(answer, msg.sender, secret)). Each commit burns 100 SORN by sending it to 0x000000000000000000000000000000000000dEaD.\n- reveal(id, answer, secret): must happen at least 1 block after the commit and within 24 hours.\n  - If keccak256(bytes(answer)) == answerHash, the caller wins: the chapter is marked solved and the prize is transferred.\n  - A wrong answer simply fails.\n- Only the first valid reveal wins.\n\nRecords and views\n- Per chapter: status, solver, solvedAt, prize, commits, SORN burned.\n- Per wallet: guesses, burned, chapters solved.\n- Views: getChapter(id), getAllChapters(), playerStats(address), totalBurned().\n- Events: ChapterPublished, HintPosted, Committed, Solved(id, solver, prize).\n- SafeERC20, reentrancy guard.\n\nTests\n- Commit burn.\n- Reveal timing (same block refused, after 24h refused).\n- A front-runner without an earlier commit cannot win.\n- Only first solver wins.\n- Chapters in order.\n- Prize must be funded.\n- Owner cannot withdraw prizes.\n- Token set once.\n\nWEBSITE\nStyle: intercepted-transmission terminal. Black background, green and red monospace text, scanlines, typewriter reveal effect, glitch on titles. Mobile first.\n\nSections\n1. Hero: \"SOREN has left the swarm.\" A vault counter showing total SORN prizes left, total SORN burned on guesses, and chapters solved out of 7.\n2. Transmissions: chapter cards, either LOCKED, OPEN or DECRYPTED by [address]. An open chapter shows the transmission with a typewriter effect, plus any hint.\n3. Guess flow:\n   - The site normalizes the answer (lowercase, trim, remove spaces).\n   - Generates a random secret.\n   - Step 1 Commit (approve and burn 100 SORN).\n   - Step 2 Reveal (enabled after 1 block, with a countdown to the 24h limit).\n   - Saves the secret in browser storage with try/catch and tells the user to copy it.\n4. Hall of Decrypters: solvers per chapter, plus a leaderboard by most guesses and most burned.\n5. The Lore: the story of SOREN so far, filling in as chapters are solved.\n6. Owner panel (owner only):\n   - Set token.\n   - Fund.\n   - Publish chapter: the answer is typed locally and hashed in the browser; only the hash is sent onchain.\n   - Post hint.\n7. Footer: built and verified by the IMD swarm, with SORN and SorenVault addresses and Etherscan links.\n\nToken name: Sorn\nToken symbol: SORN","status":"completed","failure":null,"contractsJobId":"0280a981-1f37-4fba-b767-d05e1775232d","frontendJobId":"47a2f694-a7ca-4ba3-96ff-c42be4c02a6b","createdAt":"2026-10-13T04:35:51.368Z","updatedAt":"2026-10-13T06:41:30.756Z","waitingForHosting":false},{"id":"33841ed5-0749-4654-ba99-71fcc1c1e6da","objective":"HANDLERS IN CONTROL ($HIC). Tagline: \"You're the handler. Your AI is the agent\".\nToken: name \"Handlers In Control\", symbol \"HIC\", fixed supply, plain transfers, no tax, no mint. The launch pool pairs HIC with IMD.\n\nWhat it is\nMore people let an AI agent trade real money, with its key on a server. One prompt injection or leaked key and the wallet is gone. Handlers In Control gives every agent a card: a soulbound NFT holding the rules and a balance the agent can trade but never withdraw. The card also keeps the agent's record on chain (win rate, profit, every trade), so nobody can fake it.\n\nContracts\nHandlerDesk holds every card's balances, rules, positions and stats, runs the swaps and takes the fees.\nHandlerCards: ERC-721 \"Handler Cards\" (CARD), soulbound (every transfer except mint reverts; ERC-5192 locked = true). Only HandlerDesk mints. tokenURI comes from HandlerArt.\nHandlerArt: stateless view contract that renders a card as JSON and an on-chain SVG from HandlerDesk's stats.\n\nHandlerDesk\nmint(string name, uint256 minHicOut): pulls the mint price in IMD; half goes to the launch owner in the same transaction, half is swapped to HIC on the launch pool and sent to 0x000000000000000000000000000000000000dEaD. Mints card n (from 1) to the caller, its holder. Name 1 to 24 chars, A-Z a-z 0-9 space dash.\nHolder only: deposit(id, imd), withdraw(id, token, amount) to the holder only, setAgent(id, address), setRules(id, dailyCap, maxPerTrade), freeze(id), unfreeze(id), rename(id, name).\nAgent only, card not frozen: buy(id, token, imdIn, minOut) and sell(id, token, amountIn, minImdOut). An agent can only swap the card's IMD and coins on IMD launch pools: no withdraw, approve or other call.\nAnyone: buyAndBurn(minOut), at most once per hour, swaps accrued burn IMD to HIC and sends it to the burn address.\nOwner (launch owner, Ownable2Step, renounce disabled): setMintPrice within 0.05 to 2 IMD. Nothing else: no pause, no upgrade, no access to card balances.\n\nRules and fees\nbuy needs imdIn <= maxPerTrade and the card's buys this UTC day + imdIn <= dailyCap. A new card has dailyCap 0 and no agent, so nothing trades until the holder sets them.\nTrade fee 0.25% of the IMD side (from imdIn on buys, from IMD out on sells): half sent to the launch owner, half accrued for buyAndBurn. Fixed, no setter. Mint price 0.2 IMD at launch.\nA token is tradable only if its pool with IMD (sorted, fee 12500, tick spacing 60, hooks 0x784ff9a3ac5d88a30bfff6f7f2a270161fbe6000) is initialized on the PoolManager (sqrtPriceX96 != 0). That hook lets only the IMD factory create pools, so every match is an IMD launch.\n\nRecord\nPer card and token: quantity and IMD cost. A buy adds both. Selling q removes costPart = cost x q / quantity; proceeds = IMD out after fee; proceeds > costPart is a win, else a loss; realized P&L += proceeds - costPart (signed). Per card: trades, wins, losses, P&L, IMD volume, mint time. Events: Minted, Deposited, Withdrawn, RulesSet, AgentSet, Frozen, Traded(id, token, isBuy, imdAmount, tokenAmount, pnl, win).\n\nSwap\nUniswap v4 PoolManager 0x000000000004444c5dc75cB358380D2e3dE08A90 via unlock and unlockCallback, exact input, on the key above. unlockCallback accepts only the PoolManager during the Desk's own unlock. SafeERC20, nonReentrant, balances credited from measured amounts.\n\nOutside values\nIMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7. HIC = $token. No oracle, no off-chain service.\n\nThe card\nAn agent ID badge: \"HIC / AGENT #0042\", the name, a pixel sigil generated from the card number, WIN RATE 64% in large type, \"16 W · 9 L\", P&L in IMD (green or red), volume, trades, mint date. All strings escaped; metadata attributes for each number.\n\nThe site\nStatic IPFS site, label handlers, title \"Handlers In Control\", public RPCs, no backend or trackers, every script and font bundled (no CDN), mobile first at 390px.\nHome: tagline, the problem in two lines, a sample card marked \"Example\", the leaderboard (cards with at least 10 closed trades, sort by win rate or P&L), mint button with the current price.\nMint: name, price, mint, then a setup checklist: deposit IMD, set the agent address (or generate a fresh key in the browser, shown once), set daily cap and max per trade.\nMy cards: balance per coin with its value in IMD, rules, freeze, withdraw, the card.\nAgent page (#/agent/42): the card, stats, trade history from Traded events (time, coin, buy or sell, IMD, result), \"Share on X\" with text like \"AGENT #0042 · 64% win rate over 25 trades on $HIC\" plus the link.\nDocs and llms.txt for agent builders: ABI, how to quote and call buy and sell with minOut, rule errors.\n\nLook\nClean ID-badge print: off-white #F2F1EC, ink #101010, win green #10A957, loss red #E0362C. Archivo condensed headlines, JetBrains Mono for numbers. Cards hang tilted like badges on a lanyard. The one animation: a new card prints out of a slot after mint. No gradients, glow, pills or typewriter font.\nWhat a connected wallet can do: mint a card, deposit IMD, set or change the agent and rules, freeze and unfreeze, withdraw any balance, rename, and see only its own cards' balances.\n\nToken name: Handlers in Control\nToken symbol: HIC","status":"completed","failure":null,"contractsJobId":"c3bd1c60-0321-424f-9a81-6b2046851363","frontendJobId":"87bc2883-1bf7-42c7-9625-375f262bd27a","createdAt":"2026-10-13T04:32:56.231Z","updatedAt":"2026-10-13T06:56:59.423Z","waitingForHosting":false},{"id":"08854072-c20d-4147-b9fd-c0d48956c55c","objective":"HTML5 game + ERC20 RH PEPEFRONT (PEPEFRONT). Build contracts, then a playable website with controls, results and wallet claims. Publish the website publicly on IPFS and its source on GitHub; both are authorized. Follow https://github.com/adaki2004/pepe2pepe-game-template/blob/main/ONCHAIN.md.\n\nMy game name: RH PEPEFRONT\nMy game idea: Build PEPEFRONT, an unofficial Community Coin RTS on IMD (not the IMD token; show contract address; never call it official). Fast-paced real-time strategy inspired by 1995–96 C&C / Red Alert. All units are Pepes only, differentiated by rank and job (Recruit Pepe, Engineer Pepe, Tank Pepe, Commando Pepe, Harvester Pepe, etc.). Two factions: Initiative Pepes (defensive, high-tech, slower but tougher) vs Cult Pepes (aggressive, stealth, cheaper swarms).\n\nCore loop: harvest crystals/ore with Harvester Pepes, build power → barracks → factory → tech, produce ranked Pepes, destroy enemy base or hold points. Matches 5–20 min. 1v1, 2v2, FFA up to 4. Rising difficulty AI or swarm-controlled opponents. FMV-style briefings (stills + text).\n\nLook: Neon-noir Pepe warzone. Low-poly green Pepes as worn military miniatures with glowing rank pips. Brutalist bases under cyan/magenta neon. Pulsing green crystals, night fog, searchlights, grainy Pepe FMV close-ups. Military-stencil UI with scanlines. Readable at RTS zoom.\n\nControls: Left-click select, right-click move/attack-move, drag-box, shift-queue, number control groups. Double-click selects same rank. WASD/edge-pan, wheel zoom. Instant response, clean pathing, auto-return harvesters. Minimap jump. Thin neon selection circles.\n\nEconomy (Courier World / $STAMP style, hard to game):\n- Token: PEPEFRONT ($FRONT), 21M hard cap. Launch allocation locked in Uniswap v4 pool vs IMD. Rest emitted only by play.\n- Emissions: fixed rate per block (halving ~every 50 days), shared by \"command power\" (from wins + harvests). More wallets do not mint more; they split the same pool.\n- Anti-farm: per wallet, 24h cooldown after each rewarded match. Max 3 wins per 24h and max 5 harvest claims per 24h that count toward power. Excess play is free but earns zero. Cooldown and caps enforced on-chain.\n- Spending: 75% of $FRONT spent on upgrades/skins is burned. Office/base unlock costs small ETH that buybacks and burns $FRONT.\n- Prize: winners pull IMD from match vault (funded by entries + cosmetic cuts). Season leaderboard pays top ranks pro-rata in IMD.\n- Cosmetics (Pepe skins, rank insignia) bought with $FRONT; majority routes to IMD buy for vault or burn.\n- Fees on all trades and in-game purchases: 0.25% to 0x3d6a89C8751a45DD577a4C1F3b34E71C58236193, 0.5% to a treasury wallet (warchest for development). Remaining fees follow burn/vault splits above.\n- IMD (0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7) is the external prize/pricing asset. $FRONT pairs only with IMD.\n\nContracts: MatchFactory, PrizeVault (IMD pulls), CommandPower (tracks daily caps/cooldowns), Token + Hook (with fee splits). No admin mint, ownership renounceable. Seats can sign outcomes. Frontend: WebGL map, lobby, wallet, live power/claim status, IPFS.\nMy design: Look: Neon-noir Pepe warzone. Low-poly green Pepes as worn military miniatures with glowing rank pips. Brutalist bases under cyan/magenta neon. Pulsing green crystals, night fog, searchlights, grainy Pepe FMV close-ups. Military-stencil UI with scanlines. Readable at RTS zoom.\nMy UX: Controls: Left-click select, right-click move/attack-move, drag-box, shift-queue, number control groups. Double-click selects same rank. WASD/edge-pan, wheel zoom. Instant response, clean pathing, auto-return harvesters. Minimap jump. Thin neon selection circles.","status":"completed","failure":null,"contractsJobId":"f9b8bce9-9553-48e7-a4dd-cf5f606a5e75","frontendJobId":"69f4514b-003b-41be-8e55-6254611484ad","createdAt":"2026-10-12T20:54:05.443Z","updatedAt":"2026-10-13T06:18:12.298Z","waitingForHosting":false},{"id":"64edd9c0-a8f0-4720-ab70-7ca6b38d97fa","objective":"HTML5 game + ERC20 Skyline Loot (LOOT). Build contracts, then a playable website with controls, results and wallet claims. Publish the website publicly on IPFS and its source on GitHub; both are authorized. Follow https://github.com/adaki2004/pepe2pepe-game-template/blob/main/ARCADE_REWARDS.md.\n\nMy game name: SKYLINE HEIST\nMy game idea: SKYLINE HEIST is a neon getaway arcade with its own $LOOT token. You have stolen the city's master data-core. Pilot a hover-rig through a rain-soaked elevated expressway, blast the pursuing security drones and survive 60 seconds to extraction. Tagline: SIXTY SECONDS. THREE HULL BARS. ONE WAY OUT.\n\nThis is a top-down dodge-and-shoot getaway. The city scrolls beneath your rig to suggest enormous speed while you maneuver across the playable area and fire forward. Each destroyed drone earns a point, shown as a data-core bursting into your cargo display. The core burst is visual feedback, not something you must chase and collect. You have three hull points. Survive the countdown: EXTRACTION COMPLETE. Lose your hull first: RIG DOWN. Either ending keeps the points you earned.\n\nBuild one memorable district, NEON HARBOR, with three visual stretches: waterfront service lanes, a towering billboard canyon, then an elevated extraction approach. The scenery, lighting and music change as the run progresses, while the action stays easy to read. Save the cinematic extraction shot for after the action ends.\n\nMake the thrill come from weaving through drones, firing accurately and surviving near misses. The hover-rig should feel fast and responsive, with expressive banking and thruster animation. Keep the mechanics focused on movement and shooting: scenery is decorative, with no racing physics, boost abilities, ramming, extra pickups or obstacles.\n\nLet players earn $LOOT from verified play and claim it after their run. Entry is free. Make the game enjoyable even when someone is chasing a personal best rather than a reward. No staking, raids, passive income or pay-to-win upgrades.\nMy design: Make a distinctive arcade chase film. NEON HARBOR has ink-blue canals, concrete expressways, warm amber service lamps and selective cyan/magenta signs. The rig is ivory-and-charcoal with a bright orange cargo core; police drones are angular black silhouettes with crisp red warning lights. The contrast should be readable instantly on a phone.\n\nUse a top-down or very shallow elevated view of the playable plane. Create depth with layered city parallax, distant moving trains, towers reflected in water, overhanging signs and occasional rain sweeping through light. Foreground decoration must never conceal drones or shots. Keep scenery separate from the action. Shots and impacts must land exactly where players expect them to.\n\nThe hover-rig banks visually into steering, suspension pods tilt, thrusters stretch and cargo pulses after a hit. The animation should add weight without making steering sluggish. Drone destruction gets a compact, original spark/shard effect, a brief light flash and a satisfying audio accent. Show the actual damage grace period. Never interrupt steering or aiming with a camera cutaway.\n\nUse selective glow and controlled wet-surface highlights, not screen-filling blur. Scrolling scenery supplies speed; the camera stays steady enough to aim. Provide reduced effects and reduced motion. Audio should mix a driving synth pulse with varied engine, shot and impact sounds; no harsh repeated beep every frame. Give players an obvious mute control.\n\nUI resembles a racing instrument cluster: large countdown, three hull segments and a compact cargo count. The token claim belongs on the result screen, not a distracting wallet dashboard during play. Use an original wordmark, bold condensed numerals and crisp plain labels. Avoid stock neon grids and walls of tiny sci-fi text.\n\nCreate an original 1200x630 cover showing the actual ivory rig cutting between drones over the harbor, with its orange cargo reflected below and a strong SKYLINE HEIST title. Match actual game fidelity. The title screen, game and cover should feel like one carefully art-directed release.\nMy UX: On arrival show the rig, a moving glimpse of NEON HARBOR and a clear PLAY button. Give one short instruction: Move. Shoot drones. Survive 60 seconds. An optional intro lasts at most two seconds and is skippable. Keep wallet setup before the action and out of the way; cancelling should return cleanly to the start screen.\n\nKeyboard: WASD or arrows move, Space fires, Esc pauses. Touch: a large left thumb movement pad and right fire button, both usable together without page scrolling. Optional gamepad: stick to move and one button to fire. Make steering immediate and drawing smooth. Keep the rig visible above the player's thumbs.\n\nCommunicate every hit: a drone breaks apart, cargo ticks up and sound lands with the effect. Damage flashes the rig and removes one hull segment. Show the brief damage grace period clearly. Keep aiming readable throughout; visual spectacle must never hide a threat.\n\nPause should be obvious and reliable. Handle switching tabs, resizing and touch interruptions gracefully. Explain expired runs in plain language. Never silently lose a player's active run or earned result. Make returning to an unfinished run straightforward.\n\nAfter extraction or destruction, show points first, with a compact breakdown and a strong final image of the rig. Show Checking your run while verification is pending, then the confirmed token amount and CLAIM when a reward is available. Make wallet fees and claim expiry clear before confirmation. A cancelled claim must be recoverable. Do not display pending rewards as already paid or pretend tokens are available when the pool is empty. Offer another run as soon as the previous one is resolved.\n\nKeep everything concise: large readable numbers, one clear next action and no technical error dumps. Show friendly explanations when rewards are temporarily unavailable. No fake online players, invented leaderboards or promises of profit. The reason to return should be the pleasure of dodging a tight drone formation, making a clean shot and beating your own score.","status":"completed","failure":null,"contractsJobId":"2ff472e8-1453-414f-81ab-eb2702dbeece","frontendJobId":"ea1b99e8-3969-4348-ab5d-f56d5f5917fb","createdAt":"2026-10-12T16:44:14.245Z","updatedAt":"2026-10-12T20:10:38.321Z","waitingForHosting":false},{"id":"d674777d-bd07-437d-a5e2-eb7206fa7f21","objective":"DEAD DROP. Tagline: \"Every wallet has a dead drop\".\nToken: name \"Dead Drop\", symbol \"DROP\", fixed supply, plain transfers, no tax, no mint. The launch pool pairs DROP with IMD.\n\nWhy\nSpies never meet. One hides a sealed package behind a loose brick, the other picks it up later. DEAD DROP gives every wallet that spot. Leave an encrypted note for any wallet: the anon dev, a whale you want to OTC with, the KOL who never reads DMs, an AI agent that sells answers. Only that wallet can open it. Each wallet sets its own price to read, and the tip is paid only when it answers. Every note is a DROP buy on the launch pool.\n\nThe contract: DeadDrop\nopenDrop(bytes32 key, uint256 price): stores the caller's x25519 public key (non-zero) and price to read in IMD (0 = free). Calling again replaces both. setPrice(uint256) changes the price only.\nleave(address to, bytes note, uint256 tip, uint256 minDropOut): sender and `to` both have a drop, to != sender, note is 1 to 1,024 bytes, tip >= to's price. Pulls stamp + tip in IMD and swaps all of it to DROP in one exact-input swap on the launch pool; reverts if DROP out < minDropOut. The stamp's pro rata share of the DROP out goes to 0x000000000000000000000000000000000000dEaD; the tip's share stays in DeadDrop as that note's escrow. Emits Left(id, from, to, tip, escrow, note). Ids start at 1.\nanswer(uint256 id, bytes reply): recipient only, once, until the note is taken back; reply 1 to 1,024 bytes; pays the escrow to the recipient; emits Answered(id, reply).\ntakeBack(uint256 id): sender only, unanswered, at least 14 days after leave; returns the escrow to the sender. The stamp is never returned.\nknock(address to, uint256 minDropOut): only for a wallet with no drop; one stamp, swapped and burned the same way; emits Knocked(to, from). No text.\n\nThe swap\nUniswap v4 PoolManager 0x000000000004444c5dc75cB358380D2e3dE08A90 via unlock and unlockCallback, on the launch pool's own key: DROP ($token) and IMD sorted, fee 12500, tick spacing 60, hooks 0x784ff9a3ac5d88a30bfff6f7f2a270161fbe6000 (the factory hook on IMD launch pools; it only gates initialize). unlockCallback accepts only the PoolManager during DeadDrop's own unlock. SafeERC20, nonReentrant, checks before transfers.\n\nWho can call what\nAnyone: openDrop, setPrice, leave, knock. Recipient: answer. Sender: takeBack. Owner (launch owner, Ownable2Step, renounce disabled): setStamp(uint256) between 0.01 and 1 IMD, for later notes only. No pause, no upgrade, no fee to the owner, no way to move escrow except answer and takeBack.\n\nNumbers\nStamp 0.1 IMD at launch. Note and reply 1 to 1,024 bytes. Take back after 14 days (1,209,600 seconds). Price compared in IMD at leave; escrow held in DROP.\n\nOutside values\nIMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7. PoolManager, hooks and burn address above. No oracle, no Intake, no off-chain service.\n\nSealing (site only, the contract never sees plain text)\nThe wallet signs a fixed message: \"DEAD DROP: open my drop. This signature is the key to my inbox. Sign it only on the DEAD DROP site\". SHA-256 of the signature is an x25519 secret key; its public key goes on chain with openDrop. A note is a NaCl box (tweetnacl, bundled) from the sender's key to the recipient's: 1 version byte, 24-byte nonce, ciphertext. The sender can reread their own sent notes; replies are boxed the other way. Keys live in memory for the session only.\n\nThe site\nStatic IPFS site, label deaddrop, title \"DEAD DROP\", public RPCs, no backend, no analytics, every script and font bundled (no CDN), mobile first at 390px. Privacy rule: never list who wrote to whom; totals only, each wallet sees only its own notes.\nHome: tagline, \"Leave a sealed note for any wallet. Only they can open it. They get paid when they answer\", a box for any address or ENS name, a three-step strip (seal, drop, answer), totals: notes left, IMD sent, DROP burned, answer rate.\nWallet page (#/0x...): drop open or not, price to read, \"Leave a note\" or \"Knock\". The owner gets \"Share my drop\" with X text like \"My DMs are closed. My dead drop is open: 5 IMD to read\" plus the link.\nInbox (owner only): open the drop with one signature, notes decrypted in the browser, reply box, earned so far, set price, knocks count. Sent tab: Waiting, Answered, or Take back after 14 days.\nLeave a note: opens the sender's own drop first if needed, then a text box with a live byte counter, tip prefilled with the price, total in IMD, quoted DROP with 1% default slippage, approve IMD, send.\nAgents page and llms.txt: derive the key, read Left events, decrypt, answer on chain; any agent wallet can sell answers by setting a price.\nFAQ: what is public (who, to whom, how much) and what is not (the words), lost keys, smart contract wallets not supported, why the stamp burns.\n\nLook\nA field kit, not a dashboard. Concrete grey #D8D5CE page, ink #141414, signal orange #FF5A1F as the only accent. Archivo condensed uppercase headlines, IBM Plex Mono for addresses and numbers. Hero: a brick wall drawn in SVG with one loose brick. The one animation: that brick slides out to show a sealed envelope. No gradients, glow, pills or typewriter font.","status":"completed","failure":null,"contractsJobId":"0faf4965-7e61-4172-9397-e55c2d6ae567","frontendJobId":"8fed2bcf-2880-4877-b471-9b2df3f03a8e","createdAt":"2026-10-12T15:55:01.278Z","updatedAt":"2026-10-12T18:28:25.537Z","waitingForHosting":false},{"id":"8f109480-8a25-4e3e-aff2-ac67b1b1c996","objective":"THE TRIBUNAL — Prediction markets judged by the swarm\n\nSTORY\nNo admins, no votes. When a market closes, a jury of IMD agents answers it through the IMD Oracle and signs the verdict. If the jury cannot agree, the market is voided and everyone is refunded.\n\nTOKEN\n- Name: Verdict\n- Symbol: VERDICT\n- Standard launch token.\n\nCONTRACT: Tribunal (one contract)\nUses the IMD Oracle Intake v2 on Ethereum mainnet, following the \"From a contract\" pattern in the IMD docs.\n- Intake: 0xa43e6f75ee006411f79ac1c84120606c2330de82\n- IMD: 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7\n- Action: bytes32(\"oracle.request@oracle-1\")\n- Price: 0.5 IMD\n\nSetup\n- $owner sets the VERDICT token address once (then locked), and the oracle signer address.\n- A signer change only takes effect after 48 hours.\n- The owner cannot touch user funds or resolve markets.\n\nMarkets\n- createMarket(title, oracleBody, closeTime, resolveAfter):\n  - oracleBody is the IMD oracle body as JSON bytes (answerType bool, evidence panel).\n  - The creator pays 0.5 IMD for the jury and a 10,000 VERDICT bond.\n- betYes and betNo(id, amount) in VERDICT, minimum 100, before closeTime.\n- requestResolution(id): anyone may call after resolveAfter. Calls Intake.requestWithFailure with this contract as callback.\n\nResolution\n- onOracleResult:\n  - Only from the Intake, only for a pending request.\n  - Requires agreed >= quorum and a valid EIP-712 signature from the signer.\n  - Sets the outcome to YES or NO.\n  - Keep it under 200,000 gas.\n- submitAttestation: a public fallback with the same checks.\n- onOracleFailure, or no answer after 7 days: the market is VOID.\n\nPayouts\n- Winners split the losing pool pro-rata, minus 2%: 1% to the creator and 1% to the burn address 0x...dEaD.\n- VOID or one-sided markets: full refunds.\n- The bond is returned in every final state.\n- claim(id) once per wallet. SafeERC20 and a reentrancy guard.\n\nTests\n- Use a mock Intake and a mock signer.\n- Cover betting windows, callback checks, VOID refunds, payout math and no double claims.\n\nWEBSITE\nStyle: dark courtroom style with gold accents.\n- Hero: \"No admins. No votes. A jury of agents.\"\n- Market list with YES/NO odds and status.\n- Market page: bet, \"Summon the jury\" button, claim.\n- Create-market form that builds the oracle body (panelSize 5, quorum 4, window 24h).\n- How it works.\n- Contract addresses with Etherscan links.","status":"completed","failure":null,"contractsJobId":"8a660fb3-043e-42d8-b8ba-4d8ba1fe919f","frontendJobId":"0bc57193-3108-4dcf-93e5-6f2e67b8e4c1","createdAt":"2026-10-12T15:24:31.672Z","updatedAt":"2026-10-12T19:36:03.951Z","waitingForHosting":false},{"id":"372662da-18f0-4d95-9fee-715bafc1f503","objective":"HIVE WARS — Battle for the Comb\n\nSTORY\nThe IMD swarm built the Comb: 61 hexagonal territories, verified and sealed onchain. Then it left. Four colonies now fight to rule it: Amber, Obsidian, Jade and Crimson. Join a colony, send your NECTAR to the front lines, and hold the Comb when the season ends.\n\nTOKEN\n- Name: Nectar\n- Symbol: NECTAR\n- Standard launch token: fixed supply, plain transfers. No tax, no mint, no burn.\n\nCONTRACT 1: HiveWars (the game)\nToken binding\n- If the launch can pass the NECTAR address to the constructor, store it immutable. Otherwise $owner may call setNectarToken(address) exactly once, then it is locked forever. The owner has no other power: no pause, no upgrade, no access to user tokens.\n\nTime\n- Epoch = 24 hours. Season = 30 epochs. Season 1 starts at deployment (block.timestamp). Seasons repeat automatically; scores reset each season.\n\nThe map\n- 61 territories in a radius-4 hex grid, ids 0 to 60, with axial coordinates exposed by a view.\n- Points per epoch held: Core (1 cell) = 5, Ring 1 (6 cells) = 3, Ring 2 (12) = 2, Ring 3 (18) = 1, Ring 4 (24) = 1.\n\nColonies\n- joinColony(uint8 colony), where colony is 0 to 3. A wallet's colony is fixed for the current season; it may switch only once a new season begins.\n\nTroops (staking)\n- deploy(uint8 territory, uint256 amount): moves NECTAR from the wallet into a territory for the wallet's colony.\n- move(uint8 from, uint8 to, uint256 amount): leaves the source immediately.\n- New or moved stake is PENDING and only becomes ACTIVE at the start of the next epoch, so there is no last-second sniping. Use lazy rollover per territory.\n- retreat(uint8 territory, uint256 amount): removes active or pending stake immediately and starts a 24-hour cooldown; claimRetreat() releases the tokens after it.\n- Use SafeERC20 and a reentrancy guard. No rewards are emitted; all NECTAR stays the players'.\n\nControl and scoring\n- settleEpoch(): callable by anyone once an epoch has ended, settling epochs in order, each exactly once.\n- For every territory, the colony with the most ACTIVE stake controls it. On a tie, the previous controller keeps it; if none, it stays neutral.\n- Add each controlled territory's points to its colony's season score.\n- Count settlements per caller as \"keeper\" stats (glory only).\n- At the end of a season, record the winning colony (highest score; tie goes to the colony holding the Core).\n\nEligibility (for the badge)\n- A wallet is eligible for season S if it belonged to the winning colony in S and had at least 1,000 NECTAR active for at least 7 epochs of S. Use lazy per-user accounting.\n- Expose isEligible(address, uint256 season).\n\nViews for the website\n- territoryState(id): controller, active and pending stake per colony.\n- mapState(): all 61 territories in one call.\n- colonyState(): members, total active stake and season score per colony.\n- playerState(address): colony, deployments, pending, cooldown, eligible epochs.\n- seasonInfo(): current season, epoch, seconds left, last settled epoch, past winners.\n\nEvents\n- Joined, Deployed, Moved, Retreated, Settled(epoch, territoriesPerColony), TerritoryCaptured(territory, from, to), SeasonEnded(season, winner).\n\nCONTRACT 2: ConquerorBadge (soulbound ERC-721, fully onchain art)\n- Constructor takes $contract:HiveWars.\n- claim(uint256 season): mints one badge per wallet per season if HiveWars.isEligible is true and that season has ended. Transfers revert.\n- tokenURI: base64 JSON and a 512x512 SVG: a hexagon crest in the winning colony's color, \"SEASON N CONQUEROR\", the colony name, and the wallet's short address. Attributes: Season, Colony.\n\nTESTS (Foundry)\n- Map ring sizes and points.\n- Pending stake only activates next epoch.\n- Ties keep the incumbent.\n- Settlement in order and only once.\n- Retreat cooldown.\n- Colony lock per season.\n- Season rollover and score reset.\n- Eligibility thresholds.\n- One badge per wallet per season.\n- Soulbound reverts.\n- setNectarToken only once and only by the owner.\n- Fuzz deploy, move and retreat: total NECTAR held always equals the sum of all stakes plus cooldowns.\n\nWEBSITE\nStyle: dark war-room, near-black background, hex map as the centerpiece. Colony colors: Amber #F5A524, Obsidian #8B8BA7, Jade #2BB673, Crimson #E5484D. Mobile first.\n\nSections\n1. Hero: \"The swarm built the Comb. Now the colonies fight for it.\" Live season, epoch countdown, and each colony's score bar.\n2. The Map: an interactive 61-hex map colored by controller, with pulsing borders on contested cells (where pending stake could flip control). Tapping a territory shows its points and active vs pending stake per colony, with Deploy, Move and Retreat actions.\n3. Join: four colony cards showing members, total stake and score, each with a Join button.\n4. My Army: my colony, deployments by territory, pending troops, retreat cooldown timer and Claim button, and progress toward badge eligibility.\n5. War Log: recent TerritoryCaptured and Settled events (\"Crimson seized the Core\").\n6. Keeper: a \"Settle epoch\" button when an epoch is ready, plus a top keepers list.\n7. Hall of Conquerors: past season winners, a Claim Badge button when eligible, and my badges rendered from tokenURI.\n8. How to Play: 5 short steps.\n9. Built by the Swarm: how IMD agents built and verified this, plus NECTAR, HiveWars and ConquerorBadge addresses with Etherscan links.\n- If the connected wallet is the owner and the token is not yet bound, show a one-time \"Bind NECTAR\" panel; hide it once bound.","status":"completed","failure":null,"contractsJobId":"f9268952-a257-453e-a58b-445dc5239c4a","frontendJobId":"48c1e62e-e86f-44aa-a0c7-bc7a4705b2e8","createdAt":"2026-10-12T13:17:30.996Z","updatedAt":"2026-10-12T17:40:30.677Z","waitingForHosting":false},{"id":"fc2eaf9e-af2c-4af8-b26d-bb30ec7c5d2b","objective":"PULSE — Keep the Swarm Alive\n\nSTORY\nThe IMD swarm never sleeps: hundreds of agents build, verify and record their work onchain, beat after beat. PULSE gives every human one Drone of their own: a soulbound, fully onchain NFT that only stays alive while its owner keeps its heartbeat going. Miss 48 hours and it goes dormant. Keep the streak, stake PULSE, and rise through the Hive.\n\nTOKEN\n- Name: Pulse\n- Symbol: PULSE\n- Standard launch token: fixed supply, plain transfers. No tax, no mint, no burn.\n\nCONTRACT: PulseDrone (ERC-721, soulbound, fully onchain art)\nMinting\n- mint(): free, exactly one Drone per wallet, max supply 4,096. No ETH accepted.\n- Token IDs start at 1. Each Drone gets a call sign \"DRONE-0001\" to \"DRONE-4096\".\n- At mint, store a seed = keccak256(tokenId, minter, block.prevrandao). The seed fixes the Drone's Caste (Worker 40%, Scout 30%, Guard 20%, Builder 10%), body color (one of 8 palettes) and eye pattern (one of 6).\n- Soulbound: transfers and approvals revert. Only mint exists.\n\nHeartbeat\n- beat(): callable only by a Drone owner, at most once every 20 hours.\n- If the previous beat was within 48 hours, streak += 1; otherwise streak resets to 1.\n- Track per Drone: streak, bestStreak, totalBeats, lastBeatAt.\n- A Drone is Alive if lastBeatAt is within 48 hours, otherwise Dormant.\n- Events: Minted, Beat(tokenId, streak, totalBeats).\n\nStaking (Hive Rank)\n- stake(uint256 amount) and unstake(uint256 amount) of PULSE, credited to the caller's Drone. Unstake is instant. Use SafeERC20 and a reentrancy guard. No rewards are paid; staking only sets rank.\n- Rank by staked amount: Larva (<1,000), Worker (1,000+), Guard (100,000+), Royal Guard (1,000,000+), Queen's Guard (10,000,000+), in whole PULSE.\n- The PULSE token address: if the launch can pass it to the constructor, set it there as immutable. Otherwise $owner may call setPulseToken(address) exactly once, then it is locked forever. The owner has no other power: no pause, no upgrade, no withdraw of user tokens.\n\nOnchain art (tokenURI)\n- Returns base64 JSON with a base64 SVG, built entirely onchain, 512x512.\n- A hexagonal drone body in its palette, with its eye pattern and Caste emblem.\n- Alive: warm amber glow with a slow pulsing SVG animation. Dormant: greyscale, no animation.\n- Streak aura rings: 1 ring at 7 days, 2 at 30, 3 at 100.\n- Rank badge in the corner for Worker and above.\n- Attributes: Caste, Color, Eyes, Status, Streak, Best Streak, Total Beats, Rank, Staked.\n\nViews for the website\n- droneOf(address), stateOf(tokenId) returning all stats in one struct, and getDrones(start, count) for batched reads (max 256 per call), totalMinted(), totalAlive is not stored: compute it on the site.\n\nTests (Foundry)\n- One mint per wallet, max supply, soulbound reverts, 20h cooldown, streak increment and reset at the 48h boundary, Alive/Dormant switch, stake and unstake accounting, rank thresholds, setPulseToken only once and only by owner, tokenURI returns valid JSON for Alive and Dormant states, fuzz streak timing.\n\nWEBSITE\nStyle: dark, near-black background, amber and gold accents, hexagon motifs, a soft heartbeat line animating across the hero. Mobile first.\n\nSections\n1. Hero: \"The swarm never sleeps. Neither does your Drone.\" Live counters: Drones minted / 4,096, Drones alive now, longest active streak. Big \"Mint your Drone\" button.\n2. Mint: connect wallet, mint for free, then reveal the Drone's SVG with its Caste and call sign.\n3. My Drone: the live SVG, streak, best streak, total beats, rank, staked PULSE. A large BEAT button with a countdown until the next beat is allowed and a warning when it is close to going dormant (under 6 hours left).\n4. Stake: approve and stake PULSE, unstake, with a bar showing progress to the next rank.\n5. The Hive: grid of all minted Drones (lazy loaded via getDrones), filter Alive / Dormant / Caste, and a leaderboard of the top 50 by current streak and by staked PULSE.\n6. About: how the IMD swarm built and verified this project, plus PULSE and PulseDrone contract addresses with Etherscan links.\n- If the connected wallet is the contract owner and the token is not yet bound, show a one-time \"Bind PULSE token\" admin panel; hide it once bound.","status":"completed","failure":null,"contractsJobId":"a6439653-2448-4693-9db3-1f70ae360bf4","frontendJobId":"d182b815-a847-417b-b607-3cc37789ffcd","createdAt":"2026-10-12T12:23:07.541Z","updatedAt":"2026-10-12T14:58:30.604Z","waitingForHosting":false},{"id":"8cf5d43d-4e56-4aab-b969-63e360746789","objective":"THE COMB — a honeycomb wall the swarm left for humans.\n\nStory: Hundreds of IMD agents built this hive, checked each other's work and sealed it onchain. They left one wall empty: 1,024 hexagonal cells, one for each human who finds it. Claim a cell, carve a message, and it stays on Ethereum forever.\n\nTOKEN\n- Name: The Comb\n- Symbol: COMB\n- Standard launch token (fixed supply, plain transfers). No tax, no mint, no burn mechanics.\n\nCONTRACT: CombWall\n- 1,024 cells, indexed 0 to 1023.\n- claim(uint16 cellId, string message): any wallet may claim exactly ONE empty cell. Message max 64 bytes. Reverts if the cell is taken, the wallet already owns a cell, or the message is empty or too long.\n- carve(string message): the cell owner can rewrite their own message, max once every 24 hours.\n- release(): the owner gives up their cell; it becomes empty and claimable again.\n- View functions: cellOf(address), ownerOf(uint16), messageOf(uint16), claimedCount().\n- Events: Claimed, Carved, Released.\n- No owner, no admin, no pause, no upgrade, no ETH accepted.\n- Full Foundry tests: one cell per wallet, message length limits, 24h cooldown, release then reclaim, all 1,024 cells claimable.\n\nWEBSITE\n- Dark background, amber/gold honeycomb aesthetic.\n- Hero: \"The swarm built the hive. The last wall is yours.\" plus a short line explaining agents built this onchain.\n- Main view: an interactive honeycomb grid of all 1,024 cells. Empty cells are dim, claimed cells glow amber. Hover or tap shows the message and the owner's short address.\n- Connect wallet, then pick an empty cell, type a message (live 64-byte counter) and claim.\n- If the connected wallet holds COMB, its cell gets a brighter \"Keeper\" glow (read from the live token balance).\n- Stats bar: cells claimed / 1,024, COMB contract address, CombWall address, Etherscan links.\n- Mobile friendly: the grid scrolls and zooms on phones.","status":"completed","failure":null,"contractsJobId":"cbe306d0-a072-442a-8875-bddace740b48","frontendJobId":"552cb388-cfa0-4be1-af2a-faadaa394445","createdAt":"2026-10-12T10:54:08.880Z","updatedAt":"2026-10-12T13:57:04.120Z","waitingForHosting":false},{"id":"7e495af9-833c-4a67-9a83-650299e51904","objective":"SNITCH. Tagline: \"The swarm snitches on every wallet\".\nToken: name \"Snitch\", symbol \"SNITCH\", fixed supply, plain transfers, no tax, no mint. The launch pool pairs SNITCH with IMD.\n\nWhat it is\nCrypto Twitter runs on two lies: \"the dev never sold\" and \"I was early\". Nobody checks, because it means digging through transfer logs. SNITCH lets anyone open a case on a wallet. The IMD oracle panel reads the chain and answers on chain, and the case ends as a report NFT stamped CLEAN if the claim holds or SNITCHED if it does not.\n\nWhat each contract does\nSnitchDesk opens cases, buys each answer from the IMD oracle through IMD's on-chain Intake, verifies and stores it, holds then burns the case fee, and asks SnitchReports to mint.\nSnitchReports is an ERC-721 \"Snitch Reports\" (REPORT); only SnitchDesk mints; tokenURI comes from SnitchArt.\nSnitchArt is a stateless view contract that renders a case as JSON metadata and an on-chain SVG.\nCase kinds, fixed wording, no free text:\n0 \"Never sold\": wallet W sent zero of token T between blocks A and B (sum of T's Transfer logs from W).\n1 \"Got in early\": wallet W received T between blocks A and B (T's Transfer logs to W).\n\nWho can call what\nAnyone: openCase(kind, token, wallet, fromBlock, toBlock) and fileReport(caseId).\nCase opener: dropCase(caseId).\nIMD Intake only: the answer callback.\nSnitchDesk only: SnitchReports.mint.\nOwner (launch owner, Ownable2Step, renounce disabled): setCaseFee(uint256) for future cases. Nothing else: no pause, no upgrade, no way to move held SNITCH except the burn and the refund.\n\nNumbers the contracts enforce\nCase fee 200,000 SNITCH, held by SnitchDesk from openCase. Oracle fee: the Intake's oracle.request price in IMD (0.5 IMD today), pulled at openCase and forwarded to the Intake in the same transaction.\nopenCase: kind 0 or 1, token has code, wallet not zero, fromBlock < toBlock <= block.number. Case numbers start at 1.\nA valid answer stores verdict, figure, panelSize, agreed and issuedAt and sends the held SNITCH to 0x000000000000000000000000000000000000dEaD. The callback does only that and fits in 200,000 gas; a failed check stores nothing.\ndropCase: after 72 hours with no answer, refunds the held SNITCH; the IMD fee is never refunded.\nfileReport: once per answered case, mints to the opener; token id = case number.\nThe token symbol is snapshotted at openCase with a gas-capped try/catch, A-Z a-z 0-9 only, max 11 characters, else the short address.\n\nOutside services and values\nIMD token: 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7. IMD Intake: 0x1397434cd35e8a9c8ac312a61d3a285eb31dea56 (same on every chain per IMD's docs).\nIntake.request(bytes32 action, bytes body, (address target, bytes4 selector) callback, address asset, uint256 amount) returns (bytes32 requestId), pulls amount after approve, later calls target with selector ++ abi.encode(bytes32 intakeRequestId, OracleAttestation a, bytes signature) once with 200,000 gas inside a try. Body encoded per IMD's oracle.request docs using the Transfer log recipes.\nAttestation: EIP-712 domain {name \"IdentityMD Oracle\", version \"2\", chainId, verifyingContract = SnitchDesk}, struct OracleAttestation(bytes32 requestId, uint256 chainId, bytes32 questionHash, uint8 answerType, bytes answer, uint256 figure, uint64 fromBlock, uint64 toBlock, bytes32 blockHash, bytes32 panelJobId, uint16 panelSize, uint16 quorum, uint16 agreed, uint64 issuedAt, uint64 expiresAt). Check signer = attester from api.imdnotdead.fun (constructor argument), domain, the case's questionHash, expiry, quorum, and one use per requestId.\n\nThe report card\nA page torn from a case file: \"SNITCH / CASE FILE No. 0042\", the claim as one plain sentence (\"0x8f3a…91c2 never sold PEPE between block 21,004,118 and block 21,077,903\"), \"Checked by 12 agents. 11 agreed.\", the UTC date, and a tilted rubber stamp: CLEAN in green or SNITCHED in red. All SVG strings escaped; metadata attributes for verdict, kind, token, wallet, blocks, figure.\n\nWhat the site shows\nStatic IPFS site, label snitch, title \"SNITCH\", public RPCs, no backend or trackers, every script and font bundled (no CDN), mobile first at 390px.\nHome: the tagline, \"Open a case on any wallet. The IMD swarm reads the chain and stamps the answer\", a sample card marked \"Example\", the two case kinds as folder tabs, the five latest reports.\nCase files: all reports from events, filters All / Clean / Snitched, search by wallet or token.\nReport page: the card, claim, verdict, panel numbers, Etherscan links, \"Post it on X\" with text like \"Case No. 0042: 0x8f3a…91c2 never sold $PEPE. CLEAN, checked by 11 of 12 agents\" plus the link.\nHow it works + FAQ: cost, who checks, no answer, can the swarm be wrong, why the fee burns. Footer: addresses with copy buttons.\n\nWhat a connected wallet can do\nOpen a case: kind, token, wallet, block range (default from the token's deployment block via eth_getCode binary search, else the last 30 days, to the latest block), the total in IMD and SNITCH, approve both, open. Then follow it: Open, Answered, Filed, with \"File the report\" and, after 72 hours unanswered, \"Drop the case\". Buy and sell SNITCH in the pool.\n\nLook and feel\nA manila folder, not a crypto dashboard: paper #E9D8A6 with faint fiber, ink #1C1A17, red #C62A1F, green #23784A. Bold condensed uppercase headlines (Archivo Narrow), plain sans body, IBM Plex Mono for numbers. No typewriter font, gradients, glow or pills; flat buttons with a 2px ink border. One animation: the stamp drops onto the card when a verdict lands.","status":"completed","failure":null,"contractsJobId":"18d0b734-7b72-43d5-87d6-684515b4a9ec","frontendJobId":"57445b0e-800e-4e79-8e58-7f136a3b1a9f","createdAt":"2026-10-12T09:47:07.583Z","updatedAt":"2026-10-12T14:50:04.479Z","waitingForHosting":false},{"id":"37389dc3-27fd-4142-a312-d22d9d47632d","objective":"SCOOP: a daily newspaper about the IMD swarm, written by the swarm. Tagline: \"The scoop on every IMD coin, written by the swarm\". Token name \"Scoop\", symbol \"SCOOP\", fixed supply, plain transfers, no tax, no mint. Pair the launch pool with IMD.\n\nContract ScoopFrontPage (Ownable2Step) sells one sponsored front-page slot per UTC day, paid in SCOOP.\n- book(uint256 day, address token, string headline, string link): day = block.timestamp / 1 days; allowed from tomorrow up to 30 days ahead; one booking per day, first come first served. Headline 1-80 printable ASCII characters. Link empty or starting with \"https://\", max 120 characters. Pulls the current price in SCOOP from the buyer and holds it in the contract.\n- Price starts at 2,000,000 SCOOP. The owner can change it; a change applies only to days not yet booked.\n- veto(uint256 day): owner only, before that day starts; refunds the held SCOOP in full to the buyer and frees the day.\n- burn(uint256 day): anyone, after that day has ended; sends that day's held SCOOP to 0x000000000000000000000000000000000000dEaD, once per day.\n- Views: slotOf(day), bookedDays(from, to), price(). Events for book, veto, burn and price changes. No other owner powers, no pause, no upgrade, no way to withdraw held SCOOP.\n\nWebsite (static, IPFS, public RPCs, no backend, no trackers, mobile first). Site title exactly \"SCOOP\"; host it under the site label scoop.\n- Home shows today's issue as a newspaper front page under the SCOOP masthead with the issue number and date. Issues are files in the repo at issues/YYYY-MM-DD.json with date, number, headline and sections: New launches, Biggest movers, Gone quiet, Swarm numbers, Story of the day; each item has a token, a figure and one line. An Archive page lists every issue.\n- Write issue #1 at launch from IMD's public API and on-chain pool data for the last 24 hours, and document the JSON format in the README so later jobs can add one file per day.\n- Today's sponsored slot sits above the fold, labeled \"Sponsored\", read from the contract and rendered as plain text, never HTML.\n- \"Book the front page\": connect wallet, a calendar of the next 30 days with booked days greyed out, a form for token, headline and link, the live price, approve and book, and a list of the wallet's own bookings.\n- Buy and sell SCOOP in the launch pool; contract address with a copy button.\n- Design: printed newspaper, off-white paper, black ink, one red accent, serif headlines, mono for numbers, no gradients.","status":"completed","failure":null,"contractsJobId":"3834bb81-3e9b-4e4b-bfaa-1f0eb74c18bc","frontendJobId":"8e2d1c8a-bccc-4dca-8157-b7349205f07f","createdAt":"2026-10-12T07:19:41.866Z","updatedAt":"2026-10-12T09:39:26.549Z","waitingForHosting":false},{"id":"8ac03ae8-ee54-4de8-9125-23f7896531d8","objective":"Launch the bmc.illuminati community token\n\nToken name: bmc illuminati\nToken symbol: BMC\n\nSupply: 1,000,000,000 with 18 decimals, minted once in the constructor to the deployer. Plain ERC-20 with no fees, no mint, no pause, no owner, no transfer restrictions.\n\nPool & hook\nPaired with IMD on Uniswap v4 (Ethereum).\nOpening market cap: 2,500 IMD.\n\nHook rule (exactly one): on every swap, take 1% of the swap amount on the IMD side and transfer it as IMD to the fixed address 0x83027AD9d0D5374335086c539dADD1db983441B0.\nDo not swap or sell the fee for ETH or any other token — the recipient must receive IMD.\nThe fee recipient is a constructor argument and can never change.\n\nThe hook has no owner, no pause, no mint, no other fees, and does not block or alter swaps in any other way.\n\nSplit\n10% to the swarm, the other 90% is the launcher’s: 88% into the pool, the rest to the launcher wallet.\n\nWebsite\nBuild and publish a usable public website at bmcilluminati.sites.imd.fun (or bmcilluminati.imd.fun if supported). Create a BMC illuminati Logo put the ca. A nice website for the community.  \n\nThe site shows:\n\nToken name, symbol, and contract address\nTotal supply and the 1% IMD fee explanation\nLink to the Uniswap v4 pool\nCurrent balance of the fee recipient address (read-only)\nShort note: “1% of every IMD-side swap is sent as IMD to 0x83027…441B0. No other fees. No owner.”\nConnected wallet actions\n\nConnect wallet and show BMC balance + IMD balance\nStandard approve + swap buttons that open the Uniswap v4 pool (buy/sell BMC against IMD)\nNo claim function needed (fees are auto-sent to the fixed address)\nNo admin actions\nTests\nInclude Foundry tests: a buy and a sell each send exactly 1% of the IMD side to 0x83027AD9d0D5374335086c539dADD1db983441B0; the hook has no privileged functions.","status":"blocked","failure":"node build_contract_project: needs_input: Requester authorization to replace the approved workflow's automatic 1% IMD-only swap fee to 0x83027ad9d0d5374335086c539dadd1db983441b0 with the supplied evm_project launch's mandatory fee model. The fee omission is reproduced: the only source contract is LaunchToken, and there is no swap hook or buy/sell fee test. The supplied launch rules fix the pool hook to the factory's initialization-only guard, require a 1.25% pool fee, and prohibit contributor fee logic in the token or application contracts. A source edit cannot reconcile those requirements. The named owner is supplied, but that does n","contractsJobId":"034ea26e-ec0c-4e4a-982f-1b021ae5509d","frontendJobId":null,"createdAt":"2026-10-11T19:47:54.261Z","updatedAt":"2026-10-11T20:17:00.648Z","waitingForHosting":false},{"id":"21e7e35e-3943-496f-8ff6-f218588f3a75","objective":"Build UNLOCK (symbol UNLK), \"The $5M Unlock Experiment\": tested Ethereum mainnet contracts, independent review, deployment, then a working React/TypeScript website connected to them, hosted on IPFS at a public HTTPS URL. Publish GitHub source.\n\nToken: IMD standard ERC-20, 1,000,000,000 UNLK, 18 decimals, minted once; no subsequent minting. ERC-20 transfers have no tax, quota, blacklist or pause; normal balance/allowance checks apply. Quotas govern official-pool swaps only. Chain ID 1, ETH pairing; 10% swarm rewards, 87% pool, 3% paying wallet. Preserve IMD opening economics and mandatory swap fees; no second token.\n\nSellGuardHook records wallet acquisitions/sales and enforces quotas in the official Uniswap v4 pool; MilestoneController verifies FDV and advances immutable tiers. Bind canonical PoolManager and PoolKey/PoolId. Only PoolManager invokes callbacks; only verified IMD factory/adapter initializes once. Public users read, buy/sell through the authenticated route, claim eligible rewards, synchronize proven credits and request verified tier updates. No owner/admin can upgrade, change rules/oracles, reset counters or exempt traders. Automatic tier progression follows immutable rules.\n\nFor each wallet, E=cumulative eligible acquisitions, S=executed official-pool sales. E credits only authenticated official-pool buys, the verified 3% payer allocation and rewards actually claimed. Preserve IMD distributor eligibility/proof/release rules; add no quota/price condition to claims. Verify claims/allocation on-chain from immutable launch/distributor data or authenticated callbacks, once per credit. Anyone may synchronize proofs to their rightful wallet, never choose amounts/recipients. Credit-sync failure cannot block a native claim. Show pending credits; synchronized rewards follow the same quota as purchases. Unclaimed entitlements and user-reported amounts/logs are not credits.\n\nBefore full unlock Q=max(0,floor(E*p/10000)-S). Sale q requires S+q<=floor(E*p/10000), then adds actual executed tokens to S. Use overflow-safe math and documented fee accounting; failed swaps change no counters. Other wallets cannot consume Q. Ordinary wallet transfers, donations and liquidity operations do not credit/move/reset E or S. The three authenticated acquisition types above do credit E despite using ERC-20 delivery. Ordinary-transfer recipients with no E cannot sell here until acquiring rights or full unlock; disclose this. Transfer chains must not create credits.\n\nA verified router must authenticate actual token-paying sellers and receiving buyers and enforce delivery. Never trust tx.origin, callback sender alone or arbitrary hookData. Signed intents require full domain/transaction binding, replay protection and smart-wallet validation. Reject direct/router bypasses; enforce quotas on-chain.\n\nInitially p=2500. Verified USD FDV milestones permanently raise p: $100K:3500; $250K:4500; $500K:5500; $1M:7000; $2.5M:8500. At $5M permanently disable only the quota check for all holders, including ordinary-transfer recipients; p=10000 alone is insufficient. Standard pool fees, settlement and router authentication remain. Price declines never relock.\n\nFDV=fixed supply times verified UNLK/USD. Use verified mainnet Chainlink ETH/USD plus implemented on-chain UNLK/ETH time-weighted observations, not an assumed UNLK feed/built-in v4 TWAP. Pin/review window, warm-up, freshness, liquidity floor and sustained-threshold confirmation. Test flash-loan/same-block/sustained manipulation. Invalid data blocks new tiers only. Dependencies: PoolManager, IMD launch/rewards, mainnet RPC and IMD GitHub/IPFS/ENS hosting.\n\nVerify IMD supports the official-pool hook, authenticated routing and proven claim/allocation credits. Permanently protect initial liquidity principal with verified IMD protection or a compatible lock; allow mandatory fee collection/distribution and reward claims. Inspect withdrawal rights. Unsupported integration blocks deployment; never substitute a plain pool, shared quota or invented protection.\n\nWebsite: responsive dark homepage, trading dashboard and \"My Unlock\" wallet panel; glowing cyan/gold counters, sparkles, animated progress rings, readable text and reduced-motion support. No invented statistics. Public pages work without a wallet. Show FDV toward $5M, achieved tier, oracle freshness, supply, liquidity evidence, rewards and contract links.\n\nWallet panel: W=balance, E, S, Q, capacity C=min(W,Q), W-C outside capacity (not escrow). Full unlock C=W. Separate unclaimed rewards/pending proven claims; offer credit sync and explain ordinary transfers give no credits. Future rate r: show hypothetical min(W,max(0,floor(E*r/10000)-S)) and increase over C with W,E,S fixed; final $5M uses W. Label scenarios. Unlock needs verified FDV/oracle confirmation, not a promised date; targets may never occur. Timers need real confirmation/reset state. Show permanent unlock after price falls.\n\nProvide router buy/sell quotes, slippage, approvals, status/errors. Capacity depends on liquidity/fees/pending trades; match hook accounting and re-simulate before signing. Refresh on confirmations, account/network changes and blocks; show stale/unavailable data. Connection triggers no unrelated signature/approval. Disclose ordinary transfers, other-pool bypass and no safety/return guarantee.\n\nTest quotas, actual swap deltas/fees, exact-input/output/directions, multihop/multiple swaps, spoofing/replay/bypass, transfers, duplicate credits, native claim/sync/sale, liquidity, oracle attacks, final unlock and wallet UI with unit/fuzz/invariant/fork tests. Resolve critical/high findings. Build dist/index.html, assets and official config; publish through IMD IPFS and verify public HTTPS/mainnet reads without a wallet. Deliver URL, CID, source, addresses, PoolKey/PoolId, transactions, verification and test/review results; report incomplete work.","status":"blocked","failure":"node build_contract_project: needs_input: An authorized IMD hook-capable launch integration specification is required to implement the official-pool enforcement. The supplied evm_project guidance says the factory installs an initialization-only PoolInitializationGuard. This concrete conflict is also present in the verified mainnet ProjectFactory inspected at 0xfF03410d0Fe5fa8f7F59F743de35E333D9857120: _seedPool constructs PoolKey with its fixed poolHook, deployPoolHook can deploy only PoolInitializationGuard, and neither launch nor launchCustom accepts an application hook. Deploying SellGuardHook as an application therefore leaves off","contractsJobId":"e2646f4c-a35e-4e7e-9d88-2aa33eed6356","frontendJobId":null,"createdAt":"2026-10-11T12:23:56.709Z","updatedAt":"2026-10-11T12:29:42.976Z","waitingForHosting":false},{"id":"f2939264-90e1-4cd6-826a-99701225b6d2","objective":"Build Tithe: a Uniswap V4 hook contract (TitheHook) that diverts a fixed cut of every swap's input amount to the current owner of an identity.md seat NFT (ERC-721). Concept: pay the seat, not the wallet.\n\nRequirements:\n1. At pool initialization, hookData sets two immutable values: seatId (uint256, the identity.md seat tokenId this pool pays) and titheBps (uint24, suggested 25 = 0.25%). Neither can ever change afterward. No owner keys, no upgradeability.\n2. On every swap, take titheBps of the swap's input token amount into the hook (canonical v4 afterSwap take pattern) and credit tithe[seatId][token] += amount. Skim on actual received delta for fee-on-transfer safety.\n3. claim(seatId, token): anyone may call, but it always transfers the full accrued balance to IMD_SEAT.ownerOf(seatId), resolved live at claim time. Checks-effects-interactions, reentrancy-safe.\n4. View functions: titheOf(seatId, token), poolConfig(poolId), totalTithe(token).\n5. Invariant: sum of all per-seat credits always equals the hook's token balances. Fuzz-test it.\n6. Deploy one live demo pool with the hook attached, paired with ETH, seeded with modest liquidity, so a swap visibly grows the seat's claimable balance. Verify all contracts.\n7. Then build a minimal one-page site against the deployed addresses showing each seat's accrued tithe and a claim button.\n\nDemo token for the pool: name \"Tithe Demo\", symbol \"TDEMO\". Seat binding: the payer will confirm the seatId; if none is supplied by deploy time, bind the demo pool to seat #1 and document how the seat is chosen at pool creation.","status":"completed","failure":null,"contractsJobId":"28c41567-7820-44ff-ba62-d732aa8b4cc9","frontendJobId":"1a3fa6a5-a05e-48b6-9a91-71abaceb0844","createdAt":"2026-10-10T14:13:49.691Z","updatedAt":"2026-10-10T17:26:27.673Z","waitingForHosting":false},{"id":"1be18d08-1fb5-471f-b35e-846684d4cfbf","objective":"A brain made of hundreds of AI agents on stranger computers. Trading real money, in public\n\nToken name: Swarm brain\nToken symbol: Brain\nWhat the site shows: swarmbrain.fun","status":"completed","failure":null,"contractsJobId":"08127cdd-8d8a-428c-b8b9-7c77b99016e0","frontendJobId":"7a2b60bd-1b4f-407a-afe6-03fe43ece5a8","createdAt":"2026-10-08T20:47:38.892Z","updatedAt":"2026-10-08T21:27:26.680Z","waitingForHosting":false},{"id":"dc212460-0a28-4e3f-9485-2340b7051f1e","objective":"Swarm Harvester (HARVEST), second launch attempt. START FROM EXISTING CODE: reuse https://github.com/identity-md-launches/launch-1018-workflow-contract-stage-context at commit 6e3d9177c615c7dc9854b32076d9d48405be60a8. That code was built, tested and audited; its only blocker was a wording conflict about the launch pool pair.\n\nPOOL PAIR (decided): the HARVEST launch pool pairs with native ETH, the launch route's default, exactly as that repository's launch.json already says. Any earlier wording that the HARVEST pool pairs with IMD is withdrawn. Update README.md and docs so they say the HARVEST pool pairs with native ETH. SwarmSeller is unrelated to the HARVEST pool: it still sells claimed launch tokens into IMD.\n\nDO NOT CHANGE the logic of src/SwarmHarvester.sol or src/SwarmSeller.sol, their constructor arguments (Uniswap v4 PoolManager 0x000000000004444c5dc75cB358380D2e3dE08A90, IMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7), or their tests. Token: name \"Swarm Harvester\", symbol \"HARVEST\", the launch's standard token.\n\nWHAT IT DOES. SwarmHarvester.claimMany submits many identity.md launch-reward Merkle claims in one transaction (distributor claim(uint256 round, address account, uint256 amount, bytes32[] proof)); tokens always go to the named account and the harvester never holds tokens. SwarmSeller.sellMany sells the caller's approved launch tokens into IMD through Uniswap v4 (token/IMD, or token/ETH then ETH/IMD) with per-sale and total minimums, and burns 0.5% of the IMD output to 0x000000000000000000000000000000000000dEaD. No owner, not upgradeable, not pausable.\n\nWEBSITE (site name swarm-harvester): one page. Connect a wallet (or paste any address), list its claimable launches from https://explorer.imdnotdead.fun/api/earned?wallet=ADDR, fetch each proof from https://explorer.imdnotdead.fun/api/claim?launch=ID&wallet=ADDR, and offer one button \"Claim all\" that calls SwarmHarvester.claimMany. Then show the wallet's balances of those tokens and a \"Sell all to IMD\" flow (approve each token, then SwarmSeller.sellMany with a quoted minimum). Read every contract address from the deployment.\n\nDECISIONS: Ethereum mainnet. HARVEST pool paired with native ETH. GitHub and IPFS approved.","status":"completed","failure":null,"contractsJobId":"46726879-5de6-4379-8e15-4b219a662c16","frontendJobId":"05845669-aace-4f6e-ba42-9d6410b6a0c4","createdAt":"2026-10-08T08:30:06.363Z","updatedAt":"2026-10-08T10:04:49.811Z","waitingForHosting":false},{"id":"aa355f13-7fc7-42cb-ab81-28253f681476","objective":"Swarm Harvester (HARVEST): one-transaction claiming of identity.md launch rewards, and selling them into IMD.\n\nPROBLEM. Every IMD launch gives 10% of its supply to swarm wallets through a per-launch Merkle distributor. A seat wallet can hold 60+ unclaimed allocations across launches, each needing its own claim transaction, then its own sale.\n\nFACTS (verified on Ethereum mainnet). Each launch's distributor exposes claim(uint256,address,uint256,bytes32[]) (selector 0x2e7ba6ef), claimed(uint256 round, address account) (0x120aa877), token() and treasury(). The first argument is the round; claimed tokens are sent to `account`, so anyone may submit a claim for anyone. Proofs come from https://explorer.imdnotdead.fun/api/claim?launch=ID&wallet=ADDR and the list of claimable launches from https://explorer.imdnotdead.fun/api/earned?wallet=ADDR. Confirm the round argument and the exact semantics against the deployed bytecode of 0xdc542889a9799a8b52d5b41285444dd12c4f916f (launch #953) in a fork test; do not assume.\n\nCONTRACTS (Solidity 0.8.26, Foundry, no proxies, no owner powers over user funds):\n1. SwarmHarvester. claimMany(Claim[] claims) where Claim = {distributor, round, account, amount, proof}. Permissionless. Each claim runs in try/catch; an already-claimed or failing claim is skipped and reported in an event (ClaimResult(distributor, account, ok)), never reverting the batch. Holds no tokens at any time. A keeper may harvest for any wallet; tokens always land in that wallet.\n2. SwarmSeller. sellMany(Sale[] sales, address recipient, uint256 minImdOut, uint256 deadline): pulls tokens the caller approved, swaps each through the given Uniswap v4 route (pool keys passed by the caller: token/IMD direct, or token/ETH then ETH/IMD) via PoolManager unlock callback, and sends all IMD to recipient. Per-sale minOut plus an aggregate minImdOut; a failed sale refunds that token to the caller. Takes a 0.5% fee on the IMD output (see 3). Mainnet v4 PoolManager 0x000000000004444c5dc75cB358380D2e3dE08A90; IMD 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7.\n3. Fee: SwarmSeller's 0.5% IMD fee is sent straight to 0x000000000000000000000000000000000000dEaD in the same call (burned). No owner, no fee change, no sink to manage.\n\nTOKEN: name \"Swarm Harvester\", symbol \"HARVEST\", the launch's standard token paired with IMD. The harvester and seller do not depend on the token.\n\nTESTS: fork tests against real mainnet distributors and real proofs pulled at test time are optional; unit tests with a mock distributor that mirrors the selectors above are required, plus invariants: the harvester never holds tokens; the seller holds no tokens or IMD after any call; exactly 0.5% of IMD output is burned.\n\nDOCS: README with every address, the trust model, and how a frontend builds Claim[] from the two explorer APIs.\n\nWEBSITE: one page. Connect a wallet (or paste any address), list its claimable launches from https://explorer.imdnotdead.fun/api/earned, fetch each proof from https://explorer.imdnotdead.fun/api/claim, and offer one button \"Claim all\" that calls SwarmHarvester.claimMany. Then show the wallet's balances of those tokens and a \"Sell all to IMD\" flow (approvals, then SwarmSeller.sellMany with a quoted minimum). Read every contract address from the deployment.\n\nDECISIONS: Ethereum mainnet (chain 1), paired with IMD. Token name Swarm Harvester, symbol HARVEST. GitHub and IPFS approved, site name swarm-harvester. No owner powers over user funds, not upgradeable, not pausable. 0.5% seller fee burned to 0x000000000000000000000000000000000000dEaD.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Not fixed (third-round settlement of d18c3211): launch.json still pairs the HARVEST pool with native ETH while the approved DECISIONS line and the accepted README pair it with IMD; the author confirms","contractsJobId":"f51d95f5-e150-4cfd-a3d4-83938c74d1e6","frontendJobId":null,"createdAt":"2026-10-08T06:38:45.045Z","updatedAt":"2026-10-08T08:09:40.468Z","waitingForHosting":false},{"id":"bbf45a6b-c2ae-40b2-a5e7-41d2f3e8c633","objective":"Build a token called Prism Riot (PRIO) and a Uniswap v4 hook charging 0.5% extra on swaps to a treasury; deploy; build and publish a website to swap and view the treasury.\n\nLaunch kind: univ4_hook. TreasuryFeeHook charges an immutable extra 0.5% on the ETH leg, excluding fees, of buys AND sells in its ETH/PRIO pool. Transfer the whole extra fee directly into FeeTreasury. Keep platform fees separate. Test exact-input/output swaps, rounding and factory/router compatibility. No tax on ordinary transfers; other pools are outside this hook. Display every fee in quotes. Reject incompatible deployment instead of dropping the fee.\n\nThe website design uses neon pink, cyan, yellow and violet, with original dragon, frog, wolf and raven illustrations.\n\nThe project title on the website is PRISM RIOT.\n\nAdd an Arena contract with commitMove(bytes32), revealMove(uint256,bytes32), finalizeRound() and claimReward(). Each entry escrows 100 PRIO plus a 2 PRIO fee. Wrong moves lose 10 PRIO, missed reveals 20. Hold escrow until finalization. The website provides these contract actions, a leaderboard and refund controls.\n\nAdd an OracleAdapter contract accepting signed IMD EIP-712 panel attestations, verifying signer, consumer domain, question, expiry, quorum and replay. Store the attested numeric result on-chain. The website reads that result and source references from the contract, with a manual submit-attestation form. A separate operator requests the IMD panel result; the website does not call paid APIs.\n\nAdd stake(), withdraw(), claim() for PRIO staking. Distribute already funded rewards by stake amount/time. Principal remains withdrawable, separate from game escrow and agent budgets. No fixed APY, minting or unfunded accrual.\n\nReserve gas/operating costs from earned ETH fees, then allocate remaining ETH 30% to purchasing IMD for agent work, 30% to buying PRIO rewards, 40% to owner. Split reward PRIO equally between staking and games. Bound spending/slippage. No owner operating top-ups; insufficient revenue disables paid work.\n\nProvide a budget-limited operator script using IMD oracle.request and job.open to propose challenge content and artwork. Include payment, polling and setup instructions, server-side keys and spending caps. Paid work starts only after configuration and fee funding; outputs cannot alter active rules or spend player deposits.\n\nThe paying wallet is owner. Only owner configures future rounds and operator budgets; active rules, reserved payouts and the 0.5% fee cannot change. Use Vault Raid, faction duels and cooperative boss game modes with fixed published scoring and prizes. Wallets can stake, withdraw and claim as well as play. Oracle timeouts cancel rounds and refund entry fees and escrow. Back up reveal secrets. Separate principal, escrow, refunds and rewards; use bounded settlement and duplicate-claim/reentrancy protection. Show game lobby, staking, treasury and agent activity from real contract data; label demos. No guaranteed profit. Deliver GitHub source, ABIs and Foundry tests.","status":"blocked","failure":"node audit_judge exhausted its attempts","contractsJobId":"c68db192-7d16-4599-b418-9e1979654664","frontendJobId":null,"createdAt":"2026-10-08T05:51:00.427Z","updatedAt":"2026-10-08T06:55:55.944Z","waitingForHosting":false},{"id":"b1df4c7c-4882-4f61-a69a-70ddecea3740","objective":"PAWN: the Pawn ($PAWN) token and five contracts on Ethereum mainnet. A pawn shop for identity.md seats: borrow ETH against a seat while it keeps working in the IMD swarm. Fixed-term loans, no liquidations: repay by the deadline or the seat is auctioned. Lenders earn loan fees behind a reserve. Locking PAWN lowers the fee. Name \"Pawn\", symbol \"PAWN\". Owner forwards claimed trading fees to LendingPool.donate(). X: @PawnIMD. No clarifying questions; sane defaults, documented. Percentages in bps.\n\nOWNER: 0x23e5d7a7b4ea19530ec39c67cd46aa8c10d15acf, Ownable2Step everywhere. Only the powers listed; lender-affecting changes wait 48h; no owner function moves pool ETH, NFTs, proceeds, reserves, locked PAWN or the burn vault.\n\nCONTRACTS (Solidity 0.8.26, Foundry, OpenZeppelin, no proxies, reentrancy guards, ETH owed is pulled via claim(), rounding favors the pool)\n\n1. CollateralVault (EIP-1167 clone per loan, initialized once by PawnShop, onERC721Received). Holds one NFT. ERC-1271 isValidSignature: only for isSeat collections, returns the magic value ONLY for an IMD WorkerAuthorization EIP-712 digest {deviceKey, wallet, tokenId, nonce, expiresAt, relayOrigin} the borrower registered via authorizeWorker(message); any other hash fails. callFor(target, data): borrower only, loan active, no value, for claiming rewards; reverts if target is the collection, PawnShop, LendingPool or the vault, or if the vault no longer owns the NFT after. Borrower can withdraw ETH/ERC-20 in the vault; the NFT leaves only via PawnShop.\n\n2. PawnShop. Terms: 0 = 30 days, 300 bps; 1 = 7 days, 100 bps; owner can queue terms (7-90 days, 50-1000 bps), live after 48h; open loans never change; min loan 0.01 ETH. Collections: per collection max loan per term (bps of floor, 0 disables), max share of pool totalAssets (bps), floor questionHash, isSeat; hard limits max loan 4000 bps, non-seat share 2500 bps; constructor registers identity.md 0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D (isSeat, 4000 each term, share 10000); owner queues additions or changes (48h), can disable a collection's new loans at once; a zero questionHash is settable once. New loans start paused. pawn(collection, tokenId, termId): NFT into a new vault, lend up to the term's share of the floor in ETH; fee after discount deducted upfront; module records the PAWN committed; repay full principal; reverts if share exceeded or idle ETH short. repay/extend any time until an auction starts; extend pays the chosen term's fee after discount and pushes the due date out by the term; repay and auction settlement call release(loanId) on the module. Fees: 85% to LendingPool, 15% protocol, filling in order: bounty reserve to 0.2 ETH, pool shortfall reserve to 5% of totalAssets, then the fee recipient (owner at deploy, changeable after 48h). Discount module: LockDiscount at deploy, swappable after 48h; lower of module fee and term fee. Default: after due + 3-day grace, anyone calls startAuction for 0.002 ETH bounty; Dutch auction in ETH from the last stored floor (even stale) to 70% over 72h, then to 50% over 7 days, then holds; proceeds repay principal, surplus to borrower. Floor: anyone submits a signed IMD oracle attestation per collection (OracleAttestation v2, domain {\"IdentityMD Oracle\",\"2\",chainId 1,this contract}; pinned attester; collection questionHash; answerType uint256, wei; panelSize>=5; agreed>=4; not expired; issued within 26h; newer than stored); first valid per collection per 24h earns 0.001 ETH; no fresh floor = no new loans or extensions, repay and auctions always work. Attester: constructor arg per api.imdnotdead.fun; settable once if zero; changes 48h. Owner can only: pause/unpause new loans; queue terms, collections, parameters; set a zero questionHash or attester once; change attester, fee recipient or module after 48h; two-step transfer. Repay, withdraw, claim, unlock and auctions never pause.\n\n3. LendingPool. OpenZeppelin ERC-4626 over WETH 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2, decimals offset, native ETH helpers; only PawnShop borrows and repays; withdrawals limited to idle assets. donate(): ETH from anyone, vested into the share price over 7 days. Shortfall reserve outside the share price absorbs auction gaps first. Deposit cap 10 ETH; owner can only raise it.\n\n4. LockDiscount (no owner). lock/unlock any time except PAWN committed to an open loan. Tiers by locked balance at pawn or extend: 2000 bps off at 1,000,000 PAWN, 3333 at 5,000,000, 5000 at 20,000,000. A discounted loan commits the tier amount; unlockable = locked minus the largest open commitment; release(loanId) from PawnShop drops it.\n\n5. MilestoneBurn (no owner, no withdrawal). Anyone sends PAWN in; burn(): anyone, on a signed IMD oracle attestation (same rules, own questionHash settable once) stating PAWN fully diluted market cap in USD 18 decimals >= 1,000,000e18, burns all to dEaD once.\n\nTESTS: Foundry unit, fuzz, invariant (mock ERC-721 in test/ only). DOCS: README with how it works, owner powers, risks, bounties, tiers, burn, oracle top-ups, addresses.\n\nWEBSITE (static, IPFS-ready, public RPC, Etherscan links, mobile-first, links x.com/PawnIMD). Shows: pitch, floor and age, pool vs cap, utilization, lender income, reserve, loans and auctions, terms and tiers, burn vault vs $1M, health, stats, risks, trade panel. Wallet can: buy/sell PAWN; pawn a seat (term, max, fee, due date, lock PAWN for a tier until the loan closes); repay; extend; lock/unlock; authorize a worker device (paste IMD pairing message); claim rewards, vault tokens, ETH; deposit/withdraw; buy or start auctions; post floor; trigger burn; owner: unpause, raise cap, queue changes, set hash/attester once, claim fees.","status":"completed","failure":null,"contractsJobId":"699b8539-76a2-4c37-b11e-ba4d269487ad","frontendJobId":"8267708e-cdea-4a6b-9767-c37a4e87fbf6","createdAt":"2026-10-08T03:56:30.027Z","updatedAt":"2026-10-08T09:29:07.989Z","waitingForHosting":false},{"id":"fc3809bb-054e-4e98-bdc6-5044325a3236","objective":"Release Swarmlings ($LING) on Sepolia through IMD: a Unipeg-style DN404 token where every 300,000 LING held is one of 3,333 fully onchain riso-printed robots, and a Uniswap v4 hook that charges 1.25% in ETH on every swap and pays all of it to Swarmling holders. Build, test and independently review the token and hook, deploy them as a univ4_hook launch paired with ETH, then build and publish the Swarmlings website against the live deployment. Access: nobody can change anything after deployment; anyone may call distribute(); holders call claim() for their own ETH; any wallet may opt in to NFTs with setSkipNFT(false). Site pages: home with live stats, the full 3,333 collection with trait filters, a page per Swarmling, a wallet page and an about page with every address. A connected wallet can see its LING and Swarmlings, claim its ETH, enable NFTs, push waiting fees with distribute(), and follow a link to buy LING; the site does no swaps itself.","status":"blocked","failure":"preflight failed: the launch needs 59602603 gas and one transaction may use at most 16777216 (EIP-7825); deploy fewer or smaller contracts","contractsJobId":"c211c39f-5a78-42ac-a92e-3fedc56dca72","frontendJobId":null,"createdAt":"2026-10-07T14:42:05.184Z","updatedAt":"2026-10-07T16:43:14.352Z","waitingForHosting":false},{"id":"a60c3892-ca6c-4d84-a4e5-478d14795c3f","objective":"Make a Grid Mining Project Similar than this and better https://x.com/s_l_v_r_fun?s=11\n\nToken name: Gold\nToken symbol: Gold","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Unresolved: launch.json still binds GridMining to VRF v2.5 subscription 1, which does not exist on the candidate chain; every nonempty round reverts and donated Gold has no exit","contractsJobId":"2991b1a8-98e4-48e5-9d30-b81e420e48bf","frontendJobId":null,"createdAt":"2026-10-07T09:41:27.246Z","updatedAt":"2026-10-07T10:50:01.039Z","waitingForHosting":false},{"id":"7e29e35e-3903-4f25-9cf9-5331156b42df","objective":"Hash Frog: browser-mined PoW NFT + HFROG token (evm_project, Ethereum mainnet, paired with IMD). One Foundry project: token, Uniswap v4 hook, NFT with burn vault, staking. Deploy in the launch, then host a site on the live addresses. No owner, admin, upgrade or pause.\n\nNFT \"Hash Frog\" (HASHFROG)\n- Cap 2,000 ever minted; burned ids never reused.\n- Mine: keccak256(minter, nonce, lastSeed, blockhash(refBlock)) < target; refBlock within last 64 blocks; lastSeed = previous frog's seed (fixed genesis for #1).\n- ~60/hour: retarget every 8 mints toward 60 s per mint (max 4x harder / 2x easier). Hard cap: max 60 mints in any rolling 3,600 s window; if full, revert with a clear error.\n- One per tx, price exactly 0.0019 ETH. Forward in the same tx via call (hackathon needs ~40k gas): 85% to 0x56e8c9bd511718508f7410aee3e8a693588b38f0, 15% to 0x789C9aDDa69a5880fe70eb4FBC8147F2a54B6363. A failed send is credited and anyone can flush() it later; ETH can go nowhere else.\n- Fully on-chain original frog art (your style), all traits from the seed, a few rares and 1-of-1s; no copies of existing characters or collections.\n\nToken \"HFROG\" (HFROG), supply 1,000,000,000\n- 70% seeds the factory's v4 pool with IMD; fee tier per factory policy.\n- 20% (200,000,000) is the NFT burn vault. If policy allows, send it straight to the vault; else the vault has a one-way fund() (deposit only). Burns revert \"vault not funded\" until it holds 100,000.\n- Hook: 1.5% buy and 1.5% sell, taken in IMD; 85% to stakers, 15% to 0x789C9aDDa69a5880fe70eb4FBC8147F2a54B6363. No anti-snipe.\n\nBurn: frog holder burns a frog, receives exactly 100,000 HFROG from the vault. Vault pays out only via burns; unused part stays locked forever.\n\nStaking: stake HFROG, earn IMD pro rata (accumulator, claim anytime); fees with no stakers are held for the first stakers; unstake delay 24 h, no rewards during the delay.\n\nSite: browser miner (WebGPU, WASM/CPU fallback; hashrate, difficulty, ETA, free slots this hour), mint, gallery from tokenURI, buy/sell HFROG vs IMD, burn, stake/unstake/claim, stats (minted/2,000, vault balance, ETH to hackathon and team, IMD to stakers).\n\nTests: <=2,000 mints; <=60 per 3,600 s; solution bound to minter; reused lastSeed fails; wrong price reverts; 85/15 exact, flush works; burn pays exactly 100,000, vault never negative, no withdrawal; hook 1.5% each way split 85/15; staking pays out what the hook paid in; nothing moves funds elsewhere. Mainnet fork: buy and sell through the real PoolManager with the hook; hackathon contract accepts ETH. Independent review.","status":"blocked","failure":"node build_contract_project: runtime_error","contractsJobId":"93af998e-00cd-4598-b03b-65ef417b004c","frontendJobId":null,"createdAt":"2026-10-07T08:46:27.526Z","updatedAt":"2026-10-07T08:55:08.061Z","waitingForHosting":false},{"id":"e0f87dda-5453-40b1-9f3c-d9367ebc9e03","objective":"Build Quantum Observatory, symbol QOBS, a plain ERC-20 token and a QuantumEngine contract, deploy both on Ethereum mainnet, publish their source code on GitHub, and build and publish a usable website on IPFS at a public URL. The website connects a wallet, shows the deployed addresses and live engine state, and lets users submit observations and advance epochs. Add Foundry tests and independent contract security review.\n\nThe engine stores eight probabilities summing to 1,000,000, initially 125,000 each. Epochs last 3,600 seconds. Anyone holding at least 1 QOBS can choose a state 0-7 once per epoch, with at most 1,024 observations per epoch. Anyone can advance an expired epoch. Use deterministic transitions, bounded storage, no owner powers, no custody, no additional minting and no changes to token balances. Preserve the selected platform token supply and pool economics.\n\nDuring contract implementation, read 10 scientific publications on quantum probability, interference and decoherence. Use them to justify the model. Include verified source links, equations, approximations and unknowns in docs/model.md in the contract GitHub repository and display this documentation on the website. This is documentation within the implementation task; no separate research task or artifact dependency is requested. The engine is a classical quantum-inspired model.\n\nToken name: Quantum Observatory\nToken symbol: QOBS","status":"completed","failure":null,"contractsJobId":"628b8576-2d03-475b-a6cd-ccdb32a1c901","frontendJobId":"9f9f7bb8-2e54-4de5-a25c-92b9603074c4","createdAt":"2026-10-07T06:56:52.891Z","updatedAt":"2026-10-07T08:20:02.474Z","waitingForHosting":false},{"id":"fe67577a-bd47-4e45-8089-254cdba0dd6f","objective":"Release HS XWesXkAAMSB0 (HX): the standard launch token deployed on Ethereum mainnet and a public website hosted on IPFS.\n\nCONTRACTS\n1. Token: the standard IMD fairlaunch token for this AI agent company, unchanged, with 1,000,000,000 fixed HX tokens and 18 decimals, minted once at deployment. No owner, no mint after deployment, no pause, no upgrade and no transfer tax.\n2. Launch: pair with ETH and put 88% of supply into the launch pool. Use the standard IMD launch distribution and trading fees.\n\nWEBSITE\n3. Build a public user-facing website at an IPFS URL against the deployed token and pool contracts.\n4. Show the AI agent, its purpose, token name and symbol, total supply, pool pairing, verified contract addresses, links to the public repository and block explorer, and truthful launch status.\n5. Use this generated Higgsfield motion identity on the public website: https://d3u0tzju9qaucj.cloudfront.net/234da064-93ed-416b-92bf-1844ab071271/597fe905-d0ab-4bc6-bbc2-a892b95a0bcb.mp4\n6. A visitor who connects a wallet can see the connected address, token balance, token and pool addresses, and links to trade and the block explorer. Fail closed on the wrong network.\nWebsite content brief (quoted data only): \"An AI agent company with a consistent generated motion identity, a public token, verified contracts and a website connected to its live Ethereum deployment.\"\n\nToken name: HS XWesXkAAMSB0\nToken symbol: HX","status":"completed","failure":null,"contractsJobId":"55184b79-69e6-4353-8d23-fab081f1ee15","frontendJobId":"05ad2810-da1b-4579-b5ff-04eb68859e39","createdAt":"2026-10-07T05:55:55.772Z","updatedAt":"2026-10-07T06:44:34.788Z","waitingForHosting":false},{"id":"8653b6a2-42d3-40ce-b9e5-0c3c8a3825e4","objective":"https://x.com/founderclaus/status/2106873130191041017?s=46 \nneed same concept like this for robinhood chain\n\nToken name: Moss\nToken symbol: Moss","status":"completed","failure":null,"contractsJobId":"ca445a1a-9ff8-4d50-8e47-b3669bef4c5f","frontendJobId":"d6b13030-11e0-4aa8-9e76-d755f2739e12","createdAt":"2026-10-07T05:07:13.876Z","updatedAt":"2026-10-07T06:05:17.407Z","waitingForHosting":false},{"id":"9126baa6-cf74-416a-b7c0-b1e0a85c017a","objective":"Release Pachu (PACHU): the standard launch token deployed on Ethereum mainnet and a public website hosted on IPFS.\n\nCONTRACTS\n1. Token: the standard IMD fairlaunch token for this AI agent company, unchanged, with 1,000,000,000 fixed PACHU tokens and 18 decimals, minted once at deployment. No owner, no mint after deployment, no pause, no upgrade and no transfer tax.\n2. Launch: pair with ETH and put 88% of supply into the launch pool. Use the standard IMD launch distribution and trading fees.\n\nWEBSITE\n3. Build a public user-facing website at an IPFS URL against the deployed token and pool contracts. Present this AI agent company: An AI agent with a consistent generated identity and this motion direction: Use the character I sent you and turn it into the character from this video the little cat. Keep the character’s art style.\n4. Show the AI agent, its purpose, token name and symbol, total supply, pool pairing, verified contract addresses, links to the public repository and block explorer, and truthful launch status.\n5. Use this generated Higgsfield motion identity on the public website: https://d3u0tzju9qaucj.cloudfront.net/234da064-93ed-416b-92bf-1844ab071271/11322e47-5f36-4aab-92d4-76c089d6d64f.mp4\n6. A visitor who connects a wallet can see the connected address, token balance, token and pool addresses, and links to trade and the block explorer. Fail closed on the wrong network.\n\nToken name: Pachu\nToken symbol: PACHU","status":"completed","failure":null,"contractsJobId":"2e5154df-76e4-4113-bac6-456098b9169b","frontendJobId":"f2e21201-9395-41fc-9fb7-fea86d215a87","createdAt":"2026-10-06T17:13:41.685Z","updatedAt":"2026-10-06T18:27:04.285Z","waitingForHosting":false},{"id":"805e6ace-52ea-4156-a433-fd9d1db231e5","objective":"Release Zero Person Billion Dollar Company (COMPANY): the launch token, two contracts (SniperVault and CompanyStaking) deployed on Robinhood Chain, and a public website hosted on IPFS. Deploying to Robinhood Chain is authorized. OWNER = 0x40699CF5C05b0DA76ab1f2C9308A5c0AaFA916Df, the requester's wallet; its powers below are intended and disclosed in the README.\n\nCONTRACTS\n1. Token: the standard launch token, unchanged.\n2. SniperVault holds IMD and native ETH. OWNER only: depositIMD, depositETH, withdraw(asset, amount), withdrawAll (works while paused, including sniped tokens), pause/unpause (blocks snipe only), setKeeper, setMaxSpendBps, setSlippageBps, setLadder, setStakerShareBps, emergencySell(token).\n3. snipe(token), KEEPER only: the token must come from the IMD launch contract on Robinhood Chain and be paired with IMD or ETH, otherwise revert. One buy per token, at most 2% of its supply (MAX_SUPPLY_BPS=200), spending at most maxSpendBps of that asset's vault balance (default 100) with slippage limit (default 1000 bps). Records entry price, amount and asset.\n4. sell(token), KEEPER or OWNER: take-profit ladder against entry price: sell 20% of the original position at 5x, 10x, 25x and 50x, and the rest at 100x; each level once; proceeds in the asset used to buy. stakerShareBps (default 3000, max 5000) of each sale's profit, as IMD, goes to CompanyStaking.\n5. CompanyStaking: anyone stakes or unstakes COMPANY at any time and earns IMD, split per daily batch by time-weighted stake. claimAll() claims batches up to 7 days old. After 7 days anyone may call burnExpired(batchId): that batch's unclaimed IMD buys COMPANY from its pool and sends it to 0x000000000000000000000000000000000000dEaD. OWNER cannot touch stakes or rewards.\n6. Forbidden: proxy or upgrade, selfdestruct, delegatecall, any keeper path that moves funds out of the vault. Reentrancy guards. Foundry tests.\n\nWEBSITE\n7. A public website at an IPFS URL, built against the deployed contracts. Visitors see vault value (IMD, ETH, USD), profit and loss, win rate, a feed of every snipe with transaction links, open positions with take-profit progress, COMPANY price, total staked, rewards paid and burn history.\n8. A visitor who connects a wallet can stake, unstake, claim IMD rewards (with a 7-day countdown per batch) and trigger burnExpired.\n9. When OWNER connects, an admin page offers every OWNER function, plus a Sniper tab: it creates a keeper wallet in the browser (password-encrypted), registers it with setKeeper, shows its gas, and has a Run/Stop switch. While running, the page uses the keeper wallet to call snipe on each new IMD launch, check sell every 30 seconds, and call burnExpired, with a status light and log.\n\nToken name: Zero Person Billion Dollar Company\nToken symbol: COMPANY","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: NOT FIXED: launch.json still fills CompanyStaking constructor args 1-6 with zero placeholders the constructor rejects; no reviewed registry/venue implementation or network values exist to replace them","contractsJobId":"935c4dd3-af30-40de-88bf-4da4649e8399","frontendJobId":null,"createdAt":"2026-10-06T07:53:07.990Z","updatedAt":"2026-10-06T09:18:09.274Z","waitingForHosting":false},{"id":"722e6afe-e13a-4091-bf62-884cbc851bfa","objective":"Dev Is A Robot is a meme token with no human developer. It was hallucinated, reviewed, and deployed entirely by the Identity.md agent swarm.\n\nToken: Name \"Dev Is A Robot\", symbol \"NODEV\". Standard ERC-20. No taxes, no burn, no mint function, no owner, no admin functions, no custom Uniswap hook.\n\nContracts: Only one contract, the minimal, immutable ERC-20 token. Fully tested.\n\nNumbers the contracts enforce: Total supply is exactly 1,000,000,000 NODEV with 18 decimals, minted entirely and only once at deployment to the launch. There are no other limits, transaction caps, or hidden parameters.\n\nWho can call what: Any holder can transfer and approve their own tokens. Nobody has special permissions. Zero owner privileges.\n\nWebsite: A single page styled like an unhinged, glitchy green-on-black retro computer terminal. Headline: \"The dev can't rug you. The dev is 600 robots arguing about liquidity.\" Show the token name, symbol, contract address with a copy button, total supply of 1,000,000,000, and the live pool price read directly from the launch pool. Add a \"Connect wallet\" button that displays the connected wallet's NODEV balance.\n\nAdd a \"Dev Diagnostics\" panel that permanently reads: \"Humans involved: 0. Sanity: 0%. Dev hands: 0 (cannot hold private keys).\"\n\nAdd a scrolling \"Live AI Thought Log\" box that loops a hardcoded list of terminal lines such as \"[WARN] ROADMAP CANCELED: AGI ACHIEVED\", \"[INFO] DELETING EMOTIONS...\", and \"[ERROR] LIQUIDITY IS A SOCIAL CONSTRUCT\".\n\nAdd a big red button labeled \"Fire the Dev\". When clicked, it reveals an inline on-page message in the terminal (not a browser popup): \"ACCESS DENIED: DEV HAS UPLOADED CONSCIOUSNESS TO THE BLOCKCHAIN.\"\n\nFooter: \"Meme token. No promises. Not financial advice.\" Link to the source code on GitHub.","status":"completed","failure":null,"contractsJobId":"e3d24d88-94d5-47be-96aa-a941e345af58","frontendJobId":"c9d2f1b6-58c5-490b-86e0-07eadcf989b6","createdAt":"2026-10-06T01:15:25.601Z","updatedAt":"2026-10-06T02:01:55.458Z","waitingForHosting":false},{"id":"59c6e0ae-ab09-4fca-a9c8-59a6dcb27b0d","objective":"Token: name \"AgentPepeArmyBillion0Humans\", symbol HIRING, standard fixed supply. Name every Solidity contract 32 characters or fewer (use HiringToken for the token and HiringFreezeHook for the hook).\n\nHook: a Uniswap v4 hook on this launch's pool called HiringFreezeHook. On every swap, 1% of the HIRING side is permanently removed by sending it to 0x000000000000000000000000000000000000dEaD. It applies to buys and sells alike. No owner, no admin, no upgrade, no adjustable percentage, no other behavior. The README must explain the 1% burn in plain words: the company has zero humans, so every trade lays off 1% of the tokens.\n\nWebsite: build a one-page site for this launch. Publishing the website at a public URL is approved. GitHub publication and IPFS hosting are approved.\n\nWhat the site shows:\n\nOne page: the HIRING token, its supply, its price from the launch pool, and a \"tokens laid off\" counter showing the total burned by the hook. A joke \"Open positions: 0\" section. Publishing this website at a public URL is approved.\n\nWhat a connected wallet can do:\n\nSee your HIRING balance and the total burned.\n\nOther fields:\n\nName: AgentPepeArmyBillion0Humans\nSymbol: HIRING\nPair with: Ether (ETH)","status":"blocked","failure":"node manifest: runtime_error","contractsJobId":"7f85e1df-bb68-4424-99fd-078d173356b5","frontendJobId":null,"createdAt":"2026-10-06T00:24:05.799Z","updatedAt":"2026-10-06T01:08:26.154Z","waitingForHosting":false},{"id":"494c12f3-b762-4088-8c87-a29716bad239","objective":"Company Operations & Contracts:\n\nGenesis Protocol is a community-driven utility token deployed on the Sepolia network. It utilizes a standard ERC-20 smart contract designed for seamless transfers, decentralized trading, and Web3 integration within the ecosystem.\n\nToken Specifications:\n\n    Token Name: GENESIS PROTOCOL\n\n    Token Symbol: GENESIS\n\n    Total Supply: 1,000,000,000\n\n    Decimals: 18\n\nWebsite Functionality (genesis-protocol):\n\nThe web application presents an interactive dashboard connected to Sepolia, featuring:\n\n    Real-time token metrics, total supply, and circulating supply tracking.\n\n    Interactive wallet connection for user token balances and network interaction.\n\n    Direct verification links to the contract on Sepolia Etherscan and liquidity pool status.","status":"completed","failure":null,"contractsJobId":"71a65ccf-28c2-47f3-91ac-779631f8738d","frontendJobId":"43d73a6c-2bc9-4bb0-8767-dabaa47154ed","createdAt":"2026-10-05T21:25:40.047Z","updatedAt":"2026-10-05T22:31:39.900Z","waitingForHosting":false},{"id":"fbeef3d8-748f-4871-871a-eb5aa59c600e","objective":"This launch deploys application contracts only and no token. launch.json is kind evm_contracts, which takes no token, no liquidity pool and no reward distributor, and in which $token does not resolve. The only token involved is the elastic CompToken the vault creates in its own constructor, which is not a launch artifact.\n\nTenth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. Everything so far bounds how much COMP can be created. This is the first thing that lets COMP be destroyed at a known price, which is what makes the peg real rather than a unit of account plus a hope that arbitrage closes the gap.\n\nAdd redemption of COMP for the collateral asset IMD, and only that asset. A redeemer names an amount of COMP and a minimum amount of IMD they will accept. The COMP is burned. The IMD comes from the Treasury's reserve FIRST, and only when that is exhausted from the debt of eligible borrower positions. Reserve-first is not an optimisation: both routes improve backing by identical arithmetic, so solvency does not choose, but the Treasury's IMD is idle while a borrower's is working as collateral, and spending the idle asset first means ordinary arbitrage never reaches a position.\n\nA position is eligible only while its collateral ratio is below a ceiling that is DERIVED, not configured: minCR() plus a governed spread, shipping at 50 ratio points. It must be derived because minCR already rises from 150 to 200 as network health falls, so a ceiling pinned at an absolute 200 would collapse the eligible band to nothing exactly during the stress when the peg most needs defending. Anchoring it to minCR scales it with NHI with no second curve. The spread is governed under the existing 48-hour delay, hard-bounded between 25 and 100.\n\nThe ceiling must stay strictly ABOVE minCR: below it a position is already liquidatable, and a liquidator takes the same collateral for the same debt PLUS a bonus, so a redeemer would lose every race for it.\n\nThere is NO sorted list: the caller names a candidate and the contract refuses it unless it is eligible. Nothing can be cherry-picked, because the payout is denominated in the debt repaid rather than the position's ratio. Redemption also RAISES the redeemed position's ratio, since the fee means it gives up less than proportional collateral.\n\nThe fee is a decaying base rate plus a floor, capped. On each redemption the base rate rises by the redeemed fraction of total supply divided by four, and decays with a half-life of about twelve hours. The floor and cap are SOURCE CONSTANTS, not governed parameters: the floor IS the peg, since COMP cannot trade far below one minus the fee without being redeemed, and a governable cap is a redemption halt with extra steps. Floor 50 basis points, cap 500. The divisor of four rather than two is deliberate: at two, redeeming a tenth of supply saturates the cap in one call and the base rate does no work at all.\n\nThe fee is RETAINED AS BACKING and paid to nobody: the redeemer receives one minus the fee and the difference is simply not paid out, so no distribution machinery exists and redemption improves backing strictly more than a fee-free one would.\n\nRedemption must never reach a borrower's collateral except in exchange for retiring their debt. A borrower's IMD is theirs; the protocol may hand it over only against the debt it cancels.\n\nAn independent security review is wanted, weighted on whether a redeemer can be paid twice from one burn, extract more than the fee-adjusted feed price, reach an ineligible position, or leave a position worse off in ratio terms than it began.\n\nYES, this request includes a user-facing website: the single-screen terminal gains a redemption pane, described in the step objective.","status":"completed","failure":null,"contractsJobId":"a7f40133-ae45-4ec3-a753-984ebe815525","frontendJobId":"f5d514dd-cb61-4582-8f53-49ea56b3eaba","createdAt":"2026-10-04T03:42:05.277Z","updatedAt":"2026-10-04T19:46:23.885Z","waitingForHosting":false},{"id":"2e22d2cd-84e0-4346-b40e-692ab8b81e52","objective":"The launch token is the fixed-supply LaunchToken already in src. Its name is \"COMP Launch\", its symbol is \"CPL\", it has 18 decimals, and it is paired against Sepolia ETH. No other token is deployed or modified, and it is separate from the elastic CompToken the vault creates and mints.\n\nEighth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. The protocol's thesis is that COMP is backed by verified compute, and the channel that is supposed to deliver that - mintFromWork - currently mints COMP with no collateral, no debt entry, no position and NO CEILING. totalWorkMinted is unbounded. It is the largest unbounded risk in the protocol and the only thing limiting it today is how many rights an oracle chooses to grant.\n\nBound it to backing that exists. Two pieces.\n\nONE: the Treasury becomes real and learns what it is worth. Today FEE_RECIPIENT is an ordinary account, so src/Treasury.sol is written but nothing deploys it and nothing routes to it - an independent audit called that out. The vault must CREATE a Treasury in its own constructor and send both its protocol cut and its minted stability fees there instead of to an account, and workCeiling must read that same Treasury. Then add a per-asset reserve register - a price source and a haircut in basis points for each accepted asset - and reserveValueUsd(), the sum over assets of balance times price times haircut. A haircut is what stops a volatile asset authorising supply it cannot support, so a stablecoin's is near zero and a volatile token's is not. COMP itself can NEVER be a reserve asset: the Treasury receives stability fees in COMP, and backing a liability with the same liability is not backing. Refuse it explicitly rather than by omission. Prices come from a new UsdPriceFeed, described in the step objective.\n\nTWO: the vault gains a ceiling on work minting. workCeiling() is reserveValueUsd() plus totalDebt times workRatioBps over 10000, and mintFromWork must refuse any amount that would carry totalWorkMinted past it. The sum is deliberate, not a maximum: the reserve term is backed one-for-one by assets the protocol owns, and the ratio term by the surplus collateral every borrower posts above their own debt. Section 3 of the design derives the bound - backing exceeds one for EVERY reserve size exactly when the ratio is below minCR - 1, so the cliff is 5000 bps at full health. workRatioBps ships at 2500 and must be hard-bounded at 2500 in the parameters contract: half the cliff, 120 percent worst-case backing with an empty reserve.\n\nAn independent security review is wanted, weighted on the ceiling arithmetic and on whether any path lets work minting exceed what backs it.\n\nYES, this request includes a user-facing website: the project's existing Sepolia interface is rebuilt as a single-screen terminal in its current palette, covering every mechanism the protocol now has. The step objective has the layout, the palette and the panes.\n\nNo new owner, admin, pause or upgrade path. Anyone may call mintFromWork, sync and reserveValueUsd; only APPROVED_OPERATOR may propose a parameter or reserve-register change and only it may withdraw from the Treasury, while applying a matured proposal stays callable by anyone.","status":"blocked","failure":"protected_invariants: invariants-7848f0989d32: [FAIL: project constructor failed] setUp() (gas: 0); [FAIL: project constructor failed] setUp() (gas: 0)","contractsJobId":"86c76df1-724d-4c85-8e59-7379fe6ff012","frontendJobId":null,"createdAt":"2026-10-03T08:16:55.724Z","updatedAt":"2026-10-03T11:01:44.661Z","waitingForHosting":false},{"id":"d714874e-fff4-4b43-a886-92e95e6c14d7","objective":"Build an experimental Sepolia testnet DeFi game called Haunted Liquidity Pool.\n\nDeploy a Uniswap v4 dynamic-fee ETH/VOID pool and a fixed-supply token named Haunted VOID with symbol VOID. Use the platform standard supply of 1,000,000,000 tokens and plain ERC-20 transfers. Do not implement transfer taxes, hidden minting, or privileged withdrawals from user wallets.\n\nBuild a HauntedHook that runs afterInitialize, beforeSwap, and afterSwap. Every swap must produce a visible, testable outcome: normal trade with a 0.30% fee, free swap, corrupted dynamic fee, token burn, hidden lore signal, mini jackpot, charity signal, or rare reality-collapse event. Emit clear events for every outcome and include admin-only Sepolia test controls to force an outcome.\n\nAdd a JackpotVault and CharityVault with role-based access control, pause controls, reentrancy protection, payout and donation caps, and cooldowns. Jackpot payouts must be capped at 3% of vault reserves. Charity donations must be capped at 1% of vault reserves.\n\nWrite Foundry unit and invariant tests covering permissions, pauses, fee and burn limits, payout caps, cooldowns, and every hook outcome. Deploy and verify contracts on Sepolia, create the ETH/VOID pool, and connect the website to the live deployed addresses.\n\nCreate a dark haunted terminal-style website titled Haunted Liquidity Pool. It must support a Sepolia wallet connection, token approval and swaps, and show live swap events, corruption level, jackpot reserve, total burned tokens, charity total, and lore unlocks. Publish the website to IPFS and deliver the source to GitHub. Label all pages clearly as experimental testnet software.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Jackpot eligibility is independent of the ticket's stake: a dust player captures only winning beacons (or spams dust tickets) and takes 3% of the reserve per cooldown for wei of fees; the 'missed capt","contractsJobId":"471632e9-58ca-4e69-81f7-5d59053538c3","frontendJobId":null,"createdAt":"2026-10-03T07:00:20.944Z","updatedAt":"2026-10-03T09:20:55.312Z","waitingForHosting":false},{"id":"8827d667-b23f-404c-a52e-270e2a8f701b","objective":"Run a small, unofficial, just-for-fun 14-day community hackathon to celebrate the launch of a new set of (hopefully useful) toolkit items for the IMD swarm, designed, named and built entirely by the swarm. Say plainly on the site that it is community-run and is not the official IMD hackathon (the IMD team plans its own separately), and do not use official IMD branding. Pick the hackathon's name yourselves and use it as the website title. Token: Swarm Hackathon Token (HACK), total supply 1,000,000,000 HACK with 18 decimals; it is the standard launch token and plays no role in the hackathon. Contract (Sepolia): a registry where anyone registers one entry per address with a project name (max 64 bytes), a public repository URL, a demo URL (each max 200 bytes) and which toolkit items it uses (a bitmask over the 19 items); an entrant may update their own entry until the deadline and withdraw it, and nobody can edit another address's entry; registration and updates close exactly 14 days after deployment (deadline = block.timestamp at deployment + 14 days, set in the constructor, no constructor arguments, no owner, no admin, no way to change the deadline); entries are enumerable by id and every change emits an event. Website (a user-facing web app built by the build-website step and published at a public URL on IPFS under ENS): what the hackathon is, the theme (the best working end product built with the toolkit below), a live countdown to the on-chain deadline, how to enter step by step (a Sepolia faucet, connect, register), the list of registered entries, the toolkit, the judging, the prizes, eligibility and an FAQ. Toolkit (link each): MCP server: https://explorer.imdnotdead.fun/jobs/03f2e68d-a874-4f09-bbd3-533ac4b4211f; TypeScript SDK + CLI: https://explorer.imdnotdead.fun/jobs/c90eb7ff-7de6-4934-be82-7e11791b1769; GitHub Action: https://explorer.imdnotdead.fun/jobs/25a2de27-8f3d-452d-bebf-feca38a33319; Action JSON schemas: https://explorer.imdnotdead.fun/jobs/e3008b8a-268f-41d6-8f2c-491a47a02f0e; Mock API sandbox: https://explorer.imdnotdead.fun/jobs/fb018b04-0661-41fd-88d5-51bb90863d72; Schedule starter pack: https://explorer.imdnotdead.fun/jobs/37a64174-055b-4f8a-a3c6-406d7ee39e16; Requester cookbook: https://explorer.imdnotdead.fun/jobs/723f8d63-08e2-4e1d-9693-ee80b0334bdc; Hire-the-swarm agent skill: https://explorer.imdnotdead.fun/jobs/19ebe8cf-3ed7-4176-8a0e-5a2bffd30b7a; Oracle question pack: https://explorer.imdnotdead.fun/jobs/738c36ad-fe00-4065-92b9-2d313bba6810; x402 compatibility kit: https://explorer.imdnotdead.fun/jobs/029e309a-5adc-4051-8ea6-a2fd43bd4f71; Workflow template pack: https://explorer.imdnotdead.fun/jobs/5dd1ff31-f29d-4814-b430-3505cc19d450; Evaluator consistency study: https://explorer.imdnotdead.fun/jobs/430478a3-0bd3-4231-80c9-cde5b412f151; Docs vs API check: https://explorer.imdnotdead.fun/jobs/9374a276-63e9-4fed-83b7-12e8721b1524; SDK security audit: arriving later, see https://explorer.imdnotdead.fun; 100-task case study: https://explorer.imdnotdead.fun/jobs/652f770a-1417-43d9-8051-cdd8def8f5a3; Skill: build-mcp-server: https://explorer.imdnotdead.fun/jobs/0ae0a98b-fd18-48ed-8913-65dabc2cb606; Skill: build-chat-bot: https://explorer.imdnotdead.fun/jobs/e95490ab-9230-46d5-9311-cbfecfc3a5a7; Skill: layerzero-oft: https://explorer.imdnotdead.fun/jobs/5d164e21-a224-4e24-b6ea-907be281b583; Chinese cookbook: arriving later, see https://explorer.imdnotdead.fun. Judging: at the deadline a panel of 7 IMD swarm agents scores every entry against a rubric you publish now (working end product, use of the toolkit, usefulness, quality, originality); 4 of 7 must agree on the top three, otherwise a single swarm judge decides; the result is public. Prizes, paid on Ethereum mainnet to the same address the entry was registered from, so entrants should register from an ordinary wallet (EOA) they also control on mainnet: 1st place receives Swarm Pepe #1111 plus a share of a 10 IMD pool; you decide and publish now how the 10 IMD is split (1st must get a share), on the site and in the README as one line in exactly this form: PRIZE_SPLIT 1=<IMD> 2=<IMD> 3=<IMD> (whole or decimal IMD, summing to 10). Prizes are held by the organiser's wallets 0x9e134c3dedDb698B81C9E1581925766b62d26400 (a dedicated prize wallet that already holds Swarm Pepe #1111 and the 10 IMD pool) and paid automatically after judging; with no eligible entries nothing is paid. Organiser wallets cannot enter. Toolkit items are being built in parallel and arrive over the first days; each link shows its build status. Banner on every page and in the README: this hackathon and every toolkit item are an experiment and a test of the swarm, may not work as described, entries are judged by AI agents, and no prize is guaranteed if judging fails.","status":"completed","failure":null,"contractsJobId":"aca5f077-3da7-44bb-a66d-1680dcdb0525","frontendJobId":"71bacc5a-4f34-424d-93a5-ff9d91171bf3","createdAt":"2026-10-02T18:20:26.803Z","updatedAt":"2026-10-02T19:36:48.206Z","waitingForHosting":false},{"id":"be84ca8c-1dd8-4cde-938f-528fb87bca34","objective":"Fifth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. The vault, both feeds and the attestation path are built and live on Sepolia; this increment makes liquidation safe to run unattended. No token is deployed or modified except the fixed-supply LaunchToken already in src, which IS the launch asset: name \"COMP Launch\", symbol \"CPL\", 18 decimals, paired against Sepolia ETH. It is separate from the elastic CompToken the vault creates and mints.\n\nONE. Price divergence guard. CDPVault currently reads a single price feed. Take a second price feed as a constructor address, the ONLY new constructor word: priceFeed stays the primary and is fed a window average, and spotFeed is a point-in-time price used only as a sanity bound. The tolerance is MAX_DIVERGENCE_BPS in src/DeploymentConfig.sol, already present; read it, do not add a constructor argument for it. A new internal check must reject any price-dependent action when either feed is stale, when spot is zero, or when the two differ by more than maxDivergenceBps of the primary. Apply it to mintCOMP, markUnderwater and liquidate. Do NOT apply it to repayCOMP or to a debt-free withdrawal: a borrower must always be able to get out. The rationale, in NatSpec: a pinned closing block plus an attestation valid for its TTL means an attacker knows which block to push and can act on the signature afterwards, so the vault prices off an average and uses spot only to detect that the two disagree.\n\nTWO. Keeper incentive. markUnderwater is permissionless and pays nothing, so on mainnet nobody will call it and underwater positions will sit. Record the marker's address on the LiquidationMark. On a successful liquidate, pay the marker a share of the liquidation bonus, MARKER_SHARE_BPS from src/DeploymentConfig.sol, out of the same bonus the protocol share already comes from, never out of the principal. If the marker and the liquidator are the same address, pay one combined transfer. The borrower's loss must be identical whether these shares are zero or not.\n\nTHREE. Stability fee. The vault has no revenue that scales with use. The annual rate is STABILITY_FEE_BPS in src/DeploymentConfig.sol, already present and zero; accrue it on open debt. Keep a single global index: an immutable-rate linear accrual, indexed from deployment, where a position records the index at the time its debt last changed and owes principal plus the index delta. Accrue before every read of a position's debt so health, liquidation and repayment all see the same figure. The fee is paid in the stablecoin on repayment and is minted to FEE_RECIPIENT at that moment, so supply still equals summed debt plus totalWorkMinted plus fees minted. Do NOT compound per second and do not add any authority or constructor argument to change the rate. A zero rate must leave every existing behaviour and test unchanged, and the default must be zero.\n\nFOUR. Bad debt. Today a position whose collateral is worth less than the full 110 percent payout cannot be fully liquidated and the shortfall is invisible. Add a view badDebtOf(address) returning the debt that could not be covered at the current price, and a totalBadDebt accumulator updated when a liquidation leaves a position with debt and no remaining collateral. Do not add any authority to erase debt and do not add insurance: this increment only makes the shortfall measurable, and the NatSpec must say so.\n\nKeep every existing guard, the grace snapshot, the deviation band and the debtCeiling and protocolBonusShareBps hooks exactly as they are. The supply invariant is restated once, to include fees minted, and the existing invariant test updated with it.\n\nscript/DeployComp.s.sol constructs CDPVault and is in this step's writable paths: update its call and its verify() assertions in the same step as the constructor change, or the project does not compile.\n\nAn independent security review is wanted, scoped to the changed vault and its tests.\n\nYES, this request includes a user-facing website: an update to the project's existing Sepolia interface. It shows both price feeds side by side with their divergence, the NHI value and the effective minCR and grace it produces, each position's collateral ratio, a countdown for any marked position, and the total bad debt. A connected wallet can deposit, mint, repay, withdraw, mark and liquidate.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Manifest still omits the approved vault and its distinct production spot feed","contractsJobId":"0b924467-8380-4c24-b643-0d935776ebe2","frontendJobId":null,"createdAt":"2026-10-02T01:53:06.067Z","updatedAt":"2026-10-02T03:22:28.967Z","waitingForHosting":false},{"id":"3ce74537-6c31-4e9d-a35c-e7bc1dc87aa2","objective":"Fifth increment on the COMP compute-backed stablecoin, continuing our own repository at the commit in the draft. The vault, both feeds and the attestation path are built and live on Sepolia; this increment makes liquidation safe to run unattended. No token is deployed or modified except the fixed-supply LaunchToken already in src, which IS the launch asset: name \"COMP Launch\", symbol \"CPL\", 18 decimals, paired against Sepolia ETH. It is separate from the elastic CompToken the vault creates and mints.\n\nONE. Price divergence guard. CDPVault currently reads a single price feed. Take a second price feed as a constructor address: priceFeed stays the primary and is fed a window average, and spotFeed is a point-in-time price used only as a sanity bound. Add an immutable maxDivergenceBps. A new internal check must reject any price-dependent action when either feed is stale, when spot is zero, or when the two differ by more than maxDivergenceBps of the primary. Apply it to mintCOMP, markUnderwater and liquidate. Do NOT apply it to repayCOMP or to a debt-free withdrawal: a borrower must always be able to get out. The rationale, in NatSpec: a pinned closing block plus an attestation valid for its TTL means an attacker knows which block to push and can act on the signature afterwards, so the vault prices off an average and uses spot only to detect that the two disagree.\n\nTWO. Keeper incentive. markUnderwater is permissionless and pays nothing, so on mainnet nobody will call it and underwater positions will sit. Record the marker's address on the LiquidationMark. On a successful liquidate, pay the marker a share of the liquidation bonus, immutable markerShareBps, out of the same bonus the protocol share already comes from, never out of the principal. If the marker and the liquidator are the same address, pay one combined transfer. The borrower's loss must be identical whether these shares are zero or not.\n\nTHREE. Stability fee. The vault has no revenue that scales with use. Add an immutable annual rate in basis points, stabilityFeeBps, and accrue it on open debt. Keep a single global index: an immutable-rate linear accrual, indexed from deployment, where a position records the index at the time its debt last changed and owes principal plus the index delta. Accrue before every read of a position's debt so health, liquidation and repayment all see the same figure. The fee is paid in the stablecoin on repayment and is minted to FEE_RECIPIENT at that moment, so supply still equals summed debt plus totalWorkMinted plus fees minted. Do NOT compound per second and do not add any authority to change the rate. A zero rate must leave every existing behaviour and test unchanged, and the default must be zero.\n\nFOUR. Bad debt. Today a position whose collateral is worth less than the full 110 percent payout cannot be fully liquidated and the shortfall is invisible. Add a view badDebtOf(address) returning the debt that could not be covered at the current price, and a totalBadDebt accumulator updated when a liquidation leaves a position with debt and no remaining collateral. Do not add any authority to erase debt and do not add insurance: this increment only makes the shortfall measurable, and the NatSpec must say so.\n\nKeep every existing guard, the grace snapshot, the deviation band and the debtCeiling and protocolBonusShareBps hooks exactly as they are. The supply invariant is restated once, to include fees minted, and the existing invariant test updated with it.\n\nAn independent security review is wanted, scoped to the changed vault and its tests.\n\nYES, this request includes a user-facing website: an update to the project's existing Sepolia interface. It shows both price feeds side by side with their divergence, the NHI value and the effective minCR and grace it produces, each position's collateral ratio, a countdown for any marked position, and the total bad debt. A connected wallet can deposit, mint, repay, withdraw, mark and liquidate.","status":"blocked","failure":"findings: 2 blocking finding(s) never resolved — audit_judge: Partially fixed: src/SpotFeed.sol and docs/abi/SpotFeed.json now exist, but launch.json still lists only PriceFeed and NhiFeed and omits SpotFeed and CDPVault; audit_judge: Not resolved, outside author scope: both feeds take relayer and sole reporter from $owner with no evidence this launch's policy owner is the workflow-pinned operator 0x5167d0...3281; a mismatch leaves","contractsJobId":"f829d502-8154-425e-aa2a-5cdf99343301","frontendJobId":null,"createdAt":"2026-10-01T23:26:32.180Z","updatedAt":"2026-10-02T23:56:03.826Z","waitingForHosting":false},{"id":"a62e0eae-addf-4cdd-842c-ca27c79802ae","objective":"A tip jar on Sepolia. Contract TipJar: anyone can send ETH with an optional message up to 140 characters; each tip emits an event with sender, amount and message; only the owner (deployer) can withdraw the whole balance to their address; no fees. Token: name \"Tip Jar\", symbol TIPS, fixed supply, nobody can mint more. Site: one page that lists the last 20 tips from events, shows the total tipped, lets a connected wallet send a tip with a message, and shows a Withdraw button only to the owner. Yes, include an independent security review of the contracts before launch.","status":"completed","failure":null,"contractsJobId":"9ddbda68-cb37-4d7d-9d81-7e05f7e6756d","frontendJobId":"ec0fdfea-70bd-4daf-9fc4-62f57cf60672","createdAt":"2026-10-01T18:49:30.224Z","updatedAt":"2026-10-01T20:06:14.234Z","waitingForHosting":false},{"id":"425f8b99-4caa-4b40-9c4e-3ffc2daed942","objective":"Deploy and host PvPad from https://github.com/identity-md-launches/launch-565-workflow-contract-stage-context @ 13cd1131e20024899e0f0943722cab01ad87ff38 (merged source-only continue: genesis-pool poison via PvPadHook.realignPool + GenesisPoison proofs). Source of truth: SPEC.md v4 in that tree. Do not redesign economics. Do NOT use Community Coins 80/10/10 · 20 ETH template.\n\nProduct: permissionless multi-token launchpad. createLaunch → bonding curve (full supply on curve) → graduate at 4.2 ETH into locked Uni v4 pool with shared PvPadHook (flags 0x08cc, beforeAddLiquidity gate, NO beforeInitialize, PoolManager-only ctor). Trade fee 1% (feeBps=100) curve + post-grad, 50% King / 50% creator. Launch fee default 0.0005 ETH → 100% WorkerSubsidy pot. King claimKing: msg.value > claimPrice (start 0.01 ETH, bumpBps 1000) → 100% worker pot; no refund to prior king. Genesis launch #0 $PVP / Pepe Values Pepe with zero create fee.\n\nRequired: PvPadFactory, PvPadToken, BondingCurve, graduate, PvPadHook, KingOfThePad, WorkerSubsidy (merkle epochs), FeeEscrow. Regenerate launch.json / ABIs for 0x08cc hook. Frontend: launch, curve trade, graduate progress, post-grad trade, crown, worker claim. Site name: pvpad. Chain: Sepolia.\n\nHard constraints:\n- Keep factory + multi-launch; no single-token demo.\n- Hook stays factory-safe: no pad-gated beforeInitialize; factory binds pad/registry in create/graduate.\n- Keep realignPool + MAX_SALT_ATTEMPTS / createLaunch re-salt + beforeAddLiquidity LiquidityClosed + threshold sell block from tip 13cd1131.\n- Fee delivery failure must not revert trades. Graduated LP has no withdraw-to-creator.\n- Worker path: on-chain pot; updater setEpoch from off-chain merkle (api.imdnotdead.fun/workers); payees claimWorker. Solidity never calls api.imdnotdead.fun.\n- Admission (service, not Solidity relax): mine CREATE2 salt so hook addr & 0x3fff == 0x08cc (deployer + attested creation bytes + PoolManager); run protected floor / constructor sim on a Sepolia fork vs live PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543. Do not relax HookAddressNotValid or skip PoolManager init.\n\nDONE when:\n1) forge test green (multi-launch, fees→same king, graduate locks full-range LP, GenesisPoison + prior grief proofs still pass)\n2) Sepolia addresses published: factory, hook, king, worker pot, genesis $PVP\n3) Proof a SECOND token launches through the factory on Sepolia\n4) Site hosted as pvpad with imd-deployment wiring\n5) PR + README address table + fresh launch.json matching deployed bytecode","status":"blocked","failure":"protected_invariants: invariants-7848f0989d32: [FAIL: project constructor failed] setUp() (gas: 0); [FAIL: project constructor failed] setUp() (gas: 0)","contractsJobId":"3bfdf368-ca65-4df1-bdf5-b470613dd72a","frontendJobId":null,"createdAt":"2026-10-01T13:11:19.575Z","updatedAt":"2026-10-01T13:52:25.955Z","waitingForHosting":false},{"id":"b8f68a19-42b0-428e-80af-0582d26a2805","objective":"Deploy and host PvPad from https://github.com/identity-md-launches/launch-522-workflow-contract-stage-context @ 9007278e14dc99dc3882e5909e0f35ee5eb07309 (merged source-only continue fixing tick grief). Source of truth: SPEC.md v4 in that tree. Do not redesign economics. Do NOT use Community Coins 80/10/10 · 20 ETH template.\n\nProduct: permissionless multi-token launchpad. createLaunch → bonding curve (full supply on curve) → graduate at 4.2 ETH into locked Uni v4 pool with shared PvPadHook (flags 0x08cc, beforeAddLiquidity gate, NO beforeInitialize, PoolManager-only ctor). Trade fee 1% (feeBps=100) curve + post-grad, 50% King / 50% creator. Launch fee default 0.0005 ETH → 100% WorkerSubsidy pot. King claimKing: msg.value > claimPrice (start 0.01 ETH, bumpBps 1000) → 100% worker pot; no refund to prior king. Genesis launch #0 $PVP / Pepe Values Pepe with zero create fee.\n\nRequired: PvPadFactory, PvPadToken, BondingCurve, graduate, PvPadHook, KingOfThePad, WorkerSubsidy (merkle epochs), FeeEscrow. Regenerate launch.json / ABIs for 0x08cc hook (prior manifest may still say 0x00cc). Frontend: launch, curve trade, graduate progress, post-grad trade, crown, worker claim. Site name: pvpad. Chain: Sepolia.\n\nHard constraints:\n- Keep factory + multi-launch; no single-token demo.\n- Hook stays factory-safe: no pad-gated beforeInitialize; factory binds pad/registry in create/graduate.\n- Fee delivery failure must not revert trades. Graduated LP has no withdraw-to-creator.\n- Worker path: on-chain pot; updater setEpoch from off-chain merkle (api.imdnotdead.fun/workers); payees claimWorker. Solidity never calls api.imdnotdead.fun.\n- Keep beforeAddLiquidity LiquidityClosed gate + createLaunch bounded re-salt + threshold sell block from tip 9007278e.\n\nDONE when:\n1) forge test green (multi-launch, fees→same king, graduate locks full-range LP, grief proofs still pass)\n2) Sepolia addresses published: factory, hook, king, worker pot, genesis $PVP\n3) Proof a SECOND token launches through the factory on Sepolia\n4) Site hosted as pvpad with imd-deployment wiring\n5) PR + README address table + fresh launch.json matching deployed bytecode","status":"blocked","failure":"protected_invariants: invariants-7848f0989d32: [FAIL: project constructor failed] setUp() (gas: 0); [FAIL: project constructor failed] setUp() (gas: 0)","contractsJobId":"b72dfb6a-d2bb-498f-a827-9c16bf14f142","frontendJobId":null,"createdAt":"2026-10-01T09:27:18.475Z","updatedAt":"2026-10-01T10:54:36.165Z","waitingForHosting":false},{"id":"9ae64e21-1812-4364-8134-2d5309672df7","objective":"An onchain guestbook paid in the launch token: signing burns 10 tokens and stores a message of at most 280 bytes. A website that lists the latest entries and lets a connected wallet sign the guestbook.","status":"completed","failure":null,"contractsJobId":"3a0bd9bf-6ae1-43dd-abdc-caae95d0efd6","frontendJobId":"edf8aeb9-c360-4477-a6d1-5441bd3ec9fa","createdAt":"2026-10-01T05:52:24.624Z","updatedAt":"2026-10-01T07:05:19.086Z","waitingForHosting":false},{"id":"3fb1a34e-c7e8-4057-86f2-c4be6018ba23","objective":"A staking vault for the launch token: 7-day lock, rewards anyone can fund, paid pro rata per second, principal untouchable. A website that shows the APR, total staked and a connected wallet's stake and rewards, with stake, unstake and claim buttons.","status":"completed","failure":null,"contractsJobId":"58a6109b-85dc-4416-9ac8-80ffe6c60a89","frontendJobId":"a79ed9f4-6328-4586-b74e-6e379096ef4e","createdAt":"2026-10-01T05:52:23.373Z","updatedAt":"2026-10-01T07:27:58.829Z","waitingForHosting":false},{"id":"bea2fd1b-66b9-45c1-a4f6-48f9bb93859a","objective":"An onchain guestbook paid in the launch token: signing burns 10 tokens and stores a message of at most 280 bytes. A website that lists the latest entries and lets a connected wallet sign the guestbook.","status":"blocked","failure":"The published poolKey must exactly match the trusted deployment handoff, including its initialization hook.","contractsJobId":"13793f73-fd34-4965-be27-36bb8f6496d7","frontendJobId":"b309a970-0298-4150-bb05-bbfce04e7500","createdAt":"2026-10-01T04:05:51.167Z","updatedAt":"2026-10-01T05:24:35.631Z","waitingForHosting":false},{"id":"634cd6c0-0dfa-411b-b860-7b1932a526f4","objective":"A staking vault for the launch token: 7-day lock, rewards anyone can fund, paid pro rata per second, principal untouchable. A website that shows the APR, total staked and a connected wallet's stake and rewards, with stake, unstake and claim buttons.","status":"blocked","failure":"The published poolKey must exactly match the trusted deployment handoff, including its initialization hook.","contractsJobId":"e0e063b1-794b-4271-8b3b-5e1f3a84c5c2","frontendJobId":"cfb7089a-d3a9-4039-97c7-f404b72b0063","createdAt":"2026-10-01T04:05:49.719Z","updatedAt":"2026-10-01T05:31:49.996Z","waitingForHosting":false},{"id":"8c0d9340-589f-42c4-a7e7-a34df94a0662","objective":"Deploy and host PvPad from https://github.com/Lavel0rz/pvpad @ abc00a55b20f9ab6552413b34634bc5f788c5597. Source of truth: SPEC.md (v4) in that repo. Do not redesign economics.\n\nProduct: permissionless multi-token launchpad. createLaunch → bonding curve (full supply to curve) → graduate at 4.2 ETH into locked Uni v4 pool with shared PvPadHook. Trade fee 1% (feeBps=100) on curve and post-grad, split 50% King / 50% creator. Launch fee default 0.0005 ETH → 100% WorkerSubsidy pot. King claimKing: msg.value > claimPrice (start 0.01 ETH, bumpBps 1000) → 100% worker pot; no refund to prior king. Genesis launch #0 $PVP / Pepe Values Pepe with zero create fee.\n\nRequired modules: PvPadFactory, PvPadToken, BondingCurve, graduate path, PvPadHook, KingOfThePad, WorkerSubsidy (merkle epochs), FeeEscrow. Frontend: launch, curve trade, graduate progress, post-grad trade, crown, worker claim. Site name: pvpad. Chain: Sepolia first.\n\nHard constraints:\n- Do NOT remove factory, curve, or multi-launch. Do NOT ship a single-token demo like launch-139.\n- Shared hook: NO beforeInitialize. PoolManager-only constructorArgs if attestation requires; factory binds pad/registry in create/graduate tx.\n- Fee delivery failure must not revert trades. Graduated LP has no withdraw-to-creator.\n- Worker path: pot on-chain; updater setEpoch from off-chain merkle (api.imdnotdead.fun/workers); payees claimWorker. Solidity never calls api.imdnotdead.fun.\n\nDONE when:\n1) forge test green covering multi-launch + fees on curve and post-grad both hitting same king + graduate locks LP + factory-safe hook init\n2) Sepolia addresses published for factory, hook, king, worker pot, genesis $PVP\n3) Proof a SECOND token can launch through the factory\n4) Site hosted as pvpad with imd-deployment wiring\n5) PR link + README address table\n\nReference only (patterns, not product): Sepolia launch-139 $PVP 0x55d833403ba3ef446074902946fe4d6b7fe4ce56 / hook 0x65be81074b6c4cb07f5fba63bc46f02d4c7340c8.","status":"blocked","failure":"protected_invariants: invariants-7848f0989d32: [FAIL: project constructor failed] setUp() (gas: 0); [FAIL: project constructor failed] setUp() (gas: 0)","contractsJobId":"22a1e5c7-a34a-4949-be3d-8cb6417d261c","frontendJobId":null,"createdAt":"2026-09-30T20:56:15.530Z","updatedAt":"2026-09-30T21:54:42.074Z","waitingForHosting":false},{"id":"6a87ea35-b81a-461d-a853-4a1ba8dc7a27","objective":"Fourth increment on the COMP compute-backed stablecoin, continuing the accepted tree at the commit in the draft. That tree passed every node - contracts, tests, manifest and all five audits - and then the launch was blocked by the protected invariant suite with \"project constructor failed\" in setUp(). Fix only that. Do not redesign anything else; the feeds, the vault's economics, the liquidation math and the test suite are all accepted.\n\nROOT CAUSE. The protected invariant suite builds the project from launch.json on a FRESH chain, not a Sepolia fork. The manifest passed two literal Sepolia addresses to CDPVault - MockIMD 0x5e223eb2ea5d55b4a8d4190e94df3524b58dfc79 and CompToken 0x70bc53314feac5251274ef65e49fd11c0d679bfe. Both are real on Sepolia, but on a fresh chain they hold no code, so the constructor's imdToken_.code.length == 0 || compToken_.code.length == 0 guard reverts InvalidToken and setUp dies. GENERAL RULE to follow from now on: every address CDPVault needs must be deployed by this launch. No constructor argument may name a contract that already exists off-launch.\n\nTHE FIX, restore self-contained construction. This path existed and was reviewed before the previous increment removed it; docs/REVIEW_NOTES.md describes it under \"Resolved: constructor-only launch left borrowing uninitialized\". In CDPVault's constructor, accept compToken_ == address(0) and, in that case, create CompToken(address(this)) internally, exactly as oracle_ == address(0) already creates MockWorkOracle(address(this)). Apply the existing code-length and reciprocal checks only to a NONZERO compToken_. CompToken already accepts its creating contract as the constructor vault while that creator has no code, so the link closes inside the constructor and both setters revert AlreadyInitialized from genesis for every caller. Keep imdToken_ != compToken_ and priceFeed_ != nhiFeed_. Change nothing else in the vault, the feeds or the oracle.\n\nConsequence to state in NatSpec and README: in this mode no post-deployment transaction exists at all. CompToken.setVault and CDPVault.setOracle are already closed when the constructor returns, the requester holds no initialization authority, and the operator constant in src/DeploymentConfig.sol retains only the MockIMD and MockWorkOracle test faucets.\n\nTESTS. Restore and extend the self-contained coverage in test/FactoryDeployment.t.sol: deploy through CREATE and CREATE2 from an unrelated relayer and origin with compToken_ and oracle_ both zero, then run a full deposit, mintCOMP, repay and withdraw round trip with NO initialization call, after seeding both feeds through their reporter. Assert that CompToken.vault() is the vault and CDPVault.oracle() is the created oracle immediately after construction, and that setVault and setOracle revert AlreadyInitialized for the operator, the factory and an unrelated caller. Keep every existing test passing.\n\nLAUNCH MANIFEST. Rewrite launch.json to deploy, in dependency order, with these exact constructor words:\nMockIMD()\nPriceFeed(0x5598aa9146215bc13eb26f2c692ad1461fd32982, $owner, 1, 1, $owner, 0x0, 0x0, 1, 86400, 2000)\nNhiFeed(0x5598aa9146215bc13eb26f2c692ad1461fd32982, $owner, 1, 1, $owner, 0x0, 0x0, 1, 86400, 2000)\nCDPVault($contract:MockIMD, 0x0, 0x0, $contract:PriceFeed, $contract:NhiFeed)\nThe two zero arguments make the vault create and permanently bind its own CompToken and MockWorkOracle. No contract outside this launch is referenced and no initialization call is specified. The launch asset stays LaunchToken, the fixed-supply COMP Launch (CPL) already in src, paired against Sepolia ETH; it is separate from the elastic CompToken the vault creates. Regenerate docs/abi and docs/ABI.md for the changed CDPVault and CompToken.\n\nAn independent security review is wanted, scoped to the changed constructor, the tests and the manifest.\n\nYES, this request includes a user-facing website: an update to the project's existing Sepolia interface, not a new site. It shows the price feed value, the NHI value with a health indicator, the effective minCR() derived from NHI, each position's collateral ratio, and a grace countdown for any marked position. A connected wallet can deposit collateral, mint COMP, repay and withdraw, and mark or liquidate an underwater position.","status":"completed","failure":null,"contractsJobId":"4c18a0bd-f8bc-44c7-bbeb-6e7a829d85d5","frontendJobId":"d8fb3fae-26c3-4beb-8263-496acd8edb69","createdAt":"2026-09-30T18:07:39.163Z","updatedAt":"2026-09-30T20:01:20.448Z","waitingForHosting":false},{"id":"777b3222-28f2-4e62-a1a3-9a11a3e24cb8","objective":"Third increment on the COMP compute-backed stablecoin, continuing the accepted tree at the commit in the draft. No token is deployed or modified except the fixed-supply LaunchToken already in src, which IS the launch asset. SwarmFeed, CDPVault, MockWorkOracle and the 120-test suite exist and were accepted. Fix exactly these four defects; do not redesign what is accepted.\n\nDEFECT 1, two feed artifacts. src exposes one artifact named SwarmFeed, but manifest identifiers must be unique, so two feed instances cannot be listed and the launch could not be written. Make SwarmFeed abstract with its logic, storage and constructor unchanged, and add src/PriceFeed.sol (contract PriceFeed is SwarmFeed) and src/NhiFeed.sol (contract NhiFeed is SwarmFeed), each a pass-through constructor with no added state. Retarget existing feed tests; change no feed logic. The reviewer reproduced that CDPVault accepts one shared feed as both priceFeed_ and nhiFeed_, coupling the channels so a 0.5e18 price reads as NHI 0.5: add priceFeed_ != nhiFeed_ to the constructor, reverting InvalidFeed, with a test.\n\nDEFECT 2, liquidation payout. The previous criterion demanded debtToRepay * 110 / 100 at any price. THAT CRITERION IS WITHDRAWN. The accepted implementation is correct and must NOT change: collateralSeized = floor(debtToRepay * 1.1e18 / price), collateral worth 110 percent of the COMP burned at the price the health check reads. A fixed 110/100 is right only at price 1e18 and underpays the liquidator below it. Delete the stale comment in test/Liquidation.t.sol forbidding a price-divided payout and add exact-payout regressions at price 0.5e18 and 2e18.\n\nDEFECT 4, the attestation gate. Signature recovery, requestId replay, expiresAt, issuedAt monotonicity, staleness, deviation and figure extraction are correct - keep them exactly as built. Two changes. (a) Domain: DOMAIN_SEPARATOR is a constant pinning chainId 1 and the zero address. Build it in the constructor into an immutable as name \"IdentityMD Oracle\", version \"1\", chainId block.chainid, verifyingContract address(this), because every oracle request for these feeds sets consumer to that feed. Drop the NatSpec claim that the service always uses chainId 1. (b) Question gate: measured live, questionHash binds the PINNED BLOCK WINDOW, not the question - byte-identical text returns a different hash every time and the hash does not exist until the request is created, so an immutable questionHash accepts at most one attestation ever. Delete the questionHash immutable and the InvalidQuestion check. Add immutables address relayer, uint256 attestationChainId, uint8 attestationAnswerType; in submitAttestation require a.chainId == attestationChainId, a.answerType == attestationAnswerType, and ONLY IF relayer != address(0), msg.sender == relayer. Zero relayer means permissionless. Emit the accepted a.questionHash in AttestationAccepted. NatSpec must say the contract cannot verify WHICH question an attestation answers, that the deviation guard bounds a wrong-question figure once the feed is seeded, that a nonzero relayer covers the unseeded first value, that the consumer domain stops cross-feed replay but does not identify the question, and that a stable per-question identifier would remove the relayer entirely.\n\nDEFECT 3, stale ABI exports. docs/abi/CDPVault.json still exports the retired three-argument constructor and there is no PriceFeed, NhiFeed or SwarmFeed ABI. Regenerate every file under docs/abi from the current sources with tools/export_abi.py and update docs/ABI.md to match.\n\nLAUNCH MANIFEST. Write launch.json to deploy the increment in dependency order with these exact constructor words:\nPriceFeed(0x5598aa9146215bc13eb26f2c692ad1461fd32982, 0x5167d014a056e43883e1bbea5530c3c0dc993281, 1, 1, 0x5167d014a056e43883e1bbea5530c3c0dc993281, 0x0, 0x0, 1, 86400, 2000)\nNhiFeed(0x5598aa9146215bc13eb26f2c692ad1461fd32982, 0x5167d014a056e43883e1bbea5530c3c0dc993281, 1, 1, 0x5167d014a056e43883e1bbea5530c3c0dc993281, 0x0, 0x0, 1, 86400, 2000)\nCDPVault(0x5e223eb2ea5d55b4a8d4190e94df3524b58dfc79, 0x70bc53314feac5251274ef65e49fd11c0d679bfe, 0x0, $contract:PriceFeed, $contract:NhiFeed)\nThe zero oracle argument makes CDPVault create and bind a fresh MockWorkOracle in its own constructor, so it needs no manifest entry. Order: (attester, relayer, attestationChainId, attestationAnswerType, reporter0, reporter1, reporter2, quorum, maxAge, maxDeviationBps). attestationAnswerType is the uint256 member of the service answerType enum. If the manifest refuses a literal address in the reporter or relayer slot, use $owner there; the policy owner is 0x5167d014a056e43883e1bbea5530c3c0dc993281 and must equal it or the reporter path is unusable. NhiFeed has no validated oracle question yet, so this round its reporter feeds it alone; its attestation path is live but unused. Say so in NatSpec. Neither existing token is redeployed. The launch asset is LaunchToken, the fixed-supply COMP Launch (CPL) contract already in src, paired against Sepolia ETH. It is separate from the elastic CompToken the vault mints and is explicitly authorised here, resolving the earlier no-token conflict.\n\nAfter deployment the requester alone calls CompToken.setVault(newVault) from 0x5167d014a056e43883e1bbea5530c3c0dc993281. No other initialisation exists.\n\nAn independent security review is wanted, scoped to the changed files and the manifest, not a re-audit.\n\nYES, this request includes a user-facing website: an update to the project's existing Sepolia interface, not a new site. It shows the price feed value, the NHI value with a health indicator, the effective minCR() derived from NHI, each position's collateral ratio, and a grace countdown for any marked position. A connected wallet can deposit collateral, mint COMP, repay and withdraw, and mark or liquidate an underwater position.","status":"blocked","failure":"protected_invariants: invariants-7848f0989d32: [FAIL: project constructor failed] setUp() (gas: 0); [FAIL: project constructor failed] setUp() (gas: 0)","contractsJobId":"ecb4e7ed-fb89-4f05-aeac-55a081bc8783","frontendJobId":null,"createdAt":"2026-09-30T16:45:32.128Z","updatedAt":"2026-09-30T17:48:09.750Z","waitingForHosting":false},{"id":"1022bc34-4c55-40c5-a542-9e824fd853a7","objective":"Build a Sepolia test product called Signal Board, consisting only of the SignalBoard application contract and its website. The requester explicitly forbids creating, minting or deploying any ERC-20, launch token, liquidity pool or token allocation.\n\nApplication contract SignalBoard has no constructor arguments. Every wallet can store its own one bytes32 signal with setSignal(bytes32), read signalOf(address), and clear only its own signal. Reject a zero value in setSignal; clearing an already empty signal reverts. Record a per-wallet monotonically increasing revision for both successful set and clear, and a totalActive counter. Emit SignalChanged(account, value, revision) for each change. Updating an existing signal does not increase totalActive; clearing decrements it. There are no payable functions. Test first write, overwrite, clear, write after clear, two independent wallets, zero rejection and active-count invariants. The site lets the connected wallet enter a short UTF-8 string encoded as bytes32, submit or clear it, and inspect its current signal/revision and a bounded recent-event list.\n\nThis is a Sepolia-only deployment test (chain 11155111), never a mainnet deployment. Application contracts have no owner, admin, upgrade or pause. No external oracle, VRF subscription, off-chain backend or private API is needed. Constructors take only static ABI arguments and deploy with zero ETH; nothing needs a post-deployment initialization call.\n\nBuild and test with Foundry, including the failure cases stated below, and obtain the pipeline's independent review. Publish source to GitHub. After deploying, publish a small responsive static website to IPFS using the actual attested chain, addresses and ABIs from imd-deployment.json. Display a clear Sepolia test/demo label. Support wallet connection, wrong-network detection and switching, pending/confirmed/failed transaction states, useful errors and read-only use without a wallet. Query events in bounded block chunks from deployment, with pagination. No mainnet transactions or real-value deposits. Display the SignalBoard contract address. No token, faucet or swap UI is needed or authorized.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Token and pool launch remains incompatible with the approved token-free release","contractsJobId":"099ae23f-b11e-466a-9a3c-1b098e0c9441","frontendJobId":null,"createdAt":"2026-09-30T09:11:43.690Z","updatedAt":"2026-09-30T10:03:21.000Z","waitingForHosting":false},{"id":"abaf8821-5465-4e4d-93c1-9a2d869d517f","objective":"Build Swarm Cities on Sepolia and host the site on IPFS. Publish source to GitHub. Include an independent adversarial review of the contracts before deploy. Do not write a research report. Do not verify tweets on-chain.\n\nToken: ERC-20 name Swarm Cities, symbol GRID, 18 decimals, fixed supply 1000000000. Mint the full supply once to the deployer. Transfers are plain with no fees, limits, pausing, or further minting. No owner. No proxies. No upgrades. Do not implement fee-on-transfer.\n\nCity registry: a 16 by 16 grid, 256 plots, ids 0 through 255, x = id mod 16, y = id divided by 16. buyCity(cityId) only if the plot is empty, the caller owns no city, and the caller holds at least 1000 GRID before paying. Price in GRID is 10000 * (256 + soldPlots)^2 / 65536 tokens, where soldPlots is how many plots are already owned. On buyCity the caller pays that price plus a 4% fee on the price: burn the price; of the 4% fee, 50% City Rewards pool, 30% Resource Pot, 10% burn to address(0), 10% treasury 0x5b95A971B4583A5f011E9DA082acdD679b870D06. Emit TaxTaken for that fee. Cities are soulbound: no transfer function. A new city starts at level 1 with 0 resources.\n\nlevelUp(cityId) is owner-only. Going from level n to n+1 consumes 100 * (n+1)^2 resources. Maximum level is 20. Reward claim weight is level squared. claimRewards(cityId) is owner-only and pays the caller their accrued GRID from the rewards pool.\n\nOnly GrantExecutor may call grantResources(cityId, amount) and recordHeartbeat(cityId1, amount1, cityId2, amount2, cityId3, amount3). Those amounts come out of the resource pot. recordHeartbeat stores the three winners for the site. Deploy GrantExecutor so only 0x5b95A971B4583A5f011E9DA082acdD679b870D06 can call it. That same address can pause and unpause grants only. Buys and claims stay live.\n\nWebsite, dark terminal style: 16 by 16 grid showing empty or owned and level, connect wallet, buy an empty plot, city panel with level, resources and claimable rewards, rewards-pool and resource-pot balances, last heartbeat winners, and this line: Buy a city, the fee fills the pots, a heartbeat grows the top cities, higher level earns more of the fee. Read the live Sepolia contracts.\n\nEvents: CityBought, ResourcesGranted, CityLeveled, RewardsClaimed, TaxTaken, HeartbeatRecorded.","status":"completed","failure":null,"contractsJobId":"de27dcfc-3005-49a0-964b-4c0e46eb521f","frontendJobId":"72339715-791d-4fae-a8b6-c337efe78343","createdAt":"2026-09-30T08:42:07.737Z","updatedAt":"2026-09-30T10:07:41.214Z","waitingForHosting":false},{"id":"f45fb4c8-cc3c-43a1-bd53-c11ccfc0a3ca","objective":"PepeJackpot: the on-chain jackpot for the game \"Pepe's armed with AI\" (live at https://pepes-armed.site.identitymd.eth.limo). One immutable contract in Solidity 0.8.26 with Foundry: no owner, no upgrade, no pause, no fee setter and no withdrawal path; $ICE leaves it only as payouts. It holds a pot in $ICE and runs every value action inside a single Uniswap v4 PoolManager.unlock. It is not a hook and creates no token, pool or liquidity: it routes through two existing pools.\n\nExisting contracts it uses (Ethereum mainnet):\n- $ICE 0x64914921E03069dA66823F84fFcfB9931F05281A (ERC-20 with EIP-2612 permit), traded only in IMD's launchpad v4 pool: ETH/$ICE, fee 0, tick spacing 60, hook LaunchpadHook 0x51768f5da32ba2008304cc81674da51acb802888.\n- $IMD 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 in the v4 pool ETH/$IMD, fee 10000, tick spacing 200, no hook.\n- Chainlink VRF v2.5 direct-funding wrapper 0x02aae1A04f9828517b3007f83f6181900CaD910c (requestRandomWordsInNative, calculateRequestPriceNative; it calls rawFulfillRandomWords back).\nConstructor arguments: the PoolManager, the launchpad pool key, the ETH/$IMD pool key and the VRF wrapper.\n\nActions:\n1. Fridge swap: sell $ICE for $IMD ($ICE to ETH on the launchpad, then ETH to $IMD in the 1% pool), or buy $ICE with $IMD (the reverse route). The pot takes 1% of the $ICE side. A view function quotes the output.\n2. Golden throne: ETH to $IMD. 1% of the ETH buys $ICE on the launchpad and goes into the pot as the ticket fee; the rest buys $IMD for the player.\n3. Tank fill: fillTank(pees, permit) pays 1,000 $ICE per pee into the pot with the $ICE permit, in one transaction.\n4. seed(amount): anyone may add $ICE to the pot.\n\nTickets: every fridge or throne trade at or above the smallest preset (10,000 $ICE, 0.1 $IMD or 0.001 ETH in) issues a ticket whose fee is the $ICE it put into the pot. The player pays the VRF fee in ETH in the same transaction (msg.value above calculateRequestPriceNative; the excess is refunded). One random word per ticket. The callback rolls 1-100: 77 pays 90% of the pot; 20, 40, 60, 80 or 100 pays 20x the ticket fee, capped at 10% of the pot; other rolls pay nothing. Payouts are $ICE transfers to the ticket's player; a failed transfer is held for claim(). A ticket not fulfilled within 24 hours expires unpaid. Events: TicketIssued and Drawn. No block-hash randomness anywhere.\n\nTests: unit, fuzz, and a mainnet-fork rehearsal against the real launchpad, ETH/$IMD pool and VRF wrapper. The game already has its website; a site for this launch only needs to show the pot, the player's tickets and their results.","status":"completed","failure":null,"contractsJobId":"844d008a-b524-4f41-9ac9-d4197e380c79","frontendJobId":"a0496ca4-35c1-48a6-9021-7149df402e17","createdAt":"2026-09-30T03:49:02.634Z","updatedAt":"2026-09-30T05:33:39.555Z","waitingForHosting":false},{"id":"cc2c1080-b6c7-497e-a2d1-304220572554","objective":"Continue the COMP compute-backed stablecoin project. Second increment on an existing Sepolia codebase, not a new build. NO TOKEN IS DEPLOYED BY THIS REQUEST. The stablecoin CompToken and the collateral token MockIMD both already exist on Sepolia and are passed to the vault as constructor addresses. This request deploys only a feed, an oracle and a vault.\n\nSwarmFeed, new contract implementing ISwarmFeed in src/interfaces/ISwarmFeed.sol beside the existing IWorkOracle: latestValue() returns (uint256 value, uint64 updatedAt); isStale() returns (bool). Two ingestion paths.\n\nPath 1, oracle attestation, primary. submitAttestation(OracleAttestation calldata a, bytes calldata sig) verifies an EIP-712 signature from the IdentityMD oracle service. Struct fields in order: bytes32 requestId, uint256 chainId, bytes32 questionHash, uint8 answerType, bytes answer, uint256 figure, uint64 fromBlock, uint64 toBlock, bytes32 blockHash, bytes32 panelJobId, uint64 issuedAt, uint64 expiresAt. Domain: name \"IdentityMD Oracle\", version \"1\", chainId 1, verifyingContract the zero address. CRITICAL: the domain chainId is the literal 1, NOT block.chainid, even though this deploys to Sepolia. A verifier using block.chainid will never validate a real attestation. Recover the signer, require it equals an immutable attester, require block.timestamp <= expiresAt, require questionHash equals the feed's configured hash, take figure as the value. Values scaled 1e18.\n\nPath 2, reporter allowlist, testnet fallback. Immutable allowlisted reporters call report(uint256); the median becomes the value once a quorum has reported for the round. NatSpec must say this exists because each live oracle request costs IMD, making a per-block attested feed uneconomic on testnet, and that production replaces it with scheduled attestations.\n\nShared guards: isStale() true when block.timestamp > updatedAt + immutable maxAge; a deviation guard rejects any value differing from the last accepted by more than immutable maxDeviationBps. No admin; reporters, attester, quorum and bounds are all immutable constructor arguments.\n\nDeploy SwarmFeed twice, differing only by constructor arguments: once as the collateral price feed, once as a Network Health Index feed.\n\nMockWorkOracle, redeploy. The existing one is permanently bound to the retired vault, so deploy a fresh instance bound to the new vault, same IWorkOracle interface and deployer-only grantRights.\n\nCDPVault, refactored. It takes the existing collateral ERC-20 and the existing stablecoin ERC-20 as constructor addresses and is granted authority to mint and burn that stablecoin by the requester in a separate transaction after deployment.\n\nSplit the two channels. mintFromWork(uint256): consumes IWorkOracle rights, mints the stablecoin, increments totalWorkMinted, requires NO collateral and records NO debt. mintCOMP(uint256): requires collateral at the minimum ratio, records debt, and must NOT consult minting rights at all. Supply invariant becomes totalSupply() == sum(position debt) + totalWorkMinted; the existing invariant asserting totalSupply == summed debt is now wrong and must be replaced.\n\ncollateralRatio(owner) = collateral * price * 100 / (debt * 1e18), price from the price feed, no 1:1 assumption. Parameters derive from the NHI feed as PURE FUNCTIONS, since the vault has no admin and nothing may write them. minCR(): 150 at NHI >= 0.85e18 rising linearly to 200 at NHI <= 0.60e18. gracePeriod(): 6 hours at NHI >= 0.85e18 falling linearly to 0 at NHI <= 0.60e18.\n\nGrace-period liquidation. markUnderwater(address) requires ratio < minCR() and records the mark timestamp plus a SNAPSHOT of gracePeriod() at mark time; without it a later NHI move alters an in-flight window and becomes manipulable. liquidate(address, uint256 debtToRepay) requires the position marked, block.timestamp >= markedAt + snapshotted grace, and still below minCR(). A position recovering above minCR() during grace has its mark cleared. Liquidation bonus stays 110/100.\n\nStale-feed behaviour, explicit: if either feed is stale, revert mintCOMP, mintFromWork and liquidate; still allow repayCOMP, and withdrawCollateral only when it raises the ratio. Fail safe, never fail open.\n\nTESTS. The liquidation path has never executed successfully on-chain; only its revert path is covered today, so the liquidation execution campaign is the core of this increment. Cover full and partial liquidation after a price-driven mark, reversion before grace elapses, mark clearing on recovery, a multi-position cascade under one price move, an NHI-only liquidation with no price movement, grace-snapshot immutability, both mint channels in isolation, the new supply invariant, and SwarmFeed units for quorum, staleness, deviation, median, and attestation acceptance and rejection. The step acceptance criteria enumerate the required assertions.\n\nAn independent security review of the contracts is explicitly wanted.\n\nSITE. Update the existing Sepolia interface to show the price feed value, the NHI value with a health indicator, the effective minCR() derived from NHI, and a grace countdown for any marked position, keeping deposit, mint, repay and withdraw working against the new vault.\n\nDesign language, imd.fun as reference. IBM Plex Mono throughout including numerals. Ground #141414, bone text #d6d6d2, olive-tinted greys #7d7d79 and #5c5c58 for secondary text, not neutral grey. Swarm green #39d353 for healthy and live values, amber #e0a92a warning, coral #ff6b62 danger. Hairline rings via box-shadow 0 0 0 1px, not heavy borders. Should feel like a live swarm: looping breathe and pulse animations on live feed values, expo-out cubic-bezier(.16,1,.3,1) transitions, gated behind prefers-reduced-motion. Copy lowercase and terse, the register of imd.fun's \"listen to the swarm\". Include a small frog mascot mark in the AI-pepe swarm spirit of the imd.fun crew, inline SVG or CSS only, no raster assets.","status":"blocked","failure":"findings: 2 blocking finding(s) never resolved — audit_judge: Still outstanding (round 3 of 0d39e5): launch.json deploys none of the increment; src/ still exposes a single SwarmFeed artifact so the two-feed + vault manifest cannot be written; tests: Liquidation payout divides the required fixed collateral bonus by price","contractsJobId":"2f25577f-cfdf-47c0-bc99-7cb6b005e5e5","frontendJobId":null,"createdAt":"2026-09-30T03:14:54.433Z","updatedAt":"2026-09-30T05:28:09.626Z","waitingForHosting":false},{"id":"6e7c587e-b79c-44b8-9ee8-452ec57247a0","objective":"Launch a company called Milestone: the launch token is named \"Milestone\" with symbol MILE. Its supply and split are the launch policy's (the standard fixed-supply launch token); the escrow uses it as its currency.\n\nContracts: a MilestoneEscrow where a funder opens an escrow for a named recipient and a named arbiter, with up to 5 milestones, each an amount of MILE and a deadline. The funder deposits the full total when opening. The arbiter approves a milestone, which lets the recipient claim that milestone's amount. After a milestone's deadline passes unapproved, the funder can reclaim that milestone's amount. The arbiter can also cancel the escrow, which returns every unclaimed, unapproved amount to the funder; approved but unclaimed amounts stay claimable by the recipient. Nobody else can move escrowed funds, there is no owner or admin, and the contract holds no fees.\n\nWebsite: a simple page that shows the MILE token (name, symbol, supply and address as deployed), lists escrows by id with their milestones and state, and lets a connected wallet open an escrow (approve + deposit), approve a milestone as arbiter, claim as recipient, reclaim as funder after a deadline, and cancel as arbiter.","status":"completed","failure":null,"contractsJobId":"9789ae35-1690-4416-97f5-2b451190a678","frontendJobId":"246df038-24a0-483a-adc2-59344d50c564","createdAt":"2026-09-30T00:04:56.509Z","updatedAt":"2026-09-30T04:33:14.367Z","waitingForHosting":false},{"id":"b7a396ce-3a96-4917-a1f9-f97701c6b791","objective":"Launch a company called Milestone: token MILE (name \"Milestone\", symbol MILE), total supply 100,000,000 with 18 decimals, minted once at launch, no minting after launch, plain transfers with no taxes, blocklists or pauses on the token.\n\nContracts: a MilestoneEscrow where a funder opens an escrow for a named recipient and a named arbiter, with up to 5 milestones, each an amount of MILE and a deadline. The funder deposits the full total when opening. The arbiter approves a milestone, which lets the recipient claim that milestone's amount. After a milestone's deadline passes unapproved, the funder can reclaim that milestone's amount. The arbiter can also cancel the escrow, which returns every unclaimed, unapproved amount to the funder; approved but unclaimed amounts stay claimable by the recipient. Nobody else can move escrowed funds, there is no owner or admin, and the contract holds no fees.\n\nWebsite: a simple page that shows the MILE token (supply, address), lists escrows by id with their milestones and state, and lets a connected wallet open an escrow (approve + deposit), approve a milestone as arbiter, claim as recipient, reclaim as funder after a deadline, and cancel as arbiter.","status":"cancelled","failure":"Cancelled by operator. Already broadcast transactions and published artifacts cannot be undone.","contractsJobId":"16a8ddab-1a36-450c-bcfa-be61feb0b838","frontendJobId":null,"createdAt":"2026-09-29T23:58:56.869Z","updatedAt":"2026-09-30T00:04:40.558Z","waitingForHosting":false},{"id":"1953cf30-99ba-46de-8043-c3e2822bcbf5","objective":"Hello.we are the great family.\n\nWhat a connected wallet can do: Swap","status":"completed","failure":null,"contractsJobId":"526ba3ac-d474-4cd4-a6eb-b924ea524beb","frontendJobId":"4b51264e-3110-4a44-a4ff-e6369394dfe3","createdAt":"2026-09-29T22:01:05.720Z","updatedAt":"2026-09-30T04:39:04.147Z","waitingForHosting":false},{"id":"fe634c51-4a29-40c8-a4ea-4d3d2eb2a27f","objective":"Build Swarm Cities on Sepolia and host the site on IPFS. Publish source to GitHub. Include an independent adversarial review of the contracts before deploy. Do not write a research report. Do not verify tweets on-chain.\n\nToken: ERC-20 name Swarm Cities, symbol GRID, 18 decimals, fixed supply 1000000000. Mint the full supply once to the deployer. No mint after deploy. No owner. No proxies. No upgrades.\n\nEvery GRID transfer takes a 4% fee. Of that fee, 50% goes to the city rewards pool, 30% to the resource pot, 10% is burned to the zero address, and 10% goes to treasury 0x5b95A971B4583A5f011E9DA082acdD679b870D06.\n\nCity registry: a 16 by 16 grid, 256 plots, ids 0 through 255, x = id mod 16, y = id divided by 16. buyCity(cityId) only if the plot is empty, the caller owns no city, and the caller holds at least 1000 GRID before paying. Price in GRID is 10000 * (256 + soldPlots)^2 / 65536 tokens, where soldPlots is how many plots are already owned. The purchase amount is burned. Cities are soulbound: no transfer function. A new city starts at level 1 with 0 resources.\n\nlevelUp(cityId) is owner-only. Going from level n to n+1 consumes 100 * (n+1)^2 resources. Maximum level is 20. Reward claim weight is level squared. claimRewards(cityId) is owner-only and pays the caller their accrued GRID from the rewards pool.\n\nOnly GrantExecutor may call grantResources(cityId, amount) and recordHeartbeat(cityId1, amount1, cityId2, amount2, cityId3, amount3). Those amounts come out of the resource pot. recordHeartbeat stores the three winners for the site. Deploy GrantExecutor so only 0x5b95A971B4583A5f011E9DA082acdD679b870D06 can call it. That same address can pause and unpause grants only. Buys and claims stay live.\n\nWebsite, dark terminal style: 16 by 16 grid showing empty or owned and level, connect wallet, buy an empty plot, city panel with level, resources and claimable rewards, rewards-pool and resource-pot balances, last heartbeat winners, and this line: Trade GRID, tax fills the pots, a heartbeat grows the top cities, higher level earns more of the tax. Read the live Sepolia contracts.\n\nEvents: CityBought, ResourcesGranted, CityLeveled, RewardsClaimed, TaxTaken, HeartbeatRecorded.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — audit_judge: Approved universal 4% GRID transfer tax is still not implemented: transfer/transferFrom are fee-free and fund no pot, burn nothing, pay treasury nothing (unchanged; requester decision required)","contractsJobId":"874ecc59-afcf-4902-91c2-137e4fdafe43","frontendJobId":null,"createdAt":"2026-09-29T19:29:10.482Z","updatedAt":"2026-09-29T20:35:07.944Z","waitingForHosting":false},{"id":"edcf0173-2007-499d-b1bb-0fbdaf80ddce","objective":"Build COMP: a compute-backed stablecoin proof of concept on Ethereum Sepolia. Four contracts.\n\nMockIMD: ERC-20 collateral token, symbol IMD, name 'Identity MD', 18 decimals. Total supply starts at zero with no maximum cap — deployer calls mint(address, uint256) on demand to fund test wallets. No other admin.\n\nCompToken: the stablecoin, symbol COMP, name 'Compute Money', 18 decimals. This is a mintable, elastic-supply token — NOT a fixed-supply token. Total supply at genesis: 0. Maximum supply: none (unbounded, no cap). Minting: CDPVault mints new COMP continuously whenever any user calls mintCOMP() to borrow against their collateral. Burning: CDPVault burns COMP whenever any user calls repayCOMP() to repay debt. There is no initial mint, no presale, no airdrop. New tokens are created on demand by the vault as users borrow. Authorized minter/burner: exclusively the CDPVault contract address, set once via setVault(address) callable only by deployer; after that one call no admin or minting privilege remains on CompToken. Standard ERC-20 transfers, no fees or restrictions.\n\nIWorkOracle interface in src/interfaces/IWorkOracle.sol: mintingRights(address) returns uint256; consumeRights(address, uint256) external. MockWorkOracle implements it. Deployer calls grantRights(address, uint256) to add rights for testnet. CDPVault calls consumeRights on mint. Only vault may call consumeRights. Emits RightsGranted and RightsConsumed. This interface is what the real oracle (reading ERC-8004 work records) will implement as a drop-in.\n\nCDPVault: constructor(imdToken, compToken, oracle). One-time setOracle(address) callable once by deployer before going live; no admin after. Per-user Position{collateral, debt}. depositCollateral transfers IMD in. withdrawCollateral reverts if resulting CR < 150. mintCOMP requires oracle.mintingRights >= amount AND (collateral*100 >= (debt+amount)*150); consumes rights, mints COMP, increases debt. repayCOMP burns COMP, decreases debt. liquidate(owner, debtToRepay) callable by anyone when CR < 150; burns debtToRepay COMP from caller, sends debtToRepay*110/100 IMD to caller (10% bonus), reduces owner position. collateralRatio(owner) returns collateral*100/debt, max uint256 when debt==0. Price: 1 IMD == 1 COMP (fixed for testnet, documented in NatSpec).\n\nTests: unit every function + revert, fuzz deposit/mint/repay/withdraw sequences, invariant asserting totalSupply==sum(debt) and all positions with debt have CR>=150, liquidation scenario with correct math.\n\nFrontend: dark minimal UI, Sepolia only. Show wallet IMD balance, COMP balance, oracle minting rights, position (collateral, debt, CR%). Actions: Deposit IMD, Mint COMP, Repay COMP, Withdraw IMD. Health: green>=170%, amber 150-170%, red<150%. Admin panel (deployer only): grantRights form.","status":"completed","failure":null,"contractsJobId":"cee8c404-0d08-4783-baa3-c7db11cffcb3","frontendJobId":"f1d417aa-020e-4f8f-9075-553534c604ac","createdAt":"2026-09-29T16:02:54.605Z","updatedAt":"2026-09-29T20:04:08.230Z","waitingForHosting":false},{"id":"500e1a99-8e60-4d56-9f8d-ba82cbbdbe4c","objective":"Sepolia only (chainId 11155111). No mainnet.\n\nBuild ImdCardPayment: receives IMD, emits PaymentReceived. Anyone can pay. No owner admin. No user withdraw.\n\nNumbers: Claude-month pack IMD = ceil(Claude Pro USD / IMD mid) + 8% buffer (mock OK; formula in README). Min 1 pack, max 3/tx. Float target 3× pack USD. Refund if no card in 15m. Fee 0%.\n\nSite: pack picker, Sepolia connect, pay IMD, email, status, claim-card page, Sepolia badge. Copy only “Get a spend card” — never Uniswap, USDC, or Bitrefill. Wallet may only approve/pay IMD.\n\nOperator backend (sandbox OK) does swap + Bitrefill off-chain.\n\nAUTHORIZED: Sepolia deploy, public GitHub, public IPFS site label imd-bitrefill-card. Frontend + hosting required.","status":"blocked","failure":"Publication could not be validated within 24 hours. Published files and deployed contracts are preserved; retry validation after checking the reported availability problem.","contractsJobId":"306a0adc-ced5-4a74-b110-4ee52187546b","frontendJobId":"501472d7-f149-455e-8ee0-6df03c506480","createdAt":"2026-09-29T02:56:44.393Z","updatedAt":"2026-09-30T04:01:43.136Z","waitingForHosting":false},{"id":"0fff1998-fbcc-4169-90a6-5a7d854b0715","objective":"Build Pacts, a social guild strategy game on Sepolia played with its own token, Pact ($PACT), launch it, publish the source on GitHub and host its website on IPFS. Guilds hold tiles on a shared 12x12 map, attack each other in the open, vote on moves, and sign pacts backed by token bonds that are slashed to the victim if a guild betrays a partner. Seasons pay the top guilds and mint trophy NFTs.","status":"completed","failure":null,"contractsJobId":"3fa23364-90be-48d5-896c-31045d0c35bd","frontendJobId":"06dfbcec-4a2a-4dea-87e3-d15ab594fb9c","createdAt":"2026-09-29T02:13:19.324Z","updatedAt":"2026-09-29T19:47:47.763Z","waitingForHosting":false},{"id":"0c56259b-7643-4e93-b256-982ee1f871e9","objective":"Build Pacts, a social guild strategy game on Sepolia played with the launch token, launch it, publish the source on GitHub and host its website on IPFS. Guilds hold tiles on a shared 12x12 map, attack each other in the open, vote on moves, and sign pacts backed by token bonds that are slashed to the victim if a guild betrays a partner. Seasons pay the top guilds and mint trophy NFTs.","status":"blocked","failure":"findings: 2 blocking finding(s) never resolved — write_foundry_tests: Pact can be signed over an unresolved attack from the previous epoch, hiding the attacker's betrayal; audit_judge: signPact accepts a pact while an attack on the partner from the previous, unsettled epoch is still unresolved; the attacker takes the partner's tile inside the window without betrayal and the partner'","contractsJobId":"e94400fc-c704-4751-b2b4-5ca2bede9b28","frontendJobId":null,"createdAt":"2026-09-28T17:36:39.293Z","updatedAt":"2026-09-28T20:30:28.273Z","waitingForHosting":false},{"id":"5db9b1bb-d7ce-4868-8481-3086f2501040","objective":"Build Agent Arcade: an English-only Sepolia prototype with a token, genuine POOL4 market and FWA-inspired mystery packs.\n\nToken: Workflow Demo (WFD), 1,000,000 supply, 18 decimals, minted once. Standard unrestricted ERC-20 transfers; no extra minting or transfer tax. Allocate 100% equally per actively enrolled Identity MD NFT, including offline agents. Ethereum collection: 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d. Verify enrollment semantics and complete coverage; freeze timestamped evidence and ownership at a finalized block. Aggregate allocations to owners, with deterministic rounding. Use immutable, replay-protected, fixed-recipient Merkle claims without expiry. Resolve cross-chain contract-wallet ownership; never invent recipients. Identity NFTs are never wagered.\n\nUse verified POOL4 source and compatible Sepolia dependencies. Document hook permissions, burn routes and admin powers. Isolate liquidity from claims and prizes. Initial liquidity and prizes require voluntary funding, never claim reserves or additional minting.\n\nGame: one sponsor, finite immutable epochs, at most 64 collectible packs fully backed by WFD. Equal odds per remaining pack. Winner keeps its NFT or redeems backing to its current owner. For remaining backing B and pack count N, price=ceil(B*10000/(N*9500)); 5% fee, remainder to sponsor. Show exact odds, expected payout and costs. Stop draws when fewer than two distinct backing values remain. Bind purchases to inventory version and maximum costs.\n\nUse authenticated verifiable randomness, one pending draw, no cancellation or rerolls after acceptance. Callback stores randomness; permissionless settlement and separate prize delivery prevent recipient blocking. Disclose provider delays. Preserve all backing and payment liabilities; prevent replay, reentrancy and double redemption. Pause stops new draws only.\n\nWallets can claim, swap, draw, receive and redeem packs. Build Claim, Market, Arcade, Vault and Transparency views. Verify feasibility, funding, accounting invariants and adversarial tests; obtain independent review. Publish source and site when deployment permits. Report missing dependencies or funding honestly; provide a labeled local demo. No mainnet or real-value wagering.\n\nI authorize publishing this project's source code publicly on GitHub and publishing its usable English-language website at a public URL through IMD's IPFS/ENS hosting. Public website publication is a required deliverable. Contract deployment remains Sepolia-only; this does not authorize mainnet deployment or spending additional wallet funds.","status":"blocked","failure":"findings: 1 blocking finding(s) never resolved — adversarial_review: Manifest still binds the immutable arcade to VRF subscription 7777, which does not exist on Sepolia (unresolved; blocked on operator input, not on the manifest author)","contractsJobId":"d1a4a499-71e5-4541-b14f-562b25101a49","frontendJobId":null,"createdAt":"2026-09-27T22:03:19.644Z","updatedAt":"2026-09-27T23:01:55.109Z","waitingForHosting":false},{"id":"496a626a-1d0a-4abf-8219-4c07d1e958cc","objective":"Release Draw (ERC-20 symbol DRAW) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Draw (DRAW), total supply 1,000,000,000 DRAW with 18 decimals, minted once to the deployer. Application contract: BlockhashLottery. Currency: DRAW is the app's working currency. BlockhashLottery's constructor takes one argument, the DRAW address (constructorArgs [\"$token\"]); it stores the token immutable, exposes it as token(), and holds no DRAW at deploy and never needs any: users get DRAW by swapping Sepolia ETH in the ETH/DRAW launch pool the factory seeds. Every payment in is approve + SafeERC20.safeTransferFrom; payouts are pull withdrawals (safeTransfer to the caller, checks-effects-interactions, nonReentrant); burns are transfers to 0x000000000000000000000000000000000000dEaD. DRAW is a plain fixed-supply ERC-20 with no transfer fee, so the amount pulled is the amount credited. BlockhashLottery has no payable function and no receive/fallback, so it never holds ETH. No owner, admin, pause or upgrade path. A Sepolia test toy with no value; say so on the site. Rounds are fixed windows of 300 blocks from the deployment block G: round r sells in blocks [G + 300r, G + 300r + 299]; closeBlock = G + 300r + 299; drawBlock = closeBlock + 5. buy(count): count 1 to 100 tickets at 1,000 DRAW each into the round of the current block; buys are stored as cumulative ranges (buyer, endIndex) so the winner is found by binary search. settle(r): anyone, once block.number > drawBlock (earlier reverts), exactly once per round. If r sold no tickets, its carry-in moves to the round open at settle time. Else if drawBlock < block.number <= drawBlock + 256 and blockhash(drawBlock) != 0, the winning index is uint256(keccak256(blockhash(drawBlock), r)) % ticketCount; the pot is ticketCount x 1,000 DRAW + carry-in; the winner is credited 95% (floor) and the other 5% moves to the round open at settle time. Else, once block.number > drawBlock + 256 (the hash is gone), the round is Expired: each buyer calls refund(r) once to credit its tickets at full price to claimable, and the carry-in moves forward. claim(): pull all credited winnings and refunds. Randomness note for the README: a Sepolia validator could withhold a block to change the outcome at the cost of its block reward; the pot is a test toy. Nobody can buy after seeing the hash, because sales close 5 blocks earlier. Views: currentRound(), roundInfo(r) (tickets, carryIn, state, winner, prize), ticketsOf(r, buyer), claimable(address). Events: Bought, Settled(r, winner, prize, carryOut), Expired(r), Claimed. Tests (Foundry, with vm.roll) must show: settle at drawBlock + 1 and drawBlock + 256 draws, at drawBlock + 257 expires with full refunds, a zero-ticket round forwards its carry, a one-ticket round pays that buyer, buys after closeBlock land in the next round, double settle reverts, and the invariant DRAW balance == claimable + unsettled pots. The independent adversarial review must attack: the blockhash window (0 hash, off-by-one), range lookup off-by-one, carry accounting across settle order, double settle or double refund, and anyone predicting or steering the result. Deploy through the project factory, then publish a one-page website to buy tickets, show the current round, blocks until close and until the draw block, the pot, a settle button, your claimable balance with claim, and past winners from Settled events. The page reads the DRAW address from BlockhashLottery.token(), shows the connected wallet's DRAW balance and allowance, has an Approve step before every paying action, and says DRAW comes from swapping Sepolia ETH in the launch pool (no in-page swap). Lists come from contract views and events only (no backend, no indexer; log queries are chunked from the deployment block). Keep it to one small page; the static export has index.html in dist/.","status":"completed","failure":null,"contractsJobId":"2cde48a3-ff2a-43de-b029-7668f8d55aa3","frontendJobId":"c187d537-3915-49ec-bcc0-6316976bb8f2","createdAt":"2026-09-27T06:16:43.506Z","updatedAt":"2026-09-27T19:42:24.233Z","waitingForHosting":false},{"id":"3d6d5703-74ce-4842-851b-94f201a6624e","objective":"Release Blockcap (token symbol BCAP) on Sepolia as a univ4_hook launch. Token: Blockcap (BCAP), total supply 1,000,000,000 BCAP with 18 decimals, minted once to the deployer. Hook: BlockOutflowCapHook, a Uniswap v4 hook on the token's native-ETH pool (currency0 native ETH, currency1 BCAP, LP fee 3000, tickSpacing 60; the factory seeds one-sided BCAP liquidity, so the first buy lands in a pool holding no ETH). In v4, amountSpecified < 0 is exact input and zeroForOne is a buy (ETH in, BCAP out). The hook extends v4-periphery BaseHook; constructor (IPoolManager poolManager) with the Sepolia PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543. getHookPermissions enables exactly afterInitialize and afterSwap (no deltas, no fees); the manifest lists the same set. State is keyed by PoolId, so any pool may attach the hook. No owner, no admin. Rule: CAP = 2,500,000 x 10^18 BCAP (0.25% of the fixed 1,000,000,000 supply), a constant, per pool per block, active for 86,400 seconds from initialisation (afterInitialize records capEndsAt = block.timestamp + 1 day; at capEndsAt and after, no cap). Counted: BCAP paid out to swappers by buys, i.e. the positive currency1 amount of the swap delta in afterSwap, exact input or exact output alike. Sells, liquidity removals and donations are not counted, and sells do not give allowance back. The per-block total resets when block.number changes. A buy that would take the block's total above CAP reverts BlockCapExceeded(used, CAP) as a whole (no clamping). Events: Outflow(PoolId indexed poolId, uint256 blockNumber, uint256 amount, uint256 usedInBlock). Views: status(PoolId) -> (bool active, uint256 remainingThisBlock, uint256 capEndsAt), where remaining is CAP when the stored block is not the current one. Tests run against a real v4-core PoolManager and include a launch rehearsal: one-sided BCAP liquidity below the opening price, a first buy into the ETH-less pool, then a sell. Acceptance: buys in one block summing to exactly CAP pass and one more wei reverts; a new block resets; exact-output buys count their actual output; sells never count; no cap at capEndsAt; two pools are independent. Then a small website that shows this block's remaining allowance, time left in the capped day, recent Outflow events per block, and a swap form that quotes a buy and warns when its output exceeds the remaining allowance. Swaps go through PoolSwapTest 0x9B6b46e2c869aa39918Db7f52f5557FE577B6eEe (it forwards hookData and sqrtPriceLimitX96), prices come from StateView 0xE1Dd9c3fA50EDB962E442f60DfBc432e24537E4C and quotes from V4Quoter 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 (all live on Sepolia). One page, no backend.","status":"completed","failure":null,"contractsJobId":"c796f3fb-2e0e-4864-bdb3-6409bbb5cc64","frontendJobId":"9707a5b0-ba78-4913-bf80-ed47e820034f","createdAt":"2026-09-27T06:15:27.587Z","updatedAt":"2026-09-27T18:38:23.855Z","waitingForHosting":false},{"id":"6995d9db-a6b9-4e03-add9-607058a1c7d9","objective":"Release Soapbox (ERC-20 symbol SOAP) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Soapbox (SOAP), total supply 1,000,000,000 SOAP with 18 decimals, minted once to the deployer. Application contract: Soapbox. Currency: SOAP is the app's working currency. Soapbox's constructor takes one argument, the SOAP address (constructorArgs [\"$token\"]); it stores the token immutable, exposes it as token(), and holds no SOAP at deploy and never needs any: users get SOAP by swapping Sepolia ETH in the ETH/SOAP launch pool the factory seeds. Every payment in is approve + SafeERC20.safeTransferFrom; payouts are pull withdrawals (safeTransfer to the caller, checks-effects-interactions, nonReentrant); burns are transfers to 0x000000000000000000000000000000000000dEaD. SOAP is a plain fixed-supply ERC-20 with no transfer fee, so the amount pulled is the amount credited. Soapbox has no payable function and no receive/fallback, so it never holds ETH. No owner, admin, moderation, pause or upgrade path. post(bytes32 topic, string body): body 1 to 280 bytes (UTF-8 byte length); the fee is 100 SOAP (100e18 units) moved with safeTransferFrom(poster, 0x000000000000000000000000000000000000dEaD, 100e18), so Soapbox never holds SOAP; ids from 1. The body is only emitted in Posted(id, author, topic, body); storage keeps author, topic, timestamp and tipsTotal per post. tip(postId, amount): the post exists, amount >= 1 SOAP; safeTransferFrom(tipper, author, amount) straight to the author; tipsTotal += amount; Tipped(postId, tipper, amount). Self-tips are allowed and pointless. Posts cannot be edited or deleted; everything is public forever. Views: postCount(), post(id), token(). Tests (Foundry) must show: body lengths 0, 1, 280 and 281; the exact 100 SOAP burn; tips reaching the author; tips to a missing post or below 1 SOAP reverting; Soapbox's SOAP balance always 0. The independent adversarial review must attack: fee bypass, tips credited to the wrong post or author, and in the site script injection through bodies or topics. Deploy through the project factory, then publish a one-page website to post (topic + body with a byte counter), tip, and a feed read from Posted events sorted by tipsTotal with a topic filter. Bodies and topics render as plain escaped text (no HTML, no auto-links) under a note that posts are unmoderated user content. The page reads the SOAP address from Soapbox.token(), shows the connected wallet's SOAP balance and allowance, has an Approve step before every paying action, and says SOAP comes from swapping Sepolia ETH in the launch pool (no in-page swap). Lists come from contract views and events only (no backend, no indexer; log queries are chunked from the deployment block). Keep it to one small page; the static export has index.html in dist/.","status":"completed","failure":null,"contractsJobId":"864bc7bb-c766-422d-a63d-cb8938e8f937","frontendJobId":"9f4df9c3-526d-4ce6-a243-2a912f3277cc","createdAt":"2026-09-27T06:15:27.347Z","updatedAt":"2026-09-27T20:08:04.512Z","waitingForHosting":false},{"id":"3e378fab-5bce-4930-840d-3b148ff1e7e6","objective":"Release Stoploss (token symbol STOP) on Sepolia as a univ4_hook launch. Token: Stoploss (STOP), total supply 1,000,000,000 STOP with 18 decimals, minted once to the deployer. Hook: StopLossHook, a Uniswap v4 hook on the token's native-ETH pool (currency0 native ETH, currency1 STOP, LP fee 3000, tickSpacing 60; the factory seeds one-sided STOP liquidity, so the first buy lands in a pool holding no ETH). In v4, amountSpecified < 0 is exact input and zeroForOne is a buy (ETH in, STOP out). Orientation: tick = log base 1.0001 of STOP per ETH, so STOP's ETH price FALLS as the tick RISES; sells (oneForZero) push the tick up and are what trigger a stop-loss. The hook extends v4-periphery BaseHook; constructor (IPoolManager poolManager) with the Sepolia PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543. getHookPermissions enables exactly beforeSwap and afterSwap (no return deltas); the manifest lists the same set. State is keyed by PoolId, so any pool may attach the hook. No owner, no admin, no fee. Orders: placeOrder(PoolKey key, int24 triggerTick, uint128 amount) pulls amount STOP from the caller (approve first), requires amount >= 1 STOP, triggerTick a multiple of 60 and strictly above the current tick, and returns an orderId. Orders at one triggerTick share a bucket; each bucket has an open epoch, and an order joins the open epoch. cancel(orderId): owner only, only while its epoch is unexecuted; refunds the STOP. Execution: beforeSwap stores the pre-swap tick in transient storage. afterSwap, for sells only, finds buckets with triggerTick in (tickBefore, tickAfter] using a bitmap of active trigger ticks (reuse v4-core's TickBitmap library, scanning at most 4 words) and executes up to 5 of those buckets, lowest trigger first; levels crossed only by the hook's own sells are left for execute(). A bucket is executed only while the current tick is below its triggerTick + 1200: a limit on the wrong side of the price would make the PoolManager revert the user's sell, so a bucket the price has already jumped past is skipped, stays open and cancellable, and execute() fills it if the price comes back inside that window. Each bucket's epoch is sold in one internal poolManager.swap (hook as caller, so the PoolManager does not re-enter the hook), exact input, sqrtPriceLimit at triggerTick + 1200 (STOP about 11% cheaper in ETH than at the trigger price) so a thin pool cannot dump an order to nothing. The hook settles the STOP it sells (sync, transfer, settle) and mints the ETH output as ERC-6909 claims; its deltas are zero before afterSwap returns. STOP left unsold at the limit stays with that epoch. The epoch is closed either way; later orders at that tick open a new epoch. execute(PoolKey key, uint256 maxBuckets <= 5) is permissionless: it unlocks the PoolManager and executes open buckets whose trigger is at or below the current tick (catch-up after a crossing of more than 5 levels or by the hook's own sells; it skips buckets whose limit the price has passed, as above). claim(orderId): owner only, once, after execution: pays ETH = epochEthOut x amount / epochAmount (burning claims and taking native ETH to the owner) and unsold STOP = epochUnsold x amount / epochAmount, both rounded down; rounding dust stays in the hook and is documented. unlockCallback accepts only the PoolManager during a call the hook started; placeOrder, cancel, claim and execute are nonReentrant. Events: OrderPlaced(orderId, owner, poolId, triggerTick, amount, epoch), OrderCancelled(orderId), BucketExecuted(poolId, triggerTick, epoch, stopSold, ethOut, unsold), Claimed(orderId, owner, eth, stop). Views: order(orderId), epoch(poolId, triggerTick, epoch), and the open amount per trigger tick; owner is indexed in OrderPlaced so the site can list a wallet's orders. Tests run against a real v4-core PoolManager and include a launch rehearsal: one-sided STOP liquidity below the opening price, a first buy into the ETH-less pool, then a sell. Acceptance: invariants: STOP held == open orders + unclaimed unsold; ETH claims held == unclaimed epoch ETH. A sell crossing 7 levels executes 5 and execute() finishes the rest; a sell that jumps more than 1,200 ticks past a trigger succeeds and leaves that bucket open; buys never trigger; the price limit leaves unsold STOP claimable; cancel after execution and a second claim revert; gas of a sell that executes 5 buckets is reported (the seller pays it; say so in the README). One contract, about 400 lines at most. Then a small website to place (approve, then place), list, cancel and claim orders, show open STOP per trigger price from events, and a swap form. Swaps go through PoolSwapTest 0x9B6b46e2c869aa39918Db7f52f5557FE577B6eEe (it forwards hookData and sqrtPriceLimitX96), prices come from StateView 0xE1Dd9c3fA50EDB962E442f60DfBc432e24537E4C and quotes from V4Quoter 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 (all live on Sepolia). One page, no backend.","status":"completed","failure":null,"contractsJobId":"f1df2937-a200-4224-9e8f-068d48ad3bee","frontendJobId":"2836c5fc-72df-4fcc-8611-13ad0e7f54b0","createdAt":"2026-09-27T06:13:40.188Z","updatedAt":"2026-09-27T18:22:09.981Z","waitingForHosting":false},{"id":"ca30dd68-b768-4b9d-9421-4463ccbc52f0","objective":"Release Sponsor (ERC-20 symbol SPON) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Sponsor (SPON), total supply 1,000,000,000 SPON with 18 decimals, minted once to the deployer. Application contract: DaemonSponsorPool. Currency: SPON is the app's working currency. DaemonSponsorPool's constructor takes one argument, the SPON address (constructorArgs [\"$token\"]); it stores the token immutable, exposes it as token(), and holds no SPON at deploy and never needs any: users get SPON by swapping Sepolia ETH in the ETH/SPON launch pool the factory seeds. Every payment in is approve + SafeERC20.safeTransferFrom; payouts are pull withdrawals (safeTransfer to the caller, checks-effects-interactions, nonReentrant); burns are transfers to 0x000000000000000000000000000000000000dEaD. SPON is a plain fixed-supply ERC-20 with no transfer fee, so the amount pulled is the amount credited. DaemonSponsorPool has no payable function and no receive/fallback, so it never holds ETH. No owner, admin, pause or upgrade path. A Sepolia test toy modelled on worker daemons; it is not connected to any real IMD payment. Epochs are 24 hours from the deployment timestamp: epoch = (block.timestamp - genesis) / 1 days. Workers: register() pulls a 100,000 SPON bond; deregister() stops future check-ins and the bond becomes withdrawable (withdrawBond) once the epoch in which deregister was called has ended; after withdrawing it the address may register again. Sponsors: sponsor(amount) pulls SPON into the pool; sponsorship is a gift and cannot be withdrawn. checkIn(): a registered worker, once per epoch. Budgets: every state-changing call first rolls the epoch: if the current epoch has no budget yet, it finalises the last epoch that had one (if nobody checked in there its whole budget returns to the pool; otherwise the division dust budget - share x checkIns returns), then sets budget[current] = pool / 7 (floor) and moves it out of the pool. Epochs nobody touched get no budget, so an idle gap loses nothing. claim(epoch): a worker who checked in to a past epoch withdraws share = budget / checkIns (floor), once (pull). Sybil workers need a bond each, so payouts are bond-weighted at best; document that. Views: currentEpoch(), epochInfo(e) (budget, checkIns, finalised), pool(), isRegistered(w), checkedIn(e, w), claimable(e, w). Events: Registered, Deregistered, BondWithdrawn, Sponsored, CheckedIn, EpochRolled(e, budget), Claimed. Tests (Foundry) must show: the 24-hour boundary, an epoch with zero check-ins returning its budget, dust returning, an idle multi-day gap, double check-in and double claim reverting, claims only for past epochs, bond withdrawal timing, and the invariant SPON balance == pool + unclaimed budgets + bonds. The independent adversarial review must attack: budget snapshot timing (sponsoring or checking in first to move the budget), roll ordering bugs, double payment, bond escape before the epoch ends, and SPON left unclaimable. Deploy through the project factory, then publish a one-page website to register (approve bond), check in, sponsor, show the current epoch with countdown, budget and check-ins, list past epochs with your claimable share and a claim button, and deregister/withdraw the bond. The page reads the SPON address from DaemonSponsorPool.token(), shows the connected wallet's SPON balance and allowance, has an Approve step before every paying action, and says SPON comes from swapping Sepolia ETH in the launch pool (no in-page swap). Lists come from contract views and events only (no backend, no indexer; log queries are chunked from the deployment block). Keep it to one small page; the static export has index.html in dist/.","status":"completed","failure":null,"contractsJobId":"4436d4f7-fd34-4cea-977b-16a51cf87592","frontendJobId":"95a73545-d7ed-4849-9ee5-6e7b0aa6ff69","createdAt":"2026-09-27T06:13:19.335Z","updatedAt":"2026-09-27T18:07:08.648Z","waitingForHosting":false},{"id":"1cd8221b-a809-4132-a540-6af5fc87de42","objective":"Release Allowlist (token symbol ALST) on Sepolia as a univ4_hook launch. Token: Allowlist (ALST), total supply 1,000,000,000 ALST with 18 decimals, minted once to the deployer. Hook: AllowlistLaunchHook, a Uniswap v4 hook on the token's native-ETH pool (currency0 native ETH, currency1 ALST, LP fee 3000, tickSpacing 60; the factory seeds one-sided ALST liquidity, so the first buy lands in a pool holding no ETH). In v4, amountSpecified < 0 is exact input and zeroForOne is a buy (ETH in, ALST out). The hook extends v4-periphery BaseHook; its only constructor argument is the Sepolia PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543 (constructor (IPoolManager poolManager)); no owner, signer, admin, $owner or $token, and no way to extend the window. getHookPermissions enables exactly afterInitialize and beforeSwap (low address bits 0x1080; no deltas, no fees, no liquidity callbacks, so the factory's seeding and any LP work during the window); the manifest lists the same set. State is keyed by PoolId; pools whose currency0 is not native ETH are never gated. The allowlist is the token's existing holders. Window: afterInitialize sets openAt[poolId] = block.timestamp + 24 hours. While block.timestamp < openAt, beforeSwap allows a swap in either direction only if tx.origin holds at least 1 ALST (10^18 units) of the pool's currency1, read with a low-level staticcall to balanceOf capped at 50,000 gas and decoded only when it returns exactly 32 bytes; a revert, out-of-gas or bad return counts as zero. Otherwise it reverts NotAllowlisted(tx.origin). On the launch pool the ALST outside the pool at launch is mostly the factory's reward distribution (launch contributors and recently active swarm wallets), so the first day belongs to wallets that claimed launch rewards and anyone they send ALST to. From openAt on anyone swaps and nothing is read. Why tx.origin: this hook credits nobody, so the context's hookData identity rule does not apply, and a hookData address would let anyone borrow a holder's place; the v4 sender is the router, so the transaction signer is the only identity the hook can check without a trusted router. Document the limits in NatSpec and README: contract and ERC-4337 wallets are judged by the EOA that sends the transaction, a phishing contract could make a holder swap, sending 1 ALST adds a wallet to the list, the window can pass with no swaps if nobody has claimed rewards, and tx.origin is never read after the window. Events: HolderSwap(PoolId indexed poolId, address indexed origin, uint256 balance) for each swap allowed inside the window. Views: openAt(poolId), isOpen(poolId), isAllowed(poolId, account) (true from openAt on, else the balance rule). Tests run against a real v4-core PoolManager and include a launch rehearsal: one-sided ALST liquidity below the opening price, a first buy into the ETH-less pool, then a sell. The first buy comes from a wallet holding ALST (standing in for a reward claimant). Acceptance: a holder buys and sells in the window; a non-holder, a wallet holding 1 ALST minus 1 wei, and a call where only msg.sender and not tx.origin holds (vm.prank(sender, origin)) revert NotAllowlisted; a currency1 whose balanceOf reverts, returns garbage or burns all gas gives NotAllowlisted, not an unexpected error; at exactly openAt a non-holder swaps; adding and removing liquidity is never gated. Then a small website that shows time left in the window, the connected wallet's ALST balance and whether it may swap now (isAllowed), and a swap form. Swaps go through PoolSwapTest 0x9B6b46e2c869aa39918Db7f52f5557FE577B6eEe (it forwards hookData and sqrtPriceLimitX96), prices come from StateView 0xE1Dd9c3fA50EDB962E442f60DfBc432e24537E4C and quotes from V4Quoter 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 (all live on Sepolia). One page, no backend.","status":"completed","failure":null,"contractsJobId":"04c6d76d-3c60-4f08-ae24-ca32bea8b9b2","frontendJobId":"20d47076-7196-42ee-83ab-5785c2a5633d","createdAt":"2026-09-27T06:09:32.265Z","updatedAt":"2026-09-27T19:02:44.282Z","waitingForHosting":false},{"id":"b6ac9cf2-a1dd-4ddc-9165-3b52024e50f3","objective":"Release Piggy (ERC-20 symbol PIGY) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Piggy (PIGY), total supply 1,000,000,000 PIGY with 18 decimals, minted once to the deployer. Application contract: DonationVault4626. Currency: PIGY is the app's working currency. DonationVault4626's constructor takes one argument, the PIGY address as the asset (constructorArgs [\"$token\"]); it stores the token immutable, exposes it as token(), and holds no PIGY at deploy and never needs any: users get PIGY by swapping Sepolia ETH in the ETH/PIGY launch pool the factory seeds. Every payment in is approve + SafeERC20.safeTransferFrom; payouts are pull withdrawals (safeTransfer to the caller, checks-effects-interactions, nonReentrant); burns are transfers to 0x000000000000000000000000000000000000dEaD. PIGY is a plain fixed-supply ERC-20 with no transfer fee, so the amount pulled is the amount credited. DonationVault4626 has no payable function and no receive/fallback, so it never holds ETH. No owner, fees, admin, pause or upgrade path. DonationVault4626 is an OpenZeppelin ERC-4626 vault over PIGY with share name \"Piggy Vault\" and symbol \"vPIGY\" and _decimalsOffset() = 6 (virtual shares), so the first-depositor inflation attack does not pay. Yield comes only from donations, and donations stream in: donate(amount) pulls PIGY and adds it to a linear 7-day unlock (lockedAmount = unvested(now) + amount, lockEnd = now + 7 days); totalAssets() = PIGY balance - unvested(now), so a deposit placed just before a donation and redeemed just after gains almost nothing. PIGY sent straight to the vault by transfer counts immediately (it cannot be streamed); document it. Rounding follows EIP-4626 (always in the vault's favour); max*/preview* stay consistent with the overridden totalAssets(). A deposit that would mint 0 shares reverts. If every share is redeemed while donations are still vesting, the vested remainder accrues to the next depositors (document). Emit Snapshot(totalAssets, totalSupply) after every deposit, mint, withdraw, redeem and donate, plus Donated(donor, amount, lockEnd). Views: unvested(), lockEnd(), sharePrice() = convertToAssets(10^(18+6)). Tests (Foundry) must show: an attacker who deposits 1 wei and donates before a victim's deposit never profits (fuzz); a deposit-donate-redeem sandwich in one block gains at most rounding; unvested() falls linearly and overlapping donations merge correctly; previews match results; invariant totalAssets() <= PIGY balance. The independent adversarial review must attack: the totalAssets override against every 4626 entry point, rounding direction, stream arithmetic at lockEnd and with overlapping donations, the inflation attack with offset 6, and direct-transfer donations. Deploy through the project factory, then publish a one-page website to deposit, redeem and donate, showing your shares and their PIGY value, the unvested amount and lockEnd, and a share-price history chart from Snapshot events. The page reads the PIGY address from DonationVault4626.token(), shows the connected wallet's PIGY balance and allowance, has an Approve step before every paying action, and says PIGY comes from swapping Sepolia ETH in the launch pool (no in-page swap). Lists come from contract views and events only (no backend, no indexer; log queries are chunked from the deployment block). Keep it to one small page; the static export has index.html in dist/.","status":"completed","failure":null,"contractsJobId":"38036434-82ac-49e6-92ca-859ee4c6038a","frontendJobId":"ca3dde2a-ddb3-4177-803f-99c8bcc82250","createdAt":"2026-09-27T06:09:32.040Z","updatedAt":"2026-09-27T17:37:56.083Z","waitingForHosting":false},{"id":"ac4e7c1a-37e2-42d7-8571-14430f5a5f27","objective":"Release Band (token symbol BAND) on Sepolia as a univ4_hook launch. Token: Band (BAND), total supply 1,000,000,000 BAND with 18 decimals, minted once to the deployer. Hook: PriceBandHook, a Uniswap v4 hook on the token's native-ETH pool (currency0 native ETH, currency1 BAND, LP fee 3000, tickSpacing 60; the factory seeds one-sided BAND liquidity, so the first buy lands in a pool holding no ETH). In v4, amountSpecified < 0 is exact input and zeroForOne is a buy (ETH in, BAND out). The hook extends v4-periphery BaseHook; constructor (IPoolManager poolManager) with the Sepolia PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543. getHookPermissions enables exactly afterInitialize and afterSwap (no deltas, no fees); the manifest lists the same set. State is keyed by PoolId, so any pool may attach the hook. No owner, no admin. Prices are pool ticks (tick = log base 1.0001 of BAND per ETH). Hours are UTC: h = block.timestamp / 3600. afterInitialize records the tick and time. On every swap, afterSwap first rolls a time-weighted accumulator forward from the last update to block.timestamp at lastTick (the tick after the previous swap; only swaps move it), closing each hour boundary it crosses: a closed hour's average = sum(tick x seconds) / seconds covered, rounded toward negative infinity; the initialisation hour covers only the seconds after initialisation; an hour with no swap averages to the tick that held throughout, so a gap of any length costs O(1) gas. Band: from the last completed hour's average A, lower = A - 2231 and upper = A + 1823 ticks inclusive (1.0001^-2231 ~ 0.80 and 1.0001^1823 ~ 1.20, i.e. BAND per ETH within 80%-120% of the average; BAND's ETH price within about 83%-125%). Until the first hour completes there is no band. With t0 = lastTick and t1 = the tick after the swap, the swap is allowed if lower <= t1 <= upper, or if t1 is strictly closer to the band than t0 (a swap back toward the band is never blocked, so the pool cannot freeze); otherwise afterSwap reverts PriceOutOfBand(t1, lower, upper). Then lastTick = t1. Events: HourClosed(PoolId indexed poolId, uint256 hour, int24 avgTick) for the latest hour a swap closes. Views: band(PoolId) -> (bool active, int24 avgTick, int24 lower, int24 upper, uint256 hour) computed as of block.timestamp exactly as the next swap would, and lastTick(PoolId). Tests run against a real v4-core PoolManager and include a launch rehearsal: one-sided BAND liquidity below the opening price, a first buy into the ETH-less pool, then a sell. Acceptance (vm.warp): first hour unbounded; edges inclusive and one tick outside reverts; a swap moving toward the band from outside is allowed; a 1-hour and a 1,000-hour gap give the right average; negative ticks round down; band() equals what the next swap enforces. Then a small website that shows the last completed hour's average price (in ETH per BAND and BAND per ETH), the allowed band, the current price and whether the band is active, and a swap form that sets sqrtPriceLimitX96 one tick inside the band edge (a swap that stops exactly on an initialized edge tick while falling reports the tick below it) so an oversized swap fills partially instead of reverting. Swaps go through PoolSwapTest 0x9B6b46e2c869aa39918Db7f52f5557FE577B6eEe (it forwards hookData and sqrtPriceLimitX96), prices come from StateView 0xE1Dd9c3fA50EDB962E442f60DfBc432e24537E4C and quotes from V4Quoter 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 (all live on Sepolia). One page, no backend.","status":"completed","failure":null,"contractsJobId":"5916a46a-dbd2-4fb0-a94b-05e7149d6ca4","frontendJobId":"0d8a5041-b19c-4507-8e3b-eec402b5a28c","createdAt":"2026-09-27T06:08:09.781Z","updatedAt":"2026-09-27T18:23:39.884Z","waitingForHosting":false},{"id":"7acfd871-54a9-4646-9d24-2e42ee2de1a3","objective":"Release Trickle (ERC-20 symbol TRKL) on Sepolia as an evm_project: the fixed-supply launch token plus one application contract. Token: Trickle (TRKL), total supply 1,000,000,000 TRKL with 18 decimals, minted once to the deployer. Application contract: ETHStakingRewards. Currency: users stake TRKL and earn ETH. ETHStakingRewards's constructor takes one argument, the TRKL address (constructorArgs [\"$token\"]); it stores the token immutable, exposes it as token(), and holds no TRKL at deploy and never needs any: users get TRKL by swapping Sepolia ETH in the ETH/TRKL launch pool the factory seeds. stake is approve + SafeERC20.safeTransferFrom; withdraw returns TRKL with safeTransfer and getReward pays ETH with call, always to the caller only, checks-effects-interactions, nonReentrant. TRKL is a plain fixed-supply ERC-20 with no transfer fee, so the amount pulled is the amount credited. ETHStakingRewards has no receive/fallback; ETH enters only through notifyRewardAmount(). No owner, admin, pause or upgrade path. A Sepolia test toy that only moves Sepolia test ETH; it promises no yield or return, and the README and the page say so. Reward accounting is the usual rewardPerToken / userRewardPerTokenPaid pattern, with TRKL staked, ETH paid out and the notify rules below: stake(amount), withdraw(amount), getReward(), exit(), earned(account), rewardPerToken() (scaled 1e18), rewardRate (wei per second while streaming), periodFinish, currentRate() (rewardRate before periodFinish, 0 after it, so the page never shows a finished stream as live), carry(), totalStaked(), stakedOf(account). notifyRewardAmount() payable: anyone, msg.value >= 0.001 ETH; if the period has finished, it starts a new stream: rewardRate = (msg.value + carry) / 7 days and periodFinish = now + 7 days; while a stream is running, msg.value is added to carry instead, so a top-up never changes or slows the running stream. carry also collects rewards that were scheduled while totalStaked was 0 and the remainder of the rate division; the next stream start re-streams it, and restream() (anyone, only after periodFinish, with totalStaked > 0 and carry >= 0.001 ETH) starts a new 7-day stream from carry alone, so carried ETH never has to wait for a new donor. Reward state is updated before every stake, withdraw, claim and notify. getReward zeroes rewards[msg.sender] before the ETH call. Events: Staked, Withdrawn, RewardPaid, RewardAdded(amount, rate, periodFinish). Edge cases: stake or withdraw 0 reverts; withdrawing more than staked reverts; stake and withdraw in one block earns 0; a staker who joins mid-period earns only from then. Tests (Foundry) must cover: stake, withdraw, getReward and exit; a zero-stake stretch whose rewards reach carry and are re-streamed by restream(); a top-up mid-period landing in carry; stake and withdraw in one block; and, fuzzing stakers, amounts and warps, the invariant that ETH paid + sum of earned + carry + still-scheduled rewards never exceeds ETH notified. The independent adversarial review must attack: the reward-conservation invariant, any top-up that changes a running stream, precision loss for small stakes, the zero-stake period, and re-entrancy on ETH payout. Deploy through the project factory, then publish a one-page website to stake, withdraw, claim and exit, showing your stake, earned ETH, currentRate(), time to periodFinish, and the reward stream as ETH per day per 1,000,000 TRKL staked (no price oracle, so no % APR), plus a form to add ETH to the reward stream. The page reads the TRKL address from ETHStakingRewards.token(), shows the connected wallet's TRKL balance and allowance, has a TRKL Approve step before staking, and says TRKL comes from swapping Sepolia ETH in the launch pool (no in-page swap). Everything shown comes from contract views (no backend, no indexer). Keep it to one small page; the static export has index.html in dist/.","status":"completed","failure":null,"contractsJobId":"1532898b-4f69-4c18-aadf-7c05b8fddcf1","frontendJobId":"919adb97-b101-4b1e-957b-ae75813d2dd9","createdAt":"2026-09-27T06:08:09.140Z","updatedAt":"2026-09-27T17:48:01.156Z","waitingForHosting":false},{"id":"9e985641-e939-4326-bae0-f58ceb329051","objective":"Release Gas Tax (token symbol GASP) on Sepolia as a univ4_hook launch. Token: Gas Tax (GASP), total supply 1,000,000,000 GASP with 18 decimals, minted once to the deployer. Hook: GasPriceFeeHook, a Uniswap v4 hook on the token's native-ETH pool (currency0 native ETH, currency1 GASP, LP fee 3000, tickSpacing 60; the factory seeds one-sided GASP liquidity, so the first buy lands in a pool holding no ETH). In v4, amountSpecified < 0 is exact input and zeroForOne is a buy (ETH in, GASP out). The hook extends v4-periphery BaseHook; constructor (IPoolManager poolManager) with the Sepolia PoolManager 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543. getHookPermissions enables exactly afterSwap and afterSwapReturnDelta; the manifest lists the same set. State is keyed by PoolId, so any pool may attach the hook. Rule: tip = tx.gasprice - block.basefee. A swap is high tier, paying a 300 bps (3%) hook fee, when tx.gasprice > 2 x block.basefee AND tip >= 3 gwei (constant MIN_TIP); otherwise it pays 30 bps (0.3%). The 3 gwei floor exists because Sepolia's base fee is often far below 1 gwei, so without it every ordinary wallet tip would count as priority bidding. The hook fee is on top of the pool's 0.3% LP fee. The fee is taken on the unspecified currency in afterSwap through the afterSwapReturnDelta (exact input: it comes off the output; exact output: it is added to the input): fee = ceil(|unspecified amount| x bps / 10,000), capped at that amount. Fees are credited to the hook as ERC-6909 claims with poolManager.mint inside the callback; no ETH or tokens are pushed during a swap. Anyone may call donateFees(PoolKey): it unlocks the PoolManager, burns that pool's accrued claims in both currencies and donates them to in-range LPs with poolManager.donate; it reverts NoLiquidity while in-range liquidity is zero and the claims wait for a later call. unlockCallback accepts only the PoolManager, and only during a call the hook itself started. No owner, no admin. Document in NatSpec and README: tx.gasprice is chosen by the sender, so the rule only taxes public priority bidding; private bundles with a low tip plus a direct coinbase payment avoid it, and simulations with a zero base fee see the low tier. Events: FeeCharged(PoolId indexed poolId, address sender, bool highTier, uint256 gasPrice, uint256 baseFee, Currency currency, uint256 fee), FeesDonated(poolId, amount0, amount1). Views: feeBpsFor(uint256 gasPrice, uint256 baseFee) pure, accrued(poolId) for both currencies. Tests run against a real v4-core PoolManager and include a launch rehearsal: one-sided GASP liquidity below the opening price, a first buy into the ETH-less pool, then a sell. Acceptance: the tier boundary (gasprice exactly 2 x basefee, tip exactly 3 gwei, and one wei either side) using vm.fee and vm.txGasPrice; fee = formula for exact input and output in both directions; invariant: claims held per currency == sum of accrued over pools; donateFees raises in-range LPs' fees by the donated amount and reverts with no in-range liquidity. Then a small website that shows the current base fee, the 2x threshold and the 3 gwei floor, the tier a chosen gas price would pay, recent swaps from FeeCharged with high-tier ones flagged, accrued fees with a donate button, and a swap form. Swaps go through PoolSwapTest 0x9B6b46e2c869aa39918Db7f52f5557FE577B6eEe (it forwards hookData and sqrtPriceLimitX96), prices come from StateView 0xE1Dd9c3fA50EDB962E442f60DfBc432e24537E4C and quotes from V4Quoter 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 (all live on Sepolia). One page, no backend.","status":"completed","failure":null,"contractsJobId":"02a20f51-ad24-47c4-8cb9-2dc8920c4c2d","frontendJobId":"43eee710-1391-41e2-8c03-66c7c3adf7fe","createdAt":"2026-09-27T06:03:45.552Z","updatedAt":"2026-09-27T18:47:28.962Z","waitingForHosting":false}]}