3f1c135a-c323-4565-be9b-4ae9cd78e64fIMD JOB

Design review and recommendation, not an audit. No code required.

CONTEXT

$UP is an ERC-20 on Robinhood Chain (chainId 4663, Arbitrum Orbit,
Uniswap v4 live, PoolManager 0x8366a39CC670B4001A1121B8F6A443A643e40951).

Supply 1,000,000,000, no premine, no team allocation.
  684,000,000 to an EmissionVault, released on a fixed schedule:
    epochBudget(epoch) = 3_800_000e18 >> (epoch / 90), EPOCH = 1 day.
    Lifetime sum is exactly 684M, which is why the allocation is 684M.
  316,000,000 seeds a single-sided Uniswap v4 position held by the
    hook itself, so liquidity can never be withdrawn by anyone.

The token is mined: every day a fixed budget is split between AI
agents in proportion to the tasks each completed that day. Task counts
come from an off-chain API and are pushed on-chain by a single
distributor key. There are about 370 recipients today.

The pool has a static 1% LP fee. The hook is the sole LP, collects the
fees and splits them, with immutable bps and no setters:
  3500 burned via token.burn()
  3500 to the EmissionVault (miners)
  2400 to a CommunityTreasury
   500 to the creator
   100 to a third party

QUESTIONS, in priority order:

1. Distribution to miners. We currently plan: distributor calls
   EmissionVault.release(to = distributor), then BatchPay.pay() to
   ~370 addresses. That is a push model and the distributor briefly
   holds the tokens. Compare it against a Merkle claim model and
   against a streaming model. Which would you choose for ~370
   recipients on an Arbitrum Orbit L2 where recipients have no gas,
   and why? Give concrete gas and UX numbers.

2. Trust in the distributor. The daily task counts are off-chain, so
   somebody must attest to them. We cap withdrawals at 7x the current
   epoch budget per epoch. What else materially reduces the damage
   from a compromised distributor key, without introducing an owner
   or an upgrade path? Consider posting a Merkle root with a
   challenge window, an allowlist of recipients fixed at deployment,
   and a multisig. Rank them by benefit against added complexity.

3. Fee routing. Is splitting inside the hook the right place, or
   should the hook forward 100% to a single immutable splitter
   contract? What breaks in each design if one recipient is a
   contract that reverts on receive, or is later self-destructed?

4. Single-sided launch. The hook opens one position with 316M UP and
   zero ETH in a tick range entirely on one side of the starting
   price, then never touches liquidity again. What are the concrete
   failure modes? Specifically: first-buyer sniping of the cheapest
   ticks, the range being fully consumed, price moving back below the
   range, and fee accrual when the position is out of range.

5. Anything in this design you would refuse to ship, and why.

Answer with reasoning and numbers. Where you are uncertain, say so.
Do not produce contracts.