Crypto DEFI Explained: How It Works

Crypto decentralized finance, or DeFi, refers to financial applications organized around crypto-system components such as protocol rules, a transaction ledger, and participants that update, store, or read that ledger. DeFi is not one protocol or a single operating model. To understand a particular application, map its rules, the system that records transactions, the participants and services involved, and the infrastructure between users and the ledger. Implementations differ in permission model, consensus, governance, and ledger access. [claim_bis_three_components]

The word “decentralized” is not proof that every part of an application is distributed or free of concentrated control. Crypto and DeFi systems can exhibit substantial de facto centralization even when their stated architecture or ethos emphasizes decentralization. The degree and location of concentration must be assessed for a specific network, asset, application, and time window. [claim_bis_de_facto_concentration]

What Crypto DEFI Explained means

A useful working definition of crypto DeFi is a financial application that relies on crypto-system components and ledger-based activity. This describes a family of systems, not a guarantee about control, safety, access, or outcomes. The accepted architecture claims provide a way to analyze these systems; they do not establish the properties of a particular product.

At a high level, a cryptocurrency system contains protocol rules, a transaction ledger, and a network of participants that update, store, and read the ledger. Implementations differ in permission model, consensus, governance, and ledger access, so the high-level description should not be mistaken for a specification of any one network. [claim_bis_three_components]

For a DeFi application, the BIS reference model distinguishes settlement, application, and interface layers, each with distinct technical dependencies. A system may distribute or combine these layers differently. The model is therefore useful for locating functions and dependencies, but it does not require every application to have three cleanly separated components. [claim_bis_defi_layers]

  • Settlement layer: the part of the reference model associated with recording or settling transactions.
  • Application layer: the part associated with application rules and functions.
  • Interface layer: the point through which a person or another system interacts with the application.

These labels help structure an examination; they do not establish who operates a given component. A user-facing interface may be a distinct dependency from the application and settlement functions. Conversely, components that look separate in a diagram may be combined in a particular implementation. [claim_bis_defi_layers]

Core components of Crypto DEFI Explained

Protocol rules and application logic. Rules define the behavior an application is designed to implement. The accepted claims do not specify the functions, administrative powers, or governance of any particular application. Those details must be established from evidence about the system under review rather than inferred from the DeFi label.

Ledger and network participants. A transaction ledger is updated, stored, and read by network participants in the high-level crypto-system model. The permission model, consensus, governance, and access arrangements vary across implementations. A technical review should identify the relevant network and its actual operating assumptions. [claim_bis_three_components]

Settlement, application, and interface dependencies. The three-layer model separates functions for analysis while recognizing that implementations may combine or distribute them differently. A team can use it to ask where a function occurs, what other components it depends on, and which parts of the system fall within the review boundary. [claim_bis_defi_layers]

Users and supporting components. A financial application may involve users, network participants, interfaces, and other components. The exact arrangement is implementation-dependent. Decentralized exchanges (DEXs) illustrate why the distinction matters: in the public permissionless DEX model used in a BIS comparison, a user can retain control of assets while trades execute or settle through smart contracts on a blockchain. DEX designs differ and can still depend on interfaces, relayers, administrators, or off-chain order components. [claim_bis_dex_distinction]

That DEX example is bounded. Retaining control of assets in the cited model does not demonstrate that every service in the transaction path is decentralized, nor does it establish the custody or control arrangements of every product described as a DEX. [claim_bis_dex_distinction]

How Crypto DEFI Explained works

There is no single transaction flow established by the architecture model. The following sequence is a way to map a particular system; exact steps and components depend on its implementation. [claim_bis_defi_layers]

  1. An action is prepared. A user or connected system interacts through an interface or another access path. The interface is worth identifying as a dependency because it is one of the layers in the reference model.
  2. Application rules are involved. The application layer is where the system’s application functions are analyzed. The accepted claims do not prescribe what a specific application permits or whether other components participate; those facts require implementation-specific evidence.
  3. The network handles ledger activity. In the high-level crypto-system model, participants update, store, and read the ledger. The permission model, consensus, governance, and access arrangements vary by implementation. [claim_bis_three_components]
  4. The system records or settles activity. The settlement layer is the relevant part of the DeFi reference model, but a system may combine or distribute layers differently. A review should establish where the relevant record is maintained and what evidence describes the resulting state. [claim_bis_defi_layers]
  5. A result is presented or read. An interface can display information, but the display itself should not be treated as a substitute for evidence about the ledger or application state. The appropriate verification path depends on the system being examined.

For the cited public permissionless DEX model, users can retain control of assets while trades execute or settle through blockchain smart contracts. This does not describe every DEX: designs can differ and may rely on interfaces, relayers, administrators, or off-chain order components. A reviewer should trace the specific transaction path rather than generalize from the category name. [claim_bis_dex_distinction]

Trust and control boundaries

A blockchain-based design does not, by itself, answer who can operate, change, or interrupt every component. De facto centralization can exist despite a stated decentralized architecture or ethos. To assess concentration, specify the network, asset, application, and time window; a broad label cannot supply that system-specific conclusion. [claim_bis_de_facto_concentration]

