Start with what a liquidity pool actually is
When a token launches into a pool (say, paired against ETH on Uniswap), someone deposits both assets together. In return, they receive a claim on that pool, on Uniswap V2 this is a fungible LP token, on V3 and V4 it's an NFT representing a specific price-range position. Whoever holds that claim can redeem it at any time for their share of whatever's currently in the pool. That's the entire mechanism a rug pull exploits: the creator holds the claim, and cashes it in.
"Locking" means removing the ability to redeem that claim
There are meaningfully different ways to do this, and they are not interchangeable:
Burning
The LP token or position NFT gets sent to a dead address nobody controls (like 0x000...dead). Nobody can ever redeem it again, including the creator. Simple to verify: anyone can look up that address's holdings. The tradeoff: any future swap-fee income tied to that position is destroyed along with it, gone forever, not paid to anyone.
Third-party time-lock
The LP position is deposited into a separate locker contract that holds it until a set unlock time. This is genuinely locked until that timer expires, at which point it behaves like a normal, withdrawable position again. Worth checking the actual unlock date, a "locked" pool that unlocks next week is a very different promise than one locked for a year.
Structurally locked (no withdraw function)
The strongest form: the position lives in a contract that was written with no function capable of moving it out, ever. Not "locked until," not "locked unless an admin key," genuinely locked because the code path to unlock it doesn't exist in the deployed bytecode. This is how ScanHood's own launchpad locks every launch, verified two ways: the launch factory must recognize the token, and the position NFT must actually sit in the locker contract's address, not just be claimed to.
How to tell which one you're actually looking at
Don't take a label at face value. For any pool, look up who (or what) actually holds the LP position on-chain. If it's a dead address, that's burned. If it's a contract, check whether that contract's code has a withdraw function at all, that's the real test, not what the project's marketing page calls it. ScanHood's /scanner does exactly this check automatically for its own launches and flags a majority-EOA-held pool as a real risk.
Frequently asked
Is burned liquidity safer than locked liquidity?
They solve the exact same problem (the creator can't pull the pool) equally well, once genuinely burned or structurally locked. The difference isn't safety, it's what happens to future fee income: burning destroys it, structural locking preserves it for whoever the contract designates. Neither is more "safe" than the other in the rug-prevention sense.
How long should a time-lock last to be meaningful?
There's no universal answer, but a lock measured in days offers very little real protection since it will unlock while the token is still new and thin. Longer locks (months to years) are more meaningful, and always worth checking the actual unlock date rather than trusting the word "locked" alone.
Can a multisig-held LP position be considered locked?
Not in the same sense. A multisig can still withdraw the position if enough signers agree, it's a trust and coordination barrier, not a structural impossibility. It's meaningfully safer than a single wallet holding it, but it's a different category from a contract with no withdraw function at all.
Does ScanHood verify this for every token, or just its own launches?
ScanHood verifies its own launchpad tokens with certainty (checking both the factory record and the actual position holder). For tokens from other locked-LP launchpads, it checks against a maintained allowlist. For anything else, it falls back to a heuristic (LP holder concentration), which is a real signal but not the same strength of proof.