Contract behavior, administrative control, oracle inputs, bridges, composability, and incident planning.
By the end, you should be able to
- Map contract and administrative dependencies.
- Explain why applications need oracles.
- Recognize bridge and composability risk.
A DeFi position is a dependency chain
A visible interface may depend on several independent systems.
Code executes rules—and preserves bugs
A smart contract executes according to deployed code and current state. Audits, tests, and public source code reduce uncertainty but cannot prove the absence of vulnerabilities or unsafe economic design.
Oracles connect external facts
Contracts cannot natively know off-chain prices or events. Oracle systems deliver data under defined source, aggregation, timing, and governance assumptions. A bad input can trigger otherwise correct code.
Bridges add verification and custody assumptions
Moving value between networks may lock assets, mint representations, verify messages, or rely on signers. Composing protocols expands the dependency graph and creates paths for failures to spread.
What this does not tell you
- An audit is evidence of review, not insurance or a guarantee.
- A decentralized base network does not make every application decentralized.
- Emergency controls can reduce one risk while creating governance or key-holder risk.
Draw a dependency map
Select a public DeFi application and identify what must work for users to exit safely.
- List contracts, oracle, network, interface, admin keys, and bridged assets.
- Find public audits and incident disclosures.
- Describe one failure path and one mitigation without assigning a safety score.
Check your understanding
1. Why do many contracts use oracles?
2. What does an audit prove?
3. Why can bridges increase risk?