Build and independently review Tip Jar: token Tip Jar (TIPJ) and contract TipJar, where anyone tips any address an amount of TIPJ with an optional bytes32 note; tips are transferred straight through with transferFrom, and the contract keeps per-recipient and per-tipper running totals readable on chain. Follow the evm-project-launch guidance for a Sepolia project launch: a fixed-supply ERC-20 with 18 decimals, a zero-argument constructor minting the whole supply to its deployer and no mint backdoor, plus one application contract whose only constructor argument is the token address passed as $token. No owner, no admin, no upgradeability, no fee; checks-effects-interactions; events for every state change; thorough Foundry tests including a malicious reentrant token and token permission failures. The manifest names the token and the contract with the $token argument. Independent review before deployment. Contributors never broadcast; the admitted release goes through the deployer.

WORKFLOW CONTRACT STAGE CONTEXT: the stage produces implemented and tested contracts, ABI documentation and an independently reviewed launch.json. Each assignment contributes only within its own role and write scope. Source-producing assignments own implementation, tests and ABI exports at docs/abi/<Contract>.json where their scope permits. The generated manifest assignment writes only launch.json. Review assignments inspect accepted source and manifest and return findings without editing files; they do not implement contracts or generate ABI files. Use the supplied canonical manifest guidance: policy and signed artifact linkage belong to services, while concrete source, constructor, policy or authorization conflicts remain review findings. Services publish source, attest, admit and deploy after this stage, then start the frontend. Read .imd/reads/workflow.md for the complete approved requirements and apply them to your assigned contribution; later service outcomes are not prerequisites of this assignment.

Build and independently review Odds and Evens, a simple two-player game played for a fixed-supply launch token, for a Sepolia project launch. Follow the evm-project-launch guidance exactly: a fixed-supply ERC-20 named Odds and Evens with symbol ODDS, 18 decimals, zero-argument constructor minting the whole supply to its deployer, no mint backdoor; and one game contract, OddsAndEvens, whose only constructor argument is the token address passed as $token. Game: a player opens a game by staking an amount of ODDS (transferFrom, so the player must approve first) and committing keccak256(number, salt) where number is 1 to 10, choosing odds or evens; a second player joins by staking the same amount and committing their own number; both reveal within a fixed 24-hour reveal window; the sum of the two numbers is even or odd and the player who chose that parity wins the whole pot; if only one player reveals before the deadline the revealer wins by forfeit; if nobody reveals, either player can cancel and both stakes are refunded. No house fee, no owner, no admin, no upgradeability, no external calls other than the token, pull-based or direct token payouts with checks-effects-interactions, and events for opened, joined, revealed, settled and cancelled games. Thorough Foundry tests for every outcome, forfeit, refund, invalid commits, wrong stakes, reentrancy through a malicious token, and token permissions. The manifest names the token and the game contract with the $token argument. Contributors must not broadcast; the admitted release goes through the deployer.

