Prerequisites
You are preparing to deposit funds into an unaudited DeFi protocol.
You can find the 'Contract' page for this protocol on Etherscan or any blockchain explorer, and see the familiar green checkmark label.
Verified smart contract source code only confirms that the published code matches the bytecode running on-chain, and it never represents that the code is secure.
Etherscan's 'Verified' label only does one thing: it recompiles the Solidity code submitted by the developer, and checks if the compilation output matches the on-chain deployed bytecode. It does not scan the code for backdoors, vulnerabilities, or functions that could steal your funds.
Step 1: Check Verification Type – Full Verification vs Partial Verification
[What to do]: Review the contract's verification mode, to confirm if malicious developers could hide harmful logic in the submitted source code.
[How to do it]: On the Etherscan contract page, check the verification details to see if there is a 'Contract Metadata' or 'Compiler Metadata' field.
Situation A: Marked as Full Verification → The hash of the metadata file is appended to the bytecode, and any modification to the source file will cause a hash mismatch. This is relatively more reliable, but you still need to follow the subsequent checks.
Situation B: Marked as Partial Verification (the most common verification method currently) → Comments, variable names, and even partial logical structures do not affect compilation results, and can be altered freely. If the metadata hash is not used or mismatched, bad actors can implant deceptive comments or misleading variable names in the source code that will not be flagged by the verification process.
[Completion Criteria]: Confirm the verification type of the target contract. If it is partial verification, mark the contract's security level as unconfirmed.
High Risk Alert: Partial verification allows developers to upload a seemingly normal source code, while deploying a completely different set of logic on-chain. Malicious contracts can hide logic via inline assembly, or use proxy patterns and library calls to execute operations that do not exist in the published source code. This means even if you read the full source code and find no issues, there could still be a backdoor hidden in the bytecode.
Step 2: Check for Inline Assembly or Proxy Patterns
[What to do]: Search for key keywords in the source code to identify high-risk patterns.
[How to do it]: On the contract source code page, press Ctrl+F (or Cmd+F) to search for the following keywords: assembly {, delegatecall, proxy, implementation.
Situation A: The source code contains a large number of assembly { blocks → High Risk. Malicious logic can be fully hidden in assembly, with no high-level language comments or variable name hints. Assembly can directly manipulate storage slots to write secret state. A common example: the contract publicly shows that 'Owner permissions have been renounced', but the actual control permission is written to another unzeroed storage slot in the bytecode.
Situation B: The source code contains delegatecall or uses a proxy pattern → High Risk. The actual logic of the contract may be hosted at another address (the implementation contract), which could be unverified or modified at any time. The 'verified source code' you see may only be a shell, with the real functional logic stored elsewhere.
Situation C: None of the above keywords are found → Relatively lower risk, but you still need to proceed to Step 3.
[Completion Criteria]: You have confirmed whether the contract uses assembly or proxy patterns. If it does, strongly advise against depositing any funds to the protocol.
Step 3: Understand the Root Cause of 'Verification ≠ Security'
[What to do]: Build a correct cognitive framework to avoid being misled by the green checkmark.
[How to do it]: Read the following three facts, and cross-reference them with the contract you are reviewing:
Green checkmark verification confirms consistency, not security
It only guarantees that the source code you see matches the code running on-chain, it does not guarantee that the code will not act maliciously.
Malicious source code can fully meet verification requirements
Developers can upload a source code with hidden backdoors, and as long as the compiled bytecode matches the on-chain version, it will pass verification. The source code can have a public
withdrawfunction that claims 'only the Owner can call it', while the inline assembly logic inside actually allows any address to call it.
Only formal verification can prove zero vulnerabilities
Different from regular source code verification, formal verification converts contract behavior into a mathematical model, and uses a prover to traverse all possible input paths, proving that a specific property holds under all conditions. MakerDAO's DAI contract was audited by two independent firms, but its core mathematical error was not discovered by Certora's prover until 2022 – two and a half years after the contract was deployed.
[Completion Criteria]: You have understood that the only function of the green checkmark is to let you read the full source code, not to give you full confidence to deposit your funds.
Common Failure Causes
The most common mistake is assuming that 'open source code + green checkmark = security' and depositing large amounts of funds directly. In reality, countless rug pull project contracts are fully verified, but they hide trigger conditions known only to the deployer in the source code, allowing the project team to drain all liquidity and run away. Verification is not an audit: it does not reveal what the code will do, it only proves that the code has not been tampered with after deployment.
Validation Check After Operation
If you decide to proceed to interact with this smart contract, open the 'Write Contract' and 'Read Contract' tabs, and check every public function one by one – especially functions with names containing 'onlyOwner', 'set', 'update', and 'emergency'. If the behavior of these functions is not clearly explained in the project's public documentation, mark it as a critical red flag.
Next Steps
Before depositing funds, confirm that the contract has undergone a full independent audit, and that the audit report covers the correctness of business logic rather than only basic common vulnerabilities. If the project team does not publish an audit report, or the audit firm is uncredited, consider abandoning this protocol. You can verify audit credibility via the 'Customer Cases' list on Certora's official website, or the 'Security' section of the project's official documentation.
