What is DeFi? A Complete Guide to Decentralized Finance

What decentralized finance means

Decentralized finance, usually shortened to DeFi, is a group of financial applications that use blockchain transactions and smart contracts to coordinate activities such as exchanging tokens, supplying liquidity and borrowing against collateral. A user typically connects a wallet and signs instructions instead of asking a bank employee or exchange operator to execute every action. Ethereum is one important ecosystem, but DeFi is not restricted to one blockchain.

The label describes an approach to building services, not a guarantee about safety, access or independence. A protocol can use public contracts while relying on a centrally operated website, an upgrade administrator, an external price feed or a company-issued stablecoin. The useful question is therefore specific: which decisions does the software make, which decisions can people change, and what assets or permissions does the user put at risk? This guide explains those questions through mechanics and hypothetical examples. It does not recommend a token or a deposit.

Read an application as several separate layers

Consider a fictional application called River Pool. Its website displays balances and prepares transactions. A wallet holds the signing authority. Contracts on a selected network record deposits and determine what withdrawals or swaps are allowed. An external price mechanism may supply valuation information. A governance group may be able to change some settings. The same brand name can conceal several distinct responsibilities.

This separation is useful when reading a headline. If the River Pool website stops loading, that is different from its contracts being paused. If an administrator changes a borrowing limit, that is different from the blockchain reversing a transaction. If a displayed balance is wrong, first distinguish a website calculation from the underlying position. A careful explanation names the affected layer and the supporting evidence. Calling everything a blockchain failure makes the story less precise and can conceal the actual exposure.

Smart contracts and the limits of automation

A smart contract is software deployed at a blockchain address. Transactions invoke its functions, and the network applies the programmed rules to the resulting state. In a simple lending design, those rules can record collateral and debt, charge interest and permit liquidation when defined conditions are met. The execution is automatic in the sense that valid transactions follow the code; it does not mean the code understands whether an economic outcome is fair.

Code can contain mistakes, interact unexpectedly with another contract or depend on an administrator who can replace part of the implementation. Reading an audit can help identify what was assessed and when, but an audit is not a promise that every future configuration is safe. Check whether the deployed version matches the reviewed version. For a news reader, a statement that a protocol is audited is incomplete unless the scope, date and relevant changes are identified.

Wallet custody and token permissions

A wallet is the interface for managing signing authority; tokens remain recorded on their respective networks. Connecting a wallet to a page, signing a message and approving a token allowance are different actions. A token allowance can authorize a contract to transfer a specified token amount. A later deposit or swap may then use that permission. The exact effect depends on the token standard and the instruction being signed.

Use a fictional example to separate these ideas. A wallet displays 100 units of token A. A website asks for permission to spend 20 units, then asks for a transaction depositing 10. The resulting position, remaining wallet balance and remaining allowance are three different quantities. A screenshot showing only the wallet balance cannot establish that no permissions remain. This is why reporting about a wallet incident should identify the signed action and the contract involved, rather than describing every signature as simply logging in.

How decentralized exchanges match trades

A decentralized exchange, or DEX, lets users exchange assets through a protocol rather than keeping every trade inside one company’s internal account system. Designs differ. Some use liquidity pools and automated market makers; others use order books or combine several mechanisms. A website or routing service can also send a trade across multiple venues. The front end, router and underlying pool need not be the same organization.

In a pool-based example, participants provide reserves of two assets and traders exchange against those reserves according to a pricing rule. The trader pays a fee, and the pool composition changes. Uniswap’s documentation explains one family of these designs, but a rule described for a particular version should not be assumed to apply to every DEX. Compare the exact contract version, network, asset pair and fee structure before interpreting a quoted output.

Worked example: a simple constant-product swap

Imagine an intentionally simplified pool containing 100 units of asset A and 10,000 units of asset B. Ignore trading fees and assume a constant-product rule: A multiplied by B remains 1,000,000. The initial marginal ratio is 100 B for one A. If a trader adds 10 A, the pool would have 110 A. Dividing 1,000,000 by 110 leaves approximately 9,090.91 B in the pool. The trader receives approximately 909.09 B.

