放眼望去，现在谈得上符合币圈要求的借贷平台无一不是要求 Borrower 抵押一定的代币（无论是自己的代币还是公允价值的 BTC/ETH/ 稳定币，超额抵押 / 不足额抵押），使得 DeFi 里的借贷始终存在一个问题：资本效率低下。借贷和其他 Crypto 项目不同，其他项目用冗余换取 trustless，可以不讲究资本效率，但是，借贷的目的就是为了提高资本效率，这一点在传统金融里，有“信贷”来支持机构加杠杆，但是在 Crypto 的世界里，主打的就是一个 Trustless，牵扯到白条信用肯定行不通，那么，如何做一套符合 Crypto 的”信贷“模式呢？DebtDAO 找到了答案：利用 ABS（资产抵押证券，Asset-backed security）

DebtDAO 是一个面向 B2B（DAO 2 DAO）的点对点借贷平台，它最大的特色是 borrower 的抵押品不是现货代币，而是自己平台的收入合约（revenue contract）,通过转移收入合约的 owner 权限，达成抵押的目标，设置好收入分成，等待 lender 注资，启动整个借贷流程。中间还有防止收入合约抵押率不足的清算措施。在 Borrower 还清本息后，协议归还收入合约所有权给 Borrower.

看到这里，大家可能会产生两个问题：

1. 什么样的合约算收入合约？收入合约怎么定价？

2. 如何确保转移了的合约 ownership 一定能被还回来？

所以我们就带着这两个问题接着往下看。

什么是 ABS？

如同一开始讲的一样，DebtDAO 的方案借鉴了传统金融里 ABS 的概念。所以在研究 DebtDAO 之前，我们需要先大概了解下什么是 ABS，即资产抵押证券,Asset-backed security。而要了解 ABS，就得知道什么是资产证券化，这个解释起来其实很简单，就一句话：就是以基础资产未来产生的现金流作为偿付，通过结构化设计进行信用增级。而 ABS 就是在此基础上发行的资产。举个非常简单的例子来说：假设有人想和你借钱，他有很多套房子。常规的做法就是抵押房子借钱，双方点到为止。但是呢，对方和你提了一个新的借贷方案说：”兄弟，你看这样行不行，我现在的房子都在出租当中，不好把房子直接抵押在你这儿，但是呢，我可以把收租权抵押给你，这样每个月的收来的房租用来还债。“这样下来，借方无需损失自己的实际资产，又可以获得对应的经费，而贷方又能获得可预期的本息收益，在理论条件下，双方合作愉快。借款方就可以拿着新借到的钱继续买房子，出租，证券化，继续借钱一直循环下去。房租就成了这个例子里的资产证券化对象。

明白了 ABS 大概的意思，回过头来看下 DebtDAO 的方案。我们先从它的整体业务流程来入手。

DebtDAO 的业务流程

官方目前的文档都是偏向技术的，直接开始讲合约。所以我自己整理了一个业务方向的流程。这里需要注意的是右边”合约“表示的是该步骤直接交互的合约，没有写互相调用的 interface 和一些配套的基础合约。整个流程看起来很简单，我就挑几个关键步骤展开说说：

• 因为目标是 B2B 的服务，所以双方先约定好一些借贷条款，例如利率，到期日，收益分成，抵押率等参数。这里可以需要明白一下收益分成，这个是说从每笔收益里分多少比例给 Lender。这个设计之所以不是一下子就就是分 100% 的收益，是因为考虑到有些新生 DAO 初始资金不足，仅靠借贷得来的钱可能无法支持其持续运营，所以也需要从自己的收入合同里获取一定比例的资金，这样也能让 Lender 获得更为稳定的现金流（毕竟别人干不下去了的话，这收入合同也可能就不值钱了）

• 这里我们可以看到，之所以说它是利用了 ABS 的思路去做信贷，就是把”收入合约“产生的现金流进行贴现，作为抵押品进行借贷，这和上面的把房租证券化的思路是一毛一样的。但是这里和房租例子不一样的地方在于，房租证券化获得的是实打实的法币，那么在众多 DeFi 收益合约里，获得的东西可就不一而足了。这里就牵扯到了我们的第一个问题，什么样的合约才算符合 DebtDAO 的收入合约规范？定价要怎么定。我们先顺着流程往下看，在下面的步骤里会提到这些

