本文概述了即将推出的 Audaces 永续合约(Audaces Perpetual Futures)协议的运作方式以及其背后的经济原理。该市场利用了一个虚拟的自动化做市商(Virtual Automated Market Maker，vAMM)，从以太坊的永续合约协议(Ethereum’s Perpetual Protocol)中汲取灵感并借用了Solana 区块链的先进性能，可提供真正的Layer1 解决方案。 Audaces 永续合约自动做市商提供了一种新颖的多空平衡资金费率协议，旨在保护市场的保险基金免受突然的趋势变化的影响，同时首次实现了在vAMM 上市场流动性的动态扩容。

2. 虚拟自动化做市商(vAMM)

虚拟自动做市商(vAMM)的概念最先出现在”永续合约协议(Perpetual Protocol)” 一文中。 vAMM 的工作原理类似于传统的具有恒定乘积曲线的 AMM(例如 x * y = k) ，但正如其名字所示，这个 AMM 中的流动性是虚拟的。该流动性是在创建市场时设置的， 所有交易都发生在这个 vAMM 中。在实际执行中，每个市场的状态，即 vAMM 都存储在一个 Solana 帐户的数据中。

vAMM 的一个有趣特性是只要有相应的预言机存在，任何计量资产都可以成为一种期货。例如，在 BTC/USDC 期货市场上，并未产生实际的 BTC 交易，所有交易均以 USDC 进行。该 市场使用自己的价格发现机制(即 vAMM)来执行虚拟资产和报价资产之间的转换。

决定vAMM 价格惯性的关键变量是k。在传统的恒定乘积曲线模型中，k在整个该市场 的生命週期内都是一个不可变的变量。 k 值的选择是一个综合考量的结果，保证在较高值时 滑点较低，而在较低值时易于套利。本质上，k 可以看作衡量市场可用虚拟流动性的指标。此外，k 值越高则本文第 5 部分中讲到的调仓机制(rebalancing mechanism)效率也会越低。一般而言，较高的 k 值需要匹配更高的交易量才能正常发挥作用。第 6 部分主要是介 绍如何解决 k 的不变性问题，这与调仓机制密切相关。

3. 清算

同其他引入杠杆的协议一样，该协议的最大风险也在于清算风险，因此整个协议在设计 中都非常注重优化清算速度。

为了高效地清算头寸，该协议提出了一种原有方式的替代方案，原低效的设计会遍历所有已知帐户以查找待清算账户，然后再在同样巨量的交易中单独清算所有这些头寸。为了充 分发挥 Solana 区块链的高性能，理想的目标应该是只用一个指令即可在整个市场中执行清算操作。

但问题在于 Solana 上单个指令可以完成的计算週期数量有一定上限。这就意味著任何遍历所有未平仓头寸的方法都必然会在某些时刻失败。为了解决这个问题，Audaces 永续合约市场利用了两个中央持仓指数(一个用于空头头寸，一个用于多头头寸)，我们称之为清算树(Liquidation Trees)。

开单时，可以预先计算出触发清算的价格阈值。然后将此清算指数插入到存储在链上的 分页内存堆中的(critbit tree)上。这片创建的叶子节点的标识符就会记录到用户的帐户 中。当用户将来对该仓位进行操作时，智能合约会寻找相应的叶子节点。如果找不到，就意味著该仓位被清算了。

清算树(LT)本身俱有内部节点，可跟踪位于其上的未平仓头寸持有的抵押品及虚拟资 产的总量。由于 Critbit 是根据清算指数自然排序的，清算操作就会变得非常高效。智能合约沿著清算树一路走下去，要删除任意数量的持仓仓位，只用砍掉一个树枝边角。由于清算指数存储为64位整数，清算树本身最多只会有64层，这就意味沿著清算树清算的操作是限定在这个数字范围内的，通过测试这种最极限的情况，即可证明清算在所有情况下都可以成功。

