Open402 (Stablecoin Conference de Bitso)

Problem

Los agentes de IA ya pueden escribir código, tomar decisiones y gestionar tareas complejas. Lo único que no pueden hacer solos es pagar.

El protocolo x402 — estandarizado por la Linux Foundation en 2026 con el respaldo de Visa, Mastercard, Google, AWS y Stripe — resolvió el problema técnico del pago HTTP nativo. Pero generó nuevos problemas sin respuesta:

¿Cómo gestiona un agente su liquidez sin intervención humana en cada transacción?
¿Quién define qué puede gastar y cuánto?
¿Cómo paga un agente servicios que aún no hablan x402 — CFE, Telmex, Telcel?
¿Cómo hace todo esto un usuario en LATAM que nunca ha tocado una wallet?

Todas las soluciones existentes apuntaban al mismo perfil: el usuario que ya tiene una wallet, entiende gas fees y vive en dólares. Ese no es el usuario de LATAM. Y esa brecha es donde vive la oportunidad.

Solution

open402 es la infraestructura financiera que permite a agentes de IA operar en la economía real de LATAM — sin que el usuario toque una wallet, una llave privada ni un exchange.

El modelo es directo: el usuario compra créditos vía SPEI, y su agente los quema ejecutando acciones reales. Toda la complejidad de blockchain, wallets y stablecoins ocurre en el backend.

Lo que el agente puede hacer

Pagar servicios mexicanos: CFE, Telmex, Telcel, Izzi y +400 proveedores vía Prontipagos
Invertir en CETES: cotización → orden → CLABE para depósito SPEI → confirmación vía webhook (Etherfuse)
Consumir APIs con protocolo x402: pago HTTP nativo desde una Agentic Wallet en Arbitrum
Leer recibos físicos: OCR con GPT-4o Vision para extraer servicio, referencia y monto sin que el usuario escriba nada

Todo desde Telegram. Sin fricción.

El modelo de créditos

Los créditos son la capa de abstracción entre el usuario y la blockchain:

Usuario → MXN (SPEI) → Bitso FXaaS → MXNB/MXM (Arbitrum)
                                              │
                                  Créditos internos (1 crédito = $0.01 MXN)
                                              │
                     Agente ejecuta → deduce créditos → registro → settlement on-chain

El usuario no interactúa con crypto en ningún momento. La conversión SPEI → stablecoin es asíncrona y transparente.

Policy Engine

Antes de ejecutar cualquier pago, el agente valida un conjunto de reglas definidas por el usuario:

Límite máximo de monto por servicio
Umbral de confirmación obligatoria (ej. montos > $500 MXN requieren aprobación en Telegram)
Programación recurrente: mensual, semanal o puntual
Whitelist de servicios permitidos por agente

Ningún pago se ejecuta sin persistirse primero en base de datos. Las reglas son bloqueantes, no sugerencias.

Technical Approach

Arquitectura general

Usuario
  ├── Dashboard Web (Next.js 14) ──► API Routes ──► PostgreSQL (Prisma)
  └── Telegram Bot (grammy + GPT-4o)
              │
              ├── GPT-4o Vision → OCR de recibos
              ├── Function calling (9 tools)
              └── execute_payment
                      │
                      ├── x402 Client → Agentic Wallet (Arbitrum) → API x402
                      └── Prontipagos → Servicios MX (CFE, Telmex, Telcel, Izzi)

Monorepo structure

open402/
├── apps/
│   ├── web/               # Dashboard (Next.js 14, App Router)
│   │   ├── dashboard/
│   │   ├── agents/
│   │   ├── credits/
│   │   ├── rules/
│   │   ├── transactions/
│   │   └── api/etherfuse/
│   └── bot/               # Bot de Telegram
│       └── src/index.ts   # GPT-4o + function calling
│
└── packages/
    ├── db/                # Prisma schema + cliente
    ├── agent/             # Agente con AgentKit
    ├── agentkit/          # Action providers custom
    ├── sdk/               # @open402/agents (SDK público)
    └── api/               # Lógica compartida

Bot de Telegram — 9 tools de function calling

El bot usa GPT-4o-mini para entender intención y GPT-4o Vision para OCR. El modelo decide autónomamente qué tool invocar:

| Tool | Descripción | |---|---| | get_balance | Saldo de créditos del usuario | | list_agents | Agentes activos | | get_agent_detail | Reglas, wallet y últimas transacciones | | create_agent | Crear agente con wallet en Arbitrum | | create_rule | Configurar regla de gasto | | get_transactions | Historial de transacciones | | execute_payment | Validar reglas, deducir créditos, ejecutar pago | | invest_in_cetes | Generar orden Etherfuse + CLABE SPEI | | check_investment | Consultar estado de inversión por orderId |

