Blockchain, RWAs and Bitcoin: A Technical Guide to Ordinals and Runes

There is a lot of content about blockchain that is either investment hype or an impenetrable academic paper. This one tries to be the third thing: technical documentation for people who write code and want to understand what these technologies actually do, where they solve a real problem and where they are the wrong tool.

Three subjects, in order of abstraction:

1. Blockchain — what the distributed ledger is, why it is expensive and what problem it really solves.
2. RWAs — tokenizing real-world assets: where the promise meets legal reality.
3. Ordinals and Runes — how Bitcoin, which has no smart contracts, got NFTs and fungible tokens.

This is not investment advice. It is technical documentation. Nothing here suggests buying, selling or holding any asset — and the final section is precisely about the risks.

Contents

• 1 · What blockchain is, without the mysticism
• 2 · Consensus: how strangers agree
• 3 · What blockchain solves — and what it does not
• 4 · Layers: L1, L2 and rollups
• 5 · Tokens: fungible and non-fungible
• 6 · RWAs: tokenizing the real world
• 7 · The architecture of an RWA project
• 8 · Bitcoin from the inside: UTXO, script and Taproot
• 9 · Ordinals: numbering satoshis and inscribing data
• 10 · Runes: fungible tokens native to Bitcoin
• 11 · Comparison: Runes, BRC-20, RGB and Liquid
• 12 · Risks, criticism and the real debate
• 13 · Where to start as a developer

1. What blockchain is, without the mysticism

A blockchain is an append-only, replicated, ownerless database, in which the order of the records is agreed on by participants who do not trust each other.

Technically, three pieces:

• Blocks chained by hash. Each block carries the hash of the previous one. Altering an old record changes that block's hash, which invalidates every block after it.
• Digital signature. Each transaction is signed by the owner's private key. Nobody moves what is not theirs, and nobody needs a central registry to prove it.
• A consensus rule. A procedure that makes thousands of nodes, none of which know each other, arrive at the same ordering of transactions.

# The chain of hashes, in practice (Bitcoin Core)
bitcoin-cli getblockhash 840000
bitcoin-cli getblock 0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5 1
# the "previousblockhash" field links this block to the previous one

The Merkle tree is what allows you to prove a transaction is in a block without downloading the whole block — the basis of any light client:

bitcoin-cli gettxoutproof '["<txid>"]'    # proof of inclusion
bitcoin-cli verifytxoutproof "<proof>"     # verification

What makes a blockchain different from a replicated database: in a database, the administrator is in charge. On a public blockchain, nobody is — the rule is the code every node runs, and changing that rule requires convincing the entire network.

2. Consensus: how strangers agree

Proof of Work (Bitcoin)

Miners compete to find a nonce that makes the block's hash fall below a target. Finding it is expensive (energy), verifying it is instantaneous. The valid chain is the one that has accumulated the most work.

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

The energy spend is not a side effect: it is the mechanism itself. Rewriting history requires redoing the work of every subsequent block, faster than the entire network. The cost is the security.

Proof of Stake (Ethereum and most modern networks)

Validators deposit capital as collateral. Anyone validating an invalid block loses part of the deposit (slashing). The cost stops being energy and becomes locked-up capital.

Finality is the concept that most confuses people coming from databases: on Bitcoin, a transaction is never 100% irreversible — it only becomes exponentially unlikely to be reversed with each block. That is why exchanges wait for confirmations.

3. What blockchain solves — and what it does not

It solves well:

• Transferring value between parties who do not trust each other, with no intermediary.
• A public record, verifiable by anyone, without depending on the word of whoever maintains it.
• Rules that execute on their own, with nobody able to change the outcome afterwards.
• Censorship resistance: no single participant can prevent a valid transaction.

It does not solve:

• False data on the way in. If you record "this property is worth R$ 800,000" and the data is a lie, the blockchain keeps the lie with perfect integrity. This is the oracle problem, and it is fundamental — no chain can verify the physical world on its own.
• Performance. A relational database on an ordinary server does tens of thousands of writes per second. Bitcoin does about 7 transactions per second. That is not a lack of optimisation: it is the price of thousands of nodes validating everything again.
• Privacy. A public blockchain is radically transparent. Every balance and every transfer stays visible forever.
• Human error. A lost key is lost funds. A transfer to the wrong address is irreversible. There is no support line to call.

The question that separates a serious project from technological theatre: is there more than one party, without mutual trust, that needs to agree on the same state? If the answer is no, a Postgres with an audit log solves it better, cheaper and faster.

4. Layers: L1, L2 and rollups