The average execution is therefore about 90.91 B per A, below the initial marginal ratio of 100. This difference arises from the trade changing the reserve balance; the opening ratio was not an unlimited offer. Afterward, the reserve ratio is approximately 82.64 B per A. A smaller trade would change the ratio less. Real transactions add fees, routing and other conditions, so this calculation is a teaching model rather than a quotation.

The reporting lesson is straightforward: a large pool’s displayed spot price and the amount obtainable for a particular trade answer different questions. A useful market explanation states the assumed trade size and distinguishes the starting price, average execution and final pool ratio. None of these three numbers should be substituted for the others.

Price impact, slippage and transaction ordering

Price impact is the change caused by a trade’s own interaction with available liquidity. Slippage is the difference between an expected result and the actual result when execution occurs. A transaction can face both. A minimum-output instruction sets a boundary under the transaction’s rules; it does not make the original quote certain or remove the network fee if execution fails.

Transaction ordering can also affect outcomes. Ethereum’s documentation describes maximal extractable value, or MEV, as value associated with including, excluding or reordering transactions. This includes different activities with different effects; it is not a synonym for every trading loss. In a hypothetical sequence, a trade observed before confirmation can execute after other transactions have changed the pool. The important questions are what was signed, when the state changed, and what execution protection actually applied.

Liquidity providers and inventory exposure

A liquidity provider supplies assets used by a market. The position may earn trading fees, but its asset composition can change as trades pass through the pool. Holding a pool position is therefore economically different from leaving the same initial quantities untouched in a wallet. Fees, relative price movements and contract risks all matter to the result.

Concentrated-liquidity designs allow a position to apply within a selected price range. That can make the position more active around a narrow interval, while introducing range management and the possibility that the position becomes entirely one asset outside the interval. A percentage labelled as a fee return does not describe every part of this exposure. The relevant protocol documentation and the actual range are necessary context. Our separate impermanent-loss guide works through a basic full-range example; it should not be treated as a formula for every concentrated position.

Borrowing against collateral

Many DeFi lending arrangements require collateral worth more than the borrowed amount. A borrower supplies one asset and takes debt in another, subject to asset-specific parameters. Interest can vary as utilization changes. The collateral can remain exposed to market movements even though the borrower receives another asset to use elsewhere.

Aave’s borrowing documentation illustrates why readers need the actual market configuration rather than one universal lending ratio. Different assets and markets can have different borrowing limits and risk settings. A statement that someone borrowed against crypto should identify the collateral, debt asset, observation time and relevant terms. It should not imply that the loan is unsecured, that the interest rate is fixed, or that collateral cannot be sold by the protocol under its liquidation rules.

Worked example: collateral buffers and liquidation

Assume a fictional position has collateral worth $2,000, debt worth $1,000 and a liquidation threshold of 80%. For this simplified single-collateral case, a health-factor-style calculation is collateral value multiplied by the threshold, divided by debt value. The starting result is 2,000 × 0.80 ÷ 1,000 = 1.60. This is an illustrative calculation, not a statement of the current settings of any protocol.

If collateral falls to $1,400 while debt remains $1,000, the same calculation becomes 1.12. If debt instead grows to $1,100, it becomes approximately 1.02. A position can move closer to liquidation because collateral falls, debt grows or the valuation of the debt asset changes. Changes to risk parameters can also matter. Aave documents liquidation eligibility when its health factor falls below one, but actual execution details depend on the applicable system.

The initial buffer is not a forecast of how quickly someone can respond. Network congestion, oracle updates and rapid price moves can change conditions before a user’s attempted adjustment confirms. A responsible article should show the assumptions and identify the mechanism rather than presenting an initial ratio as proof that a position cannot be liquidated.

Oracles connect contracts to outside information

