Fallo de acuñación infinita

¿Qué es un fallo de acuñación infinita en cripto?

Un fallo de acuñación infinita es un defecto de un contrato inteligente que permite crear nuevos tokens sin los límites, permisos o controles de oferta adecuados.

En pocas palabras, es un error que puede permitir a un atacante acuñar más tokens de los previstos por el protocolo.

El término suele utilizarse de manera informal, mientras que los investigadores de seguridad pueden describir el mismo problema como una vulnerabilidad de acuñación infinita, un error de acuñación ilimitada, una vulnerabilidad de acuñación no autorizada o un ataque de acuñación infinita.

El glosario cripto de Ledger describe un ataque de acuñación infinita como una situación en la que un fallo de un contrato inteligente o un problema de código permite a un atacante crear una cantidad ilimitada de tokens dentro de un protocolo.

Un fallo de acuñación infinita puede afectar a tokens fungibles, activos wrapped, tokens de gobernanza, tokens de recompensa, activos sintéticos, tokens de videojuegos, activos similares a stablecoins y colecciones de NFT.

El daño puede ser grave porque la oferta de tokens es uno de los fundamentos del valor en cripto.

Si un token debería tener una oferta limitada o controlada, pero un error permite acuñar tokens de forma ilimitada, el mercado puede perder rápidamente la confianza.

En muchos casos, el atacante acuña tokens, los vende en pools de liquidez o mercados, drena activos reales y deja a los titulares con tokens diluidos o devaluados.

Un fallo de acuñación infinita no es un mecanismo de inflación normal.

Es un fallo involuntario de la lógica del token, del diseño de permisos, de los controles de actualización, de la contabilidad de un bridge o de la seguridad de los contratos inteligentes.

Por qué son importantes los fallos de acuñación infinita

Estos fallos son importantes porque pueden destruir la integridad económica de un activo cripto.

Las reglas de oferta de un token indican a los usuarios cuántos tokens pueden existir, quién puede crearlos y en qué condiciones puede incorporarse nueva oferta al mercado.

Si se pueden eludir esas reglas, el precio de mercado del token, su liquidez, el poder de gobernanza, el valor como colateral y la confianza de los usuarios pueden desplomarse.

Este riesgo es especialmente grave en las finanzas descentralizadas, porque los tokens se utilizan a menudo como colateral, activos de pools de liquidez, activos de recompensa, activos de votación o representaciones wrapped de activos en otra cadena.

Si se pueden acuñar tokens falsos o sin respaldo, quizá sea posible intercambiarlos por activos reales antes de que se detecte el fallo.

La pérdida no es solo teórica, ya que los contratos inteligentes pueden mover valor automáticamente una vez confirmada una transacción.

A diferencia de un error normal de base de datos, puede ser difícil o imposible revertir una transacción de blockchain sin una acción especial de gobernanza, una intervención a nivel de cadena o una recuperación negociada.

Por eso los fallos de acuñación infinita se consideran vulnerabilidades de contratos inteligentes de gravedad alta.

Combinan el riesgo técnico con el riesgo directo para la tokenomics.

La ausencia de una sola comprobación de permisos puede convertirse en una crisis de oferta que afecte a todo el mercado.

Cómo funciona un fallo de acuñación infinita

Un fallo de acuñación infinita suele comenzar con una función que crea nuevos tokens.

Esta función puede llamarse mint, issue, bridgeMint, depositMint, rewardMint, claim, redeem u otro nombre específico del proyecto.

La función solo debería permitir que cuentas aprobadas, módulos de confianza o condiciones válidas del protocolo creen tokens.

Si la función es pública, está mal protegida, se ha inicializado de forma incorrecta o se puede alcanzar mediante una ruta de llamada inesperada, un atacante podría activarla.

Una vez que puede acuñar tokens, el atacante podría repetir la acción muchas veces o acuñar una cantidad extremadamente grande en una sola transacción.

Después, los nuevos tokens podrían venderse, transferirse, utilizarse como colateral o para gobernanza, o enviarse a otra cadena mediante un bridge.

