Ordinals e Runes: o Guia Técnico Completo

O Bitcoin não tem contrato inteligente. Não tem estado global, não tem laço, não tem armazenamento persistente por conta. Ainda assim, desde 2023 ele carrega imagens, textos, coleções e tokens fungíveis.

Isso não aconteceu por uma mudança de consenso. Aconteceu porque dois recursos criados para outra finalidade — o desconto de peso do SegWit e o script path do Taproot — abriram, sem querer, espaço barato para dados arbitrários. Ordinals e Runes são o que se construiu em cima disso.

Este guia é a documentação que eu queria ter encontrado: o formato dos bytes, as regras exatas, os comandos e os erros que custam dinheiro.

Índice

• 1 · Pré-requisitos: UTXO, witness e Taproot
• 2 · Teoria ordinal: numerar satoshis
• 3 · Notações e raridade
• 4 · Inscrições: o envelope por dentro
• 5 · Campos de uma inscrição
• 6 · Commit e reveal, passo a passo
• 7 · Limites, peso e custo real
• 8 · Recursos avançados: parent, delegate, recursão, metadata
• 9 · Inscrições amaldiçoadas e o jubileu
• 10 · Operação prática com o ord
• 11 · Runes: por que existem
• 12 · O runestone byte a byte
• 13 · Etching: criar uma rune
• 14 · Nomes, spacers e o cronograma de desbloqueio
• 15 · Mint: cunhagem aberta
• 16 · Edicts: transferir
• 17 · Cenotaph: o runestone que queima
• 18 · Indexadores e infraestrutura
• 19 · Segurança operacional
• 20 · Os dez erros que mais custam caro

1. Pré-requisitos: UTXO, witness e Taproot

Três conceitos precisam estar firmes, senão o resto não faz sentido.

O modelo UTXO

O Bitcoin não guarda saldo por endereço. Ele guarda saídas não gastas — cada uma com um valor em satoshis e uma condição de gasto. Uma transação consome saídas inteiras e cria novas.

bitcoin-cli listunspent
# [{ "txid": "abc...", "vout": 0, "amount": 0.00015000, "confirmations": 12 }]

bitcoin-cli gettxout "abc..." 0

Como cada saída tem origem rastreável, é possível seguir frações específicas de moeda através da história. É disso que a teoria ordinal se aproveita.

O desconto do witness

O SegWit (2017) separou a assinatura do corpo da transação e criou a unidade de peso (weight unit, WU):

• byte no corpo da transação: 4 WU
• byte no witness: 1 WU

O tamanho virtual (vsize), que é o que define a taxa, é o peso dividido por 4. Na prática: dado no witness custa um quarto.

bitcoin-cli decoderawtransaction "<hex>" | jq '{size, vsize, weight}'
# size:   tamanho total em bytes
# weight: 4 * (bytes do corpo) + 1 * (bytes do witness)
# vsize:  weight / 4  <- é isto que multiplica a taxa em sats/vB

O script path do Taproot

O Taproot (2021) permite gastar uma saída revelando um script guardado em uma árvore. Esse script vai no witness — e não tem limite prático de tamanho imposto pelo consenso.

Junte as duas coisas: um script Taproot pode carregar um arquivo inteiro, pagando um quarto da taxa. Nenhuma das duas atualizações foi proposta com esse objetivo. A consequência foi emergente — e é a raiz de toda a discussão que veio depois.

2. Teoria ordinal: numerar satoshis

A teoria ordinal, criada por Casey Rodarmor, é uma convenção de numeração. Ela não altera o Bitcoin em nada: é uma regra que qualquer pessoa pode aplicar sobre a cadeia e chegar ao mesmo resultado.

Regra 1 — atribuição. Satoshis são numerados de 0 a 2.099.999.997.690.000, na ordem em que são minerados. Os satoshis do subsídio de um bloco recebem os próximos números disponíveis.

