MiCA w pigułce: Twój dokument techniczny dotyczący kryptowaluty nie może być tylko plikiem Gitbook lub PDF

„MiCA Decoded” to cotygodniowa seria 12 artykułów dla serwisu Bitcoin.com News, której współautorami są współzałożyciele i dyrektorzy zarządzający LegalBison: Aaron Glauberman, Viktor Juskin i Sabir Alijev. LegalBison doradza firmom z branży kryptowalutowej i FinTech w zakresie licencjonowania MiCA, wniosków CASP i VASP oraz strukturyzacji regulacyjnej w Europie i poza nią.

Zgodnie z MiCA biała księga jest obowiązkowym instrumentem ujawniania informacji. Jej najbliższym odpowiednikiem w tradycyjnych finansach jest prospekt emisyjny, a nie dokument marketingowy. Rozporządzenie określa, kto musi ją przygotować, w jakim formacie, z jakimi identyfikatorami, podlegającą jakiej automatycznej walidacji oraz z odpowiedzialnością przypisaną do konkretnej, wymienionej z imienia i nazwiska osoby.

Błąd w którymkolwiek z tych elementów oznacza, że dokument nie istnieje w oczach europejskich organów regulacyjnych, niezależnie od tego, jak dobrze jest napisany.

W szóstej części serii „MiCA Decoded” wyjaśniamy krok po kroku, co to właściwie oznacza.

Mit: Biała księga MiCA to tylko GitBook lub plik PDF

Biała księga MiCA ma rangę formalnego zgłoszenia regulacyjnego.

Rozporządzenie wykonawcze Komisji (UE) 2024/2984, które reguluje formy, formaty i szablony białych ksiąg dotyczących aktywów kryptograficznych, wymaga, aby dokument był przygotowany w ustrukturyzowanym formacie cyfrowym, zaprojektowanym tak, aby ESMA i właściwe organy krajowe we wszystkich państwach członkowskich UE mogły przeprowadzić identyczną automatyczną analizę każdego zgłoszenia, niezależnie od tego, kto je złożył i gdzie.

Cel prawny tego wyboru projektowego ma większe znaczenie niż szczegóły techniczne. MiCA jest rozporządzeniem dotyczącym jednolitego rynku, a porównywalność zgłoszeń stanowi podstawowe narzędzie egzekwowania przepisów.

Biała księga, której nie można odczytać za pomocą tego samego urządzenia, co wszystkie inne białe księgi złożone w Europie, nie jest zgodna z przepisami, niezależnie od treści, jaką zawiera. ESMA opublikowała wymaganą taksonomię (ustrukturyzowane ramy określające, co musi zawierać zgodna z przepisami biała księga) 5 sierpnia 2025 r. Przepisy wchodzą w życie 23 grudnia 2025 r.

Obowiązki informacyjne różnią się w zależności od rodzaju danego kryptowaluty. MiCA wyodrębnia trzy odrębne kategorie, z których każda ma własny szablon białej księgi i wymagania dotyczące pól:

Kategoria ta określa nie tylko treść białej księgi, ale także całą ścieżkę prawną prowadzącą do jej złożenia. Projekt nie może wybrać kategorii, która ma zastosowanie, w oparciu o własne preferencje. Określają ją cechy aktywów, a z tego wynikają obowiązki związane z przygotowaniem.

Kto ponosi obowiązek prawny – i odpowiedzialność

W przypadku zdecydowanej większości tokenów na rynku (sklasyfikowanych jako „inne” aktywa kryptograficzne lub OTHR) obowiązek ten nie spoczywa automatycznie na podmiocie, który stworzył token. W przypadku tych aktywów MiCA nakłada obowiązek na oferenta lub osobę ubiegającą się o dopuszczenie do obrotu, które są zdefiniowanymi rolami, które mogą, ale nie muszą pokrywać się z pierwotnym emitentem.

To rozróżnienie ma realne konsekwencje. Projekt należący do kategorii OTHR, uruchomiony z Brytyjskich Wysp Dziewiczych, Kajmanów lub jakiejkolwiek innej jurysdykcji offshore, może być oferentem w rozumieniu MiCA i bezpośrednio ponosić obowiązek sporządzenia białej księgi, bez konieczności przenoszenia swojej siedziby prawnej do Europy.

(Uwaga: Ta elastyczność strukturalna dotyczy wyłącznie tokenów OTHR. W przypadku tokenów powiązanych z aktywami (Asset-Referenced Tokens) oraz tokenów pieniądza elektronicznego (E-Money Tokens) obowiązek prawny i ścisła odpowiedzialność cywilna za białą księgę spoczywają wyłącznie na autoryzowanym emitencie z UE i nie mogą być delegowane).

Jak przeanalizowaliśmy w drugiej części tej serii, rejestry ESMA potwierdzają, że jest to już standardowa praktyka: większość niezależnych zgłoszeń tokenów pochodzi od podmiotów z siedzibą poza UE.

