Por qué tu billetera muestra una transferencia que nunca enviaste: transacciones de valor cero y envenenamiento de direcciones

Una transacción saliente desconocida no significa automáticamente que hayan hackeado tu billetera. Aprende qué demuestran realmente los registros de valor cero, las direcciones parecidas y los movimientos reales de activos.

¿Qué demuestra esta entrada sobre mi billetera?

Si tu historial indica de repente que enviaste 0 USDT a una dirección desconocida, esa entrada por sí sola no demuestra que alguien haya accedido a tu clave privada. Un tercero puede crear determinados registros de transferencias de cero tokens que mencionen tu dirección sin tu firma ni tu autorización para gastar una cantidad distinta de cero. El registro puede existir en la cadena de bloques aunque nunca hayas iniciado la operación.

Las preguntas útiles son más concretas: ¿Qué activo es? ¿Cuánto se movió realmente? ¿Quién envió la transacción? ¿Qué autorizó cualquier gasto real?

• Un evento de tokens de importe cero no demuestra que hayas firmado o gastado nada. Para un token auténtico, un importe exactamente igual a cero significa que esa transferencia concreta no movió tokens.
• Una transferencia con el nombre de un token conocido no identifica el activo. Un contrato sin relación puede utilizar el mismo nombre y símbolo.
• Un pago entrante diminuto puede ser auténtico y, a la vez, insertar una dirección de remitente engañosa en tu historial.
• Un movimiento saliente confirmado e inexplicado de activos auténticos requiere investigación. No lo descartes porque otro campo indique cero.

Esta guía abarca Ethereum, BNB Smart Chain (BSC) y redes similares que utilizan contratos de tokens al estilo de Ethereum. Los ejemplos son registros ficticios deliberadamente simplificados, no capturas de pantalla ni hallazgos sobre una billetera específica.

Primero, identifica qué campo indica cero

La expresión transacción de valor cero se utiliza para varias situaciones diferentes. Solo una de estas indicaciones significa que la cantidad de tokens es cero:

• Cantidad de tokens: 0 USDC. Para el contrato auténtico de USDC, una cantidad exactamente igual a cero significa que esa transferencia no mueve USDC.
• Valor de la transacción: 0 ETH. No se adjuntó ETH a la transacción principal. Aun así, pueden moverse tokens y ejecutarse acciones de contratos.
• Valor estimado: $0.00. La interfaz muestra una valoración en moneda fiduciaria. Esto no determina la cantidad de tokens.

En BSC, el campo de moneda nativa normalmente utiliza BNB en lugar de ETH. Una interacción con un contrato cuyo valor nativo sea cero puede transferir tokens, cambiar permisos de gasto o activar otras operaciones. El valor nativo es distinto de los datos de entrada de la transacción.

Una pequeña cantidad positiva puede redondearse a $0.00. Un activo sin un precio fiable también puede mostrar una valoración fiduciaria poco útil. Amplía la cantidad de tokens hasta su precisión completa; incluso una cantidad mostrada de 0.00 puede ocultar una cantidad positiva menor. Los cambios en la valoración de la cartera no son un registro fiable de las unidades que entran o salen de una cuenta.

El cero es una cantidad de tokens permitida, así que por sí solo no demuestra un ataque. Las direcciones parecidas y los datos de pago copiados son indicios que conviene investigar.

Por qué pueden diferir los dos campos «De»

El historial de una billetera puede combinar información de distintas capas:

1. La transacción: la instrucción firmada que se envía a la red. En una transacción convencional de Ethereum, el campo principal «De» identifica la cuenta firmante.
2. El evento del token: un registro emitido por un contrato durante la ejecución. Un evento Transfer tiene sus propios campos De, Para e importe.
3. La fila del historial: la presentación de esa información en la billetera o el explorador. Puede marcar un evento como OUT porque este indica tu dirección como remitente.

Esos dos campos «De» no son intercambiables. Que tu dirección aparezca dentro de un evento no equivale a una firma de tu billetera. Un contrato malicioso puede incluir tu dirección en los datos de un evento, pero eso no significa que su registro proceda del contrato del token auténtico. Por tanto, el contrato emisor es una parte esencial de las pruebas.

Del mismo modo, el hash de una transacción identifica la transacción, pero no demuestra tu consentimiento. Una transacción incluida con el estado Success indica que su ejecución externa no se revirtió. No constituye un aval del token, del destinatario ni de su propósito.

