MiCA a DEX-y i DeFi: jak ocenić, czy projekt jest „w pełni zdecentralizowany”?

W poprzednim artykule przyjrzeliśmy się granicom regulacyjnego oddziaływania rozporządzenia MiCA na zdecentralizowane finanse (DeFi), w tym zdecentralizowane giełdy (DEX-y). Jeśli nie czytałeś/aś jeszcze pierwszej części, możesz zapoznać się z nią tutaj.  Wskazaliśmy, że rozporządzenie MiCA nie obejmuje usług świadczonych w pełni zdecentralizowanie, bez pośredników, ani emisji kryptoaktywów bez możliwego do zidentyfikowania emitenta. Takie podejście może stanowić furtkę do wyłączenia projektu spod obowiązków regulacyjnych.

W praktyce jednak kluczowe wyzwanie sprowadza się do tego, jak ocenić, czy dany projekt – w tym DEX – rzeczywiście spełnia kryteria decentralizacji, a także czy emisja kryptoaktywów pozwala na identyfikację emitenta. MiCA nie zawiera ani definicji „pełnej decentralizacji”, ani „możliwego do zidentyfikowania emitenta”, ani listy kryteriów, które mogłyby być stosowane przez organy nadzoru – w tym Komisję Nadzoru Finansowego – do kwalifikowania projektów jako objętych lub wyłączonych spod regulacji.

W konsekwencji każdy przypadek może wymagać indywidualnej oceny, co rodzi istotną niepewność prawną – zarówno po stronie projektów, jak i organów nadzoru.

W drugiej części artykułu skupimy się więc na poszukiwaniu praktycznych kryteriów, które mogą mieć znaczenie przy ocenie poziomu decentralizacji danego projektu.

Czy projekt jest wystarczająco zdecentralizowany?

W podejściu scentralizowanym za funkcjonowaniem usługi stoi zazwyczaj konkretny podmiot prawny, który odpowiada za wdrożenie, utrzymanie i ewentualne modyfikacje algorytmu. To właśnie jego udział może czynić go „pośrednikiem” w rozumieniu rozporządzenia MiCA

W projektach opartych na pełnej decentralizacji kluczową cechą jest co do zasady brak realnej możliwości sprawowania kontroli nad działaniem algorytmu po jego wdrożeniu. W przeciwieństwie do modeli scentralizowanych, w których kod może być zarządzany lub modyfikowany przez określony podmiot, zdecentralizowane rozwiązania często funkcjonują w sposób całkowicie autonomiczny. Smart kontrakt uruchomiony w sieci blockchain działa według niezmienialnych reguł – bez opcji wstrzymania czy ręcznej ingerencji, co praktycznie uniemożliwia przypisanie komukolwiek roli operatora lub nadzorcy, zatem jeśli po wdrożeniu smart kontraktu do sieci blockchain nie ma już technicznej możliwości jego modyfikacji, może to wskazywać na decentralizację projektu.

Tego rodzaju autonomiczne algorytmy mogą działać w sposób ciągły, bez udziału czynnika ludzkiego, nie przypisując skutków prawnych żadnemu zidentyfikowanemu podmiotowi. Dobrym przykładem są zdecentralizowane giełdy krypto (DEX-y), proste autonomiczne smart kontrakty typu swap, umożliwiające wymianę jednego tokena na inny według stałego kursu, bez interfejsu użytkownika i bez jakiejkolwiek możliwości modyfikacji po wdrożeniu. Klasycznym przykładem pełnej decentralizacji, w mojej ocenie, może być pierwsza wersja protokołu Uniswap (v1).

Zatem aby dana usługa w zakresie kryptoaktywów została wyłączona spod regulacji, musi być świadczona w sposób „w pełni zdecentralizowany, bez pośredników”. Każda forma kontroli, nadzoru, aktualizacji czy możliwości ingerencji w kod – może oznaczać, że projekt podlega MiCA i wymaga uzyskania licencji CASP.

Emisja kryptoaktywów a decentralizacja

Kwestie związane z emisją kryptoaktywów zostały uregulowane inaczej. W tym przypadku, przepisy tytułów II, III i IV (dotyczące m.in. whitepaperów, zasad emisji i dopuszczania tokenów do obrotu) nie będą miały zastosowania, jeżeli token nie posiada możliwego do zidentyfikowania emitenta.

W praktyce może to obejmować sytuacje, w których emisja tokenów odbywa się automatycznie bez centralnego udziału człowieka. Również tutaj kluczowe znaczenie ma to, czy da się przypisać proces emisji określonemu podmiotowi lub grupie podmiotów, które kontrolują lub czerpią z niego korzyści.

Kluczowe elementy oceny decentralizacji usług

Decentralizacja nie jest cechą zero-jedynkową, lecz spektrum obejmującym różne aspekty działania projektu. W praktyce należy analizować rzeczywistą strukturę kontroli i wpływu, ponieważ wiele projektów reklamowanych jako „zdecentralizowane” wciąż zawiera istotne elementy scentralizowane – takie jak osoby lub podmioty dysponujące decydującym wpływem na funkcjonowanie systemu.

