Validatore di indirizzi crypto

Cosa verifica questo strumento, e cosa non può verificare

Dietro "questo indirizzo è valido" si nascondono due domande diverse. La prima è se la stringa è ben formata: lunghezza corretta, alfabeto corretto, checksum integro. Questa domanda ha una risposta definitiva, e questa pagina risponde nel tuo browser senza inviare l'indirizzo da nessuna parte. La seconda è se l'indirizzo esiste, detiene un saldo, o appartiene alla persona che te lo ha fornito. Nessun controllo offline può rispondere a questo, e qualsiasi strumento che affermi il contrario sta leggendo una blockchain, non la stringa.

La distinzione conta perché le due modalità di errore non si somigliano affatto. Un indirizzo malformato viene rilevato qui e da ogni wallet, quindi un errore di battitura in un indirizzo TRON è un fastidio, non una perdita. Un indirizzo ben formato che appartiene alla persona sbagliata è invisibile a qualsiasi controllo mai scritto.

TRON: Base58Check, verificato fino al checksum

Un indirizzo TRON è di 34 caratteri e inizia con T. Dietro quella stringa ci sono 25 byte: un byte di versione, 20 byte di indirizzo e un checksum di 4 byte. Il byte di versione è 0x41 su mainnet, ed è la ragione per cui ogni indirizzo si presenta con una T iniziale una volta che i 25 byte sono codificati in Base58.

Il checksum è costituito dai primi quattro byte di SHA-256(SHA-256(payload)), dove il payload è il byte di versione più i 20 byte di indirizzo. Questa pagina calcola davvero quell'hash, usando la Web Crypto API del browser, e lo confronta con i quattro byte contenuti nell'indirizzo. Un singolo carattere alterato produce un payload diverso, un hash diverso, e una discrepanza. Questo è l'intero meccanismo, ed è il motivo per cui un indirizzo TRON digitato male viene respinto invece di essere accettato nel vuoto.

Base58 esclude anche di proposito quattro caratteri dal proprio alfabeto: zero, O maiuscola, I maiuscola e l minuscola. Sono le coppie che le persone confondono leggendo un indirizzo ad alta voce o copiandolo a mano, ed escluderle significa che quelle confusioni non possono produrre un diverso indirizzo valido. Se il controllo segnala un carattere fuori dall'alfabeto, di solito il colpevole è uno di questi quattro.

Una cosa che il formato non ti dice: se l'indirizzo è un wallet o un contratto token. Entrambi usano la stessa forma con prefisso T su TRON. Il contratto di USDT, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, è un indirizzo valido secondo ogni controllo di questa pagina, e inviarvi un deposito resta comunque un errore. La pagina sull'indirizzo TRC20 approfondisce questa distinzione e la notazione esadecimale.

Ethereum e BSC: un formato, due chain

Un indirizzo EVM è 0x seguito da 40 caratteri esadecimali, 42 caratteri in totale. Ethereum, BNB Smart Chain, Polygon e Arbitrum lo usano tutti, perché condividono lo stesso livello di esecuzione e la stessa derivazione delle chiavi. Questo ha una conseguenza da dire chiaramente: non esiste un modo per distinguere a colpo d'occhio un indirizzo ERC-20 da uno BEP-20. La stringa è identica. Quello che cambia è la rete a cui trasmetti la transazione, e i saldi che esistono su ciascuna chain.

È qui che nascono la maggior parte delle perdite cross-chain. Un indirizzo perfettamente valido su Ethereum è altrettanto valido su BSC, quindi un wallet invierà tranquillamente token BEP-20 a un indirizzo che il destinatario monitora solo su Ethereum. I fondi non sono spariti, si trovano sull'altra chain, ma recuperarli richiede la chiave privata e un wallet configurato per quella rete. La pagina sull'indirizzo ERC20 e la pagina sull'indirizzo BEP20 approfondiscono il lato pratico della cosa, incluso come il BEP-20 differisca dal più vecchio formato BEP-2, che inizia con bnb1 e non è intercambiabile con nulla di quanto visto qui.

EIP-55: il checksum nascosto nella capitalizzazione

L'esadecimale non distingue maiuscole e minuscole, quindi 0xab… e 0xAB… indicano lo stesso account. EIP-55 mette a frutto questa capacità in eccesso: esegue l'hash dell'indirizzo in minuscolo con Keccak-256, e lascia che ogni nibble dell'hash decida se la corrispondente lettera esadecimale va scritta maiuscola o minuscola. Il risultato assomiglia a un normale indirizzo a maiuscole miste e trasporta circa quattro bit di rilevamento errori per lettera.

