Qué es un contrato inteligente (y por qué no es un contrato)

Un contrato inteligente no es un contrato y no es inteligente. El nombre lo acuñó Nick Szabo en los años noventa y ha causado más malentendidos que cualquier otro término del sector: la gente asume que hay un acuerdo, que hay partes, que hay algún tipo de interpretación razonable de lo pactado. No hay nada de eso.

Lo que hay es un programa. Un programa que vive en una dirección de una blockchain, que se ejecuta cuando alguien le manda una transacción, y que hace exactamente lo que dice su código, incluidos sus errores. Si el código tiene un fallo que permite vaciarlo, el código no está "incumpliendo" nada. Está funcionando.

Esa distinción no es filosófica. Es la razón por la que se han perdido miles de millones de dólares en operaciones perfectamente válidas desde el punto de vista del protocolo.

La definición precisa

Un contrato inteligente es código y estado almacenados en una dirección de la cadena, que se ejecuta de forma determinista en una máquina virtual replicada por todos los nodos de la red.

Desmontemos la frase por partes:

• Código y estado en una dirección. El contrato tiene su propio saldo y sus propias variables. La dirección se calcula al desplegarlo y no cambia nunca.
• Se ejecuta cuando alguien lo llama. Un contrato no hace nada por su cuenta. No tiene un temporizador, no se despierta a las tres de la mañana. Alguien tiene que enviarle una transacción y pagar el gas. Los protocolos que parecen actuar solos usan bots externos que llaman a la función correspondiente.
• De forma determinista. Aquí está el núcleo.

La EVM y por qué el determinismo lo es todo

La Ethereum Virtual Machine es la máquina que ejecuta ese código. No es una máquina en un servidor: cada nodo de la red ejecuta las mismas instrucciones sobre el mismo estado y tiene que llegar exactamente al mismo resultado. Si un nodo obtuviera un resultado distinto, la red se partiría.

Por eso la EVM no tiene acceso a nada externo. No puede hacer una petición HTTP. No puede leer la hora del sistema. No tiene un generador de números aleatorios real. Todo lo que usa tiene que estar ya en la cadena, porque solo así todos los nodos calculan lo mismo.

De ahí salen dos consecuencias con las que se pelea todo el sector:

Los oráculos. Si un protocolo de préstamos necesita el precio de ETH para liquidar posiciones, alguien tiene que meter ese precio en la cadena. Ese alguien es un oráculo, y es una dependencia externa con su propio modelo de confianza. Buena parte de los ataques a protocolos DeFi no rompen el contrato: manipulan el precio que el contrato lee.

La aleatoriedad. Un sorteo on-chain honesto es un problema de ingeniería serio. Los intentos ingenuos —usar el hash del bloque, la marca temporal— son predecibles o manipulables por quien produce el bloque.

El ciclo de vida, paso a paso

Despliegue. Envías una transacción sin destinatario cuyo campo de datos contiene el bytecode compilado. La red ejecuta el constructor y guarda el resultado en una dirección nueva. Es una de las operaciones más caras que existen porque escribe código permanente en el estado.

Dirección. El contrato pasa a existir en esa dirección. No hay servidor, no hay dominio, no hay forma de "moverlo".

ABI. El Application Binary Interface es la especificación de qué funciones tiene el contrato, con qué parámetros y qué devuelven. Es lo que permite a tu monedero traducir "quiero aprobar 100 USDC" en la secuencia de bytes correcta. Sin ABI, un contrato verificado sigue siendo legible; sin ABI ni código verificado, estás firmando bytes a ciegas.

Llamadas. Hay dos tipos y confundirlos es habitual. Una lectura (call sin cambio de estado) es gratis: la ejecuta tu nodo localmente y no toca la cadena. Una escritura requiere transacción, gas y firma.

Eventos. El contrato emite registros indexados que no forman parte del estado ejecutable pero quedan en los recibos de las transacciones. Son lo que leen los exploradores y los frontales para mostrarte tu historial. Un contrato que no emite eventos es técnicamente correcto y prácticamente inservible.

"Inmutable" es, casi siempre, mentira

Este es el punto más importante de toda la guía, y el que menos aparece en las explicaciones divulgativas.

Es cierto que el bytecode desplegado en una dirección no se puede modificar. Pero eso no significa que el comportamiento del protocolo con el que interactúas sea inmutable, porque la industria desarrolló hace años tres formas de sortearlo.

El patrón proxy

Se despliegan dos contratos. El proxy guarda el estado —los saldos, las posiciones, todo— y una variable con la dirección de la lógica. La implementación contiene el código. Cuando llamas al proxy, este delega la ejecución en la implementación pero sobre su propio estado.

