DeFi Dependencies, Stablecoins and Governance

DeFi applications can compose several familiar components into one unfamiliar risk path. A lending position might depend on a stablecoin, bridge, oracle and upgrade authority at the same time. This lesson makes those dependencies visible and shows why several applications are not necessarily independent sources of safety.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Draw the whole dependency stack

Think about a flat on the tenth floor of a building in Istanbul. Your door lock might be excellent, but you also depend on the foundations, the lifts, the wiring and the people who manage the building. A failure on any floor below can reach you.

Using a DeFi app is similar. You depend on the blockchain it runs on, the smart contracts, the price data those contracts read, any stablecoins involved, the website you use to reach it, the people who govern it, and finally your own wallet and habits. Failures have happened at many of these layers, some costing hundreds of millions of US dollars.

We will trace the data, assets, code and people in this stack, connecting each layer to the others.

A keeper may submit actions such as liquidations or updates; its availability and incentives can matter under the design.

Open diagram at original size ↗

Read diagram as text

From the bottom upward: blockchain outages or reorganisations; smart-contract bugs, upgrades or admin keys; oracle manipulation; stablecoin depegging; front-end or DNS hijacking; governance and treasury attacks; and the user’s approvals, signatures and settings.

A red path illustrates failure reaching the deposit through the stack. Layers can fail together; the diagram is an inventory for questions, not a safety score.

Oracles, depegs and a rush to exit

A stale oracle can assess collateral differently from the current market. Manipulation can make a price feed or thin pool misleading. A stablecoin depeg can reduce collateral value or increase the cost of repaying debt measured in another asset. An exit route may also lack liquidity precisely when many users want to leave.

Apply a combined stress case. If collateral value falls while debt interest grows and network congestion delays a repayment, the health factor can deteriorate faster than a single-price example suggests. A reassuring wallet balance does not show whether the protocol can be exited. Record which value the protocol uses, which value a market can execute and what action would be needed. These can diverge under stress.

See how oracles can be manipulated

An oracle supplies information that a contract uses, such as a collateral price. A thin pool can be moved by relatively little trading, so using its momentary price as the only borrowing reference can let an attacker overstate collateral value.

Inspect source diversity, liquidity, update timing, averaging, deviation limits and fallback behaviour. Multiple reporters do not provide independent evidence if they all read the same fragile source.

Remember stablecoin and run risk inside DeFi

Much of DeFi is priced in stablecoins. Lending pools lend them, liquidity pools pair them, and yields are quoted in them. If a stablecoin loses its peg, every position built on it is hit at once. In the stablecoin and transfer lessons in Level 3 you studied how the algorithmic stablecoin UST lost its US dollar peg in May 2022, and LUNA collapsed; that collapse spread through every DeFi app that relied on it.

Run risk is the second problem. A lending pool lends out most of its deposits. If many suppliers try to withdraw together, the money may not be there until borrowers repay or are liquidated, much like a bank run. The BIS has warned that DeFi has few of the shock absorbers banks have, and that forced liquidations can deepen a fall.

Think of a busy restaurant in Cape Town where everyone tries to leave by one door when the fire alarm sounds. The exit was fine for normal traffic, not for everyone at once. Ask how a protocol behaves in a rush, not only on a calm day.

These data and asset risks belong alongside the code and governance checks in the next two steps.

Composability means applications can interact and reuse assets or functions. This can enable useful services, but it also transmits failures. A receipt token used as collateral connects the lender to the original pool's accounting and exit rules. A contract that assumes another token transfers normally may fail with a restrictive or unusual implementation.

An economic exploit can use permitted actions in a way that undermines incentives or valuations. The code might execute as written while the design's assumptions fail. Short-lived borrowed liquidity, transaction ordering and concentrated voting power can matter depending on the mechanism. Beginners need not reproduce an exploit. They should recognise that code correctness and economic robustness are separate questions, both of which require review.

Understand smart contract bugs

A smart-contract bug can allow an unintended action, such as withdrawing too much collateral or bypassing a required check. Economic weaknesses can also produce loss when code runs as designed. Keep those mechanisms separate when reading an incident report.

An upgrade deserves fresh review because new code or changed parameters can introduce a failure absent from the older version. A past audit applies to its actual scope and version, not to every later change.

Know what a flash loan is and how attackers use it

Imagine a bank in New York lending you US$100 million for one second, on one condition: if the money is not back by the end of that second, the loan never happened. It sounds impossible in ordinary finance. In DeFi it exists.

A flash loan is a loan with no collateral that must be borrowed and repaid within a single blockchain transaction. If repayment fails, the whole transaction is undone, so the lender takes no credit risk. Honest uses include arbitrage between DEXs and refinancing loans.

The danger is that a flash loan gives anyone huge temporary buying power. An attacker can borrow millions, push a thin market or a vote, exploit a flaw while the effect lasts, repay the loan and keep the profit, all in seconds. The Euler attacker used flash-loaned funds, and you will see an even bolder case in the governance section. A flash loan is a tool, not a bug; the bug is any design that trusts something a flash loan can move.

Bugs and manipulation come from outside. The next risk comes from the people who built the protocol.

Front ends, administrators and governance capture

Check who holds the admin keys