Build and launch VolatilityGuard Lab as one standalone contract job on Sepolia: implement VolatilityGuardHook and VolatilityGuardToken, meaningful tests, independent adversarial review of source and launch manifest, GitHub source publication, verified factory deployment with a seeded Uniswap v4 pool. No website or IPFS deliverable. Hook: per-PoolId isolation; bounded observation ring/TWAP and EWMA volatility; adaptive price-deviation limits; rolling volume budget resistant to split swaps; NORMAL/WARMUP/GUARDED/RECOVERY states, stale/low-liquidity handling and deterministic recovery. Authenticate canonical PoolManager callbacks/accounting, never trust sender/hookData identity. Specify both swap directions and exact-input/output, units/rounding, bounded execution and caps. Keep LP exits possible and initialization/warmup non-bricking. Reverts cannot persist breaker transitions. No discretionary admin powers or claim of total MEV protection. Support arbitrary currencies. VGL: name Volatility Guard Lab, symbol VGL, 18 decimals, no constructor args, fixed 10^27 units minted to deployer, no mint backdoor. Native ETH pair (zero address), static fee 3000, tickSpacing 60; initial sqrtPriceX96 792281625142643375935439503360000 (0.00000001 ETH/VGL). Verify Sepolia PoolManager 0xe03a1074c86cfedd5c142c4f04f1a1536e203543. Use existing verified periphery, no new deployed helper. Workers never receive deployment keys or broadcast. Deliver a pinned/vendored Foundry project with bytecode_hash=none, offline build/test/fmt checks, fuzz/invariant/stress tests for accounting, isolation, manipulation/split volume, unauthorized callbacks, reentrancy, stale history, edge values, recovery and LP exits. Report actual counts, gas, failures and limitations. Preserve pinned dependency contents; verify any vendor digest inventory after final formatting rather than claiming a stale check passed. Export implementation-derived ABI JSON under artifacts/abis/ and architecture/threat-model/integration documentation with exact pool-key derivation, existing quote/swap/liquidity recipes and decoded errors. Document token-sided bootstrap: buy with ETH first; reverse swaps need accrued ETH liquidity. Resolved operator policy: Sepolia univ4_hook policy v2, never mainnet. Token/hookAdmin/treasury/LP policy owners are 0x09ec38170e94532eddb57c69dfc4f1fdcd0d4a60 without extra contract admin behavior. Supply: 80% liquidity, 10% treasury, 10% contributors; 1h contributor lock and 30% per-wallet cap. Factory seeds up to 8e26 VGL units and ZERO ETH. Deployer derives the widest aligned token-only range and affordable liquidity from the opening price using exact integer Uniswap tick math. Configured deployer gas is capped by the existing 0.3 Sepolia ETH policy; no extra funding or spending authority. Execution boundaries: builder implements source/tests/docs/ABIs; the control plane adds a separate launch.json assignment; an independent reviewer reviews source AND canonical manifest and returns findings without changing files. Repair concrete blocking findings while preserving required behavior. Review follows supplied canonical manifest/service guidance: policy, signed artifact linkage and post-review publication/attestation are service responsibilities, not invented manifest fields. Workers submit their completed predeployment assignment without waiting for future deployment receipts or GitHub URLs. After accepted review the existing publisher creates the automatic launch repository in its configured GitHub org; verifier and deployer handle attestation, admission and deployment. The operator verifies published source and deployed contracts to assess the overall launch. DeFi references support implementation, not a separate commissioned research report.

WORKFLOW CONTRACT STAGE CONTEXT: the stage produces implemented and tested contracts, ABI documentation and an independently reviewed launch.json. Each assignment contributes only within its own role and write scope. Source-producing assignments own implementation, tests and ABI exports at docs/abi/<Contract>.json where their scope permits. The generated manifest assignment writes only launch.json. Review assignments inspect accepted source and manifest and return findings without editing files; they do not implement contracts or generate ABI files. Services publish source, attest, admit and deploy after this stage, then start the frontend. Read .imd/reads/workflow.md for the complete approved requirements and apply them to your assigned contribution; later service outcomes are not prerequisites of this assignment.

Build and independently review a fully on-chain marketplace for any ERC-721 asset, delivered as a Sepolia evm_project launch. Follow evm-project-launch guidance exactly: the launch deploys a fixed-supply token with a zero-argument constructor that mints the whole supply to its deployer (name it for the marketplace; FWA is an existing external token and its buy-and-burn is out of scope), plus the application contracts below in deployment order, with static constructor arguments only and references limited to $token, $owner and $contract:EarlierName. Contributors must not broadcast; the admitted release goes through the deployer. Requirements: - Use Solady for gas efficiency. Vendor the Solady sources you use into the repository as plain files (no git submodules, no remote dependencies, no forge install at build time): the verifier builds offline. - Actions: list (the marketplace takes custody of the NFT), buy, global offer (an ETH offer for any token of a given ERC-721 contract), accept offer, and cancel for both listings and offers. Push ETH and NFTs on settlement; no pull architecture. Every listing and every offer must mature for one block before it can be filled. - A 0.5% protocol fee on every trade, paid to the payout wallet $owner. Any ERC-721 may be malicious: reentrancy, reverting or lying transfer hooks, or a contract that reports false ownership must never endanger assets custodied for other listings. Use checks-effects-interactions, reentrancy guards, and settle each trade so a failure only affects that trade. - A Royalties contract, deployed as its own application contract and passed to the marketplace as $contract:Royalties, that delegates royalty logic to a swappable implementation address settable by $owner, but hardcodes that the fee is between 0 and 5% inclusive and defaults to 0 with no recipient until set; anything outside that range must revert. - On-chain price oracle state per ERC-721 collection: a rolling average sale price over 1 hour, 1 day and 1 week, and the current floor listing price, all readable by view functions and updated on every sale, listing and cancellation. - Events for every action (list, cancel listing, buy, offer, cancel offer, accept offer, fee and royalty payments, oracle updates, royalty implementation changes) with enough indexed fields for an off-chain indexer. - Foundry tests covering every action, the one-block maturity rule, fee and royalty math including the 0-5% bounds, oracle averages and floor tracking, and a malicious ERC-721 that reenters and one that reverts on transfer, proving other custodied assets are unaffected. - A README describing the architecture, the fee flow, the oracle windows, the events, and how to swap the royalty implementation.