CASP prowadzący platformę handlową może również przejąć obowiązek związany z białą księgą, z własnej inicjatywy lub na podstawie pisemnej umowy z zespołem projektowym. Nie jest to luka prawna ani udogodnienie administracyjne.
Kiedy CASP składa wniosek, przyjmuje na siebie odpowiedzialność prawną za dokładność i kompletność ujawnionych informacji. Jeśli biała księga zawiera informacje wprowadzające w błąd lub nie spełnia standardów regulacyjnych, odpowiedzialność spoczywa na tym, kto ją złożył.

Osoba zatwierdzająca białą księgę nie może przenieść tego ryzyka na dostawcę oprogramowania, integratora technicznego ani kancelarię prawną. Przegląd prawny treści i poprawność techniczna to dwa odrębne obowiązki w zakresie zgodności z przepisami, a za oba odpowiada oferent. Jest to kwestia, którą większość projektów nie docenia.

Dwa kody, które muszą istnieć przed rozpoczęciem składania dokumentów

Dwa obowiązkowe identyfikatory są warunkiem wstępnym dla każdej zgodnej z przepisami białej księgi. Oba pochodzą z międzynarodowych standardów, które powstały przed MiCA. Rozporządzenie ich nie stworzyło, ale uczyniło je obowiązkowymi.

Pierwszym z nich jest identyfikator podmiotu prawnego (LEI), kod ISO 17442 przypisywany podmiotom prawnym i przechowywany w globalnej bazie danych LEI zarządzanej przez GLEIF. Wymóg jego stosowania obejmuje wiele standardów regulacyjnych: podczas gdy art. 14 RTS dotyczącego prowadzenia dokumentacji (rozporządzenie delegowane Komisji UE 2025/1140) nakłada na CASP wymogi dotyczące LEI w odniesieniu do ich klientów, art. 3 RTS w sprawie klasyfikacji białych ksiąg (rozporządzenie delegowane Komisji UE 2025/421) ściśle nakazuje, aby wszyscy autorzy białych ksiąg identyfikowali swój podmiot prawny za pomocą ważnego kodu LEI. Każdy podmiot, który jeszcze go nie posiada, musi zakończyć proces ubiegania się o LEI przed rozpoczęciem przygotowywania białej księgi.

Drugim jest identyfikator tokenu cyfrowego (DTI), kod ISO 24165 identyfikujący sam kryptowalutowy składnik aktywów, utrzymywany w rejestrze DTIF. Jego stosowanie wymagają art. 15 RTS dotyczącego prowadzenia dokumentacji oraz art. 3 RTS dotyczącego klasyfikacji białej księgi (rozporządzenie delegowane Komisji UE 2025/421). Kluczowa kwestia dla każdego projektu wprowadzającego nowy token: jeśli DTI nie istnieje jeszcze w rejestrze, ktoś musi złożyć wniosek o jego utworzenie, zanim będzie można złożyć białą księgę. W przypadku gdy CASP zgłasza aktywa bez scentralizowanego emitenta i bez istniejącej białej księgi, platforma jest odpowiedzialna za pobranie lub zażądanie DTI bezpośrednio z DTIF.

Źródło: Rejestr DTIF dla aktywów kryptograficznych

Biała księga, która nie zawiera ważnego kodu LEI i DTI, nie przechodzi automatycznej walidacji, zanim trafi do recenzenta. Projekty, które dotrą do etapu składania wniosku bez obu kodów, muszą zacząć wszystko od nowa.

Automatyczna bramka i jej znaczenie prawne

Żadna osoba z krajowego organu właściwego nie sprawdza białej księgi, która nie przeszła automatycznych kontroli. Taksonomia ESMA określa 257 kontroli istnienia (sprawdzających, czy wymagane pola są obecne) oraz 223 kontrole wartości (sprawdzających, czy zawartość pól jest prawidłowa). Zgłoszenie, które nie przeszło kontroli o poziomie ważności „Błąd”, jest technicznie nieprawidłowe. Dokument nie przechodzi dalej.

Konsekwencje prawne tej architektury są bezpośrednie: za poprawność techniczną i dokładność treści w równym stopniu odpowiada oferent. Doskonale sporządzone ujawnienie prawne w niewłaściwej strukturze nie zostanie przyjęte. Plik poprawny pod względem struktury, ale zawierający wprowadzające w błąd treści, również nie zostanie przyjęty; po prostu nie przejdzie na innym etapie i będzie miało inne konsekwencje.

Projekty oferujące tokeny w wielu państwach członkowskich UE napotykają dodatkową przeszkodę. Każda wersja językowa białej księgi wymaga osobnego pliku o odrębnej strukturze. Wszystkie wersje językowe muszą być wewnętrznie spójne i nie mogą być jedynie przetłumaczone, ale muszą mieć identyczną organizację na poziomie pól. Tłumaczenie, które nie odzwierciedla struktury oryginału, jest technicznie niezgodne z wymogami, niezależnie od jego poprawności językowej.

