How to Lock Liquidity for Your ERC-20 Token (Step-by-Step)

You have deployed your token, paired it with ETH on Uniswap, and now there is a live trading market. But there is a problem that every experienced trader will notice within seconds of looking at your project: nothing stops you, the deployer, from walking into that pool and pulling every dollar of liquidity out. That single action would leave holders with tokens they cannot sell at any price. It is the most common exit scam in crypto, and locking liquidity is the primary way honest projects prove they will not do it.

This guide explains what liquidity locking actually is at the mechanical level, why LP tokens are the thing you lock, which real lockers to use, how the process differs between Uniswap V2 and V3, and exactly how to lock step by step. It also covers the parts most tutorials skip: how to read someone else's lock on Etherscan so you are not fooled by a fake, how long you should realistically lock for, and how locking fits alongside contract verification and ownership renouncement. If you are still at the planning stage and want to create an ERC-20 token before you get here, do that first, then come back for the liquidity step.

What Is Liquidity Locking?

Liquidity locking is the act of depositing your liquidity provider (LP) tokens into a time-locked smart contract that will not release them back to you until a date you choose in advance. During that window, you cannot withdraw the underlying liquidity from the trading pool. Anyone in the world can inspect the lock on-chain and confirm the exact amount locked and the exact unlock timestamp.

The key idea is that locking does not change how the token trades, how much liquidity is in the pool, or the price. It changes one thing only: who can remove that liquidity, and when. Before locking, the deployer holds the LP tokens and can burn the pool for its underlying ETH and tokens at any moment. After locking, the LP tokens sit inside a third-party locker contract that mechanically refuses to give them back before the unlock time. Even the deployer cannot override it.

That is the entire value proposition. Locking converts a promise ("I won't rug you") into an enforceable, publicly verifiable constraint. It is one of the few trust signals in decentralized finance that does not require anyone to take your word for anything, because the guarantee is enforced by code that both you and your holders can read.

LP Tokens and Why Locking Them Matters

To understand why you lock LP tokens specifically, you have to understand what they represent. When you add liquidity to a decentralized exchange, you deposit two assets into a pool: your token and a pairing asset, usually ETH or a stablecoin like USDC. In return, the exchange gives you a receipt that proves you own a share of that pool. That receipt is the LP token.

On Uniswap V2 and its many forks (SushiSwap, PancakeSwap on other chains, and countless others), the LP token is itself a fungible ERC-20 token. If you deposited liquidity that represents 100% of a brand-new pool, you receive LP tokens representing that full 100% share. Whoever holds those LP tokens can call the removeLiquidity function and withdraw the underlying ETH and tokens, in proportion to their share, at any time.

This is the crux of the risk. The pool contract does not care who you are. It only checks whether you hold the LP tokens that entitle you to withdraw. So if the deployer holds all the LP tokens, the deployer can drain the entire pool in a single transaction. The tokens holders bought become worthless because there is no longer anything backing them on the other side of the trade.

Locking solves this by moving the LP tokens out of the deployer's control. Once the LP tokens live inside a locker contract with a future unlock date, the removeLiquidity call can only succeed after that date, and only for the wallet the locker recognizes as the beneficiary. Until then, the liquidity is effectively frozen in place, supporting the market. That is why the object you lock is never the token itself and never the raw ETH, but always the LP tokens, because the LP tokens are the key that unlocks the vault.

The Rug-Pull Trust Problem It Solves

A rug pull is when a project's operators remove the liquidity backing their token, converting holders' investments into unsellable dust and walking away with the ETH. The name comes from pulling the rug out from under buyers. It remains one of the most common forms of loss in permissionless token markets precisely because deploying a token and seeding a pool is so easy, and because nothing structurally prevents the operator from reversing the second step.

Here is the sequence a classic liquidity rug follows. The team deploys a token, adds liquidity on Uniswap, and promotes the project. Buyers arrive and swap ETH for the token, which pushes the token price up and, importantly, deposits their ETH into the pool. At the peak of buying interest, the operator calls removeLiquidity, withdrawing all the ETH (including everything buyers just added) plus the paired tokens. The pool is now empty, the price chart drops to zero, and holders are left with tokens no one can buy.

