Un agent d'IA s'apprête à transférer des capitaux vers un protocole de prêt.
Avant de signer quoi que ce soit, il récupère les frais du protocole enregistrés pour le dernier trimestre.
Question simple : comment sait-il que ce chiffre est réel ?
Pour l'instant, ce n'est généralement pas le cas.
Le chiffre provient d'une API ou de la base de données de quelqu'un, et l'agent agit à partir de ce qu'on lui fournit, à la vitesse d'une machine.
C'est autour de cette lacune que @SpaceandTime a été conçu.
Space and Time est une blockchain de données soutenue par M12, le fonds de capital-risque de Microsoft.
Elle indexe les données on-chain, stocke à côté les jeux de données off-chain et renvoie des résultats SQL accompagnés d'une preuve zk (Proof of SQL).
Qu’il s’agisse d’un agent ou d’un contrat, celui qui reçoit le résultat vérifie la preuve et n’a pas à faire confiance à l’opérateur.
IA
La pile technologique des agents se met rapidement en place : portefeuilles, signatures, moyens de paiement, exécution interchaînes. Mais ce qui se trouve entre l’intention d’un agent et sa transaction reste encore peu développé : les données qui lui indiquent si la transaction a du sens ou non.
Voyons ce qu’un agent financier sérieux doit faire avant d’agir.
Analyser l’évolution d’une position sur plusieurs semaines, agréger l’activité sur différents protocoles et différentes chaînes, récupérer des données hors chaîne comme les niveaux de réserves, puis appliquer une logique à l’ensemble.
Un agent qui évalue un prêt veut savoir comment le ratio de garantie de l’emprunteur a évolué au cours des 30 derniers jours. Or, un contrat intelligent ne peut pas répondre à cette question à partir de l’état actuel.
Un trader humain vérifierait rapidement le tableau de bord avant de cliquer. Un agent, lui, ne marque pas de pause.
Un chiffre obsolète ou manipulé est directement intégré à une transaction signée. Si l’historique des frais ou les données de garantie sont renvoyés sous forme de résultat de requête prouvé, l’agent peut vérifier lui-même les données qu’il utilise, et la contrepartie peut vérifier ce que l’agent a vu avant que les fonds ne soient transférés.
C’est cette deuxième étape qui transforme « laisser un agent gérer de l’argent » : d’un acte de foi en une décision qu’une équipe chargée des risques peut approuver.
Tokenisation
La première vague de tokenisation n’était qu’un emballage : un jeton qui suit le cours d’une obligation ou d’une action. Les produits que les institutions exploitent aujourd’hui reposent sur des calculs.
- un fonds monétaire tokenisé se rééquilibre en fonction des courbes de rendement et applique des règles de rachat selon des seuils de liquidité.
- un pool de crédit privé perçoit les paiements de dizaines de prêts, applique une logique de cascade entre les tranches et ajuste les valorisations à mesure que les défauts surviennent.
L’actif est le résultat de ce calcul.
C’est là que la plupart des projets butent : les contrats peuvent appliquer des règles, mais pas effectuer des calculs sur de grands ensembles de données ou des données historiques. Les systèmes hors chaîne peuvent faire ces calculs, mais chaque détenteur doit alors faire confiance au résultat.
Les émetteurs finissent par simplifier l’actif ou par ajouter un intermédiaire de confiance, ce qui va à l’encontre de la raison même de la tokenisation.
Space and Time comble cette lacune : un administrateur ou un émetteur exécute le calcul de la valeur liquidative sous forme de requête SQL sur les données des positions, puis publie le résultat avec une preuve attestant que le calcul a été correctement effectué à partir de ces données.
La conservation et l’audit permettent toujours d’établir la composition des positions. La preuve comble le dernier écart entre ces registres et le chiffre que voit un détenteur sur la chaîne.
Même principe pour une action tokenisée négociée sur plusieurs pools : le volume total de tous les pools est calculé en une seule fois et prouvé à partir des données engagées.
DeFi
Un contrat voit le bloc actuel et rien de ce qui le précède. C’est pourquoi la plupart des incitations DeFi manquent de nuance.
Un seul niveau de frais pour tout le monde. Des récompenses distribuées à partir d’instantanés que les farmers apprennent à exploiter. Des programmes de fidélité incapables de reconnaître la fidélité.
Les hooks d’Uniswap v4 montrent à la fois les limites et la solution. Un hook peut exécuter une logique personnalisée à chaque swap, mais il ne connaît que l’état actuel du pool et les données qu’on lui transmet.
Space and Time publie des modèles de hooks dans lesquels le hook pose une question historique — par exemple, combien ce portefeuille a-t-il échangé au cours des 30 derniers jours ? — et reçoit une réponse vérifiable par preuve.
Le modèle de remise de fidélité met en cache le niveau de l’utilisateur une fois son admissibilité prouvée, puis applique les frais réduits au moment du swap. La requête SQL est la seule chose que le développeur doit écrire.
Le même principe s’applique aux programmes de récompenses : l’admissibilité est calculée à partir de l’activité réelle passée, puis prouvée. Ainsi, personne ne déclare ses propres activités et chacun peut vérifier qui était admissible, et pourquoi.
Les protocoles peuvent enfin établir le prix en fonction des comportements dans la durée, plutôt que d’un instant unique.
Jeton
Le jeton est lié au travail réellement effectué. Chaque charge de travail sur le réseau est réglée en $SXT : indexation des données de la blockchain, insertion de jeux de données hors chaîne, génération et vérification de preuves de requêtes.
Chaque requête coûte des SXT, car elle mobilise de vraies ressources de calcul. En contrepartie, des SXT sont mis en staking pour soutenir les validateurs qui exécutent les requêtes et sécurisent la blockchain.
L’utilisation et la sécurité reposent sur le même actif, et les frais sont inscrits sur la chaîne, où chacun peut les suivre.
Si votre agent ou votre protocole pouvait prouver une requête historique avant d’agir, laquelle choisiriez-vous en premier ?