Cinco ejemplos comentados del historial de transacciones

Ejemplo 1: una transferencia saliente de cero tokens que nunca firmaste

Entrada del historial: OUT · 0 USDC · De tu dirección a una dirección desconocida muy parecida.

• De de la transacción: una cuenta sin relación envió la transacción.
• De del evento del token: el evento menciona tu dirección.
• Contrato emisor del token: el contrato auténtico de USDC en esta red.
• Cantidad exacta de tokens: cero.

Qué demuestra: el contrato auténtico del token registró una transferencia de cero tokens que menciona tu dirección. Esa transferencia concreta no movió USDC. No demuestra que tu billetera firmara la transacción, que quien la invocó tenga permiso para gastar una cantidad positiva ni que te hayan robado la clave.

Cómo ocurre: ERC-20, el estándar habitual de tokens, exige que las transferencias de importe cero emitan eventos Transfer. En las implementaciones comunes, la función de transferencia delegada, transferFrom, comprueba si la cantidad solicitada supera la autorización de quien realiza la llamada. Cero no supera una autorización de cero. Siempre que lo permitan las demás reglas del contrato, la llamada puede tener éxito sin una aprobación previa.

Esto no es una garantía universal para todos los tokens. Cada contrato puede imponer restricciones adicionales.

Qué comprobar después: examina el resto de la transacción. Una fila con cero solo describe esa fila; otra operación podría tener un efecto distinto. Si se trata de un registro de envenenamiento aislado sin gastos ni cambios de permisos sospechosos, la respuesta adecuada es evitar la dirección insertada, no suponer que debes sustituir la billetera.

Ejemplo 2: una transacción falsa que muestra una gran cantidad de tokens

Entrada del historial: OUT · 2,500 USDC · De tu dirección a una dirección desconocida.

• Símbolo del token mostrado: USDC.
• Contrato emisor: un contrato sin relación, no el USDC auténtico.
• Cantidad indicada por el evento: 2,500.
• Movimiento de USDC auténtico en esta transacción: ninguno.

Qué demuestra: otro contrato emitió un registro presentado con la etiqueta USDC. No demuestra que salieran 2,500 USDC auténticos de tu cuenta.

Una transacción falsa en una billetera puede ser un dato real de la cadena de bloques con una interpretación engañosa. Los atacantes pueden copiar el nombre y el símbolo de un token y emitir eventos que se asemejen a tus pagos anteriores, incluidos sus importes. Los contratos no estándar también pueden emitir registros de transferencias que no correspondan a cambios en sus propios saldos.

Qué comprobar después: identifica la red y el contrato exacto que emitió el evento. Compara esa dirección con la información del contrato del emisor obtenida de manera independiente para esa red. Un símbolo, un logotipo o una etiqueta de verificación del código fuente conocidos no bastan para acreditar la identidad del emisor.

Ejemplo 3: un pequeño pago real desde una dirección parecida

Entrada del historial: IN · 0.000001 USDC · De una dirección desconocida a tu dirección.

Supongamos que el contrato auténtico del token confirma la transferencia y que tu saldo aumenta en esa diminuta cantidad. En este caso llegaron tokens reales. Recibirlos no exigía que aprobaras al remitente ni le concede autoridad para gastar.

La trampa está en la dirección. Considera estos ejemplos inventados, agrupados con espacios para que se vea cada carácter. Las direcciones reales no contienen espacios; los grupos centrales en negrita son diferentes:

Destinatario verificado: 0x7a2f 1111 2222 3333 4444 5555 6666 7777 8888 9c4d

Dirección insertada: 0x7a2f aaaa bbbb cccc dddd eeee ffff 0000 1111 9c4d

Una interfaz que solo muestre el principio y el final podría presentar ambas como 0x7a2f...9c4d.

Qué demuestra: alguien te envió una pequeña cantidad desde esa dirección. No demuestra que el remitente sea tu destinatario habitual ni una cuenta bajo tu control. La coincidencia de los caracteres visibles no acredita la propiedad.

Qué comprobar después: recupera la dirección de destino prevista a través de un contacto verificado por separado o de la página de cuenta de confianza del destinatario. Compara la dirección completa. El envenenamiento de direcciones intenta convertir una entrada insertada en el historial en la dirección que eliges para un pago posterior. La pérdida puede producirse más tarde, cuando autorizas una transferencia perfectamente válida al destino equivocado.

Ejemplo 4: cero ETH, pero salen 2,500 tokens auténticos

