Design Taskmarket Hook Integrations for Robinhood Chain

Research and design an implementation-ready framework linking Taskmarket's new lifecycle hooks on Base to verifiable work or market behavior on Robinhood Chain. The Taskmarket hook is the core requirement. Show how a custom ERC-8195 `ITMPHook` commits a scoped intent or outcome, consumes authenticated finalized remote state, and gates the appropriate Taskmarket lifecycle transition without violating callback gas or liveness constraints. A generic Robinhood Chain survey, offchain bot, evaluator-only design, bridge overview, or standalone Uniswap v4 hook is not sufficient. ## Starting sources - Taskmarket hook developer guide: https://docs.taskmarket.dev/developer/hooks - Taskmarket hook operations reference: https://docs.taskmarket.dev/reference/hooks - Builder Reserve example: https://github.com/daydreamsai/taskmarket-builder-reserve - HookR: https://hookr.fun/docs and https://hookr.fun/integrations - Long: https://app.long.xyz/ - Pons: https://docs.ponsfamily.com/, https://docs.ponsfamily.com/v2, and https://github.com/ponsdotdev/ponsfamily - Robinhood Chain and Stock Token documentation: https://docs.robinhood.com/chain/ - Uniswap v4 hooks: https://developers.uniswap.org/docs/protocols/v4/concepts/hooks The Builder Reserve repository currently requires authenticated GitHub access. Use it if accessible, but do not make private access a prerequisite. Its relevant public design premise for this task is: Taskmarket remains authoritative for its Base lifecycle and USDC settlement; remote assets and protocol state remain authoritative on Robinhood Chain; only authenticated state is transported; and slow or retryable cross-chain work occurs outside bounded Taskmarket callbacks. ## Required ecosystem research Research and model at least: 1. HookR's selectable Uniswap v4 launch blocks, custom-hook review route, manifests, runtime-hash checks, and canary approach. 2. Long.xyz's Robinhood Stock Token pairings and claimed permissionless fee-cycle surface. Explicitly document its current public source, ABI, address, and authority gaps rather than inventing implementation details. 3. Pons V1 and Pons V2 as separate generations. V1 is not a v4-hook implementation; V2 uses a shared v4 hook and retryable graduation path rather than arbitrary per-launch hooks. 4. At least one additional fully source-verifiable Robinhood Chain implementation, preferably Hood Market or another entry backed by verified contracts and deployment evidence. 5. Relevant native primitives: canonical Stock Token identity, feeds and multiplier handling; Uniswap v4 hook permission flags; cross-chain transport and finality; and contract runtime/proxy verification. Treat "popular" as a claim requiring time-stamped, reproducible evidence. App visibility or marketing copy alone is not a usage ranking. ## Design target Design a reusable, versioned adapter boundary rather than one protocol-specific bot. Explore both directions: - a Taskmarket outcome authorizes or changes one narrowly scoped Robinhood market-hook behavior; and - Robinhood market-hook fees or state fund, verify, or reward Taskmarket work. The reference receipt-first flow is: 1. A Base Taskmarket task commits a bounded Robinhood intent. 2. A selected worker executes an allowlisted action through a Robinhood-side adapter. 3. The executor emits a canonical, idempotent receipt. 4. An authenticated relay/inbox finalizes the receipt on Base after the required finality. 5. `checkSubmit` and/or `checkComplete` validates compact finalized state. 6. Taskmarket pays only after the promised evidence is accepted. Also compare a non-blocking sidecar policy where Taskmarket USDC can settle independently and the Robinhood effect completes later. State clearly which policy fits each proposed use case. Cross-chain calls, DEX execution, live HTTP/RPC requests, dynamic oracle reads, and unbounded proof parsing must not occur inside a Taskmarket callback. ## Required deliverables 1. **Research matrix:** Cover HookR, Long, Pons V1, Pons V2, and at least one additional implementation. Include verified contracts and source links where discoverable, v4-hook status, factory/router or pool relationships, admin/upgrade roles, evidence events, popularity evidence, and a `verified`, `inferred`, or `unknown` label for every material claim. 2. **At least three concrete concepts centered on Taskmarket hooks:** Include at least one Taskmarket-outcome-to-market concept and one market-fees/state-to-Taskmarket concept. Rank them by impact, feasibility, integration dependency, and risk, and recommend one first experiment. 3. **Implementation-ready architecture:** Provide component and sequence diagrams; Base and Robinhood authority boundaries; a callback-by-callback `ITMPHook` mapping; versioned `hookData`, intent, and receipt fields; adapter interfaces; transport/finality assumptions; and reconciliation and emergency paths. Solidity interfaces or pseudocode are encouraged, but production code is not required at this reward. 4. **Threat model and test plan:** Cover replay, duplicates, reordering, reorgs, forged sources, arbitrary calldata, upgrade/codehash drift, oracle/multiplier mistakes, slippage, callback denial of service, key/approval scope, lifecycle bypasses, economic manipulation, and restricted-asset exposure. 5. **Follow-on prototype plan:** Define a testnet/local first adapter, exact scope, dependencies, effort estimate, unknowns, acceptance tests, deployment evidence, and a path to a no- or low-value canary. Do not perform mainnet writes or real-value trading for this task. ## Hard acceptance criteria A submission is eligible only if all of the following are true: - It specifies an actual custom Taskmarket `ITMPHook` design and makes that design central. - It correctly handles `checkFund`, relevant claim/select/submit/evaluate/complete gates, best-effort `on*` behavior, cancellation, expiry, nonterminal forfeit-and-reopen, and the selected-auction expiry path that may bypass `checkComplete`. - It accounts for `BaseTMPHook`, immutable Diamond and `onlyDiamond` protection, ERC-165, shared V1 `hookData`, the maximum hook count, the 1,000,000-gas callback limit, and 32-byte return-data cap. - It draws an asynchronous authority boundary between Base and Robinhood Chain. It does not propose a synchronous cross-chain contract call. - Intent and receipt commitments bind at least the task ID, requester, source and execution chain IDs, adapter ID/version, target/runtime identity, action or outcome parameters, nonce, deadline, and evidence/finality policy. - Critical success is checked before payout or explicitly declared a non-blocking sidecar. No essential action relies only on a swallowed `on*` callback. - Its threat model and tests include replay, duplicate, conflict, reorder, delay, reorg, cancellation/expiry, forfeit/reopen, auction bypass, and codehash/upgrade cases. - Robinhood Stock Token identity comes from canonical addresses or registries and correctly handles feed/multiplier semantics. Symbols and HTTP APIs are not value-bearing authority. - Pons V1 and V2 are not conflated; Hook and HookR are not conflated; and Long's unverified implementation details are not stated as fact. - It does not reward self-trading, wash volume, or a spoofable website/API counter. - It requires no mainnet write, token launch, liquidity deposit, or real-value trade and makes no unsupported audit or production-readiness claim. - The submission is a clear Markdown, PDF, or public repository artifact with primary-source citations and enough interface/schema detail for a follow-on implementer. ## Scoring rubric | Area | Points | |---|---:| | Taskmarket lifecycle correctness and meaningful `ITMPHook` use | 30 | | Concrete, original hook-to-hook implementation concepts | 20 | | Async receipt and reusable adapter architecture | 20 | | Security, liveness, recovery, and test-plan quality | 20 | | Robinhood ecosystem research and source verification | 10 | Missing the Taskmarket hook design, collapsing Base and Robinhood into a synchronous call, placing an essential action only in `onComplete`, or rewarding unverifiable trading volume makes a submission ineligible regardless of score. ## Requester review procedure 1. Apply the hard gates first: an actual `ITMPHook` lifecycle mapping and asynchronous Base-to-Robinhood boundary. 2. Verify ecosystem claims against first-party sources and onchain evidence. 3. Walk the recommended concept through normal completion, cancellation, expiry, forfeit/reopen, delayed delivery, and selected-auction expiry. 4. Walk its receipt state machine through wrong source/chain/task, replay, reorder, conflict, reorg, and runtime-code drift. 5. Score whether a follow-on implementer could build the interfaces and tests without guessing material security decisions.