• L1 (base layer) — Bitcoin, Ethereum. Maximum security, minimum capacity, high cost.
• L2 (second layer) — processes off-chain and anchors to the L1. Lightning Network (Bitcoin), Arbitrum and Optimism (Ethereum).
• Rollup — executes transactions off the L1 and publishes the data or the proof on the L1. Optimistic assumes validity and opens a challenge window; ZK publishes cryptographic proof that the execution is correct.
• Sidechain — a separate chain with its own consensus and a bridge to the L1. It inherits less security (Liquid, Rootstock).

# Lightning: a payment channel off-chain, settled on the 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

The rule of thumb: the further you get from the L1, the cheaper and faster it is — and the more extra trust you have to assume.

5. Tokens: fungible and non-fungible

• Fungible — each unit is worth the same as any other (a stablecoin, a fund share). On Ethereum: ERC-20.
• Non-fungible (NFT) — each unit is unique and identifiable (a property deed, a certificate). On Ethereum: ERC-721.

// ERC-20: the essentials of the fungible interface
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);
}

For RWAs there is a third family, that of permissioned tokens, in which a transfer only happens if both parties are cleared:

// ERC-3643 (T-REX): a transfer subject to identity verification
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);
}

That is the central difference between "free" crypto and a regulated asset: the token of a financial asset needs to know who is on the other side.

6. RWAs: tokenizing the real world

An RWA (Real World Asset) is the on-chain representation of an asset that exists outside it: a government bond, a fund share, a receivable, a property, private credit, a commodity.

What tokenization actually delivers

• Fractionalisation. A R$ 2 million property becomes 2 million units. It cuts the minimum ticket drastically.
• Near-instant settlement. No T+2: transferring the token is the settlement.
• Continuous operation. The ledger does not close at 5 p.m. or at the weekend.
• Composability. The token can be used as collateral in another protocol without asking permission.
• Transparency of backing. An audit can be published continuously instead of quarterly.

Where the promise meets reality

Here is what most promotional texts leave out:

1. The token is not the asset. It is a claim on the asset, and that claim lives in the legal contract, not in the code. If the issuer goes under, the smart contract keeps working perfectly — and with no backing at all.
2. Custody is the weak link. Somebody stores the property, the bond, the gold. That somebody is a central point of trust, exactly what the blockchain was supposed to eliminate.
3. The oracle sets the price. If the price source is manipulated or goes offline, everything depending on it breaks with it.
4. Regulation rules. A fund share is a security, whether it sits in a registry office or on a blockchain. Issuing without registration is an irregular offering.
5. Liquidity does not come from the token. Tokenizing an illiquid asset generally produces an illiquid token. The market of buyers has to exist.

The landscape, by category

The cases that worked share a clear pattern: they work better the more standardised, liquid and regulated the original asset is. Tokenized government bonds thrived; fractional real estate is still hard — not because of a technical limitation, but because the problem was never technological.

In Brazil

• The CVM has already taken a position: a token representing a collective investment with an expectation of profit is a security and follows the usual rules.
• The CVM's regulatory sandbox has been used by issuers to test the tokenization of receivables under supervision.
• Drex, from the Central Bank, is the most relevant piece: a tokenized settlement infrastructure in which the money and the asset change hands in the same event (delivery versus payment), removing counterparty risk at settlement.
• Tokenizing receivables and credit is the segment with real traction in the country — not by chance, it is where the asset is already standardised and the problem (expensive, bureaucratic receivable financing) is concrete.

7. The architecture of an RWA project

From the point of view of whoever builds it, a serious project always has these layers:

[ Asset in the real world ]  property, bond, receivable
        │
[ Legal structure         ]  SPV, fund, assignment contract — who is legally answerable
        │
[ Custody                 ]  who holds the asset and answers for it
        │
[ Oracle / attestation    ]  price, proof of reserve, asset status
        │
[ Token                   ]  permissioned contract (ERC-3643, ERC-1400)
        │
[ Compliance              ]  KYC/AML, allowlist, limits per jurisdiction
        │
[ Distribution            ]  platform, wallet, secondary market

The code is the smallest part of the problem. A permissioned token contract is a few hundred lines; the legal structure and the custody take months.

Proof of reserve

Without this, the token is an unverifiable promise:

// Query a proof-of-reserve feed before allowing issuance
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);
}

Note the require on the age: a stale oracle is as dangerous as a wrong one, and forgetting that check is one of the most common findings in an audit.

Questions for evaluating any RWA project

1. Who is legally answerable if the asset disappears? Is there a registered company and a contract?
2. Where is the asset and who audits the custody — how often?
3. What happens if the issuer stops operating? Is there a redemption plan?
4. Is the token transferable to anyone or is there an allowlist? Who controls it?
5. Which oracle feeds the price and what happens if it fails?
6. Does the contract have a pause, freeze or seizure function? Who holds that key?

The last question is decisive: nearly every regulated RWA token does have a freeze function — the law requires it. That is not a flaw, it is a requirement. But you need to know it exists, and who holds the key.

8. Bitcoin from the inside: UTXO, script and Taproot

