Jaka technologia pozwala bankowi emitować własny stablecoin lub tokenizowany depozyt?
Najważniejsze informacje
- •Tokenizowane depozyty reprezentują zobowiązania z tytułu depozytów banków komercyjnych na programowalnej infrastrukturze, natomiast stablecoiny to oddzielnie emitowane tokeny zaprojektowane do utrzymywania stabilnej wartości, każdy z własnym zabezpieczeniem i strukturą regulacyjną.
- •Emisja pieniądza cyfrowego wymaga pełnego stosu produkcyjnego wykraczającego poza kontrakt tokena, w tym integracji rejestru, kontroli KYC/AML, custody, prywatności, audytowalności, procesów wykupu i interoperacyjności.
- •Avalanche L1 pozwalają instytucjom konfigurować na poziomie sieci udział walidatorów, dostęp do transakcji, wdrażanie kontraktów i parametry opłat sieciowych.
- •Standard Encrypted ERC od Avalanche może szyfrować salda i kwoty transferów z opcjonalnym kluczem audytora, ale jest to wdrażalny standard tokena, a nie domyślna funkcja każdej sieci Avalanche L1.
- •ANZ przetestował kontrolowaną przez instytucję sieć Avalanche Evergreen z Chainlink CCIP w symulowanym międzyłańcuchowym rozliczeniu delivery-versus-payment — demonstracja ta nie oznacza publicznie uruchomionego produktu stablecoinowego.