Tú siempre usas la dirección del proxy, que nunca cambia. Pero quien tenga la clave de administrador puede apuntar esa variable a otra implementación. El código antiguo sigue ahí, intacto e inmutable, y ya no se ejecuta nunca más.

Las claves de administrador

Muchos contratos tienen funciones restringidas a una dirección concreta: cambiar comisiones, modificar parámetros de riesgo, añadir o quitar activos aceptados, retirar fondos del tesoro. Quién es esa dirección importa muchísimo. No es lo mismo una cuenta individual que un multifirma de siete con umbral de cuatro, y no es lo mismo un cambio instantáneo que uno con retardo temporal de 48 horas que te da tiempo a salir.

Las funciones de pausa

Casi todo protocolo serio tiene un interruptor de emergencia que congela retiradas o depósitos. Es una decisión de ingeniería defendible: ha salvado fondos en ataques en curso. También significa que hay alguien capaz de impedir que retires tu dinero.

El gas como límite físico

Cada instrucción de la EVM cuesta unidades de gas. Eso convierte al gas en algo que no existe en programación normal: un límite físico a la complejidad del código.

Un bucle sobre una lista que crece indefinidamente acabará superando el límite de gas de un bloque y la función quedará permanentemente inejecutable. Es un modo de fallo real, con casos documentados de protocolos que quedaron bloqueados por diseñar mal una estructura de datos.

Para dar magnitud: a fecha de agosto de 2026, con el gas a 0,151 gwei, un swap en Uniswap cuesta alrededor de 0,131 $. Traducido a unidades de gas con ETH a 2.505 $, son unas 346.000 unidades, dieciséis veces lo que consume una transferencia simple de ETH. Ese factor dieciséis es el precio de ejecutar lógica en lugar de mover un saldo.

Composabilidad: la virtud y el riesgo

Cualquier contrato puede llamar a cualquier otro sin permiso previo. Un protocolo nuevo puede construirse encima de tres existentes en una tarde. A eso se le llama composabilidad y es lo que hace que DeFi avance tan rápido.

También es lo que hace que un fallo se propague. Si tu protocolo lee precios de un oráculo que a su vez depende de la liquidez de una pool, y alguien manipula esa pool con un préstamo relámpago, tu protocolo liquidará posiciones sanas o aceptará colateral que no vale nada. No hay ningún fallo en tu código. El fallo está tres capas más abajo, en algo que ni siquiera elegiste.

El corolario es duro: tu riesgo no es el de tu contrato, es el de la unión de todos los contratos con los que interactúa, y esa superficie crece con cada integración nueva.

Lo que ha salido mal, con su causa técnica

El caso Nomad merece una lectura aparte. Una actualización rutinaria dejó un valor por defecto que hacía que el contrato aceptara como válido cualquier mensaje. En cuanto la primera persona lo descubrió, cientos de usuarios copiaron su transacción cambiando la dirección de destino. No hizo falta ser un experto: bastaba copiar y pegar. Es el ejemplo más limpio de por qué el código público significa fallos públicos.

El otro patrón que conviene interiorizar es que los puentes concentran una proporción desmesurada de las pérdidas, porque acumulan custodia de activos sin heredar la seguridad de la cadena que los respalda. Si usas una Layer 2, el puente es tu punto de exposición más serio, no la red en sí.

Como referencia de escala: según el informe de Chainalysis publicado el 8 de enero de 2026, en 2025 se robaron más de 3.400 millones de dólares, y los tres mayores incidentes concentraron el 69 % de las pérdidas de servicios.

Qué es una auditoría y qué no garantiza

Una auditoría es una revisión manual y automatizada del código por parte de una firma especializada, que produce un informe con los fallos encontrados y su gravedad. Es útil. También es sistemáticamente sobrevendida.

Lo que una auditoría no cubre:

• El código que se despliega después. La auditoría se hace sobre un commit concreto; si actualizan el proxy la semana siguiente, ese código no está auditado.
• El diseño económico. Un contrato puede ser impecable y su modelo de incentivos ser insostenible. Terra es el ejemplo canónico.
• Los oráculos y las dependencias externas. Suelen quedar fuera del alcance.
• La gestión de claves. Que el multifirma esté bien configurado no lo verifica el código.
• El frontal web. El ataque al Ledger Connect Kit del 14 de diciembre de 2023 no tocó ningún contrato: comprometieron una librería de JavaScript usada por miles de aplicaciones y drenaron unos 484.000 $. Los contratos estaban perfectos.

Una auditoría reduce la probabilidad de un fallo evidente. No convierte un protocolo en seguro, y varios de los incidentes de la tabla anterior ocurrieron en código auditado.