Regra 2 — transferência. Satoshis passam pelas transações em ordem primeiro a entrar, primeiro a sair (FIFO). Concatene as entradas na ordem em que aparecem; distribua para as saídas na ordem em que aparecem.

# Entradas:  [ A: sats 100-199 ]  [ B: sats 500-549 ]
# Saídas:    [ X: 120 sats ]      [ Y: 30 sats ]

# X recebe: 100-199 (100 sats) + 500-519 (20 sats)
# Y recebe: 520-549 (30 sats)

Regra 3 — taxas. Os satoshis pagos como taxa vão para o minerador e entram na saída da coinbase, logo depois dos satoshis do subsídio. É por isso que gastar um sat inscrito como taxa entrega sua inscrição ao minerador.

Vale insistir: nada disso é validado pela rede. Um nó Bitcoin não sabe o que é um ordinal. Quem sabe é o indexador que roda essa regra. Duas implementações divergentes produziriam saldos divergentes — a convenção só vale porque todos usam a mesma.

3. Notações e raridade

O mesmo satoshi pode ser escrito de cinco formas. Todas identificam o mesmo número.

A notação de grau é a que revela a raridade, porque expõe os quatro ciclos do Bitcoin de uma vez:

A°B′C″D‴
# A = ciclo         (a cada 6 halvings, quando halving e ajuste coincidem)
# B = índice do bloco na época de halving (0 a 209.999)
# C = índice do bloco no período de dificuldade (0 a 2.015)
# D = índice do satoshi dentro do bloco

Daí sai a escala de raridade:

ord find 2099994106992659      # em que UTXO está este sat
ord list <outpoint>            # que sats estão neste UTXO
ord traits 2099994106992659    # raridade, ciclo, época, notações

A raridade é uma propriedade da convenção, não do protocolo. Um sat "rare" é indistinguível de qualquer outro para o consenso do Bitcoin — vale o que o mercado que aceita a convenção decidir que vale.

4. Inscrições: o envelope por dentro

Uma inscrição anexa conteúdo a um satoshi. O conteúdo vai dentro de um envelope no script Taproot revelado no gasto:

OP_FALSE
OP_IF
  OP_PUSH "ord"              # marcador do protocolo
  OP_PUSH 0x01               # tag 1 = content-type
  OP_PUSH "image/png"
  OP_PUSH 0x00               # tag 0 = corpo (body)
  OP_PUSH <bytes ...>        # conteúdo, em pedaços de até 520 bytes
  OP_PUSH <bytes ...>
OP_ENDIF

Três detalhes que explicam por que isso funciona:

1. OP_FALSE OP_IF ... OP_ENDIF cria um bloco que nunca executa. Para o consenso, é dado inerte — não custa validação, não quebra nada.
2. Cada push carrega no máximo 520 bytes, então o conteúdo é fatiado. O indexador concatena os pedaços na ordem.
3. O envelope vive no witness, com o desconto de 4×. É o que torna o custo suportável.

A inscrição é atribuída ao primeiro satoshi da primeira saída da transação de reveal — a menos que um ponteiro diga outra coisa (tag 2, adiante).

O identificador de uma inscrição é o txid do reveal seguido do índice:

6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
# <txid do reveal> + "i" + <índice da inscrição naquela transação>

5. Campos de uma inscrição

Depois do marcador "ord", o envelope carrega pares de tag e valor. As tags são números:

A convenção de paridade importa: tags pares são essenciais — um indexador que não reconhece uma delas deve tratar a inscrição como inválida; tags ímpares podem ser ignoradas com segurança por versões antigas. É o mecanismo que permite evoluir o protocolo sem quebrar quem não atualizou.

# Conteúdo comprimido, para caber mais barato
OP_PUSH 0x09  OP_PUSH "gzip"
OP_PUSH 0x01  OP_PUSH "text/html;charset=utf-8"
OP_PUSH 0x00  OP_PUSH <html comprimido>

6. Commit e reveal, passo a passo

Inscrever exige duas transações. Entender isso evita a maior parte dos erros operacionais.

