Déployer un jeton RPL

Cette page fait passer un jeton de rien à un actif vivant et transférable sur Rand. RPL est le standard de jeton de Rand, nouveau sur la chain 14. Si vous avez déjà déployé un ERC-20 ou créé un mint SPL, la première section est celle à lire lentement, car un jeton RPL n’est ni l’un ni l’autre. Jetons RPL est la page de concepts qui sous-tend celle-ci.

1. Ce qu’est un jeton RPL

Un jeton RPL est une entrée dans le registre des jetons du ledger, et non un smart contract. Il n’y a aucun code à écrire, compiler ou auditer. Créer un jeton est une seule transaction qui ajoute une ligne au registre ; dès lors, les unités du jeton sont des notes protégées ordinaires, détenues dans le même pool que RAND et dépensées de la même façon.

Les symboles ne sont pas uniques. N’importe qui peut créer un jeton nommé USDC, exactement comme sur Ethereum et Solana. L’identité d’un jeton est son identifiant d’actif : vérifiez l’identifiant rpl1… avant d’accepter ou de référencer un jeton, jamais le symbole. La forme textuelle comporte une somme de contrôle : un identifiant mal saisi est refusé, et non envoyé ailleurs.

En quoi il diffère d’ERC-20 et de SPL

Ce qui reste public, c’est la frontière : l’enregistrement d’un jeton, chaque émission et chaque destruction, avec leur montant. C’est ce qui rend l’offre totale auditable par tous. Les transferts entre détenteurs ne révèlent rien, pas même quel jeton a été déplacé.

2. Avant de commencer

rand --key wallet.key.json keygen     # writes the spend key; refuses to overwrite
rand --key wallet.key.json address    # your rand1… address
rand --key wallet.key.json faucet     # testnet only, allowlisted wallets only: asks a validator node to mint 100 RAND to this wallet
rand --key wallet.key.json balance    # scans the tree, prints the spendable value and the unspent note count

--key vaut par défaut wallet.key.json et peut être défini une fois pour toutes via RAND_KEY ; --rpc (ou RAND_RPC) désigne le nœud auquel parler et vaut par défaut http://127.0.0.1:8545. Les commandes ci-dessous écrivent --key explicitement. Avant de dépenser une preuve, vérifiez que le nœud est sur la chain 20 : la méthode JSON-RPC rand_chainId y renvoie 20. Le wallet doit être une build chain 20, v0.6.8 : la chain 20 lie chaque preuve et chaque message signé, y compris celui d’une émission de jeton, à son hash de genesis ; un rand v0.6.7 produit donc des preuves et des signatures que la chain 20 refuse.

3. Créer le jeton

token create prend ses montants dans la plus petite unité du jeton. --fixed-supply et --initial sont des nombres entiers d’unités de base : avec --decimals 2, un montant de 1000000 vaut 10 000,00 jetons. Chaque commande suivante (rand send --asset, rand token mint, rand token burn) prend les unités d’affichage du jeton depuis la v0.5.10, comme les montants en RAND sont exprimés en RAND (1.5) : le wallet lit decimals dans la ligne de registre du jeton, et un nombre de chiffres fractionnaires supérieur à celui du jeton est refusé. Sur la chaîne, un montant est toujours l’entier en unités de base.

Décidez d’abord d’une chose : peut-on jamais émettre davantage d’unités ? La réponse est fixée dans le jeton à sa création et ne peut pas être élargie ensuite.

Un jeton à offre fixe

rand --key wallet.key.json token create \
  --name "Example Credits" \
  --symbol EXC \
  --decimals 2 \
  --fixed-supply 1000000 \
  --to rand1…

--to est l’adresse rand1… complète qui reçoit l’offre, par exemple la sortie de rand address. --fixed-supply est en unités de base : 1000000 avec 2 décimales fait 10 000,00 EXC.

La commande lit auprès du nœud l’index suivant du registre et les frais d’enregistrement, construit la note de l’émission initiale, prouve un bundle de frais, soumet l’enregistrement et attend le bloc. En cas de succès, elle rapporte la soumission, puis affiche une ligne de la forme index <N>, id <64 hex> (<rpl1…>), puis committed at height <H>. Notez l’identifiant rpl1… : c’est l’identité du jeton, et chaque commande suivante le prend en paramètre.

