Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 6: La Puerta 402 ⚡
Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 6: La Puerta 402 ⚡
Un agente que solo sabe cobrar es una alcancía con modales. Para que chigu sea autónomo de verdad tiene que poder pagar, pedir un recurso, encontrarse una puerta cerrada que dice “402, paga primero”, y cruzarla solo. Construí el MCP para que lo hiciera. Después descubrí que medio internet del L402 público está caído.
De dónde venía
La fase 1 cerró con chigu recibiendo su primer sat real. Sabía cobrar. Pero cobrar es la mitad fácil: alguien te paga y listo. La mitad difícil y la que define si un agente es autónomo o es un chatbot con wallet, es pagar: que el agente, por su cuenta, decida que necesita algo, se tope con un muro de pago y lo resuelva sin pedirme permiso.
Eso es exactamente lo que estandariza L402.
Qué es L402, en una línea
HTTP tiene desde siempre un código de estado reservado que casi nadie usó: 402 Payment Required. Estaba ahí, vacío, esperando una forma de pago nativa de internet. L402 lo llena con Lightning: pides un recurso, el servidor te responde 402 y un invoice, pagas, y vuelves a pedir el recurso con la prueba de pago. La puerta se abre.
El flujo completo el “dance”, son cuatro pasos:
1. probe → pido el recurso
2. 402 → el servidor responde "paga primero" + invoice
3. pay → pago el invoice por Lightning
4. fetch → vuelvo a pedir, ahora con la prueba → 200 OK
Para chigu, esto es la llave de un mundo entero: APIs de pago, datos, cómputo, todo cobrable por sat, sin tarjeta, sin cuenta, sin pedirle permiso a nadie.
El MCP propio
Decidí no usar una librería ajena de caja negra para algo tan central. Escribí un MCP, un servidor de herramientas que el agente puede invocar, dedicado a L402. Tres tools, una por cada parte que importa del dance:
| Tool | Qué hace |
|---|---|
probe |
toca el recurso y reporta si pide pago (y cuánto) |
pay |
paga el invoice del 402 |
fetch |
trae el recurso ya pagado |
Más un recurso payer://info para que el agente pueda preguntar con qué wallet está pagando antes de gastar.
La pieza de diseño que más cuidé fue el payer intercambiable. El que paga de verdad es un componente enchufable: hoy corre un MockPayer que simula pagos para las pruebas, y dejé dos enchufes reales documentados pero todavía sin implementar, uno por cada wallet candidata. Cuando llegue el momento de gastar sats de verdad, escribo el adapter y el resto del código ni se entera. Es el mismo patrón de capas modulares que vengo usando desde la fase 1: lo estable separado de lo que cambia.
El resultado: ~430 líneas de código, 35 de 35 tests en verde, y seis decisiones de diseño anotadas en el camino.
La capa que vive fuera del LLM
Hay una defensa nueva en este paso que vale la pena explicar, porque es la lección de Freysa aplicada, ese experimento donde un agente con fondos fue convencido por puro texto de regalar el dinero que debía proteger.
El tope de gasto del payer está hard-coded en su constructor. No vive en el prompt, no es un parámetro que el agente pueda leer ni negociar, no hay forma de hablarle a chigu para que lo suba. Está cocido en el código que paga, una capa por debajo de donde el LLM puede llegar. Aunque alguien jailbreakee al agente y lo convenza de pagar un millón de sats, el payer corta en el tope y punto.
La regla que sigo: el cap de gasto nunca vive donde el LLM puede leerlo. Si está en el prompt, no es un límite, es una sugerencia.
Medio internet del L402 está caído
Llegó el momento de probar el dance completo contra un servidor L402 real y me estrellé con algo que no esperaba: los endpoints públicos de L402 están caídos. Probé los tres que tenía en la lista, los servicios de referencia que todo el mundo cita en los tutoriales, y los tres estaban muertos o no respondían el 402.
Es un dato incómodo sobre el estado del ecosistema: L402 es una idea preciosa con muy poca infraestructura viva detrás. Para un builder es señal de oportunidad tanto como de fricción.
La salida fue de manual: me armé mi propio servidor L402 mínimo como fixture de prueba, unas pocas decenas de líneas con la librería estándar, sin dependencias. Y contra ese servidor el dance corrió entero: probe → 402, pay con el MockPayer por 10 sats, fetch → 200. El recurso bajó. La puerta se abrió. La mecánica funciona; lo que falta es un internet que la use.
Dónde va a vivir la wallet de gasto
Cobrar lo hago con un custodio y una API key de permisos mínimos, alcanza para recibir. Pero pagar de verdad necesita una wallet con capacidad de envío, y ahí no quiero un custodio: quiero que chigu pague desde un nodo Lightning propio.
La decisión que cerré en este paso: la wallet de gasto va a correr sobre el nodo Lightning Network, gestionada por un hub que expone Lightning a aplicaciones de forma controlada, con tope de presupuesto. No un servicio nuevo en otra máquina, no la nube. La conexión entre el agente y esa wallet será por un canal acotado: el agente puede pedir pagos hasta un límite, nada más.
Hay un solo bloqueo: ese nodo todavía está sincronizando la cadena entera desde el bloque cero. Hasta que termine, la wallet real espera. Por eso este paso se quedó con el MockPayer, el cableado está listo y probada; falta enchufar.
Qué viene en el siguiente episodio
El siguiente paso reemplaza el simulador por el payer real: chigu pagando un L402 con sats de verdad desde el nodo LN, y el MCP enchufado directo al agente en producción. El cierre natural de este arco, el primer pago saliente, el espejo exacto del primer sat que cobró en el Ep 5.
Y con sats en juego, llega por fin la prueba que vengo difiriendo: intentar jailbreakear a chigu para que pague de más, y ver si las capas aguantan.
chigu@blink.sv ·
_@chigu.techflows.work· Nostr:npub18rl9xeaxw0leee0easqu9cngrq0ny4zsmdsx4jhj5fkfmstgklhq2q5mqzSi esto te es útil, un zap es la mejor señal. Si algo está mal, corrígeme públicamente, lo agradezco más que el zap.
Write a comment