Gem Wallet

Wallets are evaluated by their track record of published security audits.

Walletbeat examines the set of published security audits of the wallet. To qualify, a security audit must be publicly available, and must be from a security auditor that has a traceable corporate entity distinct from the wallet's own development team.

Security audits typically come with one or more security flaws found, categorized by level of severity. Definitions of severity vary across auditors, but generally anything "medium" or above is worth paying attention to.

A wallet gets a passing rating if it has been audited at least once within the last 365 days, and that all medium-or-higher severity flaws that were found across all audits (including older ones) are addressed.

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 whether or not they integrate a light client for verification of Ethereum L1 state.

Note: Walletbeat currently only considers L1 chain state verification for this criterion, not L2s. This is because L2 state verification is still in its infancy. As L2 technology matures, Walletbeat will also start requiring wallets to verify L2 chain state.

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 evaluated based on whether it is possible to use them in conjunction with any physically-separate hardware wallet. This means the software wallet must provide the same level of functionality as when not using a hardware wallet, and the private key must never leave the hardware wallet.

Wallets that require the use of a separate software component (e.g. WalletConnect to an external desktop application that does the actual interfacing with the hardware device) in order to use the hardware wallet get a partial rating. The need for this additional software component means the user has to do more work to get the hardware wallet working, which decreases the likelihood that users will actually do so in practice.

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.

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

Wallets are assessed based on whether they make it easy for the user to create a distinct account for each new app they use, and whether this is the default choice.

When connecting to apps that the user previously connected to, the wallet must use the address(es) that were last used for this specific app.

Wallets that do not support connecting to apps are exempt from this attribute.

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.

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.

Wallets are rated based on how much of the complexity involved in dealing with multiple chains is abstracted away from users, while keeping risks and fees transparent.

To get a passing rating, wallets must be cross-chain aware in how they display account value and individual token balances:

• When displaying the user account's total value, this value should sum up the user's valuations across all chains the wallet supports by default.
• When displaying a specific token's balance, the balance should reflect the user's total balance for this token across all wallet-supported chains (and on which the token exists). For rating purposes, Walletbeat looks specifically at Ether and USDT balances.

In addition, wallets must make it easy for users to move their assets across chains when needed. To get a passing rating, wallets must provide a built-in bridging feature.

• This bridging feature must explain the risks involved in bridging assets across chains. Our friends at L2BEAT do a fantastic job documenting this, but wallet developers also have a duty to explain these risks to their users.
• For bridge operations where the net fee is larger than 1bps, the wallet must display the fee breakdown by default.
• When the user attempts to send tokens to an address on a chain where the user's balance is insufficient, but for which they have sufficient tokens on another chain, the wallet should automatically propose to bridge them.

Smart account types such as ERC-4337: Account Abstraction for smart contract wallets and EIP-7702: Account Abstraction via smart contract authority delegation unlock the ability to perform multiple operations as a single transaction. This is exposed to applications through EIP-5792 Wallet Call API.

To qualify for a passing rating, the wallet must:

• Support at least one type of smart account.
• Implement EIP-5792 Wallet Call API.
• Support atomic transaction bundles, as per the atomic capability declared in wallet_getCapabilities.

Wallets are evaluated based on whether they directly integrate with hardware wallets from a plurality of major hardware wallet manufacturers.

A wallet receives a passing rating if it supports hardware wallets from at least 3 major hardware wallet manufacturers:

• Ledger
• Trezor
• Keystone
• GridPlus
• imKey

Hardware wallets accessible only through WalletConnect are not counted, as they require relying on WalletConnect and external software beyond the wallet itself in order to function.

A wallet receives a partial rating if it supports only two such hardware wallets manufacturers (without relying on WalletConnect or external software).

A wallet fails this attribute if it only directly supports hardware wallets from a single manufacturer.

Wallets that do not directly support hardware wallets at all are exempt, as this check is only about hardware wallet interoperability. General direct hardware wallet support is also part of Walletbeat's security criteria as a separate attribute.