Smart Contract Risk: What to Check Before Depositing Funds

Smart contract risk comes from unaudited code, admin keys and weak oracles, not just price moves; this checklist covers what to verify before you deposit funds.

Smart contract risk is a different category from market risk

Every deposit into a DeFi protocol carries market risk, the chance that the assets you hold change in price. It also carries a separate risk that has nothing to do with price: the chance that the code and the people who control it fail you outright. ethereum.org’s own security documentation frames the stakes plainly, warning that smart contracts “handle large amounts of value” and that mistakes can cause “irrecoverable losses for users,” since code deployed to a blockchain is typically difficult or impossible to patch after the fact.

That combination, real money plus code that is hard to fix, is why smart contract risk deserves its own checklist rather than getting folded into “the market might go down.” A protocol can post a strong, well-earned APR from real trading volume, exactly the kind of real yield worth farming, and still be one bad contract away from a total loss that has nothing to do with any of that yield math.

Start with the code: audits and verified source

The first check is whether you can actually see what you’re depositing into. A contract with published, verified source code lets anyone, including automated tools, compare what’s deployed on-chain against what the team claims it does. An unverified contract is a black box; there is no independent way to confirm it does what its marketing says.

An audit is the next layer, and it matters what an audit actually is. ethereum.org’s security guide is direct about the limits: “audits won’t catch every bug and are mostly designed to provide an additional round of reviews.” Treat an audit as one more filter, not a guarantee. A few checks turn a vague “audited” label into something useful:

• Who performed it. A named, reputable security firm with a public track record carries more weight than an unnamed or self-published review.
• What version it covers. An audit of an earlier contract version says little about code that has since been modified or redeployed.
• Whether findings were fixed. Most audit reports list issues by severity. Check that critical and high-severity findings were actually resolved, not just acknowledged.
• Whether a bug bounty is active. ethereum.org’s guide also points to ongoing bug bounty programs as a complementary check, since they keep incentivizing outside researchers to look for problems after the initial audit is done.

None of this replaces the fact that smart contracts also underpin the pool math and the lending logic behind whatever yield you’re chasing; a protocol can be mathematically fair to every depositor and still be running on code that has never been reviewed.

Who can change the rules after you deposit?

A contract that looks immutable today can still be changed tomorrow if it was built with an upgrade path. ethereum.org’s documentation on upgradeable contracts explains the tradeoff directly: developers use patterns like proxy contracts so they can “fix vulnerable contracts” after launch, but this means “users must trust developers not to modify smart contracts arbitrarily,” which works against the plain idea of code you can rely on staying the same.

Proxy-based upgrades carry their own added risk on top of that trust question. The same documentation warns that “proxy patterns are more complicated to use and can introduce critical flaws,” meaning the upgrade mechanism itself is one more piece of code that can contain a bug, separate from whatever bugs exist in the logic it’s meant to fix.

Two controls meaningfully reduce, though don’t eliminate, this risk:

• Multisig control. Requiring several independent signers to approve any admin action, rather than a single private key, removes the single point of failure a lone compromised key represents.
• A timelock on changes. ethereum.org’s guidance recommends a delay between when an upgrade is proposed and when it takes effect, specifically so it can “give users some time to exit the system if they disagree with a proposed change.” A protocol that can upgrade instantly, with no delay and no public queue of pending changes, gives you no window to react at all.

Before depositing, look up who holds the admin key or contract ownership, whether it’s a multisig, and whether a timelock applies to upgrades and parameter changes. This information is usually visible on a block explorer or in the protocol’s own documentation, and it tells you more about your real exposure than the posted APR does.

Two failure modes worth understanding, without the exploit details

You don’t need to read Solidity to do useful due diligence, but knowing the shape of the two most common vulnerability classes helps you ask better questions and read an audit report with more context.

Reentrancy happens when a contract makes an external call, such as sending funds out, before it has finished updating its own internal records. That ordering mistake can let an outside contract call back into the original one and repeat an action, like a withdrawal, multiple times before the first one is even recorded as complete. ethereum.org’s security guide lists reentrancy among the well-known vulnerability classes and notes that prevention comes down to ordering: contracts should update their own state before making outside calls, not after.

Oracle manipulation targets contracts that rely on an external price feed to make decisions, such as how much collateral a loan requires or how a trade gets priced. If that feed can be pushed away from the real market price, even briefly, an attacker can trigger favorable terms for themselves at the contract’s expense. ethereum.org’s oracle documentation notes that “decentralized oracles reduce the risk of passing invalid information to onchain contracts” by comparing data from multiple sources rather than trusting one feed alone. A protocol pulling its price from a single, thin market is more exposed than one using a broad, time-weighted feed across many venues. The same oracle dependency shows up in lending protocols, where a manipulated price can push a healthy position into liquidation, or a bad loan into looking healthy, without the borrower doing anything unusual.

Neither of these requires you to audit code yourself. What they tell you is what to look for in an audit report’s table of contents, and why “has this contract been reviewed for reentrancy and oracle dependencies specifically” is a better question than “has this been audited.”

Sizing your exposure to unproven contracts

Even a full checklist pass doesn’t reduce smart contract risk to zero, so position size is part of the risk control, not just the due diligence. A simple rule some DeFi users apply is capping how much of a DeFi allocation goes into any single protocol based on how proven its contract is.

Example: Suppose you’ve set aside a hypothetical $20,000 for DeFi activity. You decide to cap any single unaudited protocol at 5% of that allocation, and any audited-but-recently-launched protocol at 15%.

The exact percentages are a personal risk decision, not a rule this site is telling you to follow, but the structure is worth borrowing: decide your cap before a high posted APR is tempting you to skip the checklist, not after.

Run through our security checklist tool as a starting template, and pair it with the wallet-side protections in our crypto wallet security guide, since a perfectly audited contract still can’t stop a stolen key or a drainer signature on your end. If you’ve already granted a protocol access to your tokens, our guide to reviewing and revoking token approvals covers how to check and undo that access.

Common mistakes to avoid

1. Treating “audited” as a single fact instead of a set of details. Which firm, which version, and whether findings were fixed all change what the label is worth.
2. Skipping the admin key question because the team seems trustworthy. A trustworthy team with an unrestricted, no-timelock admin key is still a single point of failure.
3. Chasing the highest posted APR without checking contract age. A very high rate on a brand-new, unaudited contract is often unpriced risk, not free yield, a pattern also covered in our guide to yield farming.
4. Assuming a big TVL number means a contract is safe. Total value locked reflects how much capital other people have deposited, not how carefully the code was reviewed.
5. Sizing a position as if the checklist replaces a loss limit. Even a strong checklist pass deserves a position size you could afford to lose entirely.

The bottom line

Smart contract risk is a separate category from market risk, and it needs its own checklist before you deposit: verified and audited code, a known and constrained admin key, and an oracle design that doesn’t lean on one thin price source. None of these checks reduce the risk to zero, which is why position size, capped higher for unproven contracts, is the part of the checklist that protects you even when the code review misses something.

This content is for education only and is not financial, investment, tax or legal advice. Crypto assets are volatile and you can lose money. Examples use hypothetical numbers. See our disclaimer and editorial policy.