Blockchain, RWAs e Bitcoin: Guia Técnico de Ordinals e Runes

Existe muito conteúdo sobre blockchain que é ou hype de investimento, ou artigo acadêmico impenetrável. Este aqui tenta ser a terceira coisa: documentação técnica para quem programa e quer entender o que essas tecnologias fazem de verdade, onde elas resolvem um problema real e onde são a ferramenta errada.

Três assuntos, em ordem de abstração:

1. Blockchain — o que é o registro distribuído, por que ele custa caro e que problema ele realmente resolve.
2. RWAs — tokenização de ativos do mundo real: onde a promessa encosta na realidade jurídica.
3. Ordinals e Runes — como o Bitcoin, que não tem contrato inteligente, ganhou NFTs e tokens fungíveis.

Isto não é recomendação de investimento. É documentação técnica. Nada aqui sugere comprar, vender ou manter qualquer ativo — e a parte final é justamente sobre os riscos.

Índice

• 1 · O que é blockchain, sem misticismo
• 2 · Consenso: como estranhos concordam
• 3 · O que blockchain resolve — e o que não resolve
• 4 · Camadas: L1, L2 e rollups
• 5 · Tokens: fungíveis e não fungíveis
• 6 · RWAs: tokenizar o mundo real
• 7 · Arquitetura de um projeto de RWA
• 8 · Bitcoin por dentro: UTXO, script e Taproot
• 9 · Ordinals: numerar satoshis e inscrever dados
• 10 · Runes: tokens fungíveis nativos do Bitcoin
• 11 · Comparativo: Runes, BRC-20, RGB e Liquid
• 12 · Riscos, críticas e o debate real
• 13 · Por onde começar como desenvolvedor

1. O que é blockchain, sem misticismo

Uma blockchain é um banco de dados append-only, replicado, sem dono, em que a ordem dos registros é acordada por participantes que não confiam uns nos outros.

Tecnicamente, três peças:

• Blocos encadeados por hash. Cada bloco carrega o hash do anterior. Alterar um registro antigo muda o hash daquele bloco, o que invalida todos os seguintes.
• Assinatura digital. Cada transação é assinada pela chave privada do dono. Ninguém move o que não é seu, e ninguém precisa de um cadastro central para provar isso.
• Regra de consenso. Um procedimento que faz milhares de nós, sem se conhecerem, chegarem à mesma ordem de transações.

# A cadeia de hashes, na prática (Bitcoin Core)
bitcoin-cli getblockhash 840000
bitcoin-cli getblock 0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5 1
# o campo "previousblockhash" liga este bloco ao anterior

A árvore de Merkle é o que permite provar que uma transação está em um bloco sem baixar o bloco inteiro — a base de qualquer cliente leve:

bitcoin-cli gettxoutproof '["<txid>"]'    # prova de inclusão
bitcoin-cli verifytxoutproof "<prova>"     # verificação

O que faz uma blockchain ser diferente de um banco replicado: em um banco, quem manda é o administrador. Em uma blockchain pública, ninguém manda — a regra é o código executado por todos os nós, e mudar essa regra exige convencer a rede inteira.

2. Consenso: como estranhos concordam

Proof of Work (Bitcoin)

Mineradores competem para achar um nonce que faça o hash do bloco ficar abaixo de um alvo. Achar é caro (energia), verificar é instantâneo. A cadeia válida é a que acumulou mais trabalho.

bitcoin-cli getblockchaininfo | jq '{blocks, difficulty, chainwork}'
bitcoin-cli getmininginfo | jq '{networkhashps, difficulty}'

O gasto de energia não é um efeito colateral: é o próprio mecanismo. Reescrever a história exige refazer o trabalho de todos os blocos posteriores, mais rápido que a rede inteira. O custo é a segurança.

Proof of Stake (Ethereum e a maioria das redes modernas)

Validadores depositam capital como garantia. Quem valida bloco inválido perde parte do depósito (slashing). O custo deixa de ser energia e passa a ser capital travado.

Finalidade é o conceito que mais confunde quem vem de banco de dados: no Bitcoin, uma transação nunca é 100% irreversível — ela só fica exponencialmente improvável de reverter a cada bloco. É por isso que exchanges esperam confirmações.