此模型也有一个不足，一旦发生清算，就无法跟踪某个订单的清算时间。证明某个订单 为什么被清算很容易，但缺少清算时间信息就意味著无法将维持保证金(maintenance margin)退还给被清算用户。但是，市场清算效率的提升可以缓解这种问题，通过允许较低 的维持保证金，将风险控制在保险基金可接受的范围内。

在实际执行中，快速清算启动服务器会在每个时间片发出清算交易，使每个新的 Solana 区块中至少包含一笔清算交易。

清算树架构有效地实现了 Solana 上最快速的清算解决方案，现在更快性能的关键就是 预言机的更新频率和 Solana 的区块验证时间。正是基于这个原因，我们选择了 Pyth 网络作为底层的预言机解决方案，因为它可以保证更新频率能跟上区块验证时间

因此，唯一限制清算速度的因素是预言机的速度，这意味著如果预言机每 x 毫秒更新 一次并且 Solana 的出块时间为 y(本文撰写时 y 约为 400 毫秒)，清算频率将为 1 。

max(x,y)

由此看来清算系统的扩容完全没问题，因为不像 Solana 上的其他槓杆交易协议，清算者不必重复遍历其所有帐户。

清算是相对于指数(oracle预言机)价格执行的。与相对于市场价格的清算相比，这减轻了清算可能带来的雪球效应，因为在相对于市场价格的清算中，例如，每次清算空头只会推高市场价格，引发新的清算，等等。

最后，由于清算树(LT)存储了当前未平仓头寸的信息，随著市场的发展，Solana 帐 户 10Mb 的内存极限最终会耗尽。为了规避这个限制，我们採用了内存分页机制，将保存 LT 信息的内存块拆分到多个帐户。尽管如此，使用数十个帐户作为 Solana 的输入指令仍然可 能会带来冗馀操作，仅计算週期这一个限制就可能会阻碍内存的反序列化。

因此，我们使用了“LT 实例”(LT instances)。每个市场可以存在多个实例，每个实 例存储 2 个 LT(一个空头，一个多头)，每个都可能使用多个内存页面(例如，多个帐户)。这样一来，每个实例使用的 Solana 帐户少于 10 个，且完整的市场未平仓头寸信息则分 别储存在数十个或数百个内存页。因此扩容的唯一限制就是清算被启动(crank)的频率， 因为每次清算就是针对一个实例执行，换句话说，一次清算一对 LT。

4.资金费率

为了能够自由地使用高效的数据结构，Audaces 永续合约市场不会直接从用户的未平仓头寸中获取资金费率。而是从用户账户的馀额中支付资金费率，这样头寸不会受影响。这就 要求用户预留足够的馀额来支付可能需要的资金，以避免自己的头寸被清算。一个高效并被 良好套利市场中锁定在用户账户中的资金会更少，从而尽量减少相关的无常损失。

在实际操作中，资金费率通过三个步骤实现，并基于如公式 1 所示的公式。第一个步骤 是以短时且规律的间隔对市场资金费率的采样，以便准确估计市场价格与指数价格之间相对 差异的时间加权移动平均值。第二个步骤以更长的时间间隔进行，併计算最终上一轮资金费 率的值。在这一步，多头和空头之间的不平衡会被记录下来，并限制用户收到的资金相比需 要支付的资金费率。这是为了确保保险基金永远不会用来支付资金费率。最后的步骤是在每个用户的帐户上，并从用户帐户中提取相关资金费率，如有必要，清算他们的头寸。

公式 1 代表资金费率 f，其中 P 为资金费率週期(以小时为单位)，N 为给定时间段的 样本数，m 为市场价格函数，o 为指数价格(或预言机)函数

5. 调仓

