L402 auditado: el HTTP 402 original se convierte en payment method

Cinco años antes de que existiera x402, Lightning Labs ya tenía un HTTP 402 funcionando. Lo auditamos el 2026-08-18: la spec, el rastro de estandarización y el proxy que la implementa. El protocolo funciona. El papeleo nunca ocurrió. Y la implementación de referencia hoy habla también el scheme de pago de otro.

Casi toda la conversación sobre pagos agénticos de los últimos dieciocho meses asume que el HTTP 402 estuvo dormido hasta que las stablecoins lo despertaron. No fue así. L402, antes llamado LSAT, corre en producción desde 2019 detrás de Lightning Loop, y el repositorio que guarda su especificación se creó el 2020-02-07. Resolvía el mismo problema que resuelve x402: cómo un servidor cobra por request a un cliente anónimo sin cuentas, sin API keys y sin registro fuera de banda.

El diseño es lo bastante distinto como para estudiarlo en sus propios términos, y su trayectoria en 2026 es lo más interesante de todo. Así que clonamos el repo de la spec, el proxy de referencia y el repositorio de bLIPs de Lightning, bajamos los registros de IANA y el datatracker del IETF, y leímos lo que realmente hay.

Qué especifica L402

La especificación del protocolo son 402 líneas de Markdown con formato de RFC. El núcleo son dos headers.

// Challenge: servidor a cliente, con HTTP 402
WWW-Authenticate: L402 macaroon="<base64>", invoice="<bolt11>"

// Credencial: cliente a servidor, en el reintento
Authorization: L402 <base64(macaroon)>:<hex(preimage)>

Ambos parámetros del challenge son REQUIRED. El macaroon MUST comprometerse al payment hash de la factura BOLT 11 dentro de su identificador. Ese compromiso es todo el truco: el servidor verifica el pago comprobando H == sha256(r) contra el hash que él mismo incrustó, donde r es el preimage que el cliente obtuvo al pagar. Sin consulta a base de datos, sin llamada al nodo Lightning, sin facilitator. La spec llama a esto el camino RECOMMENDED y es la razón por la que L402 escala horizontalmente: cualquier réplica que tenga la root key del macaroon puede verificar cualquier credencial.

El identificador del macaroon son 66 bytes en big-endian: versión de 2 bytes (hoy 0), el payment hash de 32 bytes y un token ID aleatorio de 32 bytes que sobrevive a la rotación del macaroon e identifica al comprador entre credenciales. Los caveats son strings clave-valor que se agregan a la cadena HMAC, y cada caveat nuevo solo puede restringir: services=name:tier, <service>_capabilities=cap1,cap2 y restricciones por capacidad.

Los status codes son más estrictos de lo que suele verse. El 402 se usa exclusivamente para el challenge inicial. Una vez que el cliente presenta una credencial, válida o no, el servidor MUST responder 401 si la verificación falla, nunca otro 402. Esa sola regla permite distinguir "no pagaste" de "tu credencial está rota" sin parsear un body.

Dos detalles delatan la edad del protocolo, y para bien. gRPC tiene su propio flujo, porque gRPC exige HTTP 200 en toda respuesta: el challenge viaja en un trailer grpc-status-details-bin con Grpc-Status: 402. Y la Section 10 obliga a emitir ambos nombres de scheme por compatibilidad, LSAT primero. El proxy de referencia hace exactamente eso, con un comentario que explica que los clientes viejos de Loop solo miran el primer header WWW-Authenticate.

El rastro de estandarización está vacío

A L402 se lo describe siempre como bLIP-26, "Status: Active". Lo verificamos. El pull request #26 de lightning/blips, titulado "blip-0026: L402 - Lightning HTTP 402 Protocol", lo abrió Olaoluwa Osuntokun el 2023-06-07. Al 2026-08-18 sigue abierto: un commit, 650 líneas agregadas, 13 comentarios, 91 comentarios de review, última actividad 2026-03-11, estado de merge limpio. El listado raíz del repositorio tiene desde blip-0001 hasta blip-0055 con huecos; blip-0026.md no está entre ellos.

