Smart Contracts Intro: Code Is Law, But Code Has Bugs

You deposit your money into the Aave lending protocol, and the next day you hear that some contract was hacked and hundreds of millions were lost — you start wondering: code is law? But what if the code has bugs?

1. What Are Smart Contracts

1.1 Definition

Smart contracts are self-executing programs deployed on a blockchain — they automatically execute when conditions are met, without human intervention. Think of them like vending machines: you insert coins, select a product, and the machine dispenses it — no shop clerk needed.

1.2 Core Characteristics

• Immutable: Once deployed, the code cannot be modified (unless specially designed)
• Self-executing: Automatically runs when conditions are met; no one can stop it
• Transparent: The code is on-chain and visible to anyone
• Trustless: No need to trust a third party

1.3 The Power of Smart Contracts

Without smart contracts, blockchain is just a ledger. With smart contracts, blockchain becomes a computing platform — DeFi, NFTs, DAOs, and games all rely on smart contracts to operate.

2. The Ideal vs. Reality of “Code Is Law”

2.1 The Ideal

In a perfect world, smart contract code precisely enforces rules with no room for human interference, no possibility of corruption, and no trust issues.

2.2 The Reality

Code can have bugs, and once deployed, those bugs cannot be fixed. Historical losses from smart contract bugs:

• The DAO (2016): $60M stolen, leading to the ETH fork
• Parity Wallet (2017): $150M locked and inaccessible
• Poly Network (2021): $610M stolen (later returned)
• Wormhole (2022): $326M stolen

Key Insight: “Code is law” means — if the code is wrong, the “law” itself is wrong, and it cannot be amended.

3. Four Common Smart Contract Bug Types

3.1 Reentrancy Attacks

An attacker repeatedly calls the same function during contract execution, withdrawing funds multiple times before the balance is updated. The DAO incident was a reentrancy attack. Prevention: use the Checks-Effects-Interactions pattern.

3.2 Integer Overflow

Numerical calculations exceed the maximum value of the variable type, causing incorrect results. For example, adding 1 to a 256-bit integer’s maximum value resets it to 0. Prevention: use SafeMath libraries (built into Solidity 0.8+).

3.3 Missing Access Control

Certain contract functions should only be callable by administrators, but the code lacks permission checks — anyone can call them. Prevention: use the onlyOwner modifier.

3.4 Logic Errors

The contract logic itself has flaws, such as incorrect liquidation price calculations or wrong reward distribution formulas. These are the hardest to detect and prevent.

4. How to Determine If a Contract Is Safe

4.1 Has It Been Audited?

Well-known audit firms: Trail of Bits, OpenZeppelin, Quantstamp, Certik. Audited contracts are relatively safer, but audits do not guarantee zero bugs.

4.2 Is It Open-Source?

Open-source contracts allow anyone to review the code. You cannot verify the security of closed-source contracts — never use closed-source contracts to manage your assets.

4.3 Runtime Duration

The longer a contract has been running, the safer it is — time is the best test. A contract running for 2+ years with no major incidents is more trustworthy than one launched just a week ago.

4.4 Usage Volume

Contracts with higher TVL (Total Value Locked) generally receive more attention, making bugs easier to discover. However, high TVL also means greater incentive for attacks.

5. DeFi Safety Principles

1. Only use top-tier protocols (Aave, Compound, Uniswap, etc.)
2. Only use audited, open-source contracts
3. Test with small amounts first
4. Never grant unlimited Approve allowances
5. Verify contract addresses before interacting
6. Don’t chase new projects — newer means higher risk

Summary

Smart contracts are blockchain’s most powerful feature and biggest risk source. Code is law, but code can also have bugs — and once deployed, bugs are immutable. As a user, your safety strategy: stick to verified top-tier protocols, test with small amounts, and authorize cautiously.

Deep Dive: Smart Contract Audits

To understand smart contract security, you need to know what audits actually do and their limitations:

What Audit Firms Do:

• Read contract code line by line to find logic vulnerabilities
• Check access control (who can call which functions)
• Verify mathematical calculations (overflow risks)
• Check external call safety (reentrancy risks)
• Test behavior under extreme conditions (insufficient gas, abnormal inputs)

What Audits Cannot Guarantee:

• Audits are not a 100% safety guarantee — audited contracts have still been attacked later (e.g., Audius was attacked in 2022 despite a Certik audit)
• Audits have time limitations — if contract code is updated after the audit, the new code may not have been audited
• Auditors may miss issues — humans are not machines; complex logic vulnerabilities can be overlooked
• Some attack methods audits cannot cover (e.g., flash loan attacks, governance attacks)

How to Use Audit Information:

• Review audit reports: most projects publish them — read the issues found and their fixes
• Consider the auditor’s reputation: Trail of Bits and OpenZeppelin audits are the most trusted
• Audited ≠ risk-free, but unaudited = extremely high risk

Smart Contract Interaction Safety Checklist

Before every smart contract interaction, check these items:

1. Is the contract address correct?: Get addresses from official Twitter/Discord, not from search engines or strangers
2. Is the contract open-source?: Check Etherscan for published code. Closed-source contracts are extremely risky
3. Has the contract been audited?: Look for audit reports from reputable firms
4. Is the approval amount reasonable?: Choose exact amounts instead of unlimited when Approving. Use Revoke.cash to periodically clean old approvals
5. Is the Gas Limit sufficient?: Let MetaMask auto-estimate; don’t manually set it too low
6. Is the transaction amount correct?: Confirm the amount before submitting
7. Confirm on device: If using a hardware wallet, verify all details on the device screen

History’s Worst Smart Contract Attacks

Event	Year	Loss	Attack Type
The DAO	2016	$60M	Reentrancy
Parity Wallet	2017	$155M	Missing access control
Poly Network	2021	$611M	Cross-chain contract vulnerability
Wormhole	2022	$326M	Signature verification vulnerability
Ronin Network	2022	$625M	Validator compromise
Beanstalk	2022	$182M	Flash loan + governance attack
Curve Finance	2023	$70M	Reentrancy (Vyper compiler bug)

Common lessons from these attacks:

• Reentrancy is the oldest yet still the most common attack type
• Missing access control causes massive losses
• New attack types keep emerging (flash loan + governance attacks)
• Even audited contracts are not risk-free

Ultimate Safety Advice for Beginners

If you’re a beginner, the simplest smart contract safety strategy:

1. Stick to top protocols: Aave, Compound, Uniswap, MakerDAO — these have run 2+ years, have billions in TVL, and have been audited multiple times
2. Test with small amounts: First time using any protocol, only test with $50-100
3. Don’t chase new projects: A protocol launched last week is far riskier than one running for 2 years
4. Authorize cautiously: Before every Approve, ask yourself “if this contract is malicious, how much would I lose after authorizing?”
5. Use a dedicated wallet: Use a separate wallet for DeFi interactions (with only operational funds), keep large assets in another wallet

Ready to start your crypto journey? Register on Gate.io with the lowest fees and complete beginner guides.