3. O que blockchain resolve — e o que não resolve

Resolve bem:

• Transferir valor entre partes que não confiam uma na outra, sem intermediário.
• Registro público, verificável por qualquer um, sem depender da palavra de quem o mantém.
• Regras que executam sozinhas, sem alguém podendo mudar o resultado depois.
• Resistência a censura: nenhum participante isolado consegue impedir uma transação válida.

Não resolve:

• Dado falso na entrada. Se você registra "este imóvel vale R$ 800 mil" e o dado é mentira, a blockchain guarda a mentira com integridade perfeita. É o problema do oráculo, e ele é fundamental — nenhuma cadeia consegue verificar o mundo físico sozinha.
• Performance. Um banco relacional em um servidor comum faz dezenas de milhares de escritas por segundo. O Bitcoin faz cerca de 7 transações por segundo. Não é falta de otimização: é o preço de milhares de nós validarem tudo de novo.
• Privacidade. Blockchain pública é radicalmente transparente. Todo saldo e toda transferência ficam visíveis para sempre.
• Erro humano. Chave perdida é fundo perdido. Transferência para o endereço errado é irreversível. Não existe suporte para ligar.

A pergunta que separa projeto sério de teatro tecnológico: existe mais de uma parte, sem confiança mútua, que precisa concordar sobre o mesmo estado? Se a resposta é não, um Postgres com log de auditoria resolve melhor, mais barato e mais rápido.

4. Camadas: L1, L2 e rollups

• L1 (camada base) — Bitcoin, Ethereum. Segurança máxima, capacidade mínima, custo alto.
• L2 (segunda camada) — processa fora e ancora na L1. Lightning Network (Bitcoin), Arbitrum e Optimism (Ethereum).
• Rollup — executa transações fora da L1 e publica na L1 os dados ou a prova. Optimistic assume validade e abre janela de contestação; ZK publica prova criptográfica de que a execução está correta.
• Sidechain — cadeia separada com consenso próprio e ponte para a L1. Herda menos segurança (Liquid, Rootstock).

# Lightning: canal de pagamento fora da cadeia, liquidação na L1
lncli openchannel --node_key=<pubkey> --local_amt=1000000
lncli listchannels | jq '.channels[] | {remote_pubkey, capacity, local_balance}'
lncli closechannel --funding_txid=<txid> --output_index=0

A regra prática: quanto mais longe da L1, mais barato e mais rápido — e mais confiança extra você precisa assumir.

5. Tokens: fungíveis e não fungíveis

• Fungível — cada unidade vale o mesmo que qualquer outra (uma stablecoin, uma cota de fundo). No Ethereum: ERC-20.
• Não fungível (NFT) — cada unidade é única e identificável (matrícula de imóvel, certificado). No Ethereum: ERC-721.

// ERC-20: o essencial da interface fungível
interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address conta) external view returns (uint256);
    function transfer(address para, uint256 valor) external returns (bool);
    function approve(address gastador, uint256 valor) external returns (bool);
    function transferFrom(address de, address para, uint256 valor) external returns (bool);
}

Para RWA existe uma terceira família, a dos tokens permissionados, em que a transferência só acontece se ambas as partes estiverem habilitadas:

// ERC-3643 (T-REX): transferência sujeita a verificação de identidade
function transfer(address para, uint256 valor) public override returns (bool) {
    require(identityRegistry.isVerified(para), "destinatario nao verificado");
    require(compliance.canTransfer(msg.sender, para, valor), "regra de compliance");
    return super.transfer(para, valor);
}

Essa é a diferença central entre cripto "livre" e ativo regulado: o token de um ativo financeiro precisa saber quem está do outro lado.

6. RWAs: tokenizar o mundo real

RWA (Real World Asset) é a representação, em blockchain, de um ativo que existe fora dela: título público, cota de fundo, recebível, imóvel, crédito privado, commodity.

O que a tokenização entrega de fato

• Fracionamento. Um imóvel de R$ 2 milhões vira 2 milhões de unidades. Reduz o ticket mínimo drasticamente.
• Liquidação quase instantânea. Sem D+2: a transferência do token é a liquidação.
• Operação contínua. O registro não fecha às 17h nem no fim de semana.
• Composabilidade. O token pode ser usado como garantia em outro protocolo sem pedir autorização.
• Transparência de lastro. Auditoria pode ser publicada continuamente em vez de trimestralmente.