Build and independently review a fixed-supply launch token and a simple record registry with an explicit owner constructor argument. Follow evm-project-launch guidance, use $token and $owner references, and test registry permissions and state changes. Contributors must not broadcast; the admitted release goes through the deployer.

Build and independently review Duel Arena, a playable non-hook rock-paper-scissors escrow game, for automatic Sepolia deployment through the evm_project launch pipeline. Deliver a complete standalone Foundry project with source, meaningful tests, README, and artifacts/report.md. This job requests GitHub publication, an admitted on-chain deployment, and named registry artifacts. Contributors must never read wallet keys or broadcast transactions; the configured deployer handles the accepted release. Deploy exactly two authored contracts: DuelToken and DuelArena. Follow the pinned evm-project-launch reference and Sepolia policy v3. DuelToken is a conventional fixed-supply ERC-20 named "Duel Arena", symbol "DUEL", 18 decimals, with NO constructor arguments and exactly 1,000,000,000 tokens (10^27 base units) minted to msg.sender in its constructor. No mint, tax, pause, blacklist, upgrade, or admin functions. DuelArena is non-upgradeable, uses only this token, has no administrator, platform fees, oracle, randomness service, or privileged withdrawal. Constructor parameters are (address token_, uint64 joinWindow_, uint64 revealWindow_); launch arguments must be ["$token","3600","3600"]. Validate the constructor inputs and complete all setup there. Use Solidity 0.8.26, bytecode_hash = "none", offline-buildable dependencies, and no ffi or filesystem permissions. No frontend, badges, NFT collection, or additional game modes in this iteration. Game: - A creator chooses a positive token stake and either a specific different opponent or address(0) for an open duel. Creator escrows one stake and submits a nonzero commitment when creating. Reject zero stakes, self-opponents, and amounts that could overflow pot accounting. - Use bytes32 duelId = keccak256(abi.encode(creator, nonce)). Creation supplies the expected per-creator nonce, checks it, then consumes it atomically. Provide getters/helpers so clients can derive the ID and commitment without a separate reservation transaction. IDs cannot be reused after terminal states. - Commitment must be keccak256(abi.encode(block.chainid, address(this), duelId, player, uint8(move), bytes32(salt))), with move 0=rock, 1=paper, 2=scissors. Domain-bind every component and document a fresh unpredictable 32-byte salt per move. Show how to compute commitments locally without publishing a move or salt before reveal. - Join deadline is creation timestamp + joinWindow. A permitted opponent other than creator joins before that deadline, commits their move, and escrows exactly the same stake. No third player, second join, commitment replacement, or stake edits. Reveal deadline is successful join timestamp + revealWindow. Both commitments exist before any reveal is accepted. - Joining and revealing require timestamp < the applicable deadline; expiry/timeout finalization requires timestamp >= deadline. Reject invalid moves, wrong salts/player/domain/duel, repeat reveals, early reveals, and late reveals without consuming a valid future action. - Settle as soon as the second valid reveal arrives: winner receives a withdrawal credit of the entire pot; equal moves give each player their original stake as credit. - After the reveal deadline, anyone may finalize. Exactly one valid reveal awards the whole pot to that revealer; no reveals returns each original stake. After an unmatched duel's join deadline, anyone may expire it and credit the creator's stake. There is no cancellation function. All terminal transitions happen exactly once. - Use pull withdrawals with clear events and checks-effects-interactions/reentrancy protection. A failed transfer must preserve the user's credit, and reentry must not enable duplicate claims. Track total liability (active escrow + withdrawal credits): settlement preserves it, withdrawals reduce it, and token balance always covers it. Unexpected direct token transfers are surplus with no privileged recovery. Do not advertise arbitrary rebasing/fee-token compatibility. - Persist readable duel state, deadlines, revealed moves only after valid reveal, outcome, credits, and per-player wins/losses/draws/forfeits. Ordinary winner/loser receive W/L; equal moves give each a draw; sole revealer receives W and opponent L plus a forfeit; neither reveals gives each a forfeit but no W/L/draw; unmatched expiry changes no competitive stats. State explicitly that this is an address-based record, not Sybil-resistant reputation. Validation: Meaningful Foundry tests must cover all nine move pairs; open and designated opponents; creator nonce races/reuse and multiple concurrent duels; domain/replay separation by chain, arena, duel and player; all deadline boundaries including exact equality; invalid/duplicate/out-of-order actions; both timeout outcomes and unmatched expiry; double settlement/withdrawal; isolated escrow between games; failed withdrawals and attempted reentrancy; conservation of token balances and liabilities. Include bounded fuzz/property coverage of accounting and state transitions. Verify the token's exact supply and lack of privileged minting. Run forge build, forge test and forge fmt --check offline. Document actual checks and remaining limitations in artifacts/report.md. README must explain the architecture, state/outcome table, timeout lock-up tradeoff, token acquisition through contributor claims or an existing holder/pool (no faucet mint backdoor), approvals, and ready-to-use cast examples for two wallets to create, join, reveal, inspect, finalize and withdraw. Use placeholders for deployed addresses and wallet credentials; never embed real secrets. Do not execute the examples against a public chain. Document the arena/token constructor and commitment ABI exactly. The separate manifest assignment writes launch.json using kind evm_project, DuelToken, and DuelArena with the arguments above; use the reference's hookless native-ETH Sepolia pool parameters. The final independent reviewer must inspect accepted source, tests and manifest together, reproduce concrete escrow/commitment/deadline/permission failures, and raise blocking findings for real defects before release. Passing the protected deployment floor alone does not establish game correctness.