• 部署合约。这里我们会发现，这仨主要的合约都是由 Borrower 花钱去部署的，我本来想试下，一看 gas 200 多刀，怕了 - -。但是你去看看官方合约也能明白它的原理。需要强调的是，这些合约都是开源的意思就是说，你可以不用官方前端，自己去 fork 合约部署就行，官方也非常欢迎 fork。刚好，我们就来看看这几个核心合约的功能:

• 检查对应的合约是否算得上收入合约。如果符合标准的话就添加对应合约地址到 Spigot 和 Escrow 白名单。这里的收入合约并没有官方标准，但是总体来说，适用的是诸如 yearn 金库存款手续费，Indexcoop 相关收入合约，NounsDAO 销售合约，还有大量的 defi 手续费分成合约，这也代表，SLoC 本身就可以作为一种 ABS 抵押品。同时 Arbiter 还需要检查收入合约是否和 Spigot 兼容，文末附有一个 100% 兼容条件的 list。

• Arbiter 负责出售收入合约产生的收入，变成 lender 需要的代币。例如收入合约产生的收入是 ETH，但是 lender 借出去的钱是 USDC, 那么 arbiter 就会按比例把 ETH 在对应平台（DebtDAO 的 SLoC 里用的是 0x）换成 USDC，返还到 SLoC lender 的财库里，等待 lender 提取。这里就很考验 Arbiter 的出售策略了，毕竟真涉及到大规模出货的话….

• Arbiter 还负责清算资不抵债的 Spigot（Spigot 到了清算线以下），第一种清算形式如上所说的把收益权 100% 给到 lender，这是 SLoC 需要 Arbiter 去触发的（不设计成自动执行的原因我想是因为 DAO 2 DAO 的借贷，需要的宽限期不固定，并不能一概而论，要视具体情况而言），第二种则是 Arbiter 可以清算 Borrower 还没 claim 的 SLoC 里金库的资金清算了给 Lender

• 因为 Arbiter 的角色如此重要，所以在 DebtDAO 官方的设计里，Arbiter 是由 DebtDAO 自己来承担的（本身也是个独立合约）。但是实际上，arbiter 可以由双方指定，甚至可以由 Lender 自己担任。不过 Arbiter 不是 DebtDAO 的话，并不会显示在 DebtDAO 的前端页面。在前端页面里你会发现就是 Borrower 创建 SLoC。

• 虽然前面说了 Spigot 的 owner 具有调整收入分配比例，转移收入权限的能力，但是由于 owner 是 SLoC, 它里面并没有调整分配比例的功能，这也就是说，你在创建合约时设置的收入比例实际上是无法手动修改的。只有当 Spigot 的价值低于抵押率时（预言机报价），任何人都可以触发状态修改函数，修改对应对应 Spigot 成可清算状态，这就允许把收入比例调整成 100% 归属 owner，一直到债务还清或者预言机报价 Spigot 的价值到了清算线以上。一个 SLoC 里可以抵押多个 Spigot（这也是 ABS 的特点之一）

• 虽然里面设计到了预言机。但是如果把抵押率设置成 0，其实也就没预言机的事情了。

• DebtDAO 官方的 SLoC 仅支持固定利率的利息收取方式，这一方面它主打的是 dao 2 dao 的服务，固定利率可让借贷双方的预期变得可控。同时可以套进去诸如 LIBOR 这样的传统利率。

• 如果仔细看流程图，会发现这里面有一个非常奇怪的角色似乎起到了非常重要的作用，那就是 Arbiter. 我们单独说下。

• owner 可以设置收入分配比例，多少给自己，多少给 manager，同时还能转移合约所有权给别人。更为重要的是，owner 可以设置功能白名单，约束 manager 可以调用的功能，一旦出现意外，就可以把 manager 的权限停掉。你就把这个角色当成是真正的老板。Manager 权限就简单了，负责运营协议，提高收入合约的现金流，和传统公司里的 CEO 没啥区别。

• 这里我们会发现，Spigot 本身就可以作为一个独立产品，在链上通过合约分离了管理财务（owner）和管理产品（manager）。这对于形成规模化的 DAO 或者其他协议来说是非常重要的，如果推广开来，会让整个生态变得更加专业化。

• 具体到 DebtDAO 流程里来，我们可以看到 Borrower 需要把收入合约的所有者权限转移给 Spigot，自己作为 manager 继续运营产品，而 Spigot 本身就会作为抵押品，进行证券化。本息还完后，Spigot 的 owner 权限就会自动转移给 Spigot。当然，这个步骤就不是在 Spigot 里完成了，而是涉及到了 Secured Line of Credit 合约。

