Security

Most ways people lose money on a launchpad aren't exotic hacks. They're ordinary powers written into the token contract on purpose: the creator mints more supply, freezes your wallet, turns off selling, or drains the pool.

This page goes through each of those, says whether Runitup's tokens can do it, and — since "trust us" isn't an answer — says why not.

What the scanner checks actually mean

If you've pasted a token into a tool like GoPlus Security or Quick Intel, you've seen this list. Here's what each item means for you as a holder.

What a launched token actually is

A Quick launch token is a completely standard ERC-20 with no custom logic at all. The entire contract is a constructor that creates the supply once, and then nothing. There is no other code in it.

An Advanced launch token is the same ERC-20 with one addition: support for a max-wallet cap, which launches from this site do not set today. It has no owner, but it does have a limit admin, the wallet that launched it, whose only powers are to loosen or lift a cap. The table below holds for both, with that one exception noted.

Max-wallet cap on Advanced launches

Not offered on the site today. The Advanced token contract supports a max-wallet cap, but the launch form does not offer one on any chain, so a token launched from this site never has one. A cap can only be set at launch, and a token launched without one can never be given one. This is how a cap behaves on a token that has one.

A cap limits how much of the supply one wallet may hold, between 0.1% and 99.99%, for a set time or until it is turned off.

• What it blocks. A buy or a transfer that would take the receiving wallet over the cap reverts. A scanner may report this as a transfer limit, and it is one.
• What it never blocks. Selling. The pool is exempt, so tokens can always be sent into it, whatever the size.
• Who is exempt. The pool and the launch's own contracts, the creator's wallet, the fee recipient, the platform treasury and the burn address. The creator can exempt more addresses but can never take an exemption away. The platform can exempt shared contracts such as routers.
• It can only be loosened. The limit admin can raise the cap, end it sooner or lift it for good. The contract refuses to lower it or extend it, and a token launched without a cap can never be given one.

The token page shows the cap while it is in force.

Uniswap V4 pools

V4 changes where a pool lives, not what your token is. The token contract is the same, so every answer in the table above is unchanged.

Two differences are worth stating because they are real:

• Every V4 pool lives inside one contract, the pool manager, rather than each pool being its own contract. That is a design choice by Uniswap, not something Runitup configures.
• Liquidity is locked the same way. The LP position is an NFT held by the same locker contract used for V3, which has no withdraw function. Same guarantee, same contract.

Tokens paired against tokenized stocks

A token can be paired against a tokenized equity rather than ETH. This is a real difference in risk and worth understanding before buying one.

