ERC7527 遵循 「信貸創造貨幣」 的共識，提出了一種基於 Premium 驅動的去中心化定價的正規化。本文將深入介紹 ERC7527 的原理及協議細節，以及其潛在優勢及拓展應用。
（前情提要： V神新提的EIP-7706詳解，梳理最新以太坊Gas機制）
（背景補充： 共享排序協議Espresso如何實現Layer2擴容，優化區塊鏈交易？）
如何對早期的想法或者應用進行定價，並參與投資？這在去中心化世界是一個巨大的挑戰。ERC7527 遵循 「信貸創造貨幣」 的共識，提出了一種基於 Premium 驅動的去中心化定價的正規化。
在本文中，我們將深入介紹 ERC7527 的原理及協議細節，進一步介紹連續報價模型的運作原理及其巨大優勢。同時，我們也會介紹一些基於 ERC7527 的可程式設計性和可組合性而產生的拓展應用。
ERC7527
ERC7527 提出了一種通過發行 ERC7527 通證給應用定價的新正規化。ERC7527 代幣的價格實際上就量化了應用的市值 (應用市值 = ERC7527 價格 × 數量)。這種方法將對應用的定價轉化為了對 ERC7527 代幣的定價。ERC7527 代幣的定價分為以下兩個部分：
- 報價。ERC7527 提供了對外買入 (wrap) 和賣出 (unwrap) 報價的介面，允許開發者自己實現
- 定價。基於 ERC7527 的 FOAMM (Function Oracle Automated Market Maker) 通過 wrap 新增內部流動性實現了買入定價，或通過 unwrap 移除內部流動性實現了賣出定價。這種方案無需依賴外部的流動性提供者。
對於 ERC7527 通證的買入報價和定價的問題，ERC7527 則充分提供了可程式設計性。具體來說，使用者可以呼叫以下函式獲取報價：
而 ERC7527 開發者則需要在開發過程中設計報價模型來最終給出報價。當用戶呼叫 getWrapOracle 獲得當前的報價後，使用者可以選擇向 ERC7527 的池子內注入流動性以實現報價到定價的轉化。具體來說，使用者可以呼叫 FOAMM 內的 wrap 函式來注入流動性：
對於 ERC7527 通證的賣出報價和定價問題，ERC7527 使用了 FOAMM 構建的池子解決了賣出報價到定價的轉化，使用者可以通過池子將資產銷燬、移除內部流動性實現退出。這裡可能存在一個問題，即池子內的流動性由誰提供的問題。
在上文中，我們提到 FOAMM 通過 wrap 新增內部流動性，這部分就是池子內流動性的來源。ERC7527 使用 FOAMM 將使用者買入資產所支付的流動性注入到池子內以充當退出流動性。對於開發者而言，只需要給出賣出報價就可以，由於池子記憶體在流動性，賣出報價就是賣出定價。具體來說，開發者需要實現以下函式實現賣出報價功能：
開發者可以基於池子的流動性構造任意的賣出報價函式，需要注意的是，賣出報價最終應當保持池子的清算平衡。使用者可以隨時呼叫 getUnwrapOracle 獲取當前的 ERC7527 通證的賣出報價，並可以選擇進一步呼叫 FOAMM 的 unwrap 函式來銷燬 ERC7527 通證以獲取池子內的賣出報價數量的通證：
總結來說，對於使用者而言，ERC7527 的互動僅有兩部分：
- 呼叫 getWrapOracle 函式讀取當前的買入報價，假如買入報價合適則呼叫 wrap 函式注入流動性獲得 ERC7527 通證。
- 呼叫 getUnwrapOracle 函式讀取當前的賣出定價，假如賣出定價合適則呼叫 unwrap 函式銷燬持有的 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 定義了三種不同的模組:
- App App 合約地址是 ERC7527 通證合約地址。ERC7527 要求 App 合約需要繼承 ERC721Metadata 的相關介面。而且該合約需要暴露 mint 和 burn 介面以方便池子呼叫，且 mint 和 burn 介面僅能由池子呼叫以避免惡意鑄造 ERC7527 通證導致池子清算不平衡。
- Agency Agency 是上文頻繁提到的池子和 FOAMM 所處的合約，也是與使用者互動的核心合約，上文提到的 getWrapOracle/wrap/getUnwrapOracle/unwrap 函式都位於此合約內，該合約儲存使用者買入 (wrap) 時注入的通證以備使用者退出 (unwrap) 時使用。該合約是 ERC7527 通證清算的合約。
- Factory 這是一個輔助合約，該合約的功能是簡化 App 和 Agency 的部署以方便使用者部署 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 為基礎給出的報價。當然，這種基於棧的賣出報價只是一種最簡單的賣出報價方案。
從微觀上，報價模型應該具有某種類似荷蘭式拍賣的價格調整機制。荷蘭式拍賣最大的特點是將時間引入了報價模型，隨著長時間的無人成交，價格應當自動下降。
但荷蘭式拍賣具有一個較為嚴重的缺點，由於隨著時間推移價格一定會下降，存在等待博弈的囚徒困境，最終導致報價不斷下降。一個良好的報價模型在微觀層面上應當包含時間因子，且也應該存在上漲和下降兩段。
綜上所述，一個良好的報價模型應當符合以下要求:
- 給出的買入報價不應當低於已形成的定價。這是為了保證宏觀上隨著 ERC7527 通證的保有量增加，買入報價和定價都上漲。
- 具體的報價函式應該具有時間因子，且應當同時包含上漲和下降兩階段。
除此外，我們還希望報價模型可以滿足以下應用的成長規律:
- 早期階段具有高成長性
- 中後期階段具有較為穩健的成長性
我們會在後文具體介紹解決方案。
首先，滿足觀要求實際上很簡單，我們需要在報價模型內納入定價（Pn-1）作為因子。然後，對於微觀需求，我們可以將函式分段來解決問題。最終，我們可以獲得以下報價函式：
關於此報價函式的引數的具體含義，讀者可以參考上一篇文章內給出的介紹。我們在此處直接給出此定價函式的影象：
在上圖內，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 線圖的設定的最初報價為 0.1。在供應量達到 20000 時，價格從最初的 0.1 上漲為 300，漲幅達到了 3000 倍。
當然，有些應用可能無法一帆風順的走向成功。以下走勢 K 線圖展示了在早期蓬勃發展，突然遭遇危機導致使用者退出的價格變化情況：
上述幾個案例證明我們所提出的報價模型是有效的，其滿足了應用的成長規律，既存在早期的高成長，也存在後期的穩健成長。這些優勢是因為我們採用了分段的報價模型，在早期和後期使用了引數不同的報價函式。
另一方面，因為報價函式是連續的，所以使用者可以等待報價函式給出預期的報價，而且報價的具體情況會隨著使用者的行為發生變化。這使得在本節介紹的報價模型內，不僅存在使用者與報價模型的博弈，也存在的是使用者之間博弈。而使用者之間博弈是極其複雜，這導致很難根據報價模型反向推匯出一種策略以獲取無風險收益。
拓展應用
在本節中，我們將介紹 ERC7527 的以下幾種拓展應用:
- ERC7527 作為 AI 應用的激勵層
- 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 (…) 交易) 也會直接報錯。
在 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鏈上信貸協議能否成功突圍？