Encabezado de la transacción: Valor · 0 ETH.

• Valor nativo adjunto a la llamada: 0 ETH.
• Transferencia de tokens auténticos: 2,500 USDC desde tu dirección.
• Cambio del saldo de USDC causado por esta transacción: una disminución de 2,500 USDC.
• Estado de ejecución: Success.

Qué demuestra: en este ejemplo salieron USDC auténticos. El cero describe los ETH adjuntos a la llamada. No describe la transferencia de USDC ni excluye los costes de gas.

Qué sigue sin saberse: por qué se hizo el pago y si lo querías realizar. Podría corresponder a un intercambio, depósito, operación programada, pago a la dirección equivocada o gasto no autorizado. Relaciónalo con la acción que realizaste y el destino previsto antes de clasificarlo.

Ejemplo 5: salen tokens auténticos, pero otra cuenta envió la transacción

Entrada del historial: OUT · 500 USDC auténticos · Destino desconocido.

Supongamos que la transacción realizada con éxito redujo tu saldo de USDC auténtico en 500, pero su campo principal «De» indica a otra persona.

Qué demuestra: los tokens se movieron. Que el remitente de la transacción sea distinto no convierte ese movimiento en falso.

Un tercero con autorización previa puede utilizar una asignación de tokens sin pedirte que firmes una nueva transacción para cada retirada. Algunos tokens también admiten firmas permit, que autorizan una asignación mediante un mensaje firmado que puede presentar otra parte. Las cuentas inteligentes y las billeteras delegadas añaden otras formas de que alguien presente una operación autorizada.

Qué comprobar después: examina a quien tiene permiso de gasto, la asignación o autorización firmada pertinente y la operación de la billetera. Si el débito sigue sin explicación, trátalo como un incidente de seguridad. Las pruebas pueden apuntar a una aprobación perjudicial, una firma engañosa o un control de cuenta comprometido; la fila por sí sola no permite distinguirlos.

En una transacción ordinaria firmada directamente, que tu dirección figure en el campo principal «De» es prueba de una firma válida para esa cuenta. Aun así, no demuestra que entendieras la acción, que pretendieras enviar al destinatario ni que la iniciaras personalmente. El campo «De» de un evento de token aporta muchas menos pruebas.

Qué midieron realmente los 270 millones de intentos de envenenamiento

Un análisis de dos años de actividad en Ethereum y BSC, desde el 1 de julio de 2022 hasta el 30 de junio de 2024, identificó aproximadamente 270 millones de registros de transferencias de envenenamiento dirigidos a 17 millones de direcciones.

Los registros se dividieron en tres categorías:

• 147.7 millones de transferencias de valor cero.
• 118.4 millones de transferencias de tokens falsificados.
• 4.0 millones de transferencias diminutas.

Estos eran registros de transferencias incluidos en unas 18.2 millones de transacciones, ya que los atacantes pueden agrupar varios registros. Las direcciones atacadas no equivalen a personas, billeteras comprometidas ni víctimas que hayan perdido dinero.

El análisis identificó 6,633 transferencias de pago exitosas por un total de al menos $83.8 millones. Algunas víctimas pagaron más de una vez. La detección se centró en determinadas monedas estables, por lo que la estimación de pérdidas es un límite inferior dentro de ese alcance, no el total de todos los tokens o cadenas.

La implicación práctica es que comprobar solo las cantidades cero pasa por alto una parte considerable del ataque. Las entradas falsificadas pueden imitar un pago significativo, y una transferencia entrante diminuta puede mover tokens reales mientras introduce una dirección peligrosa.

Cómo examinar tu entrada concreta

1. Abre la transacción en la red correcta. Usa la opción de explorador de tu billetera o un explorador conocido como Etherscan o BscScan. Comprueba el estado de la transacción. Leer detalles públicos no requiere conectar una billetera, aprobar tokens, firmar mensajes ni introducir una frase de recuperación.
2. Identifica el activo real. Distingue ETH o BNB nativos de un token que use ese nombre. Para los tokens, contrasta la red exacta y el contrato emisor con una referencia fiable del emisor.
3. Lee la cantidad con toda su precisión. Separa la cantidad de tokens del valor nativo de la transacción y de la estimación fiduciaria.
4. Distingue al remitente de la transacción del remitente del evento. Si se trata de una cuenta inteligente, examina también la operación y sus permisos. Que otra persona pague el gas no prueba que tus activos no se hayan movido.
5. Revisa toda la transacción. Examina todos los movimientos de tokens, las transferencias de monedas nativas y los cambios de permisos relevantes. Si el explorador muestra variaciones de saldo a nivel de transacción, úsalas para conciliar el resultado. Que el saldo actual no haya cambiado es una prueba más débil: depósitos posteriores o transferencias compensatorias pueden ocultar movimientos previos.
6. Verifica el destino de forma independiente. Utiliza los datos de pago de confianza del destinatario o una entrada en la libreta de direcciones que ya hubieras verificado. Una fila reciente del historial es una prueba para examinar, no una confirmación del destino correcto.