La ruta exacta depende del diseño del protocolo.

Algunos fallos de acuñación infinita se deben a la falta de control de acceso.

Otros se deben a una lógica contable defectuosa.

Otros tienen su origen en una inicialización insegura de contratos actualizables.

También pueden deberse a fallos de verificación de un bridge, cuando un contrato acuña activos wrapped sin confirmar que se bloquearon o quemaron activos reales en otro lugar.

Fallos de acuñación infinita y estándares de tokens

Muchos tokens cripto siguen estándares como ERC-20 para los tokens fungibles.

El estándar de tokens ERC-20 define funciones comunes como totalSupply, balanceOf, transfer, approve y transferFrom.

La documentación para desarrolladores de ERC-20 de Ethereum explica que ERC-20 proporciona funciones para transferir tokens, consultar saldos y la oferta total, y aprobar el gasto por parte de terceros.

El estándar ERC-20 no exige por sí mismo que todos los tokens tengan una función de acuñación pública.

La acuñación suele ser una función adicional controlada por el contrato del token o por la lógica del proyecto.

Un contrato de token seguro debería definir quién puede acuñar, qué cantidad se puede acuñar, cuándo está permitida la acuñación y si existe una oferta máxima.

Un fallo de acuñación infinita suele aparecer cuando estas reglas adicionales faltan, están incompletas o se han conectado incorrectamente con otros contratos.

Por eso no basta con utilizar un estándar de token.

Un token puede seguir una interfaz común y, aun así, tener una lógica de acuñación peligrosa.

Causas habituales de los fallos de acuñación infinita

La causa más habitual es la falta de control de acceso en una función de acuñación.

Si cualquiera puede llamar a una función que crea tokens, cualquiera podría inflar la oferta.

Otra causa habitual es una gestión incorrecta de roles.

Un contrato puede utilizar roles como owner, admin, minter, bridge u operator, pero asignarlos de forma incorrecta.

Una tercera causa es una inicialización desprotegida en contratos actualizables.

Si un proxy o un contrato de implementación no se inicializa correctamente, un atacante podría convertirse en propietario o minter.

Una cuarta causa son los fallos de verificación de bridges.

Un contrato de bridge puede acuñar tokens wrapped sin verificar correctamente que los activos se hayan bloqueado o quemado, o que se haya demostrado su existencia en la cadena de origen.

Una quinta causa son los errores aritméticos o contables.

Un contrato puede calcular incorrectamente las recompensas, las participaciones, los depósitos o los saldos reclamables y permitir reclamaciones repetidas.

Una sexta causa son las llamadas externas inseguras.

Si la lógica de acuñación interactúa con otros contratos antes de actualizar el estado interno, un atacante podría encontrar una forma de repetir o manipular el proceso.

Fallos de acuñación infinita y control de acceso

El control de acceso es una de las defensas más importantes contra los fallos de acuñación infinita.

La documentación de control de acceso de OpenZeppelin explica que este control determina quién puede realizar acciones como acuñar tokens, votar o congelar transferencias.

El Smart Contract Top 10 de OWASP incluye las vulnerabilidades de control de acceso entre los principales riesgos de los contratos inteligentes, ya que la falta de controles de permisos o su debilidad pueden permitir que usuarios no autorizados accedan a funciones sensibles.

Una función de acuñación es sensible porque modifica la oferta del token.

Si la acuñación debe limitarse a una tesorería, un bridge, un conjunto de validadores, un contrato de gobernanza o un módulo de recompensas, el código debe aplicar esa regla cada vez.

Un buen control de acceso no debería depender únicamente de la confianza off-chain o de la honestidad del usuario.

El contrato inteligente debería rechazar la acuñación no autorizada aunque un atacante llame directamente a la función.

Los desarrolladores también deberían evitar conceder amplios poderes de acuñación a demasiadas cuentas.

Cuantas más cuentas puedan acuñar, mayor será la superficie de ataque.