A control review can separate three questions:

  • What is documented about the application? Distinguish the stated rules from assumptions about a deployed system. The high-level claims do not establish product-specific administrative or governance powers.
  • How are the layers arranged? Map settlement, application, and interface functions, including where they are combined or distributed and what dependencies they introduce. [claim_bis_defi_layers]
  • Where might control be concentrated in practice? Assess the particular network, asset, and application over a stated time window, rather than treating decentralization as a binary property. [claim_bis_de_facto_concentration]

Asset control and service dependence are separate questions. The cited DEX model permits retained user control of assets during smart-contract execution or settlement, while the broader DEX comparison notes possible dependencies on interfaces, relayers, administrators, and off-chain order components. Neither statement should be extended beyond its scope. [claim_bis_dex_distinction]

Liquidity can also matter when a system has payment or settlement obligations. The CPMI Principles for Financial Market Infrastructures state that designated financial market infrastructures must manage sufficient liquid resources in relevant currencies to meet settlement obligations under normal and stressed conditions. The principle is used here as an operational analogy for crypto payment infrastructure; it does not mean every crypto product is a designated FMI or subject to that standard. [claim_payment_settlement_liquidity]

Limitations and failure modes

The accepted claims do not establish that a particular application is secure, continuously available, recoverable, liquid, or suitable for a particular purpose. They provide analytical models and bounded observations, not product-specific guarantees. A layer diagram, smart-contract description, or decentralization statement cannot establish properties that have not been documented and verified for the system in scope.

Several limits follow from the architecture and claim scopes:

  • Layer boundaries may differ. Settlement, application, and interface functions have distinct dependencies in the reference model, but systems may combine or distribute the layers differently. A dependency may therefore cross conceptual boundaries. [claim_bis_defi_layers]
  • Implementations are not interchangeable. Permission model, consensus, governance, and ledger access vary. Findings about one system should not automatically be transferred to another. [claim_bis_three_components]
  • Decentralization is not binary. Substantial de facto centralization may coexist with a decentralized ethos. Its degree and location require an assessment tied to a particular network, asset, application, and time window. [claim_bis_de_facto_concentration]
  • DEX patterns vary. The cited public permissionless model allows users to retain asset control during smart-contract trade execution or settlement, but other designs and their dependencies can differ. [claim_bis_dex_distinction]
  • The liquidity principle has a defined scope. The PFMI requirement applies to designated financial market infrastructures. Its use as an analogy does not extend the standard to every crypto product. [claim_payment_settlement_liquidity]

These limits also inform incident analysis. If an observed result differs from an expected result, the layer model offers a way to locate relevant dependencies for investigation. The accepted claims do not prescribe a recovery process or establish that a particular transaction or failure can be reversed. Verification and response procedures must be specific to the system and evidence available.

What teams should verify

A technical evaluation should turn the reference models into evidence about a specific system, deployment, and period. A practical checklist is:

  1. Define the review boundary. Identify the network, application, interface, supporting components, and relevant time window. State what is outside scope.
  2. Map the layers. Locate settlement, application, and interface functions. Document where they are combined or distributed and identify each layer’s dependencies. [claim_bis_defi_layers]
  3. Record network assumptions. Verify the permission model, consensus, governance, and ledger-access arrangements for the implementation. These properties differ across systems. [claim_bis_three_components]
  4. Compare documented rules with the system under review. Establish what the application documentation says, then distinguish those statements from observed behavior and unresolved assumptions. The high-level source claims do not supply product-specific controls.
  5. Trace interfaces and supporting components. Identify who or what operates each relevant component. For a DEX, check for interfaces, relayers, administrators, and off-chain order components rather than assuming they are absent. [claim_bis_dex_distinction]
  6. Assess concentration with a defined scope. Specify the network, asset, application, and time window before evaluating where control is concentrated. Do not use a general decentralization claim as a substitute for that assessment. [claim_bis_de_facto_concentration]
  7. Determine whether settlement liquidity is relevant. If the system has payment or settlement obligations, identify the operational requirements that apply. Treat the PFMI liquidity principle as applying to designated FMIs; elsewhere, use it only as an analogy unless applicability is established. [claim_payment_settlement_liquidity]
  8. Specify evidence for state and outcomes. Identify the ledger or application evidence the team will consult and how it will distinguish that evidence from an interface display. The source claims do not prescribe one universal verification method.

A review record can capture the system boundary, layer map, implementation assumptions, control dependencies, evidence examined, and unresolved questions. Keeping conclusions tied to the system and time window examined makes their scope clearer and helps teams revisit them when those conditions change.

Sources and claim scope

This explainer uses high-level architecture and risk observations from the Bank for International Settlements, a comparison of decentralized exchanges, and the CPMI Principles for Financial Market Infrastructures. The liquidity point is limited to designated FMIs and is only an operational analogy for other crypto payment infrastructure. These sources do not establish the properties or regulatory status of a particular product.

References

  • Bank for International Settlements, Cryptocurrencies: Looking Beyond the Hype.
  • Bank for International Settlements, The Crypto Ecosystem: Key Elements and Risks.
  • Bank for International Settlements, The Technology of Decentralized Finance (DeFi), Working Paper 1066.
  • Bank for International Settlements, The Anatomy of Decentralised Exchanges, Working Paper 1227.
  • Committee on Payments and Market Infrastructures, Principles for Financial Market Infrastructures overview.

Sources and references