A liquidity lock places the LP tokens representing ownership of a pool into a time-locked contract, so the person who created the pool cannot withdraw it until the lock expires. It is the standard defence against the most common rug pull, where a creator seeds a pool, waits for buyers, then removes the liquidity and leaves holders with tokens nobody can sell. A lock is not permanent and it is not the same as burning — the liquidity comes back to its owner when the timer runs out, which makes the expiry date as important as the lock itself.
Key Facts
- LP tokens are a receipt proving ownership of a share of a pool. Whoever holds them can withdraw that share.
- A lock deposits those LP tokens in a contract that releases them only after a set date.
- Locked is temporary. Burned is permanent. They are frequently described interchangeably and should not be.
- A lock with a 30-day timer is a 30-day delay on a rug pull, not a prevention of one.
- Partial locks are common — a creator can lock 60% of LP tokens and hold the rest freely.
- Pump.fun graduations burn LP tokens outright, so graduated tokens skip this problem entirely.
- A lock does nothing about token supply concentration, which is a separate risk.
What Is Being Locked
When someone deposits SOL and tokens into a pool, they receive LP tokens in return — a claim on their share of whatever is inside. Those LP tokens are the withdrawal key. Anyone holding them can redeem them and take the underlying assets out, which is why the depth you see in a pool is only as reliable as the question of who controls the LP tokens for it.
A lock takes those LP tokens out of the creator’s wallet and puts them in a contract programmed to hold them until a date. During that period, the pool cannot be drained by its owner, because the receipt is inaccessible. After that date, it can be — the contract releases the LP tokens back and everything returns to how it was before.
Locked, Burned, or Neither
| Unlocked | Locked | Burned | |
|---|---|---|---|
| Who can withdraw the pool | The LP holder, anytime | Nobody until expiry | Nobody, ever |
| Reversible | N/A | Yes, at expiry | No |
| Rug risk at liquidity layer | High | Deferred | Eliminated |
| What to check | Nothing — assume the worst | Expiry date and percentage locked | That the burn actually happened |
| Typical use | New manual pools | Projects wanting flexibility | Launchpad graduations |
The middle column is where most confusion lives. “Liquidity locked” in a project’s announcement sounds like a permanent guarantee and almost never is. The two follow-up questions are what percentage was locked and until when — a 70% lock expiring in three weeks means 30% can leave immediately and the remainder in under a month. Burning the LP tokens is the version with no follow-up questions.
How to Verify a Lock Yourself
Start on DEXScreener, which flags pool status on most Solana pairs and will show whether liquidity is marked locked or burned. Treat that as a starting point rather than proof, then confirm on-chain: find the pool’s LP mint on Solscan and look at where those LP tokens actually sit. Held in a known locker contract with a visible unlock timestamp is a real lock. Sitting in an ordinary wallet is not, regardless of what any announcement claims.
Two traps to watch. Partial locks are reported as “locked” by interfaces that do not show the percentage, so check how much of the LP supply is actually in the locker. And a lock says nothing about token supply — a creator with locked liquidity and 25% of the token supply in their wallet can still collapse the price by selling tokens, without touching the pool at all. That is a different failure mode from a classic liquidity rug and needs its own check.
Why Locks Exist at All
If burning is strictly safer for holders, the obvious question is why anyone locks instead. The honest answer is flexibility: a project that may need to migrate liquidity to a different AMM, adjust a pool’s parameters, or restructure later cannot do any of that with burned LP tokens. For a protocol with genuine reasons to manage its own liquidity, a lock is a reasonable compromise. For a memecoin with no roadmap requiring it, the flexibility is mostly optionality for the creator, and it is fair to ask what they intend to do with it.
Where $DOLAN Sits on This
DOLAN Duck ($DOLAN) fair launched with a fixed 98.3M supply across roughly 10,700 holders, which means the relevant checks are the standard ones rather than anything special: whether the LP tokens for its pool are burned or locked, and whether any single wallet holds enough supply to matter independently of the pool. Both take under a minute on an explorer and both should be redone periodically, not once — a lock that was comfortable six months ago may be expiring now. The general lesson from this whole topic is narrow and useful: “liquidity locked” is a claim with a date attached, and the date is the part that determines whether it means anything today.
A liquidity lock puts the LP tokens representing pool ownership into a time-locked contract, preventing the creator from withdrawing the pool until the lock expires.
No. A lock is temporary and releases the LP tokens back to their owner at expiry. Burning destroys the LP tokens permanently, so the liquidity can never be withdrawn by anyone.
The LP tokens return to whoever locked them, and they can withdraw the pool at any time afterwards. That is why the expiry date matters as much as the existence of the lock.
Find the pool’s LP mint on an explorer and check where the LP tokens are held. In a recognised locker contract with a visible unlock timestamp is real; sitting in an ordinary wallet is not.
No. A lock only protects the pool. A creator holding a large share of the token supply can still collapse the price by selling tokens into that pool without touching the liquidity at all.
Yes, and it is common. A creator can lock 60% of LP tokens and keep the rest freely withdrawable, while announcements still describe the liquidity as locked. Always check the percentage.
Flexibility. Burned liquidity cannot be migrated to another AMM or restructured later. That matters for protocols with real roadmaps and is mostly optionality for the creator on a plain memecoin.