Cómo leer un contrato antes de firmar

No hace falta saber Solidity para hacer estas comprobaciones en un explorador de bloques como Etherscan.

• Comprueba que el código esté verificado. Si el explorador solo te enseña bytecode, no interactúes: nadie puede saber qué hace.
• Mira la fecha de despliegue y el número de transacciones. Un contrato con dos días de vida y cuarenta interacciones es un riesgo distinto a uno con tres años y millones.
• Busca en la pestaña de lectura las funciones owner, admin o similares, y mira qué dirección devuelven. Si es una cuenta individual y no un multifirma, lo sabes.
• Comprueba si es un proxy. Los exploradores lo indican y te enseñan la implementación actual. Si lo es, mira cuándo se actualizó por última vez.
• Busca funciones de pausa, de lista negra o de mint arbitrario. Existen y son legítimas en muchos casos, pero cambian lo que estás asumiendo.
• En la pantalla de firma, lee qué función estás llamando y con qué parámetros. Si el monedero muestra "aprobación ilimitada" y tú creías estar haciendo un swap de 50 €, para.
• Revisa periódicamente tus aprobaciones activas y revoca las que ya no uses.

Ejemplo trabajado: qué ocurre cuando apruebas un token y haces un swap

Quieres cambiar 500 USDC por ETH en un exchange descentralizado. Esto es lo que sucede de verdad, a fecha de agosto de 2026.

Punto de partida. Tus 500 USDC no son un objeto que esté "en tu monedero". Son una entrada en una tabla dentro del contrato de USDC: la dirección de tu cuenta apunta al número 500.000000. Tu monedero no guarda saldos, guarda una clave privada y consulta esa tabla.

Paso 1 — La aprobación. El router del exchange no puede tocar tu saldo de USDC porque el contrato de USDC no se lo permite. Así que firmas una transacción al contrato de USDC, no al exchange, llamando a approve(router, 500000000). Esto escribe una segunda entrada: "la dirección del router puede mover hasta 500 USDC de esta cuenta". Se emite un evento Approval. Coste: una escritura de almacenamiento, del orden de céntimos con el gas a 0,151 gwei.

Aquí es donde muchos frontales te ofrecen aprobar una cantidad ilimitada en vez de 500. Ahorra una transacción futura y deja una autorización viva sobre todo tu saldo de ese token, indefinidamente.

Paso 2 — El swap. Ahora firmas una segunda transacción, esta sí al router, indicando cuánto entregas, qué quieres recibir y un mínimo aceptable de salida. Dentro de esa única transacción ocurre lo siguiente:

1. El router llama a transferFrom en el contrato de USDC.
2. USDC comprueba la autorización que escribiste en el paso 1, la reduce en 500 y mueve tu saldo a la pool.
3. La pool calcula cuánto ETH te corresponde según su fórmula y su liquidez actual.
4. Si el resultado queda por debajo del mínimo que indicaste, toda la transacción revierte: los USDC vuelven a tu cuenta y el gas se pierde.
5. Si pasa el filtro, la pool te transfiere el ETH y emite los eventos correspondientes.

Todo esto es atómico. O sucede entero o no sucede nada. No existe el estado intermedio en el que entregaste los USDC y no recibiste el ETH.

Paso 3 — La factura. Con el gas a 0,151 gwei y ETH a 2.505 $, el swap ronda los 0,131 $ y la aprobación bastante menos. Sobre 500 €, el coste de red es despreciable. Lo que sí te cuesta dinero es la comisión de la pool y el deslizamiento, que dependen de la pool concreta y de su liquidez en ese momento.

Lo que queda después. Si aprobaste exactamente 500 USDC, la autorización queda en cero y no hay nada pendiente. Si aprobaste ilimitado, ese router puede seguir moviendo tus USDC mañana, el mes que viene y dentro de dos años, incluso si actualizan su implementación a otra cosa. Esa autorización olvidada es uno de los vectores más comunes de pérdida de fondos, y revocarla cuesta una transacción de céntimos.

Preguntas frecuentes

Fuentes y referencias

1. Ethereum.org — Introduction to smart contracts
2. Ethereum.org — Ethereum Virtual Machine (EVM)
3. Chainalysis — Crypto hacking and stolen funds 2026
4. Chainalysis — 2026 Crypto Crime Report
5. SEC — Clarifies application of federal securities laws to crypto assets (17 mar 2026)
6. CoinDesk — Ledger Connect Kit exploit (14 dic 2023)
7. Etherscan — explorador de Ethereum y verificación de código

Guías relacionadas