Haven 3.0开发初步提案

的

需要注意的是，这个提议是 建议草案.
尚未就我们的代币经济学做出任何决定，也没有什么是一成不变的。

本文档中提出的所有内容都是与社区进一步讨论的想法，一旦达成协议，我们将再次发布公告。

自从转换是 暂停，经济学工作组 (EWG) 的成员一直在忙于研究解决方案，以使 Haven 网络恢复到完全正常运行的状态，而不会像 Terra 生态系统持有者那样让 Haven 社区面临进一步的恶性通货膨胀风险。

如果没有社区的投入，这项工作会更加困难，并且会花费更长的时间。
我们的许多成员提出的想法，并由我们整理 x自愿的v 在 这个文件，为 EWG 团队提供了合作的基础，这最终导致我们提出了此处提出的提案。

我们认为我们已经提出了一个可行的解决方案，我们希望在我们的 1TP3财富经济学 获取社区反馈的渠道。
这些讨论对于完善模型并最终提出功能解决方案非常重要。

对某些人来说，这里提出的措施可能看起来很苛刻和不公平，但我们必须记住，该协议目前处于糟糕的状态；我们必须确保它不会变得更糟，并给协议时间来恢复。

值得提醒大家的是，Vault 从未打算用作交易工具；我们鼓励大家在交易所交易 XHV 和 xUSD，这将提高采用率并增加流动性。

Terra 的发展路径给出了一个提示，试图将比特币池用于混合支持的算法稳定币，以免它们变得太大，以至于其稳定性机制无法处理极端的外来冲击。

但Haven不同；隐私方面防止将公共区块链、抵押品和稳定币用于支持目的。

到目前为止，算法稳定币模型的关键问题是代币经济学设计意味着稳定币价格受到支持而损害了原生资产价格。
在 Haven 的情况下，这意味着购买便宜的 xUSD 铸造成 XHV，然后在市场上出售 XHV。这会对原生资产价格造成持续抑制，如果原生资产价格无限期下跌，可能会导致死亡螺旋和对稳定币的完全丧失信心。

有点违反直觉的是，不优先考虑稳定币价格而是保护原生资产价格的代币经济学设计作为一个生态系统具有更长的寿命，因此对稳定币的价值有更大的信任。

于是 EWG 团队想出了一个新颖的想法； Haven 正在加倍努力“成为你自己的银行”，并将要求以 XHV 的形式提供抵押品以使用支持功能。

新思路可以用一句话概括：

对于陆上/海上，您的保险库中必须有等值的未锁定 XHV。

我们将此想法称为 Vault Backed Shoring，或 VBS。它旨在为使用支撑功能提供流动性限制，由每个用户自己决定。

有了这个新的抵押品要求，它将在很长一段时间内锁定抵押品和铸造的硬币，支撑用户将不断暴露并与基础抵押品的波动性相关联，同时他们正在积极改变协议供应数量。

如果他们卖掉他们的 XHV 抵押品并且不在他们的金库中持有 XHV，他们将无法使用支撑功能，从而阻止他们完全“选择退出”波动的系统，而社区则随着通货膨胀的增加而支付相反的头寸。

简而言之，Vault Backed Shoring 旨在为支持功能的用户在游戏中用作减速器和皮肤要求。

注意： 只有使用支撑功能（XHV <-> xUSD）的参与者才需要 VBS，而不是标准的 XHV 或 xAsset 转移。

外包示例：

要将 100 xUSD 转换为 XHV，您需要在金库中至少有 $100 价值的 XHV，已解锁。
这个价值 $100 的 XHV（称为抵押品）将在转换期间与被转换的资金一起被锁定。

如果 XHV 的当前价格是 $0.50，这意味着您需要在您的金库中至少有 200 XHV（解锁）才能在岸上获得 100 xUSD。
使用此示例成功转换后，您将锁定 400 XHV 一段时间（请参阅下面的建议锁定时间）。

离岸外包示例：

要将 100 XHV 转换为 xUSD，您需要在金库中至少有相同数量的 XHV（在本例中为 100）并解锁。
这意味着您只能离岸最多 50% 保存在保险库中的 XHV，前提是没有任何 XHV 被锁定。

建议的 VBS 锁定时间

资金和抵押品要求都将被锁定 21 天.

