Keycard Shell

Wallets are rated based on whether they alert the user about potential scams. This is measured along three scenarios: Does the wallet warn the user when...

• Sending funds to an address the user has never previously sent or received funds from before
• Interacting with a contract that is known to be a scam
• Interacting with a contract that the user has never previously interacted with before
• Interacting with a contract that has only recently been deployed onchain
• Connecting to an app that is known to be a scam

For payments-focused wallets that do not support interacting with arbitrary contracts or external applications, only the payment scenario applies.

Note that wallets should only warn the user about such scenarios, not outright prevent the user from making such transactions, as preventing them entirely would limit the user's ability to have real sovereignty over their own wallet.

Wallets are also rated based on whether these warnings are implemented in a privacy-preserving manner. Specifically:

• When sending funds, does the lookup for past interactions with that address unconditionally reveal the sender and recipient addresses to an external provider other than the wallet's default RPC provider for this chain?

  • Wallets can implement this feature in a privacy-preserving manner by maintaining a local set of known addresses.

• When interacting with a contract, does the check whether that contract is known to be a scam reveal the user's IP address together with the contract address about to be interacted with?

  • This is a privacy leak similar to that of leaking the user's browsing history, as contract addresses are usually closely tied to the application being visited.
  • Wallets can implement this feature in a privacy-preserving manner by maintaining a local, frequently-updated cache of known-scam contract addresses.

• When connecting to an application, does the check whether that application reveal the domain name or URL of the application being used?

  • If leaking full URLs, this is a privacy leak similar to that of leaking the user's browsing history.
  • If leaking domain names only, they must not be linkable to the user's IP address or Ethereum address.
  • Wallets can implement this feature in a privacy-preserving manner by maintaining a local, frequently-updated cache of known-scam contract URLs, or by looking up such a list based on a domain hash prefix like Safe Browsing.

Wallets are evaluated based on key aspects of transaction legibility, with different criteria for software and hardware wallets:

Calldata Decoding/Display: The wallet's ability to decode and display calldata for various transaction types, including:

• Simple transfers
• Token approvals
• DeFi interactions
• Complex nested transactions

Transaction Details Display: The wallet's ability to display essential transaction information:

• Gas limit and/or gas price
• Transaction nonce
• Sender address (from)
• Recipient address (to)
• Chain/network identifier
• Transaction value/amount

Software Wallet Specific Requirements: For software wallets, calldata must be displayed in multiple formats:

• Raw hex format: Users can view the raw hexadecimal calldata
• Formatted output: Users can view decoded, human-readable calldata
• Copy to clipboard: Users can copy the calldata directly for verification

Hardware Wallet Specific Requirements: For hardware wallets, the signature/transaction information must be visible on the hardware wallet device itself. Any data shown on a software wallet component is ignored for hardware wallet ratings.

Hardware wallets must also provide data extraction methods to allow users to independently verify transaction data:

• Visual display: Users can view the data on the hardware wallet screen
• QR code: Users can scan a QR code displayed on the device to extract data
• Hashes: Users can compare hashes displayed on the device to verify data

Rating Criteria:

For software wallets:

• A wallet receives a passing rating if it displays calldata in all three formats (raw hex, formatted, copyable) and displays all essential transaction details.
• A wallet receives a partial rating if it has some combination of these features, but not all at the full level.
• A wallet receives a failing rating if it lacks calldata display capabilities or does not display essential transaction details.

For hardware wallets:

• A wallet receives a passing rating if it supports decoding of complex nested transactions, displays all essential transaction details on the device, and provides comprehensive data extraction methods (QR codes and hashes, in addition to visual display).
• A wallet receives a partial rating if it has some combination of these features (decoding support, transaction details display, or data extraction methods), but not all at the full level.
• A wallet receives a failing rating if it lacks calldata decoding support, does not display essential transaction details on the device, and provides no effective data extraction methods.

Wallets are assessed based on the passkey verification library they use:

1. Pass (Best): Using the most gas-efficient and well-audited library like:

   • Smooth Crypto Lib
   • Daimo P256 verifier
   • OpenZeppelin P256 verifier
   • WebAuthn.sol which falls back to Fresh Crypto Lib

2. Partial: Using libraries that work but are less optimal:

   • Fresh Crypto Lib
   • Other less common verification libraries

3. Fail: Not implementing passkeys or using a non-recognized library.

