Standard asynchronicznego stokenizowanego skarbca ERC-7540
Wprowadzenie
ERC-7540 rozszerza standard stokenizowanego skarbca ERC-4626, dodając obsługę asynchronicznych przepływów depozytów i umorzeń. Wprowadza wzorzec żądania, a następnie odbioru (request-then-claim): użytkownicy najpierw przesyłają żądanie (blokując swoje aktywa lub udziały), a następnie odbierają wynik po jego przetworzeniu przez skarbiec.
Jest to potrzebne, gdy skarbiec nie może dokonać natychmiastowego rozrachunku w jednej transakcji, na przykład:
- Protokoły aktywów świata rzeczywistego (RWA), takie jak stokenizowane obligacje skarbowe, kredyty prywatne i inne aktywa z cyklami rozrachunku T+1 lub T+2
- Pożyczanie z niepełnym zabezpieczeniem, gdzie ocena zdolności kredytowej odbywa się w sposób pozałańcuchowy
- Międzyłańcuchowe strategie skarbców, w których mostowanie wprowadza opóźnienia
- Tokeny płynnego stakingu (LST) z okresami odblokowania
Skarbce mogą być asynchroniczne tylko dla depozytów, tylko dla umorzeń lub dla obu tych operacji. Ta elastyczność pozwala programistom skarbców dodawać przepływy asynchroniczne tylko tam, gdzie wymaga tego bazowa strategia, zachowując synchroniczność drugiej strony.
Wymagania wstępne
Aby lepiej zrozumieć tę stronę, zalecamy najpierw przeczytać o standardach tokenów, ERC-20 oraz ERC-4626.
ERC-4626 a ERC-7540
W ERC-4626 rozrachunek depozytu następuje atomowo: inwestor wysyła aktywa i otrzymuje udziały z powrotem w jednej transakcji.
ERC-7540 dzieli to na dwa etapy. Inwestor najpierw wywołuje requestDeposit(), aby zablokować aktywa, a następnie czeka, aż menedżer skarbca przetworzy żądanie. Po jego zrealizowaniu inwestor wywołuje deposit(), aby odebrać swoje udziały. Kursy wymiany są ustalane w momencie realizacji, a nie w momencie żądania.
Przepływ umorzenia działa w ten sam sposób: requestRedeem() blokuje udziały, a po zrealizowaniu inwestor wywołuje redeem(), aby odebrać aktywa.
Funkcje i cechy ERC-7540
ERC-7540 dziedziczy pełny interfejs ERC-4626, ale zmienia przeznaczenie deposit/mint/withdraw/redeem na funkcje roszczeń (odbioru). Nowe funkcje requestDeposit i requestRedeem obsługują początkowy etap żądania.
Każde żądanie przechodzi przez trzy stany: oczekujące (przesłane, czekające na przetworzenie), możliwe do odebrania (zrealizowane i wycenione) oraz odebrane (inwestor odebrał swoje udziały lub aktywa).
Przepływ żądania depozytu
requestDeposit
function requestDeposit(uint256 assets, address controller, address owner) external returns (uint256 requestId)
Wykonuje transfer assets z owner do skarbca i przesyła żądanie depozytu. Adres controller otrzymuje kontrolę nad żądaniem. Zwraca requestId identyfikujący partię żądań.
pendingDepositRequest
function pendingDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets)
Zwraca kwotę assets w oczekującym (jeszcze niemożliwym do odebrania) żądaniu depozytu dla danego controller i requestId.
claimableDepositRequest
function claimableDepositRequest(uint256 requestId, address controller) external view returns (uint256 assets)
Zwraca kwotę assets w możliwym do odebrania (zrealizowanym, ale jeszcze nieodebranym) żądaniu depozytu dla danego controller i requestId.
Odbieranie depozytów
Gdy żądanie depozytu staje się możliwe do odebrania, użytkownik wywołuje standardową funkcję ERC-4626 deposit lub mint, aby odebrać swoje udziały. W ERC-7540 funkcje te nie wykonują już transferu aktywów (to nastąpiło w momencie żądania). Wybijają one jedynie udziały dla odbiorcy.
Przepływ żądania umorzenia
requestRedeem
function requestRedeem(uint256 shares, address controller, address owner) external returns (uint256 requestId)
Blokuje shares z owner i przesyła żądanie umorzenia. Adres controller otrzymuje kontrolę nad żądaniem.
pendingRedeemRequest
function pendingRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares)
Zwraca kwotę shares w oczekującym żądaniu umorzenia dla danego controller i requestId.
claimableRedeemRequest
function claimableRedeemRequest(uint256 requestId, address controller) external view returns (uint256 shares)
Zwraca kwotę shares w możliwym do odebrania żądaniu umorzenia dla danego controller i requestId.
Odbieranie umorzeń
Gdy żądanie umorzenia staje się możliwe do odebrania, użytkownik wywołuje standardową funkcję ERC-4626 redeem lub withdraw, aby odebrać swoje aktywa.
Zarządzanie operatorami
ERC-7540 zawiera wzorzec operatora (z ERC-6909 (otwiera się w nowej karcie)), który pozwala stronom trzecim zarządzać żądaniami w imieniu użytkownika.
setOperator
function setOperator(address operator, bool approved) external returns (bool)
Zatwierdza lub odwołuje operator do działania w imieniu msg.sender w przypadku żądań depozytu/umorzenia i roszczeń.
isOperator
function isOperator(address controller, address operator) external view returns (bool)
Zwraca informację, czy operator jest zatwierdzony do działania w imieniu controller.
Identyfikatory żądań
Identyfikatory żądań odróżniają od siebie różne partie żądań. Wszystkie żądania współdzielące ten sam requestId są zamienne: przechodzą między stanami razem i otrzymują ten sam kurs wymiany.
Gdy skarbiec zwraca requestId = 0 dla wszystkich żądań, tylko adres controller różnicuje stan żądania. Wiele żądań od tego samego kontrolera jest agregowanych.
Zdarzenia
Zdarzenie DepositRequest
MUSI zostać wyemitowane, gdy żądanie depozytu zostanie przesłane za pośrednictwem requestDeposit.
event DepositRequest(
address indexed controller,
address indexed owner,
uint256 indexed requestId,
address sender,
uint256 assets
)
Zdarzenie RedeemRequest
MUSI zostać wyemitowane, gdy żądanie umorzenia zostanie przesłane za pośrednictwem requestRedeem.
event RedeemRequest(
address indexed controller,
address indexed owner,
uint256 indexed requestId,
address sender,
uint256 shares
)
Zdarzenie OperatorSet
MUSI zostać wyemitowane, gdy operator zostanie zatwierdzony lub odwołany za pośrednictwem setOperator.
event OperatorSet(
address indexed controller,
address indexed operator,
bool approved
)
Funkcje podglądu
Funkcje podglądu muszą zostać wycofane tylko dla przepływów, które są asynchroniczne, ponieważ kurs wymiany nie jest znany, dopóki żądanie nie zostanie zrealizowane. W skarbcu z asynchronicznym depozytem previewDeposit i previewMint MUSZĄ zostać wycofane, podczas gdy previewRedeem i previewWithdraw nadal działają jak w ERC-4626 (i odwrotnie dla skarbca z asynchronicznym umorzeniem). Jest to kluczowa różnica w zachowaniu w stosunku do ERC-4626.