How to investigate the security of a DeFi protocol

Before depositing funds in a decentralized finance (DeFi) protocol, many people look only at the advertised yield and the total amount deposited. Neither tells you whether the protocol is secure. This article proposes a checklist of questions for you to investigate on your own, based on public technical documentation and regulators’ reports.

A warning before we start: following this checklist does not turn a protocol into a safe investment. It helps you see risks that are usually hidden behind the interface. The editorial team does not recommend protocols, assets or companies. What DeFi is and the general risks it carries are covered in DeFi: what decentralized finance is.

Why the question goes beyond the code

The Financial Stability Board (FSB), which coordinates G20 regulators, lists among DeFi’s operational vulnerabilities governance, dependence on the underlying blockchain, smart contracts, oracles and bridges. On contracts, the report notes that code is widely reused, so seemingly independent contracts may share the same vulnerabilities, and that an erroneous or fraudulent transaction generally cannot be reversed (FSB, 2023).

The OWASP Smart Contract Top 10, 2025 edition, points in the same direction. The first two items are access control flaws and price oracle manipulation; flash loan attacks appear in seventh place (OWASP). In other words: a significant part of the risk lies in who controls the system and in the economic environment in which it operates, not just in lines of code.

That is why the checklist below has six steps, from the most verifiable to the most subjective.

Step 1: is the code published and does it match what runs

A contract on the blockchain is stored in machine format (bytecode). To read what it does, you need the source code, and you need to know that the source code shown is actually what is in use.

That is what source code verification does: it recompiles the published code with the same settings and checks whether the result matches the bytecode at the contract address. According to ethereum.org, block explorers such as Etherscan display a “verified” badge when there is a match. The same page explains that this match is often partial (comments and variable names do not change the bytecode) and that services such as Sourcify allow a full match.

What to check:

• are the contract addresses listed in the protocol’s official documentation?
• does each address appear as verified in a block explorer?
• if a contract has no verified code, treat it as a red flag. You have no way of knowing what it does.

Step 2: who can change the contract

This is, in the editorial team’s assessment, the most important step. Most protocols have administrative functions: pausing, changing parameters, minting tokens or replacing the entire logic. What these powers are and where the risk lies is explained in Smart contracts with admin keys.

What to check:

• Is the contract upgradeable? Upgradeable contracts use an intermediary (proxy) that points to the logic code. Block explorers usually indicate when a contract is a proxy and what the current implementation is. ethereum.org points out that, in this case, you are trusting the developers not to change the contract arbitrarily.
• Who is the owner or administrator? An ordinary address (a single key), a multi-signature wallet or a governance contract? ethereum.org treats a single owner as a single point of failure (Smart contract security).
• If it is a multisig, how many signatures out of how many signers? And are the signers identified?
• Is there a waiting period (timelock)? How long is it? According to OpenZeppelin, the delay exists to give users time to review the operation and exit the system. A timelock of a few minutes does not fulfill that role.
• Who can pause, and what is blocked when it is paused? Frozen withdrawals are a risk to you, even when the pause is well-intentioned.

Much of this information should be in the protocol’s documentation. When it is, check in the block explorer whether it matches.

Step 3: audits, bounties and track record

A protocol that claims to have been audited should publish the full report. How to read that report (date, reviewed version, scope, unfixed issues) is covered in Smart contract audits: method and limits. Here, three complementary questions:

• Does the audit cover the code in use today? If the contract was upgraded afterwards, the new version may not have been reviewed.
• Is there a bug bounty program? ethereum.org recommends it as an additional layer, with rewards proportional to the value at risk.
• Has the protocol suffered incidents before? Look for the protocol’s own report on the case (post-mortem): what failed, whether users were reimbursed and what changed afterwards. A well-explained and fixed incident says something different from a hushed-up one.

Step 4: what the protocol depends on

A protocol can have flawless code and still break because of an external component. The FSB lists oracles, bridges and the blockchain itself as critical dependencies.

• Price oracles: where does the price the protocol uses to liquidate collateral come from? A single source, easy to manipulate with a large trade, is a known risk. The topic is covered in Oracles: how a physical asset reaches the blockchain.
• Bridges: if the deposited assets are “wrapped” versions of tokens from another network, their value depends on the bridge that issued them. See Blockchain bridges: how they work and where they fail.
• Stablecoins: if the protocol depends on a stablecoin, a loss of its peg hits you. See What stablecoins are and how they hold their value.
• Other protocols: the FSB describes composability, building one protocol on top of another, as a source of interconnection and contagion. If the protocol deposits its funds with third parties, their risks are yours too.

Step 5: governance and incentives

Many protocols are governed by votes of token holders. The FSB notes that voting power is often extremely concentrated, that participation can be low and that governance tokens can be acquired, including through flash loans, to influence a vote or pass a malicious proposal.

What to check:

• how much of the governance token supply is held by the team, early investors or a few addresses? The concepts for this analysis are in Tokenomics: how to analyze it before evaluating a project.
• what is the quorum to approve a change, and is there a delay between approval and execution?
• are there “guardians” with veto or pause powers? The FSB cites such roles as an indicator of concentrated power.

How votes work and why they are not always decentralized is covered in What a DAO is and how its governance works.

Step 6: the interface and your wallet

Some attacks never touch the protocol. Fake websites that imitate the original ask you to authorize your wallet and then drain the funds. Access the protocol only through addresses confirmed in the official documentation, read what you are signing and review the permissions you have already granted. The step-by-step guide is in Crypto wallet phishing: how to protect yourself.

Also remember that, when you use a protocol directly, there is generally no guarantee fund or identifiable company to turn to. The FSB notes the uncertainty about what protections exist after a loss, because it can be difficult to identify a legally responsible party.

How to use the result

In the end, you will have a list of answers, some reassuring, others not. In the editorial team’s assessment, three answers weigh more than the rest:

1. unverified code;
2. upgrades or minting controlled by a single key, with no waiting period;
3. dependence on a fragile oracle or bridge for the asset you are going to deposit.

Any one of them means that the security of your money depends, to a large extent, on people and components you do not control. That does not prove there will be a loss, but it indicates where one could happen.

Key takeaways

• Investigating a DeFi protocol means checking published code, administrative powers, audits, dependencies, governance and the interface you use.
• The most revealing questions are about control: who can change the contract, how many people need to agree and how much time you have to exit.
• The checklist reduces surprises, not risk to zero. Audited, well-governed protocols have also failed, and the amount deposited can be lost entirely.