﻿---
title: "Cómo identificar tokens honeypot"
description: "Lista práctica para detectar tokens que pueden comprarse pero no venderse: identidad del contrato, restricciones, privilegios, simulación, liquidez y prueba de ida y vuelta."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cómo identificar tokens honeypot

> Contenido educativo; no constituye asesoramiento de inversión. Los criptoactivos pueden perder todo su valor.

<a id="answer"></a>

## Respuesta directa

Un token honeypot está diseñado o configurado para que el operador pueda adquirirlo, pero no venderlo con normalidad, o solo venderlo pagando una comisión extrema. La restricción puede estar en la lógica de transferencia, un contrato externo, una lista de direcciones, un interruptor de negociación, un límite o una implementación actualizable.

Ningún resultado aislado de un escáner demuestra que el token sea seguro. Comprueba por separado la red y dirección exactas, el código verificado y los roles privilegiados; simula la ruta completa de venta desde la cartera prevista; revisa ventas reales y liquidez; y solo entonces considera una ida y vuelta pequeña cuya pérdida total puedas asumir.

Un gráfico alcista aporta poca evidencia. Si la mayoría no puede vender, el historial puede mostrar compras sin un flujo competitivo de ventas, y el precio mostrado no dice cuánto valor puede salir realmente del pool.

<a id="mechanism"></a>

## Cómo funciona

ERC-20 normaliza funciones como `transfer` y `transferFrom`, pero no exige la misma política a todos los tokens. Una implementación personalizada puede condicionar por remitente, destinatario, importe, estado del bloque u otro contrato. Así puede permitir transferencias al pool y revertir, retener casi todo o bloquear selectivamente la salida por la ruta de venta.

Revisa la ejecución completa, no solo el nombre de una función. Una venta en un creador de mercado automatizado puede involucrar autorización, router, varios pools y la lógica del token. Busca funciones controladas por propietario o rol que pausen operaciones, cambien comisiones o límites, gestionen listas, sustituyan router o par, acuñen oferta o modifiquen dependencias.

Renunciar a la propiedad no es concluyente. Pueden quedar otros roles o controladores, y un proxy puede conservar la dirección mientras cambia la implementación. OpenZeppelin indica que las funciones privilegiadas pueden acuñar, congelar transferencias o actualizar; un bloqueo temporal permite conocer un cambio programado y salir antes.

La simulación es útil, pero limitada. `eth_call` ejecuta sobre el estado de un bloque elegido sin crear una transacción; `eth_estimateGas` tampoco la añade a la cadena. Configura remitente, ruta, importe y contexto reales. El éxito describe esa llamada en ese estado, no el bloque siguiente ni una acción administrativa posterior.

<a id="example"></a>

## Flujo de verificación

- Confirma red y dirección completa con fuentes oficiales independientes. En el explorador, comprueba que el bytecode coincide con el código publicado y si la dirección es un proxy.

- Sigue `transfer` y `transferFrom`, incluidos código heredado y llamadas externas. Identifica ajustes de comisión, interruptores, máximos por cartera o transacción, listas, exenciones, roles, administradores de proxy y demoras.

- Examina ventas recientes de direcciones no relacionadas. Confirma que produjeron el activo esperado, no solo un estado exitoso. Compara entrada, salida, eventos, comisión efectiva, impacto y reservas.

- Simula la venta exacta desde la cartera prevista en el estado actual. Contrasta al menos dos herramientas o RPC independientes cuando importe; una reversión, salida inexplicable o gran discrepancia es señal de parada.

- Si todo lo anterior resulta satisfactorio, prueba compra y venta con un importe que puedas perder por completo. Verifica saldos finales y recibos. No eleves repetidamente el deslizamiento para forzar una operación inexplicable.

La cifra económica relevante es el valor recuperable, no el saldo mostrado:

Valor recuperable = salida esperada del swap - impacto de precio - comisión del protocolo - comisión del token - comisión de red

Las reservas también pueden dificultar la salida de un token legítimo. Estima la salida para el tamaño previsto; una venta diminuta no demuestra que otra mayor se ejecute cerca del precio mostrado.

<a id="risks"></a>

## Señales de alerta y límites

- Las ventas revierten mientras las compras funcionan, o solo venden direcciones privilegiadas o exentas.

- La comisión efectiva es extrema, no divulgada, específica de la cartera o modificable de inmediato.

- Falta código verificado, no cubre la implementación activa o depende de un contrato externo no verificado.

- La liquidez es escasa, está bajo un solo controlador o puede retirarse sin bloqueo o demora de gobierno significativos.

- Los simuladores discrepan, la ruta solo funciona en una interfaz controlada por el proyecto o faltan ventas independientes recientes.

Detente si la identidad es incierta, una venta no se explica, no pueden enumerarse privilegios o la posible pérdida supera el presupuesto. Comprar más no diagnostica nada. Más Gas puede favorecer la inclusión, pero no eludir restricciones; más deslizamiento acepta peor precio y puede ampliar la pérdida.

Una revisión limpia y una ida y vuelta exitosa solo prueban un instante. Reservas, listas de bloqueo, comisiones, dependencias y lógica actualizable pueden cambiar. Revisa antes de aumentar materialmente la exposición y asume que ninguna lista elimina el riesgo de contrato o liquidez.

<a id="misconceptions"></a>

## Errores comunes

- **«Código verificado significa seguro».** La verificación enlaza código y bytecode; no demuestra que la lógica sea benigna ni que los privilegios estén limitados.

- **«Renunciar a la propiedad impide cambiar reglas».** Otros roles, controladores o administradores del proxy pueden conservar autoridad.

- **«El escáner dice que se vende, así que la próxima venta funcionará».** Estado, remitente, ruta, bloque, liquidez e implementación pueden diferir.

- **«Una venta pequeña prueba que saldrá toda la posición».** Comisiones escalonadas, límites, impacto y reservas finitas pueden cambiar por completo el resultado.

<a id="related"></a>

## Temas relacionados

- [Riesgo de tokens con comisión de transferencia](/es/crypto/fee-on-transfer-token-risk/)
- [Cómo verificar la dirección del contrato](/es/crypto/token-contract-verification/)
- [Simulación de transacciones](/es/crypto/transaction-simulation/)
- [Rug pulls](/es/crypto/rug-pull/)
- [Lista de deslizamiento y rutas DEX](/es/crypto/dex-slippage-route-checklist/)

<a id="sources"></a>

## Fuentes

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulta: 2026-08-20)
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consulta: 2026-08-20)
- [Control de acceso](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (consulta: 2026-08-20)
- [Patrón de actualización mediante proxy](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin (consulta: 2026-08-20)

Source: https://wiki.fcontext.com/es/crypto/honeypot-token-detection/index.mdx
