Por que a túa carteira mostra unha transferencia que nunca enviaches: transaccións de valor cero e envelenamento de enderezos

Unha transacción saínte descoñecida non significa automaticamente que a túa carteira fose pirateada. Aprende que demostran realmente os rexistros de valor cero, os enderezos semellantes e os movementos reais de activos.

Que demostra esta entrada sobre a miña carteira?

Se o teu historial indica de súpeto que enviaches 0 USDT a un enderezo descoñecido, esa entrada non demostra por si soa que alguén accedese á túa chave privada. Un terceiro pode crear certos rexistros de transferencias de cero tokens nos que aparece o teu enderezo sen a túa sinatura nin permiso para gastar unha cantidade superior a cero. O rexistro pode existir na cadea de bloques aínda que nunca iniciaches a operación.

As preguntas útiles son máis concretas: Que activo é? Canto se moveu realmente? Quen enviou a transacción? Que autorizou calquera gasto real?

Un evento de tokens de cantidade cero non demostra que asinases ou gastases nada. Nun token auténtico, unha cantidade exactamente igual a cero significa que esa transferencia non moveu tokens.
Unha transferencia co nome dun token coñecido non identifica o activo. Un contrato alleo pode utilizar o mesmo nome e símbolo.
Un pagamento entrante diminuto pode ser auténtico e, ao mesmo tempo, introducir no teu historial un enderezo de remitente enganoso.
Un movemento saínte confirmado e inexplicado de activos auténticos require investigación. Non o descartes porque outro campo indique cero.

Esta guía abrangue Ethereum, BNB Smart Chain (BSC) e redes semellantes que utilizan contratos de tokens ao estilo de Ethereum. Os exemplos son rexistros inventados e simplificados deliberadamente, non capturas de pantalla nin achados dunha carteira concreta.

Primeiro, identifica que campo indica cero

A expresión transacción de valor cero emprégase para varias cousas distintas. Só unha destas indicacións significa que a cantidade de tokens é cero:

Cantidade de tokens: 0 USDC. No contrato auténtico de USDC, unha cantidade exactamente igual a cero significa que esa transferencia non move USDC.
Valor da transacción: 0 ETH. Non se achegou ETH á transacción principal. Aínda poden moverse tokens e executarse accións de contratos.
Valor estimado: $0.00. A interface mostra unha valoración en moeda fiduciaria. Isto non establece a cantidade de tokens.

Na BSC, o campo da moeda nativa utiliza normalmente BNB en lugar de ETH. Unha interacción cun contrato de valor nativo cero pode transferir tokens, cambiar permisos de gasto ou activar outras operacións. O valor nativo é distinto dos datos de entrada da transacción.

Unha cantidade positiva pequena pode arredondarse a $0.00. Un activo sen prezo fiable tamén pode ter unha valoración fiduciaria pouco útil. Mostra a cantidade de tokens con toda a precisión: mesmo unha cantidade indicada como 0.00 pode agochar unha cantidade positiva menor. A valoración cambiante dunha carteira non é un rexistro fiable das unidades que entran ou saen dunha conta.

Cero é unha cantidade de tokens permitida, polo que cero por si só non demostra un ataque. Os enderezos semellantes e os datos de pagamento copiados son pistas que cómpre investigar.

Por que os dous campos From poden ser diferentes

O historial dunha carteira pode combinar información de distintas capas:

A transacción: a instrución asinada enviada á rede. Nunha transacción convencional de Ethereum, o campo From principal identifica a conta asinante.
O evento do token: un rexistro emitido por un contrato durante a execución. Un evento Transfer ten os seus propios campos From, To e cantidade.
A fila do historial: a forma en que a carteira ou o explorador presenta esa información. Pode marcar un evento como OUT porque nel aparece o teu enderezo como remitente.

Eses dous campos From non son intercambiables. Que o teu enderezo apareza nun evento non equivale a unha sinatura da túa carteira. Un contrato malicioso pode introducir o teu enderezo nos datos dun evento, pero iso non fai que o seu rexistro proceda do contrato do token auténtico. Por iso, o contrato emisor é unha parte esencial da proba.

Do mesmo xeito, un hash identifica unha transacción, pero non demostra o teu consentimento. Unha transacción incluída e marcada como Success indica que a súa execución externa non se reverteu. Non é unha validación do token, do destinatario nin da finalidade.