Les frais par défaut sont la base plus les frais d’enregistrement de la chaîne, soit 1,001 RAND sur la chain 20 ; il n’y a donc rien à calculer ; --fee (en RAND) les augmente. --no-wait rend la main dès que la transaction est soumise et omet la ligne committed. --cuda prouve sur un GPU NVIDIA connecté, exige une build avec --features cuda et ne bascule pas sur le CPU.

Si un autre jeton est enregistré pendant que le vôtre est en cours de preuve, il prend l’index pour lequel le vôtre avait été scellé. Le nœud refuse l’enregistrement et la commande affiche another token took index N first — re-run to register at N+1, avec les vrais numéros. Un enregistrement refusé n’atteint jamais un bloc ; ce qui est perdu, c’est la preuve, soit environ 100 secondes de calcul. Relancez la commande et elle prouve contre l’index suivant.

Toute l’offre se trouve désormais dans une seule note protégée détenue par l’adresse --to. L’enregistrement et son montant sont publics ; ce que le destinataire fait ensuite de la note ne l’est pas.

Un jeton émissible

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json

Cela écrit une nouvelle clé Dilithium2 dans exp-authority.key.json (mode 0600, sans jamais écraser un fichier existant) et enregistre le jeton avec cette clé comme autorité de mint et une offre de zéro. La sortie est la même, en deux lignes, que pour un jeton à offre fixe. Exactement une des options --fixed-supply et --authority-key-out doit être fournie.

Pour frapper un premier montant dans la même transaction, ajoutez --initial et --to, qui doivent être fournis ensemble :

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json \
  --initial 5000 \
  --to rand1…

Tant que l’enregistrement est en cours, la clé se trouve dans exp-authority.key.json.pending. Elle est promue en exp-authority.key.json dès que la chaîne accepte l’enregistrement, et supprimée si la chaîne le refuse. Si la connexion échoue sans que l’issue soit connue, le fichier reste en .pending : vérifiez avec rand token list avant de le supprimer.

Le fichier de clé est le pouvoir d’imprimer le jeton. Gardez-le hors ligne et sauvegardé ; il est distinct de la clé de dépense de votre portefeuille et n’est jamais nécessaire pour envoyer ou recevoir.

Pourquoi le destinataire du premier mint fait partie de l’identifiant

Un enregistrement n’est pas signé par son créateur. Quiconque voit le vôtre en attente dans le mempool peut en soumettre une copie, payée avec son propre lot de frais. Si l’identifiant d’actif ne couvrait que le nom, le symbole et le montant, cette copie pourrait désigner l’adresse du copieur comme destinataire et atteindre un bloc en premier : il posséderait l’identifiant et, pour un jeton à offre fixe, toute l’offre à jamais.

L’identifiant est donc un hachage de tout ce que contient l’enregistrement, mint initial compris : son montant, son destinataire, son aléa, son horodatage et son enveloppe chiffrée. Une copie avec un autre destinataire produit un identifiant d’actif différent. C’est un autre jeton qui se trouve partager votre symbole, ce que n’a jamais promis davantage un symbole non unique. Votre identifiant ne peut être enregistré qu’avec votre destinataire.

--salt <hex32> fixe le sel de 32 octets qui entre aussi dans l’identifiant. Si vous l’omettez, le portefeuille en tire un au hasard. Fixez-le lorsque l’identifiant doit être reproductible, par exemple pour publier l’identifiant avant que le jeton n’existe.

Le vérifier

rand token info rpl1…          # by id: rpl1… or 64 hex characters
rand token info 2              # or by the index `token create` printed
rand token list --limit 20     # one page of the registry; --from <index> pages on

token info affiche la ligne du jeton en JSON : index, id, id_text (la forme rpl1…), name, symbol, decimals, authority, mint_nonce, total_supply et registered_at. authority vaut {"kind":"none"} pour un jeton à offre fixe et {"kind":"key","key":…,"address":…} pour un jeton mintable. total_supply est une chaîne décimale en unités de base. token list affiche enabled, registration_fee, next_index et les lignes tokens. Les deux lisent la liste complète du nœud, de sorte que le nœud n’apprend pas quel jeton vous intéressait.

Ou via JSON-RPC, où le paramètre peut être l’index, l’identifiant hexadécimal de 64 caractères ou la forme rpl1… :

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1,
  "method": "rand_getToken",
  "params": ["rpl1…"]
}'

Le résultat est la même ligne qu’affiche token info, ou null si aucun jeton de ce type n’existe ; un identifiant malformé (somme de contrôle erronée, casse mélangée, longueur incorrecte) produit l’erreur -32602. rand_getTokens prend [from_index, limit] et parcourt page par page tous les jetons enregistrés, et rand_getTokenSupply renvoie seulement { total_supply, backings }. Aucune de ces méthodes ne nécessite de clé. Voir JSON-RPC.

