Key takeaways
- A liquidity pool described as having locked liquidity was drained of roughly $14 million.
- Locking liquidity prevents exactly one thing: the deployer withdrawing the pooled funds themselves.
- It does nothing about mint functions, owner privileges, upgradeable contract logic, transfer restrictions or a vulnerability in any connected contract.
- Lock duration and who holds the lock are part of the claim and are frequently omitted when the phrase is used as a selling point.
- An audit describes the code as written, including deliberate administrative powers — it is not a statement that those powers are safe to grant.
A liquidity pool advertised as having locked liquidity was drained of around $14 million. The locking was real. It simply protects against something other than what happened.
This gap matters because "liquidity locked" has become shorthand for safe, and it is one of the narrowest guarantees in the entire sector.
What locking actually does
When a token launches on a decentralised exchange, someone deposits both sides of the pair — the new token and something established — and receives liquidity provider tokens representing that deposit. Those LP tokens can be redeemed for the underlying funds.
So whoever holds the LP tokens can withdraw the pool. If that is the deployer, they can remove the established asset at any moment, leaving holders with a token that cannot be sold for anything. That is the classic exit, and it is what locking was invented to prevent.
Locking means sending the LP tokens to a contract that will not release them until a set date, or burning them so nobody can ever redeem them. Verifiable on-chain, genuinely useful, and the protection is complete against that one specific action.
Everything it does not cover
Here is the part that gets collapsed into a single phrase, and each item has emptied pools.
A mint function. If the contract allows new tokens to be created, the deployer does not need the pool's LP tokens. They mint a large supply and sell it into the pool, taking the established asset out through the front door. The liquidity stays locked the entire time.
Owner privileges. Contracts frequently retain administrative functions: pausing transfers, blacklisting addresses, adjusting a transaction fee. A fee that can be set to an arbitrary level is a mechanism for taking the value of every trade, and it is a single transaction away.
Upgradeable logic. Where a contract sits behind a proxy, the code governing it can be replaced. Everything you verified about its behaviour describes the implementation in place when you looked, not the one that will be there tomorrow.
Transfer restrictions. A token can be written so that buying succeeds and selling fails for anyone outside a permitted list. The pool holds funds, the chart looks normal, and the exit does not exist.
A vulnerability somewhere else. Composability means a pool interacts with other contracts — oracles, routers, lending markets, vaults. A flaw in any of those can be used to extract value from the pool without touching the lock at all.
The parts of the claim people omit
Even taken on its own terms, the phrase usually arrives incomplete.
Locked for how long. A lock expiring in thirty days is a countdown rather than a commitment, and the date is published. Locked where, and under whose control — a lock held by a contract the deployer can modify is not a lock. And locked in what proportion, because a small percentage of liquidity locked while the rest stays withdrawable satisfies the wording and none of the intent.
All of this is checkable on-chain in a few minutes. The reason it so often is not checked is that the phrase does the reassuring before anyone gets to the detail.
Why an audit does not close the gap
Audited is the other word that gets used as a synonym for safe, and it means something more specific.
An audit reviews code for flaws against what it is intended to do. If a contract deliberately grants its owner the power to mint tokens or set a fee without limit, a competent audit documents that power. It is a finding, not a defect, because the code does what it was written to do.
So a report can note extensive owner privileges and the project can still describe itself as audited, entirely accurately. The reports are usually published, and the sections that matter most are the ones about centralisation and privileged functions.
The useful way to read a safety claim
Treat each claim as covering exactly what it says and nothing adjacent.
Liquidity locked means the deployer cannot withdraw the pool for a stated period. It does not mean the supply is fixed, the contract is immutable, the owner has no special powers, selling is possible, or the surrounding protocols are sound. Those are five separate questions with five separate answers, and all of them are published somewhere.
The honest summary is that these claims are not lies. They are narrow truths doing much broader work than they can carry, and the distance between the two is where the fourteen million went.
Education, not investment advice.
Frequently asked questions
What does locked liquidity actually mean?
The liquidity provider tokens representing a pool deposit have been sent to a time-locked contract or burned, so whoever deployed the token cannot redeem them and withdraw the pooled funds. It is verifiable on-chain and it protects completely against that one action.
How can a pool be drained if the liquidity is locked?
Several ways that never touch the lock. A mint function lets new tokens be created and sold into the pool. Owner privileges can set fees or restrict transfers. Upgradeable contracts can have their logic replaced. And a vulnerability in a connected contract can extract value from outside.
Does a mint function matter that much?
It is among the most consequential things to check. If supply can be increased, the pool can be emptied by selling newly created tokens into it, and the locked liquidity simply sits there while that happens.
What should I check about a lock itself?
How long it runs, who or what holds it and whether that can be modified, and what proportion of total liquidity is actually locked. A short expiry, a lock the deployer controls, or a small locked percentage all satisfy the phrase while defeating its purpose.
Doesn't an audit cover this?
An audit reviews code against its intent. Deliberate owner powers, such as minting or setting fees, are documented as findings rather than flaws, because the code does what it was written to do. A project can be accurately described as audited while retaining extensive privileges — which is why the centralisation section of the report is the part to read.
Is any of this verifiable without technical skill?
A fair amount. Contract verification status, owner address, whether a proxy is in use, lock duration and locked proportion are visible through block explorers and common analysis tools. It is a few minutes of looking rather than an audit.
Not financial advice. Crypto assets are volatile and unregulated in many jurisdictions. In India, gains are taxed at 30% with 1% TDS on transfers. Do your own research and never invest money you cannot afford to lose.
Editorial note: Crypto Shakti uses an AI-assisted research and drafting workflow. Every article is grounded in the linked primary sources and live market data captured at publication time.