KYC w DeFi czy dowód bez ujawniania danych
Pierwszy krok to zrozumienie, że MiCA nie wymaga, aby każdy smart kontrakt znał twoje imię i nazwisko. Wymaga, aby dostawca usług kryptoaktywowych (CASPs) przeprowadził należytą weryfikację klienta. Jeśli korzystasz z niepowierniczego portfela i protokołu, który nie jest CASP, formalnie nie ma kto tej weryfikacji wymagać. Problem pojawia się przechowywanie w małym mieszkaniu momencie, gdy wchodzisz w interakcję z podmiotem regulowanym — giełdą, brokerem, kantorem.
Zanim cokolwiek wdrożysz, sprawdź trzy rzeczy: czy dokument z KSeF ma numer identyfikujący go w łańcuchu, kto odpowiada za zgodność danych między systemem a kontraktem oraz co się stanie, gdy dłużnik nie zapłaci. Bez odpowiedzi na te pytania tokenizacja należności będzie tylko technologiczną ciekawostką, a nie narzędziem do zarządzania płynnością.
Krajowy System e-Faktur daje ustrukturyzowany dokument XML z pełnym zestawem danych: NIP, kwoty netto i VAT, daty, pozycje. Ten sam plik można potraktować nie tylko jako obowiązek księgowy, ale jako nośnik wartości. Warunek jest jeden: dane muszą być podpisane i niezmienne, a do tego potrzebny jest rejestr, który potwierdzi ich pochodzenie. Blockchain sprawdza się tu lepiej niż zwykła baza, bo pozwala przypisać fakturze unikalny identyfikator i historię zdarzeń bez centralnego administratora.
Escrow na blockchainie działa jak rachunek powierniczy, ale z automatyką. Kupujący blokuje środki w kontrakcie, a warunkiem ich zwolnienia jest potwierdzenie dostawy lub upływ terminu z KSeF. Jeśli dokument zostanie zmieniony korektą, kontrakt odczytuje nowy status i odpowiednio dzieli środki. To eliminuje ręczne uzgadnianie, ale wymaga zaufanego źródła danych. Sam KSeF nim nie jest, więc potrzebny jest oracle lub podpisany komunikat z systemu ERP, który potwierdzi zgodność stanu dokumentu ze stanem kontraktu.
Praktyczna implementacja zaczyna się od prostego testu na kartce: wypisz, kto ma dziś prawo wykonać daną operację, a potem kto ma prawo zmienić to prawo. Dopiero potem pisz kod. Typowy błąd polega na tym, że zespół przenosi do kontraktu dokładnie ten sam schemat, który miał wcześniej, i dodaje tylko ładniejszy interfejs. Efekt jest taki, że podpisy nadal muszą być zebrane w jednej transakcji, a wszystkie zalety elastyczności pozostają niewykorzystane.
Praktyka wygląda inaczej niż w prezentacjach. Najczęstszy błąd to tokenizacja faktury bez weryfikacji, czy dłużnik istnieje i czy dokument nie został już sfinansowany. Drugi błąd to pominięcie korekt i faktur zaliczkowych, które zmieniają kwotę. Kontrakt musi przewidzieć anulowanie, częściową zapłatę oraz sytuację, gdy dłużnik spłaca tylko część. Bez tego token reprezentuje roszczenie, którego nikt nie wyegzekwuje.
Drugi częsty problem to kolejność i ważność podpisów. Gdy podpisy pochodzą z różnych źródeł i odnoszą się do różnych akcji, łatwo o powtórzenie tego samego podpisu, o zbyt długie okno ważności albo o sytuację, w której dwa podpisy blokują się nawzajem. Warto od początku wprowadzić licznik operacji lub identyfikator zgody, który jednoznacznie wiąże podpis z zamiarem. Bez tego nawet poprawny próg staje się podatny na odtworzenie zgody w innym kontekście.
MiCA nie zniknie, ale nie musi oznaczać oddania pełnej dokumentacji przy każdej transakcji. Klucz to świadome rozdzielenie: jeden wiarygodny wystawca poświadczeń, wiele miejsc, w których udowadniasz tylko uprawnienie. Taka architektura spełnia wymogi regulacyjne i ogranicza ekspozycję danych do minimum.
Limity muszą być egzekwowane w UserOp, nie w UI Limit dzienny i limit na pojedynczą operację to nie parametr wyświetlany użytkownikowi, lecz warunek walidacji w funkcji validateUserOp. Zaimplementuj licznik przesuwany w oknie czasowym, z resetem po upływie okresu, a nie licznik globalny zerowany ręcznie. Uważaj na wyścigi: dwie równoległe UserOpy mogą przejść walidację, zanim pierwsza zaktualizuje stan. Rozwiązaniem jest aktualizacja licznika przed wykonaniem zewnętrznego wywołania i odrzucanie operacji, których suma przekracza próg. Kolejny częsty błąd: limit liczony w natywnej monecie, podczas gdy portfel obsługuje wiele tokenów. Ustal, czy limit obowiązuje per aktyw, czy łącznie, i zapisz to jawnie w specyfikacji.
Jak to wdrożyć. Zacznij od jednego kroku: sprawdź, czy twój portfel ma opcję wysyłki przez prywatny kanał, i włącz ją dla transakcji, które i tak są pilne. Potem przetestuj intencję na małej kwocie, porównując wynik z klasyczną transakcją. Nie zmieniaj wszystkiego naraz – najpierw sprawdź, czy wykonanie faktycznie wypada lepiej, i dopiero wtedy przenieś tam stały ruch. Detaliczny nie zniknie z MEV, ale przestanie płacić za samą widoczność swojej transakcji.
Tokenizacja należności bez fikcji Tokenizacja faktury nie polega na zamianie dokumentu w kryptowalutę. Chodzi o wyodrębnienie prawa do zapłaty i zapisanie go jako tokenu powiązanego z konkretnym dokumentem z KSeF. Najprostszy model to token reprezentujący roszczenie o zapłatę z terminem wymagalności. Wystawca faktury rejestruje hash dokumentu w kontrakcie, określa kwotę i datę, a następnie emituje token. Nabywca tokenu płaci wystawcy od razu, a w terminie wymagalności odbiera należność od dłużnika. To faktoring w wersji programowalnej, bez pośredników, którzy po drodze zmieniają warunki.