A blockchain contract cannot simply assume that an arbitrary website’s latest number is an agreed fact. An oracle arrangement supplies information that a contract can use, such as an asset price or the outcome of an event. Oracle designs vary in their data sources, update conditions, aggregation and governance. Those details matter when the supplied information controls borrowing limits or liquidation.

For example, two websites can show similar market prices while a lending contract uses a specific oracle with its own update rule. Comparing the websites alone does not establish what the contract saw at a particular block. When evaluating an incident, locate the feed, timestamp and transaction evidence. Distinguish a stale observation, a manipulated source, an integration mistake and a legitimate price move. These explanations imply different causes even if a user-facing balance changed in every case.

Stablecoins and the meaning of one dollar

A stablecoin aims to track a reference value, often a currency such as the US dollar. Different designs rely on different forms of reserves, collateral, redemption arrangements or incentives. The word stable describes an objective. It does not establish that the market price will always equal the reference, that every holder can redeem directly, or that the token has the protections of a bank deposit.

In DeFi, a stablecoin may be a borrowed asset, a trading-pair component or collateral for another product. That makes the exact token important. A native token issued on one network and a bridged representation on another can have different dependencies. If a story says that a pool holds dollars, examine whether it actually holds a dollar-denominated token. The issuer, contract and redemption route provide context that a ticker symbol alone cannot supply.

Where yield comes from

A displayed yield may combine borrowing interest, trading fees, token incentives and other rewards. These sources have different economic meanings. Interest is paid by borrowers under a lending arrangement. Trading fees depend on activity and the allocation rules. Incentive tokens can increase the displayed return while their market value changes. A yield number without its components is difficult to interpret.

As an original hypothetical comparison, imagine two products both display 12% for a recent annualized period. Product A attributes the full figure to fees paid by users. Product B attributes 3% to fees and 9% to a reward token. This does not prove that A is safe or that B is bad. It shows that the same headline number can represent different dependencies. A useful comparison asks whether incentives continue, what token pays them, how the period was annualized and what losses or costs the figure excludes.

Worked example: gross yield versus net outcome

Suppose a hypothetical $1,000 position earns $30 in fees over a stated period and $20 in rewards valued at the end of that period. Entering and exiting costs $12 altogether. The simplified income after those costs is $38, or 3.8% of the initial $1,000. This calculation still ignores changes in the value of the assets held, taxes, failed transactions and any other expenses. It is not a prediction or a current product return.

If the underlying position ends worth $900 before those income items, adding $38 leaves $938. Positive fees did not prevent a negative overall result. Conversely, a rising asset price can produce a gain even when fee income is small. Report income, asset valuation and costs separately before combining them. This prevents a percentage from one component being presented as the return on the whole strategy.

Annualization adds another assumption. Multiplying a short period’s rate by the number of such periods in a year assumes the rate is representative. Compounding additionally assumes reinvestment under suitable conditions. A high annualized figure from a short burst of activity should therefore be described with its measurement window, rather than presented as an amount someone will receive over the next year.

Networks, fees and bridges

DeFi activity takes place on specific networks. Transaction fees pay for execution resources, and Ethereum’s gas documentation distinguishes the amount of work from the price paid per unit. A token balance does not automatically mean the wallet also has the required fee asset on that network. An application can quote a trade without guaranteeing that the user can afford its full execution cost.

Bridges connect activity across blockchain environments, often by locking an asset and representing a claim elsewhere or by using another transfer mechanism. They introduce dependencies that differ by design, such as validators, messaging systems, contracts or custody. A token with the same displayed symbol on two networks is not automatically interchangeable through an ordinary transfer. For research, record the network and contract address alongside the asset name. When a bridge is part of a position, include its failure and exit conditions in the explanation.

Governance, upgrade powers and emergency controls

Governance describes how a protocol’s rules or parameters can change. Some systems use token voting, delegation, timelocks or multisignature administrators. The existence of a vote does not by itself establish that control is evenly distributed. The relevant questions include who can propose, who can approve, how much voting power is concentrated, and what actions can happen outside the ordinary voting process.