Quindi un indirizzo EVM a maiuscole miste sta facendo un'affermazione, mentre uno tutto minuscolo o tutto maiuscolo no. Entrambi sono input legali per ogni wallet e ogni nodo. Solo quello a maiuscole miste può essere verificato.

Questa pagina segnala quale dei due hai incollato, e si ferma lì. Verificare il checksum EIP-55 richiede un'implementazione di Keccak-256, e la Web Crypto API del browser non offre Keccak — offre SHA-256, che è quello che usa il controllo TRON sopra. Piuttosto che distribuire una funzione hash scritta a mano per un controllo rilevante ai fini della sicurezza, lo strumento ti dice cosa non ha verificato. Se il tuo indirizzo proviene dall'interfaccia di un wallet, quasi certamente porta già un checksum corretto; se proviene da un database o da un file di log, vale la pena eseguire una verifica EIP-55 completa nel tuo stesso codice, dove una libreria collaudata è a un import di distanza.

Da dove arrivano gli indirizzi in un'integrazione

Validare un indirizzo incollato è l'ultima linea di difesa. Quella precedente è non incollare affatto indirizzi. In un flusso di pagamento o payout, gli indirizzi di deposito vengono generati per ogni cliente e monitorati in modo programmatico, così nessun essere umano ne ridigita mai uno e la questione del formato non si pone.

Questo è il compito della API TRON e degli endpoint equivalenti per Ethereum e BSC: creare un indirizzo, registrare un webhook per esso, accreditare il deposito quando arriva la notifica. Gli indirizzi restano non-custodial, e la prova gratuita dura sette giorni senza carta di credito e senza KYC. Due dettagli operativi vale la pena conoscere prima di costruirci sopra: i webhook non hanno retry automatico, quindi una consegna fallita si recupera con POST /<chain>/webhooks/notifications/failed invece di attendere una nuova consegna, e Solana non ha alcun supporto per i webhook.

Gli altri calcolatori di questo sito sono elencati nella panoramica degli strumenti.

Domande frequenti

L'indirizzo lascia il mio browser?

No. Sia la decodifica Base58 sia l'hashing SHA-256 girano localmente, tramite la Web Crypto API del browser. Non c'è alcuna richiesta a un server, il che significa anche che lo strumento funziona con la rete disconnessa.

Cosa viene verificato esattamente per un indirizzo TRON?

Quattro cose: che la stringa sia lunga 34 caratteri, che ogni carattere sia nell'alfabeto Base58, che si decodifichi in 25 byte con byte di versione 0x41, e che i quattro byte finali corrispondano ai primi quattro byte di SHA-256(SHA-256(payload)). Il checksum viene calcolato, non presunto.

Si può distinguere un indirizzo ERC-20 da un indirizzo BEP-20?

No, e non può farlo nient'altro. I due standard usano lo stesso identico formato 0x più 40 caratteri esadecimali. Uno strumento che afferma di distinguerli sta indovinando oppure sta interrogando una blockchain per i saldi, il che è una domanda diversa dalla validità dell'indirizzo.

Perché il checksum EIP-55 non viene verificato?

Richiede Keccak-256, che la crittografia integrata del browser non fornisce, e questa pagina non include un'implementazione di hash propria per un controllo su cui le persone farebbero affidamento. Ciò che la pagina segnala è se l'indirizzo è scritto in maiuscolo/minuscolo misto, il che significa che porta un checksum EIP-55, oppure in un unico case, il che significa che non ne porta nessuno.

Un indirizzo valido significa che i fondi arriveranno?

No. La validità è una proprietà della stringa. Se l'indirizzo è monitorato, se si trova sulla chain da cui stai inviando e se appartiene al destinatario previsto sono tutte domande separate che nessun controllo offline può risolvere.

Perché Base58 esclude alcuni caratteri?

Zero, O maiuscola, I maiuscola e l minuscola sono esclusi perché facilmente confondibili tra loro. Escluderli fa sì che una lettura ambigua non possa produrre in silenzio un indirizzo diverso ma comunque valido.

Qual è la forma hex di un indirizzo TRON?

Gli stessi 21 byte di payload scritti come hex: 41 seguito da 40 caratteri esadecimali. La TVM usa quella forma internamente, i wallet mostrano la forma Base58Check. La forma hex non porta alcun checksum, quindi non c'è nulla da verificare al suo interno.

Un indirizzo di contratto è un indirizzo valido?

Sì, per ogni controllo di formato. Su TRON e sulle chain EVM, gli indirizzi di contratto e gli indirizzi wallet sono indistinguibili per forma. Inviare un deposito a un contratto di token supera la validazione e comunque perde i fondi, motivo per cui la validazione dell'indirizzo è un controllo di formato e non un controllo di sicurezza.