When a team adds liquidity to a pool, they receive a claim on that liquidity — an LP token for a V2 pool, or a position NFT for a concentrated V3 or V4 position. Whoever holds that claim can withdraw the underlying liquidity. A liquidity lock takes that claim and time-locks it in a contract, so the liquidity cannot be pulled until the lock expires.

This matters because pulling liquidity is the mechanism behind a rug pull: the team removes the pool, the price collapses to near zero, and holders are left with tokens they cannot sell into anything. A genuine lock removes that lever for the duration of the lock. It is not a guarantee of a good project, but it is one of the clearest, most verifiable safety signals a team can offer.

The reason it carries weight is that it is checkable. Unlike a promise in a whitepaper or a pinned message in a chat, a lock is on-chain state that anyone can read independently. That is also why the rest of this guide focuses as much on how to verify a lock as on what a lock is — the value of a lock is only as good as your ability to confirm it for yourself.

The point of a lock is that anyone can check it, and you do not need to connect a wallet to look. Verification is read-only: you are reading public on-chain state, not signing anything. On Base and BNB Smart Chain you can verify a Sally lock in two ways.

The first is to resolve a lock by its lock id through the public, CORS-open lock API, which returns the lock's details as data you can read or pull into your own tooling. Because the API is CORS-open, you can call it straight from a browser or a script without a backend of your own, which makes it easy to build your own checks or dashboards on top of it. The second is to view a lock-proof card, a human-readable summary of the same on-chain facts for people who just want to look rather than integrate.

In both cases you start from the lock id, which the project should publish alongside their other links. Either path reads the same underlying chain state, so a project cannot show you a flattering card while the API tells a different story — the two are views onto one source of truth. You are checking the chain, not taking the team's word for it.

A lock-proof card surfaces the facts that actually answer "is this safe to trust?" rather than a simple yes/no badge. For a given lock id you can see:

What gets locked depends on how the liquidity was provided. A classic V2-style pool issues fungible LP tokens, so a lock secures those LP tokens. A concentrated liquidity position on Uniswap V3 or V4 is instead represented by a position NFT, so the lock secures that NFT.

The distinction matters when you read a proof. Concentrated positions cover a chosen price range rather than the whole curve, which is why a meaningful TVL figure is not always available for them — Sally reports TVL where it can and is explicit when it cannot, rather than inventing a number. The owner, tokens, locked value, share of pool and unlock time remain verifiable in both cases.

If you are the project, a lock you cannot easily show is a lock that does not build much trust. Sally lets you embed a lock-proof card directly on your own site, so visitors see the live, on-chain status of your lock without leaving your page or needing a wallet.

Because the card reads the same public data anyone can verify independently, it is proof rather than a claim. Put it on your landing page next to your other trust signals, and prospective holders can confirm the lock and watch the unlock countdown for themselves.

This is the difference between saying "liquidity is locked" and showing it. A static badge or a screenshot can be faked; a live card backed by the on-chain lock cannot, because anyone who doubts it can resolve the same lock id themselves. For a new project trying to earn trust quickly, a verifiable lock card on the homepage does more work than any amount of assurance in prose.

A lock answers one question — can the liquidity be pulled right now — and it answers it well. It does not tell you whether the token itself is honest. A project can lock liquidity and still ship a token you cannot sell, or one whose owner can raise the sell tax toward confiscation.

So treat proof-of-lock as one layer, not the whole picture. Before you buy, also run the token through Sally's honeypot checker to confirm you can actually sell and to read the tax, ownership and proxy signals. A locked pool plus a clean sell simulation is a much stronger position than either on its own.