Skip to content
The Founding Airdrop is live. 20,000,000 $MOON for the founding crew. Join now →
Before you trade

Safety and risks

This page is the honest version. It tells you what the contracts actually enforce, what they do not, and where you can lose money. Some of it is unflattering.

The short version: the liquidity really is locked and the supply really is all in the pool, but the code is unaudited, the factory owner key is currently compromised, and most new tokens go to zero regardless of any of that.

What is structurally guaranteed

These are properties of the deployed bytecode, not promises. Each one is readable on the explorer and none of them depends on anybody behaving well.

Enforced by the chain
  • Liquidity is locked with no withdraw path. The Uniswap position NFT is transferred to LpLocker during the launch transaction. That contract has no owner and no function that transfers, withdraws, unlocks or decreases a position. The only thing it can do is harvest fees.
  • The entire supply went into the pool. The factory mints the whole supply and deposits all of it as single sided liquidity in the same transaction. If less than the full supply lands in the position, the transaction reverts. There is no team allocation held back.
  • Fixed supply, mint renounced. The token has no mint function after initialisation. The factory holds a temporary admin role for the length of the launch transaction and then zeroes itself in finalize. Nobody can mint another token, ever.
  • No transfer tax, no blacklist, no owner. Every token is an EIP 1167 clone of one implementation at this address, so they all share identical bytecode. The only transfer path logic is the anti snipe cap described below.
  • The fee split is immutable per token. The creator, protocol and community shares are written into the locker when the position is deposited and there is no function to change them afterwards. Fees are pull based: you call claim on FeeVault yourself and no admin can move what you are owed.

The defaults a launch uses today, all readable on the factory:

Fee tier
Paid on every swap.
1%
Default supply
1,000,000,000
Anti snipe window
Buys only. Self disables when it ends.
300s
Anti snipe max wallet
20,000,000 tokens at the default supply.
2%
Protocol fee share
Hard capped at 40% by PROTOCOL_BPS_CAP.
20%
Creator fee share floor
Before any carve-out the creator chooses to give holders.
60%

The code is unaudited

No third party audit

These contracts have never been audited by an external firm. What they have had is an internal adversarial review, which found and fixed real bugs, and a test suite. That is not the same thing and you should not treat it as if it were.

An internal review is done by the people with the strongest incentive to believe the code works. Every serious exploit in this industry got past someone who was sure the code was fine. Assume there is a bug nobody has found yet, including in the parts this page describes as guaranteed, and size your position on that basis.

The contracts are also non upgradeable, which cuts both ways. Nobody can quietly swap the logic under you, and nobody can patch a bug either. If something is wrong, it is wrong permanently.

The factory owner key is compromised

Compromised key, being rotated

The LaunchFactory owner is currently a throwaway key that must be treated as compromised. Assume a hostile party can call every owner function on it right now. This is being fixed by rotating ownership to a multisig. It has not happened yet. Read owner() on the factory in the explorer to see who currently holds it.

The blast radius is real but bounded, and the boundary is worth understanding exactly, because it is the difference between a nuisance and a catastrophe.

What the owner can do, on future launches only:

  • setAntiSnipe takes a max wallet and a window with no bounds check at all. A hostile owner could set the cap to 1 basis point and the window to the maximum a uint32 holds. On a 1,000,000,000 supply that is a 100,000 token limit per wallet, or 0.01%, lasting roughly 136 years. Any token launched under those settings would be close to unbuyable.
  • setSplit can move the protocol fee share, though it is capped in code at 40% by PROTOCOL_BPS_CAP. That is the one owner power with a real ceiling.
  • setFees can change the launch fee and the buy and burn contribution, with no cap.
  • setPayoutAddresses can redirect where the protocol share of future launches is sent.

What the owner cannot do, at all:

  • Touch a token that already launched. Every parameter freezes at launch. The anti snipe values are baked into the token at initialisation, the deadline is set in finalize, and the fee split is written into the locker when the position is deposited. Changing a factory default has zero effect on anything already deployed.
  • Touch the locker or the vault. Neither contract has an owner. The locker cannot release a position and the vault has no admin path to accrued balances.
  • Take your tokens or your claimable fees. There is no path to your balance from any owner function.
If you are about to launch

The factory reads its defaults at execution time, not when the UI showed them to you. In principle a hostile owner could change the split or the anti snipe values in the block before your launch lands, and your token would freeze with those values instead of the ones you saw. The ceiling on how bad that gets is the 40% protocol cap, so your fee share cannot drop below 60% before your own community carve-out, but your anti snipe settings have no such floor. Check your token on the explorer after it launches.

Anti snipe is a deterrent, not a control

For the first 300 seconds a wallet cannot buy past 2% of supply, which is 20,000,000 tokens at the default 1,000,000,000. It applies to buys only, it never blocks a sell, and it switches itself off permanently when the window ends.

It is trivially bypassable
  • Multiple wallets. The cap is per wallet, not per person. Ten wallets buying 20,000,000 each is 200,000,000 tokens, or 20% of supply, inside the window. The only cost of the tenth wallet is gas.
  • Routing. The check only fires when tokens move directly out of the pool. A route where the tokens land somewhere else first and are forwarded to the buyer does not trip it.

Treat it as a speed bump against lazy snipers. Do not price a token as if early concentration were prevented, because it is not.

There is one asymmetry worth knowing, because it limits the damage of the owner key problem above. The cap is checked only on transfers out of the pool, so it can restrict how much you buy but it can never stop you selling what you already hold. Even the hostile configuration described earlier gates entry, not exit.

MEV and sandwich exposure

