Cada vez que minteas un NFT, estás llamando a un contrato inteligente. Cada vez que listas una obra en venta, aceptas una oferta o apruebas que un marketplace mueva tus tokens, estás interactuando con código que alguien más escribió y desplegó permanentemente en una blockchain. Sin embargo, la mayoría de los artistas nunca ha leído una sola línea de ese código.
Esta guía existe para cambiar eso. No para convertirte en desarrollador, sino para darte el entendimiento suficiente para hacer las preguntas correctas, detectar las señales de alerta y proteger tu obra. Recorreremos cuatro blockchains, desde la pionera (Ethereum) hasta el lienzo inesperado (Bitcoin), examinando cómo cada una maneja el concepto de código ejecutable on-chain.
No se requiere conocimiento previo de programación. Cada concepto técnico se explica con lenguaje llano, diagramas y casos reales del mundo del arte cripto.
¿Qué es realmente un contrato inteligente?
Antes de la blockchain, antes de Ethereum, antes de Solidity, la idea ya existía. Entender su origen revela lo que se suponía que debía ser y en lo que se convirtió.
La idea (1994)
En 1994, el científico de la computación Nick Szabo propuso el concepto de "contrato inteligente": un programa que ejecuta automáticamente los términos de un acuerdo, del mismo modo que una máquina expendedora aplica la regla "inserta moneda, recibe producto" sin necesidad de un vendedor.
La visión de Szabo era simple: si dos partes acuerdan condiciones, y esas condiciones pueden ser verificadas por una máquina, entonces la máquina puede ejecutar el acuerdo sin un intermediario de confianza. Sin abogado, sin agente de custodia, sin banco.
La realidad (2015 en adelante)
Cuando Ethereum se lanzó en 2015, le dio a la idea de Szabo su primer hogar real. Un contrato inteligente en Ethereum es un programa almacenado en una dirección específica de la blockchain. Una vez desplegado, nadie puede modificarlo (con algunas excepciones importantes que examinaremos en el Capítulo 12). Se ejecuta exactamente como fue escrito, cada vez, para cualquiera que lo invoque.
Pero "inteligente" es una palabra generosa. Un contrato inteligente no es inteligente. No razona, no se adapta, no aprende. Es una máquina determinista: ante la misma entrada, siempre produce la misma salida. Es "inteligente" solo en el sentido de que se ejecuta automáticamente. Un nombre más preciso sería "acuerdo autoejecutante" o "programa autónomo."
Un contrato inteligente es a un contrato legal tradicional lo que un rollo de pianola es a una partitura. La partitura requiere un intérprete para ejecutarla. El rollo de pianola se ejecuta mecánicamente, exactamente como fue codificado, sin espacio para la interpretación. Las ventajas (precisión, automatización, ausencia de confianza) son también los peligros (rigidez, irreversibilidad, ausencia de juicio).
¿Qué lo diferencia de un programa normal?
Un programa normal se ejecuta en el servidor de alguien. Ese alguien puede apagarlo, modificarlo o negarte el acceso. Un contrato inteligente, una vez desplegado, se ejecuta en cada nodo de la red simultáneamente. Ninguna entidad puede detenerlo, alterarlo o censurarlo. Esta es la propuesta de valor fundamental: código que nadie controla pero que todos pueden verificar.
Por supuesto, "nadie controla" viene con matices. El desplegador eligió qué hace el código. El desplegador eligió quién tiene permisos especiales. Y como veremos, algunos contratos están diseñados para ser actualizables, lo que significa que alguien sí retiene el control. Pero la promesa, el ideal, es radical: un programa que sirve a sus usuarios sin un amo.
Anatomía de un contrato
Todo contrato inteligente, independientemente de la blockchain en la que viva, tiene los mismos componentes básicos. Entenderlos es como entender las partes de una célula antes de estudiar biología.
Estado: la memoria
Un contrato tiene almacenamiento persistente, datos que sobreviven entre llamadas. Para un contrato NFT, el estado incluye: quién es dueño de cada token, el número total de tokens minteados, la URI base que apunta a los metadatos y cualquier permiso especial (quién puede mintear, quién puede pausar el contrato).
Este estado vive directamente en la blockchain. Modificarlo cuesta gas (en Ethereum) o renta (en Solana), porque cada nodo de la red debe almacenar estos datos para siempre.
Funciones: las acciones
Las funciones son las operaciones que un contrato puede realizar. Vienen en dos sabores:
- Funciones de lectura (gratuitas): Solo consultan el estado sin modificarlo. Ejemplo: "¿Quién es dueño del token #42?" o "¿Cuántos tokens existen?" No cuestan nada porque no modifican la blockchain.
- Funciones de escritura (cuestan gas): Modifican el estado. Ejemplo: "Mintear un nuevo token," "Transferir el token #42 a Alice," o "Establecer una nueva URI base." Requieren una transacción, una tarifa y confirmación de la red.
Eventos: los anuncios
Cuando algo importante ocurre dentro de un contrato, este puede emitir un evento: un registro que las aplicaciones externas pueden escuchar. Cuando minteas un NFT y tu wallet lo muestra inmediatamente, es porque la wallet estaba escuchando un evento Transfer del contrato.
El constructor: nacimiento y muerte
El constructor es código especial que se ejecuta exactamente una vez, en el momento del despliegue. Establece el estado inicial: el nombre de la colección, el símbolo, la dirección del propietario y cualquier otra configuración. Después del despliegue, el constructor nunca puede ejecutarse de nuevo.
Datos persistentes | Lectura (gratis) + Escritura (gas) | Registros para apps externas
Modificadores y control de acceso
No todas las funciones deberían ser invocables por cualquiera. Los modificadores son reglas que restringen el acceso. El más común es onlyOwner, que limita una función a la dirección del desplegador. Otros incluyen acceso basado en roles (solo el rol "minter" puede mintear) y bloqueos temporales (esta función no puede llamarse hasta el bloque 10.000.000).
Cuando lees un contrato y ves un modificador onlyOwner en una función crítica como setBaseURI, significa que el desplegador puede cambiar a dónde apuntan los metadatos. Eso es poder. Si es benigno o peligroso depende de quién lo tiene y qué pretende.
La máquina virtual: donde vive el código
Los contratos inteligentes no se ejecutan en tu computadora ni en el servidor de una empresa. Se ejecutan dentro de una máquina virtual replicada en miles de nodos. Entender esta máquina es entender el escenario donde tu arte actúa.
¿Qué es una máquina virtual?
Una máquina virtual (VM) es un entorno de computación aislado. Piensa en ella como un sandbox: los programas pueden ejecutarse dentro, pero no pueden salir a tocar archivos, internet u otros programas. Este aislamiento es crítico para la seguridad. Un contrato malicioso no puede acceder a tu disco duro, tu cámara ni tu cuenta bancaria. Solo puede hacer lo que el protocolo de la blockchain permite.
La EVM (Ethereum Virtual Machine)
La EVM es la máquina virtual más influyente en la historia de la blockchain. Cada nodo de Ethereum ejecuta una copia de la EVM, y cada copia procesa cada transacción de manera idéntica. La EVM está basada en pila, lo que significa que procesa datos empujando y sacando valores de una pila, una operación a la vez.
Cuando despliegas un contrato en Solidity, el compilador lo traduce a bytecode: una secuencia de instrucciones de bajo nivel llamadas opcodes. Cada opcode tiene un costo fijo de gas. ADD (suma) cuesta 3 gas. SSTORE (escritura en almacenamiento) cuesta 20.000 gas para un slot nuevo. El gas total consumido por una transacción determina su tarifa.
La EVM tiene aproximadamente 140 opcodes. Algunos son aritméticos (ADD, MUL, SUB), algunos gestionan memoria (MLOAD, MSTORE), algunos interactúan con la blockchain (BALANCE, BLOCKHASH) y algunos controlan el flujo de ejecución (JUMP, JUMPI). Ningún opcode accede a internet ni a ningún sistema externo. Esto es por diseño.
Solana: el runtime Sealevel
Solana no usa la EVM. Ejecuta su propio runtime llamado Sealevel, que puede procesar miles de transacciones en paralelo. Donde la EVM procesa una transacción a la vez, Sealevel analiza qué cuentas toca cada transacción y ejecuta simultáneamente las transacciones que no entran en conflicto.
En Solana, los contratos inteligentes se llaman "programas" y se compilan a bytecode BPF (Berkeley Packet Filter). Una diferencia arquitectónica clave: en Solana, los programas son sin estado (stateless). No almacenan datos dentro de sí mismos. En su lugar, leen y escriben en "cuentas" separadas que contienen los datos. Esta separación de lógica y almacenamiento es lo que permite el paralelismo.
Tezos: la VM Michelson
Tezos ejecuta su propia máquina virtual basada en pila, diseñada para la verificación formal: la prueba matemática de que un programa hace exactamente lo que dice. Los contratos se compilan a Michelson, un lenguaje de bajo nivel donde cada operación es explícita y verificable. Esta es la blockchain del matemático. El énfasis no está en la velocidad sino en la corrección.
Bitcoin: sin máquina virtual (casi)
Bitcoin nunca fue diseñado para ejecutar contratos inteligentes. Su lenguaje de scripting, Bitcoin Script, es intencionalmente limitado: no es Turing-completo, lo que significa que no puede hacer bucles ni realizar computación arbitraria. Esta fue una elección deliberada por seguridad y simplicidad.
Sin embargo, Bitcoin ha evolucionado. La actualización Taproot (noviembre 2021) expandió lo que Script puede hacer, y protocolos como Ordinals y Runes han encontrado formas creativas de inscribir datos y definir tokens en Bitcoin. Exploraremos esto en profundidad en el Capítulo 8.
| Cadena | VM / Runtime | Lenguaje | ¿Turing-completo? | Paralelismo |
|---|---|---|---|---|
| Ethereum | EVM | Solidity, Vyper | Sí | Secuencial |
| Solana | Sealevel (BPF) | Rust, Anchor | Sí | Paralelo |
| Tezos | Michelson VM | SmartPy, LIGO | Sí | Secuencial |
| Bitcoin | Intérprete Script | Bitcoin Script | No | N/A |
De la idea a la blockchain: el ciclo de vida
Un contrato inteligente atraviesa fases distintas, desde su concepción hasta el despliegue permanente. Cada fase tiene implicaciones para el artista.
Fase 1: Escritura
Alguien (un desarrollador, una plataforma o, cada vez más, una herramienta de IA) escribe el código fuente del contrato. Para una colección NFT, esto típicamente significa definir: qué sucede cuando alguien mintea, cómo funcionan las transferencias, qué información de regalías se adjunta y quién tiene privilegios administrativos.
La mayoría de los artistas nunca escribe sus propios contratos. Usan plataformas (Foundation, SuperRare, objkt, Manifold) que despliegan contratos pre-escritos y auditados en su nombre. Esto es práctico, pero significa que estás confiando el código de esa plataforma con tu arte.
Fase 2: Compilación
El código fuente legible por humanos se traduce a bytecode que la máquina virtual puede ejecutar. Este paso es automático y lo maneja un compilador (solc para Solidity, cargo para Rust/Solana, el compilador SmartPy para Tezos).
Fase 3: Despliegue
El bytecode compilado se envía a la blockchain en una transacción especial. Esta transacción cuesta gas (o la tarifa equivalente de la cadena). Una vez confirmada, el contrato existe en una dirección específica, para siempre. En Ethereum, esta dirección se deriva de la dirección del desplegador y su contador de transacciones (nonce).
Legible por humanos | Traducción | Legible por máquinas | Vive on-chain para siempre
Fase 4: Verificación
Después del despliegue, el código fuente puede publicarse en un explorador de bloques (Etherscan, Solscan, TzKT) para que cualquiera pueda verificar que el bytecode on-chain coincide con el código publicado. Esto se llama "verificación." Un contrato no verificado es una señal de alerta. Significa que no puedes leer qué hace realmente el código.
Fase 5: Interacción
Los usuarios (y otros contratos) interactúan con el contrato desplegado enviando transacciones que invocan sus funciones. Cada interacción es pública, permanente y auditable. Cuando minteas un NFT en Foundation, tu wallet envía una transacción al contrato de Foundation invocando la función mint con tus parámetros.
El despliegue es irreversible. Si el contrato tiene un bug, no se puede parchar. Si tiene una vulnerabilidad, no se puede corregir. Las únicas opciones son: desplegar un nuevo contrato y migrar (costoso, disruptivo), usar un patrón de actualización si fue incorporado desde el inicio (ver Capítulo 12), o abandonar el contrato por completo. Por eso importan las auditorías.
Ethereum: la pionera
Ethereum inventó el concepto de blockchain de propósito general. Todo lo que vino después, desde DeFi hasta NFTs y DAOs, se construyó sobre los cimientos que estableció.
Solidity: la lingua franca
Solidity es el lenguaje dominante para contratos inteligentes en Ethereum. Creado por Gavin Wood en 2014, su sintaxis se parece a JavaScript, haciéndolo accesible para desarrolladores web. Un contrato NFT básico en Solidity define un mapeo de IDs de token a direcciones de propietarios, una función de minteo que crea nuevos tokens y una función de transferencia que mueve tokens entre direcciones.
Pero la accesibilidad es una espada de doble filo. Porque Solidity parece simple, los desarrolladores a veces subestiman sus sutilezas. Muchos de los peores exploits en la historia de la blockchain vinieron de código en Solidity que parecía correcto pero contenía un defecto oculto.
Las garantías de la EVM
Cuando invocas una función en un contrato de Ethereum, cada nodo de la red ejecuta el mismo código con las mismas entradas y llega al mismo resultado. Si no están de acuerdo, la red rechaza al disidente. Esto es consenso. Significa que no necesitas confiar en ningún nodo individual; confías en las matemáticas del acuerdo.
Gas y costos de computación
Cada operación en la EVM cuesta gas. Las operaciones simples (suma, comparación) cuestan 3-5 gas. Las operaciones de almacenamiento cuestan miles. Un minteo estándar de NFT cuesta aproximadamente 50.000-150.000 unidades de gas, dependiendo de la complejidad del contrato. Multiplica por el precio actual del gas (en gwei) y el precio de ETH para obtener el costo en dólares.
FUNCIÓN mint(destinatario, tokenURI):
requerir(invocante == propietario O invocante == minter)
requerir(suministroTotal < suministroMáximo)
nuevoTokenId = suministroTotal + 1
propietarioDe[nuevoTokenId] = destinatario
tokenURIs[nuevoTokenId] = tokenURI
suministroTotal = suministroTotal + 1
EMITIR Transfer(dirección(0), destinatario, nuevoTokenId)
RETORNAR nuevoTokenId
Vyper: la alternativa
Vyper es el segundo lenguaje de Ethereum, diseñado para ser más simple y más auditable que Solidity. Intencionalmente carece de características que Solidity tiene (como herencia y sobrecarga de operadores) para hacer los contratos más fáciles de leer y verificar. Algunos proyectos enfocados en seguridad prefieren Vyper precisamente porque tiene menos lugares donde los bugs pueden esconderse.
Compatibilidad EVM: el imperio se expande
La influencia de la EVM se extiende mucho más allá de Ethereum. Cadenas como Polygon, Arbitrum, Optimism, Base, Avalanche y BNB Chain ejecutan máquinas virtuales compatibles con la EVM. Un contrato escrito para Ethereum puede desplegarse en cualquiera de estas cadenas con cambios mínimos o nulos. Por eso Solidity es el lenguaje de contratos inteligentes más comercialmente importante del mundo.
Solana: la máquina de velocidad
Donde Ethereum prioriza la descentralización y la seguridad, Solana optimiza la velocidad y el costo. Para artistas que mintean grandes colecciones, este equilibrio importa.
Programas, no contratos
En Solana, los contratos inteligentes se llaman "programas." Esto no es solo una cuestión de marca: refleja una arquitectura fundamentalmente diferente. Un programa de Solana es sin estado (stateless). Contiene solo lógica, no datos. Todos los datos se almacenan en "cuentas" separadas desde las que el programa lee y escribe.
Piénsalo así: en Ethereum, un contrato es como una tienda que guarda su propio inventario en la trastienda. En Solana, un programa es como un cajero que consulta un almacén separado cada vez que un cliente pregunta. El cajero (programa) no tiene memoria de transacciones previas; simplemente sigue las reglas y actualiza el almacén (cuentas).
El modelo de cuentas
Todo en Solana es una cuenta. Tu wallet es una cuenta. Un NFT es una cuenta. Los metadatos de ese NFT son una cuenta separada. La colección a la que pertenece es otra cuenta. Este modelo es más granular que el de Ethereum, y permite el procesamiento paralelo: si dos transacciones tocan cuentas diferentes, pueden ejecutarse simultáneamente.
Programa (Lógica) → Cuenta B (Metadatos)
Programa (Lógica) → Cuenta C (Colección)
Mismo programa, diferentes cuentas de datos = ejecución paralela
Rust y el framework Anchor
Los programas de Solana se escriben en Rust, un lenguaje conocido por su seguridad de memoria y rendimiento, pero también por su curva de aprendizaje pronunciada. El framework Anchor simplifica el desarrollo proporcionando macros y abstracciones que manejan gran parte del código repetitivo. La mayoría de los programas relacionados con NFTs en Solana se construyen con Anchor.
Metaplex: la infraestructura NFT
Metaplex es a los NFTs de Solana lo que OpenZeppelin es a Ethereum: la biblioteca estándar. Proporciona programas para minteo, gestión de metadatos, subastas y escaparates. Los dos programas clave de Metaplex para artistas son:
- Token Metadata Program: Adjunta metadatos (nombre, símbolo, URI, información de regalías) a cualquier token de Solana.
- Bubblegum (v2): Habilita "NFTs comprimidos" usando árboles de Merkle, reduciendo el costo de minteo en órdenes de magnitud. Una colección de un millón de NFTs puede mintearse por unos pocos SOL en lugar de miles.
Metaplex Core: la siguiente generación
Metaplex Core es un estándar más nuevo que usa un diseño de cuenta única, reduciendo los costos de minteo en más del 80% comparado con el enfoque original de Token Metadata. También proporciona regalías forzadas a nivel de protocolo, un sistema flexible de plugins para comportamientos personalizados y soporte nativo para colecciones y ediciones.
Las tarifas bajas de Solana la hacen atractiva para ediciones grandes y ediciones abiertas. Los NFTs comprimidos a través de Bubblegum v2 permiten distribuir arte a miles de coleccionistas por centavos. La contrapartida: Solana ha experimentado varias caídas de red, y los requisitos de hardware para sus validadores son significativamente más altos que los de Ethereum, concentrando el poder de validación entre menos operadores y más acaudalados.
Renta y tiempo de vida de las cuentas
En Solana, almacenar datos cuesta "renta" pagada en SOL. Las cuentas deben mantener un saldo mínimo (el umbral de "exención de renta") o serán eliminadas por la red. Para un NFT, el costo de exención de renta es típicamente alrededor de 0.002 SOL. Este es un depósito único que se puede recuperar si la cuenta se cierra.
Tezos: la cadena del matemático
Tezos fue construida con una filosofía diferente: corrección sobre velocidad, gobernanza sobre disrupción. Para una blockchain que alberga arte, esto importa más de lo que podrías pensar.
Verificación formal: prueba, no esperanza
La característica definitoria de los contratos inteligentes de Tezos es su afinidad con la verificación formal: la prueba matemática de que un programa se comporta exactamente como se especifica. Aunque la verificación formal es posible en cualquier cadena, Tezos fue diseñada desde cero para hacerla práctica. Su lenguaje de bajo nivel, Michelson, está basado en pila y es determinista, haciéndolo susceptible a herramientas de prueba automatizada.
¿Por qué importa esto para los artistas? Porque un contrato formalmente verificado es uno donde no necesitas confiar en las intenciones del desarrollador ni esperar que no haya cometido errores. Las matemáticas lo garantizan.
Michelson, SmartPy y LIGO
Nadie escribe Michelson a mano (bueno, casi nadie). Los artistas y desarrolladores usan lenguajes de alto nivel que se compilan a Michelson:
- SmartPy: Sintaxis similar a Python, popular en la comunidad artística, usado por plataformas como objkt.com.
- LIGO: Ofrece múltiples variantes de sintaxis (CameLIGO se parece a OCaml, JsLIGO se parece a TypeScript). Usado para contratos complejos de DeFi y gobernanza.
FA2: el estándar multi-activo
Donde Ethereum separa los NFTs (ERC-721) de los tokens semi-fungibles (ERC-1155), Tezos unifica todo bajo FA2 (TZIP-12). Un solo contrato FA2 puede manejar tokens fungibles, tokens no fungibles y multi-ediciones en un solo despliegue. Esto es elegante y eficiente: un contrato, una interfaz, múltiples tipos de activos.
Tezos fue la primera cadena importante en usar proof-of-stake desde su génesis, y su consumo energético es una fracción de los niveles pre-Merge de Ethereum. Durante el boom de NFTs de 2021-2022, muchos artistas preocupados por el medio ambiente eligieron Tezos específicamente por esta razón. Plataformas como Hic et Nunc (ahora Teia) y objkt.com se convirtieron en centros culturales para el arte cripto, creando una de las comunidades de artistas más vibrantes del ecosistema.
Gobernanza on-chain y actualizaciones
Tezos tiene un mecanismo único de auto-enmienda: el protocolo mismo puede actualizarse mediante votación on-chain por los bakers (validadores de Tezos). Esto significa que la blockchain evoluciona sin hard forks. Para los contratos inteligentes, esto es significativo: las reglas de la máquina virtual pueden cambiar, pero cambian mediante consenso democrático, no por decreto corporativo.
Etherlink: el puente EVM
Reconociendo la dominancia del ecosistema EVM, Tezos lanzó Etherlink, una Layer 2 compatible con la EVM construida sobre Smart Rollups. Esto significa que los desarrolladores de Solidity pueden desplegar sus contratos de Ethereum en la infraestructura de Tezos, beneficiándose de su modelo de seguridad mientras mantienen compatibilidad con las herramientas del ecosistema EVM. Rarible ya ha añadido soporte para Etherlink en drops y trading de NFTs.
Smart Rollups: escalando sin compromisos
Los Smart Rollups de Tezos están integrados en el protocolo (no son un complemento de terceros). Permiten computación fuera de cadena con verificación on-chain, aumentando dramáticamente el rendimiento. El objetivo a largo plazo es ambicioso: un millón de transacciones por segundo en la capa de rollups. Para los artistas, esto significa que los proyectos generativos a gran escala y las ediciones abiertas se vuelven económicamente viables en Tezos sin sacrificar las garantías de corrección de la cadena.
Bitcoin: el lienzo inesperado
Bitcoin nunca fue diseñado para el arte. Fue diseñado para mover valor, punto. Y sin embargo, mediante una combinación de ingenio y terquedad, los artistas encontraron una entrada.
Bitcoin Script: la limitación intencional
El lenguaje de scripting de Bitcoin es deliberadamente limitado. No puede hacer bucles, no puede almacenar estado complejo y no puede llamar a otros scripts. Satoshi Nakamoto lo diseñó así para minimizar la superficie de ataque: un lenguaje más simple significa menos formas de que las cosas salgan mal.
Bitcoin Script maneja condiciones como "esta transacción solo puede gastarse si se proporcionan la firma A y la firma B" (multi-firma) o "esta transacción no puede gastarse hasta la altura de bloque 800.000" (bloqueos temporales). Útil para lógica financiera, pero lejos de lo que necesitas para NFTs.
La actualización Taproot (noviembre 2021)
Taproot expandió lo que Bitcoin Script podía hacer al introducir firmas Schnorr y un nuevo tipo de script llamado Tapscript. Críticamente, hizo económicamente viable incrustar cantidades mayores de datos en transacciones de Bitcoin. Esto abrió la puerta.
Ordinals: cada satoshi recibe un nombre
En enero de 2023, el desarrollador Casey Rodarmor lanzó el protocolo Ordinals, que asigna un número secuencial a cada satoshi (la unidad más pequeña de Bitcoin, 1 BTC = 100.000.000 satoshis). Este "número ordinal" convierte a cada satoshi en una entidad única e identificable.
Las inscripciones llevan esto más lejos: puedes adjuntar datos (una imagen, un texto, una página HTML, incluso un programa) directamente a un satoshi específico. Estos datos se almacenan en la sección witness de una transacción de Bitcoin y viven en la blockchain de Bitcoin permanentemente. Sin IPFS, sin Arweave, sin almacenamiento externo. El arte está literalmente en Bitcoin.
Para enero de 2026, se habían creado más de 107 millones de inscripciones en Bitcoin. Esto no es un experimento de nicho; es un movimiento cultural.
Runes: tokens fungibles en Bitcoin
También creado por Casey Rodarmor, Runes (lanzado en abril de 2024) habilita tokens fungibles nativamente en Bitcoin. A diferencia de BRC-20 (un estándar anterior menos eficiente), Runes usa el modelo UTXO de Bitcoin directamente, creando menos saturación de la blockchain. Para los artistas, Runes podría habilitar ediciones, membresías o tokens comunitarios sin salir de Bitcoin.
Alkanes: los contratos inteligentes llegan a Bitcoin
El desarrollo más reciente es Alkanes, un metaprotocolo que trae contratos inteligentes basados en WASM a la capa base de Bitcoin. A diferencia de los contratos inteligentes al estilo de Ethereum, Alkanes opera sin puentes ni capas de ejecución externas. Los desarrolladores pueden construir aplicaciones y lanzar tokens nativamente en Bitcoin con lógica programable. Esto aún está en fase temprana, pero representa el intento más ambicioso de traer computación general a la capa base de Bitcoin.
La división cultural
No todos en la comunidad de Bitcoin dan la bienvenida a estos desarrollos. Los maximalistas de Bitcoin argumentan que las inscripciones saturan la blockchain y distraen de la misión de Bitcoin como dinero sólido. Los defensores responden que la seguridad y permanencia de la red Bitcoin la convierten en el lienzo definitivo para el arte digital. Como artista, debes saber que este debate existe y que ocasionalmente afecta decisiones técnicas (algunos mineros han discutido filtrar transacciones de inscripciones).
A finales de febrero de 2026, Magic Eden anunció que cerraría el soporte para Bitcoin Ordinals, Runes y NFTs EVM. El trading terminó el 9 de marzo y las APIs se desconectaron el 27 de marzo. La lección: los marketplaces son intermediarios. Incluso en Bitcoin, donde los datos son permanentes, la infraestructura a su alrededor no lo es.
Estándares de tokens: el lenguaje del arte digital
Los estándares de tokens definen cómo se comportan los activos digitales: cómo se crean, se transfieren y se consultan. Son la gramática del arte on-chain.
ERC-721: el NFT original
Propuesto en enero de 2018, ERC-721 definió lo que ahora llamamos un NFT: un token donde cada unidad es única y no intercambiable. El estándar especifica: cada token tiene un ID único dentro de su contrato, cada token tiene exactamente un propietario, los tokens pueden transferirse y la propiedad es consultable.
CryptoKitties (2017) fue el catalizador, pero ERC-721 formalizó el patrón. Cada NFT que hayas minteado en Ethereum, Polygon, Arbitrum o cualquier cadena EVM usa ERC-721 o su sucesor.
ERC-1155: el multi-token
Creado por el equipo de Enjin, ERC-1155 permite que un solo contrato gestione tanto tokens fungibles como no fungibles. Puedes tener piezas únicas 1/1 junto con ediciones de 100 en el mismo contrato. Las operaciones por lotes (mintear 50 tokens en una transacción) reducen los costos de gas dramáticamente.
| Estándar | Cadena | Tokens únicos | Ediciones | Ops por lotes | Info de regalías |
|---|---|---|---|---|---|
| ERC-721 | Cadenas EVM | Sí | No (necesita workaround) | No | Vía ERC-2981 |
| ERC-1155 | Cadenas EVM | Sí | Sí (nativo) | Sí | Vía ERC-2981 |
| FA2 (TZIP-12) | Tezos | Sí | Sí (nativo) | Sí | Vía TZIP-16 |
| Metaplex Core | Solana | Sí | Sí (nativo) | Sí | Forzadas |
| Ordinals | Bitcoin | Sí | No | No | Ninguna |
FA2 en Tezos
FA2 es el estándar unificado. Un contrato, una interfaz, cualquier tipo de token. Esta simplicidad tiene beneficios prácticos: las wallets, los marketplaces y los indexadores solo necesitan soportar un estándar, reduciendo la complejidad de integración y los bugs.
Estándares Metaplex en Solana
Solana ha iterado a través de múltiples estándares de NFT. El programa Token Metadata original requería múltiples cuentas por NFT. Metaplex Core consolidó esto en un diseño de cuenta única con regalías forzadas y una arquitectura de plugins. Los NFTs comprimidos (Bubblegum) añadieron una tercera opción para minteo de alto volumen y bajo costo usando árboles de Merkle.
Ordinals: sin estándar, solo datos
Los Bitcoin Ordinals no siguen un "estándar de token" en el sentido tradicional. No hay un contrato inteligente que defina la lógica de transferencia. La propiedad se determina por cuál satoshi tiene la inscripción adjunta, y las transferencias siguen el modelo UTXO nativo de Bitcoin. Esto es radicalmente simple pero también significa que no hay regalías on-chain, ni mecanismos de aprobación, ni comportamiento programable después de la inscripción.
Qué pasa realmente cuando minteas
El botón de "Mint" oculta una secuencia extraordinaria de eventos. Esto es lo que realmente sucede, paso a paso, en cada cadena.
En Ethereum
Cuando haces clic en "Mint" en una plataforma como Foundation o SuperRare:
- Tu wallet construye una transacción invocando la función
mintdel contrato, pasando tu dirección y la URI de metadatos del token. - Firmas la transacción con tu llave privada y la envías a la red (vía un endpoint RPC, como se cubre en La Biblia de las Wallets).
- La transacción entra al mempool, donde espera a que un validador la incluya en un bloque.
- Un validador recoge tu transacción, la EVM ejecuta la función
mint: verifica que el minteo está permitido, asigna un nuevo ID de token, mapea ese ID a tu dirección en el almacenamiento del contrato y registra la URI de metadatos. - El contrato emite un evento
Transferdesde address(0) (la dirección cero, significando creación) a tu dirección. - El bloque se finaliza. El NFT ahora existe permanentemente en Ethereum.
- Los indexadores (como los que usan OpenSea y Rarible) detectan el evento
Transfery actualizan sus bases de datos. Tu NFT aparece en tu perfil.
Clic → Firma → Transmisión → Espera → Ejecución → Finalización
En Solana
El proceso es similar en propósito pero diferente en mecánica. Cuando minteas en Exchange Art o Tensor:
- Tu wallet construye una transacción que invoca el programa Metaplex Token Metadata (o el programa Metaplex Core).
- La transacción especifica qué cuentas crear o modificar: la cuenta de minteo, la cuenta de metadatos y tu cuenta de token.
- Un validador procesa la transacción. Como los programas de Solana son sin estado, el runtime pasa las cuentas relevantes al programa, que verifica condiciones y escribe datos.
- La finalidad se alcanza en aproximadamente 400 milisegundos. El NFT existe.
En Tezos
En objkt.com o Teia:
- Tu wallet construye una operación invocando el entrypoint
mintdel contrato FA2. - La operación se firma y transmite. Un baker la incluye en un bloque.
- La VM Michelson ejecuta el contrato. El big map (el almacenamiento eficiente de clave-valor de Tezos) se actualiza con los datos del nuevo token.
- La finalidad toma aproximadamente 30 segundos (un bloque).
En Bitcoin
Las inscripciones funcionan diferente porque no hay contrato inteligente:
- Preparas los datos (imagen, texto, HTML) y los codificas en los datos witness de una transacción de Bitcoin usando el protocolo Ordinals.
- La transacción se transmite. Un minero la incluye en un bloque.
- La inscripción queda permanentemente incrustada en la blockchain de Bitcoin. El número ordinal del satoshi al que está adjunta se convierte en su identificador.
- No hay "contrato" que invocar, ni "función de minteo" que llamar. La inscripción es el artefacto en sí mismo.
Ethereum: ~12 segundos por bloque. Solana: ~400 milisegundos. Tezos: ~30 segundos. Bitcoin: ~10 minutos. Estos tiempos importan cuando estás minteando durante un drop de alta demanda. En Ethereum, los precios de gas se disparan mientras todos compiten por espacio en el bloque. En Solana, la ventaja de velocidad puede convertirse en desventaja cuando la red está congestionada y las transacciones se descartan.
Regalías: la promesa rota
Las regalías para creadores se suponía que serían la revolución: artistas ganando de cada venta secundaria, automáticamente, para siempre. La realidad es más complicada.
El sueño
La propuesta era irresistible: mintea un NFT con un 10% de regalías, y cada vez que cambie de manos en el mercado secundario, el 10% del precio de venta fluye de vuelta a ti automáticamente. Sin agentes, sin contratos que renegociar, sin depender de la buena voluntad de nadie. El contrato inteligente lo garantiza.
Excepto que no lo hace.
ERC-2981: una señal, no una ley
ERC-2981 es el estándar de Ethereum para información de regalías. Define una función llamada royaltyInfo que cualquier marketplace puede invocar para preguntar: "Para este token, ¿quién debería recibir regalías y cuánto?" El contrato responde con una dirección y un porcentaje.
Pero aquí está el punto crítico: ERC-2981 no puede forzar el pago. Es una señal, una sugerencia. El propio estándar lo dice. El marketplace es libre de invocar royaltyInfo, leer la respuesta e ignorarla completamente. Y cada vez más, eso es exactamente lo que ocurre.
La carrera al cero
En 2023, comenzaron las guerras de marketplaces. Blur se lanzó con regalías opcionales, atrayendo traders que preferían no pagar tarifas al creador. OpenSea respondió introduciendo su Operator Filter Registry, que permitía a los creadores bloquear sus NFTs de ser comercializados en marketplaces que no honraran regalías. Pero esto creó fricción y fragmentación.
A finales de 2023, OpenSea desmanteló el Operator Filter. La "carrera al cero" se aceleró. En 2026, el panorama se ha estabilizado en un equilibrio incómodo: algunos marketplaces honran regalías voluntariamente (SuperRare, Foundation), algunos las hacen opcionales (OpenSea, Blur), y algunos las ignoran por completo.
En Ethereum y la mayoría de las cadenas EVM, las regalías no son ejecutables a nivel de protocolo. Dependen de la cooperación del marketplace. Si un comprador transfiere un NFT directamente a otra wallet (una transferencia peer-to-peer), no se activa ninguna regalía, porque la función de transferencia en ERC-721 no tiene concepto de pago.
Donde las regalías sí se cumplen
Metaplex Core en Solana es la excepción notable. Fuerza las regalías a nivel de programa. Las transferencias que no respetan las reglas de regalías son rechazadas por el propio programa, no por política del marketplace. Esta es una ventaja técnica genuina para artistas que quieren ingresos secundarios garantizados.
Los marketplaces de Tezos (objkt.com, Teia) generalmente han mantenido la aplicación de regalías, en parte porque la cultura de la comunidad valora la compensación al creador y en parte porque la flexibilidad del estándar FA2 permite una integración más estrecha entre la lógica de transferencia y el pago.
Los Bitcoin Ordinals no tienen ningún mecanismo de regalías on-chain. Las inscripciones siguen la lógica de transferencia nativa de Bitcoin, y no hay manera de adjuntar programáticamente un requisito de regalías.
¿Qué puede hacer un artista?
Elige tu cadena y plataforma deliberadamente. Si las regalías secundarias son críticas para tu modelo económico, Solana con Metaplex Core ofrece la garantía más sólida. En Ethereum, considera plataformas como Manifold que te dan tu propio contrato, y acepta que la aplicación depende de la cooperación del marketplace. En Bitcoin, construye tu modelo económico sobre ventas primarias y relaciones con coleccionistas, no sobre regalías.
| Cadena | Estándar de regalías | Nivel de cumplimiento |
|---|---|---|
| Ethereum / EVM | ERC-2981 | Voluntario (el marketplace decide) |
| Solana (Metaplex Core) | Integrado | Forzado a nivel de protocolo |
| Tezos | TZIP-16 / Plataforma | Forzado por marketplace (cultura fuerte) |
| Bitcoin | Ninguno | Ninguno |
Contratos actualizables: lo mutable inmutable
Se supone que los contratos inteligentes son inmutables. Pero algunos de los contratos más importantes del ecosistema pueden cambiarse después del despliegue. Entender cómo, y los riesgos, es esencial.
El patrón proxy
El mecanismo de actualización más común usa un sistema de dos contratos. El primer contrato (el "proxy") almacena todos los datos y recibe todas las llamadas de los usuarios. El segundo contrato (la "implementación") contiene la lógica real. Cuando llamas al proxy, este reenvía tu llamada al contrato de implementación.
La actualización funciona cambiando a cuál implementación apunta el proxy. Los datos permanecen en el proxy (sin cambios), pero la lógica que opera sobre esos datos se reemplaza. Desde la perspectiva del usuario, la dirección del contrato no cambia. Pero el código detrás de ella sí.
Después de la actualización:
Usuario → Proxy (mismos datos + misma dirección) → Implementación v2
Por qué los contratos se hacen actualizables
Las razones legítimas incluyen: corregir bugs descubiertos después del despliegue, añadir funcionalidades solicitadas por la comunidad, cumplir con regulaciones cambiantes y optimizar costos de gas. OpenZeppelin, la biblioteca de contratos inteligentes más utilizada, proporciona un framework de actualización estandarizado usado por miles de proyectos.
Los riesgos para los artistas
Un contrato actualizable significa que alguien retiene el poder de cambiar las reglas después del despliegue. Esto es la antítesis de la promesa "el código es ley." Los riesgos específicos incluyen:
- Manipulación de metadatos: El propietario del contrato podría cambiar a dónde apuntan los metadatos del token, reemplazando efectivamente tu arte con otra cosa.
- Restricciones de transferencia: Una actualización maliciosa podría congelar las transferencias, impidiéndote vender o mover tus tokens.
- Cambios de regalías: Los porcentajes de regalías o las direcciones de destinatario podrían alterarse.
- Rug pull: En el peor caso, una actualización podría drenar todo el valor del contrato.
Si un contrato es actualizable y la llave de actualización la tiene una sola dirección (no un multi-sig, no una DAO, no un mecanismo con bloqueo temporal), esa dirección tiene poder absoluto sobre el contrato. Una llave comprometida, un mal actor, un momento de debilidad, y todo cambia. Al evaluar un proyecto NFT, siempre pregunta: ¿quién controla la llave de actualización?
Mitigaciones
Los proyectos responsables usan varios mecanismos para hacer las actualizaciones más seguras: bloqueos temporales (las actualizaciones se anuncian días o semanas por adelantado, dando tiempo a los usuarios para salir), wallets multi-firma (múltiples partes deben aprobar una actualización), votaciones de gobernanza (la comunidad decide) y renuncia a la actualización (la capacidad de deshabilitar permanentemente las actualizaciones una vez que el contrato es estable).
El enfoque de Solana
En Solana, los programas son actualizables por defecto. El desplegador retiene una "autoridad de actualización" que puede desplegar nuevo código en la misma dirección del programa. Para hacer un programa inmutable, el desplegador debe revocar explícitamente esta autoridad. Siempre verifica si la autoridad de actualización de un programa de Solana ha sido revocada si la inmutabilidad te importa.
Aprobaciones y permisos: las llaves que prestas
Cada vez que interactúas con un marketplace, otorgas permisos. Entender qué estás otorgando, y a quién, es quizás el capítulo más prácticamente importante de esta guía.
Cómo funcionan las aprobaciones en Ethereum
Cuando listas un NFT en venta en OpenSea, el marketplace necesita permiso para transferir ese NFT en tu nombre cuando aparezca un comprador. Otorgas este permiso mediante una transacción de "aprobación." Hay dos tipos:
approve(dirección, tokenId): Otorga permiso para un token específico. Más seguro, pero requiere una transacción separada para cada listado.setApprovalForAll(dirección, true): Otorga permiso para cada token que poseas en ese contrato. Conveniente (una transacción cubre todos los listados), pero peligroso: si la dirección aprobada está comprometida o es maliciosa, cada token está en riesgo.
El problema de la aprobación ilimitada
Para tokens ERC-20 (tokens fungibles como WETH o USDC), la situación es aún más traicionera. Cuando apruebas un protocolo DeFi o marketplace para gastar tus tokens, a menudo apruebas una cantidad "ilimitada." Esto significa que el contrato aprobado puede mover cualquier cantidad de ese token desde tu wallet, en cualquier momento, sin confirmación adicional.
Si ese contrato es explotado posteriormente, el atacante hereda todas tus aprobaciones ilimitadas. Esto no es teórico: miles de millones de dólares se han perdido a través de exploits basados en aprobaciones.
Revisa y revoca aprobaciones antiguas regularmente. Herramientas como revoke.cash y el Token Approval Checker de Etherscan te permiten ver cada contrato que has aprobado y revocar los que ya no uses. Esto es higiene básica, como cambiar contraseñas. Hazlo al menos mensualmente.
Permisos en Solana
Solana usa un modelo diferente. Las cuentas de token tienen un campo de "delegado" que puede establecerse para permitir que otra dirección transfiera o queme el token. Importantemente, las delegaciones en Solana típicamente están limitadas a una cantidad específica, haciendo las aprobaciones ilimitadas menos comunes. Sin embargo, el concepto permanece: otorgar delegación significa confiar en otro programa con tus activos.
Operadores en Tezos
En el estándar FA2, el concepto equivalente es "operadores." Añades una dirección de operador para un tipo específico de token, y ese operador puede transferir tokens en tu nombre. El patrón es similar al setApprovalForAll de Ethereum, pero el ecosistema de marketplaces más pequeño y curado de Tezos significa que hay menos contratos desconocidos solicitando permisos.
La trampa de la firma
No todos los permisos requieren transacciones on-chain. Algunos marketplaces usan firmas fuera de cadena (EIP-712 typed data) para crear listados. Firmas un mensaje con tu wallet, y el marketplace guarda esa firma hasta que aparezca un comprador. El peligro: los sitios de phishing pueden presentar solicitudes de firma que parecen legítimas pero que en realidad autorizan transferencias de activos. Siempre lee lo que estás firmando. Si tu wallet muestra una solicitud para firmar un "SetApprovalForAll" o una interacción con un contrato desconocido disfrazada como firma, recházala.
Leer un contrato: autodefensa para artistas
No necesitas ser desarrollador para leer un contrato inteligente. Necesitas saber dónde mirar y qué buscar.
Paso 1: Encontrar el contrato
Cada NFT vive en un contrato en una dirección específica. En Ethereum, ve a la página del NFT en cualquier marketplace, encuentra el enlace "Contract Address" y síguelo a Etherscan. En Solana, usa Solscan o Solana Explorer. En Tezos, usa TzKT o Better Call Dev.
Paso 2: Verificar la verificación
En Etherscan, busca la marca verde junto a "Contract" en las pestañas de navegación. Si el código fuente está verificado, puedes leerlo. Si no está verificado, solo puedes ver el bytecode crudo, que es ilegible para humanos. Un contrato no verificado es una señal de advertencia.
Paso 3: Buscar señales de alerta
No necesitas entender cada línea. Concéntrate en estos elementos críticos:
- Funciones solo del propietario: Busca
onlyOwneroonlyRole. ¿Qué puede hacer el propietario? ¿Puede pausar transferencias? ¿Cambiar metadatos? ¿Retirar fondos? - Funciones de retiro: ¿El contrato retiene ETH? ¿Quién puede retirarlo? Una función como
withdraw()cononlyOwneres normal para un contrato de minteo (el artista cobra los ingresos). Pero si la función de retiro no existe o apunta a una dirección desconocida, eso es sospechoso. - setBaseURI o setTokenURI: ¿Se pueden cambiar los metadatos después del minteo? Si es así, tu arte podría teóricamente ser reemplazado.
- Patrones proxy: Si el contrato parece demasiado simple (solo unas pocas líneas), podría ser un proxy. Verifica si delega llamadas a otro contrato.
- Minteo oculto: ¿Puede el propietario mintear tokens para sí mismo sin pagar? Busca funciones de minteo que eviten las reglas del minteo público.
En Etherscan, ve a la pestaña "Read Contract." Invoca owner() para ver quién controla el contrato. Luego verifica esa dirección: ¿es una wallet regular, un multi-sig (como un Safe/Gnosis Safe) o una dirección de plataforma conocida? Un multi-sig es buena señal. Una wallet aleatoria es un riesgo.
Paso 4: Revisar el historial de transacciones
Etherscan muestra cada transacción enviada al contrato. Observa: cuántas direcciones únicas han interactuado (más es generalmente mejor), si el propietario ha llamado funciones administrativas recientemente, y si hay transacciones fallidas que podrían indicar bugs o exploits.
Herramientas para no-desarrolladores
Varias herramientas pueden ayudarte a entender contratos sin leer código: Bubblemaps visualiza la distribución de tokens y conexiones entre wallets. DethCode proporciona una interfaz tipo VS Code para leer contratos de Etherscan. Tenderly te permite simular transacciones antes de ejecutarlas. Token Sniffer analiza contratos de tokens buscando patrones comunes de estafa.
Seguridad: exploits, estafas y señales de alerta
Miles de millones de dólares se han perdido por vulnerabilidades en contratos inteligentes. Como artista, tu obra y la confianza de tus coleccionistas están en juego. Conocer los ataques comunes es saber cómo evitarlos.
Reentrancia: el clásico
La reentrancia es la vulnerabilidad de contratos inteligentes más antigua y más infame. Ocurre cuando un contrato envía ETH a una dirección externa antes de actualizar su propio estado. La dirección receptora puede ser un contrato malicioso que, al recibir ETH, inmediatamente vuelve a llamar al contrato original y dispara otro pago, una y otra vez, antes de que la transacción original se complete.
FUNCIÓN retirar():
cantidad = saldos[invocante]
ENVIAR cantidad A invocante // llamada externa ANTES de actualizar estado
saldos[invocante] = 0 // demasiado tarde: el atacante re-entró arriba
FUNCIÓN retirar():
cantidad = saldos[invocante]
saldos[invocante] = 0 // actualización de estado PRIMERO
ENVIAR cantidad A invocante // llamada externa DESPUÉS (seguro)
La solución es simple en principio: siempre actualiza el estado antes de hacer llamadas externas. Este patrón se llama "verificaciones-efectos-interacciones." En 2025, los ataques de reentrancia aún causaron $35,7 millones en pérdidas. En 2026, permanecen en el OWASP Smart Contract Top 10.
Fallas de control de acceso
Cuando las funciones críticas carecen de restricciones de acceso apropiadas, cualquiera puede llamarlas. Imagina una función mint sin un modificador onlyOwner que se suponía que era solo para administradores: cualquiera podría mintear tokens ilimitados. O una función setRoyaltyRecipient que cualquiera puede llamar para redirigir regalías a su propia dirección.
Manipulación de oráculos
Los contratos inteligentes no pueden acceder a datos externos directamente. Dependen de "oráculos" (servicios como Chainlink) para feeds de precios e información fuera de cadena. Si un atacante puede manipular los datos del oráculo, puede engañar al contrato para que tome decisiones basadas en información falsa. Esto es especialmente relevante en DeFi pero puede afectar mecanismos de precios de NFTs.
La anatomía del rug pull
Un rug pull típicamente sigue este patrón: un proyecto se lanza con arte y marketing atractivos, el contrato recolecta los ingresos del minteo, y luego sucede alguna de estas cosas: el equipo retira todos los fondos y desaparece, las URIs de metadatos se cambian para apuntar a imágenes en blanco o sin valor, o el contrato se actualiza (vía proxy) para deshabilitar transferencias, atrapando los tokens de los coleccionistas.
Contrato no verificado en Etherscan. Equipo anónimo sin historial. El propietario puede cambiar metadatos después del minteo. Sin multi-sig en la dirección del propietario del contrato. Promesas irrealistas de valor futuro. Presión para mintear rápidamente ("tiempo limitado"). Sin auditoría de una firma reputada. La función de retiro envía a una dirección desconocida.
Ataques de flash loan
Los flash loans permiten a cualquiera pedir prestadas cantidades enormes de criptomonedas sin colateral, siempre que el préstamo se devuelva dentro de la misma transacción. Los atacantes usan flash loans para obtener temporalmente suficiente capital para manipular mercados, explotar mecanismos de precios u obtener poder de gobernanza. En el arte cripto, esto es menos común pero no imposible, especialmente para protocolos NFT-fi que usan NFTs como colateral.
La escala del problema
El robo de criptomonedas alcanzó $3.400 millones en 2025, el peor año registrado, con más de $2.300 millones drenados solo en la primera mitad. El exploit del Cetus Protocol ($223 millones por desbordamiento de enteros), el incidente de Balancer v2 ($120 millones) y numerosos hackeos menores demuestran que la seguridad de contratos inteligentes sigue siendo un desafío sin resolver.
Gas: la economía de la ejecución
El gas es el precio de la computación. Entenderlo te ayuda a elegir el momento de tus minteos, escoger tu cadena y evitar pagar de más.
Qué es realmente el gas
El gas es una unidad de trabajo computacional, no una moneda. Cada operación en la EVM tiene un costo fijo de gas. El gas total de una transacción es la suma de todas las operaciones que dispara. Luego multiplicas por el "precio del gas" (en gwei, donde 1 gwei = 0,000000001 ETH) para obtener la tarifa en ETH.
Transacción de minteo:
Gas usado: 85.000 unidades
Tarifa base: 15 gwei
Tarifa de prioridad: 2 gwei
Tarifa total: 85.000 x 17 gwei = 1.445.000 gwei = 0,001445 ETH
A ETH = $3.200: aproximadamente $4,62
EIP-1559: el mecanismo de tarifas
Desde agosto de 2021, Ethereum usa EIP-1559, que divide la tarifa en una "tarifa base" (determinada por la demanda de la red y quemada, reduciendo el suministro de ETH) y una "tarifa de prioridad" (una propina al validador). Cuando la red está ocupada, la tarifa base sube automáticamente. Cuando está tranquila, baja. Esto crea un mecanismo de precios dinámico que reemplaza el antiguo sistema de subasta.
Gas en diferentes cadenas
Las estructuras de tarifas varían dramáticamente:
- Ethereum mainnet: $1-50+ por transacción dependiendo de la congestión de la red. Las operaciones complejas (minteo, despliegue) cuestan más.
- Layer 2s (Arbitrum, Base, Optimism): $0,01-0,50. Misma EVM, una fracción del costo.
- Solana: ~$0,001 por transacción. Las tarifas de prioridad existen pero son mínimas.
- Tezos: ~$0,01-0,05 por transacción. Estable y predecible.
- Bitcoin: $1-20+ dependiendo del tamaño de la transacción y la congestión del mempool. Las inscripciones son transacciones más grandes y cuestan más.
Eligiendo el momento de tus transacciones
En Ethereum, los precios de gas siguen patrones predecibles: más bajos durante las noches y fines de semana de Norteamérica, más altos durante las horas laborales europeas/americanas. Herramientas como Blocknative Gas Estimator y Ultrasound.money muestran datos de gas en tiempo real e histórico. Si tu minteo no es urgente, esperar horarios de baja actividad puede ahorrarte un 50% o más.
Cuando despliegas tu propio contrato, la transacción de despliegue es la más cara (a menudo $50-200 en Ethereum mainnet durante condiciones normales). Considera desplegar en una Layer 2 o durante períodos de gas bajo. Para minteos, las operaciones por lotes (ERC-1155) y el lazy minting (minteo bajo demanda cuando el coleccionista compra) pueden reducir los costos significativamente.
On-chain vs off-chain: dónde vive realmente tu arte
El contrato inteligente dice que eres dueño del token #42. Pero, ¿dónde está la imagen real, la obra real? La respuesta es más compleja, y más frágil, de lo que la mayoría de los artistas creen.
La Token URI
Cada NFT tiene una tokenURI que apunta a un archivo JSON que contiene los metadatos: el nombre, la descripción, los atributos y, críticamente, el campo image, que es una URL que apunta al archivo de la obra real. El token on-chain es esencialmente un puntero. A dónde apunta determina todo.
Dónde pueden vivir los metadatos
- Servidor centralizado (HTTP): Los metadatos viven en el servidor de una empresa. Si la empresa cierra, el servidor se cae o el dominio expira, los metadatos (y por lo tanto el arte) desaparecen. Esta es la peor opción para la permanencia.
- IPFS (InterPlanetary File System): Una red descentralizada direccionada por contenido. Los archivos se identifican por su hash de contenido, así que la URI nunca cambia. Pero alguien debe "pinear" el archivo (mantener una copia disponible). Si todos los que pinean dejan de hacerlo, el archivo se vuelve inaccesible. Servicios como Pinata, Infura IPFS y nft.storage proporcionan pinning.
- Arweave: Una red de almacenamiento permanente donde pagas una vez y los datos se almacenan para siempre (en teoría). El modelo económico incentiva a los mineros a mantener los datos disponibles. Muchos proyectos serios de arte (Art Blocks, plataformas de arte generativo) usan Arweave.
- Completamente on-chain: Los datos de la obra se almacenan directamente en el almacenamiento del contrato inteligente o como parte de la transacción de despliegue. Esta es la opción más permanente pero también la más cara. Solo archivos pequeños (SVGs, arte ASCII, imágenes pequeñas codificadas en base64) son prácticos completamente on-chain.
- Inscripciones de Bitcoin: Los datos inscritos vía Ordinals se almacenan en los datos witness de la blockchain de Bitcoin, haciéndolos tan permanentes como Bitcoin mismo. Este es posiblemente el almacenamiento más permanente disponible, respaldado por la blockchain más valiosa y segura.
↓ tokenURI apunta a...
Servidor HTTP (frágil) IPFS (necesita pinning) Arweave (permanente) On-chain (permanente)
El problema de la fragilidad
Un NFT cuyos metadatos apuntan a https://empresa.com/api/token/42 es tan permanente como el servidor de esa empresa. Si la empresa pivotea, se queda sin dinero o simplemente olvida renovar el dominio, el arte se desvanece. El token sigue existiendo on-chain, pero apunta a la nada. Eres dueño de un recibo por un artículo que ya no existe.
Si eres artista, verifica a dónde apuntan tus obras minteadas. Ve al contrato en Etherscan, invoca tokenURI con tu ID de token y examina la URL devuelta. Si comienza con https:// apuntando a un dominio de empresa, la permanencia de tu arte depende de esa empresa. Si comienza con ipfs://, verifica que el archivo siga pineado. Si comienza con ar://, está en Arweave (bien). Si los datos se devuelven en línea (base64), están on-chain (lo mejor).
Congelar metadatos
Algunos contratos permiten al propietario "congelar" los metadatos, haciendo la tokenURI permanentemente inmodificable. Este es el estándar de oro para contratos desplegados por artistas: sube el arte a IPFS o Arweave, establece la URI y congela. Después de congelar, ni siquiera el propietario del contrato puede cambiar a dónde apunta el arte.
El futuro: hacia dónde van los contratos inteligentes
La tecnología está evolucionando rápidamente. Estos son los desarrollos que darán forma a cómo los artistas interactúan con los contratos inteligentes en los próximos años.
Account abstraction y smart wallets
Como se cubre en La Biblia de las Wallets, la abstracción de cuentas (ERC-4337) difumina la línea entre wallets y contratos. Tu wallet misma se convierte en un contrato inteligente, capaz de lógica personalizada: recuperación social, límites de gasto, llaves de sesión que otorgan permisos temporales. Para los artistas, esto significa experiencias más fluidas para los coleccionistas (sin gestión de gas para los compradores) y mecanismos de minteo más sofisticados (suscripciones, pagos a plazos, acceso condicional).
Intents: lo que quieres, no cómo conseguirlo
Las arquitecturas basadas en intents son un paradigma emergente donde los usuarios especifican lo que quieren ("comprar este NFT por menos de 0,5 ETH") y "solvers" compiten para encontrar la mejor manera de cumplir esa intención. Esto mueve la complejidad del usuario a la infraestructura, haciendo que las interacciones con contratos inteligentes se sientan más como usar un motor de búsqueda que como programar una computadora.
Interoperabilidad entre cadenas
Los bridges y protocolos cross-chain están madurando, habilitando que los NFTs se muevan entre cadenas. Estándares como OFT de LayerZero (Omnichain Fungible Token) y protocolos de mensajería cross-chain están haciendo técnicamente factible que un NFT minteado en Ethereum sea visible y comercializable en Solana o viceversa. Esto aún está en fase temprana y es riesgoso (los exploits de bridges han causado algunas de las mayores pérdidas en la historia cripto), pero representa un futuro donde los artistas no tienen que elegir una sola cadena.
La verificación formal se vuelve mainstream
Lo que Tezos fue pionera en implementar está llegando gradualmente a otras cadenas. Las herramientas de verificación formal para contratos en Solidity están mejorando, y las firmas auditoras usan cada vez más pruebas matemáticas junto con la revisión manual. A medida que lo que está en juego crece, la industria se está moviendo de "probar y esperar" hacia "demostrar y desplegar."
Arte generativo on-chain
El arte generativo completamente on-chain (donde el algoritmo vive en el contrato mismo, no solo un puntero a código externo) se está volviendo más factible a medida que las L2 reducen los costos de almacenamiento y plataformas especializadas (Art Blocks Engine, fxhash) proporcionan infraestructura. El contrato no es solo un certificado de propiedad; es el renderizador de la obra, su ADN, su fuente de verdad permanente.
Regulación
Los contratos inteligentes existen en una zona gris legal. Preguntas sobre si ciertos tokens constituyen valores, si los desarrolladores de contratos inteligentes tienen responsabilidad legal, y cómo la gobernanza descentralizada interactúa con la ley existente se están debatiendo activamente. Los artistas deben mantenerse informados, porque las decisiones regulatorias afectarán qué plataformas sobreviven, cómo se gravan las regalías y qué obligaciones contractuales existen entre creadores y coleccionistas.
Los contratos inteligentes tienen menos de una década. La primera generación estableció el concepto. La generación actual está luchando con la escala, la seguridad y la sostenibilidad. La próxima generación probablemente lucirá muy diferente a la de hoy: interfaces más simples, garantías más fuertes, integración más profunda con el mundo físico y (ojalá) derechos de creador ejecutables incorporados en cada protocolo.
Glosario
Referencia rápida de términos usados a lo largo de esta guía.
| Término | Definición |
|---|---|
| ABI | Application Binary Interface. Una descripción JSON de las funciones y eventos de un contrato, usada por wallets y dApps para interactuar con el contrato. |
| Account Abstraction | Un paradigma (ERC-4337) donde las wallets de los usuarios son contratos inteligentes en sí mismas, habilitando lógica personalizada como recuperación social y transacciones sin gas. |
| Bytecode | La versión compilada y legible por máquinas de un contrato inteligente, desplegada on-chain. El código fuente legible por humanos se compila a bytecode. |
| Constructor | Código especial que se ejecuta una vez al momento del despliegue, estableciendo el estado inicial del contrato. No puede volver a llamarse. |
| ERC-721 | El estándar de Ethereum para tokens no fungibles. Cada token es único y tiene exactamente un propietario. |
| ERC-1155 | Un estándar multi-token que soporta tanto tokens fungibles como no fungibles en un solo contrato. |
| ERC-2981 | El estándar de información de regalías. Proporciona una función para consultar detalles de regalías, pero no fuerza el pago. |
| EVM | Ethereum Virtual Machine. El entorno de ejecución que ejecuta contratos inteligentes en Ethereum y cadenas compatibles. |
| FA2 (TZIP-12) | El estándar de token unificado de Tezos. Maneja tokens fungibles, no fungibles y multi-edición en una sola interfaz. |
| Gas | Una unidad de trabajo computacional en Ethereum. Cada operación cuesta una cantidad fija de gas. Gas total por precio de gas igual a tarifa de transacción. |
| Inscripción | Datos (imagen, texto, HTML) permanentemente incrustados en una transacción de Bitcoin vía el protocolo Ordinals. |
| Mempool | La sala de espera para transacciones no confirmadas. Las transacciones esperan aquí hasta que un validador las incluye en un bloque. |
| Opcode | Una instrucción individual de bajo nivel en la EVM. Los contratos inteligentes se compilan en secuencias de opcodes. |
| Oráculo | Un servicio que proporciona datos externos a los contratos inteligentes (feeds de precios, aleatoriedad, eventos fuera de cadena). Chainlink es el proveedor más grande. |
| Patrón Proxy | Un diseño que separa datos (contrato proxy) de lógica (contrato de implementación), permitiendo actualizaciones al intercambiar la implementación. |
| Reentrancia | Una vulnerabilidad donde un contrato hace una llamada externa antes de actualizar su estado, permitiendo al contrato llamado re-entrar y explotar el estado desactualizado. |
| Rug Pull | Una estafa donde los creadores del proyecto lo abandonan después de recolectar fondos, a menudo involucrando manipulación de metadatos, retiro de fondos o congelamiento de transferencias. |
| Sealevel | El motor de ejecución paralela de Solana. Procesa transacciones no conflictivas simultáneamente para alto rendimiento. |
| Token URI | La URI almacenada en el contrato inteligente que apunta a los metadatos del token (nombre, descripción, URL de imagen, atributos). |
| Verificación Formal | Prueba matemática de que un programa se comporta como se especifica. Elimina ciertas clases de bugs con certeza. |