Skip to content
The Founding Airdrop is live. 20,000,000 $MOON for the founding crew. Join now →
How it works

Fees and rewards

Every swap in your pool pays a 1% fee. That fee does not go to Moonfiesta and it does not go to a treasury by default. It accrues inside the locked Uniswap position and gets split three ways between the creator, the protocol, and an optional holder share, on a ratio that is written on chain when the token launches and can never be changed afterwards.

This page explains where the fee comes from, who gets what, and the exact two step path from a swap to WETH in your wallet.

Where the fee comes from

Moonfiesta does not invent a fee. Every launch opens a standard Uniswap V3 pool at the 1% fee tier, and 1% is simply what that tier charges. The fee is taken off the top of whatever you put into the swap, before the trade is priced, and it is credited to the liquidity providers in that range. Since your pool has exactly one liquidity position and that position is locked in LpLocker forever, one hundred percent of the fee lands there. Nowhere else.

The trader pays it. There is no separate Moonfiesta cut layered on top of the swap, and there is no tax on the token itself. If you buy 1 WETH worth of a coin, 0.01 WETH becomes fee and the remaining 0.99 WETH executes against the pool.

Fee tier
Uniswap V3, fixed at launch.
1%
Who pays
Taken from the swap input.
The trader
Who receives
The locked position
Extra protocol fee on swaps
None
Transfer tax
Plain ERC20 transfers. Not a tax token.
0%
Fees are a function of volume, not of price
A pool that never trades never earns anything. Market cap going up does not accrue fees. Only swaps do. A coin can look alive on a chart and still have produced almost nothing to claim.

The three way split

When the factory hands the position NFT to the locker, it records a split in the same transaction: creator basis points, protocol basis points, and holder basis points. The three must add up to exactly 10000 or the transfer reverts and the launch fails. The locker stores that split against the position id and exposes no function to edit it. Not for the creator, not for the protocol, not for the factory owner.

The live test token launched with this split:

Creator
6500 bps. Paid to the launching wallet.
65%
Protocol
2000 bps. Paid to the Moonfiesta treasury.
20%
Holders
1500 bps. Paid to one address chosen at launch.
15%

The creator share is the remainder: the factory computes it as 10000 minus the protocol share minus the holder share. The holder carve out comes out of the creator's side, not the protocol's, which is the honest way to read it. Choosing a 15% holder share means giving away 15 points of your own take.

With the settings live today, the protocol share is 20% and the holder carve out is capped at 20%, so the least a creator can end up with is 60%. That 60% is a consequence of the current configuration, not a law. The number the contract actually enforces forever is a hard cap of 40% on the protocol share, compiled into the factory as a constant that no one can raise.

Owner key risk on future launches
The factory owner key is compromised. The owner can call setSplit and move the protocol share anywhere up to that 40% cap, which would change the split applied to future launches. It cannot touch a token that already exists: the split for an existing token lives in the locker, recorded at lock time, with no setter. Check the split shown for a coin before you launch or buy, and read Safety and risks in full. The contracts are unaudited.
What the chain actually enforces
The three shares must sum to 10000. A non zero share must have a non zero recipient. The split is written once, when the position is locked, and the locker has no function to change it. An existing token's split is genuinely immutable.

Harvest, then claim

Fees do not arrive in your wallet by themselves. Getting them out is two transactions, and they are deliberately separate.

Swap to wallet
Pool
1% of each swap accrues to the position
collectRewards
LpLocker harvests and splits
FeeVault
Credits owed[you][token]
claim
You withdraw to your wallet
Anyone can run step two for anyone. Only you can run step three for yourself.
  1. Fees accrue in the pool
    Nothing to do. Uniswap tracks what the position has earned as people trade.
  2. Someone calls collectRewards on LpLocker
    This is permissionless. collectRewards(tokenId) takes the position id, not the token address, and anyone can call it for anyone's token: the creator, a holder, a bot, a keeper, a stranger. The caller pays the gas and receives nothing for it. The locker pulls the fees out of Uniswap, splits them by the recorded ratio, sends the tokens to FeeVault, and credits each recipient's balance there.
  3. You call claim on FeeVault
    claim(WETH) zeroes your balance and transfers it to you. Only you can claim what is owed to you. There is claimMany too, if you want several tokens in one transaction.

If you want to know why the position id and not the token address: the locker keys everything off the Uniswap NFT. It keeps tokenIdOf(launchToken) as a lookup so the UI can go from a coin to its position without you thinking about it.

Why claiming is pull based

The obvious design is to push: harvest the fees and transfer each recipient their share in the same call. It is one transaction instead of two and it feels better. It is also fragile in a way that matters here.

Recipients are arbitrary addresses. Any of them can be a contract. If a push design transfers to three recipients in a loop and one of them reverts on receipt, whether by accident, because it is a contract with no fallback, or on purpose, the whole harvest reverts. One bad recipient bricks fee collection for everyone else on that position, permanently, and there is no admin to fix it because the locker has no owner.

Pull based removes the failure mode. The harvest only ever writes a number into owed[recipient][token], which cannot revert on anyone else's behalf. Withdrawal is a separate call that each recipient makes for themselves, paying their own gas. A recipient who cannot receive tokens only fails to collect their own share. The other two are untouched.

The same reasoning shows up twice
The factory uses the same pattern for ETH: launch fees and refunds go into ethOwed and are withdrawn later, so nothing is pushed during a launch and a reverting treasury can never block someone else's coin from launching.

WETH, not ETH

Rewards pay out in WETH, the ERC20 wrapper, at 0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73. Not native ETH. The pool is a token/WETH pair, so fees are collected in WETH, credited in WETH, and claimed in WETH. The vault never unwraps for you. If you want native ETH, unwrap it yourself afterwards.

