Zum Hauptinhalt springen
Change page

ERC-7540: Standard für asynchrone tokenisierte Tresore

Einführung

ERC-7540 erweitert den ERC-4626-Standard für tokenisierte Tresore um die Unterstützung für asynchrone Einzahlungs- und Rücknahmeprozesse. Er führt ein Anfrage-dann-Beanspruchen-Muster (request-then-claim) ein: Benutzer reichen zunächst eine Anfrage ein (wodurch ihre Vermögenswerte oder Anteile gesperrt werden) und beanspruchen dann das Ergebnis, nachdem der Tresor es verarbeitet hat.

Dies ist erforderlich, wenn ein Tresor nicht sofort in einer einzigen Transaktion abgewickelt werden kann, zum Beispiel:

  • Protokolle für reale Vermögenswerte (RWA) wie tokenisierte Staatsanleihen, Privatkredite und andere Vermögenswerte mit T+1- oder T+2-Abwicklungszyklen
  • Unterbesicherte Kreditvergabe, bei der Bonitätsprüfungen offchain stattfinden
  • Kettenübergreifende Tresor-Strategien, bei denen das Bridging Verzögerungen verursacht
  • Liquid-Staking-Token (LST) mit Entbindungsfristen

Tresore können wählen, ob sie nur bei Einzahlungen, nur bei Rücknahmen oder bei beidem asynchron sein möchten. Diese Flexibilität ermöglicht es Tresor-Entwicklern, asynchrone Prozesse nur dort hinzuzufügen, wo die zugrunde liegende Strategie dies erfordert, während die andere Seite synchron bleibt.

Voraussetzungen

Um diese Seite besser zu verstehen, empfehlen wir Ihnen, sich zunächst über Token-Standards, ERC-20 und ERC-4626 zu informieren.

ERC-4626 im Vergleich zu ERC-7540

In ERC-4626 wird eine Einzahlung atomar abgewickelt: Der Investor sendet Vermögenswerte und erhält in einer einzigen Transaktion Anteile zurück.

ERC-4626 synchronous deposit flow

ERC-7540 teilt dies in zwei Schritte auf. Der Investor ruft zunächst requestDeposit() auf, um Vermögenswerte zu sperren, und wartet dann darauf, dass der Tresor-Manager die Anfrage verarbeitet. Sobald diese erfüllt ist, ruft der Investor deposit() auf, um seine Anteile zu beanspruchen. Wechselkurse werden zum Zeitpunkt der Erfüllung festgelegt, nicht zum Zeitpunkt der Anfrage.

ERC-7540 asynchronous deposit flow

Der Rücknahmeprozess funktioniert auf die gleiche Weise: requestRedeem() sperrt Anteile, und sobald die Anfrage erfüllt ist, ruft der Investor redeem() auf, um Vermögenswerte zu beanspruchen.

Funktionen und Merkmale von ERC-7540

ERC-7540 erbt die vollständige ERC-4626-Schnittstelle, verwendet jedoch deposit/mint/withdraw/redeem als Anspruchsfunktionen (Claim-Funktionen) um. Die neuen Funktionen requestDeposit und requestRedeem übernehmen den anfänglichen Anfrageschritt.

Jede Anfrage durchläuft drei Zustände: ausstehend (eingereicht, wartet auf Verarbeitung), beanspruchbar (erfüllt und bepreist) und beansprucht (Investor hat seine Anteile oder Vermögenswerte abgeholt).

Request lifecycle: Pending, Claimable, Claimed

Ablauf der Einzahlungsanfrage

requestDeposit

function requestDeposit(uint256 assets, address controller, address owner) external returns (uint256 requestId)

Überträgt assets von owner in den Tresor und reicht eine Einzahlungsanfrage ein. Die Adresse controller erhält die Kontrolle über die Anfrage. Gibt eine requestId zurück, die den Anfrage-Stapel (Batch) identifiziert.

pendingDepositRequest

function pendingDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets)

Gibt die Menge an assets in einer ausstehenden (noch nicht beanspruchbaren) Einzahlungsanfrage für die angegebene controller und requestId zurück.

claimableDepositRequest

function claimableDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets)

Gibt die Menge an assets in einer beanspruchbaren (erfüllten, aber noch nicht beanspruchten) Einzahlungsanfrage für die angegebene controller und requestId zurück.

Einzahlungen beanspruchen

Sobald eine Einzahlungsanfrage beanspruchbar wird, ruft der Benutzer die Standard-ERC-4626-Funktion deposit oder mint auf, um seine Anteile zu beanspruchen. In ERC-7540 übertragen diese Funktionen keine Vermögenswerte mehr (das ist bereits zum Zeitpunkt der Anfrage geschehen). Sie prägen lediglich Anteile für den Empfänger.

Ablauf der Rücknahmeanfrage

requestRedeem

function requestRedeem(uint256 shares, address controller, address owner) external returns (uint256 requestId)

Sperrt shares von owner und reicht eine Rücknahmeanfrage ein. Die Adresse controller erhält die Kontrolle über die Anfrage.

pendingRedeemRequest

function pendingRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares)

Gibt die Menge an shares in einer ausstehenden Rücknahmeanfrage für die angegebene controller und requestId zurück.

claimableRedeemRequest

function claimableRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares)

Gibt die Menge an shares in einer beanspruchbaren Rücknahmeanfrage für die angegebene controller und requestId zurück.

Rücknahmen beanspruchen

Sobald eine Rücknahmeanfrage beanspruchbar wird, ruft der Benutzer die Standard-ERC-4626-Funktion redeem oder withdraw auf, um seine Vermögenswerte zu beanspruchen.

Operator-Verwaltung

ERC-7540 enthält ein Operator-Muster (aus ERC-6909 (öffnet in einem neuen Tab)), das es Dritten ermöglicht, Anfragen im Namen eines Benutzers zu verwalten.

setOperator

function setOperator(address operator, bool approved) external returns (bool)

Genehmigt oder widerruft operator, um im Namen von msg.sender für Einzahlungs-/Rücknahmeanfragen und Ansprüche zu handeln.

isOperator

function isOperator(address controller, address operator) external view returns (bool)

Gibt zurück, ob operator genehmigt ist, im Namen von controller zu handeln.

Anfrage-IDs

Anfrage-IDs unterscheiden zwischen verschiedenen Anfrage-Stapeln. Alle Anfragen, die dieselbe requestId teilen, sind fungibel: Sie wechseln gemeinsam zwischen Zuständen und erhalten denselben Wechselkurs.

Wenn ein Tresor requestId = 0 für alle Anfragen zurückgibt, unterscheidet nur die Adresse controller den Anfrage-Zustand. Mehrere Anfragen desselben Controllers werden aggregiert.

Ereignisse

DepositRequest-Ereignis

MUSS ausgelöst werden, wenn eine Einzahlungsanfrage über requestDeposit eingereicht wird.

event DepositRequest(
    address indexed controller,
    address indexed owner,
    uint256 indexed requestId,
    address sender,
    uint256 assets
)

RedeemRequest-Ereignis

MUSS ausgelöst werden, wenn eine Rücknahmeanfrage über requestRedeem eingereicht wird.

event RedeemRequest(
    address indexed controller,
    address indexed owner,
    uint256 indexed requestId,
    address sender,
    uint256 shares
)

OperatorSet-Ereignis

MUSS ausgelöst werden, wenn ein Operator über setOperator genehmigt oder widerrufen wird.

event OperatorSet(
    address indexed controller,
    address indexed operator,
    bool approved
)

Vorschaufunktionen

Die Vorschaufunktionen dürfen nur für die Prozesse rückgängig gemacht werden (revert), die asynchron sind, da der Wechselkurs erst bekannt ist, wenn die Anfrage erfüllt ist. In einem Tresor mit asynchroner Einzahlung MÜSSEN previewDeposit und previewMint rückgängig gemacht werden, während previewRedeem und previewWithdraw weiterhin wie in ERC-4626 funktionieren (und umgekehrt für einen Tresor mit asynchroner Rücknahme). Dies ist ein wesentlicher Verhaltensunterschied zu ERC-4626.

Weiterführende Literatur