Fallos de acuñación infinita y oferta máxima

Una oferta máxima puede reducir el riesgo de acuñación infinita, pero solo si se aplica correctamente en el código.

Un token puede anunciar una oferta máxima en la documentación, las páginas promocionales o un white paper.

Sin embargo, el límite que realmente importa es el que impone el contrato inteligente.

Si el contrato permite acuñar por encima del límite declarado, los usuarios dependen de promesas en lugar de código.

Un límite de oferta seguro debería comprobar la oferta total antes de cada operación de acuñación.

La función de acuñación debería fallar si la nueva oferta supera el límite.

Esta comprobación debe aplicarse a todas las rutas de acuñación, no solo a la función principal.

Por ejemplo, la acuñación de bridges, de recompensas de staking, de reclamaciones y de administradores no debería eludir el límite de oferta, salvo que el diseño lo permita claramente.

Un límite de oferta que se aplica a una función, pero no a otra, puede crear una ruta oculta de acuñación infinita.

Los usuarios y auditores deberían comprobar siempre todas las rutas que puedan aumentar la oferta de tokens.

Fallos de acuñación infinita en activos wrapped

Los activos wrapped están especialmente expuestos al riesgo de acuñación infinita porque representan activos que deberían existir en otro lugar.

Normalmente, un token wrapped se acuña cuando se bloquea, se quema o se demuestra de otra forma la existencia de un activo real en una cadena de origen o un sistema de custodia.

Si el contrato del token wrapped acuña sin una prueba válida, los nuevos tokens wrapped podrían carecer de respaldo.

Esto genera un problema directo de solvencia.

Los usuarios pueden creer que cada token wrapped está respaldado por un activo subyacente, pero el exploit crea más derechos de reclamación de los que el sistema puede atender.

El atacante podría intercambiar los tokens wrapped sin respaldo por activos líquidos antes de que reaccione el mercado.

Por eso las funciones de acuñación de un bridge deben tener reglas de verificación estrictas.

Deberían validar los mensajes, las firmas, los nonces, los eventos de la cadena de origen, la protección contra repetición y los permisos de los relayers de confianza.

Un fallo de acuñación infinita de un activo wrapped no es solo un error del token.

También es un fallo contable cross-chain.

Fallos de acuñación infinita en sistemas de recompensas

Los sistemas de recompensas también pueden provocar fallos de acuñación infinita.

Un contrato de staking, farming, videojuegos o fidelización puede acuñar recompensas según la actividad del usuario.

Si la fórmula de las recompensas es incorrecta, los usuarios podrían reclamar más tokens de los previstos.

Si la función de reclamación no actualiza correctamente los saldos reclamados, se podría reclamar la misma recompensa repetidamente.

Si el contrato confía en los valores proporcionados por el usuario, un atacante podría enviar datos falsos para generar grandes recompensas.

Si el sistema de recompensas no limita las emisiones, un pequeño error lógico puede convertirse en un gran problema de oferta.

Los contratos de recompensas deberían llevar un registro cuidadoso de los depósitos, las participaciones, el historial de reclamaciones, la deuda de recompensas y los límites de emisión.

También deberían probar casos límite, como depósitos de cero, depósitos muy elevados, varias reclamaciones en un bloque y rutas de retirada de emergencia.

La acuñación de recompensas debería tratarse con la misma seriedad que la acuñación de la tesorería.

Fallos de acuñación infinita y contratos actualizables

Los contratos actualizables pueden generar riesgos específicos de acuñación infinita.

Un proyecto puede utilizar un contrato proxy para poder actualizar la lógica más adelante.

Esto puede resultar útil para corregir errores, añadir funciones o mejorar el comportamiento del protocolo.

Sin embargo, la posibilidad de actualización también añade riesgos porque el administrador de la actualización puede tener capacidad para cambiar la lógica de acuñación.

Si el proxy se inicializa incorrectamente, un atacante podría hacerse con el control del rol de administrador.