This is the mirror image of buying, where the UI wraps your ETH into WETH inside the router so you never handle WETH directly. See How to trade. On the reward side the wrapper is visible, because you are the one receiving it.

Sells accrue fees in the launch token, not in WETH
Uniswap charges the fee on whatever goes into the swap. Buys put WETH in, so buys produce WETH fees. Sells put the coin in, so sells produce fees denominated in the coin itself. A harvest therefore credits you on both sides, and your vault balance in the coin is real and claimable with claim(coinAddress). The creator studio only reads and claims your WETH balance today, so the token side is easy to forget it is there. It is not lost, it is just not surfaced yet.

Claiming in the UI

The creator studio wraps both steps. Each coin you launched has a Harvest button, which calls collectRewards for that coin's position and moves the fees from Uniswap into the vault. The panel at the top shows your claimable WETH read straight from owed(you, WETH) on the vault, and Claim to wallet calls claim(WETH).

Harvest first, then claim. If your claimable balance reads zero right after a burst of trading, that is expected: the fees are still sitting in the Uniswap position and nobody has harvested them into the vault yet. Both numbers only move once their transaction confirms.

Neither step is required on any schedule. Unharvested fees are not at risk, they are just still in the position. Unclaimed balances sit in the vault until you want them. There is no expiry and no admin path to move them.

The holder revenue share

A creator can carve out part of their own fee share for holders at launch, up to the configured cap. The live test token uses 15%. That share is credited on every harvest, same as the other two.

This is worth being precise about, because it looks like something it is not.

A reflection or tax token
Logic in the token's transfer function. You pay to move your own coins.
Taxes every transfer
The Moonfiesta holder share
Logic lives in the locker. The token itself has no tax.
Routes swap fees

The token contract has no tax code in it at all. The only logic on the transfer path is the temporary anti snipe cap on buys, and it switches itself off when the window ends. Sending your coins to a friend costs you nothing but gas. The holder share is fee routing that happens entirely outside the token, in a contract the token does not know about.

The holder share goes to one address
The locker credits a single communityRecipient, fixed at launch. It does not know who your holders are and it does not distribute to them. Splitting that balance across actual holders is entirely the creator's problem, off chain or through a contract they point it at. If a creator sets the holder recipient to their own wallet and calls it a revenue share, nothing stops them. Check where that address actually points before you buy a coin because of its holder share.

A worked example

Take the live split, 65 creator / 20 protocol / 15 holders, and a week where the coin trades 150 WETH of buys and 40,000,000 tokens worth of sells. The two sides accrue separately, so do the arithmetic twice.

The buy side, in WETH

150 WETH in, at 1%, is 150 x 0.01 = 1.5 WETH of fees.

Creator, 65%
1.5 x 0.65
0.975 WETH
Protocol, 20%
1.5 x 0.20
0.300 WETH
Holders, 15%
1.5 x 0.15
0.225 WETH
Total
1.500 WETH

The sell side, in the coin

40,000,000 tokens in, at 1%, is 400,000 tokens of fees.

Creator, 65%
260,000 tokens
Protocol, 20%
80,000 tokens
Holders, 15%
60,000 tokens
Total
400,000 tokens

After one collectRewards call the creator can claim 0.975 WETH and 260,000 tokens from the vault, in two separate claims or one claimMany. The studio will show the 0.975 WETH.

Scaling is linear and there is no cliff: 1000 WETH of buy volume is 10 WETH of fees and 6.5 WETH to a creator on a 65% share. Divide by 100 to get from volume to fees, then apply your share.

Rounding dust goes to the creator
The locker computes the protocol and holder amounts by multiplication, then gives the creator whatever is left over rather than computing it. Integer division loses at most a wei or two per harvest and the creator absorbs it. This matters for nothing financially. It matters because it means the three shares always sum to exactly the harvested amount, with nothing stranded in the locker.

Common questions

Can the split be changed after my token launches?

No. It is recorded in the locker when the position is locked, in the launch transaction, and the locker has no function that writes it again. Not the creator, not the protocol, not the factory owner.

The factory owner can change the defaults that future launches get, up to the hard coded 40% protocol cap. That key is compromised, which is why Safety and risks exists.

Do I have to harvest my own token?

No. collectRewards is permissionless and anyone can call it for any position. The split is fixed, so a stranger harvesting your token cannot redirect anything: it credits the same three addresses it always would. They just pay the gas for you. Claiming, on the other hand, is yours alone.

Can someone claim my fees?

No. claim reads owed[msg.sender][token] and pays the caller. There is no argument for a recipient, no delegate path, and no admin function to move accrued balances. The vault credits the addresses the split names and nothing else.

What if I lose access to the creator wallet?

The fees are unrecoverable. The creator address is fixed in the position record at launch and there is no way to reassign it. Fees will keep accruing and keep being credited to an address you cannot use. Launch from a wallet you intend to keep.

Does the protocol take a cut of my supply or my liquidity?

No. The protocol share is a share of swap fees only. The factory charges a small flat ETH fee at launch, separate from all of this, and it never receives any of your token or any of the locked liquidity. The principal is not withdrawable by anyone, including us. See Locked liquidity.

Where do the fees live before I claim?

In two places depending on how far along they are. Before a harvest they are inside the Uniswap position, owed to the locked NFT. After a harvest they are ERC20 balances held by the FeeVault contract at 0x6Ef8d43e565b2AD52909591427089b41083bE0De, with your share recorded against your address. You can read owed(yourAddress, tokenAddress) on the explorer without connecting anything.