Wallets that don't support smart contract accounts or are hardware wallets are exempt from this rating.

Hardware wallets are assessed based on the comprehensiveness of their bug bounty program:

1. Pass (Best): Implements a comprehensive bug bounty program with:

   • Active program accepting vulnerability reports
   • Full coverage of hardware, firmware, and software components
   • Competitive financial rewards based on severity
   • Responsive disclosure process
   • Transparent communication about fixes
   • Clear upgrade paths for users when needed

2. Partial: Implements a basic bug bounty program with limitations:

   • May have limited coverage (only certain components)
   • Smaller or unclear rewards
   • Basic vulnerability disclosure policy without formal rewards
   • Slower response times
   • Unclear upgrade paths for users
   • Inactive or temporarily paused programs

3. Fail: No bug bounty program or security update process:

   • No formal process for reporting vulnerabilities
   • No incentives for responsible disclosure
   • No clear path for providing security updates
   • Known critical vulnerabilities remain unaddressed

Evaluated based on:

• Factory Operational Security: Availability and verification (audits, certifications) of documentation detailing security practices during manufacturing.

• Tamper Evidence: Effectiveness of physical seals or mechanisms to detect package tampering.

• Hardware Verification: Ease of verifying the received hardware against a Bill of Materials (BOM) or reference design.

• Tamper Resistance: Physical device protections (e.g., security mesh) against unauthorized modification.

• Genuine Check: Availability and reliability of software/hardware mechanisms to verify device authenticity before and during use.

• Anti-Kleptography: Measures to prevent cryptographic keys or randomness from being subtly leaked during operations.

Evaluated based on several factors:

• Update Security: Protection against silent/forced updates, authentication requirements for updates, and possibility of downgrades.
• Source Code Openness: Availability and licensing of firmware source code (full or partial), and isolation between open/closed parts.
• Build Verifiability: Ability to reproduce firmware builds from source and compare against official binaries (reproducible builds).
• Runtime Integrity: Mechanisms to check the authenticity of the code running on the device.
• Custom Firmware: Support for users loading custom firmware and its impact on device security/integrity.

Evaluated based on the following criteria (mapped to 16 internal sub-criteria):

• Human readable addresses: Are raw addresses easy to review? Is the HWW displaying the ENS linked to an address if available?

• Human readable identification of well known contracts: Is the HWW displaying information about well known contracts? How reliable is it (considering rogue proxies)? How independently chosen is it?

• Possible to review all TX parameters raw: Are all raw parameters from a TX displayed? Easy to review (calldata…)?

• Human readable review of TX parameters: Is the HWW displaying a human readable version of some/all parameters? Are there restrictions?

• Coverage of human readable TX parameters reviewable: Describe how extensive/limited the display of human readable TX parameters is. Is it using independent data? How frequently is it collected and updated?

• Easy to extend human readable TX parameters: Is it possible for the user to add support to get a human readable display of an unknown TX parameter? Describe the process.

• Expert mode for TX review: Is there a mode available to sign the transaction quickly while displaying enough information to verify the TX on a secondary trusted computer?

• Possible to review all EIP 712 parameters raw: Are all raw parameters from an EIP 712 message displayed? Easy to review (structures, byte arrays,…)?

• Human readable review of EIP 712 parameters: Is the HWW displaying a human readable version of some/all parameters? Are there restrictions?

• Coverage of human readable EIP 712 parameters reviewable: Describe how extensive/limited the display of human readable EIP 712 message parameters is. Is it using independent data? How frequently is it collected and updated?

• Easy to extend human readable EIP 712 parameters: Is it possible for the user to add support to get a human readable display of an unknown parameter in an EIP 712 message? Describe the process.

• Expert mode for EIP 712 review: Is there a mode available to sign an EIP 712 message quickly while displaying enough information to verify the EIP 712 message on a secondary trusted computer?

• Risk analysis support: Is the HWW displaying a risk evaluation / threat warning to the user when signing transactions or messages? Describe how the evaluation works.

• Risk analysis without phoning home possible: Is it possible to run the risk analysis process without contacting the HWW manufacturer? Describe which external services are involved and if the full TX/message data could be recovered by any party.

• Fully local risk analysis possible: Is it possible to run the risk analysis evaluation locally? Describe the components provided by the HWW provider and the setup.

• TX simulation support: Is the HWW displaying high level simulation results (balance difference…) to the user when signing transactions or messages? Describe how the evaluation works.