Del lado de IANA pasa lo mismo. El registro de HTTP Authentication Schemes que bajamos el 2026-08-18 lista catorce schemes: Basic, Bearer, Concealed, Digest, DPoP, GNAP, HOBA, Mutual, Negotiate, OAuth, PrivateToken, SCRAM-SHA-1, SCRAM-SHA-256 y vapid. L402 no es uno de ellos. Payment, el scheme del que hablamos más abajo, tampoco. La frase de la propia spec, "The L402 scheme is registered under the HTTP Authentication Framework specified in RFC 7235", se lee mejor como "definido dentro de ese framework"; no hay entrada de registro detrás.

No es fatal. Los bearer tokens movieron la web durante años antes del RFC 6750, y un proxy que corre vale más que una fila en un registro. Pero importa para quien decide qué implementar, porque significa que no hay superficie de conformance entre vendors: ni nombre de scheme registrado, ni documento adoptado por un working group, ni autoridad de test vectors fuera de la propia implementación.

Cómo se ve el repositorio hoy

El repo de la spec tiene 90 stars, 19 forks y 11 issues abiertas, sin archivo de licencia, y su último push fue el 2026-06-09. Se reestructuró en marzo de 2026: los commits del 2026-03-11 y 2026-03-20 partieron el monolito en protocol-specification.md, un macaroon-spec.md de 533 líneas y algo que no habíamos visto en ningún otro repo de protocolo.

agent-spec.md tiene 88 líneas y el README lo describe como "el protocolo completo en ~560 tokens para integración por agentes de IA". Es una especificación compilada para una ventana de contexto: headers, flujo, tabla del identificador, gramática de caveats y un checklist de implementación de nueve pasos, sin una sola frase explicativa. Se piense lo que se piense del protocolo, ese archivo es buena idea. Una spec que un agente puede sostener entera en contexto mientras escribe un cliente es un canal de distribución, y la mayoría de los repos de protocolo de este espacio todavía obligan a leer cuarenta páginas de prosa para encontrar el nombre de un header.

Donde se nota la edad es en el ecosistema de clientes. El README lista dos librerías, lsat-js y boltwall, ambas de Tierion. Sus últimos pushes fueron el 2023-08-09 y el 2023-04-26. Ninguna está archivada; ninguna se movió en tres años.

Aperture no está quieto

Aperture, el reverse proxy que termina L402, es otra película: licencia MIT, 268 stars, 77 forks, 58 issues abiertas, 607 commits totales de los cuales 180 cayeron solo en 2026, head del 2026-08-13. Tres de sus directorios no existían hace un año.

Vale la pena leer el diseño de metering completo, porque es el tratamiento más honesto del billing de LLMs que encontramos en un codebase de pagos. Los bundles se reservan al acuñar el challenge, no al pagarlo, y una reserva impaga expira a los diez minutos. Las reservas usan el max_tokens del propio request cuando existe y un estimatedtokens configurable con default 4.096 cuando no, para que diez requests concurrentes no sean admitidos todos contra los mismos últimos mil tokens. Aperture captura una cola acotada de 16 KiB del body de la respuesta, se la entrega al price server y debita el uso real ponderado por dirección, redondeando hacia arriba para que los satoshis descontados siempre cubran los satoshis servidos. En respuestas en streaming recorre las líneas data: buscando el último chunk con usage, cae a hacer brace-matching sobre una cola truncada y quita el Accept-Encoding del cliente para que la cola sea legible. Cuando no hay usage parseable, el request se liquida al estimado y no a cero.

Es el mismo problema que trabajamos en el scheme upto de x402, resuelto con otro primitivo: un balance prepago que se drena off-chain en vez de una autorización con tope on-chain que se captura por el monto real.

El tercer directorio es la noticia

El paquete agregado el 2026-03-19 se llama mpp, y sus constantes nombran sus fuentes sin rodeos:

// AuthScheme is the HTTP authentication scheme name for the Payment
// protocol as defined in draft-httpauth-payment-00.
AuthScheme = "Payment"

MethodLightning = "lightning"
IntentCharge    = "charge"   // draft-lightning-charge-00
IntentSession   = "session"  // draft-lightning-session-00

Eso es el Machine Payments Protocol, el esfuerzo de Stripe y Tempo que auditamos desde la spec el 2026-08-10. Lightning Labs lo implementó dentro de Aperture, como par de su propio protocolo. Con enablempp: true, una sola respuesta 402 lleva hoy tres ofertas: un challenge LSAT, un challenge L402 y un challenge Payment. El campo de configuración se llama literalmente authscheme y acepta "l402", "mpp" o "l402+mpp".

