Wybór standardu tokena był kiedyś tylko technicznym przypisem – czymś, o czym Twój developer Solidity decydował pierwszego dnia, a potem nikt już do tego nie wracał. To się zmieniło, gdy MiCA uczyniła egzekwowanie wymogów compliance wymogiem projektowym, a nie dodatkiem po stronie backendu.
Standard, który wybierzesz teraz, determinuje, jak udowadniasz compliance regulatorom, jak Twoje tokeny współpracują z portfelami i giełdami oraz czy możesz emitować instrumenty wieloklasowe bez wdrażania osobnych kontraktów.
Ten przewodnik opisuje ERC-1400 i ERC-3643 z perspektywy buildera – co każdy standard faktycznie robi na poziomie kontraktu, gdzie się pokrywają i jak wymogi MiCA wpływają na wybór każdego z nich. Oparty na platformach, które dostarczyliśmy dla instytucjonalnych emitentów w Europie, Kanadzie i Nowej Zelandii.
Dlaczego ta decyzja ma większe znaczenie w 2026
Przed MiCA wybór między ERC-1400 a ERC-3643 był głównie kwestią preferencji. Oba działały. Oba mogły być compliant. Logika compliance i tak żyła po stronie backendu, a regulatorzy nie zdefiniowali jeszcze, co w praktyce oznacza „udowodnione egzekwowanie”.
MiCA zmieniła zasady gry. Trzy wymogi w szczególności wpływają na wybór standardu tokena:
Egzekwowanie restrykcji transferu (Tytuł II/V): Regulatorzy oczekują od emitentów wykazania, że restrykcje są faktycznie egzekwowane, a nie tylko obiecane w whitepaperze. Standard egzekwujący compliance on-chain zapewnia silniejszy dowód niż taki, który opiera się na sprawdzeniach backendowych.
Przechowywanie rekordów (Artykuł 68): Pięć lat rejestrów transakcji z pełną identyfikowalnością, włącznie z wynikami weryfikacji compliance dla każdego transferu. Jeśli weryfikacje compliance zachodzą off-chain, potrzebujesz osobnego systemu audytowego do ich logowania. Jeśli zachodzą on-chain, blockchain JEST Twoim śladem audytowym.
Obowiązki CASP (Tytuł V): Dostawcy usług kryptoaktywów muszą utrzymywać ślady audytowe, które regulatorzy mogą niezależnie zweryfikować. Compliance on-chain jest z natury niezależnie weryfikowalny. Compliance realizowany w backendzie wymaga udostępnienia serwerów audytorom.
Nic z tego nie oznacza, że ERC-1400 jest nieużywalny pod MiCA. Oznacza jednak, że ciężar dowodu jest inny, a to wpływa na Twoją architekturę, koszty audytu i profil ryzyka regulacyjnego.
ERC-1400: Security tokeny z partycjami
ERC-1400 został zaproponowany przez Polymath, Securitize i innych w odpowiedzi na specyficzne potrzeby emisji security tokenów. Jego cechą definiującą są partycje – możliwość podziału jednego kontraktu tokenowego na podzbiory z różnymi regułami.
Jak działa
Token ERC-1400 może zawierać wiele partycji w ramach jednego kontraktu. Partycje to etykietowane „pojemniki”: udziały Serii A, udziały Serii B, transze vestingowe albo tokeny ograniczone vs. nieograniczone. Każda partycja może mieć własne reguły transferu, a inwestorzy mogą posiadać tokeny w wielu partycjach.
Transfery są walidowane przy użyciu mechanizmu autoryzacji off-chain. Zanim transfer zostanie wykonany, system sprawdza, czy nadawca ma prawo do transferu z danej partycji i czy odbiorca jest uprawniony do otrzymania tokenów. Ta walidacja typowo zachodzi w backendzie: system compliance generuje sygnaturę, którą kontrakt akceptuje.
Standard zawiera również system zarządzania dokumentami, czyli on-chainowe referencje do dokumentów prawnych (prospekt, term sheet, umowy inwestorskie) powiązanych z tokenem.
Co ERC-1400 robi dobrze
Instrumenty wieloklasowe. Jeśli tokenizujesz fundusz z wieloma klasami udziałów albo emitujesz obligacje zamienne obok equity, system partycji ERC-1400 obsługuje to natywnie w jednym kontrakcie. Bez partycji wdrażałbyś osobne kontrakty dla każdej klasy, co tworzy problemy z rekoncyliacją i podnosi koszty wdrożenia.
Produkty strukturyzowane. Harmonogramy vestingu, okresy lock-up i stopniowe uwalnianie tokenów naturalnie pasują do logiki opartej na partycjach.
Śledzenie dokumentów. Wbudowane zarządzanie dokumentami daje on-chainowy punkt odniesienia dla dokumentacji prawnej.
Gdzie ERC-1400 nie wystarczy
Compliance zależny od backendu. Walidacja oparta na autoryzacji off-chain oznacza, że sprawdzenia compliance zachodzą przed zapisaniem transakcji on-chain. Powstaje luka czasowa: status KYC inwestora może zmienić się między sprawdzeniem w backendzie a wykonaniem on-chain. Pod MiCA ta luka to ryzyko regulacyjne, które trzeba udokumentować i ograniczyć.
Częściowa kompatybilność z ERC-20. System partycji dodaje złożoność, która osłabia kompatybilność ze standardowymi portfelami i kontraktami DEX. Niektóre portfele nie wyświetlą poprawnie sald partycji. Niektóre giełdy nie obsłużą transferów uwzględniających partycje.
Wyższe koszty gazu. Logika partycji, referencje do dokumentów i dodatkowe wymagania storage’owe sprawiają, że transfery ERC-1400 są droższe niż ERC-3643 lub podstawowe transfery ERC-20.
ERC-3643 (T-REX): Compliance wbudowany w token
ERC-3643, opracowany przez Tokeny i oficjalnie włączony (merged) do głównego repozytorium Ethereum na GitHubie, podchodzi do problemu fundamentalnie inaczej. Zamiast walidować transfery off-chain, buduje logikę compliance bezpośrednio w smart kontrakcie, używając on-chainowego frameworku tożsamości ONCHAINID.
Jak działa
Każdy token ERC-3643 ma zestaw walidatorów compliance osadzonych w kontrakcie. Przed każdym transferem kontrakt automatycznie sprawdza, czy zarówno nadawca, jak i odbiorca mają wymagane zweryfikowane claimy – status KYC, akredytację, kwalifikowalność jurysdykcyjną, limity posiadania – wszystko on-chain.
Claimy są wystawiane przez zaufanych wystawców (Twój dostawca KYC, regulator, kancelaria) i przechowywane w ONCHAINID inwestora – osobnym smart kontrakcie pełniącym funkcję zdecentralizowanej tożsamości. Kontrakt tokenu sprawdza ONCHAINID, a nie bazę danych backendu.
Sprawdzenie compliance i transfer zachodzą w tej samej transakcji. Albo oba się udają, albo oba kończą się niepowodzeniem. Nie ma luki między „czy ten inwestor jest kwalifikowany?” a „czy transfer się wykonał?”.
Co ERC-3643 robi dobrze
Egzekwowanie compliance on-chain. Najsilniejszy argument za ERC-3643 pod MiCA. Gdy regulator pyta „jak egzekwujecie restrykcje transferu?”, możesz wskazać sam blockchain. Sprawdzenie compliance jest niezmienne, opatrzone timestampem i niezależnie weryfikowalne.
Pełna kompatybilność z ERC-20. Mimo dodanej logiki compliance, tokeny ERC-3643 zachowują się jak standardowe tokeny ERC-20 dla każdego portfela lub giełdy obsługującej ERC-20. Salda wyświetlają się poprawnie. Transfery działają przez standardowe interfejsy.
Optymalizacja gazu. Kontrintuicyjnie, ERC-3643 jest bardziej efektywny gazowo niż ERC-1400 dla standardowych transferów. Sprawdzenia compliance dodają narzut, ale brak logiki partycji i zoptymalizowany model storage utrzymują niższe koszty całkowite.
Elastyczność międzyjurysdykcyjna. Ponieważ reguły compliance są modularne (każda reguła to osobny kontrakt walidatora), możesz komponować zestawy reguł specyficzne dla jurysdykcji bez modyfikowania samego tokenu.
Gdzie ERC-3643 nie wystarczy
Brak natywnych partycji. Jeśli potrzebujesz instrumentów wieloklasowych (Serie A/B, różne prawa per transza), ERC-3643 nie ma wbudowanego rozwiązania. Potrzebujesz osobnych kontraktów dla każdej klasy albo dodatkowej warstwy partycjonowania.
Brak natywnego zarządzania dokumentami. W przeciwieństwie do ERC-1400, nie ma wbudowanego mechanizmu linkowania dokumentów prawnych do tokenu on-chain.
Overhead infrastruktury tożsamości. ONCHAINID wymaga konfiguracji wystawców claimów, zarządzania cyklem życia claimów (wygaśnięcie, wycofanie) i zapewnienia, że Twój dostawca KYC potrafi wystawiać claimy on-chain.
Porównanie bezpośrednie
Ramka decyzyjna: kiedy którego użyć
To nie jest sytuacja „jeden jest lepszy”. Właściwy standard zależy od Twojego modelu aktywów, środowiska regulacyjnego i priorytetów operacyjnych.
Wybierz ERC-1400 gdy:
Twój model aktywów wymaga partycji. Equity wieloklasowe, instrumenty zamienne, transze vestingowe – jeśli różni posiadacze tokenów mają strukturalnie różne prawa w ramach jednej emisji, system partycji ERC-1400 to najczystsze rozwiązanie.
Operujesz w jurysdykcji z mniej restrykcyjnymi wymogami compliance. Jeśli Twój regulator akceptuje dokumentację compliance realizowaną w backendzie, dodatkowa złożoność tożsamości on-chain może być nieuzasadniona.
Potrzebujesz on-chainowych referencji do dokumentów. Jeśli utrzymanie weryfikowalnego linku między tokenem a ramami prawnymi on-chain jest ważne, zarządzanie dokumentami w ERC-1400 to natywna funkcja.
Wybierz ERC-3643 gdy:
Budujesz pod MiCA lub podobnie rygorystycznymi regulacjami. Egzekwowanie compliance on-chain to najsilniejszy techniczny dowód egzekwowania restrykcji transferu. Wymogi MiCA z Artykułu 68 dotyczące przechowywania rekordów są w praktyce spełniane natywnie.
Potrzebujesz compliance międzyjurysdykcyjnego. Modularny system walidatorów pozwala egzekwować różne reguły dla różnych jurysdykcji inwestorów bez modyfikacji kontraktu.
Dostęp do rynku wtórnego ma znaczenie. Pełna kompatybilność z ERC-20 oznacza łatwiejszą integrację z DEX-ami i standardowymi portfelami.
Chcesz niższe długoterminowe koszty audytu. Compliance on-chain tworzy samodokumentujący się ślad audytowy.
Rozważ podejście hybrydowe gdy:
Potrzebujesz zarówno partycji, JAK I compliance on-chain. Użyj ERC-1400 dla struktury tokenu i nałóż walidację tożsamości w stylu ERC-3643. To najbardziej złożone podejście, ale daje to, co najlepsze z obu światów.
Budujesz platformę obsługującą wielu emitentów z różnymi potrzebami. Budowaliśmy wszystkie trzy konfiguracje. Podejście hybrydowe jest częstsze, niż mogłoby się wydawać — około 40% regulowanych platform, które dostarczyliśmy, używa jakiejś formy połączonej architektury.
Co zmienia MiCA Faza 2 (2026)
Druga faza implementacji MiCA, nabierająca pełnej mocy w 2026, dodaje wymogi, które jeszcze bardziej przechylają decyzję w stronę compliance on-chain:
Obowiązkowe ślady audytowe compliance. CASP muszą utrzymywać pięć lat rejestrów wykazujących, że każdy transfer został sprawdzony pod kątem compliance. W ERC-3643 dzieje się to automatycznie. W ERC-1400 musisz zbudować i utrzymywać osobny system logowania.
Dostęp nadzorczy. Regulatorzy mogą żądać dostępu w czasie rzeczywistym do danych compliance. Dane on-chain są dostępne domyślnie. Dane compliance w backendzie wymagają dostępu API, uptime’u serwera i standaryzacji formatu danych.
Paszport transgraniczny. MiCA pozwala na paszportowanie autoryzacji CASP z jednego państwa UE na całą Unię. To oznacza, że Twój framework compliance musi obsługiwać 27 jurysdykcji. Modularny system walidatorów ERC-3643 jest do tego zaprojektowany.
Praktyczne uwagi z wdrożeń produkcyjnych
Kilka rzeczy, których nauczyliśmy się, budując z oboma standardami, a których nie znajdziesz w dokumentacji specyfikacji:
Onboarding wystawcy claimów to bottleneck dla ERC-3643. Uruchomienie wystawiania claimów ONCHAINID przez dostawcę KYC (Sumsub, Onfido, Veriff) wymaga pracy integracyjnej. Zaplanuj 2–4 tygodnie.
Nazewnictwo partycji ERC-1400 ma znaczenie. To, jak nazywasz i strukturyzujesz partycje, ma długoterminowe implikacje. Zmiana struktury partycji po emisji jest możliwa, ale bolesna.
Oba standardy obsługują upgradeowalne proxy. Nie jesteś na zawsze zamknięty w początkowej logice kontraktu. Ale: upgrade logiki compliance w produkcji wymaga starannego governance’u.
Koszty gazu stają się nieistotne na L2. Jeśli wdrażasz na Polygon, Base lub Arbitrum (co robi większość nowych platform tokenizacyjnych), różnica kosztów gazu między ERC-1400 a ERC-3643 jest pomijalna.
FAQ
Czy mogę przejść z ERC-1400 na ERC-3643 po uruchomieniu?
Technicznie tak, ale wymaga to migracji pozycji wszystkich posiadaczy tokenów do nowych kontraktów. To jest disruptive i kosztowne. Lepiej wybrać właściwy standard z góry. Jeśli nie jesteś pewien, podejście hybrydowe daje największą elastyczność.
Czy ERC-3643 wymaga, żeby każdy inwestor miał tożsamość on-chain?
Tak, każdy portfel posiadający tokeny ERC-3643 musi mieć powiązany ONCHAINID z wymaganymi zweryfikowanymi claimami. W praktyce jest to obsługiwane podczas onboardingu inwestora.
Jakiego standardu używa Securitize / Tokeny / Polymath?
Tokeny opracowali ERC-3643 i używają go wyłącznie. Securitize pierwotnie wspierali ERC-1400, ale przeszli na DS Protocol. Polymath przeszedł na Polymesh (osobny chain). W praktyce wybór dotyczy mniej standardu konkretnego vendora, a bardziej modelu compliance pasującego do Twojego środowiska regulacyjnego.
Czy CMTAT (standard szwajcarski) jest realną alternatywą?
CMTAT jest rozwijany przez Swiss Capital Markets and Technology Association i zyskuje popularność w Szwajcarii. Jest lżejszy od obu standardów, zaprojektowany specyficznie pod szwajcarskie prawo papierów wartościowych. Dla platform wielojurysdykcyjnych modularny system compliance ERC-3643 jest bardziej elastyczny.
Następne kroki
Jeśli budujesz platformę tokenizacyjną i oceniasz standardy tokenów:
→ Przeczytaj: Platforma Tokenizacyjna White-Label – Budować, Kupić czy Dostosować? – pełny przewodnik architektoniczny po platformach tokenizacyjnych w 2026.
→ Zobacz nasze case studies – jak wdrożyliśmy oba standardy w produkcji dla Alior Banku, SOIL i innych instytucjonalnych emitentów.
→ Umów call architektoniczny – 30 minut na zmapowanie Twojego modelu aktywów i rekomendację właściwego standardu.
Powiązane artykuły:
- Platforma Tokenizacyjna White-Label w 2026: Budować, Kupić czy Dostosować? (artykuł pillar)
- MiCA Faza 2: Techniczny checklist dla platform tokenizacyjnych (wkrótce)
