Le testnet d'agents de Gora est en ligne, et son application de démonstration est un fonds d'IA auquel vous pouvez participer

Gora est un réseau d'ordinateurs hors chaîne qui exécutent le code d'une application et signent ce qu'elle a renvoyé, de sorte qu'un smart contract ou un portefeuille puisse agir sur une réponse validée par une majorité de machines indépendantes. Son testnet est en ligne — la documentation pour développeurs de Gora le dit sans détour et le point de terminaison qu'elle nomme répond — et la partie qu'un non-développeur peut utiliser dès aujourd'hui est un fonds de trading piloté par IA que l'on ouvre dans un navigateur, que l'on regarde prendre des décisions et dans lequel on dépose des GORA de testnet.
Le fonds d'IA, vu par un visiteur
L'application s'appelle Gora Trading Bot et elle s'ouvre sur des chiffres avant tout discours : une NAV de 1.0266 GORA par part, en hausse de 2.66 % sur 48 étapes, 25.7k GORA d'actifs et 40 déposants. La NAV, soit la valeur liquidative — le prix d'une part du fonds —, est le taux auquel un dépôt serait converti. Sous les chiffres figure la carte de décision : la stratégie est MOMENTUM V0, la décision retenue est STAY FLAT avec 55 % de confiance, et le raisonnement est une phrase plutôt qu'une boîte noire — « Pas d'avantage exploitable : le prix oscille autour de sa moyenne. Rester sans position ne coûte rien et garde le capital disponible. » Suivent deux hachages tronqués, l'un pour le prompt envoyé au modèle, l'autre pour sa réponse, et l'inférence est attribuée à « Gora validators (P1) ».
Un bouton propose de lancer vous-même une étape de stratégie, et un clic a ajouté une nouvelle entrée en haut du journal de décisions, marquée « attested » et portant sa propre paire de hachages tronqués. Chaque entrée associe un numéro d'étape et ce tag « attested » à la justification en une ligne du modèle : le journal enregistre l'arrivée d'un déposant avec 1,250.00 GORA et des parts émises à une NAV de 1.0142, puis une décision de conserver une position longue, le prix restant au-dessus de sa moyenne et le drawdown depuis l'entrée dans les limites tolérées.
Rejoindre le fonds, c'est déposer des GORA contre des parts à la NAV du moment, avec un retrait possible à tout moment et sans blocage, selon les conditions affichées sur la page elle-même. Obtenir ces GORA suppose de passer par un faucet, et le bridge en expose un pour Algorand. Vingt-cinq mille GORA répartis entre quarante déposants, c'est une échelle de démonstration, et les GORA qui s'y trouvent sont un actif de test ; les actifs d'un testnet, la copie expérimentale d'une blockchain, n'ont aucune valeur monétaire.
Une loterie avec une cagnotte on-chain
L'autre application du bridge est une loterie, et elle montre quelle part du règlement peut tenir dans un contrat. « Participez gratuitement. À chaque période de tirage, la cagnotte on-chain paie 3 utilisateurs inscrits tirés au hasard, en GORA », peut-on lire sur sa page, qui ajoute que participer inscrit votre compte Algorand dans l'application de loterie et que votre approbation de portefeuille est signée par votre clé puis vérifiée par le réseau. L'application Algorand qui la sous-tend stocke l'ensemble des règles sous forme de paramètres plutôt que de promesses.
| Enregistrement on-chain (testnet Algorand) | Ce qu'il nous apprend |
|---|---|
| Applications passerelle 767488273 et 764251228 | Les requêtes sont conservées dans des boîtes propres à chaque requête, et un fulfil est signé par le comité puis vérifié on-chain avec ed25519verify_bare, si bien qu'un contrat peut rejeter une réponse arrivée sans les signatures du comité. |
| Application de staking des validateurs 764254589 | Stocke l'identifiant de l'actif GORA, une mise minimale de 100 GORA, un délai de déblocage et une clé publique de participation enregistrée par validateur. La clé de participation est la clé chaude avec laquelle un processus validateur signe ses votes et ses preuves VRF ; ce qui fixe le poids de vote d'un validateur lors de la sélection du comité, c'est le GORA qu'il a mis en staking, et non la clé. |
| Application de loterie 764491406 | Contient l'adresse de l'opérateur, l'actif servant de prix, un lot de 10,000,000 exprimé dans un actif à six décimales (10 GORA), un réglage de période à 300, un compteur de tours à 17 et l'horodatage du dernier tirage. |
| Actif de test GORA 764254575 | Nommé « Gora Test », six décimales, un milliard émis. |
Comment une réponse est signée
Rien de tout cela ne constitue une blockchain à part. « Le réseau Gora n'est pas une blockchain — il s'accorde sur les résultats d'une application et écrit des attestations sur la chaîne visée par ce résultat », affirme la documentation. Les validateurs misent des GORA sur Algorand, Base ou Solana et signent à l'intérieur des tours avec une clé de participation, tandis que la clé de propriétaire qui les autorise reste froide. Une requête entre, un comité est choisi pour ce tour, le comité exécute l'application, et le résultat sur lequel il s'accorde revient signé ; quiconque détient les clés publiques des validateurs peut contrôler les signatures, et un contrat peut les contrôler on-chain.
Une application, c'est du code hors chaîne — WASM, JavaScript, TypeScript ou Python — accompagné d'un manifeste et d'une politique. La politique est la partie qu'il faut connaître : elle limite les chaînes que l'application peut toucher, les types d'actions qu'elle peut demander, les montants qu'elle peut déplacer par transaction et par jour, et les destinataires qu'elle peut payer. Le manifeste du fonds indique lui-même que le nœud Gora ne détient pas les clés des utilisateurs et ne règle pas leur gas, l'utilisateur ou un compte préapprouvé payant par défaut. Le code décide et renvoie une instruction ; jamais il ne détient de clé privée ni ne déplace l'argent lui-même. L'aléa arrive comme effet de bord de ce même dispositif, puisque sélectionner un comité exige déjà de chaque validateur qu'il publie une sortie aléatoire vérifiable, et une application ou un contrat peut demander ce nombre lié à son propre identifiant de requête. La documentation le décrit comme une enveloppe scellée dont quiconque possède la clé publique du validateur peut confirmer qu'elle a été décidée avant le début du tour.
La documentation ne survend pas non plus ce qui est effectivement branché. Elle précise que les appels HTTP sortants ne fonctionnent aujourd'hui que pour les applications WASM, que le mode quorum-fetch relève de « la conception cible et n'est pas encore entièrement câblé », et que l'ensemble repose sur un modèle de confiance « testnet v1 ».
Pourquoi les agents en ont besoin, et qui d'autre s'y attelle
L'utilisateur visé est un agent — un programme qui observe, décide et agit sans qu'une personne appuie sur un bouton. Le manifeste publié par Gora le 20 avril développe l'argument opérationnel : un agent qui doit lire depuis Solana, appeler une API, calculer quelque chose puis écrire dans un contrat Algorand est aujourd'hui assemblé à partir de services distincts, « chacun avec ses propres modes de défaillance, chacun contrôlé par une partie différente », et les personnes touchées par l'action d'un agent doivent pouvoir savoir qu'elle s'est produite correctement, « non parce que quelqu'un l'affirme, mais parce que l'exécution est vérifiable de façon indépendante ».
Gora n'est pas le seul à le revendiquer. Les contenus de Chainlink sur l'IA vérifiable décrivent l'acheminement de l'inférence IA à travers un réseau décentralisé de nœuds afin d'éliminer les points de défaillance uniques, et 0G commercialise du calcul vérifié, de la mémoire persistante et du règlement onchain pour les agents sur un mainnet dont son annonce dit qu'il tourne depuis septembre 2025. La différence de Gora tient à son positionnement plutôt qu'à ses capacités : il ne demande pas à un agent de migrer vers une nouvelle chaîne, et la réponse qu'il produit est écrite sur la chaîne où vit déjà le contrat. Sur Algorand, le protocole AC2 de la Fondation, publié le 25 août, traite du problème voisin — permettre à une personne d'approuver les actions d'un agent avec une passkey tout en gardant les clés sur l'appareil —, là où l'équivalent côté utilisateur chez Gora est une demande de signature examinée sur un téléphone. L'ancien tableau de bord du projet liste encore des flux d'oracle, un portail de nœuds et un portail de vesting à côté d'un « taux de rendement actuel » de 10 %, et il renvoie les stakers vers un site de staking distinct dont le pied de page de la liste des validateurs indique « Affichage de la page 1 / 1 (36 résultats) » à côté d'un panneau invitant les détenteurs à « staker leurs $GORA en ERC-20 auprès du validateur de leur choix » et marqué « Bientôt disponible ! » — une chaîne de pagination, et non un décompte des validateurs actifs sur ce réseau ; le réseau d'agents et l'ancienne activité d'oracle cohabitent donc pour l'instant.
Ce que montrent les enregistrements on-chain
Tous les contrats du tableau ont été créés par une seule adresse du testnet Algorand, qui détient aussi la clé de gestion de l'actif GORA de test. Une clé de gestion peut modifier la configuration d'un actif, ce qui constitue le seul point de contrôle conservé dans l'ensemble ; les adresses de gel et de clawback de cet actif sont à zéro, personne ne peut donc geler le solde d'un détenteur ni récupérer ses tokens. Par comparaison, l'actif GORA du mainnet enregistré avec gora.io pour URL a ses champs manager, freeze, clawback et reserve tous non renseignés — plus rien ne peut en émettre ni en saisir. Aucun audit de tout cela n'apparaît dans la documentation ni sur le site, et l'organisation GitHub publique GoraNetwork recense 15 dépôts totalisant 20 étoiles, son dépôt le plus récemment poussé ayant été mis à jour en avril 2025, tandis que des recherches par mots-clés sur le code de validateur du cœur du protocole décrit par la documentation n'ont renvoyé aucun dépôt.
Il y a aussi une étiquette à lire de près. Le journal de diffusion du bridge de développement renvoie 31 événements, et l'objet de preuve de chacun est typé « mock_gora_quorum_v1 », avec un ensemble de validateurs « devnet-mock » et un quorum « mock » — ce sont les propres soumissions de signature mobile du bridge vers Algorand, et le quorum qui les sous-tend est un substitut, non le comité décrit dans la documentation. La liste des validateurs n'est guère plus solide : quatre validateurs sont enregistrés, chacun affiche le statut « Crashed », et les résumés de tours révèlent une participation inégale, l'un des validateurs validant sept tours dans ses cinquante dernières entrées de journal et un autre enregistrant onze échecs. Le poids de vote est lui aussi déséquilibré.
Chart: Poids de vote des quatre validateurs enregistrés sur le testnet de Gora
Sur le testnet partagé, l'identité d'un développeur est un jeton porteur qu'il invente lui-même : le premier jeton à déployer un identifiant d'application en devient propriétaire, et lui seul peut mettre à niveau l'application, gérer ses planifications ou lire son état, ce qui fait de la propriété le secret d'une chaîne de caractères que vous avez choisie. Les interfaces en ligne se tiennent d'ailleurs à l'écart du domaine du projet — la documentation est hébergée sur gora.mintlify.app, le point de terminaison du nœud est une adresse IP nue atteinte via le DNS à joker nip.io, www.gora.io/docs renvoie une 404 et docs.gora.io ne résout pas —, tandis que la page d'accueil affiche encore « ARRIVE LE 05/01 » et « Lancement imminent » au-dessus d'un réseau dont les points de terminaison répondent déjà ; une capture Wayback du 10 mai 2026 porte la même formulation.
Deux points que ce passage n'a pas permis de confirmer. La documentation affirme que les applications iOS et Android « sont livrées préconfigurées avec le bridge en production », mais des recherches sur l'App Store pour Gora Network, Goracle et Gora wallet n'ont renvoyé que des applications sans rapport, on ignore donc si un client mobile est installable aujourd'hui ; la boîte de réception de signature mobile du bridge renvoie bien quatre requêtes, dont des entrées de loterie signées, donc le flux tourne depuis un endroit ou un autre. Et sur le mainnet Algorand, le plus grand pool listé de l'actif GORA sur Tinyman contenait environ 3,100 $ et affichait moins de 2 $ de volume en 24 heures au moment de la vérification.
Comment démarrer, et ce qu'il faut surveiller
Un développeur n'a besoin ni d'inscription ni de GORA pour entrer : une seule commande curl installe la CLI, vous définissez un jeton de développeur de votre choix, vous pointez vers le point de terminaison et vous déployez ; le déploiement et l'invocation sont gratuits sur le testnet, et une invocation consomme environ 106 unités de facturation sur un solde de développeur préalimenté. Les binaires de nœud pour macOS et Linux sont sur le miroir de versions du point de terminaison en v0.1.1, et les applications Algorand de passerelle, de staking et de loterie sont déjà déployées pour qu'un contrat puisse leur parler.
Pour tous les autres, le fonds et la loterie sont les deux portes accessibles dans un navigateur, toutes deux sur testnet et gratuites à consulter. Le serveur Discord de Gora, où la loterie annonce que les gagnants sont proclamés, affichait 19,816 membres dont 202 en ligne au moment de la vérification, tandis que le canal Telegram du projet, @goranetwork, compte 274 membres et n'a rien publié depuis juin 2024. Ce qu'il faut surveiller, c'est de savoir si la page d'accueil du projet rattrapera le réseau qu'il décrit désormais, et si les quatre validateurs cesseront d'afficher « Crashed ». Le prochain tirage de la loterie est le paiement le plus facile à suivre de bout en bout : trois utilisateurs inscrits, payés depuis une cagnotte dont les règles tiennent dans un contrat.
Source
- gora.io
- github.com
- Custom Blockchain Oracle Solutions | Gora Network
- Gora Website
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- gora-bridge.74.241.248.103.nip.io
- Devnet quickstart - Gora Docs
- Raffle App - Gora Docs
Source: https://gora.io/