lending-analysis

借贷分析

借贷架构会将活动分散在多个事件类型表中（存款／取款／借款／还款／清算），而不是放在一个统一的“借贷事件”表里。大多数错误都源于只查询其中一张表，或关联方式有误。

覆盖范围不止 Aave，且不同事件类型之间并不均衡

借贷表通常涵盖许多协议及其分叉版本，不仅限于显而易见的头部协议（Aave），还包括 Morpho Blue、Fluid、Euler、Maple，以及大量其他分叉版本。默认情况下，不要将查询范围限定为“仅 Aave”；请先检查实际覆盖范围。

不同事件类型的覆盖范围也不一致——范围较窄的表（例如 flashloans）可能只支持部分协议（例如，仅支持原生闪电贷功能的协议），而覆盖范围更广的存款／借款表则涵盖更多协议。如果将闪电贷数据与一般借贷活动关联，就等于默认将协议范围缩小到 flashloans 支持的协议；请明确说明这一点。

没有任何表将“抵押品互换”或“债务互换”标记为事件——需要通过关联推导

通常没有专门的事件类型来标记抵押品互换、债务互换、加杠杆或去杠杆等投资组合管理操作。可以通过 transaction_hash 关联不同事件类型的表，并对比触发了哪些表以及涉及哪些代币来识别：

• 取款 + 存款（代币不同），且没有借款／还款 → 抵押品互换
• 还款 + 借款（代币不同），且没有存款／取款 → 债务互换
• 存款 + 借款 → 加杠杆
• 还款 + 取款 → 去杠杆

因此，仅将 loans 表作为“任何借贷交互”的替代指标，会造成显著漏计——新借款只是部分活动；大量实际头寸管理活动（互换、去杠杆、自我清算）完全不会涉及 loans，而只会出现在其他三张表中。

通常也没有专门的表说明闪电贷“为何”发生（套利、抵押品互换，还是治理／攻击事件）——可以检查其他表是否具有相同的 transaction_hash（例如 DEX 交易表、与治理相关的原始日志模式等）来进行分类，所用的关联方法与上文相同。

关联性能：先按日期筛选，再按哈希关联

借贷事件表通常按 block_timestamp::date 聚簇，而不是按 transaction_hash。若仅按 transaction_hash 进行多表关联（以检测上述模式），将无法进行任何分区裁剪，并会扫描整张表。请先在 CTE 中将每张表筛选到目标日期范围，再进行哈希关联。

不同表的列名不一致——使用前请检查

不要参照同类表猜测列名；命名并不统一：

• withdrawals 使用类似“提款人”的列，deposits 使用类似“存款人”的列，loans 使用类似“借款人”的列，而 repayments 可能同时包含借款人列和单独的还款人列（两者可能不同——其他人可以代借款人还款）。
• 在 liquidations 中，类似代币符号的列通常指的是被扣押的抵押品，另有单独的“还款代币”列指的是被偿还的债务代币——由于两者都是“清算中涉及的代币”，很容易弄混。
• USD 列的命名方式一致（例如 usd_amount）——未经检查，不要假设任何给定的表中存在大小写或顺序不同的变体（amount_usd）。

按交易量排名：排除空值，别让它们占据榜首

缺乏可靠价格数据的资产（常见于特殊的本金代币／生息封装代币）可能有较高的实际交易次数，但 USD 金额为 NULL。如果按“交易量或次数排名靠前的资产”排序时，没有先筛选 usd_amount IS NULL，这些资产就可能因为缺少价格关联而悄然挤掉真正规模较大的资产（主流稳定币、ETH），而非因为它们的实际规模更大。

利用率：按资产计算，而不只是看协议级别

协议级别的综合利用率可能看起来并不高（例如约 45%），但其中的个别市场利用率可能接近 100%（通常是稳定币和 ETH，因为它们往往是需求最高的借款资产）。如果你真正想问的是“这个市场是否紧张”，就应通过按代币分组的市场粒度表，按资产拆分计算利用率（outstanding_loans_usd / supplied_amount_usd），而不是只依赖协议级别的汇总值。

TVL／指标表并非线性流水线，且结果不总是一致

一种常见结构是：细粒度的市场级表（项目 + 协议 + 代币 + 市场，按日终插值）生成两个相互独立的汇总表——一个是具有自身 TVL 类指标的协议级“借贷活动”表，另一个是代币级原始链上余额／TVL 表。它们不是同一个数字的两种计算方式；对同一项目同一天的数据进行比较发现，两者相差几个百分点，这可能是因为各自流水线采用了不同的定价或时间点。每次分析只选用一个 TVL 来源，并始终保持一致——不要在分析过程中混用两者，也不要将它们取平均值。

跨链标准化

在 EVM 链上确立的列约定（例如，表示借贷操作类型的事件类型列）并不意味着非 EVM 链（Solana）就没有对应字段——应通过搜索架构进行验证，而不是想当然地认为存在缺失。即使某条链自身的原生架构表在上游采用了不同结构，跨链／联合借贷表也更有可能为每个来源链都完整填充该字段——优先直接从跨链表中查询，而不要硬编码对各来源链的假设。

清算成交：检查连接两侧的基数

如果一笔清算事件可以由多个部分成交完成，且这些成交共享同一个（用户、资产、时间戳）键，那么将成交级行直接连接到事件级表（一笔清算事件一行，例如被扣押抵押品总额）会导致行数扩增——每多一笔成交，事件级字段就会被重复计数。连接事件级表之前，应先按（用户、资产、时间戳）汇总成交数据，计算 SUM／COUNT。

这是成交到事件的通用基数不匹配问题，并非清算所独有——每当将每个键对应多行的表连接到每个键对应一行的表时，都应先对两侧检查基数（分别按键执行 COUNT(*) GROUP BY key），再判断重复计数问题已解决。也可能“事件级”一侧也存在意料之外的重复行，反而导致低估——只检查一侧的基数可能会漏掉这一点。

---

数据源

每个链数据库都有自己的 lending 架构（<chain>.lending.deposits、 withdrawals、loans、repayments、liquidations、markets_daily、metrics_daily）。 与 DEX 一样，借贷目前还没有专用的跨链数据库——对于涉及多条链的问题，请使用 crosschain.lending 下的多链组合视图（crosschain.lending.metrics_daily、tvl_daily、repayments 以及其他按事件类型划分的表），不要手动合并各链的表。

随着架构演进，表名和列名可能会变化，因此不要凭记忆硬编码以上名称。先运行 data-matching，确认适用于具体问题的当前表；如果需要在编写 SQL 前再次确认某一列，请直接使用 search_schemas／search_docs。