ERC

ERC7527 遵循 信贷创造货币 的共识，提出了一种基于 Premium 驱动的去中心化定价的正规化。本文将深入介绍 ERC7527 的原理及协议细节，以及其潜在优势及拓展应用。前情提要： V神新提的EIP7706详解，梳理最新以太坊Gas机制背景补充： 共享排序协议Espresso如何实现Layer2扩容，优化区块链交易？

本文目录

如何对早期的想法或者应用进行定价，并参与投资？这在去中心化世界是一个巨大的挑战。ERC7527 遵循 信贷创造货币 的共识，提出了一种基于 Premium 驱动的去中心化定价的正规化。

在本文中，我们将深入介绍 ERC7527 的原理及协议细节，进一步介绍连续报价模型的运作原理及其巨大优势。同时，我们也会介绍一些基于 ERC7527 的可程式设计性和可组合性而产生的拓展应用。

ERC7527 提出了一种通过发行 ERC7527 通证给应用定价的新正规化。ERC7527 代币的价格实际上就量化了应用的市值 (应用市值 = ERC7527 价格 数量)。这种方法将对应用的定价转化为了对 ERC7527 代币的定价。ERC7527 代币的定价分为以下两个部分：

对于 ERC7527 通证的买入报价和定价的问题，ERC7527 则充分提供了可程式设计性。具体来说，使用者可以呼叫以下函式获取报价：

而 ERC7527 开发者则需要在开发过程中设计报价模型来最终给出报价。当用户呼叫 getWrapOracle 获得当前的报价后，使用者可以选择向 ERC7527 的池子内注入流动性以实现报价到定价的转化。具体来说，使用者可以呼叫 FOAMM 内的 wrap 函式来注入流动性：

对于 ERC7527 通证的卖出报价和定价问题，ERC7527 使用了 FOAMM 构建的池子解决了卖出报价到定价的转化，使用者可以通过池子将资产销毁、移除内部流动性实现退出。这里可能存在一个问题，即池子内的流动性由谁提供的问题。

在上文中，我们提到 FOAMM 通过 wrap 新增内部流动性，这部分就是池子内流动性的来源。ERC7527 使用 FOAMM 将使用者买入资产所支付的流动性注入到池子内以充当退出流动性。对于开发者而言，只需要给出卖出报价就可以，由于池子记忆体在流动性，卖出报价就是卖出定价。具体来说，开发者需要实现以下函式实现卖出报价功能：

开发者可以基于池子的流动性构造任意的卖出报价函式，需要注意的是，卖出报价最终应当保持池子的清算平衡。使用者可以随时呼叫 getUnwrapOracle 获取当前的 ERC7527 通证的卖出报价，并可以选择进一步呼叫 FOAMM 的 unwrap 函式来销毁 ERC7527 通证以获取池子内的卖出报价数量的通证：

总结来说，对于使用者而言，ERC7527 的互动仅有两部分：

在上文给出的 getWrapOracle 和 getUnwrapOracle 函式的返回值内都出现了 price 和 fee 选项，其中 price 代表当前 wrap 或者 unwrap ERC7527 通证所需要支付的通证数量，而 fee 则代表手续费，无论是 wrap 或 unwrap 操作，使用者都需要支付一定数量的手续费，这些手续费最终被指定使用者提取。

ERC7527 是一种标准通证，与 ERC20 通证等类似，也有其通证地址。ERC7527 存在如下定义栏位：

上述结构体定义了 ERC7527 最核心的属性，其中 currency 代表使用者提供哪种通证来铸造 ERC7527 通证，premium 指 ERC7527 通证的初始报价，feeRecipient 代表 wrap 和 unwrap 互动过程中的手续费接收地址，而 mintFeePercent 和 burnFeePercent 则代表 wrap 和 unwrap 的手续费率。

ERC7527 通证具有权利金 (premium) 的波动特征，在上文函式定义内使用了 price 一词，即 Asset 结构体内的 premium。

ERC7527 定义了三种不同的模组

三种元件之间的关系可以参考下图：

ERC7527 内的 App 和 Agency 是存在双向系结关系的。从程式码角度看，App 的 mint 和 burn 函式仅能由 Agency 呼叫，而且 ERC7527 也约定了一系列函式以方便使用者在已知 App 的情况查询 Agency 地址 (getAgency 函式)，和已知 Agency 的情况下查询 App 的地址 (getStrategy 函式)。

从流动性角度来看，App 内的每一个 ERC7527 通证都有对应的池子内的的流动性，这保证了池子的清算平衡。