Si la función de actualización no está protegida, un atacante podría sustituir una lógica segura por otra maliciosa que permita acuñar tokens.

Si la nueva implementación contiene un error en la distribución del almacenamiento, los datos de oferta o de roles pueden corromperse.

Las consideraciones de seguridad oficiales de Solidity advierten de que los contratos tipo proxy y el diseño de autorizaciones requieren una atención especial, ya que los sistemas de contratos pueden conceder inadvertidamente permisos poderosos al componente equivocado.

Los proyectos que utilicen contratos actualizables deberían recurrir a timelocks, aprobaciones multifirma, auditorías, supervisión y procesos de actualización documentados con claridad.

Señales de alerta de un fallo de acuñación infinita

Una señal de alerta es una función de acuñación pública sin una comprobación de permisos visible.

Otra es que la función de acuñación solo compruebe condiciones débiles, como tx.origin, el número de bloque o datos introducidos por el usuario.

Una tercera señal es un sistema de roles en el que el rol minter está controlado por una cuenta desconocida, no verificada o externa.

Una cuarta señal es un token que afirma tener una oferta fija, pero mantiene activas funciones de acuñación sin un límite claro.

Una quinta señal es un token de bridge cuyas pruebas de respaldo no están claras o cuya verificación de mensajes no está documentada.

Una sexta señal es un contrato de recompensas que puede acuñar recompensas sin un calendario de emisiones máximo.

Una séptima señal es un contrato actualizable sin timelock, sin una política de actualización publicada o con un control administrativo poco claro.

Ninguna de estas señales demuestra que exista un exploit.

Sí indican aspectos que merecen una revisión más exhaustiva antes de confiar en el token.

Cómo pueden evitar los desarrolladores los fallos de acuñación infinita

Los desarrolladores pueden evitar estos fallos si diseñan las reglas de acuñación antes de escribir el código.

El proyecto debería definir quién puede acuñar, por qué está permitida la acuñación, qué cantidad puede acuñarse y cuándo debe detenerse.

Todas las rutas de acuñación deberían aplicar controles de acceso.

Todas deberían respetar los límites de oferta o de emisión si así lo exige la tokenomics.

Los desarrolladores deberían evitar duplicar la lógica de acuñación en muchos contratos, porque el código duplicado aumenta la posibilidad de que las comprobaciones sean incoherentes.

Cuando proceda, deberían utilizar bibliotecas revisadas y evitar crear lógica personalizada para tokens sin una razón sólida.

Deberían escribir pruebas unitarias, de integración, de invariantes y fuzzing sobre el comportamiento de la oferta.

También deberían comprobar que las cuentas no autorizadas no puedan acuñar en condiciones normales ni en casos límite.

El diseño más seguro parte de la base de que los atacantes llamarán directamente a las funciones, reordenarán transacciones, utilizarán contratos para llamar y probarán todas las ramas del código.

Auditoría del riesgo de acuñación infinita

Una auditoría de contratos inteligentes debería rastrear todas las funciones que puedan aumentar la oferta del token.

El auditor debería buscar funciones de acuñación directas, llamadas internas a la acuñación, reclamaciones de recompensas, mensajes de bridges, contratos de depósito, funciones de administración, funciones de actualización y controles de emergencia.

También debería confirmar que cada ruta que aumenta la oferta dispone de los permisos adecuados.

Además, debería verificar que la oferta total no pueda superar el límite previsto ni el modelo de emisión.

El Smart Contract Security Verification Standard de OWASP establece requisitos y pruebas de seguridad que pueden ayudar a los equipos a diseñar, revisar y verificar contratos inteligentes seguros.

Los auditores también deberían revisar los eventos, ya que la acuñación debería generar registros on-chain claros.

Si la oferta puede cambiar sin eventos transparentes, la supervisión resulta más difícil.

Una auditoría no debería limitarse a preguntar si la acuñación funciona.

Debería comprobar si puede funcionar cuando no debería.

Pruebas para detectar fallos de acuñación infinita

Las pruebas para detectar estos fallos deberían incluir tanto el comportamiento normal como el comportamiento ante fallos.

