The rug it's meant to prevent
A classic liquidity rug: a creator launches a token, pairs it with real ETH in a pool, waits for buyers, then calls a function that pulls their share of the pool straight back into their wallet. The token's price collapses to near zero in one transaction, and there's nothing anyone holding the token can do about it. This is the single most common way new tokens go to zero on purpose.
What "locked" has to mean to actually stop this
Locking liquidity means the ability to withdraw that pool position is removed, provably, on-chain, not promised. There are three real approaches, and they are not equivalent:
| Method | How it works | Can it be undone? |
|---|---|---|
| Burned | LP tokens sent to a dead address (0x000...dead) | No, but future fee income is also destroyed |
| Time-locked (3rd party) | LP tokens held by a locker contract with a timer | Not until the timer expires, then yes |
| Structurally locked | Position held by a contract with no withdraw function in its code at all | Never, there is no code path that moves it |
| "Locked" (unverified claim) | Team says it's locked, may be a multisig or a promise | Often, yes |
The difference between the third and fourth rows is the entire point. A contract with no withdraw function can't be rugged no matter who controls it, because the function to do it doesn't exist in the deployed bytecode. A "locked" label with no on-chain proof is just marketing until you check.
How ScanHood's own launchpad does it
Every ScanHood launch path (bonding curve, direct V3, direct V4) mints its liquidity position straight into a locker contract that has no withdraw function anywhere in its code. This is checked, not assumed: ScanHood's scanner independently verifies two things on-chain before calling a token "locked": the launch factory must recognize the token as one of its own launches, and the position NFT must actually be held by the locker contract, matching what the factory claims.
How to verify it yourself, for any launchpad
Frequently asked
Does locked liquidity mean the token is a safe buy?
No. Locked liquidity removes one specific failure mode, the creator pulling the pool. It says nothing about honeypot mechanics, tax hooks, deployer history, or whether anyone will ever want to buy the token from you. Always check the full scan, not just the lock status.
Is burned liquidity better or worse than locked?
Different tradeoff. Burning is simpler to verify (anyone can check the dead address) but destroys the pool's fee income forever. Locking (done right, with no withdraw path) is equally un-ruggable while letting fees keep flowing to whoever the contract designates. Neither is inherently "better", they solve the same problem differently.
Can a locker contract be upgraded to add a withdraw function later?
Only if it's an upgradeable (proxy) contract, which defeats the entire point of locking. A genuinely non-upgradeable locker's code is fixed forever at deploy time, there's no admin key that can add a new function to it later. Check whether the locker itself is a proxy before trusting a "locked" claim long-term.
What's the difference between a locked pool and a locked token?
A locked pool means the trading liquidity can't be pulled. A separate concept, token supply locks or vesting, controls whether a large holder (usually the team) can dump their own token balance on the market. ScanHood's launch template has no team allocation at all on most paths, so this second risk often doesn't apply, but it's worth checking independently for any token.