• 这里需要注意的是，我们会发现在整个借贷流程结束后，Borrower 获得的是 Spigot 合约，想要把对应收入合约的 ownership 复原，则需要再次和 Spigot 交互，转移权限。当然，一直用 Spigot 合约进行收入合约的管理也没问题。

• Escrow 合约就是最简单的存放抵押品的合约。单独做一个功能简单的托管合约就是为了隔离风险，别忘了软件工程里核心的一句话：高内聚，低耦合。

• Spigot. 实现 trustless 信贷最重要的合约。它做了一件最重要的事情，分离 owner 权限和经营者 (manager) 权限。

• Secured Line of Credit. 上面说了 Spigot 只做了分离权限的事情，那么，如何确保借贷流程的执行，如何确保 ownership 在还款完毕后能被归还给 Borrower，以及作为抵押品的 Spigot 价值过低如何被清算？这些流程都是由 SLoC 来完成的。前面提到了 Borrower 抵押收入合约后可以作为 manager 继续管理产品，获得收益分成。但是 owner 给谁呢？如果直接给 Lender，如何确保 Lender 会归还权限呢？所以，每个 Spigot 的 owner 都是对应的 SLoC. 而 SLoC 就是完成 trustless 信贷的核心合约。它除了涉及到了前面提到的几个”如何“外，需要额外注意的有几点：

• 实际上，Arbiter 就是整套系统里风险最大的点。他是负责管理 SLoC 状态转换的核心角色，主要负责的事情如下：

• 其他流程就没什么需要特别注意的了，就是常规 P2P 借贷的流程。不过，需要再次说明的是，DebtDAO 里的所有合约都是开源的，并且都是可以独立使用的，所以并不是说这个流程就是固定不变的。不同的项目方可以根据自己的需要随意使用不同的合约，还有大量的配套合约和接口这里都没写，大家有兴趣的可以自行去 DebtDAO 官方文档查看

总结

虽然 DebtDAO 刚刚上线，但是这个产品我个人一直在关注，本身的设计和定位足够清晰明了，有一点 Uni 的感觉了。这里面是有可能搞出一些有意思的东西的。而 DebtDAO 和它下面的协议更像是 Filecoin 和 IPFS 的关系，IPFS 是个伟大的发明，filecoin 是 IPFS 的官方实例。同理，Spigot 和 SLoC 也是具有革命意义的设计，官方出了个 DebtDAO 来实例化成具体的产品。他们以一种最大程度符合去中心化精神的形式实现了信贷，加上完全开源，在市场越来越正规的前提下，肯定会诞生出很多有意思的东西。

例如，虽然它官方是一个 D2D 的产品，但是，是否可以做出一个 C2D 的产品？当然可以，学 maple finance, 在 lender 端 toC, 用有锁仓期的池子作为 lender，对接 B 端 borrowers, 变成一支分红基金。再比如，能否用来给各种公链节点加杠杆？让节点把自己的收益打包成收益合约, 可以结合诸如@alkimiya_io 这样的产品，增强节点的现金流，搞出新的玩法。说到节点了，如果再结合 MEV 呢？或者说再结合利率期权的玩法呢？这里面的想象空间太大了。。。。

而且，更为重要的是，这套玩法是可以引入链下的。比如 MetaCartel 之前搞的线下聚会，就用的 DebtDAO 借的钱，抵押的就是门票收入，这时候因为门票还没卖，所以就由 Unlock protocol 作为担保人，抵押了自己的收入合约。具体案例可以看这篇报道《MetaCamp Announces It’s Community-Backed Credit》

而最大的风险点，Arbiter，如果在大家的收入合约写得都非常规范的前提下，是可以交由系统自动执行的，这里面套用 zk 等方式，可以把这个风险消除掉。据我所知，DebtDAO 现在正在做相关的事情，我们可以等等看，大概的思路类似于 Anoma

最后，还是要吐槽一句，DebtDAO 官方文档还是要努力优化呀…………写的都是啥，和直接看合约没啥区别

参考：

《DebtDAO 官方文档》：

https://debtdao.org/

《DebtDAO 官方 market》

https://debtdao.finance/#/mainnet/market/

《与 Spigot 100% 兼容的要求列表》

https://debtdao.org/dev/security-and-monitoring/template-spigot-evaluation

《MetaCamp Announces It’s Community-Backed Credit》

https://debtdao.org/blog/metacamp-announces-its-community-backed-credit

Anoma

https://anoma.net/