Ujawnianie informacji dotyczących zrównoważonego rozwoju stanowi dodatkowe ograniczenie. Taksonomia nakazuje stosowanie określonych jednostek miary dla zużycia energii i emisji CO2: odpowiednio kWh i tCO2. Są to prawne wymogi dotyczące ujawniania informacji, a nie opcjonalne raportowanie środowiskowe. Zgłoszenie z użyciem innych jednostek lub pominięcie pól powoduje niepowodzenie walidacji.

Wszystkie te wymagania mają ten sam schemat: biała księga jest dokumentem prawnym, który musi spełniać standardy egzekwowane automatycznie. Projekty, które traktują to jako ćwiczenie z pisania dokumentów, a nie proces zapewnienia zgodności z ustrukturyzowanymi wymaganiami wstępnymi i automatyczną kontrolą, napotkają te wymogi, zanim trafią do ludzkiego regulatora.

Co to oznacza w praktyce

Powszechne postrzeganie białej księgi kryptowalutowej jako narracyjnej prezentacji (tekstu napisanego raczej w celu przekonania niż ujawnienia informacji) opisuje rodzaj dokumentu, który MiCA zastąpiła czymś zupełnie innym.

Biała księga MiCA jest instrumentem prawnym o określonej treści, obowiązkowych identyfikatorach, ustrukturyzowanym formacie zaprojektowanym z myślą o automatycznej porównywalności transgranicznej oraz imiennej odpowiedzialności osobistej spoczywającej na każdym, kto ją podpisze. Przez nią przebiega brama wejściowa na europejski rynek kryptowalut. Projekty, które rozumieją ten dokument jako to, czym jest on z prawnego punktu widzenia, a nie jako to, co sugerowało to pojęcie historycznie, są tymi, które nie zostaną odrzucone podczas automatycznej kontroli.

Kluczowe wnioski:

• Biała księga nie jest dokumentem marketingowym. MiCA na nowo zdefiniowała to pojęcie. Najbliższym odpowiednikiem w tradycyjnych finansach jest prospekt emisyjny papierów wartościowych i należy traktować ją z taką samą wagą prawną.
• Trzy kategorie aktywów, trzy różne ścieżki. OTHR, ART i EMT mają różne wymagania dotyczące białej księgi i różne warunki wstępne dotyczące autoryzacji. To cechy aktywów decydują o tym, która kategoria ma zastosowanie, a nie projekt.
• Odpowiedzialność spoczywa na podmiocie składającym wniosek, ale zasady zależą od aktywów. W przypadku zdecydowanej większości tokenów (OTHR) obowiązek prawny spoczywa na oferencie lub osobie ubiegającej się o dopuszczenie do obrotu, a niekoniecznie na pierwotnym twórcy tokenu. Gdy CASP (np. operator platformy handlowej) zgadza się przygotować i opublikować białą księgę w imieniu projektu OTHR, przyjmuje na siebie istotne obowiązki regulacyjne, ale nie przejmuje w pełni odpowiedzialności. Zgodnie z art. 14 ust. 3 MiCA osoba pierwotnie ubiegająca się o dopuszczenie do obrotu pozostaje prawnie odpowiedzialna, jeśli dostarczy CASP niekompletne, nieuczciwe, niejasne lub wprowadzające w błąd informacje. Można zlecić wykonanie formalności, ale nie można całkowicie zlecić odpowiedzialności.
• W przypadku tokenów opartych na aktywach (ART) i tokenów pieniądza elektronicznego (EMT) ścisła odpowiedzialność cywilna za białą księgę nie spoczywa wyłącznie na uprawnionym emitencie jako podmiocie korporacyjnym; wyraźnie rozciąga się ona na członków jego organu administracyjnego, zarządzającego lub nadzorczego. Wszelkie próby ograniczenia lub wyłączenia tej odpowiedzialności w umowie są prawnie nieważne.
• LEI i DTI są warunkiem wstępnym. Oba identyfikatory muszą być gotowe przed rozpoczęciem przygotowywania białej księgi. Jeśli dla danego aktywa nie istnieje DTI, należy zwrócić się o jego nadanie do rejestru DTIF, zanim podjęte zostaną jakiekolwiek dalsze działania.
• Automatyczna walidacja jest pierwszym etapem kontroli. Przed weryfikacją pliku przez człowieka przeprowadzanych jest 257 kontroli istnienia i 223 kontroli wartości. Dokument, który nie spełnia wymogów na poziomie błędu, nie trafia do organu regulacyjnego.
• Wielojęzyczne zgłoszenia wiążą się z ukrytym obowiązkiem technicznym. Każda wersja językowa wymaga osobnego pliku o identycznej strukturze jak oryginał. Tłumaczenie, które nie odpowiada strukturze źródłowej na poziomie pól, jest niezgodne z wymogami.
• Dokładność treści i poprawność techniczna to dwa odrębne obowiązki. Pierwszy z nich obejmuje weryfikację prawną. Drugi dotyczy struktury technicznej. Oba spoczywają na oferencie i żaden z nich nie zastępuje drugiego.

Niniejszy artykuł opiera się na badaniu przeprowadzonym przez LegalBison w kwietniu 2026 r. Treść ma charakter wyłącznie informacyjny i nie stanowi porady prawnej.