Onde a promessa encosta na realidade

Aqui mora o que a maioria dos textos promocionais omite:

1. O token não é o ativo. Ele é um direito sobre o ativo, e esse direito vive no contrato jurídico, não no código. Se o emissor quebrar, o smart contract continua funcionando perfeitamente — e sem lastro nenhum.
2. Custódia é o elo fraco. Alguém guarda o imóvel, o título, o ouro. Esse alguém é um ponto central de confiança, exatamente o que a blockchain deveria eliminar.
3. O oráculo define o preço. Se a fonte de preço for manipulada ou ficar fora do ar, tudo que depende dela quebra junto.
4. Regulação manda. Cota de fundo é valor mobiliário, esteja ela em um cartório ou em uma blockchain. Emitir sem registro é oferta irregular.
5. Liquidez não nasce do token. Tokenizar um ativo ilíquido geralmente produz um token ilíquido. O mercado comprador precisa existir.

O cenário, em categorias

Os casos que deram certo têm um padrão claro: funcionam melhor quanto mais padronizado, líquido e regulado for o ativo original. Títulos públicos tokenizados prosperaram; fração de imóvel continua difícil — não por limitação técnica, mas porque o problema nunca foi tecnológico.

No Brasil

• A CVM já se posicionou: token que representa investimento coletivo com expectativa de lucro é valor mobiliário e segue as regras de sempre.
• O sandbox regulatório da CVM foi usado por emissores para testar tokenização de recebíveis com supervisão.
• O Drex, do Banco Central, é a peça mais relevante: uma infraestrutura de liquidação tokenizada em que o dinheiro e o ativo mudam de mãos no mesmo evento (delivery versus payment), eliminando risco de contraparte na liquidação.
• Tokenização de recebíveis e crédito é o segmento com tração real no país — não por acaso, é onde o ativo já é padronizado e o problema (antecipar recebível caro e burocrático) é concreto.

7. Arquitetura de um projeto de RWA

Do ponto de vista de quem constrói, um projeto sério tem sempre estas camadas:

[ Ativo no mundo real ]  imóvel, título, recebível
        │
[ Estrutura jurídica  ]  SPE, fundo, contrato de cessão — quem responde legalmente
        │
[ Custódia            ]  quem guarda o ativo e responde por ele
        │
[ Oráculo / atestação ]  preço, prova de reserva, status do ativo
        │
[ Token               ]  contrato permissionado (ERC-3643, ERC-1400)
        │
[ Compliance          ]  KYC/AML, allowlist, limites por jurisdição
        │
[ Distribuição        ]  plataforma, carteira, mercado secundário

O código é a menor parte do problema. Um contrato de token permissionado tem algumas centenas de linhas; a estrutura jurídica e a custódia levam meses.

Prova de reserva

Sem isso, o token é uma promessa não verificável:

// Consulta a um feed de prova de reserva antes de permitir emissão
interface AggregatorV3Interface {
    function latestRoundData() external view returns (
        uint80 roundId, int256 answer, uint256 startedAt,
        uint256 updatedAt, uint80 answeredInRound
    );
}

function emitir(uint256 quantidade) external onlyEmissor {
    (, int256 reserva, , uint256 atualizadoEm, ) = feedReserva.latestRoundData();
    require(block.timestamp - atualizadoEm < 1 days, "dado de reserva desatualizado");
    require(totalSupply() + quantidade <= uint256(reserva), "emissao acima do lastro");
    _mint(msg.sender, quantidade);
}

Repare no require do prazo: oráculo parado é tão perigoso quanto oráculo errado, e esquecer essa verificação é uma das falhas mais comuns em auditoria.

Perguntas para avaliar qualquer projeto de RWA

1. Quem responde juridicamente se o ativo sumir? Existe CNPJ e contrato?
2. Onde está o ativo e quem audita a custódia — com que frequência?
3. O que acontece se o emissor parar de operar? Existe plano de resgate?
4. O token é transferível para qualquer um ou há allowlist? Quem controla?
5. Qual oráculo alimenta o preço e o que acontece se ele falhar?
6. O contrato tem função de pausa, congelamento ou confisco? Quem detém essa chave?

