BRC-20

L’auteur connu sous le nom de domo cherchait à savoir si Ordinals permettait de créer des tokens fongibles : des unités d’un même token ayant le même rôle dans sa comptabilité. Le texte original décrit une expérience et met en garde contre l’idée d’y voir une solution définitive. Les règles de BRC-20 résultent d’un accord entre ses participants, sans modifier celles de Bitcoin. [1]

Une inscription est un contenu placé dans les données witness lors de la dépense d’une sortie Taproot. Pour BRC-20, elle contient du JSON, un texte organisé en champs tels que p, op et tick. Le nœud Bitcoin valide la transaction, mais n’exécute pas ce texte comme une comptabilité de tokens. C’est l’indexeur qui en interprète le sens. [5]

Le premier deploy valide réserve un ticker, l’identifiant du token, sans distinguer majuscules et minuscules. Il définit l’offre max et, éventuellement, la limite d’émission lim et la précision dec. Les règles de base autorisent jusqu’à 18 décimales. Aux tickers initiaux de 4 octets, IP1 a ajouté ceux de 5 octets associés à self_mint. On compte les octets UTF-8, pas les lettres ; ces variantes ne sont pas librement interchangeables. [2] [3] [6]

Le détenteur crée d’abord une inscription transfer indiquant amt. Ce montant est réservé dans son solde disponible, sans modifier encore son solde total. Seul le premier déplacement de cette inscription transfère les unités au destinataire. Se l’envoyer à soi-même libère la réservation. Chaque inscription transfer ne sert qu’une fois : revendre le même enregistrement ne transfère pas à nouveau les tokens. [1] [3]

Les indexeurs doivent interpréter de la même façon l’ordre des événements, les limites et le premier transfert. Ils suivent le détenteur du solde à partir du scriptPubKey, le script de verrouillage de la sortie, et pas seulement de l’adresse affichée. Une réorganisation peut modifier l’ordre et la comptabilité obtenue. La confirmation d’une transaction Bitcoin ne prouve donc pas à elle seule la validité de son opération BRC-20. [3]

Les règles de base acceptent le type de contenu text/plain ou application/json et exigent du JSON valide. Les champs obligatoires et les noms d’opérations sont en minuscules ; les valeurs requises, y compris les nombres, sont des chaînes entre guillemets. dec limite les décimales et uint64_max la plage numérique. Un nombre sans guillemets ou une virgule en trop peut invalider une opération pourtant facile à lire. [3]

Si un service crée d’abord un mint à sa propre adresse, il peut recevoir le solde du token. Transmettre ensuite l’inscription mint ne transfère pas ce solde. Dépenser par erreur l’UTXO concerné peut aussi produire un résultat inattendu. L’envoi d’une inscription comme frais de minage et la destruction de tokens ont leurs propres règles ; un transfert habituel de BTC n’est pas un mode d’emploi universel de BRC-20. [1] [6]

Vérifiez le premier deploy valide, max, lim, dec et l’éventuel self_mint, puis suivez les événements dans l’ordre des blocs et des transactions. OPI permet de comparer les empreintes des événements de chaque bloc et une empreinte cumulée de l’historique. La version des règles doit correspondre : des modules programmables plus récents étendent le modèle initial. Cet article en explique la base, pas toutes les extensions. [4]