Locking liquidity directly neutralizes this specific attack. If the LP tokens are locked for, say, twelve months, the operator physically cannot execute the removeLiquidity drain during that window. Buyers can verify this before they buy. That is why "liquidity locked" has become a baseline expectation for any token that wants to be taken seriously, and why a project without a lock (or without a burned pool, which we cover later) is treated as guilty until proven innocent.

One honest caveat worth stating plainly: a liquidity lock is not a guarantee that a project is safe. It only prevents the liquidity-removal rug for the duration of the lock. It does not prevent a malicious token contract with a hidden mint function, a transfer tax that can be raised to block selling, or a blacklist that freezes specific wallets. This is exactly why locking must be paired with a verified, honest contract, a point we return to at the end. Locking is necessary, not sufficient.

Where to Lock: The Main Liquidity Lockers

You do not build your own locker. You use an established, audited locker service that thousands of projects have used before you, because a lock is only as trustworthy as the contract holding it. Using a well-known locker also means traders recognize the lock immediately, which is half the point. Below are the main options on Ethereum, described neutrally with their real tradeoffs.

UNCX Network (formerly Unicrypt)

UNCX is one of the oldest and most widely recognized liquidity lockers in the space. It supports Uniswap V2 and V3 positions across Ethereum and many other chains, and it is the lock that a large share of traders instinctively trust because they have seen it so many times. Pros: strong brand recognition, broad chain and version support, a clean interface that generates a shareable lock page. Cons: it charges a fee (a small percentage of the liquidity or a flat ETH fee depending on options), and its familiarity makes it a target that scammers try to visually imitate, so you must reach it from the official domain.

Team Finance

Team Finance is another long-standing locker offering both liquidity locks and team token vesting. It is popular for projects that want a single dashboard for both their LP lock and their team allocation vesting schedules. Pros: mature platform, handles both LP locks and token vesting, multi-chain. Cons: fees apply, and like any hosted tool the interface is a layer between you and the underlying contract, so you should still verify the resulting lock on-chain rather than trusting the dashboard alone.

PinkLock (PinkSale)

PinkLock is the locking component of the PinkSale launchpad ecosystem, heavily used by projects that ran a presale through PinkSale. If you are launching via a presale, locking through the same ecosystem is convenient and keeps everything in one flow. Pros: tight integration with the PinkSale launchpad, familiar to presale participants, supports V2 and V3. Cons: most associated with the meme and micro-cap launch scene, which is a double-edged sign depending on your audience, and fees apply.

Mudra Locker

Mudra is a locker known for a low-cost or free tier for basic liquidity locks, which makes it attractive to smaller projects watching every dollar of gas and fees. Pros: budget-friendly, straightforward for simple LP locks. Cons: less brand recognition than UNCX or Team Finance, so some traders may be less immediately reassured by it, and you should scrutinize exactly which contract your lock ends up in.

Whichever you choose, the non-negotiable rule is to reach the locker only through its official, verified domain, ideally one you found from the project's official documentation or a reputable aggregator, never from a link dropped in a Telegram chat. Fake locker front-ends that steal your LP tokens are a real and recurring scam. When you are done, the locker gives you a public lock page and an on-chain record; both should match what you intended.

How Locking Differs on Uniswap V2 vs V3

This is the single most misunderstood part of liquidity locking, and getting it wrong wastes gas or leaves you thinking you locked something you did not. The two major Uniswap versions represent liquidity in fundamentally different ways.

Uniswap V2: fungible ERC-20 LP tokens

On Uniswap V2 (and its forks), adding liquidity mints a standard fungible ERC-20 LP token to your wallet. Every LP token in a given pool is identical and interchangeable. Locking is conceptually simple: you approve the locker to move your LP tokens, then you deposit a quantity of them into the locker with an unlock date. Because the LP token is fungible, you can lock 100% of it, or 80% and keep 20% liquid, or split it across several locks with staggered unlock dates. The mental model is "lock this many of these fungible receipts."

Uniswap V3: non-fungible position NFTs

Uniswap V3 changed the model completely. Instead of a fungible LP token, each liquidity position is a unique NFT (an ERC-721 token) with its own token ID. That NFT encodes your specific position: the price range you chose (V3 uses concentrated liquidity, so you provide liquidity between a lower and upper price bound), the amount deposited, and the fees accrued. You do not lock "an amount" of a fungible token; you lock a specific position NFT by its token ID.