这种使用 ERC7527 通证对应用进行去中心化定价的方案是一种革命性的创新，这种方案引入了一种先发货币后建立应用的新正规化。对于最早期的应用，开发者就可以直接使用 ERC7527 的 Factory 进行 ERC7527 通证部署。

使用者可以呼叫 wrap 函式铸造 ERC7527 通证来参与专案的早期投资，也可以呼叫 unwrap 函式来退出投资。对于开发者而言，ERC7527 通证的价格可以为早期应用提供有效的市值。随着应用开发和 ERC7527 通证持有者增加，应用市值增长，ERC7527 通证的持有者和应用开发者都可以获得市值增长的激励。

在上一节中，我们充分讨论 ERC7527 的运作原理，但上一节内并没有详细介绍买入报价模型的构造。ERC7527 在此处仅提供了 getWrapOracle 介面，而报价模型具体实现完全依靠开发者。在本节中，本文将提出一种较为通用的买入报价模型。

ERC7527 的买入报价应当同时考虑微观和宏观两种角度。

宏观来看，我们预期 ERC7527 通证的报价应当伴随着 ERC7527 通证持有量的增加而增加。更加具体来说，呼叫 getWrapOracle 获得的当前 ERC7527 通证的报价不应当低于定价 ( 或称为 上一次的买入成交价)。

ERC7527 通证的报价应随着 ERC7527 通证持有量的增加而增加会带来一个很有趣的结果，即 ERC7527 通证本身将具有信用扩张机制。更加具体来说，会出现 ERC7527 通证市值大于 TPL (Total Premium Locked)。这种信用扩张机制会使得每一个 ERC7527 通证的持有人获得信用的增长。

在上文，我们没有提及 unwrap 卖出交易，unwrap 卖出交易会直接使得买入交易的报价下降。我们可以使用一种最简单的基于栈的系统来实现卖出推动买入报价下降的方案：

我们将 ERC7527 内所有的历史定价储存在栈内部，当每一次新的定价 new price 形成时，我们就将其推入栈内，买入报价模型会依赖于栈内最新的定价给出买入报价。

而当用户卖出时，我们直接将最新的买入定价 new price 作为卖出定价，从 Agency 内向使用者转出流动性并同时将该定价从栈内弹出。此时报价模型还是依赖于栈内最新的定价 price2 对外给出报价。

由于 price2 是小于 new price 的，所以此时报价模型在 unwrap 后，对外给出的基于 price2 的报价也会低于过去以 new price 为基础给出的报价。当然，这种基于栈的卖出报价只是一种最简单的卖出报价方案。

从微观上，报价模型应该具有某种类似荷兰式拍卖的价格调整机制。荷兰式拍卖最大的特点是将时间引入了报价模型，随着长时间的无人成交，价格应当自动下降。

但荷兰式拍卖具有一个较为严重的缺点，由于随着时间推移价格一定会下降，存在等待博弈的囚徒困境，最终导致报价不断下降。一个良好的报价模型在微观层面上应当包含时间因子，且也应该存在上涨和下降两段。

综上所述，一个良好的报价模型应当符合以下要求

除此外，我们还希望报价模型可以满足以下应用的成长规律

我们会在后文具体介绍解决方案。

首先，满足观要求实际上很简单，我们需要在报价模型内纳入定价Pn1作为因子。然后，对于微观需求，我们可以将函式分段来解决问题。最终，我们可以获得以下报价函式：

关于此报价函式的引数的具体含义，读者可以参考上一篇文章内给出的介绍。我们在此处直接给出此定价函式的影象：

在上图内，x 轴代表当前时间距离上一次成交的时间间隔单位，而 y 轴代表当前报价与上一次成交价格之间的比值，值得注意的是，当价格下降到低于上一次成交价时，报价模型只会报出上一次等于上一次成交价的报价，这是为了满足报价模型的宏观要求。

我们直观看到上述报价模型既存在早期的上涨阶段，又存在后期的类似荷兰拍卖的下降阶段，这有效满足了报价模型的微观要求。此处，我们可以看到在上涨阶段的早期存在跳跃式上涨，这是为了避免在连续铸造过程中出现的 ERC7527 的持有量上涨但价格没有发生显着变化的情况。

我们建立一个环境来模拟上述报价模型，模拟结果如下：

