Un agente de IA está a punto de transferir capital a un protocolo de préstamos.
Antes de firmar nada, consulta las comisiones registradas por el protocolo durante el último trimestre.
Una pregunta sencilla: ¿cómo sabe que esa cifra es real?
En este momento, por lo general, no puede hacerlo.
La cifra proviene de una API o de la base de datos de alguien, y el agente actúa sobre lo que recibe, a velocidad de máquina.
Esta brecha es precisamente lo que @SpaceandTime busca resolver.
Space and Time es una cadena de bloques de datos respaldada por M12, el fondo de capital de riesgo de Microsoft.
Indexa datos de la cadena, almacena conjuntos de datos fuera de ella y devuelve resultados SQL con una prueba zk adjunta (Proof of SQL).
Quien consuma el resultado, ya sea un agente o un contrato, verifica la prueba y evita tener que confiar en el operador.
IA
El conjunto de herramientas para agentes está creciendo rápido: carteras, firmas, sistemas de pago y ejecución entre cadenas. Pero lo que se interpone entre la intención de un agente y su transacción sigue siendo escaso: los datos que le indican si la transacción tiene sentido.
Piensa en lo que debe hacer un agente financiero serio antes de actuar.
Analizar cómo se ha comportado una posición durante semanas, agregar actividad entre protocolos y cadenas, obtener datos externos como los niveles de reservas y luego aplicar lógica a todo ello.
Un agente que evalúa un préstamo necesita saber cómo ha variado la ratio de colateral del prestatario en los últimos 30 días, y un contrato inteligente no puede responder a eso a partir del estado actual.
Un operador humano revisaría el panel para asegurarse de que todo cuadra antes de hacer clic. Un agente no tiene esa pausa.
Una cifra desactualizada o manipulada se incorpora directamente a una transacción firmada. Cuando el historial de comisiones o los datos del colateral llegan como resultado de una consulta verificada, el agente puede verificar sus propios datos de entrada y la contraparte puede comprobar qué vio el agente antes de que se muevan los fondos.
Ese segundo aspecto es lo que convierte «dejar que un agente gestione dinero» de un salto de fe en algo que un equipo de riesgos puede aprobar.
Tokenización
La tokenización de primera generación era una envoltura: un token que sigue el precio de un bono o una acción. Los productos que las instituciones gestionan ahora son cálculos matemáticos.
-un fondo tokenizado del mercado monetario se rebalancea según las curvas de rendimiento y aplica reglas de reembolso en función de los umbrales de liquidez.
-un fondo de crédito privado recibe pagos de decenas de préstamos, aplica la lógica de prelación de pagos entre tramos y ajusta las valoraciones a medida que se producen impagos.
El activo es el resultado de ese cálculo.
Aquí es donde se estanca la mayoría de los programas: los contratos pueden hacer cumplir reglas, pero no pueden realizar cálculos sobre conjuntos de datos grandes o históricos. Los sistemas fuera de la cadena sí pueden hacerlo, pero entonces todos los titulares tienen que confiar en el resultado.
Los emisores acaban simplificando el activo o añadiendo un intermediario de confianza, lo que socava el motivo por el que se tokenizó en primer lugar.
Space and Time cubre esa brecha: un administrador o emisor ejecuta el cálculo del valor liquidativo mediante una consulta SQL sobre los datos de las tenencias y publica el resultado junto con una prueba de que se calculó correctamente a partir de esos datos.
La custodia y la auditoría siguen estableciendo cuáles son las tenencias. La prueba cubre el último tramo entre esos registros y la cifra que el titular ve en la cadena.
La misma lógica se aplica a una acción tokenizada que se negocia en varios pools: el volumen total de todos ellos se convierte en un único cálculo, verificado frente a datos comprometidos criptográficamente.
DeFi
Un contrato ve el bloque actual y nada anterior. Por eso la mayoría de los incentivos DeFi son poco precisos.
Un único nivel de comisiones para todos. Recompensas distribuidas según instantáneas que los farmers aprenden a manipular. Programas de fidelidad que no pueden detectar la fidelidad.
Los hooks de Uniswap v4 muestran tanto el límite como la solución. Un hook puede ejecutar lógica personalizada en cada intercambio, pero solo conoce el estado actual del pool y lo que se le envía.
Space and Time publica plantillas de hooks en las que el hook plantea una pregunta histórica —por ejemplo, cuánto ha intercambiado esta cartera en los últimos 30 días— y recibe una respuesta verificada.
La plantilla de descuento por fidelidad almacena en caché el nivel del usuario una vez comprobados los requisitos y aplica la comisión más baja en el momento del intercambio. La consulta SQL es lo único que escribe el desarrollador.
El mismo patrón se extiende a los programas de recompensas, donde los requisitos se calculan a partir de la actividad real pasada y se verifican, de modo que nadie declara su propia actividad y cualquiera puede auditar quién cumplió los requisitos y por qué.
Por fin, los protocolos pueden fijar precios según el comportamiento a lo largo del tiempo, en lugar de hacerlo según un único instante.
Token
El token está vinculado al trabajo real. Cada carga de trabajo en la red se liquida en $SXT : indexar datos de cadenas, insertar conjuntos de datos fuera de la cadena y generar y verificar pruebas de consultas.
Cada consulta cuesta SXT porque requiere cómputo real. Por otro lado, se hace staking de SXT para respaldar a los validadores que ejecutan consultas y protegen la cadena.
El uso y la seguridad dependen del mismo activo, y las comisiones se registran en la cadena, donde cualquiera puede consultarlas.
Si tu agente o protocolo pudiera verificar una consulta histórica antes de actuar, ¿cuál elegirías primero?
