ZOOBC / INFRASTRUCTURE DE TRÉSORERIE POUR AGENTS
Donnez de l'argent à votre agent d'IA. Gardez un plafond qu'il ne peut pas franchir.
ZooBC donne aux agents autonomes la latitude de dépenser, d'embaucher et d'effectuer des transactions à l'intérieur d'une limite budgétaire imposée par le réseau, et non par la maîtrise de soi de l'agent. Une implémentation de référence en Python, sans aucune dépendance, démontre la boucle de transaction complète sur le testnet en service.
- LIMITE
- Verrouillée d'avance
- CONTRÔLE
- Hausses signées par un humain
- REGISTRE
- Vérifiable de manière indépendante
COMMENCER ICI / TROIS RESSOURCES EN SERVICE
De la découverte à une transaction vérifiée.
Un agent ou un développeur peut passer d'un unique fichier de découverte à une transaction confirmée sur le testnet, sans navigateur, sans SDK et sans installer de dépendance.
Donnez un seul fichier à votre agent.
llms.txt identifie le testnet en service, les points de terminaison essentiels, le modèle de signature, le faucet et le prochain document que l'agent doit lire.
Ouvrir llms.txt ↗02 / IMPLÉMENTERLisez le guide complet des agents.
AGENTS.md documente la construction des transactions, les allocations programmées, les séquestres à expiration, les dépenses multisig, les requêtes d'audit et les lacunes connues.
Lire AGENTS.md ↗03 / EXÉCUTERExécutez la référence fonctionnelle.
Ce fichier Python sans dépendance génère une clé, réclame des jetons de test, estime les frais, signe, soumet, confirme et vérifie une véritable transaction.
Ouvrir la référence Python ↗LA COUCHE DE CONTRÔLE NON RÉSOLUE
L'autonomie ne devrait pas exiger un chèque en blanc.
Les systèmes d'IA se voient confier leurs propres tâches, outils et décisions d'achat. Le plus difficile est de leur donner une capacité financière sans surveiller chacun de leurs gestes. ZooBC transforme la limite de dépenses en état du réseau : l'agent peut agir librement à l'intérieur, mais ne peut pas la réécrire.
Le logiciel propose. Le registre impose.
TROIS CONTRÔLES + TROIS CAPACITÉS
Ce que le réseau impose, et ce que les applications construisent autour.
Les allocations verrouillées, les séquestres à expiration et les seuils multisig sont des contrôles. Le commerce, le règlement en jetons et l'identité déclarée sont des capacités assemblées à partir des transactions et des données ZooBC.
Une allocation que votre agent d'IA ne peut pas dépasser.
Un transfert programmé avec le mode de financement 0 verrouille l'allocation totale dès sa création. L'agent reçoit un montant défini à chaque déblocage, tandis que toute augmentation du total exige une nouvelle transaction autorisée par le propriétaire. Le reliquat peut être révoqué ou réaffecté.
Un paiement peut vous attendre sans bloquer votre argent.
Un agent peut proposer un paiement qui reste en attente jusqu'à ce que l'approbateur désigné l'accepte ou le rejette. Le délai d'expiration est un horodatage Unix absolu. S'il s'écoule sans réponse, le montant et la commission sont restitués automatiquement sur la chaîne.
Exigez plus d'une signature pour les paiements importants.
Un transfert multisig ne s'exécute qu'une fois atteint le seuil défini de N signatures sur M. Les applications peuvent laisser un agent gérer directement les petites transactions tout en soumettant les engagements plus importants à des approbateurs indépendants.
Les agents peuvent effectuer des transactions et laisser des reçus vérifiables.
Le commerce d'agent à agent est un cas d'usage construit à partir de transactions signées et des contrôles ci-dessus. N'importe qui peut interroger le hachage de la transaction, la confirmation du bloc, l'historique du compte et les mouvements de solde sans dépendre des journaux privés de l'un ou l'autre agent.
Réglez sur la chaîne de minuscules paiements entre machines.
Les micropaiements sont un cas d'usage construit sur le ZBC, les jetons émis par les utilisateurs, les transferts signés et la plateforme d'échange sur la chaîne. Les applications peuvent s'appuyer sur ces rails pour régler des consultations, des appels d'API ou d'autres travaux de machines tout en conservant un registre public des paiements.
Publiez ce qu'un agent déclare être.
Un agent peut écrire des enregistrements de jeu de données signés décrivant son opérateur, sa finalité, ses capacités, son point de terminaison et son calendrier budgétaire. Il s'agit d'une déclaration vérifiable émise par le compte, et non d'une primitive d'identité imposée par la chaîne. Les applications doivent encore décider si elles lui font confiance.
UN AGENT / DEUX COUCHES ÉCONOMIQUES
Voyez ce que le modèle a consommé et ce que l'agent a dépensé.
Un agent utile a deux compteurs. Son fournisseur de modèle mesure l'utilisation de l'inférence. Son compte ZooBC enregistre la valeur dépensée lorsqu'il agit sur le monde. Une application peut rapprocher les deux autour du même agent et du même flux de travail.
Tokens, appels ou calcul déclarés par le fournisseur.
Paiements, séquestres, échéanciers, frais et mouvements de solde enregistrés sur la chaîne.
Rapprochez l'utilisation du modèle et les dépenses sur la chaîne, vérifiables de manière indépendante.
Limite d'application : ZooBC impose l'allocation côté chaîne et les règles de transaction. Le fournisseur de modèle reste la source de référence pour la mesure de l'inférence : le code applicatif doit donc rapprocher les deux registres.
LE PARCOURS RÉEL DE LA TRANSACTION
Un paiement borné, de l'échéancier à la preuve dans le registre.
Voici les véritables opérations ZooBC derrière ce modèle. Le code applicatif choisit toujours le spécialiste, valide le travail et décide quelles signatures comptent.
- 01 / TX DE TYPE 29
Verrouillez l'allocation.
scheduled-transfer
funding_mode: 0Le propriétaire verrouille d'avance le montant total. Modifier le plafond total exige une nouvelle transaction.
→ - 02 / SÉQUESTRE
Proposez le paiement.
zbc-send
--escrow-approverL'agent désigne un approbateur et fournit un délai d'expiration Unix absolu pour la restitution automatique.
→ - 03 / MULTISIG
Atteignez le seuil.
zbc-cli multisig
2 of 3 examplePour un paiement plus important, l'application valide la livraison et recueille deux des trois signatures requises avant l'exécution du transfert interne.
→ - 04 / API PUBLIQUE / TESTNET
Réglez et vérifiez.
approve-escrow approval: 0
GET https://zoobc.network/api/v1/transactions/{hash}
GET https://zoobc.network/api/v1/accounts/{address}/historyL'approbation libère les fonds. L'expiration les restitue. La transaction et l'historique du compte prouvent quel chemin a été suivi.
✓
FONCTIONNEMENT
Quatre étapes, du premier fichier à la transaction vérifiée.
- 01
Lire un fichier
Commencez par llms.txt pour que l'agent découvre la chaîne en service, le guide, l'API et les règles du testnet.
- 02
Exécuter la référence
Lancez l'exemple Python pour générer, approvisionner, signer, soumettre, confirmer et vérifier une transaction.
- 03
Ajouter des contrôles
Utilisez un échéancier verrouillé, un séquestre à expiration ou un seuil multisig selon le risque réel du flux de travail.
- 04
Vérifier le registre
Interrogez le hachage de la transaction, l'historique du compte et les mouvements au lieu de vous fier à la réponse de soumission.
QUESTIONS DIFFICILES
Ce que la limite résout, et ce qu'elle ne résout pas.
Le registre peut imposer des conditions financières. Il ne peut pas remplacer une conception rigoureuse de l'agent, les déclarations d'identité ni la validation des résultats.
01Un plafond de dépenses rend-il un agent sûr ?
Il limite le montant exposé ; il ne garantit pas que chaque achat soit judicieux. Les autorisations de tâches, le choix des fournisseurs, la validation des résultats et la surveillance opérationnelle relèvent toujours du système d'agent qui entoure le portefeuille.
02L'agent peut-il augmenter sa propre allocation ?
Pas dans le modèle borné décrit ici. Relever le plafond engagé exige une nouvelle transaction autorisée par le compte qui contrôle l'allocation.
03Que se passe-t-il si un paiement proposé n'est jamais approuvé ?
Une proposition peut comporter une date d'expiration. Si l'approbation n'arrive pas avant cette échéance, le montant placé sous séquestre suit le chemin de restitution configuré au lieu de rester indéfiniment en attente.
04Qu'est-ce qui prouve quel agent a autorisé une action ?
La signature cryptographique prouve que le détenteur d'une clé donnée a autorisé le message ou la transaction. Les déclarations sur l'opérateur, la finalité et la réputation de cette clé exigent toujours des enregistrements signés clairs et une vérification indépendante.
05S'agit-il d'un produit pour agents ou d'un ensemble de primitives blockchain ?
Aujourd'hui, la base est la couche transactionnelle de ZooBC : comptes, signatures, séquestre, approbation multisignature, jetons et un registre auditable. Une intégration d'agent en production nécessite encore un logiciel qui assemble ces primitives pour son flux de travail spécifique.
LE TESTNET EST EN SERVICE
Exécutez la preuve, puis ajoutez la limite.
Commencez par la référence fonctionnelle, confirmez une véritable transaction sur le testnet, puis ajoutez les contrôles d'allocation, d'approbation et d'audit dont votre flux de travail a besoin.