> For the complete documentation index, see [llms.txt](https://docs.basednut.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.basednut.com/learn-crypto/14-composability.md). # 14 - Composability ## ๐Ÿงฉ Composability: DeFi Builds With DeFi DeFi protocols do not exist alone. A token can be deposited into a pool. That pool can be used by a vault. The vault can interact with a lending market. The lending market can depend on an oracle. One financial system can become a building block inside another. That is **composability**. {% hint style="info" %} **DeFi is powerful because protocols can build on each other. The same connections also allow failures to travel.** {% endhint %} *** ### ๐Ÿงฑ Think LEGO, but With Money Traditional financial products are usually built inside separate institutional systems. DeFi contracts can directly interact with other contracts. {% code expandable="true" %} ```mermaid flowchart LR TOKEN["Token"] POOL["Liquidity Pool"] VAULT["Vault"] LEND["Lending Market"] TOKEN --> POOL --> VAULT --> LEND ``` {% endcode %} Each component can specialize. * Tokens handle ownership and transfers. * DEXs handle exchange. * Vaults handle allocation. * Lending protocols handle credit. * Oracles provide reference prices. * Bridges connect environments. * Wrappers create new execution forms. Instead of one enormous contract doing everything, systems can combine smaller financial primitives. *** ### ๐ŸŒฐ You Already Use Composability A BASED NUT swap already combines several pieces. ``` wallet โ†“ NUT token โ†“ DEX router โ†“ liquidity pool โ†“ other asset ``` On Uniswap, Balancer, or Aerodrome, the interface may make this look like one action. Underneath it, multiple contracts participate. Add wNUT: ``` NUT โ†“ wrapper โ†“ wNUT โ†“ pool ``` Add an LP position: ``` NUT + asset โ†“ liquidity pool โ†“ LP position ``` The system becomes more capable because the pieces can interact. *** ## ๐ŸŒ The Dependency Graph Once protocols compose, your position may depend on things you cannot immediately see. Suppose you deposit into a vault. {% code expandable="true" %} ```mermaid flowchart TD USER["Your Position"] VAULT["Vault"] MARKET["Lending Market"] COLLATERAL["Collateral Asset"] ORACLE["Price Oracle"] USER --> VAULT --> MARKET MARKET --> COLLATERAL MARKET --> ORACLE ``` {% endcode %} You see: > Vault position. But your actual exposure may include: * the vault; * the lending market; * the collateral; * the oracle; * administrators controlling those systems. {% hint style="warning" %} **Your visible position may be one token. Your actual risk may be an entire system underneath it.** {% endhint %} *** ## ๐Ÿ”ฅ Failure Can Travel Suppose: ``` Protocol A โ†“ deposits into Protocol B ``` If Protocol B suffers a loss, Protocol A can inherit that loss even if Protocol A's own contracts work exactly as designed. This is different from: ``` Protocol A has a bug ``` But the user can lose money in either case. That is **dependency risk**. The important question becomes: > What must keep working for my position to keep working? *** ## ๐Ÿ” What to Look For When a DeFi position becomes more complex, identify its dependencies.
DependencyAsk
TokenCan it pause, blacklist, rebase, depeg, or change?
PoolWhere is liquidity actually held?
OracleWhere does the price come from?
VaultWhere can deposited assets go?
BridgeDoes the asset depend on another chain?
AdminWho can pause, upgrade, or reconfigure?
ProtocolWhat happens if another protocol fails?
You do not need to map every contract immediately. Start by identifying the major economic dependencies. *** ## ๐Ÿงฏ Correlated Risk Using several protocols does not automatically mean you are diversified. Imagine three positions: ``` Position A โ†’ USDC โ†’ Oracle X Position B โ†’ USDC โ†’ Oracle X Position C โ†’ USDC โ†’ Oracle X ``` They look different. But they share important dependencies. If USDC or Oracle X fails, all three may be affected. Other shared dependencies can include: * the same bridge; * the same collateral; * the same stablecoin; * the same implementation contract; * the same admin multisig; * the same chain. > **Count shared dependencies, not logos.** *** ## ๐Ÿ—๏ธ Complexity Is Not Automatically Bad Composability is not a defect. It allows protocols to specialize instead of rebuilding everything themselves. For example: ``` wrapper โ†’ representation DEX โ†’ exchange oracle โ†’ pricing vault โ†’ allocation lending market โ†’ credit ``` This can produce cleaner systems. But each connection introduces an assumption: ``` Component A assumes Component B behaves correctly. ``` More composition means more capability. It can also mean more things that must continue working. *** ## ๐Ÿงช Operational Lab: Map One Position Pick one real DeFi position. It can be: * a NUT swap; * a NUT liquidity position; * a wrapped asset; * a vault; * a lending position. Draw only the major components. {% stepper %} {% step %} ### Start with what you own Example: ``` LP position ``` {% endstep %} {% step %} ### Ask what gives it value ``` LP position โ†“ liquidity pool ``` {% endstep %} {% step %} ### Add the underlying assets ``` LP position โ†“ pool โ†™ โ†˜ NUT WETH ``` {% endstep %} {% step %} ### Add important external dependencies Examples: * wrapper; * oracle; * bridge; * reward contract; * vault; * admin authority. {% endstep %} {% step %} ### Ask one question For every node: > **What happens to my position if this fails?** > {% endstep %} > {% endstepper %} If you cannot answer yet, that is useful. You found something you need to understand before increasing exposure. *** ## ๐Ÿšซ Composability Myths * **More protocols = more diversification** โ€” not necessarily. * **More layers = more yield** โ€” not necessarily. * **Safe underlying = safe wrapper** โ€” false. * **Secure wrapper = safe underlying** โ€” false. * **One audited contract = safe system** โ€” false. * **Complexity = bad** โ€” also false. The point is not to avoid composition. The point is to see it to **understand the risks involved for you.** *** ## ๐Ÿ”— Learn More * Immunefi Research * Immunefi Web3 Security Library * CoW โ€” DeFi Security Explained * ScienceDirect โ€” DeFi security research * Hedera โ€” DeFi safety overview Use security and academic material to learn failure patterns, but use canonical protocol documentation when determining how a specific system actually works. *** ## ๐Ÿ“ Final Model ``` Composability = protocols using protocols ``` This creates: ``` more capability + more dependencies ``` The correct unit of analysis is therefore not just: ``` the token ``` It is: ``` the system the token depends on ``` **Learn what your position is connected to before assuming you know what you own.**