Docs

A creator launches a token and picks one to three approved RWA reward assets, with weights totalling 100%. From the first trade, Pons charges fees on the ETH side of the market. Those fees do not go to the creator's wallet — they go to a contract that converts them into the chosen RWAs and sends them to the people holding the token.

The RWAs are a reward, not a trading pair. Every BSKTS market is TOKEN / ETH regardless of what its basket contains.

The same five steps, in protocol terms. Each launch runs its own three-minute clock:

1. Trading on Pons accrues ETH creator fees, credited to the launch's BasketDistributor.
2. When the window closes, a keeper calls processEpoch. The distributor pulls its accrued ETH out of the Pons fee escrow.
3. The ETH is split by the basket weights and swapped for each RWA through RewardRouter, which only follows pre-approved routes.
4. The purchased RWAs are moved to AutoAirdropDistributor and recorded as that epoch's reserve.
5. The airdrop worker computes each holder's share and submits it in batches. The contract transfers the tokens out.

BSKTS launches through PonsV2LaunchFactory on Robinhood Chain (chain id 4663). Two details carry the whole integration.

The fee recipient. Pons' launch parameters include a creatorFeeRecipient. BSKTS sets it to the launch's own BasketDistributor. That single field is what makes Pons pay holders instead of the creator, and Pons fixes it at creation — so a creator cannot redirect the reward stream after the fact.

ETH as the quote asset. BSKTS always passes the zero address as the pair token, which is how Pons expresses a native-ETH market. Fees therefore arrive in one uniform asset for every launch.

Pons credits fees to an escrow rather than pushing them, and its claim() takes no arguments — it pays whoever calls it. So each distributor pulls its own balance during processEpoch; nothing can claim on its behalf, and a keeper has no recipient or calldata to manipulate.

A basket holds one to three assets from a curated registry, with weights in basis points that must total exactly 10,000. Both the assets and the weights are fixed at launch and cannot be changed afterwards, by the creator or by protocol admins.

Only assets in RewardRegistry can be chosen, and each must have an approved swap route. A creator cannot point a basket at an arbitrary token address.

With many launches running at once, nothing about a distribution is global. Every launch gets its own BasketDistributor clone, and Pons pays that specific contract, so fee streams never mix: a token's ETH physically lands in its own distributor.

Holder rewards are held in one shared AutoAirdropDistributor, but every record inside it is keyed by the launched token first:

Two guards keep those namespaces honest. Only a launch's registered distributor may credit that launch's reserves, and no allocation can exceed the reserve recorded for its own token and epoch. This matters because the reward assets themselves sit in one pooled contract balance: if two launches both reward the same asset, they share an ERC-20 balance, and it is the per-launch accounting that stops one from spending the other's share.

The holder list itself is not computed on chain. The indexer follows ERC-20 transfers for each launched token and keeps balances per token and wallet, so a wallet holding two BSKTS tokens has two independent balances and earns each basket separately. At epoch close, the worker reads the snapshot for that one token, allocates pro-rata by balance, and submits the result as an explicit list of recipients and amounts.

So a holder of token A receives only token A's basket, in proportion to their share of token A. Holding both tokens simply means being included in two separate distributions.

Eligibility is a token balance at the epoch snapshot. There is no staking, no lockup, and no registration. Allocation is strictly pro-rata: your share of the basket equals your share of the eligible supply.

A small set of addresses is excluded explicitly — the zero and burn addresses, the protocol's own contracts, and the launch's Pons bonding curve. The curve matters most: Pons mints the entire supply to it, so until the launch graduates the curve is by far the largest holder. Leaving it in would hand nearly every reward back to the venue.

Rewards are pushed, not claimed. There is no claim() function for holders to call, which means no gas cost, no forgotten rewards, and no advantage for whoever watches the chain most closely.

Two details make pushing safe. A reward below a per-asset dust threshold stays pending and accumulates instead of being sent, so tiny balances do not cost more in gas than they are worth. And a transfer that fails — a token that reverts on a particular recipient, for instance — is isolated: that holder's balance stays pending and the rest of the batch still goes out.

The protocol's own $BSKTS token follows a different economic model. Its creator fees go to the protocol treasury rather than buying an RWA basket, so it never gets a BasketDistributor and never distributes RWA rewards. The launchpad rejects any attempt to give it one.

Six contracts are deployed once on Robinhood Chain and shared by every launch, listed here in the order a launch touches them. Every address is shown in full and links to the explorer, so nothing on this page has to be taken on trust.

One per launch

BasketDistributor is the exception: there is a separate one for every token, created at launch, and its address is shown on that token's page. It is the contract Pons pays. It holds that launch's ETH, runs its three-minute clock, and on each epoch pulls its fees out of the Pons escrow, splits them by the basket weights, sends them through RewardRouter, and hands the purchased RWAs to AutoAirdropDistributor. Its basket is fixed at creation and cannot be changed by anyone, including protocol admins. Neither the creator nor an admin can withdraw from it — there is no function to do so.

Supporting code

BasketLib holds the basket rules, so the same validation applies wherever a basket is read: one to three assets, no duplicates, no zero weights, every asset in the registry, and weights summing to exactly 10,000 basis points. V3Path encodes Uniswap V3 swap paths and checks that an approved route really starts at WETH and ends at the asset it claims to buy. SliceTreasury receives the native token's fees and is deliberately never attached to a launch, which keeps protocol revenue and holder rewards from touching the same accounting.

Retired

The launchpad and the adapter are not upgradeable, so changing them means deploying new ones. These are the versions they replaced. They can no longer create launches, but the tokens they did create are unaffected and still earning: a launch's rewards run through its own distributor, which does not depend on the launchpad that created it.

Two keys sign continuously from a server: a keeper that closes epochs and a worker that sends the airdrops. Both are deliberately limited, because a server key is the one most likely to be stolen.

What no role can do matters more. Nobody can change a basket after launch, redirect where a launch's fees go, withdraw ETH or RWAs from a distributor, or pay a swap out to an address of their choosing. Those are not permissions that are withheld — the functions do not exist.