
Nie ma listy płatności x402. Żadnego rejestru, żadnej flagi na transakcji, żadnego pojedynczego kontraktu do obserwowania. Jeśli chcesz uwzględnić te płatności w produkcie analitycznym, musisz zbudować taką listę samodzielnie.
Rynek już zwraca na to uwagę. Chainalysis śledzi wzrost płatności agentowych na Base, a TRM Labs pyta, jaka ich część naprawdę pochodzi od agentów AI. Obie analizy dotyczą pomiaru rynku. Ten artykuł dotyczy drugiej strony: tego, czego wymaga samodzielne zbudowanie takiego pokrycia.
Przez ostatnie miesiące budowaliśmy tę listę na potrzeby x402 Radar. Oto jak ta praca wygląda krok po kroku.

x402 to otwarty protokół płatności, który wykorzystuje kod statusu HTTP 402, „Payment Required”, aby oprogramowanie mogło samodzielnie płacić: za wywołanie API, zbiór danych czy fragment analizy. Jest obecnie rozwijany przez x402 Foundation.
Powstał z myślą o oprogramowaniu, które płaci bez udziału człowieka, dlatego jest jednym z głównych kanałów płatności agentowych. Płatności są często bardzo małe. Na Base typowa płatność to około jednego centa.
W sieciach EVM przepływ składa się z czterech kroków:
transferWithAuthorization z EIP-3009 na USDC. Drugą drogą jest podpis Permit2.
Z tego wynikają dwie konsekwencje dla każdego, kto to indeksuje:
Transfer USDC, niekoniecznie w tx.from. Transakcję zwykle wysyła facylitator. Płacącego odczytuj z transferu, a nie z nadawcy transakcji.Facylitator x402 to usługa, która weryfikuje podpisaną przez klienta autoryzację płatności i rozlicza ją on-chain w imieniu serwera. Zwykle wysyła transakcję i płaci za gaz, więc jako tx.from widać jego adres, a nie adres płacącego.
Działa to dzięki EIP-3009: transferWithAuthorization pozwala posiadaczowi tokena podpisać transfer poza łańcuchem, a każdemu, kto ma ten podpis, wysłać go do sieci. Płacący podpisuje, facylitator nadaje.
Jeśli zdarzyło Ci się dodawać nową sieć do produktu analitycznego, większość z tego będzie brzmieć znajomo.
Brzmi to banalnie, ale takie nie jest. Istnieją co najmniej dwie rozsądne definicje:
Publiczne narzędzia śledzące liczą głównie te pierwsze. W x402 Radar liczymy te drugie, bo właśnie ten przepływ interesuje zespół compliance. Obie miary mogą opowiadać bardzo różne historie. Dlatego publiczne dane o x402 tak bardzo się różnią i dlatego każda liczba pokazywana klientom wymaga definicji obok niej.
Nawet najwięksi dostawcy analityki wyznaczają tę granicę inaczej. Chainalysis identyfikuje płatności agentowe po portfelach korzystających z protokołu x402 i naliczył znacznie ponad 100 milionów takich płatności na Base do końca I kwartału 2026 roku. TRM Labs zaczął od rozliczeń przez znanych facylitatorów, odfiltrował płatności do samego siebie, masowe przepływy od garstki płacących oraz sprzedawców z bardzo małą liczbą kupujących i oszacował, że tylko od 0,6% do 7,5% pozostałych płatności wyglądało na agentów AI.
Latem obie miary zmieniały się w naszych danych w przeciwnych kierunkach. Ten sam rynek, odwrotny trend, a różnica wynika wyłącznie z tego, co się liczy. Dlatego każda liczba wymaga definicji obok niej.
Jeśli liczysz płatności agentów, musisz najpierw wiedzieć, które adresy należą do agentów. Nie ma jednego źródła:
Każde źródło działa inaczej i obejmuje inny wycinek ekosystemu. Ich łączenie i utrzymywanie synchronizacji, gdy każdego dnia rejestrują się nowi agenci, to osobny pipeline.

Gdy masz już portfele agentów, każdy transfer USDC z ich udziałem wymaga etykiety mówiącej, jak został rozliczony:
Lista facylitatorów i ich adresów podpisujących pochodzi z publicznego wykazu i z deklaracji samych facylitatorów, a z czasem się zmienia. To także ona pozwala oddzielić płatności w pełni zgodne z x402 od pozostałych, gdy klient o to zapyta.
Dla każdej płatności zapisuj osobno co najmniej cztery adresy:
Transfer),tx.from, często facylitator),Ten ostatni wymaga danych z konkretnego momentu w czasie. Właściciele agentów się zmieniają, czasem kilka minut po ich utworzeniu, więc dzisiejszy właściciel niekoniecznie kontrolował agenta w chwili płatności.