Si el explorador no aclara el resultado, proporciona al equipo oficial de soporte de tu billetera la red y el hash público de la transacción. Describe la acción que esperabas, si la había. Estos datos ayudan a distinguir una operación desconocida pero intencionada de un gasto inexplicable sin revelar los secretos que controlan tu billetera.

Qué hacer después de comprobarlo

Si solo encontraste un registro de envenenamiento aislado

Oculta o denuncia el spam si tu billetera lo permite, y evita utilizar sus direcciones. Ocultar una fila cambia la interfaz; no borra el historial de la cadena de bloques ni revoca permisos.

Una transferencia de cero puede producirse con una autorización de cero, por lo que ese registro por sí solo no justifica revocar todas las aprobaciones ni mover todos tus fondos. Puede que no exista ningún permiso de gasto relacionado con ese registro que haya que eliminar. Nunca utilices el sitio web anunciado por un token ni un enlace de recuperación enviado por un desconocido para «limpiar» tu billetera.

Si encontraste un permiso de gasto sospechoso

Usa la función de gestión de aprobaciones de confianza de tu billetera para revisar y revocar la autorización correspondiente. Desconectar un sitio web de la billetera no revoca sus aprobaciones de tokens existentes en la cadena. Una revocación resuelve ese permiso, pero no puede reparar el robo de una clave privada.

Si se movieron activos auténticos sin que lo quisieras

Conserva el hash de la transacción, la red, el activo afectado y las direcciones pertinentes. Revisa firmas, aprobaciones y operaciones recientes de la billetera mediante canales oficiales de asistencia.

Si hay pruebas de que tu frase de recuperación o clave privada ha quedado expuesta, crea una nueva billetera con una frase de recuperación nueva en un dispositivo de confianza y sigue un plan cuidadoso para mover los activos restantes. Otra cuenta derivada de la frase comprometida no elimina esa exposición. Si los fondos desaparecen automáticamente, no sigas añadiendo dinero para gas: un programa de barrido podría llevárselo.

Si firmaste conscientemente un pago, pero copiaste un destino envenenado, documenta esa diferencia. El pago pudo haberse firmado y ejecutado correctamente, pero enviado al destinatario equivocado. Ese resultado, por sí solo, no demuestra que te hayan robado la clave privada.

Preguntas frecuentes sobre transacciones desconocidas

¿El atacante me hizo pagar el gas?

En una situación habitual de envenenamiento, el atacante envía la transacción y paga la comisión de red. El mero hecho de mencionar tu dirección en un evento de token no carga un coste a tu cuenta. Sin embargo, las transacciones patrocinadas y las cuentas inteligentes significan que quien paga la comisión no basta para determinar si una operación fue inofensiva. Comprueba los efectos reales.

¿Y si la transacción falló?

Una transferencia de tokens revertida no completó esa transferencia, aunque puede cobrarse gas. Si la billetera utiliza delegación de cuenta, compruébala por separado: Ethereum puede conservar una delegación incluso si la ejecución posterior falla. Una delegación desconocida merece revisión.

¿Una billetera de hardware evitaría el envenenamiento de direcciones?

Ofrece otro lugar donde comprobar el destino antes de firmar. No puede convertir en correcta una dirección controlada por un atacante si la apruebas. Compara la dirección completa en la pantalla de firma de confianza con los datos del destinatario verificados de forma independiente.

¿Puedo impedir que desconocidos añadan estas entradas?

Por lo general, no puedes impedir que terceros envíen activos o generen registros aplicables que involucren una dirección pública. Los filtros de la billetera y del explorador pueden reducir lo que ves. Guarda destinatarios verificados y comprueba el destino completo antes de pagar; ocultar únicamente las entradas de valor cero no detecta todas las variantes de falsificación o transferencias diminutas.