El comportamiento normal significa que los minters autorizados pueden acuñar la cantidad correcta cuando se cumplen las condiciones válidas.

El comportamiento ante fallos significa que los usuarios no autorizados no pueden acuñar, que no se pueden acuñar cantidades excesivas y que las pruebas inválidas no pueden crear oferta.

Las pruebas de invariantes son especialmente útiles porque comprueban que se cumplan siempre reglas clave.

Una invariante útil puede establecer que la oferta total nunca supere la oferta máxima.

Otra puede establecer que la oferta de tokens wrapped nunca supere el respaldo verificado.

Una invariante de recompensas puede establecer que el total de recompensas acuñadas nunca supere el calendario de emisiones.

Las pruebas fuzzing pueden ayudar a encontrar entradas poco habituales que quizá no se les ocurran a las personas.

La verificación formal también puede ayudar en sistemas de alto valor, especialmente cuando las reglas de oferta son lo bastante sencillas como para expresarlas matemáticamente.

Las pruebas adecuadas deberían realizarse antes de la implementación y continuar después de las actualizaciones.

Supervisión del riesgo de acuñación infinita tras el lanzamiento

La seguridad no termina cuando se implementa un contrato.

Después del lanzamiento, los proyectos deberían supervisar la oferta del token, los eventos de acuñación, los cambios de roles, los mensajes de bridges, los eventos de actualización y las transferencias inusuales.

Un sistema de supervisión puede alertar al equipo si la oferta aumenta demasiado rápido o si una dirección inesperada acuña tokens.

También puede alertar al equipo cuando cambien los roles administrativos, se actualicen contratos de implementación o grandes cantidades de tokens recién acuñados pasen a pools de liquidez.

Los paneles públicos pueden ayudar a los usuarios a verificar que la oferta del token coincide con la tokenomics declarada por el proyecto.

Los planes de respuesta ante emergencias deberían prepararse antes de que se produzca un incidente.

Estos planes pueden incluir pausar contratos, desactivar la acuñación, ponerse en contacto con colaboradores de seguridad, avisar a los usuarios, coordinarse con plataformas de liquidez y publicar un informe posterior al incidente.

Un proyecto que detecte tarde un fallo de acuñación infinita quizá solo disponga de unos minutos para reducir los daños.

Una detección rápida suele ser tan importante como un buen código.

Impacto en los titulares de tokens

Un fallo de acuñación infinita puede perjudicar a los titulares mediante la dilución.

Si un atacante crea muchos tokens, cada token existente puede representar una proporción menor de la oferta total.

El mercado también puede descontar el temor a que se creen más tokens en el futuro.

Esto puede reducir la liquidez y dificultar que los titulares cierren sus posiciones.

En algunos casos, también puede afectar a la gobernanza.

Si el poder de gobernanza depende del saldo de tokens, un atacante podría acuñar suficientes para influir en las votaciones.

En DeFi, el atacante podría utilizar los tokens acuñados como colateral si un protocolo de préstamos acepta el activo.

Esto puede provocar pérdidas que vayan más allá del contrato original del token.

El impacto puede extenderse a pools de liquidez, mercados de préstamos, bridges, wallets y herramientas de seguimiento de carteras.

Por eso los fallos de acuñación infinita son riesgos sistémicos para los tokens integrados en numerosos protocolos.

Impacto en los pools de liquidez

Los pools de liquidez suelen ser el primer lugar donde se hace visible el daño causado por una acuñación infinita.

Un atacante puede acuñar tokens e intercambiarlos por los activos emparejados de un pool.

A medida que el atacante vende los tokens falsos o excedentarios, el pool se llena de tokens explotados y se queda sin el activo emparejado.

Los proveedores de liquidez pueden sufrir pérdidas porque el saldo de activos del pool cambia drásticamente.

También pueden distorsionarse los oráculos de precios que dependen de los precios del pool.

Si otros protocolos utilizan esos precios, el daño puede propagarse.