An emergency pause can help contain an incident while temporarily limiting users. An upgrade can fix a bug while also creating dependence on whoever can authorize that upgrade. These are trade-offs to describe clearly. A statement that a project has a DAO should lead to examination of its actual governance powers and execution mechanism, rather than an assumption that no person or group can influence the contracts.

A research worksheet for reading a DeFi announcement

Start with identity: record the project, network, contract or market, and the date of the announcement. Then describe the action in ordinary language. Is it a new product, a parameter change, a vote, a code deployment or a marketing statement? Record the evidence that the action happened. A proposal page supports the existence of a proposal; a completed transaction may support execution. Treating those as the same stage can materially mislead readers.

Next, write down the affected users and the route through which they are affected. A fee change may influence future trades without changing an existing loan. A collateral adjustment may concern one asset in one market. A website launch may leave the underlying contracts unchanged. Identify uncertainty explicitly: an announcement might omit a launch time, unsupported regions or the final risk parameters.

Finally, separate explanation from evaluation. It is possible to explain how a feature works without calling it safe, superior or profitable. Compare the announcement with the linked documentation and, where appropriate, transaction records. Preserve credits when another outlet supplied original reporting. This worksheet is an editorial method for asking better questions, not a checklist that certifies a protocol.

Worked example: checking an advertised improvement

Imagine River Pool announces that a new route offers a better exchange rate. Its illustration shows 1,005 units received instead of 1,000, a five-unit improvement. Before treating that as a user benefit, list the assumptions. Are both quotes for the same input quantity, network, asset contracts and moment? Does either quote include a platform fee? Does the new route require an additional approval or bridge transaction?

If the extra route costs eight units in additional expenses, the five-unit improvement in quoted output does not create a higher net result in this example. If it takes longer, the comparison may also involve different price exposure. None of this proves the route is generally worse. It shows why a specific claim requires a specific comparison. A clear article can state that the displayed output improved under the example assumptions while the overall benefit depends on costs and execution conditions.

This approach also applies to claims about lower borrowing rates, deeper liquidity and reduced fees. Name the metric, comparison period, sample and omitted costs. When the evidence supports only a narrow statement, keep the conclusion narrow. Readers gain more from a transparent calculation than from an unsupported superlative.

A compact DeFi glossary

Collateral is an asset pledged to support a borrowing position. Debt is the amount owed under that arrangement, including applicable interest. Liquidity is the availability of assets for trading or withdrawals under the relevant market rules. A liquidity pool is a contract-managed collection of assets used by a protocol. A position is the particular economic claim or obligation held by a participant.

An oracle provides information used by a contract. A token allowance authorizes a specified spender under a token’s rules. A liquidation is an action that reduces or closes an under-collateralized position according to the system’s rules. A bridge connects activity across networks. A governance proposal is a suggested change; it becomes an executed change only through the applicable approval and implementation process.

Total value locked, or TVL, is a valuation measure of assets counted within a defined scope. It is not automatically revenue, unique user wealth, insurance or cash available to every person at once. When comparing published figures, read the methodology and date. Similar labels can hide different counting rules, and a change in asset prices can move a dollar-valued total without an equivalent change in token quantities.

How to use the linked learning cluster

This pillar supplies the context for narrower questions. The impermanent-loss guide isolates how a pool’s changing inventory compares with holding its starting assets. The DEX comparison guide explains what to examine across exchange designs. Existing guides cover lending and liquidation, stablecoins, smart contracts, oracles, governance, bridges and transaction ordering. Move between the broad explanation and the relevant worked example instead of treating any one page as a complete assessment of an application.

Keep three records when using educational material: the assumptions of the example, the date of the documentation and the exact system being discussed. A correct formula can still answer the wrong question if a real position has a different design. A well-supported news story can still leave an important unknown. The purpose of this learning hub is to make those distinctions easier to see and to provide a consistent place to revisit the underlying concepts as new reporting develops.

Sources & further reading

Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.