A última pergunta é decisiva: quase todo token de RWA regulado tem função de congelamento — a lei exige. Isso não é falha, é requisito. Mas você precisa saber que existe, e quem tem a chave.

8. Bitcoin por dentro: UTXO, script e Taproot

Para entender Ordinals e Runes é preciso entender três coisas do Bitcoin.

Modelo UTXO

O Bitcoin não tem contas com saldo. Ele tem UTXOs (Unspent Transaction Outputs): pedaços de moeda, cada um com um valor e uma condição de gasto. Uma transação consome UTXOs inteiros e cria novos.

bitcoin-cli listunspent
# [{ "txid": "...", "vout": 0, "amount": 0.015, "scriptPubKey": "..." }]

# Cada UTXO é gasto por inteiro; o troco volta como um novo UTXO
bitcoin-cli gettxout "<txid>" 0

É exatamente isso que permite rastrear satoshis individuais: como cada UTXO tem origem identificável, dá para seguir a trilha de qualquer fração.

Script

Cada saída carrega um script que define a condição de gasto. Não é Turing-completo de propósito: sem laços, sem estado global, sem chamada de contrato.

# OP_RETURN: saída deliberadamente não gastável, usada para gravar dados
bitcoin-cli createrawtransaction \
  '[{"txid":"<txid>","vout":0}]' \
  '[{"data":"48656c6c6f"}]'

SegWit e Taproot: o que destravou tudo

Duas atualizações prepararam o terreno, sem que fosse esse o objetivo:

• SegWit (2017) separou a assinatura (witness) do corpo da transação e deu a ela um desconto de peso: dado em witness custa cerca de 1/4 do que custaria no corpo.
• Taproot (2021) trouxe o script path, permitindo revelar um script arbitrário na hora do gasto — sem limite prático de tamanho para o dado embutido.

Junte as duas: virou viável colocar um arquivo dentro de uma transação de Bitcoin, pagando taxa com desconto. Ninguém projetou isso pensando em imagens — foi uma consequência emergente. Essa distinção está no centro de toda a polêmica que veio depois.

9. Ordinals: numerar satoshis e inscrever dados

Ordinals é um protocolo criado por Casey Rodarmor e lançado em janeiro de 2023. Ele tem duas partes independentes, e confundi-las é o erro mais comum.

Parte 1: a teoria ordinal

Cada satoshi ganha um número de série, atribuído pela ordem em que foi minerado, e é rastreado nas transações pela regra first-in-first-out: os primeiros satoshis que entram são os primeiros que saem.

# Numeração e localização de um satoshi específico
ord list <outpoint>              # quais sats estão neste UTXO
ord find 1234567890              # em que UTXO está o sat de número N
ord traits 1234567890            # raridade: uncommon, rare, epic, legendary

Repare: isso é convenção, não consenso. A rede Bitcoin não sabe o que é um ordinal. Quem sabe é o indexador que roda essa regra sobre a cadeia. Dois indexadores com implementações diferentes chegariam a resultados diferentes — a regra só vale porque todos concordam em usar a mesma.

Parte 2: inscrições

Uma inscrição anexa conteúdo (imagem, texto, HTML, áudio) a um satoshi específico, gravando os bytes no witness de uma transação Taproot, dentro de um envelope que o Bitcoin ignora:

OP_FALSE
OP_IF
  OP_PUSH "ord"          # marcador do protocolo
  OP_PUSH 1              # campo: content-type
  OP_PUSH "image/png"
  OP_PUSH 0              # campo: corpo
  OP_PUSH <bytes do arquivo>
OP_ENDIF

O OP_FALSE OP_IF faz o bloco inteiro nunca ser executado — para o consenso, é dado inerte. Para o indexador, é a inscrição.

O processo tem duas transações, e entender isso evita erro caro:

# 1) COMMIT: cria uma saída Taproot comprometida com o script da inscrição
# 2) REVEAL: gasta essa saída revelando o script — é aqui que o dado entra na cadeia