To understand Ordinals and Runes you have to understand three things about Bitcoin.

The UTXO model

Bitcoin does not have accounts with balances. It has UTXOs (Unspent Transaction Outputs): pieces of coin, each with a value and a spending condition. A transaction consumes whole UTXOs and creates new ones.

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

# Each UTXO is spent whole; the change comes back as a new UTXO
bitcoin-cli gettxout "<txid>" 0

That is exactly what makes it possible to track individual satoshis: since each UTXO has an identifiable origin, you can follow the trail of any fraction.

Script

Each output carries a script defining the spending condition. It is deliberately not Turing-complete: no loops, no global state, no contract calls.

# OP_RETURN: a deliberately unspendable output, used to record data
bitcoin-cli createrawtransaction \
  '[{"txid":"<txid>","vout":0}]' \
  '[{"data":"48656c6c6f"}]'

SegWit and Taproot: what unlocked everything

Two upgrades prepared the ground, without that being the aim:

• SegWit (2017) separated the signature (witness) from the body of the transaction and gave it a weight discount: data in the witness costs about 1/4 of what it would cost in the body.
• Taproot (2021) brought the script path, allowing an arbitrary script to be revealed at spending time — with no practical size limit for the embedded data.

Put the two together: it became viable to put a file inside a Bitcoin transaction, paying a discounted fee. Nobody designed this with images in mind — it was an emergent consequence. That distinction sits at the heart of all the controversy that followed.

9. Ordinals: numbering satoshis and inscribing data

Ordinals is a protocol created by Casey Rodarmor and launched in January 2023. It has two independent parts, and confusing them is the most common mistake.

Part 1: ordinal theory

Each satoshi gets a serial number, assigned by the order in which it was mined, and is tracked across transactions by the first-in-first-out rule: the first satoshis in are the first satoshis out.

# Numbering and locating a specific satoshi
ord list <outpoint>              # which sats are in this UTXO
ord find 1234567890              # which UTXO holds sat number N
ord traits 1234567890            # rarity: uncommon, rare, epic, legendary

Note this: it is a convention, not consensus. The Bitcoin network has no idea what an ordinal is. The indexer running that rule over the chain is what knows. Two indexers with different implementations would reach different results — the rule only holds because everyone agrees to use the same one.

Part 2: inscriptions

An inscription attaches content (an image, text, HTML, audio) to a specific satoshi, writing the bytes into the witness of a Taproot transaction, inside an envelope that Bitcoin ignores:

OP_FALSE
OP_IF
  OP_PUSH "ord"          # protocol marker
  OP_PUSH 1              # field: content-type
  OP_PUSH "image/png"
  OP_PUSH 0              # field: body
  OP_PUSH <file bytes>
OP_ENDIF

The OP_FALSE OP_IF means the whole block is never executed — as far as consensus is concerned, it is inert data. To the indexer, it is the inscription.

The process takes two transactions, and understanding this avoids an expensive mistake:

# 1) COMMIT: creates a Taproot output committed to the inscription's script
# 2) REVEAL: spends that output revealing the script — this is where the data enters the chain

ord wallet inscribe --fee-rate 15 --file arte.png
# returns: commit txid, reveal txid and the inscription id (<txid>i<index>)

ord wallet inscriptions
ord wallet send --fee-rate 12 <address> <inscription-id>

The detail that makes people lose money

An inscription lives on a satoshi. If your wallet treats that satoshi as ordinary change, it can spend it paying a network fee — and your inscription vanishes into a miner.

# Protect the inscription's UTXO from being spent by accident
bitcoin-cli lockunspent false '[{"txid":"<txid>","vout":0}]'
bitcoin-cli listlockunspent

# Never use an ordinary wallet for inscriptions: use one that understands sat control
ord wallet balance     # separates cardinal (spendable) from ordinal (protected)

Use a wallet with Ordinals support and keep the funds separate. An ordinary wallet has no idea what an inscribed sat is.

Effects on the network

Inscriptions compete for block space with financial transactions. At peak moments this raised fees noticeably and filled the mempool — which generated (and still generates) a legitimate discussion in the community about the "appropriate" use of block space.

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

10. Runes: fungible tokens native to Bitcoin

Before Runes, the way to create a fungible token on Bitcoin was BRC-20: inscriptions with a JSON saying "deployed", "minted", "transferred". It works, but with two serious problems: each operation is an inscription (junk in the witness) and the balance depends entirely on an external indexer interpreting text.

Runes, also from Casey Rodarmor, launched at block 840,000 — the April 2024 halving — to solve this natively within the UTXO model.

How it works

The protocol writes a runestone into an OP_RETURN output (data in the body of the transaction, not in the witness), and the balances live in the UTXOs themselves.

