Why you should know this
Smart contracts can hold assets and execute rules without a person approving each transaction. That does not make them infallible. Software bugs, economic design, admin keys, data feeds, bridges, user interfaces and human operations can all affect the result.
Security analysis belongs inside fundamental analysis because a product cannot deliver durable utility if users cannot reasonably trust the path. We do not need to become exploit developers; we do need to ask where trust and failure still live.
Smart contracts are programs with assets and authority
On Ethereum, a smart contract is a program deployed at an address. Users interact through transactions. Once code is deployed, behaviour may be fixed—or it may be routed through upgradeable components controlled by administrators.
Map:
- contracts that hold assets;
- contracts that set prices or collateral rules;
- upgrade or pause authority;
- token mint, burn and freeze powers;
- external calls and dependencies;
- user approvals and permissions.
“Immutable” and “upgradeable” each involve trade-offs. Immutability limits emergency changes; upgradeability can repair problems but adds governance and key risk.
Code risk
Common categories include access-control errors, reentrancy, arithmetic or accounting mistakes, oracle manipulation, faulty signatures, denial of service and business-logic failures. Security awareness lists such as the OWASP Smart Contract Top 10 are useful for organising questions.
They are not a certification that a contract is safe. The actual design, language, chain, dependencies and deployment matter.
Economic and composability risk
Code can behave exactly as written and still produce harmful outcomes. An attacker may use a flash loan, thin market or incentive loop to exploit economic assumptions. A lending protocol can depend on collateral liquidity that disappears during stress.
Composability means one application builds on another. It enables innovation but creates dependency chains: token, oracle, bridge, liquidity pool, governance and frontend. Draw what happens if each dependency fails or pauses.
Admin keys and governance
Privileged roles may upgrade code, pause withdrawals, change fees, replace an oracle or move treasury assets. Research:
- signer threshold and organisational diversity;
- timelock before execution;
- hardware and operational controls;
- monitoring and public notice;
- emergency procedures;
- whether governance can replace signers.
A multisig is a structure, not a guarantee. Five keys controlled through one organisation or weak process may still create concentration.
Oracle, bridge and infrastructure risk
Oracles supply external data such as prices. If an oracle is delayed, manipulated or inappropriate for a thin market, contracts may liquidate users incorrectly.
Bridges can add validators, custodians, smart contracts and wrapped assets. A bridged token is often a claim on assets held or controlled elsewhere. Infrastructure such as RPC providers, sequencers, cloud services, domain names and frontends can also fail or be compromised even when the base blockchain continues.
What an audit actually says
An audit typically examines a defined code version, scope and period using stated methods. Read:
- auditor identity and conflicts;
- exact commit or contract addresses;
- excluded components;
- severity definitions;
- unresolved findings;
- whether fixes were retested;
- changes deployed after the review.
Multiple audits can provide more perspectives, yet shared blind spots remain. An audit does not guarantee correct economic assumptions, secure admin operations, future upgrades or absence of unknown vulnerabilities.
Prevention, detection and response
Security maturity includes:
- tests, reviews and formal methods where appropriate;
- bug bounty and disclosure policy;
- real-time monitoring and alerting;
- bounded emergency powers;
- incident communications;
- recovery, compensation or orderly shutdown rules;
- post-incident learning.
An incident response that hides details may reduce accountability; immediate disclosure without considering active exploitation can also increase harm. Evaluate the documented process and eventual transparency.
User-layer risk
Users can sign malicious approvals, visit an imitation frontend or misunderstand a transaction preview. A secure core contract cannot protect every external interaction.
For practical use, minimise approvals, verify domains and contract addresses, use test amounts, separate essential funds and understand recovery limitations. These are general safety habits, not a promise that a route is safe.
A layered security map
| Layer | Key question |
|---|---|
| Code | What assets and rules can fail? |
| Economic design | What market assumptions can be exploited? |
| Control | Who can pause, upgrade or move value? |
| Dependencies | Which oracle, bridge or service is required? |
| Operations | How are keys, monitoring and incidents managed? |
| User | What must a person sign or trust? |
| Recovery | What happens after loss or failure? |
Common mistakes
- Treating an audit badge as a guarantee.
- Checking code but not admin keys.
- Ignoring oracle, bridge and frontend dependencies.
- Assuming “decentralised” means nobody can upgrade.
- Treating no past exploit as proof of safety.
- Confusing bug bounty size with code quality.
- Using essential money in a complex experiment.
A no-money security lab
Map a fictional lending protocol with an upgradeable contract, multisig, price oracle, bridge and web interface. Mark:
- assets at risk;
- privileged actions;
- dependency failure paths;
- audit scope and date;
- detection and response controls;
- two risks an audit does not remove.
How this connects to market mastery
Security analysis tests whether utility and economics can survive contact with real systems. It also changes position and operational thinking: uncertainty cannot always be priced; sometimes exposure should simply remain outside the system. Mastery includes respecting risks we cannot model precisely.
Key takeaways
- Protocol risk spans code, economics, control, dependencies and users.
- Upgradeability and immutability have different trade-offs.
- Audits are point-in-time, scope-limited evidence.
- Privileged keys, oracles and bridges deserve direct review.
- Prevention, monitoring, response and recovery all matter.
Completion check: Build a fictional security map and identify what remains uncertain after two audits.
Next lesson: A08-12 incorporates regulation and jurisdiction into fundamental analysis.
*Cryptocurrency and virtual asset transactions are highly volatile and irreversible, may result in significant losses, and do not guarantee returns; customers should trade only after understanding the risks involved.
