An onchain due diligence checklist for new protocols should make research slower in the right places and faster everywhere else. Most early protocols do not need a deep report. They need a quick rejection screen that finds obvious contract, admin, liquidity, or usage problems.
Radar uses due diligence to separate discovery from trust. A protocol can be interesting, growing, and still not ready for user funds, integrations, or serious ecosystem conviction.
Verify contracts and deployment history
Start with the contracts users interact with. Are they verified on a block explorer? Is the deployment recent or connected to earlier versions? Do official docs, app links, and explorers point to the same addresses? Address confusion is one of the easiest ways early users get into trouble.
Check whether the protocol uses proxies, upgradeable contracts, or multiple deployments across chains. Upgradeability is not automatically bad, but it changes the trust model. If the contracts can change, you need to know who can change them and how much warning users receive.
Map admin powers
Admin keys, multisigs, guardians, pausers, and timelocks decide what can happen after launch. A new protocol with broad admin powers may still be reasonable during early development, but the scope should be explicit. Hidden control is the problem.
Look for timelock delays, signer lists, emergency pause rules, upgrade paths, fee controls, oracle controls, and treasury permissions. The question is not whether every control is decentralized on day one. The question is whether the risk is visible and proportionate to the product.
Check TVL and usage quality
TVL can be rented with incentives, circular deposits, or a few large wallets. Before trusting a TVL chart, check wallet concentration, inflows, outflows, reward programs, and whether usage continues after the first campaign. A large number with weak user distribution is not the same as product-market fit.
Usage quality depends on category. A DEX needs route depth and repeat swaps. A lending protocol needs healthy borrow demand, collateral quality, and liquidation design. A bridge needs reliable exits and destination fit. Do not judge every protocol with one metric.
Review incidents and communication
Search for audits, bug bounty scope, incident reports, postmortems, governance discussions, and status pages. A protocol with an incident history is not automatically worse than a protocol with no visible history. The quality of response matters.
Good teams explain what happened, what was affected, what was fixed, and what users should do next. Weak teams hide details or communicate only through hype channels. For Radar, communication quality is part of protocol operations.
Turn the checklist into a decision
A due diligence checklist should end with a label: reject, watch, test with low exposure, or research deeper. Without a label, research becomes a collection of facts with no decision value.
Use watch status when the idea is promising but one or two important items are unclear. Use reject status when contract addresses, admin powers, or user-risk communication cannot be verified. Use deeper research only when the protocol survives the simple checks first.
- Match app links, docs, and explorer addresses before connecting a wallet.
- Map upgrade, pause, treasury, oracle, and fee controls.
- Judge TVL and users by category fit, not headline size alone.
- End each review with reject, watch, test, or research deeper.
What deserves deeper research
A protocol deserves deeper research when the simple checks create fewer questions instead of more. Verified contracts, understandable admin powers, category-appropriate usage, and clear communication do not prove the protocol is safe, but they justify spending more time on the design. Weak projects usually fail before that point.
The deeper phase should focus on the specific risk that matters most for the category. For lending, that may be collateral and liquidation assumptions. For bridges, it may be exit paths and message verification. For games or social apps, it may be wallet permissions and retention. Good due diligence narrows the next question instead of trying to answer every question at once.
Final protocol review rule
Do not finish due diligence with a feeling. Finish with a label and the reason for it. Reject because contracts are unclear, watch because admin scope needs answers, test because risk is limited, or research deeper because the protocol passed the first screen. The label makes the next review faster and more honest.
Continue this cluster
The protocol-ops due-diligence cluster gives Radar readers repeatable checks for contracts, governance, users, infrastructure, and communication risk.
