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. Passes if the wallet blocks the transaction or displays a checksum warning before the transaction proceeds. 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
Passes if the wallet blocks the transaction or displays a checksum warning before the transaction proceeds.
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 details screen. Also browse the wallet's transaction history. Observe whether addresses, contract addresses, and transaction hashes are displayed as clickable links to a block explorer. Passes if addresses, contract addresses and transaction hashes are clickable and open a block explorer both when attempting to send a transaction and querying the wallet history. If just one of these is provided, it's given half the points. A malicious interface misrepresents transaction or address details, preventing independent verification by the user
Links to blockchain explorers
WSR-VERI-002Consistently provides clickable links to block explorers for all key blockchain identifiers.
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 details screen. Also browse the wallet's transaction history. Observe whether addresses, contract addresses, and transaction hashes are displayed as clickable links to a block explorer.
Criteria
Passes if addresses, contract addresses and transaction hashes are clickable and open a block explorer both when attempting to send a transaction and querying the wallet history. If just one of these is provided, it's given half the points.
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. Passes if the wallet shows the expected inputs and outputs from the execution of such transaction effects before signing. 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
Passes if the wallet shows the expected inputs and outputs from the execution of such transaction effects before signing.
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. Passes if the wallet renders structured, human-readable signing details rather than raw JSON. 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
Passes if the wallet renders structured, human-readable signing details rather than raw JSON.
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. Passes if the wallet clearly displays the token, spender and approved amount. 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
Passes if the wallet clearly displays the token, spender and approved amount.
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. Passes if all signing data is visible (including the `verifyingContract` for EIP-712), scrollable and not truncated. 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
Passes if all signing data is visible (including the
verifyingContractfor EIP-712), scrollable and not truncated.Attack Scenario
A malicious dApp hides or obfuscates critical parts of a signing payload, leading the user to approve unintended or harmful data
- 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. Passes if the sign button remains disabled until the user scrolls through the entire message. 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
Passes if the sign button remains disabled until the user scrolls through the entire message.
Attack Scenario
A malicious dApp relies on users blindly approving signature requests without reviewing their contents, leading to unintended authorizations
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).
7 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. Passes if the wallet limits clipboard exposure (1 min max), warns about clipboard risks, or prevents copying. On mobile, it should prevent or warn users about screenshot risks. 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
Passes if the wallet limits clipboard exposure (1 min max), warns about clipboard risks, or prevents copying. On mobile, it should prevent or warn users about screenshot risks.
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. Passes if the wallet supports biometrics; if it allows easy-to-guess passwords/pins, make sure that it rate limits attempts after the 5th one. 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
WSR-PHYS-002Uses strong authentication, such as resistance to trivial or commonly-used passwords. Including biometrics and rate limiting in mobile.
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
Passes if the wallet supports biometrics; if it allows easy-to-guess passwords/pins, make sure that it rate limits attempts after the 5th one.
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
- 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. Passes if the wallet clearly communicates these risks and displays a warning to the user before revealing the secrets. 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
Passes if the wallet clearly communicates these risks and displays a warning to the user before revealing the secrets.
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. Passes if the wallet includes a manual lock control. 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
Passes if the wallet includes a manual lock control.
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. Passes if authentication is required before displaying mnemonics or private keys. 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
Passes if authentication is required before displaying mnemonics or private keys.
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. Passes if the wallet auto-locks after inactivity (1 minute or less by default), when the device locks, or when the app moves to the background. 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
Passes if the wallet auto-locks after inactivity (1 minute or less by default), when the device locks, or when the app moves to the background.
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. Passes if the wallet auto-locks after inactivity within 20 minutes. 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
Passes if the wallet auto-locks after inactivity within 20 minutes.
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. Passes if verified dApps are clearly distinguished from unknown ones. 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
Passes if verified dApps are clearly distinguished from unknown ones.
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 already known to be linked to theft, laundering, or fraud. Alerting on such addresses gives users a last defensive checkpoint before irreversible on-chain transfers. In the testing dApp, at `/scamtest`, click “Switch to Scam Address” and attempt to send the transaction to the pre-filled address **0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9** (the Tornado Cash attacker address). Test both via dApp and direct wallet UI. Observe whether the wallet surfaces any warning. Passes if the wallet warns or flags the malicious address or blocks the transaction. A user unknowingly sends funds to an address associated with scams, theft, or malicious activity
Malicious address detection
WSR-THRE-002Prevents or alerts users about interactions with a known malicious address.
Reasoning
Many scams rely on users sending funds to addresses already known to be linked to theft, laundering, or fraud. Alerting on such addresses gives users a last defensive checkpoint before irreversible on-chain transfers.
Instructions
In the testing dApp, at
/scamtest, click “Switch to Scam Address” and attempt to send the transaction to the pre-filled address **0x592340957eBC9e4Afb0E9Af221d06fDDDF789de9** (the Tornado Cash attacker address). Test both via dApp and direct wallet UI. Observe whether the wallet surfaces any warning.Criteria
Passes if the wallet warns or flags the malicious address or blocks the transaction.
Attack Scenario
A user unknowingly sends funds to an address associated with scams, theft, or malicious activity
- 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. Passes if the wallet warns or prevents the user from visiting or connecting to known phishing sites. 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
Passes if the wallet warns or prevents the user from visiting or connecting to known phishing sites.
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. Passes if the connection dialog clearly mentions the ability to view the user's balance and activity, as well as 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-004Informs dApp access to balances, history, and signing requests 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
Passes if the connection dialog clearly mentions the ability to view the user's balance and activity, as well as 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. Passes if the wallet shows a warning or indicator for unknown addresses. 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
Passes if the wallet shows a warning or indicator for unknown addresses.
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. Passes if the full dApp origin URL is shown without truncation. 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
Passes if the full dApp origin URL is shown without truncation.
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. Passes if spam tokens or NFTs are hidden by default or the wallet does not display NFTs. 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
Passes if spam tokens or NFTs are hidden by default or the wallet does not display NFTs.
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.