Poniżej przedstawiam zestaw najważniejszych pytań pomocnych przy ocenie poziomu decentralizacji usług. Zestawienie to stanowi próbę identyfikacji elementów, które mogą zostać uwzględnione przez organy nadzorcze przy formułowaniu wytycznych pozwalających krajowym regulatorom ocenić, czy dany model działalności rzeczywiście posiada cechy decentralizacji.

Przykładowe pytania pomocne przy ocenie decentralizacji

Suwerenność kodu i aktualizacji

1. Kto posiada uprawnienia do wdrażania zmian lub aktualizacji smart kontraktów (np. admin keys, proxy contracts, timelock DAO)?
2. Czy uprawnienia administracyjne – jeśli występują – są zabezpieczone mechanizmem multi-sig, wymagającym podpisów od kilku niepowiązanych podmiotów?
3. Kto ma prawo inicjować i zatwierdzać zmiany parametrów protokołu? Jak wygląda procedura zatwierdzania nowych wersji kodu – czy wymaga ona rozproszonego konsensusu społeczności?
4. Czy istnieje tryb „awaryjnego wyłączenia” lub wstrzymania działania protokołu? Jeśli tak – kto może go aktywować i w jakiej procedurze?

Ekonomia protokołu

1. Czy działanie usługi generuje przychody? Jeśli tak, kto je otrzymuje – pojedynczy operator, czy społeczność (np. dostawcy płynności)?
2. Czy istnieje skarbiec (community treasury) zarządzany w sposób zdecentralizowany? Jeśli tak, to jak podejmowane są decyzje o wydatkowaniu środków?
3. Czy protokół przewiduje mechanizmy takie jak fee-burn, automatyczny wykup tokenów lub redystrybucję przychodów? Kto może je modyfikować?
4. Czy parametry ekonomiczne (np. wysokość opłat, tempo emisji nagród) są na stałe zapisane w kontrakcie, czy mogą być zmienione? Jeśli tak to przez kogo?
5. Czy model wynagradzania może zostać zmodyfikowany przez wąską grupę interesariuszy?

Architektura dostępu i uczestnictwa

1. Czy użytkownik może korzystać z usługi bez rejestracji lub weryfikacji tożsamości?
2. Czy rozpoczęcie korzystania wymaga wcześniejszego zezwolenia, whitelisty lub zatwierdzenia przez podmiot centralny, operatora?
3. Czy smart kontrakty stosują ograniczenia geograficzne lub mechanizmy egzekwujące listy sankcyjne (np. OFAC)?

Autonomia majątkowa uczestników

1. Czy użytkownicy zachowują pełną i nieodwołalną kontrolę nad swoimi środkami przez cały okres interakcji z protokołem?
2. Czy kontrola nad środkami powierzona jest wyłącznie zdecentralizowanemu smart kontraktowi, czy też podmiot trzeci może nim zarządzać np. poprzez ingerencję w smart kontrakt?
3. Czy protokół przewiduje funkcje umożliwiające zamrożenie środków, cofnięcie transakcji lub wstrzymanie wypłat?
4. Jeśli cofnięcie transakcji jest niemożliwe na poziomie smart kontraktu, to czy jest również niemożliwe na poziomie warstwy bazowej (np. blockchaina na którym działa usługa)?
5. Czy użytkownik może w każdej chwili wypłacić swoje środki bez konieczności uzyskania zgody innego podmiotu?

Sterowanie protokołem

1. Jeżeli projekt korzysta z tokenów governance – jak bardzo rozproszona jest własność i siła głosu (czy np. większość głosów należy do kilku adresów)?
2. W przypadku zarządzania opartego na multisig– ilu sygnatariuszy liczy multisig, czy są oni niezależni od siebie, oraz czy możliwe jest zweryfikowanie ich tożsamości lub przynależności organizacyjnej?
3. Czy możliwe jest podejmowanie decyzji poza systemem on-chain?
4. Czy jakikolwiek podmiot trzeci posiada środki umożliwiające ingerencję w działanie lub logikę protokołu?

Odporność na cenzurę i otwarty dostęp

1. Czy jakikolwiek podmiot trzeci może jednostronnie zatrzymać lub odrzucić transakcję?
2. Czy sieć pozostaje funkcjonalna nawet w przypadku niedostępności części węzłów lub oficjalnych front-endów?
3. Czy kod źródłowy protokołu jest publicznie dostępny?
4. Czy istnieje możliwość zablokowania adresu użytkownika?
5. Czy w projekcie stosowane są tokeny, których smart kontrakty dopuszczają blokowanie określonych adresów?

Podsumowanie

Ocena decentralizacji projektu jest kluczowa dla określenia, czy projekt może być wyłączony z regulacji MiCA. Wymaga to szczegółowej analizy struktury kontroli, dostępu i autonomii w systemie. Przeprowadzenie takiej analizy pomoże zarówno projektom, jak i organom nadzoru w określeniu, czy projekt spełnia wymagania MiCA, a także w zabezpieczeniu zgodności z regulacjami.