概述
如何對早期的想法或應用程式進行定價,並參與投資?這在去中心化世界是一個巨大的挑戰。 ERC7527遵循「信用創造貨幣」的共識,提出了一種基於Premium驅動的去中心化定價的範式。
在本文中,我們將深入介紹ERC7527的原理及協議細節,進一步介紹連續報價模型的運作原理及其巨大優勢。同時,我們也會介紹一些基於ERC7527的可程式性和可組合性而產生的拓展應用。
ERC7527
在上一篇文章中,我們介紹了目前常見的純鏈上定價模型,其中也介紹了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通證不可能獲得質押收益。