Trust Wallet

trustwallet.com
Last Updated: 22-Mar 2024

Stats

Chrome
Chrome
1,000,000+
Firefox
Firefox
0
Opera
Opera
0
Edge
Edge
0
Android
Android
10,000,000+
IOS
IOS
400,000+
Windows
Windows
0
Mac OS
Mac OS
0
These are best estimates on downloads from various extension and app stores.

Staking

Swap

Bridge

Daily Transaction Count (Smart Account)

Daily Deployed Trust Wallet Smart Accounts

Daily Active Trust Wallet Smart Accounts

Weekly Active Trust Wallet Smart Accounts

Activity

Wallet Core

0 contributors in the last year

Assets

0 contributors in the last year

Security Analysis

Key Management

Responsibility

A single user is responsible for managing the private key (secp256k1key pair in this case). We’ll discuss the key generation process in detail in the next section.

Storage

where is the key stored in: - browsers - mobile devices (iOS, Android) The passkey is generated by the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices). The passkey is locally stored on the device’s Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices).

Access

The user can access Secure Enclave (in case of iOS devices) or similar modules (in case of Android devices) in order to perform different operations without the passkey ever leaving the Secure Enclave.

Metamask allows users to use a password to access the key stored in the user’s local browser’s storage.

In case of mobile wallet users can use a password OR biometrics to access the key stored in the user’s device.

More info on how MetaMask stores your wallet secret?

Account Management

  • EOA ✅
  • SCA ⚠️ (not supported natively, but could be supported using AA snap plugin)

Processes

For each case, check, how this works and some benchmarks on cost and time used to perform the operation.

Key generation

A random number selected from the secp256k1 elliptic curve serves as the private key. This key is then multiplied by a predefined point on the curve to generate the public key. The Ethereum address is derived from the last 20 bytes of the hashed public key. The 'seed phrase' is usually introduced for human-readable backup, enabling the deterministic derivation of private and public keys.

Transaction process

Signing Transactions: A transaction, containing details such as nonce(a sequential number), amount, gas price, and recipient address, is signed using the private key. This process, involving the ECDSA, a digital signature algorithm that uses elliptic curve cryptography and adopts secp256k1 as the curve, generates a signature consisting of values (r, s, v). The signature and the original transaction are then broadcast on the network.

Verifying Transactions: Once a transaction reaches Ethereum nodes, it undergoes a validation process in the node's mempool. To verify the signer, the nodes use the signature and hashed transaction to derive the sender's public key and confirm the transaction's authenticity by matching the derived address with the sender's.

Account Recovery process

Users are suggested to maintain a secure back up of the seed phrase/private key(s) in order to recover their account if needed. If a user loses their private key/seed phrase, then they cannot recover their account.

Migrating from another wallet
  • Seed phrase import supported (seed format supported: 12/24)
  • Private key import supported
  • Hierarchical deterministic (HD) address derivation
Migrating to another wallet

You can export your private key/seed phrase and import that to any other compatible wallet.

Features

In App

KYC required-
Social login-
Email login-
Passkey login-
Smart Account support-
Portfolio tracking-
On-ramp support-
Off-ramp support-
Watching wallets-
Ability to point to custom rpc-
Swap support-
Bridge support-
Stake support-
View NFTs-
Dapp browser-
gas fees customization-
token importing-

Security

Screenshot possibility while doing backup-
Transaction Simulation-

ENS Support

MainnetWhether a user is able to send transactions to a standard ENS (e.g. user.eth) on mainnet
SubdomainsWhether a user is able to send transactions to an ENS subdomain (e.g. hot.user.eth) on mainnet
OffchainWhether a user is able to send transactions to an ENS with an offchain resolver on mainnet.
L2sWhether a user is able to send transactions to an ENS on an L2 (tested on Optimism)
customWhether a user is able to send transactions to an ENS with a custom domain on mainnet (e.g. user.cb.id)

Hardware Wallet Supports

Ledger

Supported Standards