Build and launch TickOracleHook, a Uniswap v4 hook that keeps an on-chain time-weighted tick oracle for every pool it is installed on, together with the ERC-20 the launch mints, from an empty repository through to a Sepolia deployment. What the hook does. Per pool it keeps a ring buffer of observations modelled on Uniswap v3's Oracle library: each observation is a uint32 block timestamp (wrapping) and an int56 tick cumulative, and the buffer has an index, a cardinality, and a cardinalityNext. The first observation is written in afterInitialize. After that the hook tracks the latest post-swap tick per pool on every afterSwap, and writes a new observation only when the block timestamp has advanced past the last one, accumulating the previously recorded tick over the elapsed seconds — so at most one observation is written per pool per block and the tick applied to an interval is the one that stood at the end of the previous block, exactly as v3 does. Anyone may call increaseObservationCardinalityNext(PoolKey, uint16) to grow a pool's buffer; the initial cardinality is 1 and the hard cap is 1024. observe(PoolKey, uint32[] secondsAgos) returns int56[] tick cumulatives, interpolating between the two surrounding observations found by binary search and extrapolating from the latest when secondsAgo is 0, and reverts with a named error when a requested time precedes the oldest observation. consult(PoolKey, uint32 window) returns the arithmetic-mean tick over the window as int24 and reverts on a zero window. Timestamp comparisons must be correct across uint32 wraparound, as v3's Oracle.lte is. Permissions: afterInitialize and afterSwap, and only those two. getHookPermissions returns exactly those fields true and the other twelve false; both swap returnDelta flags are off, and every liquidity and donate flag is off. Callbacks return their selector and, for afterSwap, an int128 delta of zero on every path, so a swap settles exactly as it would with no hook attached. The hook must extend a BaseHook whose external callbacks refuse any caller other than the PoolManager. What the hook deliberately does not have: no owner, admin, role or privileged address; no currency handling of any kind — it never takes, settles, mints or holds a token or ETH and has no receive or fallback; no fee; no pause, proxy, delegatecall, selfdestruct, or setter beyond cardinality growth. Its constructor takes exactly one argument, the IPoolManager. Token: TickOracleToken, name "Tick Oracle Signal", symbol "TOS", 18 decimals — a plain OpenZeppelin ERC20 whose entire fixed supply is minted once, in the constructor, to msg.sender, with no mint or burn entry point afterwards, no owner, and no functions beyond the standard. Tests must place the hook's code at an address carrying exactly its flags, drive real swaps through a live PoolManager across at least two pools and several blocks of warped time, and assert observe and consult against values computed independently in the test: the interpolation, the same-block-no-second-write rule, cardinality growth and the wrap of the ring index, the uint32 wraparound comparison, and every revert path. Facts the launch policy fixes, which nothing in the repository may contradict: - total supply 1000000000000000000000000000 (1e27, which is 1,000,000,000 tokens at 18 decimals) - paired currency 0x1c7d4b196cb0c7b01d743fbc6116a902379c7238 (USDC on Sepolia) - fee tier 3000, whose canonical tick spacing is 60 - initial price 79228162514264337593543950336 (sqrtPriceX96 for 1:1) - the Uniswap v4 PoolManager on Sepolia is 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543

