How to Check a DeFi Protocol Before You Deposit: An 8-Point On-Chain Audit

Short answer: You do not need to read Solidity or Move to tell a serious protocol from a dangerous one. Eight questions, answerable from public on-chain data in about twenty minutes, separate almost all of them. None of them is "has it been audited".

A note on who is writing this. We run a multi-chain protocol. We have not passed every check on this list at every moment in our history, and we have published our own depeg post-mortem with the transactions rather than describing someone else's. A checklist from someone who has only ever been on the right side of it is a marketing page.

"Audited" is a statement about one day in the past. All eight checks below are statements about right now.

Before the eight: are you even on the real site?

This guide is about evaluating a genuine protocol. A different and larger category of loss comes from protocols that were never real, or from a real protocol's fake front end. Those have their own tells and we cover them separately — see fake wallet scams and wallet drainers and approval phishing.

Two rules prevent most of it: reach dapps from a bookmark you created yourself, never from a search ad or a DM, and treat any request to sign a token approval you did not initiate as hostile.

Everything below assumes you are on the real thing, and asks whether the real thing is safe.

1. Who can upgrade the contracts?

The single highest-value check. Most DeFi contracts are upgradeable. Whoever holds the upgrade authority can, in principle, replace the logic holding your deposit.

How: open the contract in the chain's explorer, find the owner / admin / upgrade authority, and look at what kind of account it is.

Bad answer: a single externally-owned account. Your deposit's security is now one private key's security.

Good answer: a multisig with a real threshold.

The follow-up most people skip: a multisig is only as independent as its signers. A 3-of-5 where three of the keys live in the same keystore on the same laptop is a 1-of-1 in a costume. You usually cannot verify this from outside — which is why a protocol that publishes its signer topology is telling you something meaningful.

2. Are the "locked" permissions actually locked?

Protocols often describe privileged capabilities as burned, renounced or soulbound. Verify it rather than believing it.

How: check whether the privileged capability object or role can be transferred, and whether any public function re-exposes the privileged action.

Bad answer: a capability described as non-transferable that has a public wrapper function calling straight through to it. The label is then decorative. This is a genuinely common pattern and it is easy to miss, because the documentation and the bytecode disagree and only one of them is enforced.

Renounced ownership is a property of the code, not of the announcement. If a public function can still reach the privileged path, nothing was renounced.

3. Is the deployed code the code you are reading?

Protocols upgrade. Explorers, docs and repositories go stale at different rates. It is entirely possible to read a fixed version of a contract while interacting with an unfixed one.

How: compare the on-chain deployed version or package ID against what the documentation and public repository claim is current. On chains with package versioning, check that the "published at" reference matches the live version.

Bad answer: a repository whose HEAD does not match mainnet, with no indication of which is authoritative. Ask which one is live. A protocol that cannot answer quickly does not know either.

4. Does the protocol revalidate solvency on the way out?

A lending protocol's core safety property is that it checks your position is still healthy after an action, not merely that your account exists.

How: in the public source, follow the withdrawal and borrow paths and look for the health or solvency check. The trap is that the correct check and a weaker check often have near-identical names — validating that an account is present is not the same as validating that its state is solvent, and one word of difference in a function name can be the whole security property.

Bad answer: an exit path that reads a balance and transfers without recomputing collateralisation.

Visible from outside, without reading code: compare total borrows against total supplied for each market. Utilisation above 100% means more is owed than exists. That is a solvency signal you can read off a dashboard, and it is the single most useful number on a lending protocol's front page.

5. Is there a pause layer, and what does it cover?

A pause mechanism is protective, not suspicious — the ability to stop the bleeding is why some incidents cost thousands instead of millions.

How: check whether pause functionality exists and which actions it covers: supply, withdraw, borrow, liquidate.

What to understand: pausing is asymmetric. Freezing supply while leaving borrow open means utilisation can only ratchet upward. That may well be the right call — it lets existing users exit — but it is a deliberate trade, and a protocol that has thought about it will say so.