Protocolo x402 en Arbitrum

1. Agente hace request HTTP a API protegida
2. API responde HTTP 402 (Payment Required)
3. Agente firma transferencia MXM desde su Agentic Wallet (Coinbase CDP / MPC)
4. Transacción se envía a Arbitrum One
5. Agente reintenta la request con proof de pago

Las wallets se crean con Coinbase Developer Platform usando arquitectura MPC — las llaves privadas nunca se exponen, ni al equipo del producto.

Canales de pago

| Canal | Qué paga | Mecanismo | |---|---|---| | x402 | APIs (OpenAI, CoinGecko, Perplexity…) | HTTP 402 → MXM en Arbitrum | | Prontipagos | CFE, Telmex, Telcel, Izzi (+400 servicios) | API REST con créditos internos | | Etherfuse | CETES (stablebonds tokenizados) | Orden → CLABE → webhook |

Flujo Etherfuse / CETES

Usuario: "Invertir $500 en CETES"
        ↓
Bot genera cotización (tasa nominal, fees)
        ↓
Usuario confirma → Orden creada → CLABE generada
        ↓
Usuario transfiere MXN vía SPEI al CLABE
        ↓
Etherfuse recibe depósito → ejecuta compra de stablebond
        ↓
Webhook actualiza estado en DB (completed + cetesReceived)
        ↓
Bot notifica al usuario con confirmación

On-ramp fiat — Bitso FXaaS

Usuario genera orden en dashboard
        ↓
Recibe CLABE + referencia SPEI
        ↓
Transfiere MXN → Bitso convierte MXN → MXNB
        ↓
MXNB se deposita en pool wallet de open402 (Arbitrum)
        ↓
Créditos acreditados al usuario en DB

Results

🥉 3er lugar — track General & Startup de Arbitrum en la Stablecoin Conference de Bitso 2026 (50 proyectos participantes)
💰 Pool Prize — track de Etherfuse por la integración de inversión en CETES
Demostración funcional del loop completo: SPEI → créditos → pago de servicio real → notificación en Telegram
Validación del protocolo x402 sobre Arbitrum con Agentic Wallets MPC
Integración end-to-end con Etherfuse en entorno sandbox

Tech Stack

Frontend & Auth

Next.js 14 (App Router) + Tailwind CSS
Clerk — autenticación (email, Google, GitHub) + webhooks Svix para sincronización con PostgreSQL

Backend & Database

PostgreSQL + Prisma ORM
TypeScript en todo el proyecto (monorepo pnpm workspaces)
BullMQ + Upstash Redis para jobs programados y reintentos

Bot & AI

grammy — framework del bot de Telegram
GPT-4o — function calling para interpretación de intención
GPT-4o Vision — OCR de recibos físicos

Blockchain & Payments

Arbitrum One / Arbitrum Sepolia — red principal
Coinbase CDP AgentKit — Agentic Wallets con arquitectura MPC
x402 SDK (@coinbase/x402) — protocolo de pagos HTTP nativo
MXM / MXNB — stablecoins mexicanas en Arbitrum

Integrations

Bitso FXaaS — on-ramp SPEI → MXN → MXNB
Prontipagos — pagos de servicios mexicanos (400+ proveedores)
Etherfuse — inversión en CETES (stablebonds tokenizados)

Infrastructure

Vercel — deploy del dashboard web
Railway — deploy del bot de Telegram

Key Takeaways

La experiencia de construir open402 para un hackathon dejó lecciones concretas:

El problema más difícil no fue técnico. Abstraer la blockchain del usuario — que el flujo se sintiera como cualquier app de pagos — requirió más decisiones de producto que de ingeniería. El modelo de créditos (compra con SPEI, gasta sin tocar crypto) fue la decisión de diseño más importante del proyecto.

El Policy Engine es lo que hace confiable al agente. Sin reglas bloqueantes, ninguna empresa ni usuario serio va a dejar que un agente gaste dinero de forma autónoma. La confianza en la autonomía se construye con controles granulares, no con promesas.

LATAM es un mercado sin atender en la economía de agentes. Todos los proyectos del ecosistema x402 apuntan a usuarios que ya viven en crypto. Integrar SPEI, Prontipagos y CETES no fue un detalle de localización — fue la propuesta de valor central.

El SDK público (@open402/agents) cambia el tipo de proyecto. Pasar de un producto a infraestructura que otros pueden usar encima fue una decisión consciente desde el inicio. La separación en packages (agent, agentkit, sdk) lo hizo posible sin reescribir el core.

Presentado en la Stablecoin Conference — Bitso Business, Ciudad de México, junio 2026.