Skip to content
Financial Context Wiki

DeFi

Decentralized finance (DeFi) is a family of blockchain-based protocols that use smart contracts to provide services such as trading, lending, borrowing, and asset management. This guide explains how DeFi works, why composability matters, how leverage can be hidden by headline metrics, and which technical, market, governance, and user risks require scrutiny.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

Decentralized finance (DeFi) is a broad category of applications that use blockchains, digital assets, and smart contracts to deliver financial functions. Common examples include decentralized exchanges, overcollateralized lending markets, derivatives, payments, and automated asset-management strategies.

DeFi aims to reduce reliance on traditional intermediaries, but it does not eliminate intermediation or trust. Users may still depend on developers, governance voters, administrators, oracle operators, interface providers, stablecoin issuers, bridges, and the underlying blockchain. The relevant question is therefore not simply whether a protocol is “decentralized,” but who can change it, pause it, supply critical data, or control a user’s route to it.

Typical DeFi systems have four layers:

  • A blockchain records transactions and enforces state changes.
  • Digital assets provide the units being transferred, traded, or pledged.
  • Smart-contract protocols encode market, custody, interest-rate, and liquidation rules.
  • Wallets and application interfaces let users sign transactions and call those protocols.

Access may be permissionless at the contract layer while websites, fiat on-ramps, or particular jurisdictions remain restricted.

How it works

  1. The user submits an instruction. A wallet displays a transaction or signature request. The user may transfer an asset, approve a contract to spend a token, or call a protocol function.

  2. The protocol applies encoded rules. Validators execute the transaction, and the smart contract updates balances only if its conditions are met. A lending protocol, for example, can calculate interest, test collateral limits, and trigger liquidation without a loan officer approving each action.

  3. External dependencies provide missing inputs. Many contracts need price oracles, stablecoins, bridges, front ends, keepers, or governance decisions. Those dependencies add trust assumptions and failure paths that are not obvious from the main contract alone.

  4. Composability links protocols together. A token received from one protocol can become collateral or liquidity in another. This makes it possible to assemble new products quickly, but a failure in one asset or protocol can propagate through every position that depends on it.

Blockchain settlement is generally final rather than reversible by a customer-service desk. Public code and transaction data can improve transparency, but transparency is not the same as safety: users still need the expertise and tools to interpret code, permissions, accounting, and market exposures.

Example

Suppose a user deposits $20,000 of ETH into a lending protocol and borrows 14,000 USDC. The initial loan-to-value ratio is 70%, using LTV = V_debt / V_collateral. The user then deposits the borrowed 14,000 USDC into another protocol.

Across the two protocols, dashboards may now show $34,000 of supplied assets, even though the user also owes 14,000 USDC. Before fees, interest, and price changes, the user’s net equity is still $20,000; the extra gross exposure came from leverage, not new wealth.

If the ETH collateral falls to $16,000 while the debt remains 14,000 USDC, the LTV rises to 87.5%. Depending on the protocol’s liquidation threshold, the position may be liquidated, incurring a penalty and execution costs. Congestion, thin liquidity, oracle delays, or a USDC depeg can make the realized outcome worse.

This is why total value locked (TVL) should not be read as net capital, solvency, or safety. Protocol analysis should also examine net deposits, utilization, collateral concentration, liquidation parameters, bad-debt handling, incentive-funded yields, administrator powers, and available exit liquidity.

Risks

  • Smart-contract and upgrade risk. Code may contain defects, and an upgrade mechanism or compromised administrator key can change otherwise audited behavior.
  • Market, leverage, and liquidation risk. Volatile collateral, concentrated positions, or automatic liquidations can turn a price move into a rapid loss and amplify market stress.
  • Oracle and dependency risk. Incorrect, delayed, or manipulated data can cause bad trades or liquidations; stablecoins, bridges, and integrated protocols can transmit their own failures.
  • Liquidity and redemption risk. A quoted balance or yield does not guarantee that a position can be exited at the displayed price, especially during congestion or a run.
  • Governance and operational risk. Voting power may be concentrated, emergency controls may be misused, and front ends or keepers may fail even when the core contracts remain live.
  • Wallet, approval, and fraud risk. Phishing, malicious signatures, unlimited token approvals, counterfeit assets, and lost keys can produce irreversible losses without a protocol exploit.

There may also be legal, tax, sanctions, disclosure, or consumer-protection consequences that vary by activity and jurisdiction. Permissionless access does not make a transaction lawful everywhere or provide a guaranteed remedy after loss.

Common misconceptions

Myth 1: Decentralized means nobody controls anything

Control can sit at several layers. Review upgrade keys, pause functions, governance concentration, oracle selection, front-end hosting, and control of protocol revenue instead of relying on a label.

Myth 2: APR is a guaranteed return

Borrowing demand, utilization, token incentives, and asset prices change. A displayed annual percentage rate may exclude gas, fees, slippage, impermanent loss, liquidation losses, taxes, and the possibility that rewards fall in value.

Myth 3: Higher TVL means a safer protocol

TVL can rise because asset prices increased, incentives attracted short-term deposits, or the same capital was reused across protocols. It does not measure code quality, solvency, governance quality, or executable exit liquidity.

Myth 4: An audit makes a protocol safe

An audit covers a defined code version, scope, and point in time. It cannot prove that every defect was found or protect against later upgrades, economic-design failures, compromised keys, oracle incidents, or failures in integrated protocols.

Sources

Navigation

Search the wiki...