És gener de 1997. El (Internet Engineering Task Force) acaba de publicar Definir oficialment L'especificació va ser creada per pioners web , , , , i Els arquitectes que van modelar com es comunica Internet. IETF RGPD 2068 HTTP/1.1 El Roy Fielding Jim Gettys Jeffrey Mogul Enric Freixà Tim Berners-Lee IETF RGPD 2068 El Roy Fielding Jim Gettys Jeffrey Mogul Enric Freixà Tim Berners-Lee L’especificació introdueix : anteriorment, cada sol·licitud HTTP requeria una nova connexió TCP. Les connexions persistents resolen això, permetent que múltiples sol·licituds HTTP flueixin a través d'una sola connexió TCP de llarga durada. persistent connections També hi ha , una nova manera per als servidors web de transmetre contingut sense conèixer prèviament la mida completa. ja no necessita calcular la mida total del contingut generat dinàmicament per endavant, ara és lliure per lliurar dades incrementalment, ja que es produeix. chunked transfer encoding però Un nou codi d’estat: RFC 2068 quietly introduces something intriguing HTTP 402 Payment Required This code is reserved for future use. Això mostra com els pares fundadors de la World Wide Web van predir com els diners es convertirien finalment en una gran part d'Internet. . even if they had no clear path on how it would actually play out Avui, 2025, gairebé tres dècades i múltiples versions HTTP després ( El 2015, El 2022 Malgrat la revolució de les fintech, l'augment dels pagaments en línia i una economia sencera basada en les transaccions d'Internet, ningú no havia pensat què fer amb això. HTTP/2 HTTP/3 Status Code 402 still sits there with the exact same note: 'reserved for future use.' Until now. El mes passat (Maig de 2025), alliberat , an open source protocol that gives El seu primer treball real: habilitar els nadius Pagament de sol·licituds HTTP. Coinbase x402 HTTP 402 onchain Actualment, els agents han de (Màquina a màquina) pagaments a través de la web amb reducció Intervencions (human-in-the-loop), però els fluxos de pagament tradicionals no funcionen bé en aquest cas. Requereixen múltiples interaccions humanes, redireccions i passos manuals que simplement no funcionen quan un agent d'IA necessita fer una transacció de forma autònoma. M2M HITL Proposa un flux de pagaments automatitzat en cadena implementat nativament dins del protocol HTTP, . x402 making them as seamless as any other web request Però com es veu això en la pràctica? Arquitectura i components de x402 El 402 Està construït al voltant de quatre components bàsics: x402 El a actua com a iniciador de pagament, descobrint el que es requereix per accedir i construir la càrrega de pagament adequada. En poques paraules, això és el que està fent la sol·licitud HTTP a un recurs de paret de pagament. Podria ser un navegador fent una sol·licitud de contingut premium, un agent de compra d'API d'AI o una aplicació mòbil desbloquejant característiques. El client gestiona la signatura criptogràfica utilitzant la clau privada de l'usuari i retira automàticament les sol·licituds quan es requereix el pagament. client El Implementa les polítiques de pagament per als seus punts finals mentre es manté centrat en la seva lògica empresarial bàsica. Aquest és el servidor web o l'API que allotja el contingut o el servei que es compra. Manté taules de preus simples que mapen els punts finals als costos, però delega la lògica de verificació de pagament al facilitador. resource server La lògica blockchain s'implementa en la Component: Verificació de signatures criptogràfiques, prevenció d'atacs de repetició a través del rastreig noce, i gestió de la liquidació real en cadena. permet als clients i servidors treballar amb pagaments en cadena sense entendre els detalls de la implementació de la blockchain. facilitator És resideix la capa final de liquidació, assegurant que els pagaments són immutables i transparents.Permet diners programables a través de contractes intel·ligents i monedes estables, . blockchain but its complexity is completely hidden from the application layer by the facilitator : Client Responsabilitat principal: Iniciació del pagament Característiques clau:EIP-712 signatura, retries automàtiques, descobriment de pagaments Què fa: realitza sol·licituds, gestiona carteres, retires amb pagament : Resource Server Responsabilitat principal: Execució de pagaments Característiques clau: taules de preus, respostes HTTP 402, integració de middleware Què fa: Estableix preus, comprova pagaments, serveix contingut : Facilitator Responsabilitat principal: Verificació de pagaments Característiques clau: Verificació de signatura, rastreig de noces, abstracció de gasos Què fa: Verifica les signatures, parla amb blockchain : Blockchain Responsabilitat principal: liquidació de pagaments Característiques clau: transferències USDDC, contractes intel·ligents, registres immutables Què fa: liquida els pagaments a la cadena Principis Aquesta arquitectura demostra diversos principis fonamentals de l'enginyeria de programari. Cada component té una responsabilitat única i ben definida. . separation of concerns Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction El sistema aconsegueix Els components només interactuen a través d'interfícies HTTP i REST estandarditzades. Aquest aïllament significa que podeu intercanviar components (per exemple, utilitzar una blockchain diferent, canviar proveïdors de facilitadors o modificar la lògica del servidor) sense afectar la resta del sistema. loose coupling A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementation El facilitador incorpora el aïllant tota la complexitat de la blockchain en un servei especialitzat. Això impedeix que la lògica de pagament s'escapi a les aplicacions empresarials i manté les preocupacions adequadament separades. single responsibility principle Finalment, però no menys important, aquesta arquitectura Els components d'alt nivell depenen d'abstraccions en lloc d'implementacions concretes. Els servidors i els clients depenen d'interfícies HTTP, no d'API específiques de blockchain. Això permet que el mateix codi d'aplicació funcioni a través de diferents blockchains i esquemes de pagament sense modificació. dependency inversion Flux de pagament Quan un agent o un usuari de l'IA colpeja un -enabled API, aquí està el flux de quatre passos que passa: x402 Sol·licitud inicial: El client fa una sol·licitud HTTP estàndard per accedir a algun recurs Si no s'afegeix cap pagament, el servidor respon amb HTTP 402 i inclou les dades de pagament Autorització de pagament: El client crea un pagament signat criptogràficament i retorna la sol·licitud : The server validates the payment, broadcasts it to the blockchain, and grants access Verification and access El que fa que això sigui potent és que tot passa al nivell del protocol HTTP. No redirigeix a processadors de pagaments de tercers, no flows, no account creation. OAuth Just standard HTTP with extra headers: X-PAYMENT flueix de client a servidor i conté la càrrega de pagament signada. Això inclou els detalls de pagament (import, destinatari, token) més una signatura criptogràfica que demostra que el client ha autoritzat el pagament. X-PAYMENT-RESPONSE flueix del servidor al client després d'un pagament reeixit i conté informació de recepció de transaccions, proporcionant transparència sobre el que va succeir en la cadena. El Implementació de servidors Arquitectura de middleware La implementació del servidor central gira al voltant d'un filtre de pagament (AKA middleware) que intercepta les sol·licituds HTTP i imposa els requisits de pagament. Quan s'integra al vostre servidor web, aquest middleware controla les sol·licituds entrants contra una taula de preus que mapes els terminis als seus costos. El producte mitjà segueix un simple arbre de decisió: si una sol·licitud arriba a un punt final protegit sense pagament, respon amb i instruccions de pagament detallades. Si el pagament està inclòs en el Header, verifica el pagament amb un servei de facilitador abans de permetre que la sol·licitud procedeixi. HTTP 402 X-PAYMENT Aquí teniu l'estructura essencial de la implementació de Java: public class PaymentFilter implements Filter { private final String payTo; private final Map<String, BigInteger> priceTable; // path → amount private final FacilitatorClient facilitator; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String path = req.getRequestURI(); String paymentHeader = req.getHeader("X-PAYMENT"); if (!priceTable.containsKey(path)) { chain.doFilter(request, response); // Free endpoint return; } if (paymentHeader == null) { send402Response(resp, path); // Request payment return; } // Verify payment, process request, then settle VerificationResponse verification = facilitator.verify(paymentHeader, requirements); if (verification.valid) { chain.doFilter(request, response); facilitator.settle(paymentHeader, requirements); } } } Simplement afegir el filtre de pagament a la pila de productes mitjans i definir quins punts finals requereixen pagament. The beauty of this approach is that it requires minimal changes to existing applications. Resposta PaymentRequirements Quan un client arriba a un punt final protegit sense pagament, el servidor construeix un objecte de requisits de pagament detallat. ), l'adreça de cartera de recepció, la xarxa blockchain i un temps d'expiració per evitar atacs de replay. USDC private void send402Response(HttpServletResponse response, String path) throws IOException { response.setStatus(HttpStatus.PAYMENT_REQUIRED); response.setContentType("application/json"); PaymentRequirements requirements = PaymentRequirements.builder() .paymentRequirement(List.of( PaymentRequirement.builder() .kind(new Kind("exact", "base-sepolia")) // Payment scheme + blockchain network .receiver(payTo) // Wallet address to receive payment .amount(priceTable.get(path)) // Cost for this specific endpoint .asset("<USDC_TOKEN_CONTRACT>") // USDC token contract .expiry(Instant.now().plus(Duration.ofMinutes(5))) // Payment window .nonce(UUID.randomUUID().toString()) // One-time use identifier .build() )) .build(); response.getWriter().write(Json.MAPPER.writeValueAsString(requirements)); } Cada un dels camps de la Es descriu de la següent manera: PaymentRequirements tipus: Defineix l'esquema de pagament (exacte per a quantitats fixes) i la xarxa de blockchain de destinació (base-sepolia per Base testnet). Això diu al client exactament com estructurar i executar el pagament. receptor: L'adreça de cartera on s'ha d'enviar el pagament. Aquesta és la cartera de la seva empresa que rebrà els fons. quantitat: El cost d'accés a aquest punt final específic, obtingut de la taula de preus. Per USDC, això s'expressa normalment en wei (unitat més petita). actiu: L'adreça de contracte intel·ligent del token que s'utilitza per al pagament. L'exemple mostra USDC a Base Sepolia testnet. expiració: un timestamp després del qual aquest requisit de pagament esdevé nul. Això impedeix que es reutilitzin les velles sol·licituds de pagament i afegeix seguretat contra atacs de replay. Un identificador únic (UUID) que garanteix cada requisit de pagament només es pot complir una vegada, fins i tot si el mateix client fa múltiples sol·licituds al mateix punt final. Implementació client Processament automàtic de pagaments Les biblioteques de clients embolcallen clients HTTP estàndard per processar automàticament les respostes 402.Quan un client rep una sol·licitud de pagament, (1) construeix una càrrega útil de pagament, (2) la signa amb la clau privada de l'usuari i (3) retorna la sol·licitud original amb el pagament adjunt. public HttpResponse<String> makeRequest(String url, String method) throws Exception { HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .build(); HttpResponse<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString()); // Handle 402 Payment Required if (response.statusCode() == 402) { PaymentRequirements requirements = Json.MAPPER.readValue( response.body(), PaymentRequirements.class); // Create payment payload matching the requirements PaymentPayload payment = PaymentPayload.builder() .receiver(requirements.getPaymentRequirement().get(0).getReceiver()) .amount(requirements.getPaymentRequirement().get(0).getAmount()) .asset(requirements.getPaymentRequirement().get(0).getAsset()) .nonce(requirements.getPaymentRequirement().get(0).getNonce()) .expiry(requirements.getPaymentRequirement().get(0).getExpiry()) .build(); // Sign using EIP-712 structured data signing String signature = signer.sign(payment.toSigningMap()); // Retry with payment header String paymentHeader = encodePaymentHeader(payment, signature); HttpRequest paidRequest = HttpRequest.newBuilder() .uri(URI.create(url)) .method(method, HttpRequest.BodyPublishers.noBody()) .header("X-PAYMENT", paymentHeader) .build(); return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString()); } return response; } El procés de signatura utilitza el estàndard, que crea una representació estructurada, llegible per l'home de les dades de pagament abans d'haxar-les i signar-les. Això garanteix que el pagament sigui criptogràficament segur i vinculat a la petició específica. EIP-712 Verificació de flux de pagament Facilitar la integració El servei de facilitador és on viu la complexitat de la blockchain, abstractant-la de clients i servidors.Quan un servidor rep un pagament, remet la càrrega de pagament al facilitador per a la verificació. public class HttpFacilitatorClient implements FacilitatorClient { private final HttpClient http; private final String baseUrl; @Override public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) throws Exception { // Construct verification request with payment and requirements VerifyRequest body = VerifyRequest.builder() .paymentHeader(paymentHeader) // The X-PAYMENT header from client .requirements(requirements) // What the server expects .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/verify")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, VerificationResponse.class); } @Override public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) throws Exception { // Settlement happens after successful verification SettleRequest body = SettleRequest.builder() .paymentHeader(paymentHeader) .requirements(requirements) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(baseUrl + "/settle")) .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body))) .header("Content-Type", "application/json") .build(); String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body(); return Json.MAPPER.readValue(json, SettlementResponse.class); } } The facilitator checks several things: És vàlida la signatura? La quantitat de pagament es correspon amb els requisits? Ha estat utilitzat aquest pagament abans? El pagament encara està dins de la finestra d'expiració? Si la verificació passa, el facilitador també gestiona el règim mitjançant la transmissió de la transacció a la blockchain de la seva elecció. La interfície defineix el contracte que qualsevol client facilitador ha d'implementar: FacilitatorClient public interface FacilitatorClient { VerificationResponse verify(String paymentHeader, PaymentRequirements requirements); SettlementResponse settle(String paymentHeader, PaymentRequirements requirements); } La seva aplicació ha de proporcionar una implementació concreta d'aquesta interfície. Exemple d’integració Ara que hem vist els components individuals (filtres de pagament, integració de facilitadors i maneig del client), anem a veure com aquestes peces es reuneixen en una aplicació real. Exemple que demostra el flux complet. Spring Boot En primer lloc, crear una Anàlisi : @PaymentRequired @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface PaymentRequired { String price(); String currency() default "USDC"; String network() default "base-sepolia"; } Després es modifiquen els per escanejar per aquestes anotacions a l'inici: PaymentFilter @Component public class PaymentFilter implements Filter { private final Map<String, BigInteger> priceTable; private final String payTo; private final FacilitatorClient facilitator; public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) { this.payTo = payTo; this.facilitator = facilitator; this.priceTable = buildPriceTableFromAnnotations(context); } private Map<String, BigInteger> buildPriceTableFromAnnotations(ApplicationContext context) { Map<String, BigInteger> prices = new HashMap<>(); // Scan all @RestController beans for @PaymentRequired annotations Map<String, Object> controllers = context.getBeansWithAnnotation(RestController.class); for (Object controller : controllers.values()) { Method[] methods = controller.getClass().getMethods(); for (Method method : methods) { PaymentRequired payment = method.getAnnotation(PaymentRequired.class); if (payment != null) { String path = extractPathFromMapping(method); BigInteger amount = new BigInteger(payment.price().replace(".", "")); prices.put(path, amount); } } } return prices; } } Ara podeu anotar directament els mètodes del controlador: @RestController public class WeatherController { @GetMapping("/weather") @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia") public WeatherData getWeather(@RequestParam String city) { // Your existing business logic return weatherService.getWeatherForCity(city); } @GetMapping("/premium-forecast") @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia") public ExtendedForecast getPremiumForecast(@RequestParam String city) { return weatherService.getExtendedForecast(city); } } @Configuration public class PaymentConfig { @Bean public PaymentFilter paymentFilter(ApplicationContext context) { return new PaymentFilter( context, "<WALLET_ADDRESS>", // Your wallet address new HttpFacilitatorClient("<FACILITATOR_URL>") ); } @Bean public FilterRegistrationBean<PaymentFilter> paymentFilterRegistration(PaymentFilter filter) { FilterRegistrationBean<PaymentFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(filter); registration.addUrlPatterns("/*"); registration.setOrder(1); return registration; } } El l’anotament gestiona la configuració de preus declarativament, mentre que el descobreix automàticament aquestes anotacions a l'inici i construeix la taula de preus. La lògica de negoci existent en els mètodes del controlador es manté completament inalterada. La configuració ho connecta tot registrant el filtre de pagament i connectant-lo a un servei de facilitador. cost 0,001 USDC i cost 0,01 USDC, amb tot el processament de pagament es produeix de manera transparent a la capa HTTP. @PaymentRequired PaymentFilter /weather /premium-forecast Consideracions de seguretat i producció és simple i elegant, amaga la complexitat. Això és un pro i un con. Facilita la integració, però també amaga un aspecte important: . x402 putting AI agents in charge of money creates new attack vectors Mentre que Les signatures i la gestió de nocions tracten els atacs de repetició, què passa quan un agent es veu compromès?La detecció tradicional de fraus es basa en patrons de comportament humans, però Un agent compromès podria esborrar fons més ràpid que qualsevol estafador humà. EIP-712 AI agents don't follow human spending habits El component facilitador es converteix en un altre objectiu d'alt valor ja que verifica signatures i gestiona nocions. . blockchain settlements are final Des de es basa en les transaccions en cadena, hereta els riscos operatius de les transaccions de blockchain. Les tarifes del gas fluctuen molt, de vegades fent que els micropagaments siguin econòmicament incòmodes. La congestió de la xarxa pot retardar les transaccions. Què ha de fer un agent d'IA quan necessita dades en temps real però el pagament està atrapat en un mempool? x402 Un altre aspecte important és la regulació. El compliment varia entre jurisdiccions amb diferents regles sobre els pagaments automatitzats, l'ús de criptomonedes i la retenció de dades.Un agent d'IA que realitza un gran volum de microtransaccions a través de les fronteres podria desencadenar alertes AML o violar les regulacions locals sense que ningú s'adoni. Què és el següent Què és interessant sobre Els agents d'IA necessiten capacitats de pagament autònoms, els stablecoins proporcionen una capa de diners programable, i la infraestructura de blockchain ha madurat prou per gestionar aplicacions escalables. Aquestes peces no s'han alineat abans. Internet ara necessita una nova forma de pagaments, i els fluxos tradicionals no es van construir per a agents autònoms o micropagaments. x402 és convincent gràcies al seu enfocament pragmàtic. En comptes de reinventar els pagaments des de zero, amplia la infraestructura HTTP existent. En comptes de requerir noves integracions, funciona amb patrons estàndard que ja entenem. x402 Els reptes de seguretat i operatius són reals, però són problemes d'enginyeria amb possibles solucions. Després de gairebé tres dècades, Finalment podria fer el que estava dissenyat per fer: fer que pagar per les coses a Internet sigui tan simple com sol·licitar-les. HTTP 402 The foundation is set. Now it's time to build. Gràcies de l’Eric Reppel, de Ronnie Caspers, , Joan Leffew Danny Organ, i tot l'equip de Coinbase per a l’obertura d’aquest protocol. Erik Reppel Rony Caspers Joan Leffew Danny Organ Coinbase . Gràcies Erik Reppel i Yuga Cohler Per a la revisió Les meves contribucions Dues x402 Erik Reppel Yuga Cohler Les meves contribucions Recursos i més lectura HTTP 402 Pagament requerit - RFC 2068 - Especificació HTTP original de 1997 Especificació del protocol x402 - Documentació oficial del protocol x402 GitHub Repository - Implementació de codi obert de Coinbase x402 implementació de Java - El PR que va introduir la implementació de Java del protocol EIP-712: Ethereum Typeed Structured Data Hashing and Signing - estàndard de signatura utilitzat en x402 Documentació de la xarxa base - Plataforma blockchain de la capa 2 utilitzada en exemples Documentació USDC - Detalls del contracte de l'USD Coin Stablecoin Spring Boot Filter Documentation - Implementació de middleware de Java Java HTTP Client API - Gestió d'HTTP al costat del client Normes de comunicació màquina a màquina (M2M) - Comunicació de sistemes autònoms Arquitectures autònomes d'agents d'IA - Recerca sobre patrons de disseny d'agents d'IA Google Approach to Secure AI Agents: les propostes de Google d'un marc d'agents d'IA segur i guiat per l'home