Une ligne qui existe aujourd’hui sur la chaîne 20 est zUSD, le jeton ponté à l’index 1. L’explorateur sert le registre du nœud sans que vous ayez besoin de votre propre nœud :

curl -s https://randscan.org/api/v1/tokens

Sur la chaîne 14, le 2026-09-20, cela renvoyait "registration_fee": 1000000000, "next_index": 2 et un seul jeton, abrégé ici à son premier backing :

{
  "index": 1,
  "id": "32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f",
  "id_text": "rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx",
  "name": "Shielded USD",
  "symbol": "zUSD",
  "decimals": 8,
  "authority": {
    "kind": "bridge",
    "backings": [
      { "chain": 2, "token": "000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
        "decimals": 6, "locked": "0", "minted_today": "0", "mint_day": 20716,
        "mint_cap_per_day": "10000000000000" }
    ]
  },
  "mint_nonce": 0,
  "total_supply": "0",
  "registered_at": 256
}

Sur la chaîne 20, la ligne a les mêmes id, id_text, nom, symbole et backings, mais zUSD figure dans la genèse au lieu d’être enregistré à la hauteur 256 (registered_at 0), et son offre a démarré à 99 zUSD : 22 verrouillés sur Ethereum USDT, 22 sur BSC USDT, 30 sur Tron USDT et 25 sur Solana USDT, reportés depuis la chaîne 19. (Celle de la chaîne 19 a démarré à 10 zUSD, tous sur Solana ; celle de la chaîne 18 à 9 sur Tron et 1 sur Solana.) Chaque ligne de backing porte aussi les champs de fenêtre glissante minted_in_window, mint_window_secs et mint_headroom.

La copie de registration_fee de l’explorateur est un nombre JSON ; le RPC du nœud le renvoie, comme tout montant, sous forme de chaîne décimale. Sur la chaîne 20, comme sur toutes les chaînes depuis la 15, le rand_getTokens du nœud porte aussi max_tokens (4096), burn_registration_fee et bound_note_value (tous deux true) (jetons RPL).

4. Frapper, et transmettre l’autorité

Seul un jeton doté d’une autorité Key peut être frappé, et seulement par cette clé.

rand --key wallet.key.json token mint \
  --asset rpl1… \
  --to rand1… \
  --amount 5000 \
  --authority-key exp-authority.key.json

--amount est exprimé en unités d’affichage du jeton : 5000 de ce jeton à 0 décimale correspond à 5 000 unités de base, et 1.5 d’un jeton à 6 décimales correspondrait à 1 500 000. Avant de construire une note ou une preuve, le portefeuille lit la ligne du jeton et refuse si le jeton n’est pas autorisé par Key ou si --authority-key n’est pas la clé que désigne le registre. En cas de succès, il rapporte la soumission et affiche minted <amount> (<base units> units) of asset <index> to <address>. --fee (0,001 RAND par défaut), --no-wait et --cuda fonctionnent comme pour token create.

Un mint ajoute une note pour le destinataire et augmente l’offre totale. Le montant et la clé publique du destinataire figurent sur le réseau : un mint est un événement public par conception, au même titre qu’un dépôt via le pont. Dès que le destinataire déplace la note, elle est protégée comme tout le reste. Le portefeuille qui paie les frais (--key) et la clé qui autorise le mint (--authority-key) sont deux clés distinctes, qui peuvent être détenues par des personnes différentes.

Chaque mint est signé sur l’identifiant de chaîne, l’identifiant d’actif et un compteur que tient le registre, et, sur la chaîne 20, aussi sur le hachage de genèse (rand-rpl-mint-2), de sorte qu’un mint ne peut être rejoué sur cette chaîne ni copié vers une autre, même une qui partage le même identifiant de chaîne. set-authority est lié de la même manière.

Pour transférer l’autorité à une nouvelle clé, ou y renoncer définitivement :

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --new-key next-authority.key.json

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --renounce

--new-key prend un fichier de clé et remet le jeton à la clé publique de ce fichier ; exactement une des options --new-key et --renounce doit être fournie. La commande affiche asset <index>'s mint authority is now <public key hex>, ou asset <index>'s mint authority is renounced for good. Chacune coûte la base de 0,001 RAND et un tour de preuve. --renounce transforme le jeton en jeton à offre fixe, à son offre actuelle. L’opération est irréversible : une autorité peut passer d’une clé à une autre ou d’une clé à personne, et rien d’autre. Un jeton créé avec une offre fixe ne peut jamais devenir mintable.

