Blockchain, RWAs y Bitcoin: Guía Técnica de Ordinals y Runes

Existe mucho contenido sobre blockchain que es o bien hype de inversión, o bien un artículo académico impenetrable. Este intenta ser la tercera cosa: documentación técnica para quien programa y quiere entender qué hacen de verdad estas tecnologías, dónde resuelven un problema real y dónde son la herramienta equivocada.

Tres asuntos, en orden de abstracción:

1. Blockchain — qué es el registro distribuido, por qué es caro y qué problema resuelve realmente.
2. RWAs — tokenización de activos del mundo real: dónde la promesa choca con la realidad jurídica.
3. Ordinals y Runes — cómo Bitcoin, que no tiene contratos inteligentes, obtuvo NFTs y tokens fungibles.

Esto no es una recomendación de inversión. Es documentación técnica. Nada de lo que hay aquí sugiere comprar, vender o mantener ningún activo — y la parte final trata justamente de los riesgos.

Índice

• 1 · Qué es blockchain, sin misticismo
• 2 · Consenso: cómo se ponen de acuerdo unos desconocidos
• 3 · Qué resuelve blockchain — y qué no
• 4 · Capas: L1, L2 y rollups
• 5 · Tokens: fungibles y no fungibles
• 6 · RWAs: tokenizar el mundo real
• 7 · Arquitectura de un proyecto de RWA
• 8 · Bitcoin por dentro: UTXO, script y Taproot
• 9 · Ordinals: numerar satoshis e inscribir datos
• 10 · Runes: tokens fungibles nativos de Bitcoin
• 11 · Comparativa: Runes, BRC-20, RGB y Liquid
• 12 · Riesgos, críticas y el debate real
• 13 · Por dónde empezar como desarrollador

1. Qué es blockchain, sin misticismo

Una blockchain es una base de datos append-only, replicada y sin dueño, en la que el orden de los registros lo acuerdan participantes que no confían entre sí.

Técnicamente, tres piezas:

• Bloques encadenados por hash. Cada bloque lleva el hash del anterior. Alterar un registro antiguo cambia el hash de ese bloque, lo que invalida todos los siguientes.
• Firma digital. Cada transacción va firmada con la clave privada del dueño. Nadie mueve lo que no es suyo, y nadie necesita un registro central para demostrarlo.
• Regla de consenso. Un procedimiento que hace que miles de nodos, sin conocerse, lleguen al mismo orden de transacciones.

# La cadena de hashes, en la práctica (Bitcoin Core)
bitcoin-cli getblockhash 840000
bitcoin-cli getblock 0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5 1
# el campo "previousblockhash" enlaza este bloque con el anterior

El árbol de Merkle es lo que permite demostrar que una transacción está en un bloque sin descargar el bloque entero — la base de cualquier cliente ligero:

bitcoin-cli gettxoutproof '["<txid>"]'    # prueba de inclusión
bitcoin-cli verifytxoutproof "<prueba>"     # verificación

Lo que hace distinta a una blockchain de una base de datos replicada: en una base de datos, manda el administrador. En una blockchain pública, no manda nadie — la regla es el código que ejecutan todos los nodos, y cambiar esa regla exige convencer a la red entera.

2. Consenso: cómo se ponen de acuerdo unos desconocidos

Proof of Work (Bitcoin)

Los mineros compiten por encontrar un nonce que haga que el hash del bloque quede por debajo de un objetivo. Encontrarlo es caro (energía), verificarlo es instantáneo. La cadena válida es la que ha acumulado más trabajo.

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

El gasto de energía no es un efecto colateral: es el mecanismo mismo. Reescribir la historia exige rehacer el trabajo de todos los bloques posteriores, más rápido que la red entera. El coste es la seguridad.

Proof of Stake (Ethereum y la mayoría de las redes modernas)

Los validadores depositan capital como garantía. Quien valida un bloque inválido pierde parte del depósito (slashing). El coste deja de ser energía y pasa a ser capital bloqueado.