如果用户在单次转换中没有在岸上持有足够的抵押品，VBS 会通过要求在岸者经历多个岸上循环来减缓岸上的过程，每个岸上需要 21 天才能完成。

为了说明这一点，这里有几个场景显示了多少个周期以及将存放在保险库中的全部 xUSD 所需的时间。

第一个示例使用 10k XHV 的起始数量，第二个示例使用 100k XHV 的起始数量。
这两个示例都使用 1:1 抵押品，这意味着在任何给定时间，您在岸上最多只能是您在保险库中拥有的最大数量的未锁定 XHV。
在提案的第 2 部分中，我们将看到抵押品将根据协议的状态发生变化。

很容易看出，金库中未锁定的抵押品越多，将所有 xUSD 完全转换回 XHV 所需的周期就越少。

接下来的几个场景分别使用递增和递减的 XHV 价格。

由此，我们可以看到，随着 XHV 价格的上涨，所需的在岸周期会减少，但如果您能够在一次转换中将所有 xUSD 转移到岸上，那么您最终获得的整体 XHV 会比您应该拥有的要少。

相反，随着 XHV 的价格下降，需要更多的在岸周期来转换所有的 xUSD，但最终你会得到更多的 XHV。
尽管这看起来像是在膨胀协议，但这些场景并没有考虑到协议的状态，这将阻止上面看到的膨胀类型。
这将我们带到提案的下一部分。

提案的第一部分是描述围绕 VBS 的新想法，以及如何实施。

然而，就其本身而言，VBS 不一定会阻止通胀，尤其是随着 XHV 的价格随着时间的推移而下降，它只会延长协议通胀所需的时间。

因此，需要采取其他措施来抵消不受控制的通货膨胀和鲸鱼操纵。

市值比率

正如许多社区成员在我们的 havenomics 频道中的讨论中已经注意到的那样，衡量协议健康状况的最佳方法之一是使用总离岸资产市值 (TOAMcap) 和 XHV 市值 (XHVMcap) 的比率）。

这可以简单地计算为：

数字越低，协议越健康，反之亦然。
虽然是一个主观的数据点，但是当 XHVmcap 是 TOAMcap 的 10 倍时，一个非常好的比率被认为是，即 0.1 使用上面的公式。

在撰写本文时（2022 年 6 月 23 日），XHV 的流通供应量约为 2830 万，市值为 $1600 万（使用 KuCoin 价格 $0.567）。
总资产市值约为 $16 百万。
所以我们现在拥有的 mcap 比率几乎完全一样 1，这被认为是一个糟糕的比率，因此是协议的不健康状态。

将 mcap 比率与 VBS 相结合

可以通过以下方式达到协议的不健康状态：

• XHV价格持续下跌
• 非常大的单次转换
• 过多的离岸外包
• 过多的离岸外包，这可能导致公开市场的抛售压力
• 以上几点的任意组合

如果我们将协议状态（mcap 比率）与我们的 VBS 模型结合起来，我们可以进一步限制支撑机制，以确保系统不会过度转向不健康状态。

我们建议在岸上和离岸上执行此操作的方式是不同的。

岸上

对于 Onshores，我们将随着 mcap 比率的增加而增加所需的抵押品，这意味着当协议趋于不良状态时，您需要在相同数量的 xUSD 的金库中拥有更多的 XHV。

让我们假设比率为 0.5，协议正走向不健康状态。这意味着您将无法再使用 1:1 的抵押品在境内支付您的 xUSD。
对此比率的动态计算可能会得出 1:3 的抵押品，这意味着您的金库中需要的 XHV 数量是您尝试在岸上的 XHV 数量的 3 倍。

为了更好地可视化这一点，让我们使用与之前相同的场景：以恒定价格开始 10k 的 XHV 数量，但这次使用 1:3 抵押品。

使用上一个示例中的 1:1 抵押品，我们需要 7 个在岸才能将所有 xUSD 完全转换为 XHV。
如上所述，通过 1:3 的抵押品，境内数量增加到 17 个，需要一整年的时间才能将所有 xUSD 转换为 XHV。

让我们也比较相同的场景，但起始 XHV 数量为 100k。

以前，使用 1:1 的抵押品，需要 4 个在岸（84 天）才能转换所有的 xUSD。
以 1:3 的抵押品，它已增加到 9 个在岸，或 189 天。

当然，这些场景在现实世界中是相当不现实的；无法预测市场和价格波动、基本面、情绪、转换策略等。