• TX simulation without phoning home possible: Is it possible to run the simulation process without contacting the HWW manufacturer? Describe which external services are involved and if the full TX/message data could be recovered by any party.

• Fully local TX simulation possible: Is it possible to run the simulation locally? Describe the components provided by the HWW provider and the setup.

Rating thresholds: PASS if >=11/16 criteria pass, PARTIAL if >=6/16 pass, else FAIL.

Wallets are evaluated based on their implementation of guardian-based recovery.

To qualify, wallets must implement at least one form of guardian-based recovery. They must also ensure that whatever option the user picks (as allowed by the wallet's onboarding flow), all the following prongs are satisfied:

• If the user loses access to their device (which can include both their wallet's software and their passkeys), can they still recover their account on a separate device?
• If any single external provider goes out of business, can the user still recover their account?
• If any single external provider is compromised or turns evil, can the user's account be taken over by that provider?

This attribute explicitly does not consider the scenario of the user's own self-custody key being compromised, as defenses against such scenarios are covered by a separate attribute in the Self-Sovereignty category.

In order to qualify for a perfect rating on wallet address privacy, a wallet must not, by default, allow any external entity to link your wallet address to any personal information.

As Walletbeat only considers the wallet's default behavior, wallets may still choose to offer features that allow external providers to link wallet addresses with personal information, so long as this is done with explicit user opt-in.

To determine this, Walletbeat looks at the network requests made by wallets in their default configuration, and the contents of such requests. If a request contains the user's wallet address, we look at whether it also contains any other personal information, such as the user's name, pseudonym, email address, phone number, CEX account information, etc.

Additionally, if such a request is not proxied, then it inherently reveals the user's IP address and ties it with the user's wallet address, which is also personal information.

Wallets are assessed based on whether an external provider can learn that two or more of the user's wallet addresses belong to the same user.

An external provider may learn of this correlation either through:

• The wallet software explicitly sending this data (e.g. through analytics)
• Requesting data about multiple wallet addresses in bulk, allowing the receiving endpoint to learn that all of these addresses belong to the same user. Similar correlations are also possible by IP and/or time-based correlation of requests that each contain one wallet address.

In order to prevent this information from being revealed, wallets can use a variety of strategies:

• Wallets may offer the user to only have one active wallet address at a time, and only ever makes requests about the active wallet address. The user is expected to not change their active address often. The wallet should also ensure that any account-switching widget does not cause bulk/simultaneous requests about multiple addresses to the same endpoint, such as for refreshing balances. Note that this scheme, while simple to implement, is incompatible with stealth addresses. This is because stealth addresses inherently require the user to simultaneously manage a range of addresses.
• Wallets may look up information about multiple addresses by splitting up the requests such that each request only contains one address, then sending these requests over different proxy circuits in a manner that staggers the requests over time. This ensures that the receiving endpoint cannot correlate addressed based on timing or IP address.
• Wallets may distribute requests across multiple RPC endpoints owned by separate entities for each wallet address, preventing each entity from learning more than one wallet address.

In order to get a passing rating, wallets must ensure that sending Ether or ERC-20 tokens to other addresses comes with privacy guarantees by default. In addition, they must ensure that users can receive and spend such tokens privately.

"Privately" here means that other than the wallet user, no single entity (including any external provider) can infer or reconstruct the user's transaction history.

Walletbeat currently recognizes the following privacy-preserving token transfer solutions:

• ERC-5564 Stealth Addresses
• Tornado Cash Nova
• Privacy Pools

Evaluated based on:

• Phoning Home: Whether the device contacts manufacturer servers during setup, operation, or updates, and if these connections are necessary.

• Inspectability: Ability to monitor and understand data exchanged if the device does phone home.

• Wireless Privacy: Protection of data transmitted over wireless connections (e.g., BLE, WiFi) against local attackers.

In order to qualify for this attribute, wallets must:

• Allow the user to configure the L1 RPC endpoint to a self-hosted node before any request is made to that endpoint.
• Support basic functions (account creation/import, balance lookups, token transfers) using nothing but the self-hosted node (no external services, no non-Ethereum-API calls), and whether

Wallets are rated based on whether accounts created within can be exported out of the wallet and imported into another, without requiring permission from the exporter wallet provider.

For EOA wallets based on private keys, this is relatively straightforward to determine. However, for more complex situations such as multisig wallets, Walletbeat considers whether such wallets can be made fully self-custodial, and whether assets and tokens can be permissionlessly transferred out of the wallet.

Specifically:

• EOA wallets are rated based on the exportability of their private key material, and on whether such private key material is derived using the following standards:

  • BIP-39 for deriving a binary seed from a seed phrase.
  • BIP-32 for deterministic hierarchical key derivation from the binary seed.
  • BIP-44 as a standard when deriving hierarchical private keys.

• MPC wallets are rated based on whether the user has a sufficient shares of the underlying key to have full control over the wallet in a self-custodial manner. Additionally, there must be a way for the user to generate a transaction (Walletbeat uses a token transfer out of the wallet as the litmus transaction for this) without reliance on an external API or proprietary application. The combination of these factors ensures that the wallet remains self-custodial and that the account cannot be frozen in-place due to an uncooperative external provider.

• ERC-4337: Account Abstraction for smart contract wallets (smart contract wallets) are rated based on the level of control the user has over their account according to the smart contract's control logic that the wallet uses. The user must be in control of who controls their account by default, and be able to permissionlessly create asset transfer transactions.
  Specifically, the rating considers:

  • Whether the user has the ability to change the cryptographic keys used to control the account in general, in a manner that does not involve relying on an external provider or proprietary software.
  • Whether the smart contract wallet's default configuration starts out with the user having self-custody of their account, for example by having a majority of the key shares in self-custody in a multisig wallet.
  • Whether the generation of a token transfer transaction requires relying on an external provider or proprietary software, even if the user has self-custody of all requisite cryptographic keys to sign such a transaction.

• EIP-7702: Account Abstraction via smart contract authority delegation are not yet rated on account portability and will show up as "Unrated".

If a wallet supports multiple types of accounts, the rating for the account type it supports that is least portable takes precedence. This makes the final rating act as an effective "floor" across the account types the wallet supports.

If a wallet supports multiple types of accounts and all of them have the same level of portability, the account type that takes precedence is the one that the wallet offers the user to create by default.

Wallets are rated based on whether users need to trust any intermediary in order to withdraw their funds from L2s.

This fundamentally requires two major features:

• A wallet must support the creation of an L1 transaction which forces the L2 to withdraw user funds back to the L1. This message is typically posted as an L1 transaction which forces the L2 sequencing process to take it into account.
• Since L2 force-withdrawal transactions require an L1 transaction, the wallet must also be able to get this transaction included without relying on an external service to broadcast this transaction for block inclusion. Therefore, the wallet must also support either participating in Ethereum's L1 gossip network, or (for environments that do not support this such as browser extension wallets) support broadcasting L1 transactions through a user's self-hosted Ethereum node.

With these two features in place, users can withdraw their L2 funds without trusting intermediaries.

Walletbeat currently only considers OP Stack chains and Arbitrum One for this evaluation, but more L2 chains may be added as support for force-withdrawal transaction becomes feasible for them.

Wallets are evaluated based on whether there is any mechanism by which any entity other than the user may sign or approve transactions on behalf of the user's account, or can transfer ownership of the account away from the user. This includes features like seed phrase backups where the wallet developer gets to learn the user's seed phrase, or other account recovery features that let the wallet developer unilaterally recover the user's account.

Fully-custodial wallets (i.e. wallets where the signing key material resides entirely on external services) are also not self-sovereign (aka ruggable) by definition.

Features that allow the user to pre-approve certain types of transactions ahead of time are treated as maintaining self-sovereignty, so long as the user controls their limits explicitly: time-bound, amount-bound, destination/purpose-bound, etc.

Wallets are assessed based whether the license of their source code meets the Open Source Initiative's definition of open source.

Wallets are assessed based on how sustainable, transparent, and user-aligned their funding mechanisms are.

Wallets are typically funded by one or more of the following methods:

• Self-funding from developers
• Seeking donations from users
• Seeking grants from foundations
• Venture capital funding
• Charging fees on convenience functions (e.g. swapping and bridging tokens)
• Governance tokens
• Commemorative NFT sales

Walletbeat looks at each funding source of funding and verifies whether it is done transparently and in a user-aligned manner. In this context, "user alignment" refers to whether a source of funding grows as a function of the user's own goals, rather than being uncorrelated or anti-correlated. For example, funding acquired through hidden swap fees or governance token sales with undisclosed insider token allocations are not user-aligned. Funding acquired through transparent swap fees, user donations, or ecosystem grants are user-aligned.

In order to pass this criterion, wallets must have at least one source of funding, and all of their sources of funding must be transparent to users. Additionally, if the wallet is funded from multiple sources and some of these sources are not user-aligned, the public must be able to determine the proportion of each such funding source to the wallet's overall revenue. Depending on the funding mechanism, this can be done through publication of a revenue breakdown page, public regulatory filings, or token allocation and vesting disclosures.

Wallets are evaluated based on how transparently they display transaction fees and transaction purposes to users.

A wallet receives a passing rating if it provides comprehensive fee information, including detailed breakdowns of network fees, clear disclosure of any additional wallet fees. Fees may be aggregated down to one number, but a breakdown must be available to the user within a single click.

A wallet receives a partial rating if it provides an aggregate fee but does not let the user get a detailed breakdown.

A wallet fails this attribute if it provides minimal or no fee information before transaction confirmation.

Various transaction types are tested: Ether and ERC-20 transfers on L1, built-in swaps or bridging transactions, DeFi transactions, private transactions if supported. If a wallet displays fees differently depending on the type of transaction, the transaction type with the least clear display level is taken into consideration for the purpose of this attribute.

Evaluated based on an aggregate of factors:

• Product Originality: Degree of original design versus reliance on not-in-house components.

• Availability & Support: History of product availability, risk of discontinuation, and perceived ability to honor warranty/support.

• Vulnerability History: Track record of security vulnerabilities, their severity, and the transparency/quality of documentation and fixes.

• Bug Bounty Program: Scope and rewards of the manufacturer's bug bounty program compared to industry standards.

Wallets are rated based on whether they make use of EIP-7702: Account Abstraction via smart contract authority delegation transactions (for EOA or MPC wallets), or if they support ERC-4337: Account Abstraction for smart contract wallets transactions (for smart contract wallets).

The user experience benefits of these enhancements are still in-flight and are expected to develop as these standards mature and are built on top of. As such, Walletbeat does not currently consider which improvements wallets provide for their users as a result of these new capabilities. However, it is expected that a future version of this attribute would look at such improvements. For example: to verify that users are able to update the signing authority of their wallets to a quantum-safe signature scheme.

Wallets are rated based on the types of addresses they support sending funds to.

Specifically, Walletbeat recognizes the following destination address formats. Wallets must be able to resolve at least one of them to fulfill this attribute:

• Plain ENS addresses (username.eth) without destination chain information
• ERC-7828 Chain-specific addresses using ENS: user@l2chain.eth
• ERC-7831 Multi-chain addresses: user.eth:l2chain

Additionally, the mechanism used to perform the resolution must either:

• Be done using onchain data and reusing the wallet's common chain interaction client, inheriting its verifiability (e.g. via light client) and privacy properties.
• OR be done using an offchain external provider in such a way that the address returned by the external provider is verifiable, and without revealing the user's IP address to the provider. This ensures that:
  • The wallet cannot be tricked into sending funds to an attacker compromising the offchain provider's responses
  • The provider may not progressively learn the user's contacts list by associating its successive resolution queries by IP over time.

For addresses that require an offchain lookup (e.g. ENS names using offchain resolvers with CCIP-Read), only the portion of the work necessary to arrive at the conclusion that an offchain lookup is necessary is considered. In other words, wallets must verify that the CCIP-Read OffchainLookup details are as claimed and then perform the CCIP-Read themselves, rather than trust an offchain provider to do so on their behalf.

Evaluated based on independent wallet compatibility and supplier independence.

Hardware wallets are evaluated based on the reliability, openness, and breadth of their best app connection method.

A wallet receives a passing rating if it can connect to any app using verifiable code or open standards.

A wallet receives a partial rating if it can connect to apps but requires trusting unverifiable code (proprietary closed-source), or if it can only connect to some apps even when using verifiable code or open standards.

A hardware wallet fails this attribute if it cannot connect to apps at all, severely limiting its utility.

Evaluated based on:

• Physical Durability: Resistance to drops and environmental factors.

• MTBF Documentation: Availability and reliability of Mean Time Between Failures data.

• Repairability: Ease of repair, availability of parts and documentation, and potential security implications of repairs.

• Battery: Presence, replaceability, and device functionality if the battery dies.

• Warranty: Length of warranty period, coverage limitations, and possibility of extension.