# 1) COMMIT
#    Cria uma saída Taproot cujo endereço compromete a árvore de scripts,
#    e um dos ramos dessa árvore é o envelope com o seu conteúdo.
#    Nesta etapa NADA do conteúdo aparece na cadeia.

# 2) REVEAL
#    Gasta aquela saída pelo script path, revelando o ramo do envelope.
#    É aqui que os bytes entram na blockchain, no witness.

Consequências práticas:

• A taxa do reveal é decidida no commit. O valor que a saída do commit carrega já precisa cobrir a taxa do reveal. Se a taxa da rede disparar entre as duas, o reveal pode ficar preso.
• O conteúdo só é público no reveal. Antes disso, existe apenas um compromisso criptográfico.
• A inscrição nasce na saída do reveal. É esse UTXO que você precisa proteger.

ord wallet inscribe --fee-rate 15 --file arte.png
# {
#   "commit": "e2f1...",
#   "reveal": "6fb9...",
#   "inscriptions": [{ "id": "6fb9...i0", "location": "6fb9...:0:0" }],
#   "total_fees": 24310
# }

7. Limites, peso e custo real

Limite de relay. Por padrão, um nó só repassa transações com até 400.000 unidades de peso (-maxstandardtxweight). Passando disso, a transação é válida mas não circula pela rede: só entra em bloco se for entregue direto a um minerador.

Limite de bloco. 4.000.000 WU. Uma única inscrição pode, em tese, ocupar quase um bloco inteiro.

A conta da taxa. Como witness custa 1 WU por byte:

# Estimativa para um arquivo de 100 KB no witness
# 100.000 bytes * 1 WU = 100.000 WU
# vsize = 100.000 / 4 = 25.000 vB
# a 20 sats/vB -> 25.000 * 20 = 500.000 sats de taxa (só o reveal)

bitcoin-cli estimatesmartfee 6 | jq '.feerate'    # BTC/kvB
bitcoin-cli getmempoolinfo | jq '{size, bytes, mempoolminfee}'

Regra de bolso: o mesmo arquivo no corpo da transação custaria quatro vezes mais. É o desconto do witness que torna a prática economicamente viável — e é exatamente por isso que parte da comunidade considera o desconto um erro de projeto.

Reduzir custo, na prática:

# 1. Comprima antes (tag 9 = content-encoding)
gzip -9 -c pagina.html > pagina.html.gz

# 2. Prefira formatos enxutos: SVG e HTML costumam ganhar de PNG
# 3. Use recursão: referencie bibliotecas já inscritas em vez de reinscrevê-las
# 4. Inscreva em lote: uma transação para várias inscrições
ord wallet batch --fee-rate 8 --batch lote.yaml

8. Recursos avançados: parent, delegate, recursão, metadata

Procedência (parent/child)

A tag 3 aponta para uma inscrição-pai. Para que a filiação seja válida, a inscrição-pai precisa ser gasta na transação de reveal — ou seja, só quem controla o pai consegue criar um filho. É assim que uma coleção prova autenticidade sem registro central.

# lote.yaml — coleção com procedência
mode: separate-outputs
parent: 6fb9...i0
inscriptions:
  - file: 001.png
  - file: 002.png
  - file: 003.png

Delegate

A tag 11 faz uma inscrição apontar para o conteúdo de outra. Mil itens que compartilham a mesma imagem podem ser mil inscrições minúsculas delegando a uma só — o custo despenca.

Recursão

Uma inscrição pode buscar outra através do endpoint /content/<id>. Isso permite inscrever uma biblioteca uma vez e reutilizá-la:

<script src="/content/6fb9...i0"></script>
<img src="/content/a1b2...i0">

Outros endpoints de recursão expõem dados da própria cadeia, o que permite arte generativa que reage ao estado do Bitcoin:

/r/blockheight        # altura atual
/r/blockhash          # hash do bloco
/r/blocktime          # timestamp
/r/sat/<numero>       # inscrições naquele sat
/r/children/<id>      # filhos de uma inscrição

