Per què el teu moneder mostra una transferència que mai no has enviat: transaccions de valor zero i enverinament d'adreces

Una transacció sortint desconeguda no vol dir necessàriament que t'hagin piratejat el moneder. Descobreix què demostren realment els registres de valor zero, les adreces semblants i els moviments reals d'actius.

Què demostra aquesta entrada sobre el meu moneder?

Si de sobte l'historial indica que has enviat 0 USDT a una adreça desconeguda, aquesta entrada per si sola no demostra que ningú hagi accedit a la teva clau privada. Un tercer pot crear determinats registres de transferències de zero tokens on figuri la teva adreça sense la teva signatura ni permís per gastar una quantitat superior a zero. El registre pot existir a la cadena de blocs encara que no hagis iniciat mai la transacció.

Les preguntes útils són més concretes: De quin actiu es tracta? Quina quantitat s'ha mogut realment? Qui ha enviat la transacció? Què ha autoritzat qualsevol despesa real?

• Un esdeveniment de tokens amb quantitat zero no demostra que hagis signat ni gastat res. Per a un token autèntic, una quantitat exactament igual a zero vol dir que aquella transferència no ha mogut cap token.
• Una transferència amb un nom de token conegut no identifica l'actiu. Un contracte aliè pot fer servir el mateix nom i símbol.
• Un pagament entrant minúscul pot ser real i, alhora, introduir a l'historial una adreça de remitent enganyosa.
• Un moviment sortint confirmat i inexplicable d'actius autèntics requereix una investigació. No el descartis perquè un altre camp indiqui zero.

Aquesta guia tracta d'Ethereum, BNB Smart Chain (BSC) i xarxes semblants que fan servir contractes de tokens del tipus Ethereum. Els exemples són registres inventats i simplificats deliberadament, no captures de pantalla ni conclusions sobre un moneder concret.

Primer, identifica quin camp indica zero

L'expressió transacció de valor zero s'utilitza per a coses diferents. Només una d'aquestes indicacions diu que la quantitat de tokens és zero:

• Quantitat de tokens: 0 USDC. En el contracte autèntic d'USDC, una quantitat exactament nul·la vol dir que aquella transferència no mou USDC.
• Valor de la transacció: 0 ETH. No s'ha adjuntat ETH a la transacció principal. Encara es poden moure tokens i executar accions del contracte.
• Valor estimat: $0.00. La interfície mostra una valoració en moneda fiduciària. Això no determina la quantitat de tokens.

A BSC, el camp de la moneda nativa normalment indica BNB en lloc d'ETH. Una interacció amb un contracte amb valor natiu zero pot transferir tokens, modificar permisos de despesa o activar altres operacions. El valor natiu és independent de les dades d'entrada de la transacció.

Una quantitat positiva petita es pot arrodonir a $0.00. Un actiu sense un preu fiable també pot mostrar una valoració fiduciària poc útil. Desplega la quantitat de tokens amb tota la precisió: fins i tot una quantitat mostrada com a 0.00 pot amagar una quantitat positiva més petita. El canvi de valoració d'una cartera no és un registre fiable de les unitats que entren o surten d'un compte.

Zero és una quantitat permesa de tokens, de manera que zero, per si sol, no demostra cap atac. Les adreces semblants i les dades de pagament copiades són indicis que cal investigar.

Per què poden discrepar els dos camps From

L'historial d'un moneder pot combinar informació de capes diferents:

1. La transacció: la instrucció signada que s'envia a la xarxa. En una transacció Ethereum convencional, el camp From principal identifica el compte signant.
2. L'esdeveniment del token: un registre emès per un contracte durant l'execució. Un esdeveniment Transfer té els seus propis camps From, To i quantitat.
3. La fila de l'historial: la manera com el moneder o l'explorador presenta aquesta informació. Pot marcar un esdeveniment com a OUT perquè l'esdeveniment indica la teva adreça com a remitent.

Aquests dos camps From no són intercanviables. Que la teva adreça aparegui dins d'un esdeveniment no és una signatura del teu moneder. Un contracte maliciós pot incloure-hi la teva adreça, però això no fa que el seu registre provingui del contracte autèntic del token. Per tant, el contracte emissor és una part essencial de les proves.

De la mateixa manera, un hash de transacció identifica la transacció, però no demostra el teu consentiment. Que una transacció inclosa figuri com a Success indica que l'execució externa no s'ha revertit. No és cap aval del token, del destinatari ni de la finalitat.

Cinc exemples comentats d'historials de transaccions

