When people research a new token on Base, "liquidity locked" is one of the phrases that comes up most often as a reassurance. It is a real, checkable signal, not marketing language, but it only tells you one specific thing about a token, and it is easy to misread. This article covers what a liquidity lock actually does, how to verify one yourself, and what it does not protect you from.
What liquidity actually is, in this context
When a token trades on a decentralized exchange like Uniswap or Aerodrome, its price comes from a liquidity pool: a smart contract holding a pair of assets, for example the token and ETH. Whoever funds that pool receives LP (liquidity provider) tokens representing their share of it. Anyone holding those LP tokens can redeem them at any time, which pulls their share of both assets out of the pool.
That last part matters. If a project's own team holds most of the LP tokens for a new pool, they can remove that liquidity whenever they want, all at once, leaving buyers holding a token with no way to sell it at a real price. This is the mechanism behind most liquidity rug pulls, covered in more detail in our guide to rug pulls and liquidity scams.
What a liquidity lock does
A liquidity lock addresses this specific risk. Instead of holding the LP tokens directly, the project sends them to a smart contract, either a dedicated locker service such as UNCX Network or Team Finance, or a self-deployed timelock contract, that holds the tokens and refuses to release them until a set date. Until that date passes, nobody, including the project team, can withdraw the underlying liquidity.
Locks are visible on-chain. The lock contract's address holds the LP tokens, and its unlock date is a public value anyone can read. This is what makes a lock a genuine signal rather than a claim you have to take on trust: you are not relying on the team's word, you are reading a contract.
Locking versus burning
There are two common ways teams demonstrate they cannot pull liquidity:
- Locking sends the LP tokens to a timelock contract with a fixed unlock date. After that date, the liquidity becomes withdrawable again by whoever controls the lock.
- Burning sends the LP tokens to an address with no known private key, most commonly
0x000000000000000000000000000000000000dEaD. Burned LP tokens can never be redeemed by anyone, which makes this the stronger of the two guarantees, but also permanent: the team gives up any future ability to manage that liquidity themselves.
Locking is more common for projects that want to reclaim or migrate liquidity later on. Burning is more common for projects trying to signal maximum commitment upfront.
How to check a lock yourself
You do not need to trust a project's claim that liquidity is locked. You can verify it directly:
- Find the LP token holders. Look up the token's trading pair on BaseScan and open the LP token contract for that pool. The "Holders" tab shows every address holding LP tokens and what share each one controls.
- Check who holds the majority. If a large share sits at the known burn address, that portion is permanently burned. If it sits at a contract address rather than a personal wallet, that is likely a locker contract.
- Confirm the lock on the locker's own site. Services like UNCX Network and Team Finance publish a lookup page where you can paste the token or pool address and see the exact unlock date, the amount locked, and the percentage of total LP supply that covers.
- Compare the locked or burned amount to total supply. A lock covering 40% of LP tokens leaves the remaining 60% freely withdrawable. What matters is the share that is actually secured, not just the fact that a lock exists somewhere.
What a liquidity lock does not protect against
A lock only restricts one specific action: withdrawing pooled liquidity before the unlock date. It says nothing about the token contract itself. A locked pool can still sit behind a token with:
- A mint function that lets the owner create unlimited new supply and sell it into the pool
- Transfer restrictions or high sell taxes, the kind of behavior covered in our piece on fee-on-transfer tokens and honeypots
- Blacklist or pause functions that block specific wallets from selling
- Ownership that has not been renounced, leaving privileged functions active
A lock is also only as good as its expiry date and the locker contract behind it. Short locks, sometimes just a few days, are sometimes used specifically so a project can point to "locked liquidity" during a launch window and then withdraw shortly after. Reading the actual unlock date, not just the presence of a lock, is the part people most often skip.
Where this fits into research
A liquidity lock is a useful, verifiable data point, but it is one input among several. It works best alongside checking whether the contract is verified, reviewing token approvals before interacting with anything new, and following the broader checklist in how to research a token before you swap it. None of these checks are a guarantee. Together, they give you a much clearer picture than any single signal on its own.