This has practical consequences. First, you lock the whole position NFT as a single unit, not a fraction of a fungible balance, so if you want a partial lock you must mint two separate positions. Second, the locker has to support V3 position NFTs specifically, because locking an ERC-721 is a different operation than locking an ERC-20; not every V2 locker supports V3. Third, V3 concentrated positions can drift entirely out of range if the price moves outside your chosen band, at which point the position holds only one of the two assets and provides no active liquidity, so a locked V3 position is not automatically the same ongoing protection a full-range V2 lock provides. Many projects deliberately choose a full-range V3 position (or simply use V2) specifically to make the lock's protection unambiguous. If you are still deciding where to provide liquidity in the first place, our companion guide on how to list an ERC-20 token on Uniswap V3 walks through the pool-creation side of this decision.

Step-by-Step: How to Lock Your LP Tokens

Here is the full walkthrough for a standard Uniswap V2-style liquidity lock, which is the most common case. The V3 flow is similar but you select a position by NFT token ID instead of entering an amount. Do this only after you have added liquidity and confirmed the LP tokens (or position NFT) are in your wallet.

Step 1: Confirm your LP tokens are in your wallet

After adding liquidity on Uniswap, the LP tokens are minted to the wallet that performed the deposit. On V2 you may need to import the LP token's contract address into MetaMask to see the balance, since it is not on any default token list. On V3, open the Uniswap positions page or your NFT collection and note the position's token ID. You cannot lock what you cannot see, so verify the balance or NFT is present first.

Step 2: Open the official locker interface and connect

Navigate to your chosen locker (UNCX, Team Finance, PinkLock, or Mudra) using its verified official URL. Connect the same MetaMask wallet that holds the LP tokens. Confirm the network shown matches the network your pool is on (Ethereum mainnet for a mainnet pool). The connection only reads your address; it cannot move anything without a transaction you sign.

Step 3: Select the pair and enter the LP token address

The locker will ask for the liquidity pair or the LP token contract address. Paste the LP token address (V2) or select the position NFT by its token ID (V3). The interface should auto-detect the pair, for example YOURTOKEN / ETH, and show the amount of LP tokens in your wallet. Double-check that the detected pair is exactly the one you intend to lock. Locking the wrong pair is a real mistake people make when they hold several LP positions.

Step 4: Set the amount and unlock date

Enter how many LP tokens to lock. For maximum trust, projects typically lock 100% of the initial liquidity, though some lock a large majority and keep a small liquid buffer for planned migrations. Then set the unlock date. This is the timestamp before which nothing can be withdrawn. Choose deliberately, because you cannot shorten it later. Confirm the beneficiary address (the wallet that will be able to claim after unlock) is correct, usually your own project wallet or a multi-sig.

Step 5: Approve, then lock

Locking an ERC-20 LP token takes two transactions. First, an "approve" transaction that authorizes the locker contract to move your LP tokens (this is the same ERC-20 approval pattern used everywhere in DeFi). Second, the "lock" transaction that actually transfers the LP tokens into the locker and records the unlock date. Both cost gas. Confirm each in MetaMask, reading the details before signing. For a V3 NFT, the approval is an ERC-721 approval for the specific token ID instead.

Step 6: Save your lock page and record everything

Once the lock transaction confirms, the locker generates a public lock record, usually a shareable URL and an on-chain event. Save the lock ID, the lock page URL, the LP token address, the locked amount, the unlock date, and the transaction hash. This is the evidence you will show your community. Publish the lock link in your official channels and pin it, because "trust us, it's locked" without a verifiable link is worth nothing.

How Long to Lock and Vesting Schedules

There is no universal correct lock duration, but there are sensible norms and clear tradeoffs. The lock length is a signal, and the market reads it as a proxy for how long you intend to be around.

Short locks of one to three months read as "we are testing the waters" and inspire limited confidence; sophisticated buyers will note the unlock date and may plan to exit before it. Locks of six to twelve months are a common middle ground for legitimate projects that want to demonstrate real commitment without permanently forfeiting the ability to migrate liquidity later (for example, to a new pool version or a different DEX). Multi-year locks signal strong long-term intent and are common for projects that want to remove liquidity-removal risk from the conversation entirely.