Un protocolo bien diseñado no debería depender de un único pool con poca liquidez para fijar precios críticos.

El diseño de oráculos, la profundidad de liquidez, los interruptores automáticos y la supervisión de la oferta pueden reducir la posibilidad de que un fallo de acuñación infinita provoque un fallo más amplio de DeFi.

Aun así, el error de oferta original debe corregirse en el contrato.

Fallo de acuñación infinita frente a tokenomics inflacionaria

Un fallo de acuñación infinita no es lo mismo que una tokenomics inflacionaria.

Una tokenomics inflacionaria significa que el protocolo crea intencionadamente nueva oferta conforme a reglas conocidas.

Un fallo de acuñación infinita significa que el protocolo crea o permite nueva oferta al margen de las reglas previstas.

La inflación puede ser normal si financia recompensas de staking o minería, incentivos para el ecosistema o la seguridad de los validadores.

La acuñación ilimitada y no autorizada es anómala porque incumple el modelo de oferta previsto.

Un token puede ser inflacionario y seguir siendo seguro si la emisión está limitada, es transparente y está controlada.

Un token puede afirmar que tiene una oferta fija y seguir siendo inseguro si existen rutas de acuñación ocultas.

Los usuarios deberían centrarse en el código aplicable, no solo en el lenguaje promocional.

La pregunta clave es si la nueva oferta sigue las reglas publicadas y si la lógica del contrato inteligente protege esas reglas.

Fallo de acuñación infinita frente a ataque de reentrada

Un fallo de acuñación infinita y un ataque de reentrada son conceptos distintos, aunque en ocasiones pueden solaparse.

Un ataque de reentrada se produce cuando una llamada externa permite que un contrato o un atacante vuelva a entrar en una función antes de que termine la primera ejecución.

Un fallo de acuñación infinita se centra en la creación de tokens no autorizada o excesiva.

Un error de reentrada podría provocar acuñaciones repetidas si la lógica actualiza el estado después de una llamada externa.

Sin embargo, muchos fallos de acuñación infinita no requieren reentrada.

Pueden deberse a la falta de control de acceso, pruebas de bridge incorrectas, inicialización insegura o cálculos de oferta defectuosos.

Esta distinción importa porque corregir una clase de error no corrige automáticamente la otra.

Un contrato puede protegerse contra la reentrada y seguir teniendo una función de acuñación sin protección.

Un token seguro necesita tanto un flujo de control seguro como una autorización de oferta segura.

Fallo de acuñación infinita frente a aprobación ilimitada

No hay que confundir un fallo de acuñación infinita con una aprobación ilimitada de tokens.

Una aprobación ilimitada significa que un usuario concede a otro contrato permiso para gastar una cantidad muy elevada de sus tokens existentes.

La acuñación infinita significa que se pueden crear nuevos tokens por encima de las reglas de oferta previstas.

Ambos problemas pueden ser peligrosos, pero afectan a distintas partes del sistema del token.

Una aprobación ilimitada pone en peligro el saldo de un usuario si el autorizado es malicioso o sufre un ataque.

La acuñación infinita pone en peligro toda la oferta del token si la lógica de acuñación es vulnerable.

Un usuario puede reducir el riesgo de una aprobación ilimitada gestionando los permisos de los tokens.

Un usuario no puede corregir por su cuenta un error de acuñación infinita en un contrato de token ya implementado.

Para mitigar el riesgo de acuñación infinita, los usuarios dependen del diseño del contrato, las auditorías, la supervisión, la gobernanza y la respuesta del proyecto.

Cómo pueden comprobar los usuarios el riesgo de acuñación infinita

Los usuarios pueden empezar comprobando si el contrato del token está verificado en un explorador de bloques.

Un contrato verificado permite a los usuarios y auditores leer el código fuente que corresponde al bytecode implementado.

Los usuarios pueden buscar funciones que incluyan términos como mint, issue, create, reward, bridge, claim o upgrade.

