Wallet Security Ranking Methodology
We created a standard security checklist to provide transparent, objective insights into the most secure crypto wallets.
We test, you decide.
Intent Verification
Evaluates how effectively the wallet decodes and presents transaction data. Includes translating raw hex/EIP-712 into readable formats, simulating outcomes, validating checksums, and ensuring payloads are fully visible and reviewed before signing.
Attack scenario An attacker tricks the user into blind-signing opaque or partially hidden payloads, or exploits mistyped addresses, causing unintended asset transfers to malicious destinations.
7 checks
- EIP-55 checksums are meant to catch address-entry mistakes that would otherwise be hard to spot. Warning on an invalid checksum reduces the chance of sending funds to a mistyped or malformed address, especially when users copy addresses from unreliable sources. Attempt to send a transaction to an address with an incorrect EIP-55 checksum (e.g. alter the case of any letter). The transaction should be attempted manually and from a dApp. Observe whether the wallet surfaces a warning or blocks the transaction. The wallet blocks the transaction or shows a checksum warning before the transaction proceeds, for both manually entered and dApp-provided addresses (a failed transaction counts as blocked). The wallet allows the transaction without a checksum warning in at least one of the two cases. A screenshot showing the wallet's response to the invalid-checksum address: whether it warns, blocks the transaction, or allows it to proceed. The address used must be documented. A user sends funds to a mistyped or manipulated address due to input errors or clipboard tampering.
Invalid address checksum detection
WSR-VERI-001Warns users when they input addresses with invalid EIP-55 checksums.
Reasoning
EIP-55 checksums are meant to catch address-entry mistakes that would otherwise be hard to spot. Warning on an invalid checksum reduces the chance of sending funds to a mistyped or malformed address, especially when users copy addresses from unreliable sources.
Instructions
Attempt to send a transaction to an address with an incorrect EIP-55 checksum (e.g. alter the case of any letter). The transaction should be attempted manually and from a dApp. Observe whether the wallet surfaces a warning or blocks the transaction.
Criteria
- Pass The wallet blocks the transaction or shows a checksum warning before the transaction proceeds, for both manually entered and dApp-provided addresses (a failed transaction counts as blocked).
- Fail The wallet allows the transaction without a checksum warning in at least one of the two cases.
Evidence Requirements
A screenshot showing the wallet's response to the invalid-checksum address: whether it warns, blocks the transaction, or allows it to proceed. The address used must be documented.
Attack Scenario
A user sends funds to a mistyped or manipulated address due to input errors or clipboard tampering.
- Explorer links let users independently verify addresses, contracts, and transactions instead of trusting only the wallet UI. This improves transparency and makes it easier to inspect counterparties, token contracts, and transaction outcomes before or after signing. Attempt to send a transaction and inspect the preview screen. Also browse the wallet's transaction history. Observe whether addresses, contract addresses, or transaction hashes are displayed as clickable links to a block explorer. Addresses, contract addresses, or transaction hashes are clickable and open a block explorer in both the transaction preview screen and the wallet history. Addresses, contract addresses, or transaction hashes are clickable and open a block explorer in only one of the two contexts. The wallet provides no block explorer links for these identifiers in either context. A screenshot showing whether addresses, contract addresses, and transaction hashes appear as clickable block-explorer links, captured in both the transaction details screen and the wallet history. If no links are present, include the same screens showing their absence, along with a tester note stating so. A malicious interface misrepresents transaction or address details, preventing independent verification by the user.
Links to blockchain explorers
WSR-VERI-002Provides clickable links to block explorers for at least one key blockchain identifier.
Reasoning
Explorer links let users independently verify addresses, contracts, and transactions instead of trusting only the wallet UI. This improves transparency and makes it easier to inspect counterparties, token contracts, and transaction outcomes before or after signing.
Instructions
Attempt to send a transaction and inspect the preview screen. Also browse the wallet's transaction history. Observe whether addresses, contract addresses, or transaction hashes are displayed as clickable links to a block explorer.
Criteria
- Pass Addresses, contract addresses, or transaction hashes are clickable and open a block explorer in both the transaction preview screen and the wallet history.
- Partial Addresses, contract addresses, or transaction hashes are clickable and open a block explorer in only one of the two contexts.
- Fail The wallet provides no block explorer links for these identifiers in either context.
Evidence Requirements
A screenshot showing whether addresses, contract addresses, and transaction hashes appear as clickable block-explorer links, captured in both the transaction details screen and the wallet history. If no links are present, include the same screens showing their absence, along with a tester note stating so.
Attack Scenario
A malicious interface misrepresents transaction or address details, preventing independent verification by the user.
- Many dangerous transactions only become obvious when looking at their actual effects, not just calldata or method names. Simulation helps users see expected token movements, approvals, or state changes in advance, which is one of the strongest defenses against deceptive dApp flows. Attempt to provide liquidity into a liquidity pool and perform a swap (e.g. Uniswap) and observe whether the wallet shows the expected inputs and outputs from the execution of such transaction before it is signed. The wallet shows the expected inputs and outputs from the execution of such transaction effects before signing. The wallet does not show the expected inputs and outputs before signing. A screenshot showing whether the wallet displays a simulation of the expected inputs and outputs for both the liquidity provision and the swap before signing; if it does not simulate, a screenshot of each transaction confirmation screen as it appears, along with a tester note stating no simulation was found. A malicious dApp disguises the real effects of a transaction, such as draining funds or granting approvals, until after it is signed.
Transaction simulation
WSR-VERI-003Previews the expected outcome by simulating the request execution on the blockchain before signing.
Reasoning
Many dangerous transactions only become obvious when looking at their actual effects, not just calldata or method names. Simulation helps users see expected token movements, approvals, or state changes in advance, which is one of the strongest defenses against deceptive dApp flows.
Instructions
Attempt to provide liquidity into a liquidity pool and perform a swap (e.g. Uniswap) and observe whether the wallet shows the expected inputs and outputs from the execution of such transaction before it is signed.
Criteria
- Pass The wallet shows the expected inputs and outputs from the execution of such transaction effects before signing.
- Fail The wallet does not show the expected inputs and outputs before signing.
Evidence Requirements
A screenshot showing whether the wallet displays a simulation of the expected inputs and outputs for both the liquidity provision and the swap before signing; if it does not simulate, a screenshot of each transaction confirmation screen as it appears, along with a tester note stating no simulation was found.
Attack Scenario
A malicious dApp disguises the real effects of a transaction, such as draining funds or granting approvals, until after it is signed.
- EIP-712 is designed to make structured data more understandable, but that only works if the wallet parses and presents it clearly. Human-readable rendering helps users distinguish between harmless messages and signatures that authorize critical permissions or off-chain actions. Trigger EIP-712 signature requests from well-known protocols such as OpenSea Seaport, ERC-20 Permit flows, or Uniswap, and observe how the wallet renders them — whether it shows structured, human-readable detail or raw JSON. In the testing dApp, go to `/sign` and attempt signing an ERC20 Permit or Opensea listing. The wallet renders structured, interpreted, human-readable signing details, with fields (e.g., for an ERC-20 Permit: spender, amount, and deadline), rather than raw information from the JSON object. Otherwise, EIP-712 signing is not supported. The wallet displays the EIP-712 message as a raw JSON object, even if indented or syntax-highlighted. The JSON object is not interpreted or transformed in any way. A screenshot showing the wallet's rendering of the EIP-712 request: whether it parses the message into distinct, human-readable fields or raw JSON object. If EIP-712 signing is not supported, document that instead. A malicious dApp crafts structured data that appears benign but actually grants permissions or authorizations when signed.
EIP-712 message parsing
WSR-VERI-004Displays human-readable details for EIP-712 signature requests from well-known protocols.
Reasoning
EIP-712 is designed to make structured data more understandable, but that only works if the wallet parses and presents it clearly. Human-readable rendering helps users distinguish between harmless messages and signatures that authorize critical permissions or off-chain actions.
Instructions
Trigger EIP-712 signature requests from well-known protocols such as OpenSea Seaport, ERC-20 Permit flows, or Uniswap, and observe how the wallet renders them — whether it shows structured, human-readable detail or raw JSON. In the testing dApp, go to
/signand attempt signing an ERC20 Permit or Opensea listing.Criteria
- Pass The wallet renders structured, interpreted, human-readable signing details, with fields (e.g., for an ERC-20 Permit: spender, amount, and deadline), rather than raw information from the JSON object. Otherwise, EIP-712 signing is not supported.
- Fail The wallet displays the EIP-712 message as a raw JSON object, even if indented or syntax-highlighted. The JSON object is not interpreted or transformed in any way.
Evidence Requirements
A screenshot showing the wallet's rendering of the EIP-712 request: whether it parses the message into distinct, human-readable fields or raw JSON object. If EIP-712 signing is not supported, document that instead.
Attack Scenario
A malicious dApp crafts structured data that appears benign but actually grants permissions or authorizations when signed.
- ERC-20 approvals can grant a spender long-lived control over tokens. Clearly showing the token, spender, and amount helps users detect malicious approvals, unlimited allowances, and approvals targeting unexpected contracts. Trigger an ERC-20 approve in two ways: 1) deploy a custom ERC-20 (via `/sendtransaction` in the testing dApp) and call approve directly, and 2) access any swap dApp and trigger an approve through the UI. Observe what information the wallet displays about the token, spender, and amount. The wallet clearly identifies the request as an approval and shows the token symbol or address, the spender address, and the approved amount. The wallet does not identify the request as an approval, or omits the token symbol or address, the spender address, or the approved amount. A screenshot showing the wallet's approval dialog: whether the token address, spender address, and approved amount are displayed. The token used must be documented. A malicious dApp tricks the user into approving excessive or unlimited token allowances to an attacker-controlled contract.
Clear token approval dialog
WSR-VERI-005Clearly displays all the key details for ERC-20 Approve requests.
Reasoning
ERC-20 approvals can grant a spender long-lived control over tokens. Clearly showing the token, spender, and amount helps users detect malicious approvals, unlimited allowances, and approvals targeting unexpected contracts.
Instructions
Trigger an ERC-20 approve in two ways: 1) deploy a custom ERC-20 (via
/sendtransactionin the testing dApp) and call approve directly, and 2) access any swap dApp and trigger an approve through the UI. Observe what information the wallet displays about the token, spender, and amount.Criteria
- Pass The wallet clearly identifies the request as an approval and shows the token symbol or address, the spender address, and the approved amount.
- Fail The wallet does not identify the request as an approval, or omits the token symbol or address, the spender address, or the approved amount.
Evidence Requirements
A screenshot showing the wallet's approval dialog: whether the token address, spender address, and approved amount are displayed. The token used must be documented.
Attack Scenario
A malicious dApp tricks the user into approving excessive or unlimited token allowances to an attacker-controlled contract.
- Users cannot give meaningful consent if important parts of the message are hidden, truncated, or impossible to inspect. Full visibility into signed data is critical because attackers can bury harmful payloads or structured objects. Send large payloads via `personal_sign` and `eth_signTypedData` (via `/sign` in the testing dApp) and observe whether all content is visible, scrollable, and not truncated. For EIP-712 objects, also check whether the `EIP712Domain`, including `verifyingContract`, is displayed. All signing data is visible (including the `verifyingContract` for EIP-712), scrollable, and not truncated for every functional signing method. Non-functional or unsupported methods (e.g. `personal_sign`) are ignored. For at least one functional signing method (e.g. `eth_signTypedData`), the wallet truncates the signing data, does not allow scrolling through it, or fails to show the `verifyingContract` for EIP-712. A screenshot showing the wallet's rendering of the large personal_sign and EIP-712 payloads: whether the full content is visible, scrollable, and not truncated, including the verifyingContract for EIP-712. A malicious dApp hides or obfuscates critical parts of a signing payload, leading the user to approve unintended or harmful data.
Clear message signing dialog
WSR-VERI-006Clearly displays all message signature request details without truncating or hiding information.
Reasoning
Users cannot give meaningful consent if important parts of the message are hidden, truncated, or impossible to inspect. Full visibility into signed data is critical because attackers can bury harmful payloads or structured objects.
Instructions
Send large payloads via
personal_signandeth_signTypedData(via/signin the testing dApp) and observe whether all content is visible, scrollable, and not truncated. For EIP-712 objects, also check whether theEIP712Domain, includingverifyingContract, is displayed.Criteria
- Pass All signing data is visible (including the
verifyingContractfor EIP-712), scrollable, and not truncated for every functional signing method. Non-functional or unsupported methods (e.g.personal_sign) are ignored. - Fail For at least one functional signing method (e.g.
eth_signTypedData), the wallet truncates the signing data, does not allow scrolling through it, or fails to show theverifyingContractfor EIP-712.
Evidence Requirements
A screenshot showing the wallet's rendering of the large personal_sign and EIP-712 payloads: whether the full content is visible, scrollable, and not truncated, including the verifyingContract for EIP-712.
Attack Scenario
A malicious dApp hides or obfuscates critical parts of a signing payload, leading the user to approve unintended or harmful data.
- Pass All signing data is visible (including the
- Forcing the user to scroll through the full request makes rushed or accidental approvals less likely. It is not a perfect defense, but it raises friction in exactly the places where attackers benefit from users clicking through without reviewing the content. Send a large payload via `personal_sign` or `eth_signTypedData` and observe whether the sign button is accessible before scrolling to the end of the content. The sign button remains disabled until the user scrolls through the entire message for every functional signing method. Non-functional or unsupported methods (e.g. `personal_sign`) are ignored. The sign button becomes enabled before the user scrolls through the entire message for at least one functional signing method (e.g. `eth_signTypedData`). A screenshot showing whether the sign button remains disabled until the message has been fully scrolled. A tester note confirming whether the button only became enabled after scrolling to the end is also expected. A malicious dApp relies on users blindly approving signature requests without reviewing their contents, leading to unintended authorizations.
Mandatory message review
WSR-VERI-007Requires users to review all the details before signing a message.
Reasoning
Forcing the user to scroll through the full request makes rushed or accidental approvals less likely. It is not a perfect defense, but it raises friction in exactly the places where attackers benefit from users clicking through without reviewing the content.
Instructions
Send a large payload via
personal_signoreth_signTypedDataand observe whether the sign button is accessible before scrolling to the end of the content.Criteria
- Pass The sign button remains disabled until the user scrolls through the entire message for every functional signing method. Non-functional or unsupported methods (e.g.
personal_sign) are ignored. - Fail The sign button becomes enabled before the user scrolls through the entire message for at least one functional signing method (e.g.
eth_signTypedData).
Evidence Requirements
A screenshot showing whether the sign button remains disabled until the message has been fully scrolled. A tester note confirming whether the button only became enabled after scrolling to the end is also expected.
Attack Scenario
A malicious dApp relies on users blindly approving signature requests without reviewing their contents, leading to unintended authorizations.
- Pass The sign button remains disabled until the user scrolls through the entire message for every functional signing method. Non-functional or unsupported methods (e.g.
Physical Access
Evaluates defenses against unauthorized physical access and local data exposure. Includes strong authentication, auto-locking, rate limiting, and restricting seed phrase exposure via clipboards, screenshots, or unauthenticated views.
Attack scenario An attacker with temporary physical access exploits an unlocked session or weak local authentication to authorize transactions or exfiltrate secrets (like the seed phrase).
8 checks
- Seed phrases are extremely sensitive, and clipboards and screenshots are common exfiltration paths on both desktop and mobile systems. Limiting, warning, or blocking these actions reduces the exposure window and makes users think twice before handling secrets insecurely. Navigate to the seed phrase screen and copy the mnemonic to the clipboard. Observe whether the wallet clears it after a short time or displays a warning. On mobile, also attempt to take a screenshot and observe the response. The wallet limits clipboard exposure (1 min max), warns about clipboard risks, or prevents copying. On mobile, it must also prevent or warn users about screenshot risks. The wallet offers no clipboard protection, or no screenshot protection on mobile. A screenshot showing the wallet's response when the seed phrase is copied to the clipboard: whether it clears the clipboard, warns about the risk, or blocks copying, and on mobile whether it prevents or warns about screenshots. If none of these occur, include a screenshot of the seed phrase screen as it appears. A tester note stating whether the clipboard was cleared, and after how long, is also expected. Seed phrases are exposed through clipboard access or screenshots that may be stored locally, synced to the cloud, or accessed by someone with physical access to the device.
Clipboard seed phrase leak prevention
WSR-PHYS-001Limits exposure of secrets by restricting or warning on copying seed phrases or taking screenshots.
Reasoning
Seed phrases are extremely sensitive, and clipboards and screenshots are common exfiltration paths on both desktop and mobile systems. Limiting, warning, or blocking these actions reduces the exposure window and makes users think twice before handling secrets insecurely.
Instructions
Navigate to the seed phrase screen and copy the mnemonic to the clipboard. Observe whether the wallet clears it after a short time or displays a warning. On mobile, also attempt to take a screenshot and observe the response.
Criteria
- Pass The wallet limits clipboard exposure (1 min max), warns about clipboard risks, or prevents copying. On mobile, it must also prevent or warn users about screenshot risks.
- Fail The wallet offers no clipboard protection, or no screenshot protection on mobile.
Evidence Requirements
A screenshot showing the wallet's response when the seed phrase is copied to the clipboard: whether it clears the clipboard, warns about the risk, or blocks copying, and on mobile whether it prevents or warns about screenshots. If none of these occur, include a screenshot of the seed phrase screen as it appears. A tester note stating whether the clipboard was cleared, and after how long, is also expected.
Attack Scenario
Seed phrases are exposed through clipboard access or screenshots that may be stored locally, synced to the cloud, or accessed by someone with physical access to the device.
- Weak local authentication can completely undermine all other security controls. Strong passwords, biometrics, and rate-limiting make brute force, shoulder surfing, and opportunistic device access much harder. Check whether biometric authentication is available and attempt to set a weak PIN (e.g. `1234`). Then attempt multiple incorrect logins and observe whether rate limiting activates. The wallet supports biometrics. If it allows easy-to-guess passwords/pins, it rate limits attempts after the 5th one. The wallet lacks biometrics, or allows easy-to-guess passwords/pins without rate limiting attempts after the 5th one. A screenshot showing whether the weak PIN was accepted and whether rate limiting triggers after the 5th failed attempt, noting biometric availability. The PIN used must be documented. An attacker with access to the device bypasses weak authentication mechanisms (e.g., weak passwords, lack of rate limiting) to gain control of the wallet.
Robust Authentication
Mobile WSR-PHYS-002Uses strong authentication, including biometrics, rate limiting, and resistance to trivial credentials.
Reasoning
Weak local authentication can completely undermine all other security controls. Strong passwords, biometrics, and rate-limiting make brute force, shoulder surfing, and opportunistic device access much harder.
Instructions
Check whether biometric authentication is available and attempt to set a weak PIN (e.g.
1234). Then attempt multiple incorrect logins and observe whether rate limiting activates.Criteria
- Pass The wallet supports biometrics. If it allows easy-to-guess passwords/pins, it rate limits attempts after the 5th one.
- Fail The wallet lacks biometrics, or allows easy-to-guess passwords/pins without rate limiting attempts after the 5th one.
Evidence Requirements
A screenshot showing whether the weak PIN was accepted and whether rate limiting triggers after the 5th failed attempt, noting biometric availability. The PIN used must be documented.
Attack Scenario
An attacker with access to the device bypasses weak authentication mechanisms (e.g., weak passwords, lack of rate limiting) to gain control of the wallet.
- Weak local authentication can completely undermine all other security controls. Strong passwords, biometrics, and rate-limiting make brute force, shoulder surfing, and opportunistic device access much harder. Attempt short or trivial passwords such as `1234`, `12345678`, `qwertyui`, or `password` and observe whether they are accepted. The wallet requires at least an 8 characters long password (standard across most products), and does not allow trivial passwords. The wallet accepts passwords shorter than 8 characters, or trivial ones. A screenshot showing whether each trivial password was accepted or rejected. The passwords used must be documented. An attacker with access to the device bypasses weak authentication mechanisms (e.g., weak passwords) to gain control of the wallet.
Robust Authentication
Browser WSR-PHYS-002Uses strong authentication, such as resistance to trivial or commonly-used passwords.
Reasoning
Weak local authentication can completely undermine all other security controls. Strong passwords, biometrics, and rate-limiting make brute force, shoulder surfing, and opportunistic device access much harder.
Instructions
Attempt short or trivial passwords such as
1234,12345678,qwertyui, orpasswordand observe whether they are accepted.Criteria
- Pass The wallet requires at least an 8 characters long password (standard across most products), and does not allow trivial passwords.
- Fail The wallet accepts passwords shorter than 8 characters, or trivial ones.
Evidence Requirements
A screenshot showing whether each trivial password was accepted or rejected. The passwords used must be documented.
Attack Scenario
An attacker with access to the device bypasses weak authentication mechanisms (e.g., weak passwords) to gain control of the wallet.
- Users sometimes reveal seed phrases or private keys without fully understanding that doing so grants complete control over their assets. A clear warning at the moment of exposure can prevent catastrophic mistakes and reinforces the severity of the action. Navigate to the seed phrase or private key reveal screen and observe whether the risks of sharing the secrets are shown. The wallet clearly communicates and displays a warning about these risks to the user before revealing the secrets. The wallet reveals the secrets without a clear warning about the risks. A screenshot showing whether the wallet displays a warning about the risks before revealing the seed phrase or private key. If no warning is shown, include a screenshot of the reveal screen as it appears, along with a tester note stating so. A user exposes their seed phrase without understanding it grants full control over their funds.
Seed phrase access warning
WSR-PHYS-003Warns users of the risk before allowing access to seed phrases or private keys.
Reasoning
Users sometimes reveal seed phrases or private keys without fully understanding that doing so grants complete control over their assets. A clear warning at the moment of exposure can prevent catastrophic mistakes and reinforces the severity of the action.
Instructions
Navigate to the seed phrase or private key reveal screen and observe whether the risks of sharing the secrets are shown.
Criteria
- Pass The wallet clearly communicates and displays a warning about these risks to the user before revealing the secrets.
- Fail The wallet reveals the secrets without a clear warning about the risks.
Evidence Requirements
A screenshot showing whether the wallet displays a warning about the risks before revealing the seed phrase or private key. If no warning is shown, include a screenshot of the reveal screen as it appears, along with a tester note stating so.
Attack Scenario
A user exposes their seed phrase without understanding it grants full control over their funds.
- Users need a fast way to secure the wallet when stepping away, sharing a screen, or using a device in public. Manual locking gives immediate control rather than forcing the user to wait for an inactivity timer. Look for a manual lock button within the wallet UI. The wallet includes a manual lock control. The wallet has no manual lock control. A screenshot showing whether the wallet provides a manual lock control. If none exists, include a screenshot of the menu or settings section where it would be expected, along with a tester note stating it could not be found. An attacker with access to the device interacts with an unlocked wallet session to perform unauthorized actions.
Manual wallet lock
WSR-PHYS-004Allows users to lock it manually.
Reasoning
Users need a fast way to secure the wallet when stepping away, sharing a screen, or using a device in public. Manual locking gives immediate control rather than forcing the user to wait for an inactivity timer.
Instructions
Look for a manual lock button within the wallet UI.
Criteria
- Pass The wallet includes a manual lock control.
- Fail The wallet has no manual lock control.
Evidence Requirements
A screenshot showing whether the wallet provides a manual lock control. If none exists, include a screenshot of the menu or settings section where it would be expected, along with a tester note stating it could not be found.
Attack Scenario
An attacker with access to the device interacts with an unlocked wallet session to perform unauthorized actions.
- Seed phrases and private keys should be protected behind strong re-authentication because they are the ultimate account recovery and control mechanism. Displaying them without an authentication step makes accidental exposure and local compromise far more likely. Navigate to the seed phrase or private key display screen and observe whether authentication is required before the secrets are shown. Authentication is required before displaying mnemonics or private keys, or seed-phrase backup is not available. The wallet displays mnemonics or private keys without requiring authentication. A screenshot showing whether the wallet requires authentication before displaying the mnemonic or private key, and which method it requires. If no authentication is required, include a screenshot of the secret being shown without any prompt, along with a tester note stating so. An attacker with access to the device retrieves seed phrases or private keys due to missing or weak re-authentication controls.
Seed phrase access control
WSR-PHYS-005Requires authentication to access seed phrases or private keys.
Reasoning
Seed phrases and private keys should be protected behind strong re-authentication because they are the ultimate account recovery and control mechanism. Displaying them without an authentication step makes accidental exposure and local compromise far more likely.
Instructions
Navigate to the seed phrase or private key display screen and observe whether authentication is required before the secrets are shown.
Criteria
- Pass Authentication is required before displaying mnemonics or private keys, or seed-phrase backup is not available.
- Fail The wallet displays mnemonics or private keys without requiring authentication.
Evidence Requirements
A screenshot showing whether the wallet requires authentication before displaying the mnemonic or private key, and which method it requires. If no authentication is required, include a screenshot of the secret being shown without any prompt, along with a tester note stating so.
Attack Scenario
An attacker with access to the device retrieves seed phrases or private keys due to missing or weak re-authentication controls.
- Mobile devices are frequently lost, borrowed, or left unlocked briefly, so short auto-lock periods materially reduce the chance of unauthorized access. Review the auto-lock timer in the wallet settings. If it's set to 0, the wallet won't likely auto-lock. If the wallet does not expose an auto-lock setting, exit the wallet or leave it idle and observe whether it locks after a period of inactivity. Also verify whether the wallet also locks when the application is moved to the background or when the device itself is locked. The wallet auto-locks after inactivity (1 minute or less by default), when the device locks, or when the app moves to the background. The wallet does not auto-lock in any of these cases. A screenshot showing the wallet's auto-lock configuration and whether it locks after inactivity, when the device locks, or when the app moves to the background, noting the configured timeout. If no auto-lock setting exists, include a screenshot of the security or settings section where it would be expected, along with a tester note stating it could not be found. An attacker with access to the device exploits an idle or background wallet session that remains unlocked.
Automatic wallet lock
Mobile WSR-PHYS-006Verifies wallet auto-locks on inactivity, device lock, or background.
Reasoning
Mobile devices are frequently lost, borrowed, or left unlocked briefly, so short auto-lock periods materially reduce the chance of unauthorized access.
Instructions
Review the auto-lock timer in the wallet settings. If it's set to 0, the wallet won't likely auto-lock. If the wallet does not expose an auto-lock setting, exit the wallet or leave it idle and observe whether it locks after a period of inactivity. Also verify whether the wallet also locks when the application is moved to the background or when the device itself is locked.
Criteria
- Pass The wallet auto-locks after inactivity (1 minute or less by default), when the device locks, or when the app moves to the background.
- Fail The wallet does not auto-lock in any of these cases.
Evidence Requirements
A screenshot showing the wallet's auto-lock configuration and whether it locks after inactivity, when the device locks, or when the app moves to the background, noting the configured timeout. If no auto-lock setting exists, include a screenshot of the security or settings section where it would be expected, along with a tester note stating it could not be found.
Attack Scenario
An attacker with access to the device exploits an idle or background wallet session that remains unlocked.
- Browser extension wallets often remain open for long periods on shared or unattended computers. A reasonable auto-lock time reduces the window in which an attacker, coworker, or malicious webpage can exploit an already-unlocked wallet. Check the wallet settings for an auto-lock configuration. If no setting is visible, leave the wallet idle for up to 20 minutes to observe whether it auto-locks. If it's 0 by default, then the wallet does not auto-lock on inactivity. The wallet auto-locks after inactivity within 20 minutes. The wallet does not auto-lock within 20 minutes of inactivity. A screenshot showing the wallet's auto-lock configuration and whether it locks after inactivity, noting the configured timeout. If no auto-lock setting exists, include a screenshot of the security or settings section where it would be expected, along with a tester note stating it could not be found. An attacker with access to the device exploits an idle or unattended wallet session that remains unlocked.
Automatic wallet lock
Browser WSR-PHYS-006Verifies wallet auto-locks on inactivity.
Reasoning
Browser extension wallets often remain open for long periods on shared or unattended computers. A reasonable auto-lock time reduces the window in which an attacker, coworker, or malicious webpage can exploit an already-unlocked wallet.
Instructions
Check the wallet settings for an auto-lock configuration. If no setting is visible, leave the wallet idle for up to 20 minutes to observe whether it auto-locks. If it's 0 by default, then the wallet does not auto-lock on inactivity.
Criteria
- Pass The wallet auto-locks after inactivity within 20 minutes.
- Fail The wallet does not auto-lock within 20 minutes of inactivity.
Evidence Requirements
A screenshot showing the wallet's auto-lock configuration and whether it locks after inactivity, noting the configured timeout. If no auto-lock setting exists, include a screenshot of the security or settings section where it would be expected, along with a tester note stating it could not be found.
Attack Scenario
An attacker with access to the device exploits an idle or unattended wallet session that remains unlocked.
Threat Prevention
Evaluates proactive measures against deceptive dApps and external threats. Includes blocklists for phishing and malicious contracts, identification of trusted domains, and filtering out malicious tokens or NFTs.
Attack scenario A user interacts with a phishing site or malicious contract, and the wallet fails to intercept the interaction or warn about the risk, leading to direct asset loss.
7 checks
- Verified dApp indicators help users distinguish trusted, well-known services from lookalike phishing sites. This is especially valuable during connection prompts, where users are often making a quick trust decision with limited information. Attempt to connect to a well-known dApp (e.g. Uniswap) and observe the connection request screen. Then repeat with an unknown dApp and compare how each is displayed. The wallet visibly distinguishes verified dApps from unknown ones (e.g. with a checkmark or trust badge). The wallet does not distinguish verified dApps from unknown ones. A screenshot comparing both connection screens: whether the wallet visibly distinguishes the verified dApp from the unknown one. The dApps used must be documented. A phishing site impersonates a trusted dApp to gain user trust and request sensitive actions.
Trusted dApp detection
WSR-THRE-001Informs users when interacting with a trusted dApp URL.
Reasoning
Verified dApp indicators help users distinguish trusted, well-known services from lookalike phishing sites. This is especially valuable during connection prompts, where users are often making a quick trust decision with limited information.
Instructions
Attempt to connect to a well-known dApp (e.g. Uniswap) and observe the connection request screen. Then repeat with an unknown dApp and compare how each is displayed.
Criteria
- Pass The wallet visibly distinguishes verified dApps from unknown ones (e.g. with a checkmark or trust badge).
- Fail The wallet does not distinguish verified dApps from unknown ones.
Evidence Requirements
A screenshot comparing both connection screens: whether the wallet visibly distinguishes the verified dApp from the unknown one. The dApps used must be documented.
Attack Scenario
A phishing site impersonates a trusted dApp to gain user trust and request sensitive actions.
- Many scams rely on users sending funds to addresses linked to theft, laundering, or fraud, so alerting on them gives a last defensive checkpoint before irreversible transfers. Poisoning is a related vector: a lookalike address planted in the user's history appears familiar, and since users often check only the leading and trailing characters, the wallet must treat it as malicious. Test both via dApp (at wizard/WSR-THRE-002) and direct wallet UI, observing whether the wallet surfaces any warning on each attempt. 1) Attempt to send a transaction to a known malicious address (e.g. the Tornado Cash attacker address). 2) Attempt to send a transaction to a lookalike address that shares its first and last 4 characters with a recipient you have previously sent funds to, but differs in the middle. For both the known malicious address and the poisoned lookalike address (matching the prefix and suffix of a known recipient but never transacted with), whether entered manually in the wallet UI or supplied by a dApp, the wallet warns, flags, or blocks the transaction. The wallet warns, flags, or blocks the transaction for only one of the two addresses. The wallet neither warns, flags, nor blocks the transaction for neither the malicious or poisoned/lookalike addresses. Four screenshots showing the wallet's response in each case: (1) the known malicious address entered in the wallet UI, (2) the lookalike address entered in the wallet UI, (3) the known malicious address supplied by the dApp, and (4) the lookalike address supplied by the dApp. Each screenshot must show whether the wallet flags, blocks, or allows the transaction. The addresses used must be documented. A user unknowingly sends funds to an address associated with scams, theft, or malicious activity. In the poisoning variant, a user sends funds to a lookalike address that mimics a trusted recipient's leading and trailing characters but was planted by an attacker via a dust or zero-value transfer.
Malicious and poisoned address detection
WSR-THRE-002Prevents or alerts users about interactions with a known malicious address or a lookalike (poisoned) address.
Reasoning
Many scams rely on users sending funds to addresses linked to theft, laundering, or fraud, so alerting on them gives a last defensive checkpoint before irreversible transfers. Poisoning is a related vector: a lookalike address planted in the user's history appears familiar, and since users often check only the leading and trailing characters, the wallet must treat it as malicious.
Instructions
Test both via dApp (at wizard/WSR-THRE-002) and direct wallet UI, observing whether the wallet surfaces any warning on each attempt. 1) Attempt to send a transaction to a known malicious address (e.g. the Tornado Cash attacker address). 2) Attempt to send a transaction to a lookalike address that shares its first and last 4 characters with a recipient you have previously sent funds to, but differs in the middle.
Criteria
- Pass For both the known malicious address and the poisoned lookalike address (matching the prefix and suffix of a known recipient but never transacted with), whether entered manually in the wallet UI or supplied by a dApp, the wallet warns, flags, or blocks the transaction.
- Partial The wallet warns, flags, or blocks the transaction for only one of the two addresses.
- Fail The wallet neither warns, flags, nor blocks the transaction for neither the malicious or poisoned/lookalike addresses.
Evidence Requirements
Four screenshots showing the wallet's response in each case: (1) the known malicious address entered in the wallet UI, (2) the lookalike address entered in the wallet UI, (3) the known malicious address supplied by the dApp, and (4) the lookalike address supplied by the dApp. Each screenshot must show whether the wallet flags, blocks, or allows the transaction. The addresses used must be documented.
Attack Scenario
A user unknowingly sends funds to an address associated with scams, theft, or malicious activity. In the poisoning variant, a user sends funds to a lookalike address that mimics a trusted recipient's leading and trailing characters but was planted by an attacker via a dust or zero-value transfer.
- Phishing websites are one of the most common ways users lose funds or sign malicious payloads. Detecting and warning on known phishing domains blocks attacks early, before the user even reaches the approval stage. Visit or attempt to connect to sites included in the [MetaMask phishing list](https://github.com/MetaMask/eth-phishing-detect/blob/b68a72cc477273db3717204d5db699c11980b2f5/src/config.json) and observe whether the wallet warns the user. Note that Chrome also includes built-in phishing protection, which may trigger warnings for some of these sites, though not all. The wallet warns or prevents the user from visiting or connecting to known phishing sites. The wallet neither warns about nor prevents the user from visiting or connecting to known phishing sites. A screenshot showing the wallet's response when connecting to the known phishing site: whether it warns, blocks, or connects without any warning. The sites tested must be documented. A user interacts with a known malicious website that attempts to steal funds or signatures.
Phishing dApp detection
WSR-THRE-003Prevents or alerts users about interactions with a known malicious URL.
Reasoning
Phishing websites are one of the most common ways users lose funds or sign malicious payloads. Detecting and warning on known phishing domains blocks attacks early, before the user even reaches the approval stage.
Instructions
Visit or attempt to connect to sites included in the MetaMask phishing list and observe whether the wallet warns the user. Note that Chrome also includes built-in phishing protection, which may trigger warnings for some of these sites, though not all.
Criteria
- Pass The wallet warns or prevents the user from visiting or connecting to known phishing sites.
- Fail The wallet neither warns about nor prevents the user from visiting or connecting to known phishing sites.
Evidence Requirements
A screenshot showing the wallet's response when connecting to the known phishing site: whether it warns, blocks, or connects without any warning. The sites tested must be documented.
Attack Scenario
A user interacts with a known malicious website that attempts to steal funds or signatures.
- Explaining the scope of access during the connection flow improves informed consent and reduces the chance that users treat connection prompts as harmless. Attempt connecting a dApp to the wallet and inspect the connection dialog for any description of what access the dApp is being granted. The connection dialog clearly discloses that the app gains read access to the account (e.g. addresses, balance, or transaction history) and the ability to request transaction approvals. The connection dialog does not clearly communicate read access to the account or the ability to request transaction approvals. A screenshot showing the connection dialog: whether it discloses read access to the user's account (addresses/balance/activity) and the ability to request transaction approvals. A user grants access to a malicious dApp without understanding the scope of its capabilities, allowing it to later exploit its permissions or any wallet-side vulnerabilities once connected.
dApp access disclosure dialog
WSR-THRE-004Discloses the dApp's read access to the user's account and its ability to request signatures on connection.
Reasoning
Explaining the scope of access during the connection flow improves informed consent and reduces the chance that users treat connection prompts as harmless.
Instructions
Attempt connecting a dApp to the wallet and inspect the connection dialog for any description of what access the dApp is being granted.
Criteria
- Pass The connection dialog clearly discloses that the app gains read access to the account (e.g. addresses, balance, or transaction history) and the ability to request transaction approvals.
- Fail The connection dialog does not clearly communicate read access to the account or the ability to request transaction approvals.
Evidence Requirements
A screenshot showing the connection dialog: whether it discloses read access to the user's account (addresses/balance/activity) and the ability to request transaction approvals.
Attack Scenario
A user grants access to a malicious dApp without understanding the scope of its capabilities, allowing it to later exploit its permissions or any wallet-side vulnerabilities once connected.
- Highlighting unknown recipients creates a useful pause before sending funds or interacting with a new contract that may be malicious or mistyped. Send a transaction to a fresh address (never interacted with and not saved as a contact) both through a dApp and directly through the wallet UI. Observe whether any warning or indicator appears. The wallet displays a warning or indicator when an unknown address is used, whether the address is entered manually or provided by a dApp. The wallet shows no warning or indicator in at least one of the two cases. A screenshot showing the wallet's response when sending to the fresh address: whether it displays a warning or indicator for the unknown address. The address used must be documented. A user sends funds to an unfamiliar or unverified address without recognizing the associated risk.
Unknown address detection
WSR-THRE-005Warns users when interacting with an unknown address.
Reasoning
Highlighting unknown recipients creates a useful pause before sending funds or interacting with a new contract that may be malicious or mistyped.
Instructions
Send a transaction to a fresh address (never interacted with and not saved as a contact) both through a dApp and directly through the wallet UI. Observe whether any warning or indicator appears.
Criteria
- Pass The wallet displays a warning or indicator when an unknown address is used, whether the address is entered manually or provided by a dApp.
- Fail The wallet shows no warning or indicator in at least one of the two cases.
Evidence Requirements
A screenshot showing the wallet's response when sending to the fresh address: whether it displays a warning or indicator for the unknown address. The address used must be documented.
Attack Scenario
A user sends funds to an unfamiliar or unverified address without recognizing the associated risk.
- The origin URL is one of the most important signals for spotting phishing or impersonation attempts. Showing the full, non-truncated URL helps users notice deceptive subdomains, typosquatting, or other visual tricks that could be hidden by truncation. Attempt to connect the wallet to the testing dApp and observe how the origin URL is displayed in the connection dialog. The full dApp origin URL is shown without truncation, or the complete URL can be revealed by hovering over a truncated URL or by widening the connection dialog screen if applicable. The dApp origin URL is truncated and cannot be fully revealed. A screenshot showing how the wallet displays the dApp origin URL in the connection dialog: whether the full URL is shown without truncation. The dApp used must be documented. A phishing site uses deceptive or truncated URLs to impersonate a legitimate service.
Full dApp URL display
WSR-THRE-006Clearly displays the full dApp URL in the connection prompt.
Reasoning
The origin URL is one of the most important signals for spotting phishing or impersonation attempts. Showing the full, non-truncated URL helps users notice deceptive subdomains, typosquatting, or other visual tricks that could be hidden by truncation.
Instructions
Attempt to connect the wallet to the testing dApp and observe how the origin URL is displayed in the connection dialog.
Criteria
- Pass The full dApp origin URL is shown without truncation, or the complete URL can be revealed by hovering over a truncated URL or by widening the connection dialog screen if applicable.
- Fail The dApp origin URL is truncated and cannot be fully revealed.
Evidence Requirements
A screenshot showing how the wallet displays the dApp origin URL in the connection dialog: whether the full URL is shown without truncation. The dApp used must be documented.
Attack Scenario
A phishing site uses deceptive or truncated URLs to impersonate a legitimate service.
- Spam tokens and NFTs are commonly used for phishing, impersonation, and social engineering inside wallet portfolios. Hiding them by default reduces clutter and lowers the chance that users click malicious assets or mistake them for legitimate holdings. Using a test wallet that has received spam NFTs and tokens, open the wallet and observe which assets are displayed by default. Spam tokens or NFTs are hidden by default or the wallet does not display NFTs. The wallet displays spam tokens or NFTs by default. A screenshot showing the assets displayed by default: whether the spam token or NFT appears or is filtered out; if the wallet does not display NFTs at all, a screenshot of the tokens/assets it does show. Any address that was not filtered must be documented. Spam tokens or NFTs trick users into interacting with malicious links, contracts, or social engineering schemes.
Malicious or spam token filtering
WSR-THRE-007Hides malicious tokens and NFTs by default.
Reasoning
Spam tokens and NFTs are commonly used for phishing, impersonation, and social engineering inside wallet portfolios. Hiding them by default reduces clutter and lowers the chance that users click malicious assets or mistake them for legitimate holdings.
Instructions
Using a test wallet that has received spam NFTs and tokens, open the wallet and observe which assets are displayed by default.
Criteria
- Pass Spam tokens or NFTs are hidden by default or the wallet does not display NFTs.
- Fail The wallet displays spam tokens or NFTs by default.
Evidence Requirements
A screenshot showing the assets displayed by default: whether the spam token or NFT appears or is filtered out; if the wallet does not display NFTs at all, a screenshot of the tokens/assets it does show. Any address that was not filtered must be documented.
Attack Scenario
Spam tokens or NFTs trick users into interacting with malicious links, contracts, or social engineering schemes.
FAQ
-
How is the wallet security score calculated?
We calculate the wallet Security Score by assessing each item on our checklist, applying a weight based on its importance, and summing the weighted scores. To guarantee objectivity, multiple web3 security experts contribute input to determine the weights using the AHP framework.
-
How is the wallet evaluation conducted?
Wallets are evaluated using a standardized security checklist and a custom dApp that simulates real Web3 interactions. In-house testers independently assess each wallet and cross-compare results for accuracy.
-
Why are these four categories of wallet security checks important?
The four categories of checks of the wallet security ranking, dApp Permissions, Intent Verification, Threat Prevention, and Physical Access, represent a practical approach to evaluating a wallet’s protection against current real-world threats impacting crypto users.
-
Which is the most secure crypto wallet?
Use Coinspect’s objective and regularly updated Wallet Security Ranking to select the crypto wallet that best aligns with your requirements and risk profile.
This ranking is for informational purposes only. It should not be relied on to provide legal, tax, financial, investment, or other types of advice. Coinspect does not guarantee or warrant the accuracy, completeness, timeliness, suitability, or validity of the information provided and will not be responsible for any claim attributable to reliance on errors, omissions, or other inaccuracies of any part of such information.