Firefly 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 a third-party 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 .

In order to qualify for a perfect rating on wallet address privacy, a wallet must not, by default, allow any third-party 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 third-parties 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 a third-party can learn that two or more of the user's wallet addresses belong to the same user.

A third-party may learn of this correlation either through the wallet software explicitly sending this data (e.g. through analytics), or by requesting data about multiple wallet addresses in bulk, which allows 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.

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 a third-party RPC endpoint 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 a third-party 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 third party.

• ERC-4337 (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 a third party 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 a third-party or proprietary software, even if the user has self-custody of all requisite cryptographic keys to sign such a transaction.

• EIP-7702 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 a third-party 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, and clear explanation of transaction purposes.

A wallet receives a partial rating if it provides some fee information but lacks complete transparency in one or more areas.

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

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

Because 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, 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: [email protected]

• 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 third-party provider in such a way that the address returned by the third-party 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, and that the provider may not progressively learn the user's contacts list by associating its successive resolution queries by IP over time.