Finalidad es el concepto que más confunde a quien viene de las bases de datos: en Bitcoin, una transacción nunca es 100% irreversible — solo se vuelve exponencialmente improbable de revertir con cada bloque. Por eso los exchanges esperan confirmaciones.

3. Qué resuelve blockchain — y qué no

Resuelve bien:

• Transferir valor entre partes que no confían la una en la otra, sin intermediario.
• Un registro público, verificable por cualquiera, sin depender de la palabra de quien lo mantiene.
• Reglas que se ejecutan solas, sin que nadie pueda cambiar el resultado después.
• Resistencia a la censura: ningún participante aislado consigue impedir una transacción válida.

No resuelve:

• El dato falso en la entrada. Si registras "este inmueble vale 800 mil reales" y el dato es mentira, la blockchain guarda la mentira con una integridad perfecta. Es el problema del oráculo, y es fundamental — ninguna cadena puede verificar el mundo físico por sí sola.
• El rendimiento. Una base relacional en un servidor corriente hace decenas de miles de escrituras por segundo. Bitcoin hace unas 7 transacciones por segundo. No es falta de optimización: es el precio de que miles de nodos lo validen todo otra vez.
• La privacidad. Una blockchain pública es radicalmente transparente. Todo saldo y toda transferencia quedan visibles para siempre.
• El error humano. Una clave perdida son fondos perdidos. Una transferencia a la dirección equivocada es irreversible. No hay un soporte al que llamar.

La pregunta que separa un proyecto serio del teatro tecnológico: ¿hay más de una parte, sin confianza mutua, que necesite ponerse de acuerdo sobre el mismo estado? Si la respuesta es no, un Postgres con log de auditoría lo resuelve mejor, más barato y más rápido.

4. Capas: L1, L2 y rollups

• L1 (capa base) — Bitcoin, Ethereum. Seguridad máxima, capacidad mínima, coste alto.
• L2 (segunda capa) — procesa fuera y ancla en la L1. Lightning Network (Bitcoin), Arbitrum y Optimism (Ethereum).
• Rollup — ejecuta transacciones fuera de la L1 y publica en la L1 los datos o la prueba. El optimistic asume la validez y abre una ventana de impugnación; el ZK publica una prueba criptográfica de que la ejecución es correcta.
• Sidechain — cadena aparte con consenso propio y un puente hacia la L1. Hereda menos seguridad (Liquid, Rootstock).

# Lightning: canal de pago fuera de la cadena, liquidación en la 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

La regla práctica: cuanto más lejos de la L1, más barato y más rápido — y más confianza extra tienes que asumir.

5. Tokens: fungibles y no fungibles

• Fungible — cada unidad vale lo mismo que cualquier otra (una stablecoin, una participación de un fondo). En Ethereum: ERC-20.
• No fungible (NFT) — cada unidad es única e identificable (la escritura de un inmueble, un certificado). En Ethereum: ERC-721.

// ERC-20: lo esencial de la interfaz fungible
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 los RWA existe una tercera familia, la de los tokens permisionados, en la que la transferencia solo ocurre si ambas partes están habilitadas:

// ERC-3643 (T-REX): transferencia sujeta a verificación de identidad
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);
}

Esa es la diferencia central entre la cripto "libre" y un activo regulado: el token de un activo financiero necesita saber quién está al otro lado.

6. RWAs: tokenizar el mundo real

Un RWA (Real World Asset) es la representación, en blockchain, de un activo que existe fuera de ella: un bono público, una participación de un fondo, un derecho de cobro, un inmueble, crédito privado, una materia prima.

Qué entrega realmente la tokenización

• Fraccionamiento. Un inmueble de 2 millones se convierte en 2 millones de unidades. Reduce drásticamente el ticket mínimo.
• Liquidación casi instantánea. Sin T+2: la transferencia del token es la liquidación.
• Operación continua. El registro no cierra a las cinco de la tarde ni el fin de semana.
• Componibilidad. El token puede usarse como garantía en otro protocolo sin pedir autorización.
• Transparencia del respaldo. La auditoría puede publicarse de forma continua en lugar de trimestral.