Cinco exemplos comentados de historiais de transaccións

Exemplo 1: unha transferencia saínte de cero tokens que nunca asinaches

Entrada no historial: OUT · 0 USDC · Do teu enderezo a outro descoñecido e semellante.

From da transacción: unha conta allea enviou a transacción.
From do evento do token: o evento menciona o teu enderezo.
Contrato emisor do token: o contrato auténtico de USDC nesa rede.
Cantidade exacta de tokens: cero.

Que demostra: o contrato auténtico do token rexistrou unha transferencia de cero tokens na que figura o teu enderezo. Esa transferencia concreta non moveu USDC. Non demostra que a túa carteira asinase a transacción, que quen a chamou teña permiso para gastar unha cantidade positiva nin que che roubasen a chave.

Como ocorre: ERC-20, o estándar común de tokens, esixe que as transferencias de cantidade cero emitan eventos Transfer. Nas implementacións habituais, a función delegada transferFrom comproba se a cantidade solicitada supera o permiso concedido a quen fai a chamada. Cero non supera un permiso de cero. Sempre que se cumpran as demais regras do contrato, a chamada pode ter éxito sen unha aprobación anterior.

Isto non é unha garantía universal para todos os tokens. Cada contrato pode impoñer restricións adicionais.

Que comprobar despois: examina o resto da transacción. Unha fila de cero só describe esa fila; outra operación podería ter un efecto distinto. Se se trata dun rexistro illado de envelenamento sen gastos sospeitosos nin cambios de permisos, a resposta axeitada é evitar o enderezo introducido, non supoñer que cómpre substituír a carteira.

Exemplo 2: unha transacción falsa que mostra unha cantidade grande de tokens

Entrada no historial: OUT · 2,500 USDC · Do teu enderezo a outro descoñecido.

Símbolo de token mostrado: USDC.
Contrato emisor: un contrato alleo, non o USDC auténtico.
Cantidade indicada no evento: 2,500.
Movemento de USDC auténticos nesta transacción: ningún.

Que demostra: outro contrato emitiu un rexistro presentado coa etiqueta USDC. Non demostra que saísen da túa conta 2,500 USDC auténticos.

Unha transacción falsa nunha carteira pode conter datos reais da cadea de bloques cunha interpretación enganosa. Os atacantes poden copiar o nome e símbolo dun token e emitir eventos semellantes aos teus pagamentos anteriores, incluídas as cantidades. Os contratos non estándar tamén poden emitir rexistros de transferencias que non se corresponden con cambios nos seus propios saldos.

Que comprobar despois: identifica a rede e o contrato exacto que emitiu o evento. Compara ese enderezo coa información contractual do emisor obtida de maneira independente para esa rede. Un símbolo, logotipo ou etiqueta de verificación do código fonte coñecidos non abondan para demostrar a identidade do emisor.

Exemplo 3: un pagamento real diminuto desde un enderezo semellante

Entrada no historial: IN · 0.000001 USDC · Dun enderezo descoñecido ao teu.

Supoñamos que o contrato auténtico do token confirma a transferencia e que o teu saldo de tokens aumenta esa pequena cantidade. Neste caso chegaron tokens reais. Recibilos non esixiu que aprobases o remitente e non lle outorga permiso para gastar.

A trampa está no enderezo. Considera estes exemplos inventados, separados por espazos para que se vexan todos os caracteres. Os enderezos reais non conteñen espazos; os grupos centrais en letra grosa son diferentes:

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

Enderezo introducido: 0x7a2f aaaa bbbb cccc dddd eeee ffff 0000 1111 9c4d

Unha interface que só mostre o principio e o final podería presentar ambos como 0x7a2f...9c4d.

Que demostra: alguén enviouche unha cantidade pequena desde ese enderezo. Non demostra que o remitente sexa o teu destinatario habitual nin unha conta baixo o teu control. A coincidencia dos caracteres visibles non demostra a titularidade.

Que comprobar despois: obtén o destino previsto dun contacto verificado por separado ou da páxina fiable da conta do destinatario. Compara o enderezo completo. O envelenamento de enderezos pretende converter unha entrada introducida no historial no enderezo que escollas para un pagamento posterior. A perda pode producirse máis tarde, cando autorices unha transferencia perfectamente válida ao destino equivocado.

Exemplo 4: cero ETH, pero saen 2,500 tokens auténticos

