# HoodPools — feasibility and implementation brief

Research checked 8 September 2026. Working name: HoodPools. Proposed ticker: HOODP. Name, ticker and domain availability have not been cleared. This is an engineering feasibility review, not a deployed protocol or contract audit.

## Verdict

The liquidity-and-rewards model is technically feasible on Robinhood Chain. An exact launch using the requested venue and a universal 3% tax is not verified. The reachable primary sources are for **degen.zone**; **degenland.zone** could not be reached, and their relationship has not been established. All degen.zone findings below are conditional on that being the intended venue.

Robinhood’s current documentation describes a live, permissionless EVM chain, mainnet chain ID **4663**, testnet **46630**, and ETH gas. This is newer than historical articles describing a testnet-only network. Its stock integration guide explicitly supports standard AMM pools. [Chain overview](https://docs.robinhood.com/chain/) · [Network configuration](https://docs.robinhood.com/chain/connecting/) · [Stock integrations](https://docs.robinhood.com/chain/building-with-stock-tokens/)

This establishes documented capabilities, not an end-to-end verification of the proposed launch, deployed launchpad bytecode, liquidity access or profitability.

## What Shroom actually publishes

Shroom describes pairing SHROOM with stocks and other tokens, earning fees on routed swaps, and reinvesting fees into liquidity. Its future plan includes using excess fees to buy and burn SHROOM. Its periodic MU holder distributions are described separately as distributed by Pons, subject to Pons requirements. It does not describe the exact holder/staker fee split proposed for HoodPools. Its TVL is explicitly labeled as held by a team wallet. [Shroom](https://www.shroomnetwork.com/)

I inspected that page’s public HTML and serialized dashboard payload. On this research date, **all 48 `ownedPools` entries were labeled `dexVersion: "V4"`**. Example: USDG / SHROOM, pool ID `0x1fb7fc8f1c926dd3a491601a624ab35ab7110c0e42b0484d07f224d6f7eef284`. That is a 32-byte pool identifier, not an ERC-20 address.

This is first-party website data, not independent onchain verification. Repeated pairs have distinct pool IDs; the page does not establish the exact fee tiers, hooks, tick spacing, price ranges, creation transactions, LP ownership restrictions or keeper code. Its headline and table fee totals also differ, with the headline noting inclusion of closed positions. Do not derive guaranteed APRs or exact fee rates from those ratios.

## The proposed fee model

The user's intended economic allocation is **2 percentage points of eligible trade volume for liquidity and 1 percentage point for the team**. That means a two-thirds / one-third split of received creator fees, not 2% and 1% of the fee itself.

Degen.zone documents creator fee tiers from 0.50% through 3.00%, in 0.25-point steps. A 3.00% creator setting adds 0.30% platform and 0.05% referral charges, making the trader-facing fee **3.35%**, excluding gas and price impact. [Fee schedule](https://degen.zone/docs/fees)

For $10,000 of eligible notional, the documented schedule gives $300 to the creator rail, $30 to the platform and $5 to referrals. HoodPools would split the $300 into $200 of liquidity budget and $100 for the team. This is a notional illustration; fees may arrive in different currencies and quantities.

A strict 3.00% total with exactly 2.00% liquidity and 1.00% team leaves no room for the platform charge. It would need a different/custom venue arrangement, subsidy, or revised allocations. The documented fee tiers also do not offer a 2.65% creator setting to make 3.00% total.

## Graduation matters

Degen.zone's default V3 graduation changes the revenue model: a 0.30% pool fee is split 65% creator / 35% platform, equating to about **0.195% of total trading volume** for the creator when its locked position supplies the relevant liquidity.

Its opt-in V4 hook preserves the creator-selected swap fee after graduation. Election occurs while the bonding curve is filling, before completion. The documentation describes creator fees accruing separately per pool currency, with creator-wallet claims. The launchpad's locked V4 position has no ordinary LP fee, and external frontends may not support that venue. Consequently, this launch pool is a funding source; it cannot be assumed to earn the ordinary LP revenue modeled for secondary stock pools. [Graduation](https://degen.zone/docs/graduation)

Automated fee claim discovery and unsigned transactions are documented, but creator authorization, smart-account compatibility and the specific hook generation still need contract-level validation. A generic keeper cannot be assumed to have permission to claim on a creator's behalf. [Fee-claim API](https://degen.zone/docs/api/fees)

## Launchpad availability is unresolved

The documentation conflicts internally. Its status page says Robinhood launches are testnet-only and no mainnet launchpad is deployed; other sections describe live EVM fee rails, mainnet chain IDs and mainnet activity. The status page itself also contains mainnet exceptions to its broad statement. Treat this as **unverified availability**, not proof that a mainnet launch either works or is impossible. [Status and availability](https://degen.zone/docs/status)

Resolve this using the actual launch form’s selected chain, verified factory/graduator/hook addresses, deployed bytecode, ABI, a known successful mainnet launch and a complete fee-claim transaction trace. No token has been launched during this task.

## A pool hook is not a universal token tax

A fee attached to the canonical launch pool only affects swaps using that pool. HOODP / NVDA, HOODP / USDG, peer-to-peer transfers and other pools do not automatically inherit it. Once cheaper routes exist, trading may migrate away from the fee-generating launch pool. The liquidity funding model must account for that erosion.

Adding a fee inside every ERC-20 transfer is a different design and can break standard integrations; Uniswap V3 specifically documents fee-on-transfer tokens as unsupported by its routers. [Uniswap token integration issues](https://developers.uniswap.org/docs/protocols/v3/concepts/unsupported-tokens)

Proposed approach: keep HOODP a standard ERC-20, distinguish the launch creator-fee venue from ordinary fee-earning secondary LPs, and measure how much volume remains on the funding venue. If the 3% must apply to every trade, a custom architecture and integration analysis are required. Charging that fee on each leg of NVDA → HOODP → AAPL also makes routing expensive. Do not promise both universal high tax collection and frictionless stock routing.

## Proposed system architecture

This is an engineering proposal, not Shroom's verified implementation.

1. **Launch and collection adapter.** Launch the standard ERC-20, select the documented creator fee and, if supported, elect V4 before graduation. Establish who is allowed to claim and where fees are paid. Use a multisig-controlled adapter only if the launchpad accepts contract creators or safely supports that routing; otherwise use a constrained, reviewed operational claim process. Support multiple incoming fee currencies.
2. **Fee splitter.** Record each received currency, send one-third to the team treasury and retain two-thirds for liquidity. Split before converting so currency accounting is explicit. Define deterministic rounding and dust policy. Do not mix launch proceeds, LP principal and distributable fees.
3. **Liquidity treasury and manager.** Accumulate enough capital for a useful position. Select allowlisted stock/stablecoin tokens, acquire both assets and create or add to a compatible pool. A $200 liquidity budget does not create $200 of each asset: it funds the combined position. Equal-value provisioning is only one simplified full-range illustration; concentrated ranges can require asymmetric quantities. Obtain HOODP from purchases or an explicitly disclosed allocation; an immutable fixed supply cannot be silently minted for every new pool.
4. **Position vault.** Hold LP positions under documented multisig/governance controls. For a standard V4 integration, identify currencies, fee, tick spacing and hook; initialize at a validated price and add liquidity through the correct manager. Verify all deployment addresses for this chain rather than assuming cross-chain sameness. Preserve the ability to collect fees and, if the strategy needs it, rebalance ranges. A permanently locked launch position is separate from protocol-controlled secondary positions. [Uniswap deployment guidance](https://developers.uniswap.org/docs/protocols/v4/deployments)
5. **Harvest and accounting.** A keeper collects actual earned fees, records amounts at collection, deducts explicitly defined execution costs and optionally converts them to one payout asset such as USDG. Rebalancing proceeds and withdrawn liquidity are not trading income. Concentrated positions need monitoring because out-of-range liquidity does not earn active swap fees.
6. **Reward splitter.** Split distributable LP fees between the holder distributor and staking vault. No split has been chosen by the user; the website’s 50/50 starting value is only an interactive example. Do not promise APR, fixed payouts or perpetual growth.
7. **Holder distributor.** Index balances at defined epochs and publish reproducible allocation data. A Merkle claim contract avoids looping over all holders onchain. Specify exclusions for LP custody, the staking vault, treasury and burn addresses, minimum eligibility and anti-snapshot-gaming rules. Snapshot construction remains a trust surface unless the process is independently reproducible and challenged.
8. **Staking vault.** Track principal independently from earned rewards with accumulated reward-per-staked-token accounting. Credit only funded rewards; define zero-stake handling, claim frequency, withdrawal rules, rounding and emergency behavior. Decide whether stakers also receive holder rewards, and prevent accidental duplicate eligibility from custody accounting.
9. **Indexer and application.** Publish real pool IDs, token addresses, position ownership, collected/unclaimed fees, accounting definitions, treasury allocations, reward epochs and transaction links. Handle reorgs and distinguish historical realized prices from current mark-to-market values.

## Stock token specifics

Robinhood Stock Tokens are tokenised debt securities issued by Robinhood Assets (Jersey) Limited, offering economic exposure rather than legal ownership of the underlying company’s shares. Retail builders acquire existing tokens through secondary venues; primary mint/burn access is restricted to authorized participants.

They expose standard ERC-20 operations and a corporate-action multiplier. Robinhood says raw balances are not rebased, while its Chainlink token prices already incorporate the multiplier. Avoid applying it twice in valuations. Verify exact token addresses and oracle settings, and account for closed-market price dislocations and thin liquidity. [Stock Tokens](https://docs.robinhood.com/chain/stock-tokens/) · [Integration guide](https://docs.robinhood.com/chain/building-with-stock-tokens/)

The issuer documents restrictions involving US persons and other jurisdictions. Token distribution, stock-token access, staking and revenue sharing need review for the intended audience and operating entity; a permissionless chain does not remove those restrictions. This review does not determine legal eligibility.

## Economic and technical proof before launch

Fees are gross revenue, not profit. Inventory losses, arbitrage against stale prices, gas, conversion costs and concentration risk can exceed them. Paying all net fees as rewards reduces reinvestment compared with Shroom's compounding model. More pools fragment capital; start with a small set supported by observable demand.

Validate the whole path on a fork/test deployment: launch → trade → graduation → collect every fee currency → 2:1 split → acquire both pool assets → mint position → independent stock swap → harvest → fund holder/staker claims → withdraw stake. Test rounding, zero deposits, depleted reward balances, failed swaps, stale oracles, sequencer outages, reentrancy, account authorization and competing cheap routes. Then review deployed contracts and governance controls before committing real liquidity.

## Website delivered

The website is a responsive concept with a sortable six-pool example portfolio, a proposed fee diagram, holder/staker tabs, a reward-split explorer and launch-readiness sources. Portfolio totals are synthetic and internally consistent: $240,000 example TVL, $328,000 daily volume and $984 gross fees at a uniform illustrative 0.30% fee. None are live protocol results.

No wallet integration, token, pool, reward vault, financial transaction or claim has been deployed or executed. The product can be connected to verified contracts once the above design choices and dependencies are resolved.


## Expanded dapp: direct community liquidity

The second website iteration adds a dashboard, six pool detail pages, personal positions, staking, rewards and a 12-article documentation library at /docs. Deposits, withdrawals, LP claims, staking, unstaking and holder/staker claims operate only on a clearly labeled, browser-local example account.

Community positions must be economically distinct from protocol-owned liquidity. Fees attributable to a user's position go to that user; only the protocol-owned share may fund protocol holder/staker rewards. For example, $100 in pool fees with an 80% protocol / 20% community active-liquidity split gives $20 to community LPs and $80 to the protocol. A hypothetical 50/50 distribution of that protocol portion funds $40 of holder rewards and $40 of staking rewards, before considering costs.

The live community-position architecture is still undecided: either user-owned positions through a verified manager, or user-owned shares in a separately accounted vault. Direct deposits must not be represented as team-owned capital. Fee settlement when changing a live position must follow the specific manager's semantics and avoid duplicate accounting. The demo preserves principal and fees as separate balances for clarity.

The demo uses fixed prices, equivalent full-range positions, manually simulated fee epochs, zero operating costs and a 50/50 protocol allocation. Wallet-only HOODP is eligible for example holder rewards; staked and LP-custodied HOODP is excluded. These are teaching assumptions, not final policy or production concentrated-liquidity math. All live contract dependencies described above remain unresolved.