Dónde la promesa choca con la realidad

Aquí está lo que la mayoría de los textos promocionales omite:

1. El token no es el activo. Es un derecho sobre el activo, y ese derecho vive en el contrato jurídico, no en el código. Si el emisor quiebra, el smart contract sigue funcionando perfectamente — y sin ningún respaldo.
2. La custodia es el eslabón débil. Alguien guarda el inmueble, el bono, el oro. Ese alguien es un punto central de confianza, exactamente lo que la blockchain debería eliminar.
3. El oráculo define el precio. Si la fuente de precio se manipula o se cae, todo lo que depende de ella se rompe con ella.
4. Manda la regulación. Una participación de un fondo es un valor mobiliario, esté en un registro o en una blockchain. Emitir sin registro es una oferta irregular.
5. La liquidez no nace del token. Tokenizar un activo ilíquido produce por lo general un token ilíquido. El mercado comprador tiene que existir.

El panorama, por categorías

Los casos que salieron bien comparten un patrón claro: funcionan mejor cuanto más estandarizado, líquido y regulado sea el activo original. La deuda pública tokenizada prosperó; la fracción de inmueble sigue siendo difícil — no por una limitación técnica, sino porque el problema nunca fue tecnológico.

En Brasil

• La CVM ya se ha posicionado: un token que representa una inversión colectiva con expectativa de beneficio es un valor mobiliario y sigue las reglas de siempre.
• El sandbox regulatorio de la CVM lo han usado emisores para probar la tokenización de derechos de cobro bajo supervisión.
• El Drex, del Banco Central, es la pieza más relevante: una infraestructura de liquidación tokenizada en la que el dinero y el activo cambian de manos en el mismo evento (delivery versus payment), eliminando el riesgo de contraparte en la liquidación.
• La tokenización de derechos de cobro y crédito es el segmento con tracción real en el país — no por casualidad, es donde el activo ya está estandarizado y el problema (anticipar cobros de forma cara y burocrática) es concreto.

7. Arquitectura de un proyecto de RWA

Desde el punto de vista de quien lo construye, un proyecto serio siempre tiene estas capas:

[ Activo en el mundo real ]  inmueble, bono, derecho de cobro
        │
[ Estructura jurídica     ]  SPV, fondo, contrato de cesión — quién responde legalmente
        │
[ Custodia                ]  quién guarda el activo y responde por él
        │
[ Oráculo / atestación    ]  precio, prueba de reservas, estado del activo
        │
[ Token                   ]  contrato permisionado (ERC-3643, ERC-1400)
        │
[ Compliance              ]  KYC/AML, allowlist, límites por jurisdicción
        │
[ Distribución            ]  plataforma, monedero, mercado secundario

El código es la menor parte del problema. Un contrato de token permisionado tiene unos cientos de líneas; la estructura jurídica y la custodia llevan meses.

Prueba de reservas

Sin esto, el token es una promesa no verificable:

// Consulta a un feed de prueba de reservas antes de permitir la emisión
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);
}

Fíjate en el require del plazo: un oráculo parado es tan peligroso como un oráculo equivocado, y olvidar esa comprobación es uno de los hallazgos más comunes en una auditoría.

Preguntas para evaluar cualquier proyecto de RWA

1. ¿Quién responde jurídicamente si el activo desaparece? ¿Hay una empresa registrada y un contrato?
2. ¿Dónde está el activo y quién audita la custodia — con qué frecuencia?
3. ¿Qué pasa si el emisor deja de operar? ¿Hay un plan de rescate?
4. ¿El token es transferible a cualquiera o hay allowlist? ¿Quién la controla?
5. ¿Qué oráculo alimenta el precio y qué pasa si falla?
6. ¿El contrato tiene función de pausa, congelación o confiscación? ¿Quién tiene esa clave?