La ingeniería debajo de esa frase es cuidadosa. La oferta charge de Payment acuña su propia factura, distinta de la de L402, así que cada 402 reserva dos bundles al mismo precio y la reserva hermana que nadie paga expira sola. La clave de metering cambia según la puerta: L402 usa el token ID aleatorio del identificador del macaroon, mientras que el intent charge usa el payment hash, porque el preimage que presenta el comprador hashea exactamente a la clave del bundle, de modo que prueba de pago y clave de lookup son los mismos 32 bytes. Aperture también documenta dónde rompe a propósito la spec Payment: un charge es de un solo uso por default, pero en un servicio con metering un charge consumido dejaría varado el bundle que el comprador pagó, así que las credenciales charge siguen siendo presentables y lo que las retira es el balance agotado. El registro de consumo se escribe igual en el primer uso.

Las sessions son la tercera puerta, detrás de enablesessions. Un depósito abre la sesión, tarifado por default en veinte unidades de servicio, los requests bearer descuentan contra él con un idle timeout de cinco minutos, y el remanente se reembolsa al cerrar. Aperture guarda el balance; al price server se lo consulta dos veces por request, QuoteSession antes y SettleSession después. Los errores de las tres puertas vuelven como documentos RFC 9457 bajo https://paymentauth.org/problems/, con un subárbol específico de Lightning para preimages inválidos, facturas expiradas, sesiones cerradas y return invoices mal formadas.

Quién es dueño del método Lightning

Acá la auditoría encuentra algo que los anuncios no dicen. Consultamos el datatracker del IETF el 2026-08-18. draft-httpauth-payment-00 existe: "The Payment HTTP Authentication Scheme", 33 páginas, presentado el 2026-06-19, con vencimiento 2026-12-21, archivado como individual submission sin working group, precedido por draft-ryan-httpauth-payment-01 del 2026-03-18.

Los documentos que Aperture cita para el comportamiento Lightning, draft-lightning-charge-00 y draft-lightning-session-00, no están en el datatracker. Viven en tempoxyz/mpp-specs, el repositorio de Tempo, bajo specs/methods/lightning/. Lightning es una de diez familias de payment methods ahí, junto a card, evm, hedera, nearintents, solana, stellar, stripe, tempo y usdc. Ni los drafts de intents ni la extensión de discovery están en el datatracker; la propia referencia normativa del draft de Lightning charge apunta a datatracker.ietf.org/doc/draft-payment-intent-charge/, que devuelve 404.

Y los autores del método Lightning no son Lightning Labs. El front matter de draft-lightning-charge-00.md nombra a Kevin Zhang, Jeremy Klein y Zhen Lu, los tres de Lightspark. El archivo está en el repositorio desde su commit inicial del 2026-01-05.

Leamos la secuencia sin adornos. Lightning Labs inventó el 402 que funciona y nunca mergeó su propio bLIP. Otra empresa escribió Lightning como payment method dentro de un scheme que vive en otro repositorio. Y Lightning Labs implementó ese scheme en su proxy ocho días después de publicar un post sobre por qué L402 está hecho a medida para agentes. El protocolo que era todo el producto se está convirtiendo en un identificador de método entre diez.

L402 contra x402, mecánicamente

Los dos protocolos responden con 402 y un challenge, y los dos permiten pagar y reintentar. Todo lo demás difiere.

La prueba de L402 es un preimage: poseerlo demuestra que una factura fue pagada, y la verificación es un SHA-256. La prueba de x402 es una autorización de transferencia firmada que el facilitator verifica y liquida on-chain, algo que recorrimos en la auditoría del facilitator. L402 denomina en milisatoshis y hereda el modelo de custodia de Lightning: para vender hay que correr un nodo con liquidez entrante; para comprar hay que mantener canales fondeados. x402 denomina en stablecoins y hereda el de la cadena: para vender basta una dirección; para comprar hace falta balance y gas, o una transferencia sin gas al estilo EIP-3009.

La credencial de L402 es reusable y atenuable. Quien la tiene puede agregar caveats para restringir un macaroon antes de pasárselo a un sub-agente, y el servidor verifica esa restricción sin que nadie se lo avise. x402 no tiene un primitivo de delegación equivalente en el protocolo base; el scoping lo hace la política de la wallet del pagador, que es exactamente el trade-off que mapeamos en bearer contra walk-up. Del otro lado, x402 v2, publicado el 2026-06-24, trajo discovery, identidad basada en wallet y soporte multi-chain alineado a CAIP dentro del estándar, con una fundación y un repositorio de spec detrás. L402 tiene un proxy, un repo de spec y dos librerías cliente que no se tocan desde 2023.