vAMM 的性质意味著:如果每个参与者都选择平仓，市场就会重置为其原始价格。这表 明其核心设计缺乏时间对称性，会对系统整体的稳定性产生重要影响。如果某资产的价格自 市场开启以来就一直上涨，那么这个完美的套利市场中多头就会多于空头。因此，如果当前 的 vAMM 价格是低于预言机价格(但仍高于初始价格)，保险基金则必须支付资金费率。由 于多头多于空头，该协议将不得不注入保险基金资金来支付多头们应得的资金。而且这个问 题会在该市场存续期间越来越严重，尤其是当目前价格与初始价格差异增大时。

为了解决这个问题，一种解决方案是用未平仓头寸来支付资金费率，而非用保险基金支 付。尽管这对于保险基金来说更安全，但这意味著用户获得的资金低于他们的期望，且风险 套利的市场激励会随著时间的推移而显著减弱。调仓则可以应对这种不平衡，并且随著市场 开始积累调仓资金，可以保证均衡价格永远不会偏离标记价格太多(触发调仓的差异阈值目 前约为 10%的差异)。

调仓是通过预留一些资金，以便 vAMM 购买自己的免资金费率全额抵押头寸。这些头寸 永远不会被清算，所以不需要确切跟踪他们。如果多头过多，当用户试图平仓他们的多头或 建仓空头时，vAMM 将买断多头(或平仓自己的空头)，有点像订单簿市场中的机器人。这样 在实际情况下，有些操作就不会像期许的那样大幅改变市场价格，从而为套利者提供了从中获利的可能性，所以当存在调仓资金时，就会创造额外的调仓激励。

等式2给出了关键调仓标准的推导，偏差是当前标记价格与所谓的均衡价格的比率。调 仓机制通过根据偏差调整资金，化解了保险基金的重大长期风险(也就是，多头只能获得市 场实际能够从空头中获取的部分合理资金)。

6. k 相关问题解决方案

传统 vAMM 执行中的一个关键问题是很难在操作中动态改变 k 的值。但是，随著市场交 易量的增加而加大 k 值可以最大限度地减少大订单的滑点，同时在进入较低的交易量期间仍然保持较好的套利。加大k值背后的关键问题是它打破了路径的独立性:用户就可以直接从保险基金中获利。因此改变 k 值成本会很高，会直接将保险基金注入市场。

6.1 方法及推导

这个成本可以通过比较两个场景来评估，即所有用户平仓他们的头寸并从市场中提取他们的收益(payout)。在第一种情况下 k 的值保持不变，在第二种情况下 k 的值首先乘以一 个标量。 k 值的这种变化不会改变市场的价格，因为是通过将虚拟基础和虚拟报价都乘以标量p实现的，即k 乘以p2。

设 x 和 x0 分别为某虚拟货币的市场当前数量和均衡数量，y 和 y0 为报价货币的相关金额。

K 值不变，平仓所有头寸就相当于将∆加回到 x 上，vAMM 则恢复到 x0 和 y0。这种逆转可能会出现在多种不同的情况下:每个头寸关闭的顺序在确定每个头寸的相关收益(payout) 时很重要。例如，持有多头头寸的用户先持有等待，待到某人关闭他们的空头头寸后，再关 闭自己的多头头寸，则更有利可图。然而，所有 vAMM 的核心属性则是路径的独立性，也就 是操作的顺序并不影响所有用户的总收益(payout):只有最终状态才重要。这就使得我们 可以将分析简化为一个简单的路径:关闭所有多头，然后关闭所有空头。路径独立性甚至使 得我们可以将所有 vAMM 状态视为仅包含两个未平仓头寸的市场:一个空头和一个多头。因 此，在这种简化场景下，用户可从 vAMM 中提取的总收益 δ 就是多头和空头收益的总和。

我们首先将 vAMM 状态乘以 p，得到 (px, py) 的状态。这可以在市场价格保持不变的情况下将 k 变为 kp2 然后，我们关闭大小为 l 的多头头寸，并求解相应的(x’, y’) 状态。