Bad answer: no pause capability at all, or pause controlled by the same single key from check 1.

6. Where does the price come from?

Most exploits are not cryptography. They are a contract believing a wrong price.

How: identify the oracle for each market. Is it an established provider, a DEX spot price, or a single pool?

Bad answer: collateral valued from a single on-chain pool's spot price with no time-weighting. Thin pools can be pushed, and the cost of pushing one is frequently less than the value it unlocks.

Good answer: established oracle providers, multiple independent sources, and a stated fallback for when a feed goes stale.

7. Can you actually exit at size?

Liquidity is not a yes/no property. It is a curve, and it is the one that determines what your position is truly worth.

How: request a real swap quote for the size you would actually exit — not one token. Compare against the redemption or nominal rate.

⚠ The trap we fell into ourselves: on a stableswap pool with a high amplification factor, the reserve ratio is not the price. We once read a pool's reserves and recorded our own token's peg as 3.6% when the router was quoting 82%. Always quote the router.

Bad answer: a 1-token quote that looks healthy and a realistic-size quote that is dramatically worse, with the protocol advertising only the first.

8. Is the rewards contract funded?

Rarely checked, genuinely dangerous. The contract paying rewards is usually separate from the one holding your deposit. If emissions outrun its balance, claims begin reverting — and depending on the implementation, the reverting functions can include ones you need in order to exit.

How: read the reward distributor's balance and its emission rate, and divide. Then look at its recent transaction history for failed calls.

Bad answer: a rewarder holding a few days of emissions against an advertised APR that assumes years of them.

A run of reverts on a reward contract is public, timestamped, and visible before anyone announces it. Nobody looks.

The checklist

What this list deliberately leaves out

Audit badges. An audit is a point-in-time review of a specific commit. Check 3 exists precisely because the audited commit and the deployed code drift apart.

TVL. A number that measures how many people have not yet checked items 1–8.

Team anonymity. Pseudonymous teams run some of the most conservative protocols in DeFi, and named teams have run some of the worst. Key control is the property that matters; a legal name is not a substitute for a threshold.

Every check here is answerable from public data. That is the point. A protocol that requires you to trust its description of itself has already given you the answer.

Frequently asked questions

How do I know if a DeFi protocol is safe?

Check who controls contract upgrades, whether privileged permissions are genuinely locked, whether the deployed code matches the published code, whether exit paths revalidate solvency, whether a pause layer exists, where prices come from, whether you can exit at your position size, and whether the rewards contract is funded. All eight are answerable from public on-chain data.

Is an audit enough to trust a protocol?

No. An audit reviews a specific commit on a specific day. Contracts are upgraded afterwards, and the audited code and the deployed code drift apart. Checking who can push an upgrade tells you more about your risk tomorrow than an audit badge tells you about today.

Does high TVL mean a protocol is safe?

No. TVL measures adoption, not security, and adoption frequently precedes scrutiny. Several of the largest failures in DeFi had substantial TVL immediately before they failed.

Is a multisig always safer than a single owner?

Only if the signers are genuinely independent. A 3-of-5 multisig whose keys sit in one person's keystore provides the security of a single key with the appearance of five. Protocols that publish their signer topology are giving you information most do not.

What is the single most useful number on a lending protocol?

Utilisation. Total borrowed against total supplied, per market. Above 100% means more is owed than exists, which is a solvency signal readable from a dashboard without touching the source code.

Should I avoid protocols with anonymous teams?

Anonymity is a weak signal in both directions. Pseudonymous teams run some of the most conservative protocols in DeFi, and named teams have run some of the worst. Key control and code verifiability are the properties that actually bound your risk.

Keep reading

• Is liquid staking safe? Five risks, and how to check each one
• Has JWLEGLD ever depegged? The full on-chain history
• Fake wallet scams in 2026
• DeFi loan liquidations explained
• What are vault curators in DeFi?
• Proof of reserves explained

This article is educational and is not financial advice. Verify any protocol's contract state yourself before depositing.