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 Slice 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.

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

The fee recipient. Pons' launch parameters include a creatorFeeRecipient. Slice 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. Slice 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 Slice 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 $SLICE token follows a different economic model. Its creator fees go to the Slice 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.