FEW Whitepaper

A non-custodial daily-lottery surface for Robinhood Chain.

v0.1 — September 2026 · few.family

Abstract

FEW lets users on Robinhood Chain (chain 4663) enter a daily on-chain jackpot that settles on Base (chain 8453), without bridging manually, holding a second gas token, or trusting FEW with funds. A user signs one message, pays in USDG on their own chain, and receives ticket NFTs at their own address on Base. FEW operates purely as an interface and referrer: it holds no treasury, custodies no tickets, and touches no winnings.

1. Problem

The jackpot protocol FEW builds on lives on Base, where its liquidity and daily drawings are. Robinhood Chain users largely will not bridge on their own: it means new RPCs, new gas, and a workflow that kills casual participation. The product question is how to sell a Base-settled ticket to a user who never leaves Robinhood Chain — without becoming a custodian in the middle.

2. Design

The purchase is one signed request carried across a bridge-and-call:

1. The app reads the live drawing on Base — price, number ranges, closing time — and the user picks their numbers.
2. The user signs an EIP-712 BuyRequest binding their recipient address, a spending cap (amountIn), a hash of the exact picks, a deadline, and a pre-draw safety buffer.
3. The user pays USDG on Robinhood Chain against a bridge quote. A solver delivers USDC on Base to FEW's router contract and calls it in the same transaction.
4. The router verifies the signature, re-checks the live drawing, buys the tickets with the user as recipient, and refunds any unused budget to the user. Ticket NFTs mint directly to the user's Base address.

The signature is what makes the flow safe without custody: copied calldata can only replay the exact same purchase for the same user, a tampered request fails verification, and a request can never spend more than it was quoted for. Each request is single-use.

3. Trust model

• Tickets and winnings: non-custodial. NFTs mint to the user's address; prizes pay from the protocol to the ticket owner. FEW never touches either.
• Payment: non-custodial. Funds move user → bridge solver → jackpot protocol. The router holds no balance between transactions.
• One privileged function. The router owner can recover tokens stranded by a failed delivery. In the intended flow the router holds nothing, so there is nothing to take; this surface is documented and intentionally minimal.

4. Failure handling

5. Economics

Tickets cost exactly the protocol price — FEW adds no markup. FEW is compensated through the protocol's on-chain referral program: a share of the ticket fee at purchase and a share of referred winnings, both set by the protocol per drawing and read live, never hardcoded. The referral scheme also supports sub-affiliates, paid out of FEW's share, never the user's.

6. Risks and open items

• Claim gas. Claiming winnings is owner-gated by the protocol and needs ETH on Base. A winner who has never touched Base needs a small gas drip — this is a launch requirement, not an afterthought.
• Bridge dependency. The flow depends on bridge-and-call being available on the 4663 → 8453 route. Purchases fail safe (refund), but availability is an external dependency.
• Smart-wallet addresses. Tickets mint to the same address on Base. An address that is a smart wallet the user does not control on Base could strand tickets; the app assumes externally-owned accounts.
• Lottery participation is risk. Tickets are a game of chance. Nothing here is financial advice; play with what you can afford to lose.

7. Contracts

The router is deployed on Base as the destination of the bridge-and-call; the current address is published on the docs page. FEW is an independent interface and referrer, not affiliated with the underlying protocol.