Metadata

A tag 5 carrega metadados em CBOR — binário, mais compacto que JSON:

# {"nome": "Peça 001", "autor": "Jhonatan", "edicao": 1}
# vira alguns bytes de CBOR no envelope

ord wallet inscribe --fee-rate 10 --file arte.png --json-metadata meta.json

Reinscrição

Um satoshi pode receber mais de uma inscrição. As posteriores são reconhecidas, mas ficam claramente marcadas como reinscrições — a primeira é a canônica.

9. Inscrições amaldiçoadas e o jubileu

Nos primeiros meses, algumas inscrições foram criadas de formas que a implementação de referência não previa: envelopes duplicados na mesma entrada, tags desconhecidas, estruturas fora do padrão.

Em vez de descartá-las, o ord passou a numerá-las com números negativos — as cursed inscriptions. Era um sinal de "isto existe, mas não é canônico".

No bloco 824.544, o chamado jubileu encerrou essa distinção: a partir dali, as formas antes amaldiçoadas passaram a receber numeração positiva normal. As antigas mantiveram seus números negativos como registro histórico.

ord list <outpoint> | jq '.inscriptions'
# número negativo = inscrição anterior ao jubileu, criada de forma não canônica

A lição de engenharia aqui é boa: em protocolo baseado em convenção, mudar a regra é decisão social, não técnica. Não houve fork — houve acordo entre quem roda o indexador.

10. Operação prática com o ord

# Pré-requisito: nó completo com índice de transações
bitcoind -daemon -txindex=1
bitcoin-cli getblockchaininfo | jq '{blocks, initialblockdownload}'

# Indexador (a primeira indexação demora horas e ocupa dezenas de GB)
ord --index-sats server --http-port 8080

# Carteira
ord wallet create                       # gera e mostra a seed — guarde offline
ord wallet receive                      # endereço para depositar
ord wallet balance                      # separa cardinal (gastável) de ordinal
ord wallet outputs                      # todos os UTXOs
ord wallet inscriptions                 # o que você tem inscrito

# Inscrever
ord wallet inscribe --fee-rate 12 --file arte.png
ord wallet inscribe --fee-rate 12 --file arte.png --destination bc1p...
ord wallet inscribe --fee-rate 12 --file arte.png --postage 10000sat

# Enviar
ord wallet send --fee-rate 10 bc1p... 6fb9...i0        # por id da inscrição
ord wallet send --fee-rate 10 bc1p... 2099994106992659 # por número de sat

# Consultar
ord wallet transactions
ord decode --txid <txid>                # mostra o envelope decodificado

O parâmetro --postage merece atenção: é quantos satoshis acompanham a inscrição na saída. O padrão é 10.000 sats. Valores muito baixos podem cair abaixo do limite de poeira e travar transferências futuras.

11. Runes: por que existem

Antes das Runes, criar token fungível no Bitcoin significava usar BRC-20: inscrições com um JSON dizendo o que se queria fazer.

{"p":"brc-20","op":"deploy","tick":"ordi","max":"21000000","lim":"1000"}
{"p":"brc-20","op":"mint","tick":"ordi","amt":"1000"}
{"p":"brc-20","op":"transfer","tick":"ordi","amt":"100"}

Funciona, mas com três defeitos sérios:

1. Cada operação é uma inscrição. Transferir exige inscrever e depois enviar — duas transações e dois envelopes de lixo permanente no witness.
2. O saldo é puramente off-chain. Não está em UTXO nenhum: existe só na cabeça do indexador, que precisa interpretar texto.
3. UTXOs órfãos. O modelo gera saídas residuais que sujam a carteira e o conjunto de UTXOs da rede.

Runes, lançado por Casey Rodarmor no bloco 840.000 (o halving de abril de 2024), foi desenhado para resolver isso sendo nativo ao modelo UTXO: o saldo mora no próprio UTXO, e a instrução vai em uma única saída OP_RETURN.