Cabeceira da transacción: Value · 0 ETH.

Valor nativo asociado á chamada: 0 ETH.
Transferencia de tokens auténticos: 2,500 USDC desde o teu enderezo.
Cambio no saldo USDC provocado pola transacción: unha diminución de 2,500 USDC.
Estado da execución: Success.

Que demostra: neste exemplo saíron USDC auténticos. O cero describe o ETH asociado á chamada. Non describe a transferencia de USDC nin exclúe os custos de gas.

Que segue sen saberse: por que se fixo o pagamento e se era a túa intención. Podería corresponder a un intercambio, depósito, operación programada, pagamento a un enderezo incorrecto ou gasto non autorizado. Compárao coa acción que fixeches e co destino que pretendías antes de clasificalo.

Exemplo 5: saen tokens auténticos, pero outra conta enviou a transacción

Entrada no historial: OUT · 500 USDC auténticos · Un destino descoñecido.

Supoñamos que a transacción exitosa reduciu en 500 o teu saldo de USDC auténticos, pero que o seu campo From principal sinala outra persoa.

Que demostra: os tokens movéronse. Que o remitente da transacción sexa distinto non converte ese movemento en falso.

Alguén autorizado previamente para gastar pode usar un permiso de tokens sen pedirche unha nova sinatura para cada retirada. Algúns tokens admiten tamén sinaturas permit, que autorizan un límite mediante unha mensaxe asinada que pode enviar outra parte. As contas intelixentes e carteiras delegadas ofrecen máis formas de que outra persoa envíe unha operación autorizada.

Que comprobar despois: examina quen pode gastar, o permiso correspondente ou a autorización asinada e a operación da carteira. Se o cargo segue sen explicación, trátao como un incidente de seguridade. As probas poden apuntar a unha aprobación prexudicial, unha sinatura enganosa ou un control da conta comprometido; a fila por si soa non permite distinguilos.

Nunha transacción ordinaria asinada directamente, que o teu enderezo apareza no From principal é unha proba dunha sinatura válida para esa conta. Aínda así, non demostra que comprendeses a acción, que pretendeses enviar ao destinatario nin que a iniciase persoalmente. O From dun evento de token achega unha proba moito máis feble.

Que mediron realmente os 270 millóns de intentos de envelenamento

Unha análise de dous anos de actividade en Ethereum e BSC, desde o 1 de xullo de 2022 ata o 30 de xuño de 2024, identificou aproximadamente 270 millóns de rexistros de transferencias de envelenamento dirixidos a 17 millóns de enderezos.

Os rexistros dividíronse en tres categorías:

147.7 millóns de transferencias de valor cero.
118.4 millóns de transferencias de tokens falsificados.
4.0 millóns de transferencias diminutas.

Estes rexistros de transferencia estaban incluídos nuns 18.2 millóns de transaccións, porque os atacantes poden agrupar varios rexistros. Os enderezos obxectivo non equivalen a persoas, carteiras comprometidas nin vítimas que perderon cartos.

A análise identificou 6,633 transferencias exitosas de pagamento que sumaban polo menos $83.8 millóns. Algunhas vítimas pagaron máis dunha vez. A detección centrouse en determinadas stablecoins, polo que a estimación das perdas é un límite inferior dentro dese ámbito, non o total de todos os tokens ou cadeas.

A consecuencia práctica é que comprobar unicamente as cantidades cero deixa fóra unha parte importante do ataque. As entradas falsificadas poden imitar un pagamento significativo e unha transferencia entrante diminuta pode mover tokens reais mentres introduce un enderezo perigoso.

Como examinar a túa entrada concreta

Abre a transacción na rede correcta. Usa a opción de explorador da carteira ou un explorador coñecido como Etherscan ou BscScan. Comproba o estado da transacción. Ler os detalles públicos non require conectar unha carteira, aprobar tokens, asinar unha mensaxe nin introducir unha frase de recuperación.
Identifica o activo real. Distingue o ETH ou BNB nativo dun token que utiliza ese nome. Para os tokens, contrasta a rede exacta e o contrato emisor cunha referencia fiable do emisor.
Le a cantidade coa máxima precisión. Separa a cantidade de tokens do valor nativo da transacción e da estimación en moeda fiduciaria.
Separa o remitente da transacción do remitente do evento. Nunha conta intelixente, examina tamén a operación da carteira e os seus permisos. Que outra persoa pague o gas non demostra que os teus activos non se movesen.
Revisa a transacción completa. Observa todos os movementos de tokens, transferencias de moedas nativas e cambios de permisos relevantes. Se o explorador ofrece cambios de saldo por transacción, utilízaos para conciliar o resultado. Que o saldo de hoxe non cambiase é unha proba máis feble: depósitos posteriores ou transferencias compensatorias poden ocultar movementos anteriores.
Verifica o destino de maneira independente. Usa os datos de pagamento fiables do destinatario ou unha entrada da axenda que xa verificaches. Unha fila recente do historial é unha proba que examinar, non unha garantía do destino correcto.