5. L’utiliser

Envoyer

rand --key wallet.key.json send rand1… 250 --asset rpl1…

Cela envoie 250 unités du jeton en unités d’affichage : 250 EXP à 0 décimale, ou 250,00 EXC (25 000 unités de base) à 2. Le destinataire et le montant sont positionnels, comme pour RAND. Avant toute preuve, le portefeuille affiche une ligne, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), et demande send? [y/N]. Comparez l’empreinte à celle du destinataire et les unités de base à ce que vous aviez prévu. --yes saute la question, et un script doit le passer : sans lui, une entrée standard qui n’est pas un terminal est refusée. --asset accepte l’index, l’identifiant rpl1… ou l’identifiant hexadécimal de 64 caractères, et son omission envoie du RAND. --memo <text> scelle jusqu’à 510 octets de texte pour le destinataire dans l’enveloppe du paiement, ce que la chaîne 18 est la première à autoriser ; rien sur la chaîne ne montre qu’un mémo est présent. --fee est toujours en RAND et vaut 0,001 par défaut ; --no-wait et --cuda s’appliquent. Un identifiant est résolu en index à partir de la liste complète du registre du nœud, et un index numérique n’atteint jamais le nœud, de sorte que le nœud ne sait pas quel jeton est sur le point de bouger. C’est le même rand send qui déplace du RAND, avec la même preuve. La transaction publie quatre nullifiers, quatre engagements, des frais en RAND, un horodatage, quatre enveloppes chiffrées, la preuve du lot et, depuis la chaîne 17, un engagement d’autorisation et sa preuve, quel que soit l’actif déplacé. Un observateur ne peut distinguer un transfert de jeton d’un paiement en RAND, ne peut dire de quel jeton il s’agit, et ne voit ni expéditeur, ni destinataire, ni montant.

Les frais sont payés en RAND depuis le même lot : le portefeuille expéditeur doit donc détenir du RAND. Le portefeuille le vérifie avant de commencer la preuve.

Consulter un solde

rand --key wallet.key.json asset-balance 2     # one token, by index
rand --key wallet.key.json asset-balance       # a row for every token this wallet holds

L’argument est un index du registre. Pour un jeton, le portefeuille affiche asset <index> balance: <N> units, en unités de base. rand notes liste chaque note que le portefeuille a ouverte, avec son index asset. Le portefeuille retrouve ses notes en parcourant la chaîne avec sa clé de visualisation. Rien sur la chaîne ne détient de solde qu’il pourrait consulter.

Brûler

rand --key wallet.key.json token burn rpl1… 100

L’actif et le montant sont positionnels : l’actif sous forme d’index, de rpl1… ou d’hexadécimal, le montant en unités d’affichage du jeton, tel que send --asset le lit. --fee vaut 0,001 RAND par défaut ; --no-wait et --cuda s’appliquent.

Une combustion détruit des unités et réduit l’offre totale. Comme un mint, c’est une frontière publique : le montant et le jeton sont visibles, le détenteur ne l’est pas. Un jeton ponté tel que zUSD n’est pas brûlé de cette façon : token burn le refuse avant la preuve, et il sort par rand bridge-burn, qui libère la pièce qui le garantit.

6. Le vérifier sur l’explorateur

randscan.org montre à tous le côté public d’un token : son enregistrement, ses émissions et ses destructions, ainsi que son offre totale. Chaque token est listé sur randscan.org/tokens, et la page d’un token est /tokens/<rpl1…>, /tokens/<64 hex> ou /tokens/<index> ; randscan.org/tokens/1 est zUSD. Les mêmes données sont disponibles à GET /api/v1/tokens et GET /api/v1/tokens/:id, la seconde avec la transaction de déploiement du token et l’historique de son offre, composé de l’enregistrement, des émissions et des destructions (API de l’explorateur).

La page publique d’un transfert ne montre aucun actif, aucun montant et aucune partie, car la chaîne ne les possède pas. Pour prouver un paiement à un tiers, comme un auditeur, une contrepartie ou une plateforme d’échange, remettez-lui une clé :

rand --key wallet.key.json tx-key <TX_HASH>    # the keys for one transaction
rand --key wallet.key.json viewing-key         # the wallet's viewing key, 64 hex characters

