Tokens honeypot: los compras, pero no los vendes. Cómo lo hace el smart contract y cómo comprobarlo tú mismo

¿Qué es un honeypot en una sola frase?

Un honeypot es un token en el que el contrato te permite la compra, pero técnicamente imposibilita la venta o la carga con una comisión tan alta que de la venta no te queda casi nada. En el gráfico parece un cohete que solo sube, porque casi nadie puede vender.

Importante: en este texto describimos patrones generales en el código y en los datos, no proyectos concretos. No decimos que ningún token en particular sea una estafa. Mostramos cómo funciona el mecanismo y cómo cualquiera puede verificarlo por sí mismo. La mecánica que exponemos aquí parte de la documentación pública del estándar ERC-20, del lenguaje Solidity y de la documentación de los exchanges descentralizados (Uniswap, PancakeSwap), a la que remitimos en las fuentes.

¿Cómo lo hace técnicamente el contrato?

Un token en las cadenas EVM (Ethereum, BNB Chain y similares) es solo un smart contract. Según el estándar ERC-20, la transferencia del token pasa por la función transfer o transferFrom (ver la documentación de ERC-20 y de OpenZeppelin en las fuentes). En el cuerpo de esa función el creador puede escribir en Solidity cualquier condición. La compra y la venta no son dos funciones distintas, son solo transferencias entre tu cartera y el par de liquidez (por ejemplo en Uniswap o PancakeSwap, cuya mecánica de pares describe su documentación). Esa es la clave: el contrato sabe distinguir si los tokens salen hacia el par de liquidez (venta) o del par hacia ti (compra), y comportarse de forma distinta en cada caso.

Los patrones más habituales que aparecen en este tipo de contratos:

Lo común es que la lógica es condicional y conmutable. El contrato no tiene por qué ser un honeypot desde el principio. Puede convertirse en uno en el momento en que el creador llame a una función que restrinja el trading.

¿Cómo se ve con un número concreto?

Imaginemos un ejemplo simplificado y puramente ilustrativo (no son datos medidos). Metes 1 ETH en el contrato y compras 1 000 000 de tokens. La compra pasa sin problemas, porque el impuesto de compra está fijado en 0 %.

Luego intentas vender esos 1 000 000 de tokens de vuelta. Surgen dos situaciones típicas:

1. Honeypot duro: la transacción no pasa en absoluto. La cartera informa de que la transacción falló (revert). Tus tokens se quedan, el ETH no lo recibes.
2. Honeypot blando (fiscal): la venta pasa, pero el impuesto de venta es del 99 %. Del valor equivalente a 1 ETH te llega a la cuenta el equivalente a 0,01 ETH. Formalmente "pudiste vender", pero en realidad perdiste casi todo.

La diferencia entre estos dos casos es importante: el honeypot blando a menudo pasa un test superficial, porque la venta técnicamente funciona. Solo al mirar el importe resultante se ve que el impuesto se tragó casi todo el saldo.

¿Cómo puede uno comprobarlo antes de comprar?

Existen varios procedimientos que trabajan solo con datos disponibles públicamente. Los describimos como herramientas de verificación, no como garantía.

1. Simulación de venta

Algunas herramientas (honeypot checkers, o simuladores de transacciones) ejecutan en un entorno de prueba una compra simulada e inmediatamente una venta y miden cuánto se devolvería. El resultado suele ser el impuesto de compra estimado, el impuesto de venta y la información de si la venta pasa siquiera. Limitación: la simulación parte del estado actual del contrato. Si el creador cambia la lógica más tarde, el resultado ya puede no ser válido.

2. Lectura del código fuente verificado

En el block explorer (por ejemplo Etherscan para Ethereum o BscScan para BNB Chain, ver fuentes) se ve el código Solidity de los contratos verificados. Patrones a vigilar:

• funciones que cambian impuestos o reglas de trading tras el despliegue,
• condiciones require dentro de la transferencia que difieren para compra y venta,
• roles del tipo onlyOwner que permiten al propietario intervenir unilateralmente,
• listas de direcciones (_isBlacklisted y similares).

Si el contrato no está verificado (el código fuente no está publicado), no se puede leer qué hace. Eso por sí solo no es prueba de nada, pero es información sobre lo que no sabes.

3. Vista de las ventas reales en la cadena

En el historial de transacciones del par se puede averiguar si alguien ha vendido con éxito. Cuando hay muchas compras y casi ninguna venta, es un patrón que merece atención. Al contrario, una serie de ventas normales desde distintas direcciones es una señal de que la venta funcionaba en ese momento.

4. Quién posee y quién puede cambiar

Es útil mirar la distribución de holders y si la propiedad del contrato está renunciada (renounced), o si el propietario aún tiene derecho a cambiar parámetros. La renuncia a la propiedad reduce el riesgo de un cambio adicional de reglas, pero no descarta que la lógica de honeypot ya esté fija en el código.

¿Por qué ni siquiera un test limpio es garantía?

Porque el estado del contrato es variable en el tiempo. Tres trampas concretas:

• Cambio programado: hoy funcionan tanto la compra como la venta, mañana el creador llama a una función que bloquea la venta.
• Impuestos por umbral: el impuesto sube solo tras alcanzar cierto volumen o número de holders.
• Contratos proxy: la lógica se puede intercambiar mediante un proxy actualizable, de modo que el código que leíste ya puede no ser el que se ejecuta.

Por eso, el test dice cómo se comportó el contrato en el momento del test, no cómo se comportará después. Precisamente por estas trampas consideramos el resultado de la simulación y de la lectura del código como un fuerte indicio, no como una certeza.

Qué deberías saber hacer ahora y qué sigue siendo incierto

Tras esta lección deberías ser capaz de:

• explicar por qué el contrato puede distinguir la compra de la venta,
• nombrar los patrones básicos de honeypot (blacklist, impuesto asimétrico, bloqueo de venta, flag conmutable),
• distinguir el honeypot duro (la venta no pasa) del blando (la venta pasa, pero el impuesto se lleva casi todo),
• realizar tres verificaciones: simulación de venta, lectura del código verificado y comprobación de las ventas reales en la cadena.

Lo que sigue siendo incierto y no se puede averiguar de forma fiable de antemano: cómo se comportará el creador en el futuro, si cambiará los parámetros, y si detrás de un contrato proxy no intercambiará la lógica. Ninguna herramienta da una certeza del cien por cien, porque trabaja con el estado pasado y presente, no con la intención futura.

Esto no es una recomendación sobre qué hacer con tu dinero. Es una descripción de la mecánica y de los métodos de verificación, para que decidas con los ojos abiertos.