Pueden comprobar si estas funciones están protegidas mediante roles, propiedad, gobernanza o verificaciones de módulos de confianza.

Pueden revisar si el token tiene una oferta máxima y si el límite se aplica on-chain.

También pueden comprobar si los roles administrativos están controlados por una wallet multifirma, un timelock o una única cuenta desconocida.

Los usuarios deberían leer los informes de auditoría cuando estén disponibles, pero recordar que una auditoría no es una garantía.

También deberían comprobar si el proyecto dispone de supervisión pública, programas de recompensas por errores y procedimientos claros de respuesta ante incidentes.

Si las reglas de oferta de un token no están claras, lo más prudente es asumir que el riesgo es mayor.

Buenas prácticas para los proyectos

Los proyectos deberían mantener una lógica de acuñación sencilla y fácil de auditar.

Deberían utilizar controles de acceso basados en roles para todas las funciones de acuñación.

Cuando la tokenomics lo requiera, deberían aplicar límites a la oferta máxima o a las emisiones.

Deberían evitar conceder poderes de acuñación a cuentas externas ordinarias si existen controles de gobernanza o multifirma más seguros.

Cuando el sistema no esté en modo de emergencia, deberían utilizar timelocks para los cambios importantes relacionados con la oferta.

Deberían publicar una tokenomics que coincida con el comportamiento real del contrato inteligente.

Deberían supervisar en tiempo real los eventos de acuñación y los cambios de roles.

Deberían realizar auditorías antes del lanzamiento y después de las actualizaciones importantes.

Deberían preparar un plan de respuesta ante emergencias antes de que los usuarios y la liquidez corran riesgos.

Deberían tratar todas las funciones que aumenten la oferta como una superficie de seguridad crítica.

Buenas prácticas para los usuarios

Los usuarios no deberían confiar únicamente en la oferta máxima declarada de un token.

Deberían comprobar si el contrato aplica realmente ese límite.

Deberían evitar tokens con permisos de acuñación poco claros, controles administrativos ocultos o contratos que no se puedan verificar.

Deberían actuar con cautela ante activos wrapped con documentación deficiente sobre las pruebas o cuyo respaldo no esté claro.

Deberían tratar con cuidado los tokens de recompensa muy recientes, ya que los errores en su acuñación pueden ser difíciles de detectar al principio.

Deberían supervisar los aumentos repentinos de oferta, los grandes eventos de acuñación y las transferencias anómalas de tokens.

Deberían diversificar el riesgo en lugar de concentrar demasiado valor en un único token no auditado.

Deberían entender que una rentabilidad elevada puede ocultar un riesgo alto de los contratos inteligentes.

Deberían recordar que la recuperación del precio es incierta después de un exploit de acuñación infinita.

Errores habituales sobre los fallos de acuñación infinita

Un error habitual es pensar que los fallos de acuñación infinita solo afectan a memecoins o proyectos de baja calidad.

En realidad, cualquier token con una lógica compleja de acuñación, bridge, recompensas o actualización puede estar expuesto a este riesgo.

Otro error es creer que afirmar que la oferta es fija garantiza la seguridad.

Una oferta fija solo es significativa si el contrato inteligente la aplica en todas las rutas de acuñación.

Un tercer error es pensar que el control de acceso por sí solo es suficiente.

El control de acceso es esencial, pero también importan los límites de oferta, las pruebas de bridges, las comprobaciones contables, las pruebas, la supervisión y los controles de actualización.

Un cuarto error es creer que una auditoría elimina todos los riesgos.

Una auditoría reduce el riesgo, pero no puede garantizar que no exista ningún error ni que las futuras actualizaciones sigan siendo seguras.

Un quinto error es pensar que la acuñación infinita siempre requiere técnicas de hacking avanzadas.

Algunos incidentes se deben a errores sencillos, como una función desprotegida, un rol incorrecto o un inicializador olvidado.

Preguntas frecuentes

¿Qué significa «fallo de acuñación infinita»?

Significa que un error de un contrato inteligente permite crear nuevos tokens sin los límites o permisos previstos.

