Type “defi safety” into a search bar and the results skew oddly specific. Most of what ranks is about DeFiSafety, the Montreal-founded firm that reviews protocol documentation and publishes a Process Quality Review score. That is a real and useful resource — but it answers a narrower question than the one most searchers are actually asking. A user trying to decide whether to deposit into a lending market, a liquid-staking vault, or a perpetuals exchange is not looking for one organization’s name. They are looking for a way to think about the question themselves, for any protocol, on any given day.
That question has a workable answer. It is not a single number, and it is not a green checkmark next to an audit firm’s logo. It is four signals, read together: whether the protocol has been audited and what that audit actually covered, what its total value locked has done over time and why, how transparent the team behind it is, and — critically — how the protocol and its team behaved the last time something went wrong. None of the four is sufficient alone. A protocol can pass on three and fail on the fourth and still lose a depositor’s funds. Evaluating DeFi safety means holding all four at once, not scanning for a single reassuring badge.
Start With the Audit — But Read It Like a Snapshot, Not a Guarantee
A smart contract audit is a firm reading a protocol’s code, at a specific commit, for a bounded set of vulnerability classes, over a bounded number of engineer-hours. Reputable firms — OpenZeppelin, Trail of Bits, CertiK, Zellic, Cyfrin — are good at what audits are designed to catch: reentrancy, access-control errors, integer overflow, unsafe external calls, and known oracle-manipulation patterns. What an audit cannot do is guarantee that no vulnerability exists, because it cannot exhaustively prove the absence of a bug in arbitrarily complex code, and it cannot cover code that did not exist yet when the audit was performed.
The Curve Finance incident from July 2023 illustrates the boundary problem directly. Several of Curve’s liquidity pools had been audited. The vulnerability that cost the protocol roughly $70 million was not in Curve’s own logic — it was a reentrancy bug in specific versions of Vyper, the third-party smart-contract language Curve’s pools were compiled with, as documented in Chainalysis’s and Hacken’s post-incident analyses. The pools were audited; the compiler layer beneath them was not in scope. That distinction — what was actually reviewed versus what a headline “audited” label implies was reviewed — is the single most important thing to check before trusting an audit at face value. Read the audit report itself, not just the badge. Confirm the commit hash matches the deployed contract, confirm the scope section names the actual modules the protocol runs in production, and check the date. A protocol that shipped a major upgrade eighteen months after its last audit is running unaudited code, whatever the marketing page says.
This is also where the same point-in-time fragility that has undermined even centralized exchange audits applies just as directly to DeFi: a security posture measured once and left unrevisited degrades the moment the underlying code, dependencies, or attack surface change, regardless of how clean the original review was. The more useful signal is not “was this audited” but “how does this protocol treat security as an ongoing practice” — recurring audits after major upgrades, a public bug-bounty program (Immunefi is the standard venue), and a documented incident-response process before anything has gone wrong.
Audit stacking is a genuine, if partial, signal of maturity. EtherFi, the liquid-restaking protocol built on EigenLayer, has been through six separate audits from CertiK, Nethermind, Certora, and Omniscia, each firm covering different components and threat models — a materially different risk posture than a single-audit protocol, because independent reviewers catch different things. Contrast that with Dolomite, the multi-asset lending protocol that has assembled a four-firm audit stack (OpenZeppelin, Bramah Systems, SECBIT, Cyfrin) covering its core contracts, but whose founding team remains formally unverified on VaaSBlock’s own RMA registry. The audits are real and substantive. They are not, on their own, a substitute for knowing who is behind the protocol — which is the next signal, not a replacement for this one.
A different kind of review is worth knowing about alongside code audits: process-based reviews that assess documentation quality, test coverage, admin-key controls, and governance transparency rather than scanning the contract itself. DeFiSafety’s Process Quality Review methodology is the clearest example — it publishes its full scoring criteria openly, and its own tracked data shows that projects scoring above 80% on the PQR have historically maintained a 97% incident-free rate since mid-2020. That correlation between process discipline and outcome is exactly the kind of evidence a safety evaluation should be looking for: not a claim, a track record that can be checked against the published methodology.
TVL History Tells You More Than the Number Does
Total value locked gets treated as a size metric — bigger number, safer protocol — when the more useful read is the shape of the line over time, not its current height. A TVL chart that climbs steadily alongside real usage (transaction count, unique depositors, integrations from other protocols) is a different animal from one that spikes overnight on a liquidity-mining incentive and then decays just as fast once the token rewards taper off. The second pattern describes mercenary capital: funds that arrived to farm a yield, not because anyone assessed the protocol as a safe place to park value. A protocol whose TVL is mostly mercenary capital is also a protocol where a large, fast withdrawal event — a bank run, in effect — is more likely, because the capital was never sticky to begin with.
TVL is also manipulable in the same way trading volume is. Low-liquidity pools are easier to move with a modest amount of capital, which is exactly the mechanic behind price-oracle manipulation attacks: an attacker inflates or depresses an asset’s price within a thin pool, then borrows or trades against that distorted price elsewhere in the protocol. Chainalysis has tracked oracle-manipulation losses running into the hundreds of millions of dollars across 2022 and 2023 alone, and the mechanism is consistent enough across incidents — the Mango Markets exploit in October 2022, where an attacker used two accounts to pump the price of the MNGO token inside Mango’s own market and then borrowed against the artificially inflated collateral, walking away with roughly $117 million — that “how thin is the liquidity this protocol’s pricing actually depends on” is now a standard diligence question, not an edge case.
None of this means TVL trajectory alone tells you whether to trust a protocol. It means TVL history is a leading indicator worth reading before a deposit, not a lagging one worth checking only after something breaks. A useful practice: look at the TVL chart on a tracker like DeFiLlama over the protocol’s full lifetime, not just the last thirty days, and ask what happened at every sharp inflection point — was it a real product milestone (a new chain deployment, an integration), or an incentive program that has since ended. Institutional credit protocols carry a related but distinct version of this risk: VaaSBlock’s analysis of Maple Finance’s SYRUP-era risk surface makes the case that on-chain credit markets carry correlated, not independent, risk across their loan book — a useful reminder that TVL concentrated in a small number of large positions behaves differently under stress than TVL spread across many small ones, even when the headline number looks identical.
Team Transparency Is a Leading Indicator, Not a Vibe
Anonymity in crypto is not automatically disqualifying — Bitcoin itself shipped from a pseudonym, and some legitimately well-run protocols still operate with pseudonymous core contributors. But the base rate matters, and the base rate is not close. CertiK’s 2025 Security Report found that 94% of rug pulls originated from teams that were completely anonymous, with no verifiable identity behind the project at all. That is not a coincidence of style — anonymity removes the one mechanism (reputational and, in many jurisdictions, legal accountability) that gives a founder a durable reason not to walk away with deposited funds.
The practical test is not “does this team have real names attached” in isolation — it is whether those names can be verified against a real track record, and whether the verification predates the moment you’re checking it. A team claiming years of relevant experience whose on-chain wallets and public profiles were all created within the last few months is presenting a story that does not match its own footprint. VaaSBlock’s own RMA-verified platform data illustrates both ends of this cleanly. Aspida, a liquid-restaking protocol, carries zero named team members, no independently confirmed audit firm, and sits near the bottom of its category on VaaSBlock’s Transparency Score — a combination that, per CertiK’s own findings, describes the exact profile most associated with eventual loss events. EtherFi sits at the other end: a verified founding team with public track records, layered on top of the six-firm audit history described above. Team transparency and audit depth are correlated in the data for a reason — protocols run by people willing to be named tend to also be the ones that invest in ongoing security practice, because their own reputations are attached to the outcome.
Tools that formalize this check are useful precisely because they replace a gut read with a documented one. VaaSBlock’s Transparency Score is one example of scoring team, audit, and governance signals into a single comparable number across projects, rather than asking a reader to reconstruct the assessment from scratch for every protocol they encounter. Whichever tool is used, the underlying question stays the same: can the people responsible for this protocol be identified, and does what’s known about them hold up.
Incident History — What Matters Is What Happened After
Every sufficiently large DeFi protocol carries some non-zero probability of an incident. Complex, permissionless, adversarially-tested code running with real financial value attached will eventually be probed by someone looking for a flaw, and eventually one will be found somewhere in the stack — the protocol’s own contracts, a dependency, an oracle, a bridge. Because of that, “has this protocol ever had an incident” is a worse diligence question than “how did this protocol behave when it did.” The response tells you more about future risk than the absence of a past one does.
Euler Finance’s March 2023 exploit is the clearer of the two contrasting cases worth knowing. An attacker used a flash loan to manipulate the protocol’s internal accounting and extracted roughly $197 million. What followed was unusually direct: Euler’s team published a detailed public post-mortem, engaged security firms and law enforcement, and negotiated openly with the attacker — who returned the vast majority of the funds within days after Euler’s team offered a bounty and made clear the alternative was prosecution. The protocol rebuilt its risk parameters and reopened. Mango Markets, hit almost exactly a year earlier by the oracle-manipulation attack described above, took a different path: the attacker, Avraham Eisenberg, used Mango’s own governance mechanism to vote through a proposal letting him keep roughly $47 million of the stolen funds as a “bounty” in exchange for returning the rest — a resolution that ran through the protocol’s own decision-making process rather than around it, and one that left the DAO’s governance design looking like part of the vulnerability rather than a check against it. Eisenberg was later criminally convicted in the United States, a reminder that “the exploit was technically a governance vote” does not make it legally a gray area.
The gap between those two responses is the diligence signal. Did the team communicate clearly and quickly, with technical specifics rather than vague reassurance? Was there an independent post-mortem, not just a company statement? Were the actual code changes that fixed the vulnerability verifiable on-chain, not just announced — the same distinction VaaSBlock’s coverage of on-chain compliance verification makes about the gap between an asserted fix and a confirmed one? And did the protocol’s own governance structure end up complicit in the outcome, the way Mango’s did, or did it function as an actual safeguard? A protocol with one well-handled incident in its history can be a more trustworthy bet than one with a spotless record but no evidence of how it would respond under pressure, precisely because the well-handled incident is evidence and the spotless record is only an absence of data.
Putting the Four Signals Together
None of these four checks — audit scope and cadence, TVL trajectory, team verification, and incident response — is designed to work in isolation, and treating any single one as sufficient is how diligence fails in practice. A protocol with a deep audit stack and an anonymous team is not automatically safe; the audits reduce code risk while the anonymity leaves the accountability risk fully open. A protocol with a verified team and no incident history yet has not been tested; a young, unaudited protocol with a transparent team is still an unaudited protocol. The signals are meant to be read against each other, not added up into a single pass/fail score.
A practical version of the check, before depositing into any DeFi protocol:
- Pull the audit reports directly, confirm the scope matches what the protocol runs in production today, and check the date against the last major code change.
- Look at the TVL chart over the protocol’s full history on a tracker like DeFiLlama, not just the recent window, and identify what drove every sharp move.
- Search for the team by name, not by project handle, and check whether the identity being claimed predates the project or was created alongside it.
- Search the protocol’s name alongside “exploit,” “hack,” or “post-mortem” and read how the team communicated during the worst moment in its history, if one exists.
Neither DeFiSafety’s process-based methodology nor an on-chain platform registry replaces this work — they are aids that make parts of it faster to check, not substitutes for checking. The searcher typing “defi safety” into a search bar is usually looking for a shortcut. There isn’t a real one. There is a repeatable process, and it takes about twenty minutes per protocol once it becomes routine.
Frequently Asked Questions
Is a smart contract audit enough to trust a DeFi protocol? No. An audit confirms that a named firm reviewed a specific version of the code for a defined set of vulnerability classes. It does not cover code shipped after the audit, dependencies outside the audited scope, or the people running the protocol. Treat an audit as one input among several, not a final verdict.
What TVL size counts as safe? There is no safe threshold in absolute dollar terms. A better question is whether TVL growth tracks real usage or a temporary incentive program, and whether the pools an oracle depends on are deep enough to resist manipulation by a well-capitalized attacker.
Does an anonymous team always mean a protocol is a scam? No, but the base rate is heavily skewed: CertiK’s 2025 research found 94% of rug pulls came from fully anonymous teams. Anonymity should raise the bar for every other signal — audit depth, governance design, and incident-response track record — rather than being ignored.
What should a user check after a protocol is exploited? Whether the team published a technical post-mortem rather than a vague statement, whether an independent party reviewed the fix, and whether the patched code is verifiably deployed on-chain rather than simply announced. How a protocol handles its worst day is a stronger predictor of future risk than whether it has had one.
