隨著 ERC7540 逐漸受到關注，現在是在其之上構建新原語（primitives）的好時機。我希望解決的是讓 7540 非同步請求（async requests）具備同質化（fungible）的能力，並在以下規範中概述了我的實現方案。

如果有人深耕於 4626/7540 領域，希望能聽到您的反饋。

特別感謝 @jeroen 到目前為止提供的寶貴建議。

ERC7540Fungibility

待辦事項：想一個更好的名字

概述

ERC7540Fungibility 將待處理的 ERC-7540 非同步金庫請求轉換為同質化的 ERC-6909 索賠代幣（claim tokens）。用戶封裝其待處理的存款或贖回請求，獲得代表其倉位份額的同質化代幣，並在請求完成後銷毀這些代幣，直接從金庫領取已結算的資產。

該合約與金庫無關（vault-agnostic）——它適用於任何 ERC-7540 金庫，無論該金庫是否支持 ERC-8161 可轉讓請求。

運作原理

待處理的金庫請求是非同質化的——它與特定的控制器（controller）、金庫和請求 ID 綁定。將其封裝為 ERC-6909 代幣使其具備同質化。每個代幣代表底層倉位的相等份額。代幣持有者可以轉讓、交易或在其他協議中使用其份額。

每個封裝的請求都會獲得一個唯一的 tokenId（按順序發行）。底層金庫倉位由一個隔離的委託克隆（delegate clone）持有，該克隆在金庫上充當控制器。當金庫履行請求時，代幣持有者銷毀其 ERC-6909 份額，直接從金庫領取其對應的部分。

函數參考

函數	描述
transferDeposit	將現有的 ERC-8161 待處理存款請求封裝為同質化代幣
transferRedeem	將現有的 ERC-8161 待處理贖回請求封裝為同質化代幣
requestDeposit	從所有者處提取資產，發起存款請求，並鑄造同質化代幣
requestRedeem	從所有者處提取金庫份額，發起贖回請求，並鑄造同質化代幣
pending	檢查金庫請求是否仍在處理中
cancel	通過 ERC-8161 將金庫請求轉回指定的控制器
redeem	銷毀份額並直接從金庫領取相應部分

封裝模式

ERC-8161 轉讓 (transferDeposit / transferRedeem)

適用於支持可轉讓請求的金庫。用戶擁有現有的待處理請求，並將其控制器轉讓給委託克隆。需要將此合約設置為該控制器在金庫上的操作員（operator）。

直接請求 (requestDeposit / requestRedeem)

適用於不支持 ERC-8161 的金庫。合約從所有者處提取資產或份額，部署委託克隆，並通過該委託在金庫上發起新請求。該委託成為金庫上的控制器。

在這兩種模式下，接收者都會獲得等同於請求金額的 ERC-6909 代幣。

生命週期

封裝 (transfer* 或 request*) → [待處理] → 贖回 (銷毀份額，從金庫領取)
↓
取消 (將請求轉回控制器)

封裝 (Wrap) — 用戶封裝金庫倉位。部署委託克隆。向接收者鑄造 ERC-6909 代幣。

待處理 (Pending) — 金庫正在處理請求。代幣可自由轉讓。

贖回 (Redeem) — 代幣持有者銷毀份額，並通過 deposit()（針對存款請求）或 redeem()（針對贖回請求）直接從金庫領取其部分。每次調用都對金庫執行部分領取。返還金額由執行時的金庫匯率決定。

取消 (Cancel) — 僅限所有者。通過 ERC-8161 將金庫請求轉回指定的控制器。所有 ERC-6909 代幣將被銷毀且該代幣被刪除。僅在所有者仍持有所有份額時允許。

結算模型

沒有單獨的 claim() 步驟。當持有者調用 redeem() 時，合約通過委託克隆直接委託底層金庫的 deposit() 或 redeem() 函數。金庫在執行時決定匯率。每次部分贖回都是獨立的金庫交互。

這意味著如果金庫在兩次調用之間重新定價，不同贖回者之間的匯率可能會有所不同。這是一個刻意的設計選擇——同質化合約是一個輕量級封裝，不試圖覆蓋或快照金庫的結算機制。如果金庫重新定價，那是金庫按設計運作的結果。

這種模型的一個後果是 previewRedeem() 無法作為原生的 view 函數。ERC-7540 非同步金庫在 previewRedeem 中返回 0，且在執行前沒有 view 函數能暴露最終轉換率。鏈下使用者可以通過 eth_call 模擬結果。需要預覽的鏈上使用者可以使用 Uniswap Quoter 的 revert-call 模式——在子調用中執行金庫調用，該子調用以編碼在 revert 數據中的結果進行 revert，然後在父調用中解碼該結果。

託管模型

每個封裝的請求都有通過 EIP-1167 最小代理（minimal proxy）部署的專屬委託克隆。委託是一個輕量級執行合約（約 77 字節），負責將調用從同質化合約轉發到金庫。資產永遠不會接觸同質化合約本身。

委託克隆的存在主要是為了區分請求。對於 requestId = 0 的金庫，唯一的區分因素是控制器地址，因此我們需要為每個封裝請求提供唯一的控制器。部署輕量級克隆實現了這一點——每個克隆都有自己的地址，並在底層金庫上充當控制器。

克隆還提供了資產隔離。當請求被履行且持有者贖回時，金庫通過委託發送結算資產。如果資產匯集在主合約中，任何人都可以使用相同的底層代幣部署一個虛假的 ERC-7540 金庫，創建一個「解析」為任意金額的請求，並抽乾來自另一個合法金庫請求的資金。通過每個請求獨立的委託，惡意金庫只能接觸到它自己的克隆——沒有共享資金池可供竊取。

授權

ERC-6909 操作員 (Operators) — 通過 setOperator() 進行全局批准。操作員可以代表所有者處理所有 token ID。用於取消、代為贖回和委託封裝。

ERC-6909 額度 (Allowances) — 通過 approve() 進行特定 token ID 的批准。僅控制份額轉讓。不授予取消或贖回的權限。

金庫操作員 (Vault Operator) — 對於 transferDeposit / transferRedeem，此合約必須被設置為該控制器在金庫上的操作員。這是金庫合約上的獨立批准。

取消

取消操作通過 ERC-8161 將金庫請求轉回指定的控制器。這是一個同步操作——沒有兩步非同步取消模式。合約會：

• 驗證所有者仍持有所有份額（未發生轉讓）

• 銷毀所有 ERC-6909 代幣並將供應量歸零

• 調用金庫上的 transferDepositRequest 或 transferRedeemRequest，將請求從委託移回指定的控制器

• 刪除該代幣

金庫必須支持 ERC-8161 才能使取消功能運作。針對不支持 ERC-8161 的金庫封裝的請求（通過 requestDeposit / requestRedeem 創建）無法通過此機制取消。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/making-7540-fungible/28253)