Exemple 1: una transferència sortint de zero tokens que mai no has signat

Entrada de l'historial: OUT · 0 USDC · De la teva adreça a una adreça desconeguda molt semblant.

• From de la transacció: un compte aliè ha enviat la transacció.
• From de l'esdeveniment del token: l'esdeveniment indica la teva adreça.
• Contracte emissor del token: el contracte autèntic d'USDC d'aquesta xarxa.
• Quantitat exacta de tokens: zero.

Què demostra: el contracte autèntic del token ha registrat una transferència de zero tokens on figura la teva adreça. Aquella transferència no ha mogut USDC. No demostra que el teu moneder hagi signat la transacció, que qui l'ha invocat tingui permís per gastar una quantitat positiva ni que t'hagin robat la clau.

Com passa: ERC-20, l'estàndard habitual dels tokens, exigeix que les transferències de quantitat zero emetin esdeveniments Transfer. En implementacions habituals, la funció de transferència delegada transferFrom comprova si la quantitat sol·licitada supera el límit autoritzat de qui fa la crida. Zero no supera un límit de zero. Segons les altres regles del contracte, la crida pot tenir èxit sense cap autorització prèvia.

Això no és una garantia universal per a tots els tokens. Cada contracte pot imposar restriccions addicionals.

Què cal comprovar després: examina la resta de la transacció. Una fila amb zero només descriu aquella fila; una altra operació pot tenir un efecte diferent. Si és un registre aïllat d'enverinament sense despeses sospitoses ni canvis de permisos, el més adequat és evitar l'adreça plantada, no donar per fet que cal substituir el moneder.

Exemple 2: una transacció falsa que mostra una gran quantitat de tokens

Entrada de l'historial: OUT · 2,500 USDC · De la teva adreça a una adreça desconeguda.

• Símbol del token mostrat: USDC.
• Contracte emissor: un contracte aliè, no el d'USDC autèntic.
• Quantitat indicada a l'esdeveniment: 2,500.
• Moviment d'USDC autèntic en aquesta transacció: cap.

Què demostra: un altre contracte ha emès un registre presentat amb l'etiqueta USDC. No demostra que hagin sortit 2,500 USDC autèntics del teu compte.

Una transacció falsa en un moneder pot consistir en dades reals de la cadena de blocs interpretades de manera enganyosa. Els atacants poden copiar el nom i el símbol d'un token i emetre esdeveniments semblants als teus pagaments anteriors, incloses les quantitats. Els contractes no estàndard també poden emetre registres de transferència que no corresponen a canvis dels seus propis saldos.

Què cal comprovar després: identifica la xarxa i el contracte exacte que ha emès l'esdeveniment. Compara l'adreça amb la informació del contracte per a aquella xarxa obtinguda independentment de l'emissor. Un símbol, un logotip o una etiqueta de verificació del codi font coneguts no són suficients per establir la identitat de l'emissor.

Exemple 3: un pagament real minúscul des d'una adreça semblant

Entrada de l'historial: IN · 0.000001 USDC · D'una adreça desconeguda a la teva.

Suposem que el contracte autèntic confirma la transferència i que el teu saldo de tokens augmenta en aquella petita quantitat. En aquest cas han arribat tokens reals. Rebre'ls no requeria que autoritzessis el remitent, ni li concedeix permís per gastar.

El parany és l'adreça. Considera aquests exemples inventats, separats amb espais perquè es vegi cada caràcter. Les adreces reals no tenen espais; els grups centrals en negreta són diferents:

Destinatari verificat: 0x7a2f 1111 2222 3333 4444 5555 6666 7777 8888 9c4d

Adreça plantada: 0x7a2f aaaa bbbb cccc dddd eeee ffff 0000 1111 9c4d

Una interfície que només mostri l'inici i el final podria presentar totes dues com a 0x7a2f...9c4d.

Què demostra: algú t'ha enviat una quantitat petita des d'aquella adreça. No demostra que el remitent sigui el teu destinatari habitual ni un compte que controles. Els caràcters visibles coincidents no acrediten la titularitat.

Què cal comprovar després: recupera l'adreça de destinació prevista d'un contacte verificat per separat o de la pàgina de compte fiable del destinatari. Compara l'adreça sencera. L'enverinament d'adreces intenta convertir una entrada plantada a l'historial en l'adreça que tries per a un pagament posterior. La pèrdua pot arribar més tard, quan autoritzis una transferència perfectament vàlida al destinatari equivocat.

