Émettre un jeton
Tout compte peut créer son propre jeton sur ZooBC avec une seule transaction IssueToken. Il n’y a pas de contrat à écrire ni d’autorisation à demander : les règles fixes de la chaîne décident si la transaction est valide, et une fois qu’un bloc l’a incluse, le jeton existe et l’émetteur détient la totalité de son offre. Les unités du jeton circulent ensuite avec TransferToken et peuvent être placées dans des séquestres, des flux de paiement, des transferts programmés et des offres d’échange, ainsi que, avec 8 décimales, dans des ordres sur un marché.
La transaction IssueToken
Un IssueToken (type 10) indique :
| Champ | Règle | |
|---|---|---|
| décimales | 0 à 8 (voir [[token-decimals | les décimales et le pas]]) |
| options (flags) | remboursable, et le mode de frappe (plus bas) | |
| offre totale | supérieure à 0, et multiple du pas du jeton | |
| réserve en ZBC | 0 ou plus | |
| symbole | 2 à 10 caractères (plus bas) | |
| nom | 1 à 64 octets (plus bas) | |
| paiement de survie | facultatif (voir [[token-upkeep | l’entretien du jeton]]) |
Les options sont des bits. Le bit 0 rend le jeton remboursable. Les bits 1 et 2 fixent le mode de frappe : 0 pour une offre fixe, 1 pour un jeton frappable ; les valeurs 2 et 3 sont refusées. Le bit 3, « unbacked » (sans réserve), est enregistré et signalé, mais aucune règle ne le lit. Ce que permettent ces deux options est expliqué dans l’article sur la frappe et le brûlage.
Un jeton émis par un membre d’un groupe de comptes appartient au groupe.
La réserve
La réserve, ce sont de vrais ZBC que l’émetteur place dans le jeton. Ils quittent le solde de l’émetteur et sont détenus par le jeton lui-même, sur le compte de personne ; un nœud refuse une réserve que l’émetteur ne détient pas. Les ZBC n’en ressortent que de trois façons :
- vers les détenteurs qui brûlent des unités d’un jeton remboursable ;
- sous forme de ZBC libérés lorsque des frais sont payés dans le jeton (plus bas) ;
- vers les détenteurs, lorsque le jeton expire (voir l’entretien du jeton).
L’id du jeton
L’id d’un jeton utilisateur est constitué des 8 premiers octets du hachage de sa transaction IssueToken, lus comme un entier signé de 64 bits en petit-boutiste (little-endian), ou 1 si ce nombre vaut 0. C’est donc l’id propre de la transaction d’émission (voir la signature d’une transaction). L’id est connu dès que la transaction est signée, et les nœuds n’ont jamais à s’accorder sur un compteur. L’API affiche les ids sous forme de chaînes décimales signées : un id peut donc être négatif.
Les symboles ne sont pas uniques : deux jetons vivants peuvent avoir le même, et n’importe qui peut copier un symbole qui n’est ni réservé ni bloqué. Les portefeuilles et les applis devraient afficher et vérifier l’id, pas seulement le symbole (voir les données de la chaîne non fiables).
Règles du symbole et du nom
Un symbole compte de 2 à 10 caractères, chacun étant une lettre majuscule de A à Z ou un chiffre de 0 à 9. Cela exclut les minuscules, ainsi que les lettres ressemblantes d’autres alphabets. Deux autres règles protègent les noms bien connus :
- Réservés : les symboles de 4 ou 5 caractères qui commencent ou finissent par Z, comme ZBTC ou BTCZ, appartiennent à l’espace de noms du pont. Un symbole de 6 caractères comme ZABCDE est autorisé.
- Bloqués : une liste intégrée de 78 codes bien connus que personne ne peut usurper : 17 devises (comme USD, EUR, CNY et JPY), 18 stablecoins (comme USDT, USDC et DAI) et 43 grandes cryptomonnaies (comme BTC, ETH, BNB, SOL, XRP, ADA et DOGE).
Un nom compte de 1 à 64 octets d’UTF-8 valide. Il ne peut contenir ni les caractères <, >, " et ', ni l’accent grave (backtick) ; il ne peut contenir aucun caractère de contrôle, de largeur nulle ou modifiant le sens d’écriture, ni aucune espace autre que l’espace ordinaire ; et il ne peut ni commencer ni finir par une espace.
Déplacer des unités : TransferToken
Un TransferToken (type 11) porte l’id du jeton, un montant multiple du pas, un destinataire, une option facultative pour payer les frais dans le jeton, et un paiement de survie facultatif. L’id de jeton 0 est refusé : le ZBC n’est pas un jeton, et il circule avec SendZBC. Un transfert de plus d’unités que l’expéditeur n’en détient est une opération nulle payante : il paie ses frais et ne déplace rien.
Les transferts de jetons peuvent aussi passer par un séquestre (voir le séquestre ; les frais sont alors payés en ZBC), par un flux (voir les paiements liquides) ou par un programme (voir les transferts programmés). À partir de la version 0.5.8, une seule transaction peut porter jusqu’à 32 transferts de jetons, quels que soient les jetons, en un lot : tout ou rien, pour la somme des frais de chacun de ces transferts pris isolément, payés en ZBC, le message n’étant facturé qu’une fois (voir les transactions par lot).
Payer les frais dans le jeton
Un jeton doté d’une réserve en ZBC peut payer ses propres transferts (octet d’option à 1). Le jeton libère des ZBC de sa réserve pour couvrir le plancher et cède les unités correspondantes :
units given up = ceil( released ZBC × supply ÷ backing ), rounded up to the stepL’offre et la réserve baissent toutes les deux. Si les frais déclarés dépassent le plancher, le trop-payé reste dans le jeton.