BRC-20 es un metaprotocolo: un conjunto de reglas para interpretar datos guardados en Bitcoin. Sus operaciones básicas deploy, mint y transfer crean un token, emiten sus unidades y las transfieren. No son más BTC ni una nueva parte del consenso de Bitcoin.
El autor conocido como domo exploró si Ordinals podía permitir tokens fungibles: unidades de un mismo token con el mismo papel en su contabilidad. El texto original describe un experimento y advierte de que no debe tomarse como solución definitiva. Las reglas de BRC-20 son un acuerdo entre sus participantes, no una modificación de las de Bitcoin. [1]
Una inscription es contenido incluido en los datos witness al gastar una salida Taproot. En BRC-20 contiene JSON, un texto con campos como p, op y tick. El nodo de Bitcoin valida la transacción, pero no ejecuta ese texto como contabilidad del token. Es el indexador quien interpreta su significado. [5]
El primer deploy válido se queda con el ticker, el identificador del token, sin distinguir mayúsculas de minúsculas. Fija la oferta max y, opcionalmente, el límite de emisión lim y la precisión dec. Las reglas básicas permiten hasta 18 decimales. Además de los tickers originales de 4 bytes, IP1 introdujo los de 5 bytes asociados a self_mint. Se cuentan bytes UTF-8, no letras; ambas variantes no son intercambiables libremente. [2] [3] [6]
El propietario crea primero una transfer inscription con la cantidad amt. Así la reserva del saldo disponible, sin cambiar todavía el saldo total. Solo el primer movimiento de esa inscription transfiere las unidades al destinatario. Enviársela a uno mismo libera la reserva. Cada transfer inscription sirve una sola vez; revender el mismo registro no vuelve a transferir los tokens. [1] [3]
Los indexadores deben interpretar igual el orden de los eventos, los límites y la primera transferencia. Identifican al propietario del saldo por scriptPubKey, el script de bloqueo de la salida, y no solo por la dirección mostrada. Una reorganización puede cambiar el orden y la contabilidad resultante. Por eso, confirmar la transacción Bitcoin no demuestra por sí solo que su operación BRC-20 fuera válida. [3]
Las reglas básicas aceptan text/plain o application/json como tipo de contenido y exigen JSON válido. Los campos obligatorios y nombres de operaciones van en minúsculas; los valores exigidos, incluidos los números, son cadenas entre comillas. dec limita los decimales y uint64_max el rango numérico. Un número sin comillas o una coma de más pueden invalidar una operación aunque resulte legible. [3]
Si un servicio crea primero un mint en su propia dirección, puede quedarse con el saldo del token. Entregar después la mint inscription no transfiere ese saldo. Gastar por accidente el UTXO correspondiente también puede dar un resultado inesperado. Enviar una inscription como comisión de minería y destruir tokens tienen reglas propias; una transferencia corriente de BTC no sirve como guía universal para BRC-20. [1] [6]
Compruebe el primer deploy válido, max, lim, dec y, si corresponde, self_mint; después siga los eventos en orden de bloques y transacciones. OPI permite comparar hashes de los eventos de cada bloque y un hash acumulado de la historia. Debe coincidir la versión de las reglas: los módulos programables más recientes amplían el modelo original. Este artículo explica su base, no todas las ampliaciones. [4]
Para obtener la imagen más completa, lee esta entrada junto con Ordinals Inscriptions, Runes, UTXO, Taproot, Bitcoin Script, Fee Rate.
01¿Los Full Nodes de Bitcoin validan BRC-20?+
Validan las transacciones de Bitcoin y sus scripts, pero no calculan los saldos BRC-20. Un indexador los reconstruye según las reglas del metaprotocolo. Por tanto, un nodo Bitcoin por sí solo no basta para comprobar esa contabilidad.
02¿BRC-20 es lo mismo que Runes?+
No. La base de BRC-20 usa Ordinals Inscriptions de texto y una transferencia en dos pasos. Runes registra mensajes binarios runestone en una salida OP_RETURN y asigna tokens a UTXO de otra forma. No se pueden intercambiar las reglas de ambos sistemas.