Instead of a single cliff unlock, many lockers support vesting-style liquidity locks that release the LP tokens gradually over time, for example a portion each month after an initial cliff. Gradual release avoids the "unlock day cliff," where an entire lock expires at once and the market braces for a possible dump. A smooth vesting schedule can be reassuring because there is never a single moment when all liquidity becomes withdrawable. If your locker supports it, staggering unlocks (several locks with different dates, or a linear vest) is often a better trust signal than one large lock with a single expiry.

Whatever you choose, be transparent about it up front. State the lock duration and schedule in your documentation before launch, not after someone asks. A clearly communicated twelve-month lock beats a vaguely described "long lock" every time, because the specificity itself is a credibility signal.

How to Verify a Lock On-Chain (Yours or Someone Else's)

Being able to independently verify a liquidity lock, without trusting any website's claim, is one of the most valuable skills you can have in this space, both for proving your own honesty and for vetting other projects. A screenshot of a lock page proves nothing; screenshots are trivially faked. The blockchain is the source of truth.

Method 1: Read the LP token's holders on Etherscan

Every V2 LP token is an ERC-20 with its own contract address on Etherscan. Open that address, go to the "Holders" tab, and look at where the LP tokens actually sit. If the liquidity is genuinely locked, a large share of the LP token supply will be held by a known locker contract (UNCX, Team Finance, and so on), not by the deployer's wallet. If most LP tokens sit in an ordinary externally-owned wallet, the liquidity is not locked, regardless of what any marketing page says. If they sit in the burn address, the liquidity is burned (see the next section).

Method 2: Inspect the locker contract's records

Locker contracts expose their lock records on-chain. On the locker's public lock page you can find the lock ID; cross-reference it against the locker contract on Etherscan by reading its stored data, or follow the transaction that created the lock to confirm the LP amount and the unlock timestamp are real. The unlock date is stored as a Unix timestamp; convert it and confirm it matches the claimed duration. This is how you catch a "locked" project whose real unlock date is next week.

Method 3: Follow the lock creation transaction

Every legitimate lock has a transaction hash that created it. Open that transaction on Etherscan and read the token transfers: you should see the LP tokens moving from the deployer into the locker contract. The event logs typically encode the amount and the unlock time. If someone claims a lock but cannot produce a transaction hash that shows LP tokens entering a recognized locker, treat the claim as false.

For your own project, do all of this yourself after locking and publish the direct Etherscan links, not just the locker's marketing page. Making verification easy for others is itself a trust signal, and it inoculates you against the accusation that your lock is fake.

Burning LP Tokens vs Locking LP Tokens

There are two ways to remove the liquidity-rug risk, and they are meaningfully different. Locking freezes the LP tokens temporarily; burning destroys them permanently.

Burning LP tokens means sending them to a dead address (commonly the zero address or a known burn address) from which no one can ever retrieve them. Because the LP tokens are gone forever, no one can ever call removeLiquidity, so the underlying liquidity is permanently trapped in the pool. This is the strongest possible commitment: the liquidity can never be removed by anyone, including you, ever. Traders sometimes prefer burned liquidity over locked liquidity because there is no unlock date to worry about at all.

The tradeoff is total irreversibility. If you burn the LP tokens, you permanently give up the ability to migrate that liquidity, for example to move to a new DEX version, to consolidate pools, or to respond to a future protocol change. You also forfeit the trading fees that would otherwise accrue to those LP tokens, because you no longer hold the position that earns them. For a small meme-style project that will never migrate, burning is a clean and maximally trustworthy choice. For a project that expects to evolve its infrastructure, a long lock preserves optionality while still protecting holders.

A useful way to frame it: burning maximizes trust at the total cost of flexibility, while locking balances trust against the ability to manage liquidity responsibly in the future. Both are legitimate. What is not legitimate is doing neither and asking holders to trust you anyway. If you go the burn route, verify it the same way you verify a lock: confirm on Etherscan that the LP tokens actually landed in the burn address and are no longer in any spendable wallet.

Common Mistakes and Scams to Avoid

Locking is simple in principle but has several failure modes that catch people out, and the space around it is full of scams that specifically prey on the locking process. Here are the ones worth internalizing.

• Fake locker websites. Scammers clone the front-end of UNCX or Team Finance and trick you into approving a malicious contract that drains your LP tokens instead of locking them. Only ever reach a locker through its verified official domain, and read every MetaMask approval to confirm the contract you are approving is the real locker.
• Locking the wrong token. People sometimes lock their own project token instead of the LP token. Locking the raw token does nothing to protect liquidity; only locking the LP token (or V3 position NFT) prevents the pool from being drained. Confirm you selected the pair, not the token.
• Locking a trivial amount. A lock page showing "liquidity locked" means little if only 5% of the LP tokens are locked and the deployer still holds 95% liquid. Always check the locked percentage against total LP supply, not just the fact that a lock exists.
• A very short unlock date dressed up as a lock. A "lock" that unlocks in three days is technically a lock and practically meaningless. This is a favorite trick: announce a lock, let buyers assume it is long, and quietly set a near-term unlock. Always read the actual unlock timestamp on-chain.
• Trusting a screenshot. Never accept an image of a lock as proof. Verify the lock on Etherscan yourself using the methods above. Images are free to fabricate.
• Ignoring the token contract itself. A locked pool does not stop a malicious contract with a hidden mint, an adjustable transfer tax that can be set to 100% to block selling, or a wallet blacklist. Locking liquidity and shipping a dangerous contract is a common bait-and-switch. Locking must sit on top of an honest, verified contract, which is why our ERC-20 smart contract security best practices guide is required reading alongside this one.
• Locking before verifying the pool is correct. Lock only after you have confirmed the pool is the right pair at the right price with the right amount of liquidity. Once locked, you cannot rearrange it until unlock.

If you are combining a lock with a fundraising round, the same caution applies to the presale mechanics; our guide to running a token presale covers how locking typically slots into an ICO or IDO flow so buyers know their contributed liquidity is protected from day one.

How Locking Pairs With Verification and Ownership Renouncement

Liquidity locking is one leg of a three-legged trust stool. On its own it protects against exactly one attack. Paired with the other two signals, it becomes part of a genuinely credible security posture that serious traders look for as a set.

Contract verification is the first companion signal. A verified contract on Etherscan means the full source code is published and matches the deployed bytecode, so anyone can read exactly what the token does. Locked liquidity behind an unverified contract is a contradiction: you have proven you will not pull liquidity, but you are still asking holders to trust that the token itself has no hidden traps. Verify the contract so the code is auditable, then the lock has something honest to sit on top of.

Ownership renouncement is the second companion signal. Many token contracts have an owner address with special powers: minting new tokens, pausing transfers, adjusting fees. As long as those powers exist, holders must trust the owner not to abuse them, which partially undercuts the reassurance of a lock. Renouncing ownership sets the owner to a dead address, permanently disabling those privileged functions. For a project that has finished all owner-only setup, renouncing removes a whole category of risk. Our detailed walkthrough on how to renounce contract ownership explains when it makes sense and when keeping certain controls (behind a multi-sig) is the more responsible choice.

The order that works well in practice is: deploy an honest contract, verify it on Etherscan, add liquidity, lock (or burn) the LP tokens, then renounce ownership once no further privileged actions are needed. Do those in sequence and you have addressed the three questions every careful buyer asks: can I read the code, can the owner rug the token logic, and can the team drain the pool. If you have not built your token yet, the whole sequence starts at the deployment step, and you can use an ERC-20 token creator that gives you a clean OpenZeppelin-based contract, which makes every subsequent trust step easier to complete honestly.

FAQ

Locking liquidity is not a marketing checkbox. It is a concrete, verifiable commitment that removes the single most common exit-scam vector from your project and lets careful buyers participate without taking your honesty on faith. Choose a reputable locker, lock a meaningful share for a meaningful duration, and publish the on-chain proof so anyone can check it themselves.

If you have not launched yet, get the foundation right first. You can create your own ERC-20 token with a clean, verifiable OpenZeppelin-based contract in minutes, then move through liquidity, locking, and renouncement as a deliberate sequence. Do it in that order and you will have built something a serious market can actually trust.