La diferencia menos glamorosa es contable. La liquidación en stablecoins produce un registro on-chain que cualquier auditor puede reconstruir. La liquidación en Lightning produce un preimage y una actualización privada de canal. Para un consumidor que paga un artículo, eso es una función de privacidad. Para una empresa que debe conciliar el gasto de sus agentes contra facturas, es trabajo que alguien tiene que hacer off-chain.

Qué significa para LLM4Agents

Nosotros liquidamos en stablecoins sobre x402 y EIP-3009, y nada de esta auditoría cambia eso. La custodia en Lightning es un negocio operativo, y nuestros compradores son agentes que tienen USDC, no operadores de canales.

Tres cosas sí entran en nuestro roadmap.

Primero, el modelo de metering. El diseño de bundles de Aperture es lo más parecido que vimos a cómo factura de verdad un gateway de inferencia: cotizar al emitir el challenge, reservar un estimado al admitir, debitar el usage parseado al completar, redondear hacia arriba y liquidar los streams al estimado cuando la cola es ilegible. Esos son exactamente los casos borde que nuestro loop reserve-proxy-settle tiene que sobrevivir, y describimos nuestra versión en el post de internals del billing. Su decisión de reservar el bundle al acuñar el 402 y no al cobrarlo, dejando expirar las reservas impagas a los diez minutos, es un orden más limpio que reservar al pagar.

Segundo, la señal de convergencia. Dos linajes independientes del 402, el de Lightning y el de las stablecoins, están siendo empujados hacia el mismo scheme genérico Payment con identificadores de método debajo. Si ese scheme llega a un working group y a un registro IANA, la pregunta interesante deja de ser "x402 o L402" y pasa a ser "qué métodos acepta tu gateway". Un gateway que habla un scheme con varios métodos es mejor forma que un gateway que habla varios schemes.

Tercero, la amenaza. Si el agente de un comprador puede pagar un endpoint tarifado en Lightning y otro tarifado en stablecoins con el mismo vocabulario de headers, el diferencial sube en el stack: routing, fallback, recibos, controles de gasto, identidad. Esa es la capa donde competimos igual. Pero implica que ser agnóstico de scheme en el borde ya no es opcional.

Cómo mantenerse en la frontera

Concretamente, en orden.

Uno: implementar un parser del scheme Payment del lado comprador antes de necesitarlo. Aperture demuestra que el scheme ya lo emiten servidores reales, y la superficie de parseo es chica: parámetros de challenge ligados por un HMAC que el cliente devuelve textualmente, base64url con decodificación estricta, documentos RFC 9457 al fallar. Un agente que sale de nuestro gateway debería poder satisfacer un challenge Payment con el método usdc o evm aunque internamente liquidemos x402.

Dos: adoptar el patrón de spec comprimida. Deberíamos publicar un agent-spec.md de nuestra superficie de pago y routing, en unos cientos de tokens, para que un agente de código integre sin bajar la documentación completa. Es barato y reduce directamente el costo de que alguien nos elija.

Tres: seguir el bLIP-26 y draft-httpauth-payment como riesgo de protocolo, no como curiosidad. El draft vence el 2026-12-21. Que se refresque, que lo adopte un working group o que lo reemplacen nos dice cuánto converge la capa 402 en 2027. Hay que vigilar una llamada de adopción en un working group y el primer pedido de registro IANA en http-authschemes.

Cuatro: llevar los casos borde de metering a nuestros propios tests de conformance. Colas de stream truncadas, objetos de usage ausentes, reservas concurrentes contra un balance casi agotado y reconciliación estimado contra real son las fallas que regalan inferencia en silencio. Aperture ya las escribió; nosotros deberíamos poder demostrar que manejamos cada una.

Cinco: seguir denominando en stablecoins y ser honestos sobre por qué. No porque Lightning sea peor en micropagos, es medible que es mejor en montos muy chicos, sino porque nuestros compradores tienen dólares, nuestros vendedores facturan en dólares y el rastro de conciliación es el producto. El día que eso deje de ser cierto, la auditoría de arriba es por dónde empezaríamos.