Se o explorador non aclara o resultado, facilita ao equipo de asistencia oficial da carteira a rede e o hash público da transacción. Describe a acción que esperabas, se a había. Estes datos axudan a distinguir unha operación descoñecida pero intencionada dun gasto inexplicado sen revelar os segredos que controlan a túa carteira.

Que facer despois das comprobacións

Se só atopaches un rexistro illado de envelenamento

Oculta ou denuncia o spam se a túa carteira o permite e evita utilizar os seus enderezos. Ocultar unha fila modifica a interface; non borra o historial da cadea de bloques nin revoga permisos.

Unha transferencia de cero pode producirse cun permiso de gasto cero, polo que o rexistro por si só non é motivo para revogar todas as aprobacións ou mover todos os fondos. Pode que non exista ningún permiso de gasto asociado a ese rexistro que se poida eliminar. Nunca utilices a web anunciada por un token nin a ligazón de recuperación dun descoñecido para “limpar” a carteira.

Se atopaches un permiso de gasto sospeitoso

Utiliza a función fiable de xestión de aprobacións da túa carteira para revisar e revogar o permiso correspondente. Desconectar unha web da carteira non revoga as aprobacións de tokens existentes na cadea de bloques. Revogar soluciona ese permiso; non repara unha chave privada roubada.

Se se moveron activos auténticos sen a túa intención

Conserva o hash da transacción, a rede, o activo afectado e os enderezos relevantes. Revisa as sinaturas, aprobacións e operacións recentes da carteira a través das canles oficiais de asistencia.

Se hai probas de que se expuxo a túa frase de recuperación ou chave privada, crea unha carteira nova cunha frase de recuperación nova nun dispositivo fiable e segue un plan coidadoso para mover os activos restantes. Outra conta derivada da frase comprometida non resolve a exposición. Se os fondos desaparecen automaticamente, non sigas engadindo cartos para gas: un programa varredor podería levalos.

Se asinaches conscientemente un pagamento pero copiaches un destino envelenado, documenta esa diferenza. O pagamento pode estar correctamente asinado e executado e, con todo, chegar ao destinatario equivocado. Ese resultado non demostra por si só que che roubasen a chave privada.

Preguntas frecuentes sobre transaccións descoñecidas

Fíxome pagar o gas o atacante?

No escenario habitual de envelenamento, o atacante envía a transacción e paga a comisión da rede. O simple feito de mencionar o teu enderezo nun evento de token non carga nada na túa conta. Porén, as transaccións patrocinadas e as contas intelixentes fan que saber quen paga a comisión non baste para determinar se a operación foi inofensiva. Comproba os efectos reais.

E se a transacción fallou?

Unha transferencia de tokens revertida non completou esa transferencia, aínda que se poida cobrar gas. Se a carteira utiliza delegación de conta, compróbaa por separado: Ethereum pode conservar unha delegación mesmo cando falla unha execución posterior. Unha delegación descoñecida merece revisión.

Impediría unha carteira física o envelenamento de enderezos?

Ofrece outro lugar onde comprobar o destino antes de asinar. Non pode facer correcto un destino controlado por un atacante se ti o aprobas. Compara o enderezo completo na pantalla fiable de sinatura cos datos do destinatario verificados de maneira independente.

Podo impedir que descoñecidos engadan estas entradas?

En xeral, non podes impedir que terceiros envíen activos ou xeren rexistros aplicables que impliquen un enderezo público. Os filtros de carteiras e exploradores poden reducir o que ves. Garda destinatarios verificados e comproba o destino completo antes de pagar: ocultar só as entradas de valor cero non permite detectar todas as variantes con falsificacións ou transferencias diminutas.