How to prove you won't rug — without asking.

Published 2026-07-27 · HoodLock Team

Every project says it won't rug. The ones people believe don't say it. They make it structurally impossible and publish the link. That's the whole difference, and it's available to any team willing to give something up.

Why saying it doesn't work

The claim "we won't rug" carries exactly as much weight coming from a serious team as from a scam, because both say it and neither can be distinguished by the statement. Anything you say, a scam can say. Only what you give up separates you, and giving something up is verifiable in a way that words aren't.

The four commitments, in order of weight

1. Lock the liquidity. Removes the fastest exit. This is the baseline; without it nothing else you do gets read charitably.
2. Vest the team allocation. Removes the second-fastest exit and says something about time horizon that a lock can't.
3. Verify the contract source. Makes every claim about the token checkable. Free, and its absence is treated as an answer.
4. Give up powers you don't need. Every owner-only function is something you're asking to be trusted with. Keep only what you can explain.

The order matters because each one is read in light of the previous. Verified source on a token with unlocked liquidity doesn't reassure anyone; verified source on a token with locked LP and vested team supply completes a picture.

Make the commitments legible

A commitment nobody can find isn't doing any work. Three practical rules:

Link, don't claim. "Liquidity is locked" invites a follow-up question. A proof page link ends it.
Put the links where the question gets asked — pinned in the community, in the site footer, in the launch announcement. Not buried in a docs site.
Use links that stay valid. A proof page that reads live from the chain keeps being true; a screenshot stops being evidence the moment anything changes.

The part most teams skip

Commitments decay. An LP lock that made sense at launch becomes a countdown as the unlock date approaches, and a team that says nothing as it nears is read as planning an exit, usually unfairly, but the silence is the problem. Extend before the date, not after. On HoodLock unlock times can only be pushed further out, so an extension is permanent and public, and a track record of extensions is something no new project can fabricate.

What you're actually buying

None of this makes a project succeed. What it does is remove your project from the default category — the one where people assume the worst because most launches deserve it. You're not proving you're good; you're proving you're not the specific bad thing everyone is scanning for, which is what lets anyone evaluate the rest on its merits.

Start with the launch checklist if you haven't deployed, or lock liquidity now if you have.

Common questions

How can a project prove it won't rug pull?

By making it structurally impossible rather than promising it: lock the liquidity, vest the team allocation, verify the contract source, and give up owner powers that aren't needed. Then publish the proof links instead of the claims.

Is saying 'the team is doxxed' enough?

It helps, but it doesn't remove any technical ability to withdraw liquidity or dump a team allocation. Verifiable on-chain commitments and identity address different risks, and the on-chain ones are the ones people check first.

What's the single most important commitment?

Locking liquidity. It removes the fastest and most common exit, and without it the other commitments tend not to be read charitably — verified source on a token with unlocked liquidity reassures nobody.

Should I renounce contract ownership?

Not automatically. Renouncing removes privileged functions but also removes the ability to fix bugs. What matters more is keeping only the powers you can justify and being explicit about which ones exist and who holds them.

Keep reading

Replace the claim with a link

Lock liquidity, vest the team allocation, and publish proof pages anyone can read.

Lock tokens →