Cypherock Wallet

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.

Hardware wallets are evaluated based on their implementation of app signing capabilities.

A hardware wallet receives a passing rating if it implements full app signing, where all transaction details are clearly displayed on the hardware wallet screen for verification before signing. This includes support for standard transactions, ERC-20 token transfers, 712 messages and complex contract interactions.

The hardware should be able to display clearly all transaction types on Safe, Aave and Uniswap. To do so the hardware MUST be able to connect directly to the application or allow the user to use at least two different software wallets independent from the hardware manufacturer.

A hardware wallet receives a partial rating if it implements app signing but with limitations, such as not displaying all transaction details or not supporting app signing for all transaction types. Or if the hardware supports only one independent software wallet. Or if the hardware supports only 1/3 of the apps.

A hardware wallet fails this attribute if it doesn't properly implement app signing functionality, requiring users to trust the connected software wallet without independent verification.

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

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

   • Clear scope and guidelines
   • Competitive rewards based on severity
   • Responsive disclosure process
   • Transparent communication about fixes
   • Offers upgrade paths for users when needed

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

   • Basic vulnerability disclosure policy but no formal rewards
   • Limited scope or small rewards
   • Slower response times
   • Unclear upgrade paths for users

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:

• Master Secret Generation: Use of interoperable, well-documented standards for seed generation.
• Key Secrecy: Resistance against key extraction or recovery by the external providers. Ensuring keys are not transmitted insecurely.
• Proprietary Mechanisms: Security implications of any non-standard key handling or backup procedures.
• Physical Attack Resistance: Protection against passive (side-channel analysis) and active (glitching) physical attacks.

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.

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.

Wallets are rated based on whether they allow the user to configure the RPC endpoint used for Ethereum mainnet, and whether such configuration is possible before any request is made to an external RPC provider by default.

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 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:

• 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

Wallets must resolve either ERC-7828 or ERC-7831 addresses to fulfill this attribute. Support for plain ENS addresses alone earns a partial rating.

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

• Be done using onchain data and reusing the wallet's common chain interaction client, inheriting its verifiability (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.

Evaluated based on independent wallet compatibility and supplier independence.

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.