Privilegios Ocultos del Propietario: Funciones de Administración Peligrosas Dentro de Contratos 'Verificados'
— By Tony Rabbit in Tutorials

El código fuente verificado no significa que un token sea seguro. Aprende a auditar la lista de funciones de escritura (Write-function) de cualquier contrato, a detectar privilegios exclusivos del propietario como blacklist() y pause(), y a distinguir las herramientas de administración inofensivas de las puertas traseras que atrapan a los holders.
Los privilegios ocultos del propietario en un contrato inteligente son funciones exclusivas del administrador que permiten a un implementador de tokens cambiar las reglas después de que ya hayas comprado, y rutinariamente sobreviven en contratos que parecen perfectamente limpios en un explorador de bloques. La parte peligrosa es que la verificación del código fuente solo prueba que el código publicado coincide con el bytecode en la cadena. No dice nada sobre lo que ese código puede hacer. Un contrato puede ser verificado, auditado e incluso parcialmente renunciado, mientras que todavía contiene una función que permite al propietario congelar tu billetera, limitar tus ventas o acuñar nuevos suministros de la nada. Esta guía es una auditoría práctica, no un glosario. Aprenderás exactamente qué funciones buscar, cómo leerlas en el explorador y cómo separar las herramientas de administración rutinarias de una trampa.
Puntos Clave
- La verificación prueba que el código coincide con el bytecode, no que el código sea seguro.
- blacklist(), pause() y los interruptores de trading pueden congelar tus órdenes de venta permanentemente.
- Una puerta trasera de mint permite a un desarrollador diluir a los holders sin tocar nunca el pool de liquidez.
- Lee la pestaña Write en el explorador y juzga las funciones por quién puede llamarlas y qué cambian.
Por qué un contrato verificado o parcialmente renunciado aún puede ser peligroso
La verificación es una característica de transparencia, no un sello de seguridad. Cuando un proyecto verifica su contrato, el explorador compila el código fuente enviado y confirma que produce el bytecode exacto ya implementado. Esto es realmente útil porque te permite leer lo que hace el contrato en lugar de mirar hexadecimal. Pero un desarrollador malicioso también quiere la verificación, porque un contrato limpio y legible genera confianza más rápido que uno no verificado. Muchas estafas envían código verificado a propósito. Si no tienes clara la distinción, nuestra explicación sobre lo que realmente significa un contrato verificado detalla los límites.
Renunciar a la propiedad tiene una laguna similar. Un desarrollador puede renunciar al rol de propietario estándar y aún así mantener una segunda dirección privilegiada codificada en la lógica, o renunciar solo después de que los setters peligrosos ya hayan hecho su daño. La renuncia tampoco sirve de nada si la función riesgosa fue escrita para ser invocable por cualquiera, o si nunca estuvo protegida por la propiedad en primer lugar. Lee nuestro desglose de lo que realmente prueba un contrato renunciado antes de tratar la renuncia como una luz verde. El resumen honesto: verificado más renunciado es un punto de partida, no un veredicto.
Privilegios ocultos del propietario a buscar en un contrato inteligente
La mayor parte del poder que atrapa a los holders reside en un puñado de funciones exclusivas del propietario. Aprende estos nombres y podrás escanear un contrato en uno o dos minutos. Ten en cuenta que los desarrolladores a menudo los renombran, así que juzga por el comportamiento, no solo por la etiqueta.
- blacklist() / setBlacklist() / addBot() marca billeteras específicas para que no puedan transferir ni vender. Un desarrollador puede poner en la lista negra a los compradores justo después de que entren, dejándolos con tokens que nunca podrán descargar.
- setMaxTx() / setMaxWallet() limita cuánto puedes mover en una transacción. Establecido en un valor minúsculo, hace que las ventas significativas sean imposibles mientras las compras siguen fluyendo.
- enableTrading() / setTradingEnabled() alterna si las transferencias funcionan en absoluto. Si el trading se puede desactivar después del lanzamiento, tu salida puede cerrarse a voluntad.
- mint() o cualquier función que aumente el suministro es una puerta trasera para diluir a cada holder. Así es como un desarrollador puede drenar valor sin retirar liquidez.
- pause() / unpause() detiene toda la actividad del token. Una pausa de seguridad genuina está bien en teoría, pero en las manos equivocadas es un botón de congelación para todo el mercado.
- setFee() / setTaxes() cambia el impuesto de compra o venta. Busca un límite máximo en el código. Si el propietario puede establecer un impuesto de venta del 99 por ciento, cada venta es efectivamente confiscada.
Cómo leer la lista de funciones de escritura (Write-function) en un explorador de bloques
Abre el token en un explorador de bloques, ve a la pestaña Contrato y selecciona Write Contract (o Write as Proxy si el token utiliza un patrón de proxy). Esta lista es el menú completo de acciones que cambian el estado que expone el contrato. Lee cada entrada por su nombre y hazte tres preguntas: qué cambia, quién está autorizado a llamarla y si hay un límite en el valor al que se puede establecer.
Para verificar quién puede llamar a una función, cambia a la pestaña Read Contract y busca owner() para ver la dirección del propietario actual. Si devuelve la dirección cero (0x000...000), la propiedad ha sido renunciada. Luego, busca en las definiciones de funciones en la pestaña Código un modificador onlyOwner o una declaración require que restrinja al llamador. Una función sin control de acceso que cambia saldos o tarifas es una seria señal de alerta. Si leer Solidity no es tu fuerte, los escáneres automatizados hacen este triaje por ti, y nuestro resumen de las mejores herramientas gratuitas para analizar contratos inteligentes cubre aquellas que marcan funciones privilegiadas automáticamente.
Lo que cada privilegio permite hacer a un desarrollador, incluyendo el rugging sin tocar la liquidez
El rug pull clásico drena el pool de liquidez, y a menudo puedes verlo venir si el LP está desbloqueado. Los privilegios ocultos del propietario permiten una versión más silenciosa que nunca toca la liquidez. Con una función blacklist() operativa, un desarrollador permite que todos compren, observa cómo sube el precio y luego pone en la lista negra a los holders para que solo el equipo pueda vender ante la demanda de compra. El pool permanece lleno y el gráfico parece saludable hasta el momento en que tu venta se revierte. Una función setFee() sin límite logra el mismo resultado al dirigir casi todas las ventas a la billetera del equipo. Una puerta trasera mint() es la más lenta y más negable: el propietario acuña discretamente una enorme nueva asignación y la vende gradualmente, diluyendo a los holders mientras el contrato aún pasa una verificación de liquidez casual. Debido a que ninguna de estas requiere retirar el LP, a menudo pasan desapercibidas para las herramientas que solo monitorean la eliminación de liquidez, por lo que la revisión a nivel de función es importante junto con nuestra lista de verificación de rug pull más amplia.
Distinguir funciones de administración inofensivas de aquellas que atrapan a los holders
No todas las funciones exclusivas del propietario son una amenaza. Muchos tokens legítimos mantienen herramientas de administración por buenas razones, y el objetivo es la calibración, no la paranoia. Tres pruebas separan las funciones rutinarias de las trampas. Primero, ¿el estado peligroso ya está bloqueado en la dirección segura? Un interruptor de trading está bien una vez que el trading está permanentemente activado y la función ya no puede desactivarlo. Segundo, ¿hay un límite codificado? Una función setFee() que nunca puede exceder, digamos, el 10 por ciento es defendible, mientras que una sin límite superior no lo es. Tercero, ¿se ha renunciado a la propiedad o se ha movido a un timelock o multisig? Un privilegio que ninguna persona puede activar instantáneamente es mucho menos peligroso que uno controlado por una EOA anónima. Ejemplos genuinamente benignos incluyen una función enableTrading() de una sola vez que se activa en el lanzamiento y no se puede desactivar, una función excludeFromFee() para routers y el propio contrato, y una función de retiro limitada a la billetera de tarifas en lugar del pool de liquidez. Combina este juicio con nuestra guía más amplia sobre cómo verificar si un token es seguro antes de comprar para que la lectura del contrato sea una entrada entre varias.
Una lista de verificación rápida de auditoría de privilegios del propietario
Ejecuta esta secuencia antes de comprar cualquier token. Lleva unos minutos y detecta las trampas más comunes:
- Confirma que el contrato está verificado para que realmente puedas leer el código fuente.
- Abre la pestaña Write Contract y enumera cada función que cambia el estado.
- Marca las funciones blacklist, pause, mint, el interruptor de trading, max-tx y los setters de tarifas.
- Para cada marca, verifica el control de acceso: quién puede llamarla y si la propiedad ha sido renunciada, bloqueada por tiempo (timelocked) o multisig.
- Verifica si los setters de impuestos tienen un límite máximo codificado y cuál es ese límite.
- Confirma que cualquier interruptor de trading no se puede volver a desactivar después del lanzamiento.
- Compara con un escáner automatizado para detectar cualquier cosa que hayas pasado por alto.
- Si una sola billetera anónima puede congelar ventas, aumentar impuestos sin límite o acuñar suministro, trata el token como de alto riesgo, independientemente de lo limpio que parezca.
La disciplina que te protege es simple: juzga un contrato por lo que su propietario tiene permitido hacer, no por las insignias que lleva. Verificado y renunciado son entradas, nunca conclusiones. Una vez que leer la pestaña Write se convierte en un hábito, las palancas ocultas dejan de estar ocultas.
Este artículo es solo para fines educativos y no constituye asesoramiento financiero.