“Liquidity locked” is the two most reassuring words in a token launch, and among the least examined. The phrase implies a guarantee: the team cannot pull the rug, because the rug is bolted to the floor. But a lock is only as strong as its implementation, and implementations fail in ways their authors rarely test — not before deployment, when everything looks fine, but after, under the specific conditions an adversary will go looking for.
We looked at how locks behave in production rather than in the announcement. Seven patterns recur often enough to name. None of them require the lock to be “fake.” In most cases the lock is entirely real — it simply does not protect the thing the holder assumed it protected.
A lock answers the question “can they remove the liquidity?” It does not answer “can they make the liquidity worthless by other means?” Most failures live in that gap.
1. The owner-withdraw backdoor
The lock contract holds the LP tokens, but exposes an emergencyWithdraw or owner-only recovery function “in case something goes wrong.” Something always goes wrong. A lock with an escape hatch is not a lock; it is a delay with good branding. Read the locker's functions, not just its balance.
2. The partial lock
The announcement says liquidity is locked. It does not say what fraction. Locking 30% of the LP supply while the remaining 70% sits in a deployer wallet satisfies the headline and none of the protection. Always reconcile the locked amount against total LP supply — the percentage is the whole story.
3. The silent expiry
A lock has a duration, and durations end. A token that proudly locked liquidity “at launch” for thirty days is unlocked on day thirty-one, usually without an announcement. The lock was real; the protection had a clock on it that nobody re-read. The unlock timestamp matters more than the existence of the lock.
4. The wrong-token lock
This one is almost elegant. The team locks the token itself — not the LP token that represents the pooled liquidity. Locking the asset that the deployer holds in their own wallet protects nothing about the pool that holders trade against. It looks like a lock on a block explorer and functions as theatre.
5. The owned locker
The LP tokens are genuinely locked — inside a locker contract that is itself upgradeable or owner-controlled. The protection is only as trustworthy as the contract holding it, and a locker whose logic can be swapped by a single address has merely moved the backdoor one level up. Verify the locker, not just the lock.
6. The re-add dilution
After locking the original liquidity, the team adds new, unlocked liquidity to the same pool. The locked position becomes a shrinking share of a growing pool, and the unlocked portion can be withdrawn at will. The lock holds; its share of the truth does not.
7. The theatre lock
The most common of all: liquidity is locked, perfectly and honestly, while the mint authority remains open. Why drain a pool when you can dilute the supply into it? An open mint() turns a locked pool into an exit ramp — the holder watches the liquidity stay put while their share of it is inflated away. A lock without a renounced mint is a lock on the wrong door.
What the pattern teaches
Across all seven, the failure is the same shape: the lock is verified, the surrounding power is not. In the GhostScore model, liquidity signals feed the Liquidity and Security pillars together, precisely because a lock cannot be scored in isolation from the mint authority, the locker's ownership, and the holder distribution around it. The lesson for anyone evaluating a token is simpler still: do not ask whether liquidity is locked. Ask what the team can still do with the rules intact.