Build and launch SwapCounterHook, a Uniswap v4 hook that counts swaps per pool, together with the ERC-20 the launch mints, from an empty repository through to a Sepolia deployment. Facts the launch policy fixes, which nothing in the repository may contradict: - total supply 1000000000000000000000000000 (1e27, which is 1,000,000,000 tokens at 18 decimals) - paired currency 0x1c7d4b196cb0c7b01d743fbc6116a902379c7238 (USDC on Sepolia) - fee tier 10000, whose canonical tick spacing is 200 - initial price 79228162514264337593543950336 (sqrtPriceX96 for 1:1) - the Uniswap v4 PoolManager on Sepolia is 0xE03A1074c86CFeDd5C142C4F04F1a1536e203543

Build and launch SwapCounterHook, a Uniswap v4 hook that counts swaps per pool, from an empty repository through to a Sepolia deployment.

Implement SwapCounterHook: the smallest useful Uniswap v4 hook. It counts swaps. Behaviour, in full: - one hook permission, afterSwap, and nothing else. Not beforeSwap, not any returnDelta flag - a public mapping from PoolId to uint256, incremented by one in afterSwap - a public view returning the count for a given PoolId - afterSwap returns (IHooks.afterSwap.selector, 0). It never modifies a delta Deliberately absent, and it must stay that way: - NO owner, admin, or privileged address of any kind - NO funds. It never takes, settles, mints or holds a currency - NO withdrawal, no fees, no constructor arguments beyond the pool manager - NO upgradeability and no way to change its behaviour after deployment This exists to exercise the launch path end to end, so its value is in being impossible to get wrong rather than in what it does. A hook that holds nothing and grants nobody authority has no question to answer about who may withdraw or what happens under CREATE2 — which is the class of problem that blocked the previous attempt. Keep it that way: if a requirement seems to call for an owner or a balance, it is not this contract. The launch manifest this job produces must declare: - "kind": "univ4_hook" as its first field - the hook contract SwapCounterHook, with permissions: afterSwap, and no others - paired currency 0x1c7d4b196cb0c7b01d743fbc6116a902379c7238 (USDC on Sepolia) - fee tier 10000 Both are on the launch policy's allowlist; anything else is refused at admission.

A marketing website for a fictional plumbing company.

A marketing website for a fictional plumbing company.

Make the hook count swaps. Enable the beforeSwap callback, keep a per-pool counter keyed by pool id, increment it once per swap in either direction, and expose it through a public view function. Change nothing else: take no fee, return zero deltas, and leave liquidity, donations and the zero-liquidity case behaving exactly as they do with the empty hook. Keep it small — this is one counter and one getter.

Make the hook count swaps. Enable the beforeSwap callback, keep a per-pool counter keyed by pool id, increment it once per swap in either direction, and expose it through a public view function. Change nothing else: take no fee, return zero deltas, and leave liquidity, donations and the zero-liquidity case behaving exactly as they do with the empty hook. Keep it small — this is one counter and one getter.

Make the hook count swaps. Enable the beforeSwap callback, keep a per-pool counter keyed by pool id, increment it once per swap in either direction, and expose it through a public view function. Change nothing else: take no fee, return zero deltas, and leave liquidity, donations and the zero-liquidity case behaving exactly as they do with the empty hook. Keep it small — this is one counter and one getter.

launch-20

launch-18

launch-19