SAEP-08：链下抵押借贷 - 2025年12月8日

Spark 运营协调员代表嵌套贡献者 Phoenix Labs 已将一项提案提交至投票系统。

审议

根据提案作者所述，Spark 社区可在此对以下变更表达支持或反对意见：

概要

本提案由 Phoenix Labs 作为嵌套贡献者提交，其角色定义详见 Spark 协议文档的 A.6.1.1.1.2.2.2.2.1.2.1.1.1 - 根编辑提案提交要求例外（针对嵌套贡献者） 章节。本提案建议 Spark 治理采纳以下操作流程与授权，以将资金分配至链下抵押借贷安排。

背景

Spark 及更广阔的 Sky 生态系统多年来深度参与抵押借贷领域，MakerDAO 最初的核心 CDP 系统便是 DeFi 中最早提供的抵押贷款产品之一。目前，Spark 继续通过 SparkLend、Morpho 及其他渠道，将资产负债表中的相当大一部分配置于链上抵押借贷。

然而，尽管链上抵押借贷是 Spark 协议的核心，但在链下/中心化金融环境中扩展抵押贷款业务能提供特定优势，并开辟可持续需求的新来源。部分用户由于监管要求、风险偏好、税务考量，或对固定利率、追加保证金通知/延迟清算等特定产品功能的追求，强烈倾向于通过托管/链下服务进行抵押借贷。综合上述因素，尽管链下与链上利率持续存在数个百分点的利差，仍有数十亿美元的借贷需求愿意通过链下抵押借贷来满足，而不愿进入以太坊链上 DeFi。

Spark 目前通过 Maple 协议及其 syrupUSDC 产品参与链下抵押借贷机会。迄今为止运作良好，Spark 贡献者普遍预期与 Maple 的合作关系将持续至未来。但开发额外途径，更直接地将 Spark 流动性部署至链下借贷，也具有显著价值。部分潜在借款人表示，他们更倾向于与最终资金提供方直接合作，减少中间环节；另一些则指出，他们在 Maple 的对手方集中度已接近上限。此外，Maple 通常将贷款期限限制在 1 个月或更短，以确保充足的提款流动性，因此存在一个潜在服务不足的中期贷款（3-6 个月）细分市场。

本提案为 Spark 定义了一个框架和操作授权，即通过作为 SLL 内资金合法所有者的 Spark 资产基金会，参与链下抵押借贷安排。在此安排下，抵押资产和贷款将在合格托管方内进行发放和管理。关键的贷款服务和抵押品管理功能也可外包给信誉良好的服务提供商，确保 Spark 及相关贡献者承担有限的操作开销，并主要专注于贷款发起时的风险承销和定价。贷款发起和账户管理的生命周期被锁定和优化，以最小化对手方风险以及 Spark 资产基金会或 Spark 贡献者操作失败的可能性。

提案详情

我们提议 Spark 治理批准并采纳通过合格托管将资金配置至链下抵押借贷安排的操作流程与授权。

理由

从历史上看，我们观察到链下抵押借贷的借款利率持续比链上 DeFi 借贷高出 1-3%，仅在 DeFi 利率飙升的极短暂时期出现过倒挂。链下场外借贷利率也往往表现出更好的稳定性，例如 Maple 的 syrupUSDC 产品在过去 3 个月内的收益率波动小于 1%。拥有另一种方法来利用这一借贷需求来源，将有利于 Spark 实现收入来源的多元化，特别是在 DeFi 杠杆需求低迷的时期，例如过去几周的情况。

在操作层面，通过托管方进行链下抵押借贷将涉及将流动性转移至链下托管主账户，然后在执行适当的主贷款协议并收到抵押品代理提供的所需抵押品后，再将此流动性转移给借款人。由于交易的具体条款是在链下设定且无法写入智能合约，我们依赖上文修订的 Spark 协议文档来定义链下借贷活动的允许范围和条款。

我们在本提案中规定了可接受的风险参数和贷款条款的外部界限，这意味着不得发放超出这些阈值的贷款。然而，我们预期大多数贷款将比提案中详述的条款具有更严格的风险要求和更高的定价基准，以确保我们与更广泛的市场定价趋势保持一致，并为头寸产生足够的风险补偿。例如，对于期限较长的固定利率贷款（例如 3 至 6 个月），我们预期收取的相对于 SOFR 和 SSR 基准的利差将显著高于提案中列出的最低值。

最初，我们计划与 Anchorage（作为托管方）和 Anchorage Innovations（作为抵押品代理）合作，因为他们提供了一个集成的解决方案，将高度安全的托管与全面的抵押品管理、贷款发起和清算经验相结合，实质上处理了从发起到还款的整个贷款生命周期。未来可能会考虑其他托管方和抵押品代理，但鉴于 Anchorage 的长期良好记录、全面的产品套件、与许多潜在借款人的先前整合和对接经验以及良好的监管合规状况，他们是合适的首选。

提议的 Spark Artifact 变更可在以下拉取请求中查看：https://github.com/sky-ecosystem/next-gen-atlas/pull/140

结果

• 如果“赞成”票数最多，该提案将被批准。相关的拉取请求将被合并到 Spark 的 artifact 中。在需要时，所列变更将由相关方推进实施。
• 如果“反对”票数最多，该提案将被否决。不会实施任何变更。