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.
- 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
claimon FeeVault yourself and no admin can move what you are owed.
The defaults a launch uses today, all readable on the factory:
The code is unaudited
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
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:
setAntiSnipetakes 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 auint32holds. 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.setSplitcan move the protocol fee share, though it is capped in code at 40% byPROTOCOL_BPS_CAP. That is the one owner power with a real ceiling.setFeescan change the launch fee and the buy and burn contribution, with no cap.setPayoutAddressescan 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.
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.
- 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:
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:
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.
How to protect yourself
- Verify the token on the explorerOpen 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.
- Confirm the position is actually lockedCheck that the pool's position NFT is held by LpLocker. This is the claim that matters most and it takes one lookup.
- Read the split before you buy, not afterThe 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.
- Use a slippage number you would say out loudIf 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.
- Check the anti snipe values on the token itselfRead
maxWalletBpsandsnipeEndTimeon 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. - Size it as money you can lose entirelyNot "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.
- Discount the hype to zeroThe 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.