How to Verify a Lock on Monad

For the person on the other side of the claim — the analyst, the listing desk, the DAO reviewer, the buyer sent a screenshot and told it settles the matter. This page does not tell you how to lock anything. It tells you how to check whether someone else did.

Why is “liquidity is locked” a claim rather than evidence?

Because the sentence describes a state of the world without pointing at the record that would prove it, and on-chain records are the only thing in this market that cannot be edited after the fact. A team saying its liquidity is locked is making an assertion of the same class as saying its treasury is multisig-controlled or its audit is clean. Each may be true. None is self-verifying.

Most failures here were preceded by a truthful-sounding claim: the lock covered 4% of supply, or expired eleven days ago, or held a different token. Verification is not distrust; it is the cheapest diligence in this stack.

What does independent verification mean on Monad?

Independent verification means reaching the same conclusion the claimant reached, from public data, without their cooperation and without any artifact they produced. If your evidence chain passes through something the team gave you — a screenshot, a link they chose, a message in a channel they administer — it is not independent, and the claim is only as strong as your trust in them.

On Monad the public data lives on MonadVision, the chain’s block explorer. Monad has been live on mainnet since November 24, 2025, and everything relevant to a lock — which contract holds a balance, when it moved, how supply is distributed — is readable there by anyone.

How do you verify a lock without being handed a contract address to trust?

You start from the token contract and work outward through its holders, the only starting point a claimant cannot forge. The usual shortcut is a team handing over an address and saying the lock is here — and an address supplied by the party being audited proves nothing until you confirm independently that it holds what they say.

The inference runs in one direction. Establish the token contract first, from a source outside the team’s control — a market data application such as <a href="https://thecrypto.app" target="_blank" rel="noopener noreferrer">The Crypto App</a>, or an exchange listing — because a wrong token at the root makes every later step worthless. Then read that contract’s holder distribution on MonadVision: a real lock appears as a contract address holding a material share of supply, funded by a transfer from the wallet the team named, with no outbound transfers since. Inspect that contract for what it holds and whether its unlock timestamp is in the future. Only at the end do you compare your findings with what you were told.

How do you verify a nad.fun graduate’s liquidity, and why is it a different check?

You verify that the protocol locked it, not that the team did — a nad.fun graduate never held the LP tokens, so there is no team-side lock to look for and its absence is not a red flag. nad.fun states the mechanism in its own documentation: “The initial protocol-provided liquidity is locked through its LP tokens, and the LP fees earned by this locked liquidity stay in the pool and help deepen liquidity over time.” Graduation occurs when “the bonding curve has gathered around 225,000 MON and approximately 80% of the token supply has been sold”.

So the check changes shape: confirm the token graduated rather than still sitting on the curve, that liquidity migrated to an on-chain pool, and that the LP position sits with the protocol rather than a team wallet. Do not read no third-party lock record exists as evidence of anything — for this cohort it is the expected result. A graduate claiming to have locked their own LP is describing something that could not have happened, and that discrepancy is itself a finding. Your attention belongs on what the curve never touched — team allocation, treasury, advisor grants — and after nad.fun graduation: what’s already locked and what isn’t sets out where those sit.

How do you verify a team token lock or a vesting schedule?

The check is the same shape as a liquidity lock with two extra fields: percentage of total supply, and a release curve rather than a single date. For a single-date lock, read the locked balance, the unlock timestamp and the source wallet, then express the balance as a share of total supply — the absolute number is nearly meaningless alone. For a schedule, read the beneficiary, cliff date, release term and amount already claimed, then plot the next twelve months of releases against traded depth.

Team token locks on Monad and how to set up token vesting on Monad describe how these are constructed; vesting schedules for Monad projects covers cliff sizing, the variable you are auditing when you read someone else’s.

What does a genuine lock record show that a screenshot cannot?

