稳定币 - crvUSD
Last updated
Last updated
稳定币一直被投资者称为“CRYPTO圣杯”，特别是在DeFi Summer以后，链上流动性市场开始繁荣，稳定币这块战场成为了兵家必争之地。
在2020-2021，DeFi最活跃的这几年，去中心化稳定币，抵押稳定币，算法稳定币层出不穷，更有每条链都要发行一个稳定币的趋势。
在今年各大头部协议也开始依靠自身的市场资源，纷纷进入稳定币战场，比如Curve的crvUSD，Aave的GHO。
究其原因有以下几点：
稳定币是链上的价值尺度和支付手段，应用场景的刚需，不管是手续费还是铸币税，其带来的真实业务收入非常可观。
成为链上美联储，吸收大量TVL，控制巨额的流动性。
为协议本身的业务扩展提供最具便利性，成本最低的基础设施。
Curve Finance 的稳定币设计属于超额抵押型稳定币。这种稳定币是通过使用其他资产（如 ETH）作为抵押来铸造（或借用）的，基于特定的利率和抵押品的价值。这种类型最著名的协议是 MakerDAO 的 DAI。
在这种模型下，协议通常会设置一个最低保证金率，当用户的保证金率到达此阈值之后，清算者可以来清算掉用户的部分资产，以保证稳定币的稳定和协议健康。
上图中假设Bob作为稳定币用户，Lucy作为清算人的一种场景。当用户的仓位触及清算线时，通常系统会鼓励清算人的介入来偿还债务。
最终清算人获取利润，被清算的用户面临罚金，系统清除了债务。
这套机制里存在一个待优化的 清算问题。
上面这种类型的稳定币架构总是有一个清算机制。清算是指当抵押品的价值下跌到某个价格时，导致抵押品的价值不再支持借用的稳定币，此时，抵押品（部分或全部）将以有利的价格被拍卖，以填补借用稳定币的缺口。然而，这种清算模型存在几个问题：
当大额资产被清算时，许多抵押品将流入市场，导致市场波动。
在大多数情况下，清算者会出售被清算的抵押品以获利，导致抵押品的价格再次下跌，从而导致另一波清算，形成连环清算。
在某种特殊情况下，如果资产价格持续急速下跌，清算人没有充足动力入场，或者外部流动性不足以支持清算量，清算不能及时完成，协议将会面临坏账的风险。
清算过程不可逆，被清算的用户将遭受永久性损失。即使抵押品的价格反弹，已经被清算的抵押品也无法恢复。
鉴于这些问题，Curve 希望通过以下方式改进稳定币设计中的清算问题：
不依赖外部 DEX，因为 DEX 流动性是不可控的。
在清算发生时尽量减少用户的损失。
逐渐清算用户的抵押品，并在价格反弹时将其转换回来。
Controller 和 LLAMMA 主要负责与抵押品清算相关的工作 (蓝色框部分)。
Monetary Policy、PegKeeper 和 Stable Pool 主要负责将稳定币锚定到 1 美元相关的工作(绿色框部分)。
稳定币用户通过与Controller合约互动来管理仓位，比如： - 创建仓位 create_loan - 添加抵押品 add_collateral - 移除抵押品 remove_collateral - borrow_more, repay, liquidate….
Controller合约控制用户资产与LLAMMA交互。
套利者通过套利交易与LLAMMA交互协助清算。
Monetary Policy获取当前利率，以调控利率。
LLAMMA是crvUSD特有的借贷清算AMM算法，它的特点是在抵押品的价格低于特定价格时，池中的抵押品将逐渐变为 crvUSD。相反，当价格高于特定价格时，crvUSD 将逐渐变为抵押品。
通过LLAMMA完成清算，也被市场上称之为“软清算”，它相比较传统的抵押清算算法，最大的特点是当抵押品价格回归时，用户可以回收抵押品。
下图以 ETH 做为抵押品为例，对LLAMMA的工作原理进行解释。
P_Oracle（横轴）：外部价格。
P_AMM（纵轴）：内部价格。
蓝色线为一个斜率为 1 的直线，表示 P_Oracle 外部价格的变化。
红色线表示 P_AMM 内部价格的变化。
P_CU 和 P_CD 分别表示某个 band 范围内的上下限价格（内部价格）。
P_UP 和 P_DOWN 分别表示外部价格坐标中选定的两个参考边界价格（外部价格）。
价格变化：
当 ETH 价格高于 P_UP（黄色范围）时，该band范围内的所有资产将转换为 ETH。
当 ETH 价格低于 P_DOWN（绿色范围）时，该band范围内的所有资产将转换为 crvUSD。
当价格位于 P_UP 和 P_DOWN 之间（白色范围）时，资产将处于部分 ETH 和部分 crvUSD 的状态，ETH 和 crvUSD 的比例由价格变化决定。
套利清算：
那么crvUSD和抵押品 ETH 之间的转换是谁来完成的？
「套利者」
当外部价格 P_Oracle 变大时，P_CD、P_CU 和红色线的斜率高于蓝色1:1线，所以它代表内部价格会以更快的速度变大。同理当外部价格 P_Oracle 变小时，内部价格也会以更快的速度变小。
所以，在LLAMMA的设计中，即使不发生交易，LLAMMA 内部价格也会随着外部价格自动改变，且变化速度更快。
这种价格变化速度上的差异创造了套利空间，鼓励套利者介入来完成上面提到的LLAMMA池中 ETH 和 crvUSD 之间的转换。当 ETH 价格下跌时，AMM 内部价格会下跌的比外部价格更多，套利者会在 LLAMMA 中买入价格相对较低的 ETH，因此 LLAMMA池中的 ETH 减少而 crvUSD 会增加。
套利者从 LLAMMA 中买入 ETH 的行为其实就是在清算用户的资产，并为LLAMMA注入了crvUSD，而套利者的获利即为买入的价差。假设转换完成后LLAMMA得到的 crvUSD 大于用户的债务，那么协议将不会有坏账风险，并且整个过程不需要传统借贷协议中清算者角色的介入。
📖 下面用图示来详细展示这个过程：
当 P_AMM > P_Oracle 时，套利者将开始存入 ETH 并取出 crvUSD，P_AMM 线（红色）将开始向右移动，直到 P_AMM = P_Oracle 再次平衡。
当 P_AMM < P_Oracle 时，套利者将开始存入 crvUSD 并取出 ETH，P_AMM 线（红色）将开始向左移动，直到 P_AMM = P_Oracle 再次平衡。
首先，LLAMMA 将抵押品价格范围划分为不同的价格段，称为band。当用户存入抵押品时，他们需要提供：
抵押品的数量
存储抵押品的band数量
要铸造多少crvUSD
抵押品将根据要存储的band数量被平均分成小块，并然后根据当前价格和铸造的 crvUSD 存储在由band组成的连续价格范围内。下图显示了在计算后将 10 ETH 存储在 5 个band中的分布情况，每个带状存储 2 ETH 的 5 个小块。
此外，应注意，每个band都有一个上限价格（P_UP）和下限价格（P_DOWN）。前一个band的上限价格也是下一个band的下限价格。
例如，上图中 band0 的上限价格（3000）也是 band−1 的下限价格（3000）。每个band的上下限价格代表该band的清算开始和结束价格。当价格达到上限价格时，存储在该band中的抵押品将开始被清算，直到价格达到下限价格，表示清算结束（意味着该band中的所有抵押品已转换为 crvUSD）。
对比传统的抵押清算模式
LLAMMA自带流动性，不依赖外部的流动性支持，缓解了因外部流动性不足而无法及时清算抵押品的情况。
减少了对清算者角色的依赖，缓解出现清算不及时的情况。
清算是连续性而非阶段性的，每次资产被卖出时比较贴近市场价格，缓解用户损失。
第一道防线：PegKeeper调整货币发行量
第二道防线：Monetary Policy调控利率
PegKeeper 也叫做 stabilizer，是一组用来帮助 crvUSD 价格维持锚定的合约，其工作原理是通过铸造和销毁稳定币来调整稳定币的供应量，以此来影响市场价格。这些合约主要用来和 crvUSD 相关的池进行交互。
当 price >1 时，意味着 crvUSD 供给不足，PegKeeper 会在不需要抵押的情况下 mint 出 crvUSD 并添加到 Curve V1 池子中，以增加 crvUSD 的市场供给。
当 price<1 时，意味着 crvUSD 供给过剩，PegKeeper 会将之前添加的流动性从 Curve V1 池子中移除，以减少 crvUSD 的市场供给。
由于添加时 crvUSD 价格高，移除时 crvUSD 价格低，PegKeeper 在偿还债务后会剩余一些 LP token，这些 LP token 就是 PegKeeper 产生的利润。这些利润会在每次外部调用者调用 PegKeeper 合约时将产生利润的 1/1000 分给外部调用者作为 gas 补偿和激励，剩余的利润则会保留作为协议收益。
这个方法会存在一个问题，就是PegKeeper铸造crvUSD能力和销毁能力是完全不对等的。理论上PegKeeper拥有在无抵押的情况下无限铸造crvUSD的能力，但是在销毁crvUSD的时候，它只能回收的上限源于之前铸造了多少crvUSD的量。
也就是说，会出现一种情况，PegKeeper已经回收了全部额外铸造的crvUSD，但仍然无法使其锚定到1。
这种情况下，就需要第二个锚定措施 Monetary Policy。
一个动态调节借贷利率的组件，用来根据市场供需调节利率，进一步帮助稳定 crvUSD 的价格锚定，主要用于 crvUSD < 1 的情况。
如下图，当价格大于1时，借款利率极小。当价格小于1时，借款利率迅速上升。这将导致铸造 crvUSD 的借款人迅速偿还债务，否则他们的抵押品可能会被清算。
参考文献：
LLAMMA对Oracle数据进行了EMA处理，以防止剧烈波动对协议造成不必要的损失。具体细节我们在 中进行了讨论。