OP_RETURN
OP_13                # the Runes protocol marker
<payload>            # encoded fields: etching, mint, edicts, pointer

Three operations make up the whole life cycle:

• Etching — creates the rune: name, symbol, divisibility, supply and the issuance rules.
• Minting — mints units, respecting the terms defined at etching.
• Transfer (edict) — moves the balance between outputs of the transaction itself.

# Etching: creating a rune with open issuance terms
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 <address> 500:MINHA•PRIMEIRA•RUNE
ord wallet balance     # shows sats and runes per UTXO

Details that matter

• Names use only capital letters from A to Z, with a visual separator (•) that is not part of the identity. Short names were reserved on purpose: they only become available over time, to prevent everything being taken in the first blocks.
• Divisibility sets the decimal places, like bitcoin's own 8.
• Premine is the part the creator reserves for themselves at etching — it is the first number anybody should look at before touching a rune.
• Terms define how much each mint delivers (amount), how many mints exist (cap) and in which window of blocks they are allowed.
• Cenotaph is a malformed runestone. The protocol's safety rule is harsh and deliberate: in case of an encoding error, the runes involved are burned, not returned. An implementation bug here destroys balance.

Why Runes is technically better than BRC-20

Both, however, share the same fundamental trait: Bitcoin's consensus validates neither of them. A Bitcoin node sees only ordinary transactions. All the token semantics live in the indexers.

11. Comparison: Runes, BRC-20, RGB and Liquid

For RWAs on Bitcoin, the serious candidates are Liquid and Taproot Assets — not Runes. A regulated asset needs controlled issuance, confidentiality and the ability to freeze, and none of that exists in a protocol based on a public OP_RETURN.

12. Risks, criticism and the real debate

Honest documentation includes the counter-argument.

On Ordinals and Runes:

• There is no guarantee of consensus. If the indexers diverge, your balance "exists" on one and not on the other. There is no on-chain judge.
• Block space is scarce. Each inscription competes with payments. A significant part of the community considers this abuse; another considers it legitimate use of an open fee market. Both sides have a technical argument.
• Loss through carelessness is common. Spending an inscribed sat as change is irreversible.
• A cenotaph burns balance. Wrong encoding does not give a friendly error — it destroys.
• Liquidity and speculation. Most assets in this universe have very low liquidity and extreme volatility.

On RWAs:

• Counterparty risk comes back through the side door. You swapped "trusting the bank" for "trusting the issuer, the custodian and the oracle".
• The admin key. RWA contracts almost always have a pause and seizure function. It is a regulatory requirement — and a central point of trust.
• Regulation in motion. Rules change between jurisdictions and over time. What is allowed today may require registration tomorrow.
• The promised liquidity rarely shows up. Tokenizing does not create a buyer.

The harshest criticism, and the most useful: the overwhelming majority of projects that call themselves blockchain do not need blockchain. If there is a central company that issues, custodies, resolves disputes and can reverse an operation, you have built an expensive, slow database with better marketing. That does not invalidate the technology — it invalidates the wrong use of it.

13. Where to start as a developer

The path that teaches the most, in order:

# 1. Run a node. This is where it clicks: you start verifying instead of believing.
bitcoind -daemon -txindex=1
bitcoin-cli getblockchaininfo

# 2. Work on testnet/signet — play money, mistakes at no cost
bitcoind -signet -daemon
bitcoin-cli -signet getnewaddress

# 3. Stand up an Ordinals/Runes indexer and watch the chain
ord --signet server --http-port 8080

# 4. Inscribe and create a rune on signet before doing anything on mainnet
ord --signet wallet inscribe --fee-rate 1 --file teste.txt

For the contracts and RWA side:

# A local EVM environment, spending nothing
npm install --save-dev hardhat
npx hardhat node                 # local chain
npx hardhat test                 # contract tests

# Standards worth studying before writing from scratch:
# ERC-20, ERC-721 (base) · ERC-3643 and ERC-1400 (regulated assets)
# OpenZeppelin (audited implementations) · Chainlink (oracles and proof of reserve)

And the three rules that prevent losses while you learn:

1. Signet and testnet first, always. A mistake on mainnet has no undo.
2. Separate your wallets. One for study, one for use — and meaningful amounts only on a hardware wallet.
3. Never expose the seed. No legitimate site asks for your recovery phrase. None.

Wrapping up

Blockchain is a tool with an extremely high cost — in performance, in energy or in capital — that buys one specific property: verifiable agreement between parties without mutual trust. When you need that, there is no substitute. When you do not, any database is better in every respect.

RWAs are the most honest test of that proposition, because they expose exactly where the technology ends and the law begins. Ordinals and Runes are the most interesting demonstration of another phenomenon: how a deliberately limited network ended up used in a way nobody foresaw, out of features created for another purpose.

Understanding both cases teaches more about distributed systems than any white paper — including about when not to use them.