Construimos por capacidades, no por promesas.
Diferenciamos lo que ya se puede comprobar, lo que estamos integrando y lo que viene después. Cada elemento indica dónde tiene evidencia hoy (simulación o testnet; nada corre en producción) y quién mantiene su estado al día. No publicamos fechas rígidas.
Componentes comprobables
Base técnica y exploración
Un componente disponible no es un flujo de compra habilitado. Un pago técnico verificado no es una compra comercial.
USDC de Avalanche Fuji a Stellar con CCTP
Pago de punta a punta en testnet: quema en Fuji, atestación de Circle y acuñación en Stellar, con API, conciliación y un modo sin gas para el comprador. Reproducido de forma independiente. Es un riel técnico: aún no está unido a cotizaciones, órdenes ni entrega.
Evaluador determinista de políticas
Un prototipo en tilcai-core comprueba límites, destinatario, red y activo, y devuelve ALLOW o DENY. ALLOW indica que la política se cumple; no autoriza una transferencia ni confirma un pago.
Contratos compartidos
Tipos versionados para IDs, estados, errores, intención, mandato y herramientas MCP. Mantienen decisión, pago y entrega como estados separados. La revisión del equipo sigue pendiente.
Web, oficina y simulación visual
Una web bilingüe con una oficina y una simulación de políticas ilustrativas. No mueven fondos ni llaman a tilcai-core ni a una red de pagos.
Validación del flujo
Consulta y compra con aprobación
El piloto se declara validado cuando funciona el recorrido completo en su entorno indicado.
Pago directo en Stellar con x402
La verificación y la liquidación pasan por un OpenZeppelin Relayer. Se confirmó un pago en testnet y repetir el mismo payload no pagó dos veces, pero la prueba usó el activo nativo, no USDC. Falta repetirla con USDC y conectarla a la orden.
Cotizaciones, órdenes y adaptador comercial
Cotizaciones verificables, órdenes y el adaptador que consulta el sistema propio de cada negocio, que sigue siendo la fuente de verdad de precios y disponibilidad.
Aprobación por compra
La persona revisa y autoriza las condiciones exactas de cada compra. Conectar un asistente o una cuenta nunca autoriza gastar.
Orden, pago y entrega unidos
El riel técnico ya concilia sus pagos. Falta enlazar cada pago con su orden y con la confirmación de entrega del negocio, y mantener la retención de presupuesto cuando el resultado es incierto.
Conector MCP y guías de asistentes
La superficie de herramientas para asistentes está especificada, pero todavía no hay un servidor MCP expuesto. Se publica una guía por cliente solo después de probarlo.
Canal de WhatsApp
El equipo demostró instrucción, pago y comprobante por WhatsApp. Falta integrar el adaptador propio y repetirlo con credenciales al alcance del equipo.
Terceros y cuentas (fase SCA)
Los datos de terceros, con claves guardadas como hash, cuotas diarias y registro de cuentas, están en revisión. La autenticación por tercero, la API y la emisión de cuentas siguen pendientes.
Después de validar la base
Delegación e interoperabilidad
Sin fechas rígidas: cada elemento avanza cuando supera sus pruebas.
Smart accounts con permisos limitados
Firma delegada con alcance, vigencia y revocación, habilitada solo después de probar juntas la cuenta, el firmante y el riel.
Presupuesto compartido entre agentes
Límites y retenciones coordinados entre varios agentes, para que no gasten dos veces los mismos fondos.
Tareas programadas y más clientes o proveedores
Compras repetidas que se reevalúan en cada ejecución, además de más asistentes y negocios.
Más rutas de CCTP
Ethereum, Arbitrum, Base, Arc, Solana y Sui están en el laboratorio. Cada ruta se habilita, una por una, cuando pasa su prueba de punta a punta.
Entrada y salida en bolivianos
Todavía no hay un proveedor ni un corredor verificados. Hoy no se acepta un depósito por QR ni se convierte moneda local: CCTP solo mueve USDC.