在模拟的走势 K 线图中，第一栏代表当前的 ERC7527 通证的价格走势，而第二栏则代表当前 ERC7527 通证的持有数量，此数量会随着 wrap 操作而增加，随着 unwrap 操作而减少。从程式码层面来说，第二栏实际上是呼叫 App 的 totalSupply 函式获得的。第三栏则代表当前 wrap 和 unwrap 的次数，其中绿线则代表 wrap 的次数，而红线代表 unwrap 的次数。

上图展示了部分池子的早期运作情况，可能早期由于共识不足等原因，使用者进进出出而导致定价长时间在初始价格左右波动，直到一些利好产生，使用者选择买入但随后被早期使用者砸盘返回初始价格，最后随着 ERC7527 通证持有人增加，定价在波动中震荡上涨。

通过上述简单的模拟，我们可以看到基于连续报价模型的一个极其重要的优点，即使用者的买入操作直接影响到了报价流程，这导致几乎没有可能两种 ERC7527 通证走出相同的 K 线图，极大提高了系统的博弈复杂度。

下图展示了一段具体的报价变化，其中 B 代表买入 (wrap)，而 S 代表卖出 (unwrap)。我们可以看到整个报价模型在宏观上每一次买入的成交价都不低于上一次的成交价，而每一次卖出都使用了之前已存在的买入定价，因此这个影象具有一定的对称性。

我们实际上解决了上述报价模型的宏观和微观要求，同时在报价上也满足了 早期阶段具有高成长性 的成长规律。接下来，我们需要解决一个问题，即如何在报价上实现应用后期的稳健成长性。早期报价的高涨幅是与应用的早期高成长相匹配。中后期的报价需要与应用的稳健发展相匹配，所以我们需要在中后期构建稳健成长的报价系统。

由此，我们决定通过分段解决此问题，即在早期报价内使用高成长性的报价系统，而在后期使用稳健成长的报价系统。当然，除了本文介绍的早期和后期的两段分割外，开发者可以根据自身情况进行更多段的分割，比如在早期、中期、后期使用不同的成长函式。

事实上，我们还是使用了与早期一致的报价函式，但修改了其部分引数，修改后的报价函式曲线如下：

相比于早期报价函式，我们可以看到后期报价函式的初始涨幅更低。上图的 x 轴依旧使用了与上次成交间隔的时间单位作为 x 轴，但需要注意此处的时间单位是小于早期报价函式的。

我们尝试模拟 ERC7527 通证供应量从 0 达到 20000 期间的成交价格变化情况，我们获得了以下走势 K 线图：

上述走势 K 线图的设定的最初报价为 01。在供应量达到 20000 时，价格从最初的 01 上涨为 300，涨幅达到了 3000 倍。

当然，有些应用可能无法一帆风顺的走向成功。以下走势 K 线图展示了在早期蓬勃发展，突然遭遇危机导致使用者退出的价格变化情况：

上述几个案例证明我们所提出的报价模型是有效的，其满足了应用的成长规律，既存在早期的高成长，也存在后期的稳健成长。这些优势是因为我们采用了分段的报价模型，在早期和后期使用了引数不同的报价函式。

另一方面，因为报价函式是连续的，所以使用者可以等待报价函式给出预期的报价，而且报价的具体情况会随着使用者的行为发生变化。这使得在本节介绍的报价模型内，不仅存在使用者与报价模型的博弈，也存在的是使用者之间博弈。而使用者之间博弈是极其复杂，这导致很难根据报价模型反向推汇出一种策略以获取无风险收益。

在本节中，我们将介绍 ERC7527 的以下几种拓展应用

AI 应用激励层

AI 应用需要全新的激励层，而 ERC7527 可以为 AI 应用带来系统化的激励层，而 ERC7527 通证则是激励层的核心资产。

AI 应用在发展的最早期部署 ERC7527 通证对其应用进行定价，此时 AI 应用就有了一个市场认可的估值，而使用者也可以直接通过 wrap 操作来持有 ERC7527 通证投资 AI 应用。

从市值角度来看，伴随着 AI 应用的发展和 ERC7527 持有量的增加，AI 应用的开发者和 ERC7527 通证的持有者都会获得市值上涨所带来的巨大激励。

AI 应用也可以进一步使用分红措施激励使用者。AI 应用直接在以太坊二层要求使用者使用通证进行支付。

使用者可以呼叫合约来支付 AI 应用的费用。这些锁定在支付合约内的费用定期被划转到分红合约内，ERC7527 通证的持有者可以直接在分红合约内提取收益，而 AI 应用开发者也可以在分红合约内部提取另一部分收益。