A genuine record shows a balance held by a contract, a timestamp written on-chain, and a transfer history — three facts that agree with each other and that nobody can revise. A screenshot shows pixels; a Telegram message shows that someone typed something. Neither has the property that makes on-chain proof worth anything: the claimant cannot change it after you read it, and cannot have changed it before.

Treat a supplied image as a pointer; its diagnostic value is when it disagrees with the chain. A real lock also issues an on-chain certificate, useful because it traces back to the same record rather than standing in for it. When a team resists giving you enough detail to run the check yourself, that reluctance is data.

Which details fool people most often?

Five: coverage, duration, token identity, expiry and the next cliff — each survives a careless glance and fails a deliberate one.

Coverage. A lock on a trivial fraction of supply reads identically to a comprehensive one in any announcement. Convert to a percentage of total supply, then ask what share of the project-held position it represents.

Duration dressed as permanence. A ninety-day lock and a three-year lock look the same in a headline. Read the unlock timestamp as a date, and be alert to locked with no term attached — permanence is a specific claim, and a lock with an unlock date is not it.

The wrong token. Tickers are not unique, and a lock on a contract other than the one being traded is defeated by establishing the token independently first.

An expiry that already passed. Locks are often described in the present tense long after they lapsed. Compare the unlock timestamp with today’s date, not the announcement’s date.

A cliff landing next week. A schedule can be genuine, published, and about to release a tranche the market has not priced. Read the next release date and size before forming a view.

What can you not learn from the chain?

Whether the counterparty is honest about anything the lock does not cover — and that boundary is the most important thing on this page. A verified lock establishes that a specific balance sits in a specific contract until a specific date. It says nothing about the remaining supply, the mint authority, undisclosed wallets or future conduct. Verification narrows uncertainty; it does not remove it.

Two limits are Monad-specific. Kuru carries roughly 71.7% of Monad DEX volume as of September 2026 and is a central-limit orderbook rather than an AMM, so market-making there mints no LP tokens — an absent LP lock on a token quoted mainly on an orderbook is not a finding. And with chain TVL at $957.23M as of September 2026 concentrated in lending and yield venues, against nad.fun’s $411,668, the question that usually matters here is the cap table rather than the pool. How to lock liquidity on Monad and how to lock LP tokens on Monad cover the claimant’s side.

How do you run the check, start to finish?

Five steps, in order, because each depends on the last.

1. Establish the token contract independently. Identify the token from a source outside the claimant’s control, so a similar ticker or a substituted contract cannot invalidate everything you check afterwards.
2. Read the holder distribution on MonadVision. Look for a contract address holding a material share of supply, funded by a transfer from the wallet the team named, with no outbound transfers since.
3. Read the terms from the holding contract. Confirm the locked balance, the unlock timestamp or release schedule and the beneficiary, then convert the balance to a percentage of total supply.
4. Test the four failure modes. Check coverage, duration, token identity and expiry against today’s date, and for a schedule, the size and date of the next release.
5. Compare with what you were told. Reconcile your findings against the claim, treat any discrepancy as the start of a conversation rather than the end of one, and record what the lock does not cover.

If the two agree, you hold a verified fact rather than a repeated assertion.

FAQ

Can a screenshot prove a lock? No. A screenshot shows pixels rather than a balance held by a contract, and it can be produced or altered by the party making the claim. Use it as a pointer to what you check on-chain, never as the evidence.

Do I need a contract address to verify a lock on Monad? No. Start from the token contract and read its holder distribution on MonadVision — a real lock appears as a contract holding a material share of supply, funded by the wallet the team named, with no outbound transfers since. An address supplied by the party being audited proves nothing on its own.

Why is there no third-party lock record for a nad.fun graduate? Because nad.fun locks the protocol-provided liquidity through its LP tokens at graduation, so the team never held them. For that cohort, the absence of a team-side lock record is the expected result, not a red flag.

Next steps: what nad.fun already locked · lock a team allocation · lock liquidity · back to the Monad hub