Avec Smart ASA v2, le gel d'un jeton Algorand échappe désormais à son détenteur

Un jeton peut désormais être gelé avant même que son détenteur en possède une seule unité, et le gel subsiste une fois que celui-ci s'est retiré. C'est là le changement apporté par Smart ASA v2, l'implémentation de référence reconstruite du standard ARC-20 d'Algorand, publiée le 23 octobre.

Le jeton avec un contrat au milieu

Un ASA est le jeton natif d'Algorand. Il se crée en une seule transaction et se détient par opt-in. Son nom, son unité, ses décimales et son offre maximale sont fixés à la création. Ses quatre rôles sont rattachés à des adresses, et aucun point d'accroche ne permet à une règle propre à l'émetteur de s'exécuter lors d'un transfert entre deux détenteurs.

La méthode ancienne pour faire respecter une règle consistait à geler l'actif et à faire transiter les unités par clawback, ce qui apparaît au détenteur comme une saisie là où il attendait un transfert. ARC-20 conserve le jeton natif et confie les quatre rôles à un contrat. L'actif est créé gelé par défaut, si bien que les unités n'atteignent un détenteur que par l'intermédiaire du contrat, et que chaque mouvement est vérifié au préalable.

ARC-20 est ainsi l'exact miroir d'ARC-200¹, l'autre standard de jeton-contract d'Algorand, où le jeton est le contrat lui-même et se comporte comme un jeton Ethereum avec soldes et approbations. ARC-20 garde l'actif natif, de sorte que les portefeuilles et les plateformes d'échange le détiennent comme n'importe quel autre jeton, et place le règlement par-dessus.

Ce que change la version 2

Les gels de compte quittent le stockage propre au détenteur pour des boxes vides détenues par le contrat. Dans l'ancienne conception, l'indicateur résidait dans l'état local du compte, et le détenteur pouvait le lever. La spécification² indique désormais que l'état stocké en box ne peut être supprimé par le détenteur, et que celui-ci n'a même plus besoin de s'inscrire au contrat. Son solde bloqué passe de 0,2285 à 0,1³ ALGO.

Certaines limites demeurent. Un gel peut être posé sur une adresse avant qu'elle ne détienne quoi que ce soit, ce dont une liste de sanctions a besoin, et il survit au départ puis au retour du détenteur. Le premier gel sur un compte crée une box. Elle est financée par un dépôt de 0,0157⁴ ALGO versé au contrat juste avant l'appel de gel et remboursé lorsque le compte revient à son état par défaut.

Le bénéfice est étroit et bien réel : un émetteur peut faire respecter une règle à un détenteur qui ne coopère pas, tandis que le plafond d'offre et la logique de versement résident dans un état public que chacun peut consulter. Savoir s'il s'agit d'un avantage dépend du côté du gel où l'on se trouve.

Le reste relève de l'entretien, mais un entretien qui compte. La version précédente, publiée trois jours plus tôt, encodait les arguments d'actif et de compte comme de simples entiers et adresses, si bien que « ses sélecteurs de méthode ne correspondaient pas à l'interface ARC-20⁵ ». La version 2 recourt aux types propres au standard et demande aux clients de les régénérer. Les appels échoués consignent désormais des codes d'erreur ARC-65, ce qui permet à un portefeuille de nommer la raison au lieu d'afficher un message d'assertion. Deux points d'extension permettent à un émetteur d'ajouter des contrôles aux transferts ordinaires et de définir l'offre en circulation, avec un exemple plafonné dans le dépôt.

Les gels se superposent. Un gel global arrête les transferts et un gel de compte bloque un seul détenteur ; les notes de version précisent qu'aucun des deux ne bloque jamais un clawback, et que les rôles détenus chacun par une adresse agissent selon leurs propres règles.

Ce qu'il faut pour l'utiliser

Déployer l'ensemble suppose de déployer un contrat et de créer un actif, puis de payer des frais à chaque action. La liste de migration de la publication chiffre l'émission, le remboursement, le clawback, le transfert ordinaire et la réinitialisation d'un gel à deux fois les frais minimaux. La destruction d'un jeton coûte trois fois ce montant. Chaque compte gelé immobilise en outre un dépôt de 0,0157⁶ ALGO dans le contrat, restitué à la réinitialisation.

La voie de développement passe par AlgoKit, Poetry et un réseau local sous Docker, le tout depuis le dépôt⁷. Aucun service hébergé, aucune inscription.

Il n'y a pas davantage de quoi s'ouvrir pour un utilisateur ordinaire. La section TestNet de la publication décrit une démonstration de cinq standards, mais ne nomme aucune application ni aucun actif, contrairement aux notes de la version précédente trois jours auparavant. Un développeur peut lire le code et le déployer en local ; un lecteur en quête d'un jeton version 2 en production n'a nulle part où aller.