Aktywność x402 zaczęła się wiele miesięcy temu, więc pierwszym zadaniem jest odczytanie historii: zdarzeń rejestru od początku i każdego późniejszego transferu każdego portfela agenta. Potem indeks musi trzymać się blisko czoła łańcucha, czekać na odpowiednią liczbę potwierdzeń, by być odpornym na reorganizacje, i nadrabiać zaległości, gdy dostawcy RPC ograniczają odczyty, a to się zdarza.
Oba zadania konkurują o tę samą infrastrukturę. Pogodzenie uzupełniania historii z indeksowaniem na żywo, bez luk, to mało efektowna część pracy, która decyduje o tym, czy danym można zaufać.
x402 działa w kilku sieciach. Obecnie obejmujemy Base, Ethereum i Polygon, a następna w kolejce jest Solana. Każda sieć ma własne rejestry, facylitatorów i specyfikę indeksowania, a sieci spoza EVM w ogóle nie używają EIP-3009, więc sposoby rozliczeń wyglądają w nich inaczej. Traktuj każdą nową sieć jako osobną integrację, a nie zmianę konfiguracji.
tx.from jako płacącego. Gdy po drodze jest facylitator, zwykle nim nie jest.Najwięksi gracze mają zespoły badawcze, które mogą się tym zająć. Większość dostawców analityki ich nie ma, a ich klienci i tak będą zadawać te same pytania.
Tymczasem to ta sama praca, którą wykonujemy od pięciu lat, m.in. dla Elliptic, w ponad 56 sieciach: nowe źródła, kontrola kompletności, atrybucja i stały monitoring. x402 to po prostu nowy rodzaj płacącego, do którego ją stosujemy.
x402 Radar to miejsce, w którym to wszystko połączyliśmy. Znajduje agentów w rejestrach i katalogach, śledzi ich portfele, klasyfikuje sposób rozliczenia każdej płatności oraz rozdziela płacącego, odbiorcę, wysyłającego i właściciela, w sieciach Base, Ethereum i Polygon. Możesz korzystać z niego jako ze źródła danych przez API albo możemy zbudować te same możliwości w Twoim stosie technologicznym.
x402 to otwarty protokół płatności, który wykorzystuje kod statusu HTTP 402, „Payment Required”, aby oprogramowanie mogło samodzielnie płacić za API, dane i usługi, zwykle w USDC. Jest rozwijany przez x402 Foundation i stanowi jeden z głównych kanałów płatności agentowych.
Klient prosi o płatny zasób, serwer odpowiada kodem 402 i ceną, a klient podpisuje autoryzację płatności, zwykle transferWithAuthorization z EIP-3009 na USDC. Facylitator weryfikuje ją i rozlicza on-chain, zwykle płacąc za gaz. On-chain efektem jest zwykły transfer USDC: płacący jest w zdarzeniu Transfer, a tx.from to zwykle facylitator.
To usługa, która weryfikuje podpisaną przez klienta autoryzację płatności i rozlicza ją on-chain w imieniu serwera. Zwykle wysyła transakcję i płaci za gaz, więc jako nadawca transakcji widnieje jej adres, a nie adres płacącego.
EIP-3009 to standard tokenów, zaimplementowany w USDC, który pozwala posiadaczowi autoryzować transfer podpisem poza łańcuchem. Każdy, kto ma ten podpis, może wysłać go on-chain, wywołując transferWithAuthorization. W ten sposób facylitatorzy x402 rozliczają płatności i płacą za gaz w imieniu płacącego.
Ponieważ liczą różne rzeczy. Niektóre narzędzia liczą płatności w pełni zgodne ze specyfikacją x402, inne wszystkie płatności dokonywane przez agentów AI, a szum filtrują na różne sposoby. Chainalysis naliczył znacznie ponad 100 milionów płatności agentowych na Base do końca I kwartału 2026 roku, a TRM Labs oszacował, że tylko od 0,6% do 7,5% odfiltrowanych rozliczeń x402 wyglądało na agentów AI.
x402 zaprojektowano do działania w wielu sieciach. Działa w sieciach EVM, takich jak Base, Ethereum i Polygon, a także w sieciach spoza EVM, takich jak Solana, gdzie rozliczenie wygląda inaczej, bo nie ma tam EIP-3009. x402 Radar obejmuje obecnie Base, Ethereum i Polygon.
Chcesz przejść przez cały pipeline z inżynierem, który go zbudował? Umów 20-minutowe demo x402 Radar →