我们使用Kl 和Ks 来分别指代多头头寸和空头头寸的开盘虚拟报价金额，那么多头的相关收益 p 则如下所示:

然后我们关闭大小为 s 的空头头寸，并求解相应状态(x", y"):

空头头寸的相关收益P则由下式给出:

你们，从 vAMM 中提取的资金总额为:

接下来要评估将 k 变为 pk 的直接成本，便可以直接用以下公式：

然后可以解出 C(p, ∆) = 0，相当于∆2 = 0，也就表示∆ = 0 是当前框架中该问题的 唯一解。这种双重解暗示了一个事实，即允许我们自己改变仓位的大小幅度(有效地引入∆’) 会是一个更常见的解，但∆非零解会使得k 的变化成本对用户而言不对称，利好于某一方向。

幸运的是，通过利用第 5 部分中讨论的调仓机制可以达到∆ = 0 的状态。这一事实也 让我们深入了解了调仓机制的重要性:在多空平衡的条件下，vAMM 就像一个基于订单簿的市场，多空持仓者直接相互交易，而无需与 vAMM 交易。

6.2 K 变化后对收益的影响

使用 6.1 中描述的算法会严格改变给定特定 vAMM 路径的收益。实际上，这意味著具有较高 k 值的相同操作序列会减少不同用户的相关损益幅度，同时维持一个总体平衡。最直观的原 因是因为较高的 k 值意味著在完全相同的操作下，由于较低的滑点，vAMM 的状态跨越的市场价格区间不会太大。

然而，如果选择以k的值来反映市场的套利能力，市场激励总是会通过提供仍然遵循指数价格的市场价格来抵消这种差异。也就是说，在实践中，由于市场操作的滑点较低，头寸实际 上往往会支出更多。这也解释了为什么在这种情况下k值变化时收益也会改变。事实是此时 市场本身也更容易套利失败，10.1 中将对此风险进行更详细的描述。

7. 保险基金

该协议由保险基金支持。初始保险基金为 x USDC 并将加入协议中收取所有费用的一 小部分。欲查看保险基金在不同场景下的使用情况，请参考第 9 部分。

8. 启动(cranking)

要保持协议的正常运作需要按计划运行某些功能，我们统称这些功能为“启动”(crank turning)。其中包括:清算、资金费率和垃圾收集。请注意，这些指令无需许可，任何 Solana 钱包都可以“启动”(crank)这些功能，不过需要为交易支付 gas 费用，但发起者会因他们 启动(crank)的交易获得奖励。

需要启动(crank)的过程包括(无特定顺序):

用户可在协议存储库中找到自动启动这些辅助功能的 Rust 可执行文件以及 Typescript 客户端。

9. 量化模拟

下图显示了模拟运行期间市场状态的演变。模拟运行旨在再现接近真实的市场条件，该 测试环境搭建在 solana-program-test 库之上，该库实例化了本地 Solana 网络并向其 加载了永续智能合约。通过与该系统交互，可以模拟vAMM 的定量行为和不同的调仓机制， 同时也可以模糊测试程序的潜在错误。

为了更好呈现出市场中各事件的视觉相关性，绘製的数据已被缩放，因此图中的绝对值 无关紧要。

图 2:某一成不变的市场突然遭遇价格下跌时，保险基金(灰色)、市场价格(蓝色)、指数 价格(绿色)和均衡价格(橙色)在整个过程中(例如指令)的改变。

在这种情况下，突然的模拟崩盘导致清算激增。多头总持仓量的下降也表明了这点。此外，在下图中可以注意到，在约最初 30 条指令发布期间，虽然调仓一直在增加，但均衡价格保持不变。这是由于均衡价格相对于市场价格的公差范围 — — 当市场价格偏离该范围时， 调仓则会被激活。

