Sherpa.fun

04 — Docs

How Sherpa.fun
works

What launching a coin against another coin means, what decides what you can pair with, and where every fee goes.

Fees

One number, split two ways, and yours is the larger part.

The split

Every trade pays the pool fee you chose at launch — 1% by default. Of that:

share of the feeof trade volume, at a 1% fee
You, the creator80%0.80%
Protocol → $SHERPA buyback20%0.20%

There is no third line. The protocol keeps nothing for operations: every cent it takes is earmarked for buying $SHERPA back and destroying it. Neither the token nor the buyback exists yet — until they do, the protocol's share is collected by the protocol treasury.

Fees accrue on both sides of the pair. A buy pays in the pair asset, a sell pays in your coin — so a coin that trades in both directions earns you both.

Your 80% cannot be taken away

The creator share is snapshotted onto your launch at the moment it happens. Changing the default afterwards applies to future launches only; it cannot reach back and cut what an existing coin earns. This is deliberate and it is tested: a creator commits to a launch on the strength of a number, and a protocol that can revise that number later has not really given them anything.

The protocol's own 20% is not snapshotted, because it is the protocol's own money.

You can read any launch's own figure with feeVault.launchOf(token).creatorFeeBps rather than taking this page's word for it.

What you can do with your share

Two settings, both on the fee vault rather than on the pool — so you can change either one later, without relaunching.

Where it goes

setFeeRecipient(token, address) sends your share somewhere other than the wallet you launched from — a multisig, a treasury, a splitter. Only you can call it, and it moves only your share.

A payout already deferred stays claimable by whoever it was owed to.

Or: buy back and burn

setFeeRoute(token, BuybackBurn) stops paying you and destroys your share instead. The part already denominated in your coin is burned directly. The part in the pair asset buys your coin in its own pool and burns what it buys — so the buyback walks the price up through the same range your launch seeded.

It runs inside the same transaction as the fee collection, and the coins bought are sent straight to the burn address without ever touching the vault's balance.

No slippage bound is set on that buy. The input is a small, fixed amount of fees and the output is destroyed, so the worst a sandwich can do is cause fewer coins to be burned than the market would otherwise have given. No principal is exposed.

Or: pay your holders

setFeeRoute(token, HolderRewards) stops paying you and pays the people holding your coin instead. Each collect sells the part of your share that is in your coin — in its own pool, for the pair asset — and puts all of it, with the pair-asset part, into a pot the vault keeps for your launch (rewardsPotOf(token)). It sits there, on chain and visible, until it is paid out to holders pro rata to what they held through the interval since the last payout.

This one is a one-way door. You can move onto it from either other route, and once on it the route never changes again. Your holders are told your share is theirs, and a creator who could switch it back could make that promise and take it away the same afternoon.

Two things to know before choosing it. The split is computed off chain — who holds a coin is not something a contract can read — by one address the protocol's owner names, and that is a trust assumption: the contract guarantees nothing leaves the pot except to holders, never more than it holds, with every recipient and amount published in a HolderRewardsPaid event so anyone can check the arithmetic; it cannot check the arithmetic itself. And it only pays accounts: coins sitting in another exchange's pool, a bridge or a vesting contract earn nothing, because a payout sent to a contract is a payout nobody can spend.

The route is available once the protocol has switched holder rewards on; until then choosing it reverts.

Collecting

collect(token) is permissionless — anyone can trigger it, including a bot, including you. It does not matter who calls it, because the proceeds can only ever reach the recorded recipient, the buyback sink and the treasury. There is no path by which a caller pays themselves.

If a payout cannot be pushed — a blacklist, a paused token, a contract that will not accept it — it becomes a claimable balance rather than reverting. One party being unable to receive must not strand everybody else's fees.