12. O runestone byte a byte

Um runestone é uma saída OP_RETURN assim:

OP_RETURN
OP_13                  # marcador do protocolo Runes (OP_PUSHNUM_13)
<push de dados>        # payload
<push de dados>        # (se houver mais de um, concatene na ordem)

O payload é uma sequência de inteiros LEB128 (varint de tamanho variável), lidos como pares tag → valor:

A mesma regra de paridade das inscrições vale aqui: tag par desconhecida invalida o runestone (vira cenotaph); tag ímpar desconhecida é ignorada. É o que permite adicionar recursos no futuro sem quebrar indexadores antigos.

# Decodificar um runestone da cadeia
ord decode --txid <txid>
bitcoin-cli getrawtransaction <txid> 1 | jq '.vout[] | select(.scriptPubKey.type=="nulldata")'

Por que OP_RETURN e não witness? Porque OP_RETURN é provadamente não gastável — os nós podem descartar essas saídas do conjunto de UTXOs, sem inchar a memória da rede. Custa mais caro por byte (fica no corpo, sem desconto), e é justamente por isso que o formato é binário e enxuto.

13. Etching: criar uma rune

Etching é o ato de criar a rune. Define nome, símbolo, divisibilidade, premine e as regras de cunhagem.

# etching.yaml
mode: separate-outputs
etching:
  rune: MINHA•PRIMEIRA•RUNE
  divisibility: 2
  premine: 1000
  symbol: ¤
  supply: 21000
  terms:
    amount: 100
    cap: 200
    height: [840000, 900000]     # janela absoluta (opcional)
  turbo: true
inscriptions:
  - file: logo.png               # opcional: um "cenotaph visual" da rune

ord wallet batch --fee-rate 20 --batch etching.yaml

O commitment de 6 blocos

Aqui está o detalhe que mais confunde quem etcha pela primeira vez: o nome da rune precisa ser comprometido antes, e o compromisso precisa ter pelo menos 6 confirmações antes da transação de etching.

O motivo é anti-front-running: sem isso, qualquer um veria seu nome no mempool e publicaria a mesma rune com taxa maior. Com o commitment, quem tenta copiar precisaria esperar seis blocos — tempo suficiente para o original confirmar.

# Na prática, o ord faz isso por você e espera:
# "Waiting for rune commitment ... to mature (6 confirmations)"
# São ~1 hora entre iniciar e a rune existir. Não interrompa o processo.

Supply, premine e terms

• premine — o que o criador recebe na hora do etching.
• terms.amount — quanto cada mint entrega.
• terms.cap — quantos mints existem.
• Supply total = premine + (amount × cap).

# premine 1000 + (100 * 200) = 21.000 unidades
# Quanto maior a fatia do premine, mais centralizada é a distribuição.

Premine é o primeiro número que qualquer pessoa deveria olhar antes de tocar em uma rune. Premine de 90% significa que o criador detém quase tudo.

Flags

O campo Flags (tag 2) é um conjunto de bits:

14. Nomes, spacers e o cronograma de desbloqueio

Nomes de rune usam apenas letras maiúsculas de A a Z, codificadas como um inteiro em base 26 modificada.

MINHA•PRIMEIRA•RUNE
# A identidade real é MINHAPRIMEIRARUNE.
# Os "•" são spacers (tag 3): decoração visual, não fazem parte do nome.
# Não existem duas runes com o mesmo nome, ainda que com spacers diferentes.

O desbloqueio progressivo

Se todos os nomes estivessem disponíveis no lançamento, os curtos teriam sido tomados nos primeiros blocos. O protocolo evita isso liberando os nomes ao longo do tempo:

• No bloco 840.000 (lançamento), o nome precisa ter no mínimo 13 letras.
• A cada 17.500 blocos, o mínimo cai em uma letra.
• 12 reduções × 17.500 = 210.000 blocos — exatamente um ciclo de halving.
• No bloco 1.050.000 (halving de 2028), nomes de uma letra ficam disponíveis.