Your swap is a public transaction. Anyone watching pending transactions can buy in front of you, let your buy push the price up, and sell into it. You still get filled, just at a worse price, and the difference is their profit. Nothing about a locked position or a fixed supply prevents this. It is a property of trading on a public chain.

Your slippage setting is the only thing bounding it, because it is a floor on what you accept. Suppose the quoter says 1 ETH buys 10,000,000 tokens:

1% slippage
Minimum tokens you accept. Roughly 100,000 tokens of room.
9,900,000
50% slippage
Minimum tokens you accept. Roughly 5,000,000 tokens of room.
5,000,000

A 50% setting is an instruction to fill you even if half your money disappears. People set it because a tight slippage kept reverting, which is the wrong fix: on a thin new pool a revert is usually the trade telling you the price moved. Losing gas on a failed buy is cheaper than getting sandwiched. See How to trade for how the quote and the floor fit together.

The floor is a price floor, not an exit guarantee

This is the single most misread thing about the mechanics, so read it slowly. A creator sets a target floor market cap, and that picks the tick the pool starts at. It does not put any money in the pool.

At launch the pool holds the full supply and zero WETH. A launch with a 1 ETH floor market cap on a 1,000,000,000 supply starts at 0.000000001 ETH per token, and nobody has paid anything for anything. That market cap is a notional number, price multiplied by supply, not a balance anyone can withdraw.

Every bit of WETH in the pool arrives from a buyer. The pool's WETH balance at any moment is what net buyers put in, minus what sellers have taken out, minus fees already harvested. That leads somewhere uncomfortable:

A price floor is not a value floor

Because the position has no liquidity below the launch tick, the quoted price cannot go below the floor. That sounds protective. It is not.

If buyers push a token up and then everyone sells, the WETH walks back out of the pool to whoever sold first. When the price returns to the floor tick, the pool holds approximately the whole supply again and approximately zero WETH. The quoted price is still exactly the floor. Your tokens still mark at the floor. But there is no WETH left to sell them into, so the price you can actually get is approximately nothing.

The money that went in did not vanish. It went to the people who sold before you. That is the whole mechanism, and it is why "the price cannot go below the floor" and "you can lose everything" are both true at the same time.

Most new tokens do exactly this. The base rate for memecoins going to approximately zero is high, and there is nothing in these contracts that changes it. Locked liquidity is a guarantee about who can remove the liquidity, not a guarantee that anyone will want to buy your bag.

What locked liquidity does not cover

The lock is real and it is permanent. See Locked liquidity for the detail. Here is what people wrongly read into it.

  • No team bag at launch does not mean no whale at block two. The creator holds no supply when the transaction confirms, but nothing stops them buying their own launch immediately, at the floor, with a bot, across as many wallets as they like. They can accumulate cheaply and sell into you later. That is not a rug in the technical sense and no contract prevents it.
  • A locked pool can still be abandoned. Permanent liquidity says nothing about whether the creator ever posts again after launch day.
  • Identical bytecode does not mean identical intent. Every token here behaves the same at the contract level. The social layer, the promises, the Telegram, the roadmap: none of that is on chain and none of it is enforced by anything.
  • Metadata is unverified. The name, image and links live inside the token URI and are typed in by whoever launched it. A token can call itself anything and link anywhere. Check the contract address, not the name.

The holders share goes to one address

A creator can carve out up to 20% of the swap fees as a community share. The split itself is enforced: if a token launched with 15% to community, exactly 15% of every harvest is credited to that share and no one can change it.

The chain does not pay holders

The community share is credited to a single recipient address that the creator typed into the launch form. There is no pro rata distribution to holders anywhere in these contracts. Whether that address ever passes anything on to holders, and on what terms, is a promise made by a person, not a rule enforced by code.

So read a "holders" share as "an address the creator nominated", because that is what it is on chain. Judge it accordingly.

The mechanics of harvesting and claiming are on Fees and rewards.

How to protect yourself

  1. Verify the token on the explorer
    Open the contract address on the explorer for chain 4663 and confirm it is a clone of the canonical implementation. If the bytecode is not that clone, none of the guarantees on this page apply to it. Anyone can deploy a token that merely looks like a Moonfiesta launch.
  2. Confirm the position is actually locked
    Check that the pool's position NFT is held by LpLocker. This is the claim that matters most and it takes one lookup.
  3. Read the split before you buy, not after
    The creator, protocol and community shares are fixed for that token forever. Read them on the token page or from the locker directly. A creator taking the maximum is not a scam, but it is a fact you should know before you are in.
  4. Use a slippage number you would say out loud
    If your slippage is 50%, you are saying you would knowingly pay double. Set something tight, let it revert, and try again. See How to trade.
  5. Check the anti snipe values on the token itself
    Read maxWalletBps and snipeEndTime on the token rather than assuming the defaults. They are frozen per token, and the factory defaults can be changed by the owner for new launches.
  6. Size it as money you can lose entirely
    Not "money I would rather not lose". Money whose complete loss changes nothing about your life. This is the only risk control on the list that always works, and it is the only one that does not depend on any of the contracts behaving as documented.
  7. Discount the hype to zero
    The person telling you it is early is telling you they are earlier. A locked pool and a fixed supply say nothing whatsoever about whether a token goes up.

Not financial advice

Nothing on this page or anywhere on this site is financial advice. Moonfiesta is unaudited software for launching and trading tokens on Robinhood Chain, chain 4663. Nobody here knows your circumstances, and no one is accountable for your trades except you.

If you have read this whole page and still want to trade, at least you are doing it with an accurate picture. That is the most this documentation can honestly offer.