La variante la plus complète s'appuie sur ARC-89, le registre de métadonnées, que son propre registre d'adoption donne comme déployé sur TestNet et en attente d'un déploiement sur MainNet. La dernière version de ce registre se présente comme la première release candidate pour le déploiement MainNet. Tant qu'elle n'est pas arrivée, la variante complète reste un travail sur TestNet.

Qui le construit

Cosimo Bassi, qui publie sous le nom de cusma⁸, a rédigé la spécification ARC-20. Il maintient cette implémentation et a écrit le registre de métadonnées sur lequel elle s'appuie. Le dépôt relève de l'Algorand Foundation, et sa liste de versions situe la précédente au 20 octobre et celle-ci au 23 octobre. Le jour de la publication, il a sollicité les retours des émetteurs, des portefeuilles et des explorateurs.

Une implémentation antérieure, hébergée à algorandlabs/smart-asa⁹, remplissait la même fonction depuis 2022. Elle liait le jeton à son contrat en inscrivant le numéro du contrat dans le champ URL du jeton et conservait l'indicateur de gel de chaque détenteur dans l'état local. La version 2 remplace ce dispositif, et c'est l'ancien que suivent encore les jetons en production.

L'unique utilisateur en production

Le fichier d'adoption d'ARC-20 recense exactement un projet, enel-ebitts, avec une maturité marquée comme faible et les colonnes portefeuilles, explorateurs et outillage vides. ebitts est le service d'Enel et Conio qui vend aux foyers italiens des jetons adossés à la production de deux centrales renouvelables et impute cette production sur la facture d'électricité ; PXke a couvert son lancement en octobre.

Chaque centrale a son propre jeton, nommé d'après elle : ebitts Barile Venosa, ticker EBT-BVEN, et ebitts Piani della Marina, EBT-PDM.¹⁰ Les deux sont sur le mainnet Algorand depuis mai 2026.¹¹ Les quatre rôles du jeton éolien sont rattachés au compte que détient son propre contrat, et non à la clé d'une personne, si bien que chaque mouvement passe par ce contrat. À l'intérieur du contrat, ces quatre rôles sont assignés à un unique portefeuille. Les jetons portent dans leur champ URL l'ancien mode de liaison. Leurs contrats pointent en outre vers une application de versement, un jeton de récompense et une application d'identité, ce que ne fait pas le contrat de cette publication. Ils répondent à la même interface qu'une construction sur mesure, non à une copie de la version 2.

Ils sont bien vivants. Depuis le 4 mai, le contrat du jeton éolien a émis environ 1 830¹² transferts vers près de 370¹³ portefeuilles, dont 475¹⁴ sur les trente jours précédant le 26 octobre, tous depuis une seule adresse : il s'agit donc de distributions sorties du contrat, et non d'échanges entre détenteurs. Aucun des deux jetons ne se négocie.

La quasi-totalité des deux offres reste entre les mains d'un seul portefeuille. C'est lui qui a créé les deux contrats. L'état stocké de chaque contrat le désigne comme manager, réserve, gel et clawback. Il détient environ 97,7¹⁵ % du jeton éolien et environ 99,8¹⁶ % du jeton solaire.

Le lien de preuve du fichier d'adoption ouvre un autre jeton de la même famille, dont le contrat s'appelle REWARD et stocke deux décimales, et non l'un ou l'autre des jetons de centrale. Le registre montre que la famille existe ; il ne prouve pas à lui seul que les unités détenues par les foyers sont conformes.

Ce qui peut mal tourner

La publication dit deux choses d'elle-même. Elle invite les déployeurs à repartir d'un nouveau contrat, car les applications de la version précédente ne peuvent pas être mises à jour sur place. Et le code n'a pas été audité.

Le reste repose sur l'émetteur, et la spécification le dit. Les règles ne tiennent que tant que le jeton reste gelé par défaut, que son adresse de clawback reste celle du contrat et que ce contrat ne peut être mis à jour, supprimé ni rekeyé. Son texte révisé mentionne deux échappatoires. L'adresse de gel de l'actif peut dégeler les avoirs, et son adresse de manager peut changer le clawback, sauf si l'une ou l'autre est fixée au contrat ou laissée vide.

Un détenteur peut être induit en erreur par son propre portefeuille. L'actif sous-jacent affiche toujours zéro décimale et une offre maximale de remplissage, quelle que soit la configuration choisie par l'émetteur, et les portefeuilles qui ne comprennent pas ARC-20 affichent cela au lieu de la configuration réelle.

La documentation dérive elle aussi. Le dépôt a fait passer sa règle de métadonnées de « doit être immuable » à « devrait être immuable » le jour même de la publication, et la copie du portail développeur indique toujours « doit », et décrit encore l'état de gel comme résidant dans le stockage local du détenteur. Qui consulte le portail lit la version que cette publication a remplacée.

Une réponse à l'annonce demandait simplement à quoi pourrait bien servir un smart ASA. Le seul exemple qui fonctionne au dossier est une facture d'électricité en Italie, et il tourne sur une construction antérieure.