Decentralized finance, or DeFi, uses blockchain-based programs to provide trading, lending, borrowing, asset management, and other financial functions. Instead of sending an order to a traditional intermediary, a user signs a transaction that interacts with a smart contract. The contract applies rules visible in code and updates balances on the network.
That description is accurate but incomplete. Most DeFi systems still depend on interfaces, developers, price oracles, governance groups, stablecoins, bridges, and market makers. The useful question is not whether a protocol is perfectly decentralized. It is which functions are automated, which parties retain control, and how technical and economic failures would affect users.
The three layers of a DeFi product
A DeFi product can be analyzed as a settlement layer, an application layer, and an interface layer. The settlement network orders transactions and secures the ledger. Smart contracts at the application layer define the financial rules. Websites, wallet integrations, and data services form the interface through which most users interact. A protocol can keep operating on-chain even when a popular website is offline, but ordinary users may still be effectively blocked without an alternative interface.
The BIS working paper on DeFi technology uses a similar layered model to explain settlement, applications, and interfaces. This framework is helpful because each layer has different trust assumptions. A base chain outage, a contract bug, a manipulated price feed, and a compromised website are separate events even if they produce the same visible result: a user cannot safely complete a transaction.
Decentralized exchanges and automated market makers
Many decentralized exchanges use liquidity pools rather than a conventional order book. Liquidity providers deposit two or more assets, and a formula adjusts quoted prices as traders change the pool’s composition. Trading fees are distributed according to the protocol’s rules. This design allows continuous on-chain trading without a centralized matching engine, but it does not create liquidity from nothing.
Large trades can move the pool price and create slippage. Arbitrageurs bring prices back toward broader markets by trading against the pool. Liquidity providers are exposed to changes in the relative value of deposited assets and may underperform simply holding them, a phenomenon often called impermanent loss. Fees can offset that effect, but the result depends on volume, volatility, range settings, incentives, and contract safety.
Lending pools, collateral, and liquidation
DeFi lending protocols pool assets from suppliers and lend them to borrowers who typically post excess collateral. Interest rates adjust according to utilization or governance parameters. When collateral value falls below a threshold, liquidators repay part of the debt and receive collateral at a discount. The process is designed to keep the pool solvent without traditional credit underwriting.
The model depends on liquid collateral and reliable pricing. Rapid market gaps can leave insufficient value, while congestion can prevent liquidators from acting. A faulty oracle can liquidate healthy positions or allow bad debt. Borrowers also face recursive risk when they deposit a token that represents another protocol position. A single dashboard may show one loan while the collateral embeds several layers of contracts and counterparties.
Oracles connect contracts to outside information
Blockchains cannot directly know the market price of an off-chain asset. Oracles collect and publish data that contracts use for collateral values, derivatives, and settlements. Strong designs aggregate multiple sources, apply time-weighted methods, and include safeguards for abnormal conditions. Weak designs can be manipulated through a thin market or a single exchange.
Oracle risk is partly economic. An attacker does not need to break cryptography if manipulating a price costs less than the profit available from the protocol. Analysts should examine the source markets, update frequency, fallback behavior, and maximum value that depends on the feed. A protocol with secure code can still fail if its external data assumptions are wrong.
Composability multiplies both utility and fragility
Smart contracts can call one another, allowing developers to combine exchanges, lending markets, stablecoins, and derivatives into new products. This composability is often described as money legos. It reduces the cost of building new services and lets users move positions across protocols in a single transaction. It also creates dependency chains that are difficult to see from a front-end balance.
If a stablecoin depegs, an oracle fails, or a bridge pauses, protocols that use the affected asset may liquidate positions or halt withdrawals. Governance changes in one component can alter the risk of another overnight. Due diligence should map dependencies rather than reviewing each product in isolation. Our stablecoin guide provides a framework for one of the most common shared dependencies.
Where DeFi yield comes from
Yield may come from borrower interest, trading fees, liquidation penalties, staking rewards, or token incentives. These sources have different durability. Borrower interest reflects demand for leverage or liquidity. Trading fees depend on volume. Token emissions may be a temporary subsidy funded by new supply. A protocol can display a high annualized rate after a short burst of activity even when the return is unlikely to persist.
A useful analysis asks who is paying, why they are willing to pay, and what happens when incentives decline. Returns quoted in a volatile token should be separated from returns in the deposited asset. Leveraged loops can magnify both yield and loss. If the product description cannot explain the cash-flow source without relying on rising token prices or continued deposits, the economic foundation may be weak.
Governance, admin keys, and upgrades
Many protocols can be upgraded, paused, or adjusted by a multisignature wallet, governance vote, or security council. These controls can respond to bugs and market emergencies, but they also create concentrated authority. Timelocks may give users notice before a change, while emergency roles can act immediately. Neither arrangement is inherently good or bad; the important point is that users understand it.
Token voting can be dominated by large holders, delegates, or teams. Participation may be low, and technical proposals can be difficult for ordinary users to evaluate. Analysts should review who can change collateral parameters, transfer treasury assets, upgrade contracts, and bypass normal procedures. Decentralization is a spectrum across specific powers, not a single label applied to the whole project.
A practical risk review before depositing
Begin with the contract address and network. Identify whether the protocol is upgradeable, who controls emergency functions, and which assets or bridges it depends on. Review audits and bug-bounty programs while remembering that neither guarantees safety. Examine liquidity under stress, oracle design, liquidation rules, and historical incident responses. Use a block explorer or trusted analytics tool to verify that the interface is pointing to the expected contracts.
Start with a small position and test withdrawal before adding more. Limit token approvals, separate experimental wallets, and avoid signing transactions you cannot interpret. Consider the opportunity cost of monitoring: a position that requires constant attention may be unsuitable even if the expected return appears attractive. The operational burden is part of the risk, especially when protocols can change quickly.
- Trace every source of yield to a borrower, fee stream, reward, or subsidy.
- Map dependencies on stablecoins, bridges, oracles, and other protocols.
- Review upgrade powers, pause controls, timelocks, and governance concentration.
- Model liquidation and withdrawal conditions during congestion or a depeg.
- Use small tests and isolated wallets before exposing meaningful balances.
Conclusion
DeFi replaces some intermediary functions with transparent, programmable contracts, but it does not remove risk or human control. It redistributes them across code, collateral, governance, interfaces, and market incentives. The clearest analysis breaks a product into layers, traces the origin of returns, and asks how failure in one dependency would travel through the rest of the system.