La última pregunta es decisiva: casi todo token de RWA regulado tiene una función de congelación — la ley lo exige. Eso no es un fallo, es un requisito. Pero necesitas saber que existe, y quién tiene la clave.

8. Bitcoin por dentro: UTXO, script y Taproot

Para entender Ordinals y Runes hay que entender tres cosas de Bitcoin.

Modelo UTXO

Bitcoin no tiene cuentas con saldo. Tiene UTXOs (Unspent Transaction Outputs): trozos de moneda, cada uno con un valor y una condición de gasto. Una transacción consume UTXOs enteros y crea otros nuevos.

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

# Cada UTXO se gasta entero; el cambio vuelve como un UTXO nuevo
bitcoin-cli gettxout "<txid>" 0

Es exactamente eso lo que permite rastrear satoshis individuales: como cada UTXO tiene un origen identificable, se puede seguir el rastro de cualquier fracción.

Script

Cada salida lleva un script que define la condición de gasto. No es Turing-completo a propósito: sin bucles, sin estado global, sin llamadas a contratos.

# OP_RETURN: salida deliberadamente no gastable, usada para grabar datos
bitcoin-cli createrawtransaction \
  '[{"txid":"<txid>","vout":0}]' \
  '[{"data":"48656c6c6f"}]'

SegWit y Taproot: lo que lo desbloqueó todo

Dos actualizaciones prepararon el terreno, sin que ese fuera el objetivo:

• SegWit (2017) separó la firma (witness) del cuerpo de la transacción y le dio un descuento de peso: un dato en el witness cuesta aproximadamente 1/4 de lo que costaría en el cuerpo.
• Taproot (2021) trajo el script path, que permite revelar un script arbitrario en el momento del gasto — sin límite práctico de tamaño para el dato incrustado.

Junta las dos: se volvió viable meter un archivo dentro de una transacción de Bitcoin, pagando una comisión con descuento. Nadie diseñó esto pensando en imágenes — fue una consecuencia emergente. Esa distinción está en el centro de toda la polémica que vino después.

9. Ordinals: numerar satoshis e inscribir datos

Ordinals es un protocolo creado por Casey Rodarmor y lanzado en enero de 2023. Tiene dos partes independientes, y confundirlas es el error más común.

Parte 1: la teoría ordinal

Cada satoshi recibe un número de serie, asignado según el orden en que fue minado, y se rastrea en las transacciones con la regla first-in-first-out: los primeros satoshis que entran son los primeros que salen.

# Numeración y localización de un satoshi concreto
ord list <outpoint>              # qué sats hay en este UTXO
ord find 1234567890              # en qué UTXO está el sat número N
ord traits 1234567890            # rareza: uncommon, rare, epic, legendary

Fíjate: esto es convención, no consenso. La red Bitcoin no sabe qué es un ordinal. Quien lo sabe es el indexador que ejecuta esa regla sobre la cadena. Dos indexadores con implementaciones distintas llegarían a resultados distintos — la regla solo vale porque todos acuerdan usar la misma.

Parte 2: inscripciones

Una inscripción adjunta contenido (imagen, texto, HTML, audio) a un satoshi concreto, grabando los bytes en el witness de una transacción Taproot, dentro de un sobre que Bitcoin ignora:

OP_FALSE
OP_IF
  OP_PUSH "ord"          # marcador del protocolo
  OP_PUSH 1              # campo: content-type
  OP_PUSH "image/png"
  OP_PUSH 0              # campo: cuerpo
  OP_PUSH <bytes del archivo>
OP_ENDIF

El OP_FALSE OP_IF hace que el bloque entero no se ejecute nunca — para el consenso, es un dato inerte. Para el indexador, es la inscripción.

El proceso tiene dos transacciones, y entenderlo evita un error caro:

# 1) COMMIT: crea una salida Taproot comprometida con el script de la inscripción
# 2) REVEAL: gasta esa salida revelando el script — aquí es donde el dato entra en la cadena

