Tytuł: Wyjaśnienie X402: Natywne mikropłatności HTTP dla agentów AI

Specyfikacja X402 wykorzystuje standardowy status HTTP 402 Payment Required, aby przekształcić zwykłe wywołanie API w mikropłatność on-chain. Agenci AI mogą teraz rozliczać opłaty za zapytania do LLM lub strumienie danych bez udziału człowieka, a dostawcy mogą pobierać opłaty za każde zapytanie bez konieczności budowania własnego systemu fakturowania.

Dlaczego agenci AI potrzebują protokołu płatności

Autonomiczni agenci łączą ze sobą modele językowe, narzędzia do wyszukiwania w sieci oraz zastrzeżone źródła danych. Każde takie połączenie generuje koszty – opłaty za tokeny w modelu lub opłaty za każde wywołanie API z danymi rynkowymi. Dzisiejsze modele biznesowe opierają się na kluczach API powiązanych z kontami subskrypcyjnymi, ręcznym doładowywaniu środków lub rozliczeniach następczych. Metody te naruszają obietnicę „braku udziału człowieka” w przypadku autonomicznych agentów i zwiększają koszty operacyjne dostawców.

X402 oferuje rozwiązanie pośrednie: przepływ żądanie-odpowiedź (request-response), który wygląda jak każde inne wywołanie HTTP, ale posiada wbudowany krok płatności zapisywany w publicznym blockchainie. Jedynym wymaganiem jest to, aby klient mógł podpisać i przesłać transakcję w sieci (chain) określonej przez serwer.

Szczegółowy opis procedury (handshake) X402

  1. Wstępne żądanie – Agent wysyła standardowe żądanie GET lub POST do płatnego punktu końcowego (endpoint). Nie są wymagane żadne specjalne nagłówki.
  2. Serwer odpowiada statusem 402 – Odpowiedź zawiera status 402 oraz ciało JSON, które wymienia:
    • amount – opłata, której oczekuje serwer, wyrażona w najmniejszej jednostce tokena;
    • token – adres kontraktu ERC-20 (lub odpowiednika);
    • chain – identyfikator blockchaina, na którym musi zostać zarejestrowana płatność;
    • opcjonalny nonce – unikalna wartość zapobiegająca atakom typu replay.
  3. Klient przygotowuje płatność – Agent sprawdza adres tokena i sieć (chain) pod kątem zgodności ze swoją polityką (np. tylko zaufane sieci). Następnie tworzy transakcję przekazującą wymaganą kwotę na adres podany przez serwer, podpisuje ją swoim kluczem prywatnym i przesyła do sieci.
  4. Przesłanie hasha płatności – Gdy hash transakcji jest już dostępny, klient powtarza pierwotne żądanie, dodając tym razem nagłówek X-Payment zawierający hash. Przesyłana treść (payload) pozostaje bez zmian.
  5. Serwer weryfikuje transakcję on-chain – Serwer przeszukuje blockchain w poszukiwaniu potwierdzonego przelewu, który zgadza się z kwotą, tokenem, siecią i wartością nonce. Jeśli znajdzie dopasowanie, zwraca żądane dane ze statusem 200 OK.

Każda biblioteka klienta HTTP, która obsługuje niestandardowe nagłówki i potrafi wywołać SDK blockchaina, może wykonać te kroki. Nie jest wymagany żaden nowy protokół transportowy ani niestandardowa warstwa gniazd (socket layer).

Kwestie do rozważenia (kompromisy)

  • Opóźnienia (Latency) – Potwierdzenie w publicznym blockchainie wprowadza opóźnienie.
  • Koszty gazu (Gas costs) – Nawet tanie sieci pobierają opłaty za gaz; płatności poniżej 0,001 USD mogą być nieopłacalne.
  • Złożoność – Agenci muszą radzić sobie z nieudanymi transakcjami i reorganizacjami sieci (chain reorganizations); niezbędna jest solidna logika ponawiania prób.
  • Bezpieczeństwo – Wartość nonce zapobiega atakom typu replay, ale agenci nadal muszą chronić swoje klucze prywatne i unikać ich ponownego używania w niezwiązanych ze sobą usługach.