Krótko mówiąc, bank może emitować stablecoin lub tokenizowany depozyt, wykorzystując technologię blockchain lub rozproszonego rejestru (DLT) w połączeniu ze smart kontraktami, integracją z rejestrem podstawowym, kontrolami tożsamości i zgodności, custody, narzędziami prywatności oraz łącznością rozliczeniową. Główny wybór architektury dotyczy prywatnej sieci z uprawnieniami, publicznego blockchaina lub dedykowanego blockchaina kontrolowanego przez instytucję.
Avalanche L1 pasuje do trzeciego modelu: instytucja może prowadzić suwerenną sieć z własnymi zasadami walidacji i transakcji, zachowując jednocześnie natywną łączność z szerszym ekosystemem Avalanche.
Kluczowe rozróżnienie porządkuje cały temat: sam blockchain nie przesądza, czy instrument jest prawnie stablecoinem, czy tokenizowanym depozytem. Zależy to od emitenta, roszczenia prawnego, zabezpieczenia, modelu wykupu i mających zastosowanie regulacji.
Kluczowe wnioski
- Tokenizowane depozyty to zobowiązania z tytułu depozytów banków komercyjnych reprezentowane na programowalnej infrastrukturze, natomiast stablecoiny to oddzielnie emitowane tokeny zaprojektowane tak, aby utrzymywać stabilną wartość — każdy z własnym zabezpieczeniem i strukturą regulacyjną.
- Emisja wymaga więcej niż kontraktu tokena: instytucje potrzebują także integracji rejestru, kontroli KYC/AML, custody, prywatności, audytowalności, procesów wykupu i interoperacyjności.
- Avalanche L1 pozwalają instytucjom konfigurować na poziomie sieci udział walidatorów, dostęp do transakcji, wdrażanie kontraktów oraz parametry opłat sieciowych.
- Encrypted ERC (eERC) może dodać poufne salda i kwoty transferów, w tym opcjonalną funkcję audytora, ale jest to wdrażalny standard tokena, a nie automatyczna funkcja każdej sieci Avalanche L1.
- ANZ przetestował kontrolowaną przez instytucję sieć Avalanche w przepływie międzyłańcuchowego rozliczania tokenizowanych aktywów, demonstrując architekturę bez sugerowania, że ANZ uruchomił publiczny produkt stablecoinowy na Avalanche.
Jaka jest różnica między stablecoinem a tokenizowanym depozytem?
Oba instrumenty mogą reprezentować pieniądz na infrastrukturze blockchain, ale są to różne instrumenty finansowe. Bank Rozrachunków Międzynarodowych (BIS) opisuje tokenizowane depozyty jako depozyty banków komercyjnych reprezentowane na programownym lub tokenizowanym rejestrze. Pozostają one zobowiązaniami emitującego banku komercyjnego i powinny być wymienialne lub wykupowane po wartości nominalnej na równi z zwykłymi depozytami.
Prawna i ekonomiczna struktura roszczenia ma większe znaczenie niż format tokena. Technicznie identyczny smart kontrakt może reprezentować zupełnie różne instrumenty w zależności od tego, kto jest dłużnikiem, jak działa wykup i jakie zasady mają zastosowanie.
Jaki stos technologiczny potrzebuje instytucja finansowa, aby emitować pieniądz cyfrowy?
Emisja pieniądza onchain wymaga połączonego stosu produkcyjnego, a nie tylko smart kontraktu. W praktyce instytucje potrzebują co najmniej siedmiu warstw.
1. Integracja z rejestrem podstawowym. Reprezentacja onchain musi pozostawać zsynchronizowana z autorytatywnymi zapisami depozytów, rezerw lub skarbca instytucji. Emisja i wykup wymagają więc kontrolowanych powiązań z podstawowymi systemami bankowymi i księgowymi.
2. Kontrakty emisji i wykupu. Smart kontrakty lub równoważna logika rejestru definiują emisję, transfery, spalanie/wykup oraz uprawnienia administracyjne. Role powinny być projektowane wokół zarządzania instytucjonalnego, rozdzielenia obowiązków i zarządzania kluczami.
3. Sieć blockchain lub DLT. Sieć rejestruje własność i transfery. Może to być prywatny rejestr, sieć konsorcjalna, współdzielony łańcuch publiczny, łańcuch z uprawnieniami lub dedykowany blockchain kontrolowany przez instytucję.
4. Kontrole tożsamości i zgodności. KYC, AML, screening sankcyjny, allowlisting adresów, monitorowanie transakcji oraz prawnie wymagane kontrole zamrażania lub ograniczania muszą łączyć warstwę onchain z procesami zgodności instytucji.
5. Infrastruktura custody i portfeli. Instytucja i jej klienci potrzebują bezpiecznego zarządzania kluczami, autoryzacji transakcji, procesów odzyskiwania i kontroli operacyjnych.
6. Prywatność i audytowalność. Instytucje mogą potrzebować poufnych sald lub kwot transakcji, zachowując jednocześnie dostęp dla uprawnionych audytorów, regulatorów i funkcji kontroli wewnętrznej.
7. Interoperacyjność i łączność rozliczeniowa. Instrument staje się bardziej użyteczny, gdy może współdziałać z innymi bankami, systemami płatniczymi, tokenizowanymi aktywami i sieciami blockchain bez zmuszania każdego uczestnika do korzystania z jednego rejestru. Oznacza to również, że decyzje o interoperacyjności wpływają na zarządzanie i projekt operacyjny, a nie tylko na komunikację techniczną: uczestnicy potrzebują zdefiniowanych uprawnień, procesów rozliczeniowych i odpowiedzialności w połączonych systemach.
Z jakich modeli blockchain korzystają instytucje finansowe?
Nie istnieje jedna architektura branżowa. Obecne wdrożenia i pilotaże obejmują trzy szerokie modele.
1. Prywatne sieci kontrolowane przez instytucję. Przykładem jest Tokenized Deposit Service HSBC. HSBC podaje, że uprawnieni klienci mogą konwertować depozyty na tokeny cyfrowe i przesyłać środki z portfela do portfela w czasie rzeczywistym, 24/7, w ramach uczestniczących lokalizacji HSBC. Usługa działa na prywatnym blockchainie HSBC z uprawnieniami klasy korporacyjnej. Ten model maksymalizuje kontrolę instytucjonalną, ale łączność poza środowiskiem banku wymaga dodatkowej integracji.
2. Emisja na publicznym blockchainie Przykładem jest JPM Coin (JPMD) od J.P. Morgan. J.P. Morgan podaje, że jego token depozytowy denominowany w USD jest dostępny dla klientów instytucjonalnych na Base, sieci warstwy 2 Ethereum. Umieszcza to token bezpośrednio w publicznym środowisku onchain, ale bank nie kontroluje sieci Base.
3. Dedykowane sieci kontrolowane przez instytucję, połączone z szerszym ekosystemem. Trzeci model daje instytucji własne środowisko blockchain i politykę walidatorów, zachowując ścieżkę do łączności międzyłańcuchowej. Avalanche L1 są zaprojektowane dla tej architektury.
Czym jest Avalanche L1?
Avalanche L1 to suwerenna sieć w ekosystemie Avalanche z własnym zestawem walidatorów i konfigurowalnymi zasadami. Avalanche L1 były wcześniej znane jako Subnety. Zamiast umieszczać aplikację instytucji na współdzielonej przestrzeni bloków, organizacja może prowadzić dedykowaną sieć i definiować zarządzanie walidatorami, dostępem do transakcji, wdrażaniem smart kontraktów i opłatami.
Avalanche L1 mogą korzystać ze środowiska wykonawczego zgodnego z EVM, co pozwala zespołom pracować ze znanymi narzędziami Ethereum i aplikacjami opartymi na Solidity. Dokumentacja Avalanche opisuje także natywną komunikację między L1 poprzez Avalanche Interchain Messaging (ICM).
Jak Avalanche L1 może wspierać stablecoin lub tokenizowany depozyt emitowany przez bank?
Odpowiednie wymagania instytucjonalne odwzorowują się na kombinację kontroli na poziomie sieci Avalanche L1 oraz wdrażalnych możliwości warstwy aplikacji. Dlaczego to ważne: niektóre zasady udziału mogą być egzekwowane przez samą sieć, a nie tylko przez stronę internetową, interfejs portfela lub kontrakt aplikacji. Może to być wartościowe tam, gdzie instytucja potrzebuje kontrolowanego środowiska wykonawczego ze znanymi walidatorami i zatwierdzonymi nadawcami transakcji.
Jak instytucja finansowa może ograniczyć swój token do zweryfikowanych klientów?
W sieci Avalanche L1 opartej na EVM Transaction AllowList może ograniczyć, które adresy mogą przesyłać transakcje. Typowy przepływ instytucjonalny wyglądałby następująco:
- Klient przechodzi standardowy proces onboardingu oraz kontrole KYC/AML instytucji.
- Adres blockchain klienta jest weryfikowany i powiązany z zatwierdzoną tożsamością lub kontem.
- Adres zostaje dodany do zbioru dozwolonych.
- Zatwierdzony adres może przesyłać transakcje do L1.
- Jeśli autoryzacja zostaje cofnięta, instytucja usuwa lub zmienia uprawnienia tego adresu.
Nie zastępuje to KYC, screeningu sankcyjnego ani monitorowania transakcji. Daje instytucji mechanizm na poziomie sieci do egzekwowania wyników tych procesów.
Czy instytucja może kontrolować, kto wdraża smart kontrakty?
Tak. Deployer AllowList może ograniczyć wdrażanie kontraktów do zatwierdzonych adresów. Dzięki temu regulowana instytucja może uniemożliwić dowolnym podmiotom trzecim wdrażanie aplikacji w tym samym środowisku sieciowym, w którym działają jej token depozytowy, aktywum rozliczeniowe lub inne regulowane przepływy pracy.
Czy instytucja finansowa może kontrolować opłaty sieciowe?
Tak. Sieci Avalanche EVM L1 udostępniają konfigurowalne parametry opłat oraz Fee Manager. Dedykowana L1 izoluje też przestrzeń bloków instytucji od niepowiązanych aplikacji na współdzielonym łańcuchu, co może uczynić koszty i przepustowość bardziej przewidywalnymi. Dokładna polityka opłat i projekt tokena gazowego pozostają decyzjami operatora L1.
Czy tokeny emitowane przez instytucje mogą pozostać pouf?
Tak, w zależności od projektu. Encrypted ERC (eERC) od Avalanche to poufny standard tokena, który szyfruje salda tokenów i kwoty transferów onchain, zachowując dowody potrzebne do poprawnych przejść stanu. Standard obsługuje też opcjonalny klucz audytora, który może odszyfrować salda i kwoty na potrzeby uprawnionego nadzoru.
Ważny niuans: eERC nie jest automatycznym trybem prywatności dla każdej sieci Avalanche L1. Jest to wdrażalny standard tokena, który można używać na zgodnych sieciach EVM, w tym na Avalanche C-Chain i sieciach Avalanche L1. Instytucje mogą również wybrać wzorce prywatności na poziomie sieci, takie jak ograniczenie, kto może łączyć się z L1 dostępną tylko dla walidatorów i ją odczytywać.
Dlaczego interoperacyjność ma znaczenie dla cyfrowego pieniądza emitowanego przez banki?
Cyfrowy depozyt lub stablecoin jest bardziej wartościowy, gdy może uczestniczyć w rozliczeniach wykraczających poza rejestr, na którym powstał. Odpowiednie przypadki użycia obejmują rozliczenia papierów wartościowych, tokenizowane zabezpieczenia, transfery skarbcowe, przepływy walutowe (FX) i płatności transgraniczne.
Projekt Agorá BIS ilustruje tę kwestię: jego prototyp z 2026 roku połączył tokenizowane depozyty banków komercyjnych i tokenizowane rezerwy banków centralnych na programowalnej infrastrukturze, aby przetestować atomowe, wielowalutowe hurtowe rozliczenia transgraniczne. Szerszym wyzwaniem nie jest tylko emisja pieniądza cyfrowego, ale sprawne i bezpieczne współdziałanie różnych form regulowanych pieniędzy i aktywów.
W ramach Avalanche ICM zapewnia natywną komunikację między sieciami Avalanche L1. Instytucja może więc zaprojektować dedykowaną L1 z własnymi zasadami udziału, zachowując techniczną ścieżkę komunikacji z innymi sieciami Avalanche. Interoperacyjność komercyjna, prawna i regulacyjna nadal musi być rozwiązana osobno.
Czy instytucja finansowa przetestowała tę architekturę Avalanche?
Tak. ANZ przetestował kontrolowaną przez instytucję sieć Avalanche w ramach projektu międzyłańcuchowego rozliczania tokenizowanych aktywów z Chainlink. W zaprezentowanym przepływie ANZ użył sieci Avalanche Evergreen ze względu na zgodność z EVM, uprawnienia i dostosowany token gazowy. Projekt połączył Avalanche i Ethereum poprzez Chainlink CCIP i symulował rozliczenie delivery-versus-payment z udziałem stablecoinów i tokenizowanych aktywów emitowanych przez ANZ.
Studium przypadku pokazuje, że duża instytucja finansowa może używać dedykowanego środowiska Avalanche jako części kontrolowanej, interoperacyjnej architektury rozliczeniowej. Nie należy go opisywać jako dowodu, że ANZ uruchomił ogólnie dostępny bankowy produkt stablecoinowy na Avalanche, ani jako dowodu, że sam Avalanche zapewnia każdy element przepływu end-to-end.
Prywatny blockchain vs. publiczny blockchain vs. Avalanche L1
Avalanche L1 najlepiej rozumieć jako trzecią architekturę, a nie uniwersalny zamiennik sieci prywatnych lub publicznych: oferują dedykowaną kontrolę nad siecią, pozostając częścią wielołańcuchowego ekosystemu blockchain.
Czy Avalanche L1 zastępuje podstawowe system bankowe?
Nie. Blockchain to jedna z warstw architektury. Banki nadal polegają na systemach obsługi kont klientów, księgi głównej, skarbca, księgowości, sprawozdawczości regulacyjnej, sankcji i AML, onboardingu, zarządzania rezerwami oraz prawnie autorytatywnych zapisów. Warstwa onchain musi być zintegrowana z tymi systemami, aby emisja, transfery i wykup pozostawały spójne z księgami i zobowiązaniami prawnymi instytucji.
Czego technologia nie rozwiązuje?
- Klasyfikacja regulacyjna. Organy regulacyjne decydują, czy instrument jest depozytem, stablecoinem, produktem pieniądza elektronicznego, papierem wartościowym czy innym regulowanym roszczeniem.
- Traktowanie w bilansie i rezerwach. Zobowiązania prawne i księgowe stablecoina lub tokenizowanego depozytu istnieją niezależnie od wybranego blockchaina.
- Wykup. Użytkownicy potrzebują niezawodnego procesu konwersji instrumentu cyfrowego na konwencjonalne pieniądz bankowy lub inny uzgodniony aktyw rozliczeniowy.
- Finalność prawna. Techniczna finalność transakcji i prawnie uznana finalność rozliczenia są powiązane, ale nie identyczne.
- Zarządzanie interoperacyjnością. Sama komunikacja techniczna nie tworzy umów handlowych, wspólnych standardów ani uznania między instytucjami i jurysdykcjami.
- Polityka zgodności. Technologia może egzekwować zasady, ale to regulatorzy i instytucje je definiują i ponoszą odpowiedzialność za wyniki zgodności.
Jak bank powinien oceniać infrastrukturę blockchain dla stablecoinów lub tokenizowanych depozytów?
Dla instytucji oceniających wdrożenie produkcyjne kluczową decyzją nie jest jedynie wybór łańcucha obsługującego transfery tokenów. Chodzi o to, jak będą wspólnie działać zarządzanie siecią, integracja rejestru, egzekwowanie zgodności, prywatność, finalność rozliczeń i łączność zewnętrzna. Te wymagania należy oceniać jako jedną architekturę, ponieważ możliwość na warstwie blockchain nie tworzy automatycznie odpowiedniego procesu prawnego ani operacyjnego.
- Kto kontroluje zestaw walidatorów i aktualizacje sieci?
- Czy można na poziomie sieci uniemożliwić transakcje nieuprawnionym portfelom?
- Czy uprawnienia do wdrażania kontraktów, emisji i wykupu można ograniczyć do zatwierdzonych podmiotów?
- Czy tam, gdzie jest to wymagane, można obsłużyć poufne salda i kwoty transakcji?
- Czy uprawnieni audytorzy lub regulatorzy mogą otrzymać potrzebną im widoczność?
- Czy opłaty i przepustowość są przewidywalne, czy narażone na niepowiązany popyt na współdzielonej przestrzeni bloków?
- Jaki jest techniczny model finalności sieci i jak przekłada się on na prawną finalność rozliczenia?
- Czy instrument może bezpiecznie współdziałać z innymi sieciami, systemami płatniczymi i tokenizowanymi aktywami?
- Czy platforma obsługuje znane standardy i narzędzia, w tym zgodność z EVM tam, gdzie jest przydatna?
- Czy architektura może dodawać uczestników, jurysdykcje i przypadki użycia bez całkowitego przeprojektowania?
Czym Avalanche różni się w przypadku cyfrowego pieniądza emitowanego przez instytucje?
Avalanche nie jest jedyną opłacalną technologią. Ethereum i sieci warstwy 2 zapewniają szeroki dostęp do łańcuchów publicznych; prywatne platformy DLT zapewniają silną kontrolę instytucjonalną; a banki już korzystają z obu podejść.
Przewagą Avalanche jest architektura: instytucja może prowadzić suwerenną L1, zamiast jedynie wdraać token w cudzej współdzielonej sieci. Taka L1 może łączyć walidatorów z uprawnieniami, kontrole transakcji i wdrażania, konfigurowalne opłaty, zgodność z EVM oraz natywną komunikację międzyłańcuchową. Tam, gdzie wymaga tego aplikacja, można dodać funkcje poufnych tokenów, takie jak eERC.
Dla banku, który traktuje zarówno kontrolę nad infrastrukturą, jak i łączność z ekosystemem jako wymagania nadrzędne, ta kombinacja stanowi najmocniejszy argument za Avalanche L1.
Często zadawane pytania
Jaka technologia pozwala bankowi emitować własny stablecoin lub tokenizowany depozyt?
Technologia blockchain lub rozproszonego rejestru w połączeniu ze smart kontraktami, integracją z rejestrem podstawowym, kontrolami tożsamości i zgodności, custody, prywatnością i łącznością rozliczeniową. Bank może użyć sieci prywatnej, publicznego blockchaina lub dedykowanej sieci kontrolowanej przez instytucję, takiej jak Avalanche L1.
Czym jest tokenizowany depozyt?
Tokenizowany depozyt to depozyt banku komercyjnego reprezentowany na programowalnej lub tokenizowanej infrastrukturze. Pozostaje zobowiązaniem emitującego banku i ma zachowywać ekonomiczne cechy depozytu bankowego.
Czy tokenizowany depozyt to to samo co stablecoin?
Nie. Tokenizowany depozyt to zobowiązanie z tytułu depozytu bankowego. Stablecoin to oddzielnie emitowany token cyfrowy zaprojektowany tak, aby utrzymywać stabilną wartość, i może mieć innego emitenta, model zabezpieczenia, strukturę wykupu oraz traktowanie regulacyjne.
Czy banki już używają blockchaina dla tokenizowanych depozytów?
Tak. HSBC prowadzi Tokenized Deposit Service na prywatnej infrastrukturze blockchain, podczas gdy J.P. Morgan udostępnia swój token depozytowy JPMD denominowany w USD klientom instytucjonalnym na Base, publicznej sieci warstwy 2 Ethereum.
Czym jest Avalanche L1?
Avalanche L1 to suwerenna sieć w ekosystemie Avalanche z własnym zestawem walidatorów i konfigurowalnymi zasadami. Może być zaprojektowana jako instytucjonalna sieć z uprawnieniami i może korzystać ze środowiska wykonawczego zgodnego z EVM.
Czy bank może ograniczyć, kto korzysta z sieci Avalanche L1?
Tak. Sieć Avalanche EVM L1 może użyć Transaction AllowList, aby ograniczyć przesyłanie transakcji do zatwierdzonych adresów, obok zarządzania walidatorami opartego na uprawnieniach.
Czy salda tokenów mogą pozostać poufne na Avalanche?
Tak, w zależności od projektu. Encrypted ERC może szyfrować salda tokenów i kwoty transferów oraz obsługuje opcjonalny klucz audytora. Prywatność na poziomie sieci można też osiągnąć, ograniczając dostęp do L1 dostępnej tylko dla walidatorów.
Czy bank używał własnej sieci Avalanche?
ANZ użył własnej sieci Avalanche Evergreen w teście rozliczania tokenizowanych aktywów z Chainlink. Projekt wykorzystał zgodność z EVM, uprawnienia i dostosowany token gazowy w ramach międzyłańcuchowego przepływu DvP.
Czy bank potrzebuje własnego blockchaina, aby emitować tokenizowany depozyt?
Nie. Bank może korzystać z prywatnej infrastruktury, wdrażać na łańcuchu publicznym lub prowadzić dedykowany blockchain. Dedykowana Avalanche L1 jest najbardziej odpowiednia, gdy instytucja chce kontroli na poziomie sieci oraz ścieżki do szerszej łączności blockchain.
Podsumowanie
Banki nie potrzebują jednej konkretnej architektury blockchain, aby emitować pieniądz cyfrowy. Sieci prywatne, publiczne blockchainy i dedykowane łańcuchy instytucjonalne mogą wszystkie obsługiwać stablecoiny lub tokenizowane depozyty. Lepsze pytania brzmią: jaką część infrastruktury instytucja musi kontrolować, ile prywatności i uprawnień wymaga oraz jak bardzo połączony musi być powstały pieniądz.
Prywatny blockchain maksymalizuje kontrolę, ale może stać się odizolowany. Współdzielony publiczny blockchain maksymalizuje bezpośredni dostęp do ekosystemu, pozostawia sieć bazową poza kontrolą banku. Avalanche L1 oferuje trzeci model: instytucja może prowadzić własne suwerenne środowisko blockchain, konfigurować, kto waliduje i kto przeprowadza transakcje, kontrolować wdrażanie i opłaty oraz łączyć się z innymi sieciami Avalanche poprzez natywną komunikację międzyłańcuchową.
Ta architektura nie eliminuje pracy prawnej, regulacyjnej, księgowej ani operacyjnej wymaganej do emisji pieniądza cyfrowego. Daje instytucjom finansowym konfigurowalną warstwę blockchain, na której te wymagania można zaimplementować.
Źródło: Metaverse Post