图 3:在与图 2 相同的模拟运行期间，调仓基金(绿色)、投资于未平仓头寸的总虚拟资产金额(蓝色)和均衡价格(橙色)随时间(例如指令)的演变。调仓基金的半规律性下 跌反映了将均衡价格推向市场价格的调仓机制。

10. 风险和限制

Audaces 永续合约市场的使用并非全无风险。我们已注意尽量减少以下风险来源对用户 的影响，严格改进现有最先进的去中心化永续合约市场。本部分的分析涉及两大类风险:内在风险和平台风险。

10.1 内在风险

调仓的交易量不足 尽管我们会谨慎地调整市场参数以刺激调仓，但调仓的效果与交易 量有著内在的联系。确切地说，调仓的效果与特定时间段内价格变化和交易量之间的比率成 正比。如果市场失衡到一定程度，调仓资金的效果就会大大下降，这也意味著多头和空头之 间的套利动机会倾向某一侧。

套利失败 如果由于某种/某些原因市场价格开始与指数价格完全背离，则可能出现某 些负收益的头寸无法平仓或清算的情况。这是因为收益取决于市场价格，而清算取决于指数 价格。从本质上讲，这意味著用户将不得不等待市场价格再次靠近指数价格才能平仓。当市场失衡到一定程度，这种风险会增加:如果每个用户都试图平仓，市场价格将不会慢慢接近指数价格，一些用户可能能够提取他们的收益，而其他用户可能会被套，直到市场套利环境再次改善。这就是基于指数的清算需要调仓的原因。

10.2 平台风险

预言机失效：如果由于任何原因预言机停止运行，或者其置信度指标在足够长的时间内开始急剧下降，则清算机制将完全瘫痪。一旦预言机重新上线，清算引擎将直接利用保险资 金来缓衝任何潜在的资金损失。

Solana 网络故障：如果由于某种原因网络状态中断，或者网络本身因过多交易被丢弃 而无法响应，则清算引擎可能会减慢速度，这又会给保险基金带来额外风险。

恶意领导者：如果当前的领导验证者决定放弃所有与清算相关的交易，清算引擎则会失 效长达一个 epoch 的时间，这会给保险基金带来额外的风险。根据 Solana 官方文档，一 个epoch週期大约为100个槽长，所以单个领导者可以导致清算中断大约一分钟。恶意的领 导验证者还可以审查某些头寸的开仓，或者简单地重新排序交易，从而可以人为地构建市场 价格偏差，然后验证者可以使用这种偏差来有效地抢先运行其他订单。为了降低这种风险， 用户可以设置一个滑点阈值，以防止订单以意外的入场价格通过。

11. 总结

此白皮书中描述的协议解决了以前 vAMM 运行过程中遇到的主要问题，并为未来的协议建立了一个可搭载的框架。该协议的主要创新在于动态均衡价格，可缓解多头和空头之间的 失衡。由于失衡得到缓解，协议可以在不中断或不破坏路径独立性的情况下更改 k。这意味 著该协议可以随著交易量的增长而调整其流动性。该协议还设置了上限资金费率以保护保险 基金，但是，随著多头/空头失衡得到缓解，资金费率可能与 CEX (中心化交易所)的资金 费率接近。清算引擎专为速度和可扩展性而设计，清算树架构确保了在Solana和DeFi上实 施最快的清算解决方案。这两项保障措施可确保保险基金免受风险威胁，即使在可能触发清 算级联且标记价格可能与指数价格差异巨大的动盪时期。

Audaces 基金会已决定不发布代币并与 Solana 的早期开发人员合作，其中之一便是Bonfida。 Audaces 基金会决定将所有收入给与给 FIDA 购买和销毁的智能合约。因此，FIDA 持有者在使用Audaces协议进行交易时将享受费用折扣。虽然Audaces协议不可变，但可以通过 FIDA 代币的治理投票来修改收取费用的智能合约。

本文链接地址：https://www.wwsww.cn/btbjiaoyi/9743.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。