ord wallet inscribe --fee-rate 15 --file arte.png
# retorna: commit txid, reveal txid e o id da inscrição (<txid>i<índice>)

ord wallet inscriptions
ord wallet send --fee-rate 12 <endereco> <id-da-inscricao>

O detalhe que faz gente perder dinheiro

Uma inscrição vive em um satoshi. Se a sua carteira tratar esse satoshi como troco comum, ela pode gastá-lo pagando taxa de rede — e sua inscrição some para dentro de um minerador.

# Proteja o UTXO da inscrição contra gasto acidental
bitcoin-cli lockunspent false '[{"txid":"<txid>","vout":0}]'
bitcoin-cli listlockunspent

# Nunca use carteira comum para inscrições: use uma que entenda controle de sats
ord wallet balance     # separa cardinal (gastável) de ordinal (protegido)

Use uma carteira com suporte a Ordinals e mantenha os fundos separados. Carteira comum não sabe o que é sat inscrito.

Efeitos na rede

Inscrições disputam espaço em bloco com transações financeiras. Em momentos de pico, isso elevou taxas de forma perceptível e encheu o mempool — o que gerou (e ainda gera) uma discussão legítima na comunidade sobre uso "adequado" do espaço de bloco.

bitcoin-cli getmempoolinfo | jq '{size, bytes, mempoolminfee}'
bitcoin-cli estimatesmartfee 6

10. Runes: tokens fungíveis nativos do Bitcoin

Antes das Runes, a forma de criar token fungível no Bitcoin era o BRC-20: inscrições com um JSON dizendo "criei", "mintei", "transferi". Funciona, mas com dois problemas sérios: cada operação é uma inscrição (lixo em witness) e o saldo depende inteiramente de um indexador externo interpretar texto.

Runes, também de Casey Rodarmor, foi lançado no bloco 840.000 — o halving de abril de 2024 — para resolver isso de forma nativa ao modelo UTXO.

Como funciona

O protocolo grava um runestone em uma saída OP_RETURN (dado no corpo da transação, não no witness), e os saldos vivem nos próprios UTXOs.

OP_RETURN
OP_13                # marcador do protocolo Runes
<payload>            # campos codificados: etching, mint, edicts, pointer

Três operações compõem todo o ciclo de vida:

• Etching — cria a rune: nome, símbolo, divisibilidade, supply e as regras de emissão.
• Minting — cunha unidades, respeitando os termos definidos no etching.
• Transfer (edict) — move saldo entre saídas da própria transação.

# Etching: criar uma rune com termos de emissão abertos
ord wallet batch --fee-rate 20 --batch etching.yaml

# etching.yaml
# mode: separate-outputs
# etching:
#   rune: MINHA•PRIMEIRA•RUNE
#   divisibility: 2
#   premine: 1000
#   symbol: ¤
#   supply: 21000
#   terms:
#     amount: 100
#     cap: 200

ord wallet mint --fee-rate 15 --rune MINHA•PRIMEIRA•RUNE
ord wallet send --fee-rate 15 <endereco> 500:MINHA•PRIMEIRA•RUNE
ord wallet balance     # mostra sats e runes por UTXO

Detalhes que importam

• Nomes usam apenas letras maiúsculas de A a Z, com um separador visual (•) que não faz parte da identidade. Nomes curtos foram propositalmente reservados: eles só se tornam disponíveis ao longo do tempo, para evitar que tudo fosse tomado nos primeiros blocos.
• Divisibilidade define as casas decimais, como os 8 do próprio bitcoin.
• Premine é a parte que o criador reserva para si no etching — é o primeiro número que qualquer pessoa deveria olhar antes de tocar em uma rune.
• Terms definem quanto cada mint entrega (amount), quantos mints existem (cap) e em que janela de blocos eles são permitidos.
• Cenotaph é um runestone malformado. A regra de segurança do protocolo é dura e proposital: em caso de erro de codificação, as runes envolvidas são queimadas, não devolvidas. Bug de implementação aqui destrói saldo.

Por que Runes é tecnicamente melhor que BRC-20

Ambos, porém, dividem a mesma característica fundamental: o consenso do Bitcoin não valida nenhum dos dois. Um nó Bitcoin vê apenas transações comuns. Toda a semântica de token vive nos indexadores.

