
La majoria d’errors en un intercanvi de criptomonedes no comencen a la cadena de blocs, sinó abans: s’escull una xarxa incompatible, es copia una adreça sense verificar-la, s’ignora un Memo o es confon l’import estimat amb la quantitat final. La manera més segura d’avançar és tractar l’operació com una seqüència d’estats verificables. Si una comprovació no coincideix amb la tasca inicial, cal aturar-se abans d’enviar els fons.
Mapa d’estats de l’operació
- Estat 1: definir la tasca
- Condició de transició: saber quin actiu es lliurarà, quin es vol rebre i en quin moneder o servei ha d’arribar.
- Comprovació: escriure el recorregut complet, per exemple: «enviar l’actiu A des del moneder d’origen i rebre l’actiu B a l’adreça de destinació».
- Senyal d’èxit: l’actiu de sortida, l’actiu de recepció i el destinatari estan identificats sense ambigüitats.
- Si no coincideix, aturar-se: no crear una sol·licitud basant-se només en el símbol d’una moneda o en una adreça guardada anteriorment.
- Estat 2: reunir les dades d’origen i destinació
- Condició de transició: disposar del saldo, la xarxa de retirada, l’adreça de recepció i, quan es demani, el Memo o Tag.
- Comprovació: obtenir l’adreça directament del moneder o de la pàgina de dipòsit actual del destinatari, no d’un missatge antic.
- Senyal d’èxit: el destinatari mostra explícitament l’actiu i la xarxa acceptada.
- Si no coincideix, aturar-se: una adreça amb un format aparentment correcte no demostra per si sola que l’actiu o la xarxa siguin compatibles.
- Estat 3: comprovar la ruta d’intercanvi
- Condició de transició: la combinació d’actius, la xarxa d’enviament i la xarxa de recepció apareixen com a disponibles en crear la sol·licitud.
- Comprovació: revisar la denominació completa dels actius, les xarxes indicades, els imports mínim i màxim que pugui mostrar la interfície i les condicions de verificació aplicables.
- Senyal d’èxit: la ruta oferta coincideix exactament amb la tasca definida a l’estat 1.
- Si no coincideix, aturar-se: no substituir una xarxa per una altra només perquè sigui més barata, ni enviar un actiu embolcallat o emès per un contracte diferent sense confirmació explícita de compatibilitat.
- Estat 4: validar l’adreça, el Memo i els imports
- Condició de transició: l’adreça completa coincideix amb la proporcionada pel destinatari i tots els camps obligatoris estan emplenats.
- Comprovació: comparar diversos caràcters de l’inici, del centre i del final; confirmar l’import que s’enviarà, la comissió de xarxa i la quantitat estimada que es rebrà.
- Senyal d’èxit: la previsualització de l’operació conserva l’adreça, l’actiu, la xarxa i l’ordre de magnitud esperats.
- Si no coincideix, aturar-se: qualsevol canvi inesperat després d’enganxar l’adreça pot indicar un error de còpia, programari maliciós o una interfície fraudulenta.
- Estat 5: crear la sol·licitud i fer el pagament
- Condició de transició: totes les comprovacions anteriors són satisfactòries i s’han entès les condicions vigents de la sol·licitud.
- Comprovació: utilitzar exclusivament l’adreça de dipòsit generada per a aquesta operació i enviar l’actiu per la xarxa especificada.
- Senyal d’èxit: el moneder d’origen genera un identificador de transacció, també anomenat hash o TxID.
- Si no coincideix, aturar-se: no reutilitzar una adreça d’una operació anterior ni enviar un segon pagament per corregir el primer sense instruccions concretes del servei.
- Estat 6: esperar confirmacions i processament
- Condició de transició: la transacció és visible en un explorador de blocs adequat per a la xarxa utilitzada.
- Comprovació: revisar el TxID, l’adreça receptora, l’actiu o contracte del token, l’import i l’estat de confirmació.
- Senyal d’èxit: la xarxa ha inclòs la transacció i el servei la reconeix com a dipòsit vinculat a la sol·licitud.
- Si no coincideix, aturar-se: no considerar completat l’intercanvi només perquè el saldo hagi sortit del moneder d’origen.
- Estat 7: confirmar el resultat o activar la recuperació
- Condició de transició: l’actiu esperat apareix a l’adreça final i la transacció de sortida es pot verificar a la seva xarxa.
- Comprovació: contrastar l’actiu rebut, la xarxa, l’adreça i l’import real amb les dades de la sol·licitud.
- Senyal d’èxit: existeix un registre verificable de la transacció d’entrada i, si correspon, el moneder o la plataforma de destinació ja reflecteix el saldo.
- Si no coincideix, aturar-se: conservar la identificació de la sol·licitud i tots els TxID i passar a la diagnosi, sense repetir l’operació impulsivament.
Primer error: triar el símbol correcte però la xarxa equivocada
Un mateix actiu pot circular per infraestructures diferents. Per això, seleccionar «USDT», per exemple, no completa la decisió: també cal identificar la xarxa concreta que utilitzarà el moneder d’origen i la que admet la destinació. La compatibilitat s’ha de confirmar als dos extrems.
La confusió acostuma a sorgir quan dues xarxes comparteixen formats d’adreça semblants o quan el moneder ofereix diverses opcions de retirada. Que una aplicació permeti enganxar l’adreça no significa necessàriament que el destinatari pugui acreditar el dipòsit. A Ethereum, les sol·licituds de transacció poden incloure un identificador de cadena precisament per distingir xarxes; si aquest identificador no hi és, el moneder pot mantenir la xarxa que ja tenia seleccionada. [1]
La comprovació correcta no és «l’adreça sembla vàlida», sinó aquesta coincidència completa:
- actiu que surt del moneder;
- xarxa seleccionada per retirar-lo;
- actiu que accepta el receptor;
- xarxa de dipòsit indicada pel receptor;
- contracte del token, quan la interfície el mostri i sigui pertinent.
Si algun d’aquests elements no es pot verificar, el recorregut ja no correspon a la tasca inicial. No s’ha d’intentar resoldre la incertesa escollint la xarxa amb la comissió aparentment més baixa.
Segon error: confiar en l’adreça sense comprovar-ne l’origen
Les adreces són difícils de llegir i una substitució pot passar desapercebuda. Un atac de phishing pot copiar l’aspecte d’un lloc legítim o presentar instruccions que dirigeixin els fons cap a una adreça controlada per un tercer. Els noms i símbols dels tokens tampoc no són identificadors suficients: en xarxes amb contractes, un actiu fraudulent pot imitar-los, mentre que l’adreça del contracte continua sent diferent. [2]
Abans de confirmar, convé tornar a copiar l’adreça des de la destinació actual i comparar-la amb la que mostra el moneder a la pantalla final. Comprovar només els quatre primers i els quatre últims caràcters és millor que no fer cap revisió, però no cobreix totes les manipulacions. Cal mirar també una part central o utilitzar la funció de comparació que ofereixi el moneder.
Un codi QR redueix alguns errors de transcripció, però no certifica que la petició sigui autèntica. Les especificacions d’Ethereum adverteixen que modificar l’adreça receptora o l’import d’una petició pot redirigir una transacció irreversible; per això, la integritat de la font continua sent decisiva. [1]
La pantalla de signatura és l’últim punt de control. Si l’actiu, la xarxa, l’adreça o l’import canvien respecte del que s’havia preparat, cal rebutjar l’operació. Les transaccions d’Ethereum enviades a una adreça equivocada no es poden revertir des de la xarxa; en alguns casos, el receptor o un servei que controli l’adreça podria estudiar una recuperació, però no hi ha cap garantia. [3]
Tercer error: ometre el Memo o Tag
Algunes destinacions utilitzen una adreça compartida per a diversos clients i demanen un identificador addicional, habitualment denominat Memo, Tag, nota o referència. Si la pantalla de dipòsit mostra aquest camp com a obligatori, forma part de l’adreçament de l’operació encara que no sigui un component de l’adreça de cadena.
La regla pràctica és senzilla: si el destinatari proporciona una adreça i un Memo o Tag, tots dos s’han de copiar exactament als camps corresponents. No s’ha d’afegir un valor inventat, escriure’l en un camp de comentaris diferent ni ometre’l perquè el moneder el presenti com a opcional. El moneder pot considerar vàlida la transacció a escala tècnica, mentre que la plataforma receptora pot no saber a quin compte intern acreditar-la.
Si el camp requerit no existeix al moneder d’origen, el recorregut s’ha d’aturar. Cal confirmar amb el proveïdor del moneder o amb la destinació si aquell mètode d’enviament és compatible. Fer una transferència «de prova» sense l’identificador no resol el problema de classificació.
Quart error: confondre import enviat, comissió i import rebut
En un intercanvi poden intervenir conceptes diferents: la quantitat que surt del saldo, la comissió de la xarxa d’origen, les condicions econòmiques mostrades per l’intercanvi i l’import estimat o calculat per a la recepció. No s’ha de pressuposar que totes les interfícies descompten les comissions de la mateixa manera.
Abans del pagament, cal llegir la previsualització i respondre quatre preguntes:
- Quina quantitat exacta ha de rebre l’adreça de dipòsit?
- La comissió de retirada s’afegeix a l’import o se’n descompta?
- La cotització és fixa durant unes condicions determinades o pot variar amb el mercat?
- Quina quantitat final mostra la sol·licitud i en quin actiu està expressada?
La volatilitat pot fer que una estimació canviï mentre l’operació està pendent. També pot caducar una condició temporal indicada a la sol·licitud. Si el saldo disponible ja no permet enviar la quantitat requerida després d’incloure la comissió del moneder, no s’ha de reduir l’import arbitràriament: primer cal comprovar si la sol·licitud accepta aquesta variació.
Un altre senyal d’aturada és un canvi d’ordre de magnitud. Si s’esperava una fracció d’un actiu i la pantalla mostra centenars o milers d’unitats, pot haver-hi una confusió entre actius, decimals o camps. La documentació de les peticions de pagament d’Ethereum recomana que l’import es presenti de manera que la persona pugui verificar-ne fàcilment la magnitud abans d’autoritzar-lo. [1]
El punt sense retorn: què revisar abans d’enviar
Quan la ruta disponible coincideixi amb la tasca, es poden revisar les condicions actuals i crear una sol·licitud d’intercanvi amb l’actiu i la xarxa seleccionats. El servei admet actius com USDT, BTC, ETH, DAI, LTC, BNB, XMR i TRX, però això no implica que totes les parelles, xarxes o direccions estiguin disponibles en cada moment. La interfície de la sol·licitud és la que ha de confirmar la ruta concreta.
Just abans de prémer el botó d’enviament del moneder, la pantalla ha de permetre validar:
- la moneda o el token que s’està transferint;
- la xarxa activa al moneder;
- l’adreça de dipòsit generada per a l’operació;
- el Memo o Tag, si la destinació l’exigeix;
- la quantitat que arribarà a l’adreça després de la comissió de retirada;
- la identificació de la sol·licitud i les condicions que encara siguin vigents.
Aquesta és l’última oportunitat realista per corregir una dada sense haver de dependre d’un possible procés de recuperació. Els pagaments de Bitcoin, per exemple, no es poden anul·lar des de la xarxa; només el receptor podria efectuar una devolució posterior. [4]
Les condicions de comprovació d’identitat o d’origen dels fons poden variar segons la direcció de l’operació i els resultats de les verificacions de compliment normatiu. Cal consultar els requisits vigents abans de crear la sol·licitud. Si es demana una comprovació que no s’havia previst, la ruta queda en pausa: no s’ha d’enviar el pagament assumint que el requisit desapareixerà després.
Transacció retardada o errònia: diagnosi per branques
No existeix cap TxID
Si el moneder no mostra un hash, és possible que l’ordre encara no s’hagi transmès a la xarxa, que hagi fallat la signatura o que només estigui en una cua interna. Cal revisar l’historial del moneder i el saldo, però no repetir l’enviament fins a saber si la primera ordre pot acabar publicant-se. Dues ordres creades per impaciència poden produir dos pagaments diferents.
El TxID existeix, però l’explorador no el troba
Primer s’ha de confirmar que s’està consultant l’explorador corresponent a la xarxa realment utilitzada. Si la xarxa és correcta i la transacció continua sense aparèixer, pot ser que el moneder encara no l’hagi difós o que mostri un identificador intern. En aquesta fase, el suport del moneder d’origen és qui pot aclarir l’estat de l’enviament.
La transacció apareix com a pendent
Una operació pendent ja s’ha publicat, però encara no s’ha inclòs o finalitzat segons les regles de la xarxa. A Ethereum, una comissió insuficient respecte de les condicions de la xarxa pot mantenir una transacció encallada; el tractament possible depèn del moneder i de l’estat concret de l’operació. [3]
No s’ha de crear una altra transacció a cegues. Si el moneder ofereix funcions com accelerar o cancel·lar, cal llegir-ne les conseqüències: una cancel·lació acostuma a ser una nova transacció que competeix amb l’anterior, no una ordre garantida de reversió.
La xarxa mostra confirmació, però el servei no detecta el dipòsit
Cal comparar el registre de cadena amb la sol·licitud:
- adreça receptora exacta;
- xarxa utilitzada;
- actiu o contracte transferit;
- import rebut per l’adreça;
- Memo o Tag, quan sigui necessari;
- nombre de confirmacions o estat de finalització.
Un explorador permet seguir una operació mitjançant el hash i consultar dades com les adreces, el bloc i l’estat de confirmació. Per exemple, la documentació de TRONSCAN descriu el hash, el nombre de confirmacions i l’indicador de transacció confirmada entre els camps de seguiment. [5]
Si totes les dades coincideixen, s’han de conservar el TxID, la identificació de la sol·licitud i captures de les dades mostrades, i sol·licitar una revisió. Una transacció confirmada a la xarxa pot necessitar encara processament intern, però no s’ha de prometre un termini ni interpretar el retard com una pèrdua definitiva.
L’adreça, la xarxa, l’actiu o el Memo són incorrectes
Aquesta és una incidència de recuperació, no un simple retard. Cal deixar d’enviar fons i documentar què ha passat: xarxa d’origen, adreça receptora, actiu, quantitat, TxID i dada que no coincideix. Si una organització controla l’adreça receptora, pot estudiar si existeix una via tècnica de recuperació; això pot ser impossible, estar subjecte a comprovacions o dependre de sistemes que no admeten l’actiu enviat.
Ningú no pot garantir la devolució. Tampoc s’han de lliurar frases de recuperació, claus privades ni codis d’autenticació a una persona que prometi recuperar la transferència. El suport legítim pot necessitar dades públiques de l’operació, però no les credencials que permeten controlar el moneder.
Quan es pot considerar completat l’intercanvi
El recorregut acaba quan la transacció de sortida de l’intercanvi és verificable a la xarxa correcta, apunta a l’adreça prevista, correspon a l’actiu esperat i la destinació en reflecteix el saldo segons les seves regles. Un missatge de «processat» sense TxID, o un TxID sense coincidència d’adreça i actiu, no és una verificació suficient.
Encara poden quedar diferències entre el saldo visible i el saldo disponible, confirmacions addicionals exigides per la destinació o una revisió de compliment normatiu. Aquestes incerteses s’han de resoldre amb les dades de la sol·licitud i els registres de cadena, no repetint el pagament. La comprovació final és concreta: actiu correcte, xarxa correcta, adreça correcta i transacció confirmada o finalitzada d’acord amb els criteris de la destinació.
Els comentaris estan tancats.