In the Ethereum and contract lessons in Level 4 you learned that smart contracts usually cannot be changed once deployed unless their builders designed a way. Many protocols do build one. ethereum.org explains the common proxy pattern: users talk to a contract that stays at the same address, while the logic behind it can be swapped for a new version.

Upgrades let teams fix bugs. They also mean someone holds the power to change the rules. An admin key is the key, or set of keys, allowed to upgrade a contract, change settings or pause it. In the token research lesson in Level 5 you saw how an upgrade can become a rug pull. ethereum.org lists the risks plainly: whoever controls upgrades must be trusted, and developers could change contracts without users' consent.

Those two safeguards have names. A multisig requires several keys to approve an action, so one stolen or rogue key is not enough. A timelock delays approved changes, giving users time to leave. Neither is perfect: the multisig signers may all work for one company, and a timelock does not help someone who never checks. The bridge lesson in Level 4 showed why the authority that verifies transfers is itself a dependency to inspect.

Even with sound contracts and careful admins, you can still be attacked through the website you use to reach them.

Watch the front end and apply your approvals lesson

The front end is the website or application through which a user reaches the contracts. It can be compromised even when the underlying contracts have not changed. An attacker may insert an additional approval or prepare a transaction with different effects.

This is why contract review and signing review belong together. A hardware signer can help display what it is asked to authorise, but cannot decide whether the contract or instruction is suitable. Review the asset, spender, amount and action each time.

Meet governance tokens and DAOs

Many DeFi protocols are run, at least on paper, by their users. ethereum.org describes a DAO (decentralised autonomous organisation) as a collectively owned organisation whose rules and treasury are managed by smart contracts. You met The DAO's story in the Ethereum and contract lessons in Level 4; today the word covers thousands of groups.

In token-based DAOs, holding the governance token gives voting power, usually one token, one vote. Anyone can write a proposal, such as changing a fee or spending treasury funds, and holders vote. Because tokens trade on exchanges, anyone can buy influence. Many holders delegate their votes to active community members, a little like electing a representative. The DAO's treasury is held by contracts that pay out only when a vote passes.

Think of a housing co-operative in Berlin where each share carries one vote. It sounds democratic, until one investor buys half the shares. Level 10 looks at how protocols decide on upgrades, from improvement proposals to on-chain votes. Here, the practical question is who actually holds the votes.

Ask who really holds the votes

The BIS has called this the "decentralisation illusion". Every DeFi protocol needs some central decision-making, and governance tokens are often concentrated: many projects allocate a large part of their tokens to insiders, as you saw in the supply and allocation lessons in Level 5. Turnout can also be low, which makes a large holder even more powerful.

Treasuries make this matter. A DAO treasury may hold large sums, and a vote can move them. The Mango Markets attacker later used governance tokens obtained in the attack to vote on a proposal returning part of the funds on their own terms. Governance can be bought, borrowed or captured, and the next case shows how fast.

Learn from a governance attack

Governance can become vulnerable when temporary voting power is enough to execute a valuable change. Borrowed tokens, low turnout, weak proposal checks or concentrated delegates can alter the outcome.

Protocols can use snapshots, borrowing-resistant voting rules, timelocks, quorum requirements and execution reviews. Each has a scope and trade-off. A delay is useful notice only if users can discover the change and make a feasible response. Examine the actual governance pipeline rather than treating the label DAO as protection.

A timelock may provide notice but does not guarantee a liquid exit. An upgrade can invalidate assumptions used in an earlier report, so review dates and versions are important. Audit reports, public code, long operating history and insurance claims each have a scope. Insurance may involve a separate provider, exclusions, discretionary claims or limited funds. A past absence of loss cannot prove future safety.

TVL, incident history and stop conditions

Your protocol worksheet should cover identity, versions, assets, permissions, data, authority, liquidity, fees and exit. Add unresolved questions and explicit reasons to stop, such as unsupported token identity, unclear redemption or an unexplained administrator power. A stop condition should be observable; the project feels risky is less useful than the deployed address does not match current documentation.

Use paper practice and published information. You do not need a live deposit to demonstrate understanding. A sound conclusion can decline further action while identifying evidence that would permit further research. The next level introduces analysis tools, which should be used to describe observed information rather than conceal these underlying dependencies behind a price chart.

Check protocol data and incident histories

Public dashboards can help organise research. A TVL figure estimates the value counted under a stated method; it does not certify safe custody or count independent capital perfectly. A recorded-incident database can suggest questions about code, keys, oracles and governance. Verify a specific incident against primary disclosures before repeating its cause or loss amount, and record the date and coverage of any numerical total.

Read TVL carefully. It rises and falls with token prices, not only with deposits. The same money can be counted twice when a token from one protocol is deposited in another. And a large TVL tells you people have deposited, not that the code is safe; Euler and Beanstalk both held large sums. Use incident histories to ask whether a protocol, or code it copied, has failed before, and how the team responded.

Put all of this together in one list you can use every time.

Use a DeFi risk checklist

No checklist makes a protocol safe. It tells you which risks you are choosing to accept, and whether you can afford the worst case. Choosing not to use an app is always a valid result.

Now try the checklist on some scenarios.

Try the following questions aloud or on paper before opening the worked answers. Compare your reasoning as well as your final answer.

References and further reading