我们可以从中得出的结论是，随着协议状态的日益恶化，将 xUSD 转换为 XHV 所需的抵押品数量也在增加，这反过来又增加了周期数和将全部金额上岸所需的时间。

离岸

对于 Offshores，目前的概念是将抵押品保持在 1:1，但随着 mcap 比率的增加，我们将增加费用。此外，我们还将为较大的转换增加滑点费用，这将使协议的状态从好或坏变得更糟。

注意： 除了标准转换费之外，我们不考虑 Onshores 费用的原因是因为据信这将使 xUSD 脱钩，这可能会在公开市场上造成价格螺旋式下降。

离岸 - 转换费

我们认为，燃烧大部分费用以控制通货膨胀，同时为项目的运营成本和工资留出足够的费用符合协议的最佳利益。
就本提案而言，我们假设国库费用至少为 0.5%，任何盈余都将被烧毁。
具体数字将在稍后阶段商定。

为了计算转换费用，我们将在 mcap 比率和一个 2 或非常接近的数字（+/- 几位小数）之间使用简单的幂运算。
如果数字太高，计算将变得太快，这将使其无法使用。

为了说明这一点，请考虑以下示例，其中我们使用 4 个不同级别的指数来模拟各种级别的 mcap 比率：[1.6]、[1.8]、[2] 和 [2.2]
我们还设置了最低 (0.5%) 和最高 (80%) 费用，其中 0.5% 进入国库，其余的被烧毁。

随着比率的增加和协议状态的恶化，任何离岸公司的费用都将相应增加。
高额费用背后的想法不是惩罚用户，而是阻止他们将协议推向不良状态，并通过烧掉大部分费用来防止不受控制的通货膨胀。
 

离岸 – 滑点费

滑点费用是捕获大量转换的额外措施，这将通过一次转换使协议状态恶化。

我们会将滑点费用添加到上面计算的标准转换费用中。基本上，滑点费是在比率潜在增加后添加到标准转换费中的费用。

这是一个示例，其中该比率在离岸之前处于良好状态，但在鲸鱼进行一次转换后，它会使其进入不良状态。

其他注意事项

市值比率是否足以计算协议的状态？
答案是不。

还有一些我们还没有提到的需要考虑的事情；这 传播 TOAMcap 和 XHVMcap 之间的比率。

我们现在所处的协议状态，即不健康，意味着我们不会有很多转换通过系统，因为它要么太昂贵，要么需要太多的抵押品。
然而，一旦 XHV 的价格上涨到市值比率对在岸有利的水平，这种情况可能会改变。

随着人们开始在岸，XHV 的价格上涨，TOAMcap 和 XHVMcap 之间的价差扩大得更快，这激励了更多的在岸，从而增加了供应。
这可能会一直持续到所有 xUSD 都转换为 XHV 并且 XHV 的流通供应量将大大膨胀。

为了解决这个问题，我们可以计算出两个上限与 XHV 价格之间的价差比率，如果价差变得太大，我们可以对转换应用类似的限制，即使市值比率处于良好状态。

下面的模拟图表显示了如何计算它。
当市值比率低（健康状态 - 蓝线），但点差比率高（绿线）时，我们可以增加 Onshores 的抵押品并提高 Offshores 的费用。

回顾一下，我们提出以下措施

离岸外包

1. 具有 1:1 抵押品的 VBS，加上锁定时间（建议 21 天）。
2. 根据协议状态确定费用的 Mcap 比率。
3. 滑点费用取决于离岸的规模和潜在离岸后的协议状态。
4. 点差费用。
5. 适用于 XHV -> xUSD 转换。

离岸外包

1. 具有锁定时间的 VBS（建议 21 天）。
2. 最小抵押物为 1:1，最大为 1:3 或 1:4（待讨论）。
3. 抵押品由协议的状态决定。
4. 抵押品由点差比率决定。
5. 基本转换费。
6. 适用于 xUSD -> XHV 转换。

该提案的主要内容是社区的讨论和反馈应围绕新想法 VBS。
我们真的很想知道您的想法，以及您是否在此模型中发现任何明显的问题。
 

我们提议的内容有重要的开发工作，虽然开发团队对此进行了规划，但我们希望花时间听取社区对此提议的反馈，特别是 VBS 的新颖方法。

成员可以在 1TP3财富经济学 渠道。​​​