Checklist
How to check a crypto project before you trust it
The Verifier’s Checklist · Published
If you have been burned by a project before, you do not need another recommendation. You need to know what to check, and how to check it without taking anyone’s word for it — including ours.
These are ten questions. Each comes with the steps to answer it using a browser and a block explorer. None of them requires you to trust the project, and none of them requires you to trust us.
Four rules before you start
Rule 1
When the marketing page and the audit disagree, the audit wins.
A security page is written to reassure you. An audit report is written to be relied on. Where they differ, believe the document with the auditor's name on it.
Rule 2
Every question comes with its steps.
Most take under five minutes with nothing but a browser and a block explorer. Where one takes longer, it says so. If you cannot check a claim, it has not been shown to you.
Rule 3
Scope every claim.
“Audited” and “renounced” are almost never true of a whole system. Ask which contract, which file, which date. A project is many contracts, and each one answers for itself.
Rule 4
Say what you could not check.
Anything you could not verify belongs on your list too, in plain sight. An unanswered question is information, not a pass.
The ten questions
In order: the early questions tell you whether the later ones are worth asking.
- Q02 minutes
Is this the project’s actual site?
Lookalike domains are the cheapest attack in crypto, and the first one used on newcomers. Everything else on this list is worthless if you are reading the wrong page.
How to check
- Start from somewhere you already trust: the project’s documentation, its long-standing social accounts, or its token’s page on the block explorer.
- Follow the link from there to the site. Navigate to the marketing site from the documentation, never the other way round.
- If the project uses several domains, check that each one is linked from an official source, not just from the others.
A bad answer looks like
You cannot reach the site from any official source, or you arrived by a link someone sent you directly.
- Q12 minutes
Is there an audit report, or only a badge?
A logo is not an audit. Anyone can put an auditor’s name on a page; only a real engagement produces a report.
How to check
- Click the auditor’s logo or name on the project’s security page.
- You should reach a downloadable report, or the auditor’s own page for this project with a report attached.
- If you land on a monitoring dashboard or a “security score,” look for the report itself on it. A dashboard can show an audit in progress, which is honest, but it is not a finished report.
A bad answer looks like
The badge links to the auditor’s homepage, to a score, or to nothing — and the page still says the project is audited.
- Q23 minutes (longer to match deployed code)
What was actually in scope?
An audit covers the code it was given, at the moment it was given. If you cannot tell what that was, you cannot tell whether it is the code you are about to use.
How to check
- Open the report’s first pages. A real report names the files reviewed, the dates of the review, and usually a commit hash and file hashes.
- Read the list of files. Ask whether the contracts you will actually touch — staking, deposits, withdrawals — are in it.
- Going further: if the code on the block explorer is verified, its source should match the audited commit. This takes longer, and most people stop at the previous step.
A bad answer looks like
No file list, no dates, no commit — or a list that covers only the token while the page implies the whole system was reviewed.
- Q34 minutes
What did the audit find, and what is still unfixed?
“0 critical” is the line projects quote. The status column is the line that matters.
How to check
- Find the table of findings in the report.
- Read the Status column, not just the Severity column.
- Anything marked Partially Fixed or Acknowledged is still open, whatever the summary says. Read those findings in full.
A bad answer looks like
The project cites the headline count and stops. An open centralization finding is a normal outcome; hiding it is the warning sign.
- Q44 minutes
Who can change things, and how fast?
Every system has someone who can change its settings. What matters is who, and whether you get any warning before a change lands.
How to check
- Search the audit for centralization, privileged, owner, governance and timelock.
- Note which addresses can change fees, rates, treasury destinations or allow-lists.
- Look for a timelock: a delay between a change being scheduled and taking effect, so people can see it coming.
A bad answer looks like
A single address can change economic settings with no timelock, so changes take effect the moment they are made.
- Q53 minutes
Can new tokens be created?
Minting is not automatically bad — some systems create tokens by design. The questions are who can trigger it, how much, and whether the project tells you.
How to check
- Search the audit for mint, minting and MINTER_ROLE.
- On the block explorer, open the contract’s verified source and search for the same words.
- Find out who holds the ability to mint, and whether there is a limit.
A bad answer looks like
An unlimited mint function exists, and the project’s own page says there is “no minting capability.”
- Q63 minutes per contract
Is ownership actually renounced — contract by contract?
“Ownership renounced” is often said of a project when it is true of one contract. Check each one you will use.
How to check
- On the block explorer, open the contract and go to Contract, then Read Contract, then owner().
- The zero address (0x0000…0000) or the burn address (0x…dEaD) means no one holds the owner key. Anything else is an owner.
- If there is an owner, open that address. If it has no contract code, it is a single private key. If it is a contract, find out what kind — a multisig shows how many signers must approve.
A bad answer looks like
The page says ownership is renounced, and one of the project’s contracts still has a live owner — especially a single wallet.
- Q75 minutes
Does the marketing page agree with the audit?
This is the question the others build towards. A project that describes itself accurately has nothing to lose from it.
How to check
- Pick the three strongest claims on the project’s security page — usually about audits, keys and minting.
- Find each one in the audit report, or check it on-chain using Q5 and Q6.
- Note any claim written in the present tense that the audit describes as planned, partial or future.
A bad answer looks like
They contradict. Then the first rule applies: the audit wins.
- Q85 minutes
When a project publishes transaction hashes, do the numbers add up?
Publishing hashes is not the same as the hashes agreeing. It is a genuinely good sign when a project does it — and it only counts if the amounts reconcile.
How to check
- Open each published transaction on the block explorer and note the token transfers: from, to, amount.
- Add up what left the treasury and compare it with what arrived where the announcement says it went.
- If there is a difference, look at the balance of the address in the middle. Money sitting there is accounted for; money that moved on needs explaining.
A bad answer looks like
The hashes are real but the amounts do not tie out, or a difference is left unexplained.
- Q910 minutes — the one step that needs a node call
Is the contract upgradeable, and if so, who can upgrade it?
An upgradeable contract can have its logic replaced after you have deposited into it. That is common and often responsible — it is how teams fix bugs — but the key that does it is the most important key in the system.
How to check
- On the block explorer, a Read as Proxy or Write as Proxy tab means the contract is an upgradeable proxy. Its absence is not proof: an unverified proxy may not show it.
- Find the admin. For the standard pattern it is stored in slot 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103, readable with eth_getStorageAt on any public node.
- If the admin is itself a contract (often called a ProxyAdmin), read its owner().
- Open that owner on the explorer. A multisig or a timelock is one answer; an address with no contract code is one private key.
A bad answer looks like
The core contracts are upgradeable, the upgrade key traces to a single wallet, and the project says its contracts are “immutable” or have “no admin keys.” Renounced ownership on the token says nothing about its proxies.
What this checklist does not do
- It does not tell you whether a project will succeed, or what anything will be worth.
- It does not tell you whether a team is honest. It tells you whether what they say matches what you can check.
- It does not catch everything. Auditors say plainly that their reports are not complete, and neither is this.
- It does not tell you what to buy. It is a method for asking better questions, and the decision stays yours.
Our interest, stated
TOBB advocates for the POTS ecosystem. That is a reason to be more careful with us, not less. Run this checklist on POTS, and hold our own claims to it — every one of them is listed, with its source, in the public claims register.
No project is scored on this page. When we publish a scored example, it comes with the project’s response, and it leads with what checked out as well as what did not.
Walk through it with us
Bring a project you are weighing to a free session and we will work through these questions with you, step by step, on its real contracts and documents. We teach the method. We do not tell you what to buy.
Two modules of our free course cover this ground in depth: how to check a protocol’s security claims, and how to tell whether its governance is real.
Educational content only — nothing here is financial advice. Decentralized systems carry market and technical risk. TOBB never asks you to connect a wallet, share a seed phrase, or approve a transaction. Verify before you interact.