How feed works

1. Launch. The coin, its fee router, its purchase vault and its round distributor are created in one transaction. The reward token, reward mode, round length and minimum qualifying balance are fixed for the life of the coin.
2. Collect. Trading the coin generates creator fees in ETH. Each receipt is split when it reaches the vault: the $feed share (the equivalent of the platform fee pinned at launch, 0.25% of trading volume for coins launched now) goes to feed's platform buyer, and the rest is credited to the hour it arrived in.
3. Buy. When an hour closes, its ETH buys the reward token through one reviewed route, within price limits the contract enforces. What it buys is that round's prize.
4. Draw. The round's entrants (the largest qualifying wallets) are committed first. Then a drand beacon draws up to 10 distinct winners, who split the prize in proportion to their qualifying balances. Awards are delivered automatically, and anyone can trigger a claim, which always pays the winner.

Three things are easy to confuse and feed keeps them apart: the coin you launch, the reward token its fees buy (for example SNOP earning PONS), and ETH, the currency the coin trades against. Holding the reward token, or $feed, does not enter anyone into a coin's draw: only holding the coin does.

• Mayhem. Each of the top 1,000 qualifying wallets has the same chance on every draw, whether it holds just above the minimum or is the largest holder.
• Default (preselected at launch). The chance on a draw follows the qualifying balance: a wallet with 5% of the entrants' combined balance has a 5% chance on the first draw. Splitting the same tokens across wallets does not raise the combined chance, and splits below the minimum lose it.
• Top Holders. Only the 100 largest qualifying wallets enter, each with equal odds; rank 101 is out. With 100 entrants and 10 winners each wallet's chance is about 10%.
• In every mode the prize is split among the winners by qualifying balance: award = floor(prize × balance ÷ winners' combined balance). The rounding remainder goes to the next round.
• Every round is independent: previous winners can win again. There is no ticket, stake, entry fee or “enter” button; connecting a wallet only shows your status. Equal odds are per wallet, not per person, and nothing here is Sybil-proof.

Rounds are consecutive one-hour windows counted from the coin's launch block time: window k covers [launch + k hours, launch + k + 1 hours). A worker's delay never moves a boundary. A transfer or fee receipt in a block whose time is at or after a boundary belongs to the next window.

• The first hour is a warm-up. It collects fees but draws nobody; its fees fund round 1. The first draw therefore closes about two hours after launch, which gives early buyers a full qualifying hour.
• After a round closes its ETH is spent on the reward token, the entrant list is approved by the signature of feed's side wallet (see who runs feed) and committed, reviewed for 10 minutes, drawn from a drand beacon fixed 20 minutes ahead, settled and delivered: roughly 45 minutes under normal conditions. A new round keeps collecting meanwhile.
• The countdown on a coin page is the collection cutoff, never a payout time.

A wallet's qualifying balance for a round is the lowest balance it held through the whole window, including its close. It is a minimum, not an average or an end-of-round snapshot.

• The minimum is 0.01% of the coin's initial supply, computed on chain at launch and fixed: 100,000 tokens for a standard 1,000,000,000-token Pons launch. The wizard shows it before you launch.
• Wallets at or above the minimum are ranked by qualifying balance (ties by lower address). Mayhem and Default draw from the top 1,000, Top Holders from the top 100. With fewer qualifying wallets, all of them are drawn from.
• Excluded: the zero address and burn addresses, the coin's own contract, Pons's curve, pool, escrow and hook contracts, and feed's own contracts, under the versioned exclusion policy fixed per round. Nobody can remove an ordinary holder by hand. Smart-contract wallets are not excluded for being contracts, and the creator is treated like anyone else.
• Selling after a round closes does not change that round. Selling during the next round lowers the next round's balance.

1. The round's entrant list (every entrant with its balance and weight, as a Merkle tree) is committed on chain with the prize before any randomness exists.
2. The commit names a drand quicknet round 400 beacons (20 minutes) ahead. Once the review ends, one randomness request is made, bound to the chain, the feed, the round and the commit. There is no cancel, re-request or re-roll.
3. From the beacon's random word, draw k derives its own ticket with unbiased rejection sampling. The entrant whose range contains the ticket is drawn; an entrant already drawn is skipped (the draw still counts). Drawing stops at 10 distinct winners (all entrants when fewer) or after 100 draws.
4. Settlement proves every draw against the committed tree, then fixes each winner's award by the balance split. Awards are per (round, wallet): claim(roundId, account) pays only that wallet, and a failed transfer stays claimable instead of moving to anyone else.

A round with no qualifying wallet draws nobody: its prize returns to the carry pool and joins the next committed round. See Recent draws for every coin's latest draws and their evidence.

The $feed buy: 0.25% of trading volume

Every coin sends the equivalent of its platform fee to feed's platform buyer, always on: 0.25% of its trading volume for a coin launched now (0.0025 ETH per 1 ETH traded). The fee is pinned per coin at launch and never changes for that coin. The launcher's owner (feed's dev wallet) can change it for new launches only, with one public transaction that applies at once (no delay), at most 1% of volume (the default is 0.25%). A launch you reviewed under another fee reverts, and you review again. Because feed's router only sees creator fees, the launcher pins a share of each receipt: platformShareBps = floor(25 × 10,000 ÷ (creator fee share + creator tax)). With Pons launch configuration 0 (a 1% curve fee, 30% kept by Pons) that is 35.71% of receipts at a 0% tax, 14.70% at 1% and 2.33% at 10%: a higher tax lowers the share so the $feed buy stays at 0.25% of volume.

• The dev wallet can take the waiting ETH out. Failsafe: the platform buyer's owner, feed's dev wallet, can take any amount of the ETH waiting in it, up to all of it, out to its own wallet at once. It was added in case the buys get stuck, but the contract does not check that they are: the dev wallet can do it at any time, for any reason. ETH taken out is not used to buy $feed. Every withdrawal is public, with its amount and transaction, on the buyback page and on the admin-changes page.
• Otherwise FeedPlatformBuyer's ETH buys $feed through its configured route, and the $feed goes straight to the feed treasury (the operator's dev wallet). The owner (the same dev wallet) can change the $feed token, the route and the treasury at once, for every coin's share; each change is public on the admin-changes page.
• While $feed trades on its Pons curve there is no on-chain average price to check the buy against: the only price limit is the minimum output feed's keeper (the side wallet) sets from its own quote, and the contract only checks that it is not zero. Whoever holds the keeper's key could let a buy go through at a bad price, for example inside a sandwich, up to the route's maximum trade size once per cooldown. That part is platform ETH on its way to the treasury, never holders' prizes. The same key also approves winner lists, which does reach prizes (see who runs feed).
• The share is part of each coin's configuration hash and never changes after launch. Holders' prizes are never used for it.
• Operating costs (gas for harvests, purchases, draws and deliveries) are paid from a separately funded operator wallet (the side wallet), not from fees.

Fees move through stages feed shows separately: accrued upstream in Pons, received by the coin's vault (then split), and spent on settled purchases. None of these is added together and called revenue.

• Before graduation the coin trades on its Pons bonding curve and the creator share is credited to the coin's feed router in the Pons fee escrow, where a harvest claims it.
• After graduation the coin trades in a Uniswap V4 pool. Most fees there accrue in the coin itself, and only Pons's sweep operator can convert them to ETH. Until that happens they are shown as pending upstream, never as received.
• Purchases use the one route pinned at launch, checked against a time-weighted average price with limits on deviation, liquidity, trade size and cooldown. Thin or new markets wait instead of trading at a manipulated price. A round's leftover below the route's minimum trade, or its whole budget while purchases are paused, carries into the next round.

Prizes come only from creator fees, and creator fees come only from trades. An hour without trades buys nothing and draws nobody ("Rolled over: no fees"). feed does not mint rewards, pre-fund them or promise a rate, and the ETH collected is never converted into a promised amount before the purchase settles.

• The dev wallet is one ordinary wallet with one key, kept by feed's operator, not on feed's servers. It owns every feed contract that has an owner (the launcher, the registries, the platform buyer and its price guard) and holds every admin role: the catalog admin, curator and guardian, the owner, guardian and guardian admin of the attestor set, and the treasury that receives the $feed the platform buys. No change needs a second signature.
• The side wallet is feed's keeper, and its key is kept on feed's server. It sends the automatic transactions (harvests, purchases, draws and deliveries), makes the platform's $feed buys, and is the only signer of the attestor set: its signature alone approves a round's winner list.
• This is not independent checking. By default feed's contracts require at least two signatures on every winner list on Robinhood Chain, and its deployment script also requires three signers and multisig Safes for the admin roles. feed's deployment turns that off with an explicit setting of its attestor set (the single-operator flag), fixed when the set was deployed and readable by anyone on chain.

feed's operator runs a deterministic program (its source is not yet published) that computes each closed round from chain data: boundary blocks and hashes, every holder's opening and qualifying balance, exclusions with evidence, the entrants with weights and ranges, and the prize. The manifest is published and its hash committed on chain.

• The verifier program that holds the side wallet's key recomputes the manifest from chain data and signs only an identical result. That one signature commits a round: feed's attestor set is 1-of-1, and nothing independent checks the list before it is committed.
• A committed round is reviewed for 10 minutes. During review the guardian (the dev wallet) can cancel it; the round keeps its prize and a corrected list starts a new review. If the guardian cancelled a correct list, that round's prize stays frozen until the guardian reinstates the list, which then goes through attestation and a new review. After review the draw can no longer be stopped.
• A key held by feed's own operator is not an independent verifier, and feed does not describe its attestation as independent.

• A coin's reward token, reward mode, round length, minimum balance, $feed share and randomness contract are fixed at launch. Its purchase route is not: the curator can move it to a successor route for the same reward token, at once (see below).
• feed's fee router is the coin's Pons creator-fee recipient. It has no function that moves that role, turns on Pons buyback, approves spenders, runs arbitrary calls or withdraws.
• The vault splits each receipt exactly (the $feed share, then the round's budget) and can only buy the pinned reward token through the pinned route. It has no withdraw function.
• A round's prize is exactly what its ETH bought plus the carry pool; one round can never spend another's receipts.
• Awards are paid only to the winning wallet, never twice. Batched deliveries carry at most 50 items; a failed item stays claimable.
• A guardian pause blocks new commits and draws but never erases a committed request, a result, an award or its claim.
• At most 50 reward tokens can be active, only on Robinhood Chain and only after review. Admin changes (modules, routes and successors, the attestor set, the randomness contract and fee for new launches, the $feed buy) apply at once, with no delay; each one is public on the admin-changes page.
• What you reviewed is what launches: the configuration hash binds the $feed fee and the randomness contract in force.

Deployed contracts

• Launcher0x95F2…b349Explorer ↗ (opens in a new tab)
• Feed registry0x354d…2A1bExplorer ↗ (opens in a new tab)
• Target registry0x378B…7005Explorer ↗ (opens in a new tab)
• Attestor set0x57C4…Ec6dExplorer ↗ (opens in a new tab)

• Existing coins' prizes (attestor-set owner: the dev wallet). It replaces the signers at once. Signers it controls can commit a winner list of their own wallets for any coin's funded round. The guardian, which could cancel such a list within its 10-minute review, is the dev wallet too, so nothing else can stop it.
• Existing coins' purchases (curator: the dev wallet). It can activate a module of its choice, register a route through it and move a coin's purchase route to it, all in one block, which sends that coin's round budget through the module; the reward token itself cannot change. A module the guardian switched off can be switched on again at once, and the admin-changes page labels that as a re-activation.
• The $feed buy (owner). It sets the $feed token, route and treasury at once, for every coin's share, and it can take the ETH waiting in the platform buyer out to itself at once (the failsafe above), so that ETH never buys $feed. Holders' reward budgets are not affected.
• New launches (owner). It sets the randomness contract and the $feed fee new coins pin, at once. Existing coins keep theirs. A launch reviewed before a change reverts, so nobody pins a contract or fee they did not see.
• Emergency switches (pausing purchases, draws or launches) are instant too. They change timing, never who won what.

feed runs on Pons V2 and depends on it. Pons administration keeps powers that feed cannot remove:

• Fee-recipient override. The Pons owner can propose a new creator-fee recipient for any launch. The change becomes executable after 3 days and expires 3 days after that. If it is executed on a feed coin, future creator fees stop reaching feed. feed cannot block it; it shows an alert on the coin page and the status page. Prizes and awards feed already holds stay claimable.
• Sweeping after graduation. Once a coin graduates, most of its fees need Pons's sweep operator to convert them. If the operator stops, those fees stay upstream.
• Future launch terms. Pons can pause public launches or change the launch fee and fee policy for new launches. feed pins the terms shown at Review, so a change makes a pending launch fail rather than silently reprice. Existing coins keep the terms they launched with.
• Graduation rescue. If a graduation is stuck for 7 days, the Pons owner can release the swept reserves; anyone, including feed's keeper, can prevent this by completing the pool creation first.
• Buyback. Pons's own buyback of the coin is off at launch. feed's router cannot turn it on; the Pons owner can only turn it off.

Purchases also depend on wrapped ETH on Robinhood Chain, an upgradeable contract controlled by the chain operator, and on the reward token's own contract and market. feed monitors these and pauses purchases if their behavior changes.

You need the coin's address, the winning wallet and an RPC endpoint for Robinhood Chain. Everything below reads the chain directly, so you do not have to trust feed's servers.

# 0. Inputs
export RPC=https://rpc.mainnet.chain.robinhood.com
export REGISTRY=0x354d2EaEC577f6Cb6a50F4bf6Db346E6E99D2A1b
export COIN=<the coin's contract address>
export ACCOUNT=<the wallet that won>

# 1. Find the feed and its round distributor
FEED_ID=$(cast call $REGISTRY "feedIdBySourceToken(address)(uint256)" $COIN --rpc-url $RPC)
cast call $REGISTRY "getFeed(uint256)((uint256,address,address,address,address,address,address,uint256,address,bytes32,uint64,uint8,uint16,uint32,bytes32,bytes32,address,address,uint16,uint64,uint64,uint256,address,uint16))" $FEED_ID --rpc-url $RPC
# Field 6 is the distributor.
export DISTRIBUTOR=<field 6>

# 2. The L2 block the coin launched in. FeedRecord.launchBlock (field 21) is the L1 block
#    number on Robinhood Chain (D-031); use the block of the FeedLaunched receipt instead.
#    Its transaction hash is on the coin page (Details, Launched) and in the API (launchTxHash).
export FROM=$(cast receipt <launch tx hash> blockNumber --rpc-url $RPC)

# 3. Every round this wallet won (one WinnerAwarded log per award)
cast logs --rpc-url $RPC --address $DISTRIBUTOR --from-block $FROM \
  "WinnerAwarded(uint64 indexed roundId, address indexed account, uint256 amount, uint256 qualifyingBalance, uint256 drawIndex, uint256 ticket)" "" $ACCOUNT

# 4. The award of one round: (won, amount, qualifyingBalance, paid)
export ROUND=<roundId from topic 1>
cast call $DISTRIBUTOR "award(uint64,address)(bool,uint256,uint256,bool)" $ROUND $ACCOUNT --rpc-url $RPC

# 5. Claim. Anyone may send this; the award always goes to $ACCOUNT.
cast send $DISTRIBUTOR "claim(uint64,address)" $ROUND $ACCOUNT \
  --rpc-url $RPC --account <your keystore name>    # or --ledger

# Several rounds at once (at most 50 items; each item is isolated):
cast send $DISTRIBUTOR "claimMany(uint64[],address[])" "[<round 1>,<round 2>]" "[$ACCOUNT,$ACCOUNT]" \
  --rpc-url $RPC --account <your keystore name>

• Search logs from the L2 block of the coin's launch receipt, not from FeedRecord.launchBlock: on Robinhood Chain that field is the L1 block number, and a search from it would start in the wrong place.
• Anyone can send the claim, and the award still goes to the winning wallet. A paid award cannot be paid twice. Use a keystore or hardware wallet; never paste a private key into a command.
• In this app, Rewards does the same: claim for one award, claimMany for several (at most 50 per transaction).

Separately from the launchpad buy above, $feed's own creator fees go to the team's dev wallet. The team pledges that every hour, counted from $feed's launch, 50% of the creator fees $feed generated that hour is used to buy $feed. These buybacks are purchased through the official dev wallet rather than by a smart contract, and every purchase is listed with its transaction.

The buyback page shows each hour's fees, the 50% pledge, what the dev wallet spent and the $feed it received, next to the launchpad buys made by FeedPlatformBuyer and every withdrawal of its waiting ETH by the dev wallet (the failsafe above). The two flows are never added together. Before $feed launches, the page says so and shows no numbers, except the launchpad ETH waiting in the buyback contract (0.00363 ETH now).

• Purchases paused. If a reward token's route becomes unsafe, the curator or guardian can pause purchases. Each round's ETH carries forward in the coin's vault. Nothing is converted into a different token, and the coin's reward token cannot be changed.
• Not enough price history. A new or thin market waits until the price reference is available instead of falling back to the spot price.
• Route succession. If a pinned pool loses its liquidity, the curator can register a successor route for the same reward token; it applies at once (no delay) and never changes which token a coin earns. The guardian can cancel a successor, but the curator can set it again.
• In every case, earlier prizes, awards and claims are unaffected. A pause changes timing, not who won what.

• Rewards are not guaranteed, and being drawn never is. They depend on trading activity, upstream fee policy, purchase execution and the reward token's market.
• A reward token's price can fall. feed shows reward-token units; any USD figure is an estimate and is shown only when fresh.
• Smart contracts can contain bugs. The v2 contracts have no independent audit yet, including the randomness contract every draw uses; feed launches with that disclosed rather than waiting for the audit.
• Admin keys can change live configuration at once (see who can change what, above). They are all held by one wallet, feed's dev wallet, not by a multisig.
• Upstream parties (Pons, the chain operator, token teams, pool liquidity) can change what feed receives or buys.
• Entrant lists are approved by one key kept on feed's server, the side wallet's, and nothing independent checks them (see who runs feed, above).
• feed is not affiliated with Nosh, Pons, Robinhood Markets or any reward-token team. A token's presence in the catalog is not an endorsement by or of that token's team.