What does not change. The launched token is the same contract, the fees are the same as on an ETH pair (a 1.00% pool fee on a v1 Quick launch, the hook's charge on a v2, Advanced or sniper-window launch), and liquidity is locked identically. Nothing in the table above moves.

What does change:

• You take on the quote asset's risk too. Your token's price is quoted in shares of that stock. If the stock moves, your token's dollar value moves with it even when the token itself has not traded.
• You need the quote asset to trade. The pool has no ETH side. Buying means holding the stock token first, which is a smaller pool of possible buyers than an ETH pair.
• The stock token is somebody else's contract. Runitup did not issue it and does not control it. Its own guarantees — redeemability, transfer restrictions, who can freeze it — are the issuer's, not ours. Check the issuer before you assume the peg holds.

What Runitup does check. A token can only be paired against an asset on a governed allowlist, set by the platform. That is deliberate: the starting price is derived from the quote asset's value, so a creator free to nominate any token could mint one they control, declare it worth anything, and open a pool at a market cap of their choosing. The allowlist is what stops that.

"Ownership renounced: N/A" is stronger than "Yes", not weaker

This one looks worse than it is, so it's worth spelling out.

Normally a token contract has an owner with special powers. A careful creator gives those powers up by calling renounceOwnership(), and scanners then report "Ownership renounced: Yes".

But that's an action someone has to actually take. Until they do, the owner still has every power the contract grants. And you're trusting that they did it, and that they did it before anything bad happened.

Runitup token contracts skip the whole problem: they never declare an owner in the first place. There's no button to press, nothing to verify anyone pressed, and no code path that could introduce an owner later. It isn't possible to deploy an owner-controlled version of these contracts, permanently, by design.

The nearest thing to an owner is the limit admin on an Advanced token, and it is not one: it can loosen or lift a max-wallet cap and do nothing else. On a token launched from this site there is no cap for it to loosen.

The honest caveat

That's about the token contract — the address you'd paste into a scanner. It is not a claim that the whole platform has no admin anywhere.

The surrounding infrastructure (LaunchConfig, FeeSplitter, LiquidityLocker) does have a platform owner, with narrow and specific powers: one-time wiring done at deploy, plus a support backstop that can reassign a creator's own fee-recipient address — for cases like a creator losing access to their wallet. On a taxed token the fee recipient also receives the Creator share of the tax, so the same backstop moves that share too. It cannot change the rates, the four-way split or anyone else's share.

What that admin cannot do: touch trader funds, mint tokens, pause trading, unlock liquidity, or change the mandatory fee split.

On a taxed token, the protocol also has three narrow roles in the tax hook: its guardian multisig can switch a pool's tax off (never on or up), the platform treasury or its keeper converts the tax's Liquidity and Burn shares in capped steps, and the platform's Safe multisig can point the Stakers share at a replacement staking vault. That change has no waiting period; it applies as soon as the multisig's transaction lands. None of them can raise a tax, change a creator's rates or split, or touch the locked liquidity.

Why "Honeypot: No" is guaranteed, not just tested

A honeypot usually works by making the sell tax effectively 100% — you can buy, and selling either fails or returns nothing.

On Runitup this is impossible rather than merely absent. The launched token has no fee-on-transfer and nothing that can refuse a sell. That is true of every launch type: the one transfer rule any of them can carry, an Advanced token's max-wallet cap (which the site does not offer today), limits what a wallet can receive and never applies to tokens going into the pool.

On a Quick launch there is simply no tax to raise. A v1 (pool fee) launch runs no hook on swaps, only the pool's fixed 1.00%, which belongs to the pool and not to the creator. A v2 (hook fee) launch's pool has no fee of its own; its hook charges a fixed 1%, which no one can ever raise. With a sniper window the hook charges 80% at the open, falling to 1% within at most 300 seconds, and never higher again.

On an Advanced launch the pool itself charges no fee; its hook charges a 1% standard fee and a tax, and the limits are written into the hook's code: at most 9% set by the creator plus the 1% standard fee, so 10% at the very most. No rate can ever be raised after launch, by anyone. The one exception to the cap is an optional sniper window, which starts at 80% and falls back to the normal rate within at most 300 seconds of the launch, and can never be restarted. A tax that high for good is not something the contracts can express.

When a scanner says "Honeypot: Yes" anyway

On Arc you may see this on DexScreener, in the "Quick Intel" box on a token's page:

Read the whole box, not the first line. A scanner decides "honeypot" by simulating a sell through the token's exchange. Quick Intel's simulator knows Uniswap V2 and V3 routers; it has no Uniswap V4 on any chain, and Arc is not among the chains its API lists. Every Runitup pool on Arc is a Uniswap V4 pool, so the simulated sell never runs. "Unknown" on both taxes is exactly what a simulation that never ran looks like, and their pipeline reports that as "Honeypot: Yes".

It is a limit of the scanner, not a property of the token, and it will show on every Arc token until Quick Intel adds V4 there. We have asked them to, and to correct the tokens already flagged. Until then, check it yourself; it takes two minutes and needs no tools:

1. Read the contract. Paste the token address into Sourcify. If that token is not verified there yet, look up the factory that created it instead — 0x5c1F5D1D… on Arc, source-verified — which deploys the same twenty-line ERC-20 for every launch: a constructor and nothing else. There is no code that could refuse or tax a sell.
2. Look for sells. Open the token on Arcscan and look at its transfers. Transfers into the pool manager (0x8366a39CC670B4001A1121B8F6A443A643e40951, Uniswap's own contract on Arc) are sells, and there will be some within minutes of any launch that has traded at all. A honeypot has none.
3. Check where the pool is. The token page's DexScreener link opens the pool on DexScreener under "Uniswap": it is listed there because it is an ordinary Uniswap pool that anyone's router can reach, which is the opposite of a market that only lets you in.

The first token launched on Arc's current contracts was flagged this way on its first hour, while four different wallets sold it on chain through two different routers, all successfully. That is the pattern to expect: the box says one thing, the chain says another, and the chain is the one you can verify.

"Closed source" is the same story. Other scanners (Serialized Audit, for one) rate the same tokens Safe but label them "closed source". They read source from the chain's block explorer, and Arc's explorers do not carry verified source for launched tokens: the Etherscan-style one never indexes a contract created inside another contract's transaction, which is how every token here is born. The source is verified on Sourcify instead, the open verification service explorers themselves import from, and it is the same twenty lines for every token. A scanner that cannot see it decompiles the bytecode and reaches the same verdict, which is what "Safe, closed source" means.

Warnings a scanner shows on a coin it rates Safe

Scanners that read the source, Serialized Audit for one, rate Runitup coins Safe and then list a few "warnings worth knowing". On Robinhood Chain the token, its factory and its hook are source-verified on robin.etherscan.io and on Sourcify, so a scanner reads the real code and usually labels a new coin "Open source" or "Identical bytecode": every launch of the same type is the same contract.

The warnings describe what the pool's hook is able to do, not what has happened to a particular coin, so a coin can show one for a feature its creator never used. Here is what each one refers to.

None of these can stop you selling, take tokens out of your wallet or raise a fee after launch. Those are the things a honeypot needs, and the section above explains why the contracts cannot express them.

Liquidity is locked permanently

Once a pool exists — which is immediately at launch, for every token — the position holding its liquidity is moved into a locking contract.

That contract has no withdraw function. No unlock. No transfer. Not time-locked, not multisig-guarded — the functions do not exist. There is no code path that removes liquidity, for anyone, ever, including Runitup.

The only two things anybody can ever do with a locked position:

1. Collect its trading fees — permissionless, anyone can trigger it, and the proceeds split 75 / 25 as described in Fees. A hooked pool (taxed or sniper-window) has no LP fee, so there is nothing in it to collect; its hook pays out instead.
2. Add more liquidity to it — also permissionless. It can get deeper, never shallower.

This is what "rug pull" usually means, and it's the specific thing these contracts are built to make impossible.

Liquidity lock names the contract holding it, lists every function it has, and walks through checking any token's position yourself on the explorer — two contract reads, no Solidity required. Worth doing rather than believing this paragraph.

What this page does not protect you from

Being honest about the boundaries, because a security page that only lists reassurances isn't one:

• The price can still go to zero. Locked liquidity guarantees you can always sell. It says nothing about what you'll get.
• The creator can sell their own tokens. Nothing stops them, and a dev buy at launch means they may hold a lot. The token page's Top holders tab shows what the creator holds right now and what the top ten hold between them — current figures, not a launch-day snapshot. Check both before you buy.
• The quote asset's own risk. A stock-paired token inherits whatever happens to that stock, and to the contract that tokenizes it.
• The venue's own contracts are third-party. Uniswap's and SushiSwap's code is not ours, and a pool lives inside it. That is the same trust anyone trading on those venues already accepts.
• A taxed token's creator is an outside party. The platform does not control who launches an Advanced token. The contracts cap what the tax can do, but within those caps the creator decides the rate and where the money goes, and on a dynamic launch can move the split with 24 hours' notice. Their dev buy also happens before any sniper window opens, at the opening price. Read the token page's Tax info before you buy.