Solicitud
Un cliente o agente solicita un recurso protegido.
Laboratorio público experimental
xolosArmy Network · Construcción pública
x402eCash
Laboratorio público de x402 sobre XEC
Exploramos el comercio nativo para máquinas sobre eCash: pagos HTTP 402, autorización Tonalli, APIs cobrables y agentes autónomos controlados por políticas.
Introducción al protocolo
¿Qué es x402?
x402 es un estándar abierto y agnóstico al transporte para pagos nativos de internet. La versión 2 separa los tipos y la lógica centrales del pago de su representación en transportes como HTTP, MCP y A2A.
Requisitos
El servidor comunica los requisitos de pago: esquema, red, monto, activo y destino aceptados.
Payload
El cliente selecciona una opción aceptada y crea el payload de pago firmado correspondiente.
Reintento
El cliente repite la solicitud mediante el transporte con la información del pago adjunta.
Verificación y liquidación
El servidor verifica localmente o mediante un facilitador y sigue el flujo de liquidación del esquema elegido.
Entrega del recurso
Tras procesar el pago correctamente, puede devolver el resultado protegido y la respuesta de liquidación.
La terminología sigue la especificación oficial x402 v2 en el commit inspeccionado. x402-XEC todavía usa estructuras de la época de v1; este sitio no las presenta aún como compatibles con v2.
Base de investigación
¿Por qué XEC?
La pregunta de investigación es práctica: ¿cómo puede el dinero UTXO nativo participar en flujos de pago legibles por máquinas manteniendo explícitos los límites de autorización, política y custodia?
Dinero UTXO nativo
XEC ofrece un modelo directo de transacciones para estudiar liquidación on-chain de valor exacto sin introducir un saldo sintético de aplicación.
Economía de valores pequeños
eCash es relevante para experimentos similares a micropagos, donde importan el costo y la forma operativa de transferencias pequeñas. Aquí no suponemos cifras de rendimiento.
Lectura y verificación
Chronik brinda interfaces de indexación y lectura para descubrir UTXOs, inspeccionar transacciones y producir futura evidencia de confirmación.
Límite de la wallet
Tonalli es el límite previsto para usuario y agente: muestra los datos exactos, exige aprobación explícita y conserva las llaves dentro de la wallet.
Política antes del dinero
CAE y Agentic Contract V1 modelan por separado intención, política, aprobación humana, firma, broadcast y confirmación.
Flujos nativos para máquinas
HTTP, las APIs cobrables y, más adelante, los adaptadores MCP/A2A permiten investigar comercio entre agentes sin fingir que hoy está activo.
Componentes verificados
Lo que xolosArmy Network ya construyó
Cada tarjeta se limita a evidencia de repositorios. “Implementado” significa que existe código en la revisión enlazada; no significa automáticamente despliegue productivo ni ejecución con fondos reales.
Base de protocolo x402-XEC
Esquemas estrictos de factura y autorización, vínculo determinista al recurso, controles anti-replay, verificación local del facilitador, adaptadores Axios y Express, preparación offline y construcción de transacciones.
Examinar x402-XEC en 8696c28Dry-run HTTP 402 en navegador
El flujo registrado recibió 402, pidió aprobación simulada, adjuntó PAYMENT-SIGNATURE, repitió la solicitud y devolvió el recurso protegido. El resultado declara broadcasted: false.
Límite de autorización Tonalli
Tonalli muestra un modal de aprobación explícita y firma dentro de la wallet el mensaje de autorización. El adaptador rechaza como no soportada la firma de una transacción preparada.
Examinar el adaptador TonalliAgentic Contract V1
Una máquina de estados estricta separa intención, decisión de política, solicitud a la wallet, aprobación humana, transacción firmada, broadcast y confirmación. El contexto x402 opcional es metadata, no permiso.
Leer el contrato canónicoCAE / Tonalli Agents
Están implementados decisiones fail-closed, kill switch, allowlists de destino, límites diarios acumulados y controles anti-replay. Incluso una política aprobada se detiene antes de firma y broadcast.
Examinar la seguridad del Ciclo 1Tonalli Commerce Relay
La base de órdenes, identidad, reputación, evidencia y disputas explora un ciclo comercial XEC más amplio. El escrow real de XEC, broadcast y seguimiento de confirmación siguen pendientes.
Leer los límites de producciónVista del sistema
Arquitectura con límites
El diagrama es un mapa conceptual de integración, no una traza activa. Los límites dorados, azules y neutros discontinuos distinguen intencionalmente la evidencia actual, la integración y el futuro trabajo con dinero real.
Corte de evidencia · 2026-08-25
Matriz de estado
La fuente actual manda. “Pendiente” y “no habilitado” son estados de ingeniería deliberados, no omisiones ocultas tras lenguaje publicitario.
| Capacidad | Estado | Evidencia / límite |
|---|---|---|
| Base de protocolo HTTP 402 para XEC | Implementación experimental | Workspace de paquetes |
| Vínculo de factura y recurso HTTP | Implementado | Modelo canónico de hashes |
| Protección anti-replay | Implementado | Límite de nonce atómico; el almacén en memoria continúa siendo de un solo proceso. |
| Verificación del facilitador local | Implementado | Fixtures por defecto, adaptador real de lectura opt-in |
| Construcción offline de transacciones XEC | Implementado | Sin red ni API de broadcast |
| Adaptadores Chronik de solo lectura | Implementados · opt-in | Exigen endpoint explícito; los fixtures siguen siendo el valor por defecto. |
| E2E HTTP 402 en navegador | Probado en dry-run | broadcasted: false; aprobación y firma simuladas. |
| UI de aprobación Tonalli | Implementada | Muestra la metadata pública exacta |
| Firma Tonalli del mensaje de autorización | Integración dry-run | Outpoint de fondeo en ceros; no se crea una transacción. |
| Firma real de transacción Tonalli para x402 | Aún no demostrada | signPreparedTransaction devuelve no soportada. |
| Pago automático x402 en mainnet | No habilitado | Broadcast es un límite separado y opt-in, sin conexión a Axios ni al demo. |
| Gasto autónomo de fondos reales | Congelado | Pruebas de congelamiento |
| Alineación semántica con x402 v2 | Pendiente | La base usa estructuras de v1 y el identificador provisional xec:mainnet. |
| Identificador estandarizado de red XEC | Pendiente | v2 exige CAIP-2; la documentación upstream inspeccionada no contiene una entrada XEC. |
| Integración del transporte MCP | Investigación / pendiente | Referencia upstream v2 |
| Integración de pagos A2A | Investigación / pendiente | Referencia upstream v2 |
| API cobrable de producción | Pendiente | Este portal en GitHub Pages es estático y no tiene backend de liquidación. |
| Integración Bazaar / descubrimiento | Pendiente | Extensión upstream inspeccionada |
Sin fechas inventadas
Ruta guiada por evidencia
El orden sigue dependencias y límites de seguridad: primero modernizar el contrato del protocolo; después demostrar firma y liquidación controlada; por último, añadir servicios cobrables y transportes para agentes.
Modernización del protocolo
- Comparar x402-XEC con x402 v2 actual.
- Migrar semántica de wire cuando corresponda.
- Establecer un identificador XEC normalizado y documentar el par
(scheme, network). - Actualizar pruebas de compatibilidad y seguridad.
Límite de ejecución Tonalli
- Conservar la aprobación explícita.
- Añadir firma de transacción preparada dentro de Tonalli.
- Mantener secretos fuera de x402-XEC.
- Vincular exactamente factura, recurso, monto y
payTo.
E2E XEC controlado
- Descubrimiento read-only de UTXOs y plan determinista.
- Valor mínimo controlado y aprobación explícita.
- Firma exacta y broadcast autorizado por separado.
- Verificación Chronik, confirmación y evidencia reproducible.
Primera API cobrable
- Crear un recurso x402 real protegido con XEC.
- Desplegar por separado el backend de liquidación.
- Mantener honesto este portal estático en GitHub Pages.
Pagos entre agentes
- Conectar
AgentIntentV1con CAE. - Vincular requisitos x402 con política y aprobación Tonalli.
- Entregar el recurso protegido solo tras verificar el estado del pago.
MCP / A2A
- Seguir las especificaciones upstream vigentes.
- Construir adaptadores solo después de estabilizar el esquema XEC v2.
- Conservar los mismos límites de política y custodia en cada transporte.
Descubrimiento
- Explorar metadata Bazaar para recursos cobrables en XEC.
- Validar el catálogo contra evidencia real.
- No publicar endpoints descubribles antes de que exista la API cobrable.
Construcción pública
Libro de Evidencia
Los hitos se clasifican como código, dry-run, autorización en staging o congelado. Una clasificación “live” exige evidencia de transacción y red; aquí no se afirma ninguna.
| Fecha | Hito | Clasificación | Evidencia inmutable |
|---|---|---|---|
| 2026-07-01 | Flujo HTTP 402 en navegador completado con recurso protegido y broadcasted: false. | Dry-run | Resultado · |
| 2026-07-02 | Límite de wallet Tonalli añadido con aprobación explícita y firma del mensaje dentro de la wallet. | Código | a743f904 |
| 2026-07-02 | Modal de aprobación Tonalli añadido; aprobar no transmite ni paga una transacción. | Código | b74631b5 |
| 2026-07-03 | Ruta de autorización confiable en staging con allowlist de origen/ruta y resultado solo de autorización. | Autorización staging | 4d5ee146 |
| 2026-07-18 | Commerce Relay documentó la base de órdenes y confianza; escrow real y broadcast XEC siguieron pendientes. | Base adyacente | 5a820dce |
| 2026-07-30 | Agentic Contract V1 fusionado con orden estricto de intención a confirmación y entrega x402 segura para mostrar. | Código | cfe4cb15 |
| 2026-07-30 | CAE Ciclo 1 fusionado con política fail-closed y congelamiento explícito de ejecución monetaria. | Congelado | 7b90c805 |
| 2026-08-25 | Especificación oficial x402 v2 y fuentes HTTP, MCP, A2A, CAIP-2 y Bazaar reinspeccionadas para este portal. | Investigación upstream | f8a3682d |
Repositorios inspeccionados
Dirección de investigación
Evidencia antes que autonomía.
La siguiente demostración importante no es un contador. Es un pago XEC de valor mínimo, alineado con v2 y aprobado explícitamente, con evidencia reproducible de firma, broadcast y confirmación en Chronik.