¿Un fallo de acuñación infinita es lo mismo que un ataque de acuñación infinita?

Están estrechamente relacionados, pero el fallo es la vulnerabilidad y el ataque es la explotación de esa vulnerabilidad.

¿Un fallo de acuñación infinita puede destruir el valor de un token?

Sí. Puede destruir valor al crear una oferta excesiva, drenar liquidez, dañar la confianza y provocar una dilución grave.

¿Qué provoca un fallo de acuñación infinita?

Entre las causas habituales se encuentran la falta de control de acceso, una configuración incorrecta de roles, una inicialización insegura, pruebas de bridge defectuosas, errores contables en las recompensas y límites de oferta débiles.

¿Puede un token ERC-20 sufrir fallos de acuñación infinita?

Sí. Un token ERC-20 puede tener este fallo si la lógica de acuñación añadida es insegura o está mal controlada.

¿Una oferta máxima impide la acuñación infinita?

La oferta máxima solo ayuda si el contrato la aplica correctamente en todas las rutas de acuñación posibles.

¿Los activos wrapped pueden sufrir fallos de acuñación infinita?

Sí. Pueden sufrirlos si un bridge o un contrato de acuñación crea tokens sin respaldo y sin pruebas válidas.

¿Una auditoría puede evitar los fallos de acuñación infinita?

Una auditoría puede reducir el riesgo, pero no garantizar la seguridad, especialmente si el contrato se actualiza más adelante o se integra con nuevos sistemas.

¿Cómo pueden detectar los usuarios el riesgo de acuñación infinita?

Pueden revisar los contratos verificados, las funciones de acuñación, los roles de control de acceso, los límites de oferta, los informes de auditoría, los controles administrativos y los eventos de acuñación on-chain.

¿Qué debería hacer un proyecto al descubrir un fallo de acuñación infinita?

Si es posible, debería pausar las funciones afectadas, detener la acuñación, proteger la liquidez restante, avisar a los usuarios, investigar la causa raíz y publicar un informe claro del incidente.

¿Un fallo de acuñación infinita es lo mismo que la inflación?

No. La inflación es una emisión planificada de tokens, mientras que un fallo de acuñación infinita crea oferta de forma involuntaria o no autorizada.

¿Por qué es importante el control de acceso en la acuñación?

Es importante porque la acuñación modifica la oferta del token y solo deberían realizarla contratos o cuentas autorizados conforme a reglas estrictas.

Conclusión

Un fallo de acuñación infinita es una de las vulnerabilidades más peligrosas de los contratos inteligentes en cripto, porque puede incumplir las reglas de oferta de un token.

Se produce cuando un contrato permite acuñar tokens sin la autorización, los límites, las pruebas o los controles contables adecuados.

Puede provocar una dilución masiva, el drenaje de liquidez, el fallo de sistemas de colateral, daños a la gobernanza y la pérdida de confianza de los usuarios.

El riesgo es especialmente importante en tokens con funciones de acuñación, sistemas de recompensas, activos wrapped, bridges, contratos actualizables y una gestión compleja de roles.

Los desarrolladores pueden reducir el riesgo mediante controles de acceso sólidos, límites de oferta aplicables, pruebas de invariantes, auditorías de todas las rutas de acuñación, actualizaciones seguras y supervisión de los cambios de oferta tras el lanzamiento.

Los usuarios pueden reducir su exposición comprobando los contratos verificados, revisando los permisos de acuñación, estudiando las auditorías, vigilando los cambios de oferta y evitando tokens cuyo control de nuevas emisiones no esté claro.

Un fallo de acuñación infinita no es una inflación normal ni un error de programación inofensivo.

Es un fallo de la oferta que puede afectar a todos los titulares y a todos los protocolos conectados al token.

En cripto, el código controla el dinero y el código de acuñación controla la oferta.

Por eso todas las funciones que aumenten la oferta deben diseñarse, probarse, auditarse y supervisarse como una parte crítica de la seguridad del token.