Burning vs locking liquidity.

Published 2026-07-27 · HoodLock Team

Both remove the ability to pull liquidity. They differ in whether that removal is permanent, and the choice has consequences most teams don't think through until they need the option they gave away.

How this works on Robinhood Chain. Liquidity here lives in Uniswap v3 and v4 positions, which are NFTs rather than the ERC-20 "LP tokens" older chains use. HoodLock locks ERC-20 tokens, so it cannot hold one of those positions today — token locks, burns and vesting all work as described, but locking liquidity itself is not something we can do on this chain yet. The general explanation below still applies to how liquidity locking works elsewhere.

Side by side

	Burning LP	Locking LP
Duration	Forever	Until a date you choose
Reversible	No	After the unlock date
Can migrate to a new pool	No	Yes
Ongoing signal	One act	Extensions build a record
Cost of being wrong	Permanent	Wait for the date
Reads to holders as	Maximum commitment	Commitment with a horizon

The case for burning

Burning is unambiguous. There's no date to track, no extension to remember, no expiry conversation, and no possibility that a future version of the team decides differently. For a project whose pool configuration is settled and which wants to remove the question permanently, it's the cleanest answer available.

The case for locking

Locking preserves optionality that turns out to matter more often than teams expect:

DEX migrations. Exchanges deprecate pool versions. Burned liquidity can't follow.
Fee tier mistakes. A pool created at the wrong fee tier is a permanent problem if the LP is burned.
Consolidating fragmented liquidity across several pools into one deeper pool.
Building a track record. Each extension is a fresh, dated commitment. A burn happens once and then says nothing new.

Which to choose

A reasonable default: lock, and extend. It protects against the same exit, keeps the ability to fix mistakes, and produces an accumulating record that a one-time burn doesn't. Burning makes most sense for a settled project that has already run long locks and wants to close the question permanently — the decision reads very differently at year two than at launch.

What doesn't work is doing neither and explaining why. That's the only option holders actually penalise.

You can do both

These aren't exclusive. Burning a portion of LP while locking the rest gives a permanent floor plus a migratable remainder. Locking a large majority and burning a slice is a common shape, and both actions produce their own proof page — the combination is legible to anyone who checks.

Verifying either

A burn shows up as a null address in the LP token's holder list; a lock shows up as a locker contract. Both are checkable in the same place, and both get a permanent proof page on HoodLock. See how to check for a burn and how to check for a lock.

Common questions

Is burning liquidity better than locking it?

For preventing a rug pull, burning is stronger because nothing can ever be withdrawn. But it also permanently removes the ability to migrate pools or fix a misconfigured fee tier, and a one-time burn says nothing new after the day it happens.

Can I burn some liquidity and lock the rest?

Yes, and it is a common structure. Burning a portion creates a permanent floor while locking the remainder keeps the ability to migrate. Both actions produce their own proof page.

What happens if I burn LP and the DEX deprecates the pool?

The liquidity stays in the deprecated pool permanently. This is the most common reason teams regret burning — exchanges do deprecate pool versions, and burned LP cannot follow.

Which do holders prefer to see?

Either is far better than neither. Burning reads as maximum commitment; a long lock that has been extended repeatedly reads as ongoing commitment. The only option holders consistently penalise is doing neither.

Keep reading

Lock it, burn it, or both

Both produce a permanent proof page anyone can verify on Robinhood Chain.

Open HoodLock →