# Comprimento mínimo pela altura atual, na prática:
# 840.000 -> 13 letras
# 857.500 -> 12 letras
# 875.000 -> 11 letras
# ...
# 1.050.000 -> 1 letra

Runes etchadas antes do bloco 840.000 não existem: a primeira rune possível é a do próprio bloco de lançamento.

Rune ID

Cada rune é identificada pelo bloco e pela posição da transação dentro dele:

840000:1     # bloco 840.000, transação 1
# É este id que os edicts usam — não o nome.

15. Mint: cunhagem aberta

Se o etching definiu terms, qualquer pessoa pode cunhar até o cap ser atingido, dentro da janela permitida.

ord wallet mint --fee-rate 15 --rune MINHA•PRIMEIRA•RUNE

# Um mint é um runestone com a tag Mint (20) apontando o rune id:
# OP_RETURN OP_13 <20> <bloco> <tx>

Regras que valem conhecer:

• Um mint entrega exatamente amount. Não existe mint parcial.
• Mint fora da janela (height ou offset) não é erro de transação: ele simplesmente não produz nada, e a taxa foi paga do mesmo jeito.
• Depois do cap, mints deixam de produzir. Em runes populares isso vira corrida por bloco, e é o que costuma explodir a taxa da rede em janelas de mint.
• Janela por altura (height) usa números absolutos de bloco; janela por offset (offset) conta a partir do bloco do etching.

16. Edicts: transferir

Transferência é um edict dentro do runestone: uma tripla (id, quantidade, saída).

ord wallet send --fee-rate 12 bc1p... 500:MINHA•PRIMEIRA•RUNE

Duas convenções fazem toda a diferença:

• Quantidade 0 significa "todo o saldo restante daquela rune".
• Saída igual ao número de saídas significa "divida igualmente entre todas as saídas não-OP_RETURN". É o mecanismo de airdrop em uma transação só.

# Transação com 3 saídas (índices 0, 1, 2) mais o OP_RETURN:
# edict (840000:1, 0, 3) -> divide todo o saldo entre as saídas 0, 1 e 2

Pointer

O que sobra sem edict explícito vai para a primeira saída não-OP_RETURN. A tag Pointer (22) muda esse destino:

# Sem pointer: o troco de runes cai na saída 0
# Com pointer = 2: o troco cai na saída 2

Esquecer disso é uma das formas mais fáceis de mandar saldo para o endereço errado — inclusive para o do destinatário, quando você queria só o troco.

17. Cenotaph: o runestone que queima

Um cenotaph é um runestone malformado. O nome não é acidente: cenotáfio é um túmulo vazio.

Um runestone vira cenotaph quando:

• há uma tag par que o protocolo não reconhece;
• o payload está mal codificado (varint inválido, campos incompletos);
• um edict aponta para uma saída que não existe;
• há campos duplicados onde não deveria.

E a consequência é dura, deliberadamente:

Por que tão severo? Porque a alternativa — ignorar o erro e seguir — abriria espaço para divergência entre indexadores. Queimar é determinístico e igual para todos. O custo dessa escolha é que um bug na sua implementação destrói saldo real, sem recurso.

# Antes de assinar qualquer transação de runes construída à mão:
ord decode --txid <txid>          # o ord aponta cenotaph
# Em caso de dúvida, teste em signet primeiro. Sempre.

18. Indexadores e infraestrutura

Como nem Ordinals nem Runes são validados pelo consenso, todo saldo depende de um indexador. Rodar o seu é a única forma de não confiar em terceiros.

# Requisitos aproximados do ord com índice de sats
# - nó Bitcoin completo com -txindex=1 (~700 GB e crescendo)
# - dezenas de GB adicionais para o índice do ord
# - SSD é praticamente obrigatório; a indexação inicial leva horas

ord --index-sats --index-runes server --http-port 8080
curl -s localhost:8080/status | jq

Endpoints úteis da API local:

curl -s localhost:8080/inscription/<id> -H "Accept: application/json"
curl -s localhost:8080/output/<txid>:<vout> -H "Accept: application/json"
curl -s localhost:8080/rune/MINHA•PRIMEIRA•RUNE -H "Accept: application/json"
curl -s localhost:8080/sat/2099994106992659 -H "Accept: application/json"

Existem APIs de terceiros que poupam o trabalho de indexar. Elas são convenientes e legítimas, mas note o que você está aceitando: a resposta delas é a fonte de verdade da sua aplicação. Para exibir, tudo bem; para decidir sobre custódia de valor, rode o seu índice.

19. Segurança operacional

O risco aqui raramente é criptográfico — é operacional.

# 1. Separe as carteiras. Sats inscritos e runes NUNCA na carteira do dia a dia.
ord wallet balance     # cardinal = gastável | ordinal = protegido

# 2. Trave os UTXOs que carregam valor
bitcoin-cli lockunspent false '[{"txid":"<txid>","vout":0}]'
bitcoin-cli listlockunspent

# 3. Confira o destino antes de enviar
ord wallet send --dry-run --fee-rate 10 bc1p... 6fb9...i0

Regras que evitam quase todo prejuízo:

• Nunca envie inscrição ou rune para endereço de exchange. A exchange trata tudo como bitcoin comum e vai gastar o sat como troco. O ativo desaparece — e não há suporte que resolva.
• Use carteira com controle de sats. Carteira comum não sabe o que é UTXO inscrito.
• Cuidado com "assinar para verificar". Site pedindo assinatura de PSBT genérico é o golpe mais comum do setor: você assina uma transação que entrega seus UTXOs.
• Guarde a seed offline. Papel ou metal, nunca foto, nunca gerenciador de senha em nuvem.
• Valores relevantes só em hardware wallet com suporte explícito a Ordinals.
• Teste em signet. Sempre. Tudo. A primeira vez sempre tem uma surpresa.

bitcoind -signet -daemon
ord --signet --index-sats server
ord --signet wallet inscribe --fee-rate 1 --file teste.txt

20. Os dez erros que mais custam caro

1. Gastar sat inscrito como troco. A inscrição vai para o minerador. Irreversível.
2. Enviar para exchange. Mesma coisa, com uma camada extra de impossibilidade.
3. Não esperar o commitment de 6 blocos no etching e desistir no meio do processo.
4. Runestone malformado. Cenotaph queima o saldo de entrada.
5. Esquecer o pointer. Todo o troco de runes vai para a saída errada.
6. Mint fora da janela. Você paga a taxa e não recebe nada.
7. Postage baixo demais. Saída abaixo do limite de poeira trava transferências futuras.
8. Taxa do reveal subdimensionada. O commit já saiu e o reveal fica preso no mempool.
9. Confiar em um único indexador de terceiro para decidir sobre valor.
10. Assinar PSBT sem ler o que está sendo gasto. É assim que carteiras são esvaziadas.

Fechando

Ordinals e Runes são, tecnicamente, um caso de estudo notável: dois protocolos completos construídos sem alterar uma linha do consenso, aproveitando recursos que existiam para outra finalidade.

Isso traz uma característica que precisa estar clara antes de qualquer coisa: o Bitcoin não conhece nenhum dos dois. Não existe validação de saldo, não existe mensagem de erro amigável, não existe reversão. Existe uma convenção que vale enquanto os indexadores concordarem — e um conjunto de regras implacáveis quando você erra a codificação.

Para quem programa, o valor de estudar isso vai além do assunto: é um exemplo raro de protocolo bem documentado, com decisões de projeto explícitas (por que OP_RETURN e não witness, por que queimar em vez de ignorar, por que paridade de tags) e consequências verificáveis na cadeia. Dá para ler o código, reproduzir cada byte em signet e conferir.

E, se for tocar em mainnet: signet primeiro, carteira separada sempre, e nada de valor sem hardware wallet.