I’ve been meaning to write about this for a while. I finally had some time today.

In DeFi, deposits, loans, and swaps are all handled automatically by smart contracts. There’s no human review, and no customer service team that can recover money sent to the wrong address. When a contract is written correctly, it’s the most reliable set of rules; when it’s written incorrectly, its vulnerabilities are just as meticulously “executed.”

Related token: $ETH Current price: 2489.99 (24h -0.97%).

📌 Code is law—and so are its vulnerabilities

Once a smart contract is deployed on-chain, it executes automatically according to its code. This brings transparency and predictability: anyone can read the code, and an immutable contract’s rules won’t change just because someone changes their mind.

Conversely, once a vulnerability in the code is discovered and exploited, funds can be drained in just a few transactions, and they can be very difficult to recover. The DAO in 2016 is one example: its contract was attacked through a reentrancy vulnerability. Ethereum later addressed this with a hard fork, while the original unforked chain continued as Ethereum Classic (ETC).

📌 What exactly does an audit cover?

A security audit is an assessment carried out by a third-party security team on a particular version of the code at a specific point in time. Audit reports generally list the issues found, their severity, and whether the project team has fixed them.

Common areas checked include reentrancy, access control errors, calculation precision issues, and the possibility of oracle manipulation. Audits can help identify and reduce these common vulnerabilities, but they are limited by time, manpower, and scope.

📌 Why can things still go wrong after an audit?

First, an audit only covers the specified scope of code. Contracts outside that scope and features added later aren't included. If the code is changed after the audit, or the deployed version differs from the audited version, the conclusions may no longer apply.

Second, some risks don't lie in the code itself: an oracle or other protocol that the protocol depends on could fail; an administrator's key with upgrade privileges could be stolen; or a website's frontend could be tampered with to trick users into signing malicious transactions. Any of these could cause losses.

📌 What can ordinary users do?

When reading an audit report, pay attention to its date, scope, and any issues that haven't been fixed. Don't just look for the words “audited.” You can also check whether the contract can be upgraded unilaterally, and whether upgrade privileges are controlled by a multisig and a timelock.

Protocols that have been running for a long time and have handled large amounts of funds are generally considered more reliable, but that doesn't mean they have no vulnerabilities. So in DeFi, only put in funds you can afford to lose, spread large amounts across different protocols, and remember to revoke permissions for protocols you no longer use.

📌 Final thoughts

An audit is the starting point for security, not the finish line. It's more practical to treat smart contract risk as a cost you have to accept when participating in DeFi than to trust the words “audited.” Every return comes with a corresponding risk, so think about the worst-case scenario.

When did you first figure this out?

This is a personal perspective, not specific trading advice.