Verdetto editoriale
Fascicolo giuridico · Fonti pubbliche esaminate
Trust Wallet
Wallet self-custody multichain, browser extension e servizi integrati
Analisi di SlateChain Team editoriale · revisione fonti di SlateChain Team di revisione
Punti di forza
- Modello self-custody e recovery documentati
- Copertura multichain
- Wallet Core Apache pubblico
Limiti da considerare
- Perdita del seed potenzialmente irreversibile
- Incidente estensione 2.68
- Fee di rete e partner restano
PERIMETRO DELLA DECISIONE
Distributore, versione, controller privacy e servizi terzi vanno distinti.
Recovery
Seed e backup cifrato
Licenza
Wallet Core contro app completa
Controller privacy
Dapps Platform Bahrain W.L.L.
Release security
Estensione e aggiornamenti
Analisi
Conclusioni collegate alle fonti disponibili.
Ogni richiamo numerato apre il documento utilizzato per il passaggio specifico.
Recovery
Trust Wallet documenta frase di 12 parole e backup cifrato opzionale. La responsabilità resta dell’utente e nessun supporto deve chiedere il seed.
Fonti: [2] Trust Wallet — ciclo del seed[4] Trust Wallet — FAQ
Copertura
Il marketing prodotto e Wallet Core descrivono layer e numeri differenti; non sono intercambiabili.
Fonti: [3] Trust Wallet Core repository[4] Trust Wallet — FAQ
Costi
L’assenza di fee wallet aggiuntiva non elimina network fee, prezzo partner, bridge e slippage.
Fonti: [4] Trust Wallet — FAQ
Privacy
La privacy notice identifica Dapps Platform Bahrain W.L.L. come controller; self-custody non elimina ogni flusso dati.
Incidente 2.68
Trust Wallet ha riferito una release malevola: l’update luglio 2026 indicava 2.520 indirizzi e circa 8,5 milioni USD mentre rimborso e indagine proseguivano.
Dossier decisionale approfondito
Dal soggetto giuridico all’uscita: dieci assi che non possono essere compressi in una stella.
Trust Wallet è una scelta pratica per self-custody multichain quando l’utente sa proteggere il seed, verificare la release e leggere le autorizzazioni. L’incidente dell’estensione 2.68 rende la provenienza del software un criterio centrale, senza trasformare un evento scoped in un’accusa indistinta verso ogni versione.
Quando il profilo può funzionare
- Utenti multichain con piano recovery offline.
- Persone che verificano store, versione e firma della release.
- Utenti che separano app, extension, Wallet Core e provider integrati.
- Chi misura costi onchain e revoca approval.
Quando cercare un’alternativa
- Chi affida il seed al supporto o a screenshot non protetti.
- Chi considera Wallet Core prova dell’intera app distribuita.
- Chi usa dapp senza verificare rete, spender e importo.
- Chi presume che assenza di fee wallet significhi costo totale zero.
| Asse | Riscontro | Conseguenza per il lettore | Stato | Prossima prova |
|---|---|---|---|---|
| prodottoApp, extension e Wallet Core | Le superfici condividono componenti ma non sono equivalenti. | Il perimetro deve apparire in ogni conclusione. | Documentato | Collegare versione store, repository e funzioni attive. |
| chiaviSeed e controllo | La frase di recovery controlla gli account self-custody. | La perdita può essere irreversibile e il supporto non deve richiederla. | Documentato | Provare recovery con wallet vuoto e conservazione offline. |
| backupBackup opzionale | Un backup cifrato sposta parte del rischio su credenziali e cloud. | Comodità e dipendenza devono essere scelte consapevolmente. | Parzialmente documentato | Testare separatamente seed offline e backup opzionale. |
| controllerController privacy | La notice identifica Dapps Platform Bahrain W.L.L. nel perimetro descritto. | Self-custody non elimina responsabilità sul trattamento dati. | Documentato | Mappare ruolo e provider per app e regione. |
| releaseProvenienza della release | Wallet Core pubblico non prova l’intera build distribuita. | Store, firma e catena di rilascio sono controlli autonomi. | Parzialmente documentato | Verificare versione, publisher e remediation corrente. |
| incidenteEstensione 2.68 | Il provider ha documentato una release malevola e aggiornamenti sul rimedio. | La lezione riguarda distribution security senza estendere lo scope a ogni prodotto. | Documentato | Riesaminare numeri, scope e stato del rimborso alla data di pubblicazione. |
| firmaApproval e dapp | L’utente può concedere poteri irreversibili a contratti. | La varietà di chain aumenta il bisogno di contesto chiaro. | Documentato | Testare approval limitata, revoca e chain switch. |
| costoSwap, bridge e gas | L’assenza di una fee wallet non elimina costi di rete e partner. | Il risultato va espresso come output netto. | Documentato | Confrontare route e importo finale nella stessa finestra. |
| privacyRPC e metadati | Indirizzi, IP e uso possono transitare verso servizi necessari o opzionali. | La privacy dipende da feature e provider, non dal solo controllo chiavi. | Documentato | Osservare endpoint per feature senza usare fondi reali. |
| rimedioSupporto e dispute | Il supporto può gestire software o incidenti scoped, non invertire la chain. | Canale ufficiale, prova e limite del rimedio devono essere visibili. | Documentato | Aprire un quesito di provenienza e conservare risposta ed escalation. |
Protocolli riproducibili
Scenari che trasformano un’affermazione in una decisione osservabile.
Ogni protocollo definisce input, evidenza e regola di arresto prima dell’esecuzione.
Recovery su nuovo device
- Profilo
- Utente con wallet vuoto e seed offline.
- Percorso controllato
- Versione, chain e account derivati noti.
- Evidenza da conservare
- Prompt, warning, account trovati, backup e impostazioni finali.
- Regola decisionale
- Rifiutare qualsiasi percorso che invii il seed a un terzo.
Verifica della release
- Profilo
- Utente dell’extension prima di aggiornare.
- Percorso controllato
- Store ufficiale, publisher e versione bloccati.
- Evidenza da conservare
- Firma, note release, hash/provenienza disponibile e remediation.
- Regola decisionale
- Non installare se publisher o versione non sono riconciliabili.
Firma multichain
- Profilo
- Utente su contratto benigno e token test.
- Percorso controllato
- Rete, spender, cap e azione predefiniti.
- Evidenza da conservare
- Prompt, simulazione, chain ID, rifiuto e revoca.
- Regola decisionale
- Accettare soltanto quando potere e rete sono comprensibili.
Costo swap completo
- Profilo
- Utente che confronta route integrata e protocollo diretto.
- Percorso controllato
- Stessa chain, pair, amount e finestra.
- Evidenza da conservare
- Fee, gas, pool, impact, minimo e output finale.
- Regola decisionale
- Usare output netto, non claim di fee isolata.
Catena della responsabilità
Sei passaggi da leggere insieme.
Una licenza non descrive la custodia; una fee nominale non descrive il costo di uscita; una buona UX non sostituisce il rimedio.
Entità e territorio
Il wallet è self-custody; la privacy notice identifica Dapps Platform Bahrain W.L.L. come controller per il perimetro descritto. Wallet Core, app mobile, extension e partner di on-ramp/swap sono strati differenti e possono avere licenze e rimedi propri.
Custodia e controllo
La frase di recovery controlla gli account; backup cifrato opzionale aggiunge dipendenze cloud. Il provider non può ricostruire un seed non condiviso né annullare una firma valida.
Protezione e insolvenza
Non esiste protezione del saldo equivalente a un exchange. Un incidente di distribuzione può colpire una specifica build; il rimedio dipende da scope, prova del danno e programma del provider, non da una garanzia generale.
Costo completo
Swap e bridge includono gas, pool fee, spread, price impact, approval, failed transaction e costi partner. La dicitura no-extra-wallet-fee copre al massimo una componente.
Finanziamento e uscita
La route deve controllare chain ID, token contract, destinatario e finalità. Un errore di rete o approval può essere irreversibile; gli scenari usano importi minimi e wallet vuoti.
Privacy e rimedio
Indirizzi pubblici, IP, dispositivo e dati di utilizzo possono attraversare RPC o partner. Il supporto deve usare canali ufficiali, non chiedere il seed e distinguere incidente di versione da perdita causata da una firma.
Cronologia contestuale
Eventi datati, non etichette eterne.
Periodo dell’incidente dichiarato per l’estensione 2.68.
Versione e canale di distribuzione diventano parte della due diligence.
Aggiornamento provider su scope, indagine e rimborso.
Numeri e stato devono restare datati e attribuiti.
Privacy, seed, repository e incidente riesaminati.
Recovery, release e costi restano protocolli di prova.
Metodo applicato
Come è stato costruito questo fascicolo.
- 01
Bloccare app/extension, versione, OS e chain.
- 02
Usare account e token di prova senza valore materiale.
- 03
Separare Wallet Core dalla build distribuita.
- 04
Mappare ogni partner, fee, approval e dato.
Registro modifiche
· Aggiunti dieci assi su recovery, release, incidente, privacy e route multichain.
Domande frequenti
Risposte brevi, confini espliciti.
Trust Wallet può recuperare il seed perso?
No. Nel modello self-custody il seed è responsabilità dell’utente.
Wallet Core è l’intera app?
No. È un componente pubblico importante, non prova di UI, servizi e build store complete.
L’incidente 2.68 riguarda ogni utente?
No. Il record del provider riguarda una specifica release dell’estensione e va mantenuto nel suo scope.
No wallet fee significa costo zero?
No. Restano gas, pool, spread, impact, bridge e costi partner.
Registro delle fonti
6 documenti collegati al fascicolo.
Le fonti del fornitore descrivono ciò che il fornitore dichiara; i registri pubblici valgono solo nel loro perimetro.
- 01Contratto o documento di prodottoTrust Wallet — privacy notice ↗
- 02Contratto o documento di prodottoTrust Wallet — ciclo del seed ↗
- 03Record tecnicoTrust Wallet Core repository ↗
- 04Contratto o documento di prodottoTrust Wallet — FAQ ↗
- 05Dichiarazione del fornitoreTrust Wallet — security overview ↗
- 06Registro primarioTrust Wallet — incidente v2.68 ↗