DeFi 可组合性：梳理收益背后的依赖关系

一个仓位可能涉及多个系统

可组合性允许智能合约与其他合约交互，把功能组合成更大的应用。Ethereum 的可组合性文档将其视为应用开发的基础构件。从金融分析角度看，同样的便利也带来依赖问题：一个简单的存款界面背后，可能隐藏着多个合约、资产及控制系统。

设想一个金库接受稳定币，将其借出、获得凭证代币，再将凭证存到别处赚取额外奖励。可见余额不是单一现金账户，而是一连串权利，其赎回依赖底层步骤。增加层次可以改善功能，却不创造独立的安全来源。

为每一层画出资产负债表

从终端用户的资产出发，追踪金库实际持有什么。识别金库是否负债、是否提供无抵押或抵押贷款，以及凭证是否能够立即赎回。然后继续追踪下一层凭证的支持资产。只有当经济敞口清楚时才停止，而不是看到一个熟悉的协议名称就停止。

有用的示意图用实线箭头表示资产索取权，用虚线箭头表示预言机、跨链桥和管理员等依赖。两个金库可能持有不同凭证，却依赖同一种抵押代币或同一个紧急多签小组。仅数协议名称看似分散，依赖关系图却可能揭示集中敞口。

区分收益来源与代币增发

将报价收益拆分为借款人利息、交易费用、质押奖励和激励代币。各组成部分的驱动因素不同。奖励代币显示的美元价值取决于价格及其出售能力；它不等同于同额、可立即使用的基础资产收入。费用、借款成本和再投资支出应列在计算的支出端。

假设仓位为 $10,000，年化借款利息收入 $400，加上价值 $600 的奖励代币，显示的毛收益率为 10%。若操作费用为 $100，且奖励代币在卖出前价格减半，则示例中的实际实现额为 $400 + $300 − $100 = $600，即 6%。该计算假设本金与时点不变；它不是预测。

反向测试退出过程

进入可能很容易，退出却可能需要连续完成多次赎回。应确认哪个市场必须先提供流动性、是否有提现队列，以及释放抵押品前是否必须偿还债务。今天交易活跃的凭证，在许多持有人同时需要退出时可能变得缺乏流动性。

制作一份带时间戳的纸面退出流程。每一步都记录收到的代币、所需 Gas、价格不确定性，以及可能阻碍后续操作的条件。如果某协议暂停提款，上游金库即使自身代码没有缺陷，也可能无法付款。这是依赖环节故障的传导，并不一定意味着每一层都资不抵债。

评估共同控制机制与有限定范围的权利

审查谁能升级金库、改变路径或加入新资产。治理行动后，策略描述可能过时。审计可能覆盖金库合约，却不覆盖未来每项集成。区分不可变约束与管理者裁量，并核实已部署版本中哪些权限仍然有效。

比较时，应编写一页风险清单，而不是仅按收益率排名产品。纳入最终资产、杠杆、提现顺序、共同依赖及未知事项。如果某项关键依赖无法确认，应标注分析尚不完整。界面显示的年化百分比再精确，也无法弥补对持有对象的不确定性。这项练习的目的是理解结构，而不是建议参与。

一个颇有启发的练习是问：如果激励奖励明天降为零，还剩下什么？在不假定能卖出奖励代币的情况下，重新计算收入、支出与退出能力。这不是预测奖励会结束，而是识别该结构是否具有底层经济收入来源，或其表面吸引力是否主要依赖持续补贴与其他人购买所分发代币的意愿。

从退出目标反向画出依赖关系

进入应用时看到的页面，往往只是最外层。要最终取得银行账户中的现金，可能先要偿还借款、释放抵押品、赎回凭证、跨链转移，再完成卖出和提现。每一步都可能依赖不同服务，也可能要求前一步先成功。

从最终需要的资产和到账时间反向推演。在每个环节，什么资产必须可用？谁有权暂停操作？是否需要新的签名、网络费用或市场买方？把只在正常条件下可行的路径标出来，尤其注意紧急情况下可能同时拥堵的几个步骤。

使用两个协议，不一定构成独立的风险来源。如果它们都依赖同一个预言机、跨链桥或抵押资产，一个故障可能同时影响两边。评估分散程度时，应寻找共同的关键依赖，而不是仅按应用名称或页面数量计算“分散了几份”。

借款会放大自有资金的价值变化

假设资产价值30,000欧元、债务10,000欧元，自有净值就是20,000欧元。若资产下跌10%，而债务暂时不变，则资产剩27,000欧元，净值为17,000欧元，下降15%。这里尚未计入利息和费用，资产跌幅与自有资金跌幅并不相同。

这是资产负债表的示例，不是完整的清算模型。实际清算条件还可能依赖抵押品系数、预言机价格、债务增长和具体市场规则。估值中采用的价格，也不保证是立刻平仓时能够实现的成交价格，因此不能直接用净值计算替代退出分析。

练习同时制作两张表：一张记录经济价值，另一张记录每一步能够自由动用的流动性。净值为正，不等于眼前的支付要求一定能够满足。有足够价值和在正确时间拿到可用资金，是相互关联但不能互相替代的条件。