ord wallet inscribe --fee-rate 15 --file arte.png
# devuelve: commit txid, reveal txid y el id de la inscripción (<txid>i<índice>)

ord wallet inscriptions
ord wallet send --fee-rate 12 <direccion> <id-de-la-inscripcion>

El detalle que hace que la gente pierda dinero

Una inscripción vive en un satoshi. Si tu monedero trata ese satoshi como cambio corriente, puede gastarlo pagando la comisión de red — y tu inscripción desaparece dentro de un minero.

# Protege el UTXO de la inscripción de un gasto accidental
bitcoin-cli lockunspent false '[{"txid":"<txid>","vout":0}]'
bitcoin-cli listlockunspent

# Nunca uses un monedero corriente para inscripciones: usa uno que entienda el control de sats
ord wallet balance     # separa cardinal (gastable) de ordinal (protegido)

Usa un monedero con soporte para Ordinals y mantén los fondos separados. Un monedero corriente no sabe qué es un sat inscrito.

Efectos en la red

Las inscripciones compiten por el espacio de bloque con las transacciones financieras. En los momentos punta, eso elevó las comisiones de forma perceptible y llenó el mempool — lo que generó (y sigue generando) una discusión legítima en la comunidad sobre el uso "adecuado" del espacio de bloque.

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

10. Runes: tokens fungibles nativos de Bitcoin

Antes de Runes, la forma de crear un token fungible en Bitcoin era el BRC-20: inscripciones con un JSON que decía "he creado", "he acuñado", "he transferido". Funciona, pero con dos problemas serios: cada operación es una inscripción (basura en el witness) y el saldo depende por completo de que un indexador externo interprete texto.

Runes, también de Casey Rodarmor, se lanzó en el bloque 840.000 — el halving de abril de 2024 — para resolverlo de forma nativa al modelo UTXO.

Cómo funciona

El protocolo graba un runestone en una salida OP_RETURN (dato en el cuerpo de la transacción, no en el witness), y los saldos viven en los propios UTXOs.

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

Tres operaciones componen todo el ciclo de vida:

• Etching — crea la rune: nombre, símbolo, divisibilidad, supply y las reglas de emisión.
• Minting — acuña unidades, respetando los términos definidos en el etching.
• Transfer (edict) — mueve saldo entre las salidas de la propia transacción.

# Etching: crear una rune con términos de emisión abiertos
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 <direccion> 500:MINHA•PRIMEIRA•RUNE
ord wallet balance     # muestra sats y runes por UTXO

Detalles que importan

• Los nombres usan solo letras mayúsculas de la A a la Z, con un separador visual (•) que no forma parte de la identidad. Los nombres cortos se reservaron a propósito: solo van quedando disponibles con el tiempo, para evitar que todo se tomara en los primeros bloques.
• La divisibilidad define los decimales, como los 8 del propio bitcoin.
• El premine es la parte que el creador se reserva en el etching — es el primer número que cualquiera debería mirar antes de tocar una rune.
• Los terms definen cuánto entrega cada mint (amount), cuántos mints existen (cap) y en qué ventana de bloques se permiten.
• Cenotaph es un runestone mal formado. La regla de seguridad del protocolo es dura y deliberada: en caso de error de codificación, las runes implicadas se queman, no se devuelven. Un bug de implementación aquí destruye saldo.

Por qué Runes es técnicamente mejor que BRC-20

Ambos, no obstante, comparten la misma característica fundamental: el consenso de Bitcoin no valida ninguno de los dos. Un nodo Bitcoin ve solo transacciones corrientes. Toda la semántica de token vive en los indexadores.

11. Comparativa: Runes, BRC-20, RGB y Liquid

Para RWA sobre Bitcoin, los candidatos serios son Liquid y Taproot Assets — no Runes. Un activo regulado necesita emisión controlada, confidencialidad y capacidad de congelación, y nada de eso existe en un protocolo basado en un OP_RETURN público.

12. Riesgos, críticas y el debate real