11. Comparativo: Runes, BRC-20, RGB e Liquid

Para RWA sobre Bitcoin, os candidatos sérios são Liquid e Taproot Assets — não Runes. Ativo regulado precisa de emissão controlada, confidencialidade e capacidade de congelamento, e nada disso existe em um protocolo baseado em OP_RETURN público.

12. Riscos, críticas e o debate real

Documentação honesta inclui o contra.

Sobre Ordinals e Runes:

• Não há garantia de consenso. Se os indexadores divergirem, seu saldo "existe" em um e não no outro. Não há juiz on-chain.
• Espaço de bloco é escasso. Cada inscrição compete com pagamentos. Parte relevante da comunidade considera isso abuso; outra considera uso legítimo de um mercado aberto de taxas. Os dois lados têm argumento técnico.
• Perda por descuido é comum. Gastar um sat inscrito como troco é irreversível.
• Cenotaph queima saldo. Codificação errada não dá erro amigável — destrói.
• Liquidez e especulação. A maioria dos ativos desse universo tem liquidez muito baixa e volatilidade extrema.

Sobre RWAs:

• Risco de contraparte volta pela porta dos fundos. Você trocou "confiar no banco" por "confiar no emissor, no custodiante e no oráculo".
• Chave de administração. Contratos de RWA quase sempre têm função de pausa e confisco. É requisito regulatório — e ponto central de confiança.
• Regulação em movimento. Regras mudam entre jurisdições e ao longo do tempo. O que é permitido hoje pode exigir registro amanhã.
• Liquidez prometida raramente aparece. Tokenizar não cria comprador.

A crítica mais dura, e a mais útil: a esmagadora maioria dos projetos que se dizem blockchain não precisa de blockchain. Se existe uma empresa central que emite, custodia, resolve disputa e pode reverter operação, você construiu um banco de dados caro e lento com marketing melhor. Isso não invalida a tecnologia — invalida o uso errado dela.

13. Por onde começar como desenvolvedor

O caminho que mais ensina, em ordem:

# 1. Rode um nó. É aqui que a ficha cai: você passa a verificar em vez de acreditar.
bitcoind -daemon -txindex=1
bitcoin-cli getblockchaininfo

# 2. Trabalhe em testnet/signet — dinheiro de teste, erro sem custo
bitcoind -signet -daemon
bitcoin-cli -signet getnewaddress

# 3. Suba um indexador Ordinals/Runes e observe a cadeia
ord --signet server --http-port 8080

# 4. Inscreva e crie uma rune em signet antes de qualquer coisa em mainnet
ord --signet wallet inscribe --fee-rate 1 --file teste.txt

Para o lado de contratos e RWA:

# Ambiente local de EVM, sem gastar nada
npm install --save-dev hardhat
npx hardhat node                 # cadeia local
npx hardhat test                 # testes do contrato

# Padrões que valem estudar antes de escrever do zero:
# ERC-20, ERC-721 (base) · ERC-3643 e ERC-1400 (ativos regulados)
# OpenZeppelin (implementações auditadas) · Chainlink (oráculos e prova de reserva)

E as três regras que evitam prejuízo enquanto você aprende:

1. Signet e testnet primeiro, sempre. Erro em mainnet não tem desfazer.
2. Separe carteiras. Uma para estudo, uma para uso — e valores relevantes só em hardware wallet.
3. Nunca exponha a seed. Nenhum site legítimo pede sua frase de recuperação. Nenhum.

Fechando

Blockchain é uma ferramenta com um custo altíssimo — de performance, de energia ou de capital — que compra uma propriedade específica: acordo verificável entre partes sem confiança mútua. Quando você precisa disso, não há substituto. Quando não precisa, qualquer banco de dados é melhor em todos os aspectos.

RWAs são o teste mais honesto dessa proposta, porque expõem exatamente onde a tecnologia acaba e o direito começa. Ordinals e Runes são a demonstração mais interessante de outro fenômeno: como uma rede propositalmente limitada acabou usada de um jeito que ninguém previu, a partir de recursos criados para outra finalidade.

Entender os dois casos ensina mais sobre sistemas distribuídos do que qualquer white paper — inclusive sobre quando não usá-los.