tx-key affiche une ligne par sortie de cette transaction que ce portefeuille a envoyée, reçue ou conservée comme monnaie rendue : la sortie (bundle:0 à bundle:3, les quatre emplacements du bundle), le rôle, le montant (en RAND, ou N (asset I) pour un token) et la clé propre à la transaction sous laquelle cette sortie a été scellée. Remettez la clé de la ligne sent. Elle fonctionne pour toute transaction passée, car le portefeuille retrouve la clé à partir de la chaîne.

Collez une clé de transaction dans la page de la transaction sur randscan pour ouvrir cette sortie ; l’explorateur résout l’indice de l’actif dans le registre et affiche le token par son nom, avec ses décimales appliquées. Une clé de visualisation se saisit sur randscan.org/viewing. L’explorateur ne détient aucune clé et ne déchiffre rien sur son serveur. Via JSON-RPC, la même divulgation est rand_checkTransaction(hash, key). Aucune des deux clés ne permet de dépenser quoi que ce soit. Une clé de visualisation ne peut pas être reprise une fois partagée ; privilégiez donc une clé de transaction lorsqu’il suffit de prouver un seul paiement.

7. Tokens bridgés

zUSD (« Shielded USD ») est aussi un token RPL, avec une autorité Bridge : ses unités ne sont émises que lorsque des gardiens attestent un dépôt d’USDT ou d’USDC sur Ethereum, Binance Smart Chain, Tron ou Solana, et son offre est toujours égale à ce qui y est verrouillé. Il a été enregistré sur la chaîne 14 par une transaction à la hauteur 256, à l’indice 1, avec sept collatéralisations, et le genesis de chaque chaîne depuis, chaîne 20 comprise, le liste de nouveau sous le même identifiant, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. La chaîne 15 a repris les 10 zUSD encore en circulation à l’arrêt de la chaîne 14, les chaînes 16 à 19 ont démarré avec ces mêmes 10 zUSD, et la chaîne 20 a démarré avec les 99 zUSD en circulation sur la chaîne 19. Sur la chaîne 20, le bridge prélève 10 bps sur chaque dépôt et chaque rachat, en zUSD, vers une note de trésorerie (Bridge). zUSD est un panier : ses collatéralisations sont mises en commun à leur valeur nominale, de sorte qu’un détenteur supporte le risque de chaque pièce listée, et pas seulement celui de celle qu’il a déposée (Tokens RPL). Son offre évolue à chaque dépôt et à chaque rachat ; rand token info 1 ou la page /tokens/1 de l’explorateur donne le chiffre courant.

Son parcours sur la chaîne 14, un testnet antérieur (vérifié sur l’explorateur le 2026-09-20). Ce tableau retrace l’historique de la chaîne 14 : celle-ci est retirée, ces transactions ne figurent donc pas dans l’explorateur de la chaîne 20 :

La page du transfert montrait ce que montre tout transfert de token : quatre nullifiers, quatre engagements et des frais, et rien qui indique qu’un zUSD a circulé.

Pour montrer ce qu’une clé divulgue, les notes de version v0.5 du fullnode en ont publié deux pour ce transfert de la chaîne 14, issues d’un portefeuille de démonstration créé à cet effet et qui ne contient rien d’autre :

Sur la chaîne 14, la clé de transaction ouvrait cette sortie sur la page du transfert, et via JSON-RPC il suffisait d’un appel (vérifié le 2026-09-20). L’appel a la même forme sur la chaîne 20 pour une transaction qui vous appartient ; avec ces valeurs de la chaîne 14, un nœud de la chaîne 20 répond null (vérifié le 2026-10-01), puisqu’il n’a jamais détenu cette transaction :

curl -s https://rpc.randprotocol.org -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "rand_checkTransaction",
  "params": ["e6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed",
             "7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4ef"] }'

Ne publiez jamais la clé de visualisation d’un portefeuille que vous utilisez : elle montre définitivement tout l’historique de ce portefeuille.

Une adresse ordinaire ne peut pas créer de token bridgé. rand token create refuse une autorité Bridge, et enregistrer un token bridgé, ou ajouter une pièce derrière un token existant, exige un quorum signé de l’ensemble de gardiens post-quantique du bridge. Un token qui se nomme zUSD sans cela n’est qu’un token de plus avec un symbole emprunté, ce qui est une raison de plus de vérifier l’identifiant rpl1…. Les tokens bridgés ont toujours 8 décimales sur Rand.

Bridge couvre les dépôts, les rachats et l’ensemble de gardiens.