Exemple 4: zero ETH, però surten 2,500 tokens autèntics

Capçalera de la transacció: Value · 0 ETH.

• Valor natiu adjunt a la crida: 0 ETH.
• Transferència de tokens autèntics: 2,500 USDC des de la teva adreça.
• Canvi de saldo d'USDC causat per aquesta transacció: una disminució de 2,500 USDC.
• Estat d'execució: Success.

Què demostra: en aquest exemple han sortit USDC autèntics. El zero descriu l'ETH adjunt a la crida. No descriu la transferència d'USDC ni exclou els costos de gas.

Què continua sense saber-se: per què s'ha produït el pagament i si era la teva intenció. Pot correspondre a un intercanvi, un dipòsit, una operació programada, un pagament a l'adreça equivocada o una despesa no autoritzada. Contrasta'l amb l'acció que vas fer i la destinació prevista abans de classificar-lo.

Exemple 5: surten tokens autèntics, però un altre compte ha enviat la transacció

Entrada de l'historial: OUT · 500 USDC autèntics · Una destinació desconeguda.

Suposem que la transacció executada correctament ha reduït en 500 el teu saldo d'USDC autèntics, tot i que al camp From principal hi consta una altra persona.

Què demostra: els tokens s'han mogut. Que la transacció tingui un remitent diferent no fa que el moviment sigui fals.

Un operador autoritzat anteriorment pot utilitzar un límit de despesa de tokens sense demanar-te que signis una transacció nova per a cada retirada. Alguns tokens també admeten signatures permit, que autoritzen un límit mitjançant un missatge signat que una altra part pot enviar. Els comptes intel·ligents i els moneders delegats ofereixen altres maneres que algú altre enviï una operació autoritzada.

Què cal comprovar després: examina l'operador, el límit pertinent o el permís signat i l'operació del moneder. Si el dèbit continua sense explicació, tracta'l com un incident de seguretat. Les proves poden apuntar a una autorització perjudicial, una signatura obtinguda amb engany o el control compromès del compte; la fila per si sola no permet distingir-los.

En una transacció ordinària signada directament, la teva adreça al camp From principal és prova d'una signatura vàlida per a aquell compte. Això, però, no demostra que entenguessis l'acció, que volguessis enviar els fons a aquell destinatari o que iniciessis personalment l'operació. El camp From d'un esdeveniment de token aporta moltes menys proves.

Què mesuraven realment els 270 milions d'intents d'enverinament

Una anàlisi de dos anys d'activitat a Ethereum i BSC, de l'1 de juliol de 2022 al 30 de juny de 2024, va identificar aproximadament 270 milions de registres de transferències d'enverinament dirigides a 17 milions d'adreces.

Els registres es dividien en tres categories:

• 147.7 milions de transferències de valor zero.
• 118.4 milions de transferències de tokens falsificats.
• 4.0 milions de transferències minúscules.

Aquests registres corresponien a unes 18.2 milions de transaccions, perquè els atacants poden agrupar diversos registres. Les adreces atacades no equivalen a persones, moneders compromesos ni víctimes que han perdut diners.

L'anàlisi va identificar 6,633 transferències d'èxit a favor dels atacants per un total d'almenys $83.8 milions. Algunes víctimes van pagar més d'una vegada. La detecció se centrava en determinades monedes estables, de manera que l'estimació de pèrdues és un límit inferior dins d'aquell abast, no un total per a tots els tokens i cadenes.

La conseqüència pràctica és que comprovar només les quantitats zero deixa escapar una part important de l'atac. Les entrades falsificades poden imitar un pagament considerable i una transferència entrant minúscula pot moure tokens reals mentre introdueix una adreça perillosa.

Com examinar una entrada concreta

1. Obre la transacció a la xarxa correcta. Fes servir l'opció d'explorador del moneder o un explorador conegut com Etherscan o BscScan. Comprova'n l'estat. Consultar detalls públics no requereix connectar el moneder, autoritzar tokens, signar missatges ni introduir la frase de recuperació.
2. Identifica l'actiu real. Distingeix l'ETH o BNB natiu d'un token que faci servir aquell nom. Per als tokens, compara la xarxa exacta i el contracte emissor amb una referència fiable de l'emissor.
3. Llegeix la quantitat amb tota la precisió. Separa la quantitat de tokens del valor natiu de la transacció i de l'estimació en moneda fiduciària.
4. Separa el remitent de la transacció del de l'esdeveniment. Si es tracta d'un compte intel·ligent, examina també l'operació del moneder i els seus permisos. Que algú altre pagui el gas no demostra que no s'hagin pogut moure els teus actius.
5. Revisa tota la transacció. Examina tots els moviments de tokens, les transferències de moneda nativa i els canvis de permisos pertinents. Si l'explorador mostra els canvis de saldo per transacció, utilitza'ls per quadrar el resultat. Un saldo actual inalterat és una prova més feble: ingressos posteriors o transferències compensatòries poden ocultar moviments anteriors.
6. Verifica la destinació independentment. Fes servir les dades de pagament fiables del destinatari o una entrada de l'agenda d'adreces verificada prèviament. Una fila recent de l'historial és una prova per examinar, no una confirmació de la destinació correcta.