EIP nameEIP typeEIP statusWallet Support status
ERC-4337: Account Abstraction Using Alt MempoolStandards Track: ERCDraft
ERC-6900: Modular Smart Contract Accounts and PluginsStandards Track: ERCDraft
EIP-7039: Scheme-Handler Discovery Option for WalletsStandards Track: InterfaceDraft
🛑
EIP-7521: General Intents for Smart Contract WalletsStandards Track: ERCDraft
🛑
EIP-7377: Migration TransactionStandards Track: CoreDraft
🛑
ERC-7484: Registry Extension for ERC-7579Standards Track: ERCDraft
🛑
ERC-7529: Contract Discovery and eTLD+1 AssociationStandards Track: ERCDraft
🛑
ERC-7579: Minimal Modular Smart AccountsStandards Track: ERCDraft
🛑
EIP-3085: wallet_addEthereumChain RPC MethodStandards Track: InterfaceReview
ERC-5568: Well-Known Format for Required ActionsStandards Track: ERCReview
🛑
ERC-831: URI Format for EthereumStandards Track: ERCStagnant
EIP-1102: Opt-in account exposureStandards Track: InterfaceStagnant
EIP-1474: Remote procedure call specificationStandards Track: InterfaceStagnant
EIP-2015: wallet_updateEthereumChain RPC MethodStandards Track: InterfaceStagnant
ERC-3224: Described DataStandards Track: ERCStagnant
🛑
EIP-3326: Wallet Switch Ethereum Chain RPC Method (wallet_switchEthereumChain)Standards Track: InterfaceStagnant
ERC-4430: Described TransactionsStandards Track: ERCStagnant
🛑
EIP-5003: Insert Code into EOAs with AUTHUSURPStandards Track: CoreStagnant
🛑
ERC-5139: Remote Procedure Call Provider ListsStandards Track: ERCStagnant
EIP-5792: Wallet Function Call APIStandards Track: InterfaceStagnant
ERC-6384: Human-readable offline signaturesStandards Track: ERCStagnant
EIP-4844: Shard Blob TransactionsStandards Track: CoreLast Call
ERC-681: URL Format for Transaction RequestsStandards Track: ERCFinal
EIP-712: Typed structured data hashing and signingStandards Track: InterfaceFinal
EIP-747: wallet_watchAsset RPC MethodStandards Track: InterfaceFinal
EIP-1193: Ethereum Provider JavaScript APIStandards Track: InterfaceFinal
ERC-1271: Standard Signature Validation Method for ContractsStandards Track: ERCFinal
EIP-1559: Fee market change for ETH 1.0 chainStandards Track: CoreFinal
EIP-2255: Wallet Permissions SystemStandards Track: InterfaceFinal
EIP-2930: Optional access listsStandards Track: CoreFinal
EIP-6492: Signature Validation for Predeploy ContractsStandards Track: ERCFinal
EIP-6963: Multi Injected Provider DiscoveryStandards Track: InterfaceFinal
ERC-945: wallet_scanQRCode RPC Method
RIP-7560: Native Account Abstraction
ERC-7555: Single Sign-On for Account Discovery
🛑

Incentives

No incentives

Security

Audit

Audits in Web3 refer to the process of conducting comprehensive security assessments and evaluations of blockchain-based projects, smart contracts, decentralized applications (dApps), and other Web3 protocols. The purpose of these audits is to identify vulnerabilities, potential risks, and weaknesses in the code and system architecture to enhance security, reliability, and trustworthiness.

Bug Bounty

A bug bounty program in Web3 is an initiative offered by blockchain projects, cryptocurrency platforms, or decentralized applications (dApps) to incentivize security researchers and ethical hackers to discover and report vulnerabilities or bugs in their systems. It is a crowdsourced approach to security testing where individuals or teams are rewarded for responsibly disclosing vulnerabilities they find.

PlatformRewardStatusScope
HackerOne$1K - $50KActiveLink

Past Incidents

TODO