Una documentación honesta incluye la contra.

Sobre Ordinals y Runes:

• No hay garantía de consenso. Si los indexadores divergen, tu saldo "existe" en uno y no en el otro. No hay un juez on-chain.
• El espacio de bloque es escaso. Cada inscripción compite con los pagos. Una parte relevante de la comunidad lo considera un abuso; otra lo considera un uso legítimo de un mercado abierto de comisiones. Los dos lados tienen argumento técnico.
• La pérdida por descuido es común. Gastar un sat inscrito como cambio es irreversible.
• Un cenotaph quema saldo. Una codificación errónea no da un error amigable — destruye.
• Liquidez y especulación. La mayoría de los activos de este universo tiene una liquidez muy baja y una volatilidad extrema.

Sobre los RWAs:

• El riesgo de contraparte vuelve por la puerta de atrás. Cambiaste "confiar en el banco" por "confiar en el emisor, en el custodio y en el oráculo".
• La clave de administración. Los contratos de RWA casi siempre tienen función de pausa y confiscación. Es un requisito regulatorio — y un punto central de confianza.
• Regulación en movimiento. Las reglas cambian entre jurisdicciones y con el tiempo. Lo que hoy está permitido puede exigir registro mañana.
• La liquidez prometida rara vez aparece. Tokenizar no crea un comprador.

La crítica más dura, y la más útil: la abrumadora mayoría de los proyectos que se llaman blockchain no necesita blockchain. Si hay una empresa central que emite, custodia, resuelve disputas y puede revertir una operación, has construido una base de datos cara y lenta con mejor marketing. Eso no invalida la tecnología — invalida el uso equivocado de ella.

13. Por dónde empezar como desarrollador

El camino que más enseña, en orden:

# 1. Levanta un nodo. Aquí es donde cae la ficha: pasas a verificar en lugar de creer.
bitcoind -daemon -txindex=1
bitcoin-cli getblockchaininfo

# 2. Trabaja en testnet/signet — dinero de prueba, errores sin coste
bitcoind -signet -daemon
bitcoin-cli -signet getnewaddress

# 3. Levanta un indexador Ordinals/Runes y observa la cadena
ord --signet server --http-port 8080

# 4. Inscribe y crea una rune en signet antes de hacer nada en mainnet
ord --signet wallet inscribe --fee-rate 1 --file teste.txt

Para el lado de los contratos y los RWA:

# Entorno local de EVM, sin gastar nada
npm install --save-dev hardhat
npx hardhat node                 # cadena local
npx hardhat test                 # pruebas del contrato

# Estándares que conviene estudiar antes de escribir desde cero:
# ERC-20, ERC-721 (base) · ERC-3643 y ERC-1400 (activos regulados)
# OpenZeppelin (implementaciones auditadas) · Chainlink (oráculos y prueba de reservas)

Y las tres reglas que evitan pérdidas mientras aprendes:

1. Signet y testnet primero, siempre. Un error en mainnet no tiene deshacer.
2. Separa los monederos. Uno para estudiar, uno para usar — y las cantidades relevantes solo en hardware wallet.
3. Nunca expongas la seed. Ningún sitio legítimo pide tu frase de recuperación. Ninguno.

Cerrando

Blockchain es una herramienta con un coste altísimo — de rendimiento, de energía o de capital — que compra una propiedad concreta: un acuerdo verificable entre partes sin confianza mutua. Cuando necesitas eso, no hay sustituto. Cuando no lo necesitas, cualquier base de datos es mejor en todos los aspectos.

Los RWAs son la prueba más honesta de esa propuesta, porque exponen exactamente dónde acaba la tecnología y empieza el derecho. Ordinals y Runes son la demostración más interesante de otro fenómeno: cómo una red deliberadamente limitada acabó usándose de un modo que nadie previó, a partir de funciones creadas con otra finalidad.

Entender los dos casos enseña más sobre sistemas distribuidos que cualquier white paper — incluso sobre cuándo no usarlos.