Si l'explorador no deixa clar el resultat, facilita a l'equip de suport oficial del proveïdor del moneder la xarxa i el hash públic de la transacció. Descriu l'acció que esperaves, si n'hi havia. Aquestes dades ajuden a diferenciar una operació desconeguda però intencionada d'una despesa inexplicable sense revelar els secrets que controlen el moneder.

Què cal fer després de la comprovació

Si només has trobat un registre aïllat d'enverinament

Amaga el correu brossa o denuncia'l si el moneder ho permet, i evita utilitzar-ne les adreces. Amagar una fila canvia la interfície; no esborra l'historial de la cadena de blocs ni revoca permisos.

Una transferència zero pot passar amb un límit autoritzat de zero; per tant, el registre per si sol no justifica revocar totes les autoritzacions ni moure tots els fons. Pot ser que no hi hagi cap permís de despesa associat al registre per revocar. No utilitzis mai el lloc web anunciat per un token ni un enllaç de recuperació d'un desconegut per «netejar» el moneder.

Si has trobat un permís de despesa sospitós

Fes servir el mecanisme fiable de gestió d'autoritzacions del moneder per revisar i revocar el límit corresponent. Desconnectar un lloc web del moneder no revoca les autoritzacions de tokens ja existents a la cadena. La revocació resol aquell permís; no repara una clau privada robada.

Si s'han mogut actius autèntics sense la teva intenció

Conserva el hash de la transacció, la xarxa, l'actiu afectat i les adreces pertinents. Revisa les signatures, autoritzacions i operacions recents del moneder a través dels canals de suport oficials.

Si hi ha indicis que la frase de recuperació o la clau privada ha quedat exposada, crea un moneder nou amb una frase de recuperació nova en un dispositiu fiable i planifica amb cura el trasllat dels actius restants. Un altre compte derivat de la frase compromesa no soluciona l'exposició. Si els fons desapareixen automàticament, no hi continuïs afegint diners per al gas: un programa de buidatge els podria capturar.

Si vas signar conscientment un pagament però vas copiar una adreça enverinada, documenta aquesta diferència. Pot ser que el pagament s'hagi signat i executat correctament però hagi arribat al destinatari equivocat. Això per si sol no demostra que t'hagin robat la clau privada.

Preguntes freqüents sobre transaccions desconegudes

L'atacant m'ha fet pagar el gas?

En l'escenari habitual d'enverinament, l'atacant envia la transacció i paga la comissió de la xarxa. Que la teva adreça aparegui en un esdeveniment de token no carrega res al teu compte. Ara bé, les transaccions patrocinades i els comptes intel·ligents fan que el pagador de la comissió no sigui suficient per determinar si una operació era inofensiva. Comprova'n els efectes reals.

Què passa si la transacció ha fallat?

Una transferència de tokens revertida no ha completat aquella transferència, tot i que el gas es pot cobrar igualment. Si el moneder fa servir delegació de comptes, comprova-la per separat: Ethereum pot conservar una delegació encara que una execució posterior falli. Una delegació desconeguda mereix una revisió.

Un moneder físic evitaria l'enverinament d'adreces?

Proporciona un altre lloc on comprovar la destinació abans de signar. No pot fer correcta una destinació controlada per un atacant si tu l'autoritzes. Compara l'adreça completa a la pantalla de signatura fiable amb les dades del destinatari verificades de manera independent.

Puc impedir que desconeguts afegeixin aquestes entrades?

En general, no pots impedir que tercers enviïn actius o generin registres aplicables que impliquin una adreça pública. Els filtres dels moneders i exploradors poden reduir el que veus. Desa els destinataris verificats i comprova l'adreça completa abans de pagar; amagar només les entrades de valor zero no detecta totes les variants de tokens falsificats o transferències minúscules.