在技术实现上，ERC7527 通证存在对 ERC721 的继承，这意味着 ERC7527 通证可以借助 ERC6551 协议生成 ERC6551 帐户合约。而我们可以通过一些技术方案将 ERC7527 通证的 ERC6551 帐户跨链到以太坊二层。具体技术实现路径如下：

当用户持有 ERC7527 通证后，可以呼叫位于以太坊主网内的 ERC6551 工厂合约来为 ERC7527 通证部署 ERC6551 帐户，然后使用 ERC6551 帐户呼叫部署在主网内的 ERC6551 桥接合约，桥合约会通过跨链桥呼叫位于以太坊二层内的 ERC6551 工厂合约为使用者部署一个位于二层的 ERC6551 帐户。

ERC6551 跨链部分存在一个最简实现，开发者可以参考 ERC6551Mirror 内的程式码，此仓库使用 Chainlink CCIP 实现了 ERC6551 的跨链操作。

当 ERC6551 跨链完成后，使用者可以使用该 ERC6551 帐户提取分红合约内的奖励。

原子性预言机

ERC7615 是有趣的 ERC，其具体内容是约定了一种原子性的通用的合约之间的推送关系。这种简单的推送协议可以构造出原子性的预言机，使得借贷协议等协议的开发难度显着降低。

ERC7615 的运作原理如下图：

当用户 (Client) 呼叫传送合约 (Publisher) 的某些函式时，传送合约会查询该函式是否存在一些订阅合约，如果存在则呼叫订阅合约的 exec 函式来推送一些内容。上述流程最大的特点是原子性。假如订阅合约对于推送资料的处理出现问题，那么呼叫推送合约的交易 (即上图内的 Call somefunc (#8230) 交易) 也会直接报错。

在 ERC7527 内，我们多次提到 ERC7527 给出的卖出报价实际上就是卖出定价，任意持有 ERC7527 通证的使用者都可以以卖出定价提取 Agency 内的流动性。那么，我们是否可以将 ERC7527 的卖出定价推送给借贷协议来实现借贷协议内的清算？

答案是可以的。而且由于连续报价模型在宏观上遵循买出报价随着 ERC7527 保有量上涨而上涨的属性，借贷协议并不需要关心 ERC7527 内的 wrap 操作，而只需要关心会导致价格下降的 unwrap 交易。

我们可以在 unwrap 函式内部嵌入 ERC7615 的推送，将当前的 unwrap 的卖出定价直接推送给借贷协议，当借贷协议获得推送的 unwrap 定价时，就可以根据其价格资讯对借贷协议内使用 ERC7527 通证作为担保品的部位进行清算。

一旦某一借贷部位需要被清算，那么借贷协议可以执行 unwrap 操作提取 ERC7527Agency 内的流动性来平仓借贷部位。

比较令人兴奋的是，上述操作是原子性的，即假如借贷协议的清算失败，那么 ERC7527 的 unwrap 操作也不会成功，这意味着借贷协议完全规避了穿仓风险。

事实上，任何协议都可以在 ERC7527 内获取其推送的卖出定价，这意味着开发者只需要编写一个 ERC7615 的接受介面，就可以获得一个资产的定价并进一步完成其他操作。

在 ERC7527 内，因为 ERC7527 通证在合约上存在对 ERC721 的继承，所以开发者可以对 ERC7527 通证进行其他赋能。当用户使用传统质押方案，比如直接将 ERC7527 转移给质押合约时，使用者就丧失了 ERC7527 通证的其他权益，所以 ERC7527 通证需要一种全新的无需资产转移的质押方案。

基于 ERC7615 的推送机制，可以设计出这种无需资产转移的质押方案。具体来说，建立 ERC7527Agency 合约内的 unwrap 与质押合约的推送关系。质押的使用者可以与 ERC7527 质押合约互动进行 ERC7527 通证的质押，但这一过程并不需要将 ERC7527 通证转移进质押合约。

此时，ERC7527 通证可以获得质押合约内分红。当用户 unwrap 已质押的 ERC7527 通证时，Agency 合约会使用 ERC7615 将此讯息推送给质押合约，质押合约将解除指定 ERC7527 通证的质押状态并进行最终清算。

在此过程中，ERC7615 保证了质押系统的清算问题，确保了已销毁的 ERC7527 通证不可能获得质押收益。

LayerZero是什么？全链协议运作原理、生态热门专案、ZRO代币经济学全整理

比特币手续费可以做多、做空了！AIkimiya测试网定价市场如何运作？

老牌DeFi入局RWA：TrueFi链上信贷协议能否成功突围？