Frame
Frame...
Platforms: as a desktop application and as a browser extension. The ratings below vary depending on the version. Select a version to see version-specific ratings.
Security
Security audits
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Wallets are high-stakes piece of software as they deal with sensitive user data and funds. To ensure that their code is secure, industry best practices involve regularly submitting the wallet's source code for audit by an independent security auditor. These companies specialize in reviewing source code with an eye for security vulnerabilities. They report their findings to the wallet's development team for consideration, pointing out both flaws and potential security improvements.
These security audits matter in order to ensure the wallet's source code is secure, and remains that way over time. Wallet development teams typically publish such audits so that wallet users can feel safer knowing that the wallet's source code was independently audited.
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.
A wallet would get a passing rating if...
It was audited within the last year, and all flaws of severity "medium" or higher are addressed.
A wallet would get a partial rating in any of these cases:
It was audited over a year ago, and has not been audited since.
It was audited within the last year, and there remains at least one unaddressed security flaw of severity "medium" or higher.
A wallet would get a failing rating in any of these cases:
It was never audited by a third-party security auditor.
It was audited over a year ago, has not been audited since, and there remains at least one unaddressed security flaw of severity "medium" or higher.
Scam prevention
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Transactions in Ethereum are very difficult to reverse, and there is no shortage of scams. Wallets have a role to play in helping users avoid known scams ahead of the user making the transaction.
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 .
A few examples
A wallet would get a failing rating in any of these cases:
It does not implement any form of scam alerting.
It leaks visited URLs to a third-party as part of its malicious app warning feature.
A wallet would get a partial rating in any of these cases:
It implements some but not all of the required scam warning features.
It implements all required scam warning features, but not in a privacy-preserving manner.
A wallet would get a passing rating if...
It implements all required scam warning features in a privacy-preserving manner.
Chain verification
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
"Trust but verify" is one of the foundational principles of blockchains. It refers to the ability for participants to verify that the chain data is valid when they interact with it.
Without such verification, users rely on trusted third-parties to tell them what the state of the blockchain is, similar to the web2 trust model. This allows such third-parties to trick wallet users into signing transactions that do not end up having the user's intended effect.
To avoid this, Ethereum was designed to be verifiable on commodity hardware. Using a light client , this verification is possible without having to download the entire blockchain.
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.
A wallet would get a passing rating if...
It verifies the integrity of the Ethereum L1 chain using a light client .
A wallet would get a failing rating if...
It does not verify the integrity of the Ethereum L1 chain, relying on the honesty of third-party RPC providers instead.
Hardware wallet support
Frame supports a comprehensive range of hardware wallets, including the most popular options. Hardware wallets provide an additional layer of security by keeping private keys offline.
Hardware wallets are physical devices that store a user's private keys offline, providing an additional layer of security against online threats. By keeping private keys isolated from internet-connected devices, hardware wallets protect users from malware, phishing attacks, and other security vulnerabilities that could compromise their funds.
When a software wallet supports hardware wallet integration, users can enjoy the convenience and features of the software wallet while maintaining the security benefits of keeping their private keys offline. This combination offers the best of both worlds: a user-friendly interface with enhanced security.
Supporting multiple hardware wallet options gives users flexibility to choose the hardware solution that best fits their needs and preferences.
Wallets are evaluated based on their support for popular hardware wallet devices.
A wallet receives a passing rating if it supports all four major hardware wallet brands: Ledger, Trezor, Keystone, and GridPlus, allowing users to perform all essential operations using these hardware wallets.
A wallet receives a partial rating if it supports at least one hardware wallet brand but doesn't support all four major brands mentioned above.
A wallet fails this attribute if it doesn't support any hardware wallets.
A wallet would get a passing rating if...
It supports all four major hardware wallet brands: Ledger, Trezor, Keystone, and GridPlus, with full functionality.
A wallet would get a partial rating if...
It supports at least one hardware wallet brand, but not multiple major brands or has limited functionality.
A wallet would get a failing rating if...
It does not support any hardware wallets.
Hardware wallet integration
Frame supports hardware wallet integration with Ledger, Trezor, Keystone, GridPlus, Other hardware wallets, but with limited functionality. It lacks full EIP-712 clear signing support when connecting to important DeFi applications like Safe or Aave. This means users cannot fully verify complex transaction details on their hardware device screens, which could potentially compromise security for advanced DeFi operations.
Software wallets that integrate well with hardware wallets provide users with the best of both worlds: the convenience and feature-rich interface of software wallets, combined with the security of hardware key storage and transaction signing.
EIP-712 clear signing is particularly important for DeFi applications like Safe (formerly Gnosis Safe) and Aave, where complex transaction parameters need to be verified to prevent attacks like blind signing exploits or transaction parameter manipulation.
When a software wallet properly integrates with hardware wallets for clear signing on these platforms, users can confidently verify exactly what they're approving on their hardware device screen, even for complex smart contract interactions.
Without proper integration, users may be forced to blind sign transactions or use less secure methods, significantly increasing security risks when interacting with DeFi protocols.
Software wallets are evaluated based on their integration with hardware wallets, particularly focusing on EIP-712 clear signing support with major DeFi platforms like Safe and Aave.
A wallet receives a passing rating if it implements full EIP-712 clear signing support with at least two different hardware wallet brands (e.g., Ledger, Trezor) on both Safe and Aave. This means users can clearly verify all transaction details on their hardware wallet screens when interacting with these platforms.
A wallet receives a partial rating if it implements EIP-712 clear signing but with limitations, such as supporting only one hardware wallet brand or only one of the major DeFi platforms (either Safe or Aave but not both).
A wallet fails this attribute if it either doesn't support hardware wallets at all or supports hardware wallets but without implementing proper EIP-712 clear signing for DeFi applications.
A wallet would get a passing rating if...
It implements full EIP-712 clear signing support with at least two different hardware wallet brands on both Safe and Aave platforms.
A wallet would get a partial rating in any of these cases:
It implements EIP-712 clear signing support on either Safe or Aave (but not both), or supports only one hardware wallet brand for these integrations.
It supports hardware wallet integration but lacks proper EIP-712 clear signing support for major DeFi platforms like Safe and Aave.
A wallet would get a failing rating if...
It does not support hardware wallet integration at all.
Frame should implement full EIP-712 clear signing support for transactions with Safe, Aave, and other major DeFi platforms. This would ensure users can verify all transaction details on their hardware devices before signing. Frame should make sure to support the lastest hardware sdk such as Gridplus's or Ledger's device management kit .
Privacy
Wallet address privacy
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Your wallet address is unique and permanent, which makes it easy for applications and companies like Chainalysis to track your activity. In web-privacy terms, it is worse than cookies: its record is permanent, publicly visible, and even tracks across multiple devices and websites. The more personal information is linkable to your wallet address, the more effective such tracking can be. It is therefore important to use a wallet that does its best to protect your information from being linked to your wallet address.
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.
A few examples
A wallet would get a failing rating if...
It requires user information (other than IP address and pseudonyms) by default, and uploads this data to a third-party or records it onchain in a publicly-viewable manner.
A wallet would get a partial rating in any of these cases:
It allows a third party to learn the relationship between a user's wallet address and their IP address by default. This is treated as a partial rating because users may mitigate against this by forcing wallet requests to be proxied on their own.
It requires the user to identify themselves via a pseudonym which is sent to a third-party or recorded onchain. This is treated as a partial rating because users may choose an arbitrary pseudonym for each of their wallet address to mitigate this privacy issue.
A wallet would get a passing rating in any of these cases:
It does not require any user information to function by default, and proxies all network requests carrying the user's wallet address.
It relies exclusively on a user's self-hosted node, involving no third parties.
Multi-address privacy
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
You probably have more than one wallet address configured in your wallet, which you use for different purposes and perhaps as different identities. These wallet addresses all belong to you, but you would rather keep that fact private. It is therefore important to use a wallet that does not reveal that fact.
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.
A few examples
A wallet would get a failing rating in any of these cases:
It refreshes multiple address balances by grouping all of these addresses in the same request.
It makes multiple simultaneous requests about each of the user's wallet balances, without proxying or staggering the requests.
A wallet would get a partial rating in any of these cases:
It makes multiple simultaneous requests about each of the user's wallet balances, proxying each of them through a different proxy circuit (e.g. Tor with unique circuits for each wallet address). The receiving endpoint may still correlate these addresses through time-based correlation.
It makes multiple requests about each of the user's wallet balances, staggering them over time to avoid time-based correlation. The receiving endpoint may still correlate these addresses through IP-address-based correlation.
A wallet would get a passing rating in any of these cases:
It makes multiple requests about each of the user's wallet balances, staggering them over time to avoid time-based correlation, and using unique proxy circuits for each wallet address to avoid IP-address-based correlation.
It distributes requests about each of the user's wallet balances across unique RPC endpoints owned by different entities, preventing any single entity from learning about more than one wallet address.
It only has one active wallet address at a time, and only ever makes requests about this wallet address and no other.
It runs by default with a user's own self-hosted node, preventing any third-party from learning about any of the user's wallet addresses.
Self-sovereignty
Self-hosted node
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Ethereum's design goes to painstaking lengths to ensure that users can run an Ethereum L1 node on commodity consumer-grade hardware and residential Internet connections. Running your own node gives you several important benefits:
Privacy: Because the wallet can work directly on your own hardware with no outside dependencies, the wallet can query data about the state of the chain without revealing private details such as your wallet address or IP address to a third-party RPC provider.
Integrity: Relying on a third-party RPC provider means that this provider may return incorrect data about the state of the chain, tricking you into signing a transaction that ends up having a different effect than the one you intended. Your own L1 node will verify the integrity of the chain, so such attacks cannot occur when using a self-hosted node.
Censorship resistance: Because an L1 node may broadcast transactions into a shared mempool directly to other nodes in the network, your transactions are not censorable by a third-party RPC provider that would otherwise act as an intermediary.
No downtime: Because the L1 node is running on your own hardware, you are not at risk of losing funds or opportunities due to downtime from a third-party RPC provider.
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.
A wallet would get a passing rating if...
It lets you configure the RPC endpoint used for Ethereum mainnet.
A wallet would get a partial rating in any of these cases:
It does not let you configure the RPC endpoint used for Ethereum mainnet, but lets you add a custom chain with your own self-hosted node as RPC endpoint.
It lets you configure the RPC endpoint used for Ethereum mainnet, but makes requests to a third-party RPC provider before the user has a chance to modify this RPC endpoint configuration.
A wallet would get a failing rating if...
It uses a third-party Ethereum node provider and does not let you change this setting.
Account portability
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Question: What if a wallet's dev team walked away or turned evil one day?
One of Ethereum's core promises as an Internet upgrade is to avoid the possibility for user lock-in of web2. This is achieved by ensuring accounts are permissionlessly portable across wallets.
Ensuring that accounts remain portable avoids wallets becoming lock-in vectors in web3. Permissionless account portability also keeps the wallet ecosystem healthy through open competition.
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:
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.
A few examples
A wallet would get a failing rating in any of these cases:
It is an EOA wallet that does not use common seed phrase derivation standards for EOA key derivation, and does not allow the user to export their private keys.
It is an MPC wallet where the user does not have sufficient key shares under self-custody to unilaterally control the account by default.
It is an MPC wallet where the user is in self-custody of sufficient key shares to unilaterally control the account, but cannot generate a token transfer transaction without relying on a third party API.
It is an ERC-4337 (smart contract) wallet where the control logic of the smart contract is such that the user cannot update it to have the user's own private keys as the sole controlling keys of the account.
It is an ERC-4337 (smart contract) wallet over which the user does not have full self-custodial control by default, and needs to rely on a third-party API or proprietary software to modify this.
It is an ERC-4337 (smart contract) wallet over which the user has full self-custodial control by default, but still needs to rely on a third-party API or proprietary software to generate a valid token transfer transaction.
A wallet would get a partial rating in any of these cases:
It is an EOA wallet that does not use common seed phrase derivation standards for EOA key derivation, but does allow the user to export private keys so that they can be imported into other wallets.
It is an MPC wallet where the user is in self-custody of sufficient key shares to unilaterally control the account, but cannot generate a token transfer transaction without the use of proprietary software.
It is an ERC-4337 (smart contract) wallet over which the user does not have full self-custodial control by default, but can create a transaction that modifies this using standalone open-source software.
A wallet would get a passing rating in any of these cases:
It is an MPC wallet where the user is in self-custody of sufficient key shares to unilaterally control the account, and can generate a token transfer transaction using standalone open-source software which does not rely on any third party API.
It is an ERC-4337 (smart contract) wallet over which the user has full self-custodial control by default, and can create token transfer transactions using solely open-source software without relying on a third-party API.
Transaction inclusion
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
One of the core tenets of Ethereum is censorship resistance. This means that users must be able to reliably get transactions included onchain, without the ability for intermediaries to prevent this from happening.
This property is critical to ensure that all Ethereum participants are provided equal-opportunity, unfettered access to Ethereum, and to ensure that Ethereum is resilient to attackers that would want to prevent others from using Ethereum on such footing.
In order to uphold this property on Ethereum L2s, users must be able to force transactions to be included on L2 chains as well. Most L2s implement such functionality by allowing L2 transactions to be submitted on the L1, and enforcing that their sequencing logic must respect such L1 force-inclusion requests by including them on the L2 chain, typically within some fixed duration.
By verifying that the wallet supports L2 force-withdrawal transactions, this attribute verifies censorship resistance at both levels: L1 and L2.
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.
A wallet would get a passing rating in any of these cases:
It supports force-withdrawal transactions on L2s, and can be configured to broadcast this transaction using a user's self-hosted L1 node.
It supports force-withdrawal transactions on L2s, and supports directly gossipping such transactions over the Ethereum L1 network.
A wallet would get a partial rating in any of these cases:
It supports force-withdrawal transactions on L2s, but requires the use of a third-party RPC provider to submit the L1 transaction that it would take to initiate this force-withdrawal transaction.
It supports force-withdrawal transactions on some L2s, but not all of the L2s that are configured out of the box.
A wallet would get a failing rating if...
It does not support force-withdrawal transactions on L2s.
Transparency
Source code license
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Free and Open Source Software (FOSS) licensing allows a software project's source code to be freely used, modified and distributed. This allows better collaboration, more transparency into the software development practices that go into the project, and allows security researchers to more easily identify and report security vulnerabilities. In short, it turns software projects into public goods.
Wallets are assessed based whether the license of their source code meets the Open Source Initiative's definition of open source .
A wallet would get a passing rating if...
A wallet would get a partial rating if...
It is licensed under a license that represents a commitment to switch to a Free and Open Source Software (FOSS) license by a specific date. Examples of such licenses include BUSL .
A wallet would get a failing rating in any of these cases:
It is licensed under any non-FOSS (proprietary) license.
Its source code repository is missing a license file. The lack of a license file may be an accidental omission on the wallet developers' part, but also may indicate that the wallet may set its license to a proprietary license. Therefore, Walletbeat makes the conservative assumption that the wallet is not be Free and Open Open Source Software until it does have a valid license file.
Source visibility
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
When using a wallet, users are entrusting it to preserve their funds safely. This requires a high level of trust in the wallet's source code and in the wallet's development team. By making the wallet's source code visible to the public, its source code can be more easily inspected for security vulnerabilities and for potential malicious code. This improves the wallet's security and trustworthiness.
Wallets are assessed based on whether or not their source code is publicly visible, irrespective of the license of the source code.
If a wallet's source code is visible, it passes. If not, it fails.
Funding
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Wallets are complex, high-stakes pieces of software. They must be maintained, regularly audited, and follow the continuous improvements in the ecosystem. This requires a reliable, transparent source of funding.
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.
A few examples
A wallet would get a failing rating in any of these cases:
It has funding but has not revealed this publicly and transparently to users.
It does not have any funding. Wallets must have sustainable funding sources in order to remain secure and up-to-date.
A wallet would get a partial rating in any of these cases:
It is funded from hidden swap fees. While users can look this up onchain to see how much revenue the wallet is generating from this, making this funding source technically transparent, it is not user-aligned.
It is funded from user-visible swap fees and governance token sales with undisclosed vesting schedule. While users can use onchain lookups to determine how much revenue is generated from both sources, making the funding technically transparent, the undisclosed nature of governance token makes makes this not user-aligned.
A wallet would get a passing rating in any of these cases:
It is funded from user-visible swap fees and pre-disclosed governance token sales.
It is funded from venture capital and publishes regulatory filings showing the amount raised in each round and the top investors of each round.
It is funded from onchain donations, onchain ecosystem grants, and commemorative NFT sales.
Fee transparency
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Fee transparency is crucial for users to understand the full cost of their transactions. Without clear fee information, users may be surprised by high transaction costs or hidden fees charged by the wallet.
Transparent fee disclosure helps users make informed decisions about when to transact and which wallet to use. It also builds trust between users and wallet providers by ensuring that all costs are clearly communicated upfront.
Additionally, understanding the purpose of a transaction is important for security. When users can clearly see what they're authorizing (e.g., a token swap, NFT purchase, or contract interaction), they're less likely to approve malicious transactions.
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.
A wallet would get 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 would get a partial rating in any of these cases:
It provides detailed information about network fees, but may not fully disclose additional wallet fees or clearly show transaction purposes.
It provides basic information about transaction fees, but the information is limited and may not include a breakdown of costs.
A wallet would get a failing rating if...
It does not provide clear information about transaction fees before users confirm transactions.
Ecosystem
Account Abstraction
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
User experience on Ethereum has historically suffered from the limitations of Externally-Owned Accounts (EOAs), which is the type of account most Ethereum users use today. By contrast, smart wallet accounts offer many UX and security improvements, such as the ability to:
Batch multiple transactions, removing the need for separate "token approval" transactions before every other token operation.
Pay gas fees in other tokens than Ether, or having third-parties sponsor transaction fees (with ERC-4337)
Delegate some operation to trusted third-parties, such as allowing onchain games to withdraw small amounts of tokens without signing pop-ups for each and every transaction.
Change transaction authorization logic, enabling the use of Passkeys (and mobile phone authentication methods) for signing transactions.
Update the set of keys used to control the wallet, enabling the switch to quantum-resistant encryption algorithms in the future.
Define account recovery rules, reducing the risk of losing access to your account when losing a private key or a device.
However, smart wallet accounts have historically been an all-or-nothing, wallet-specific proposition for users. There was no transition path to such wallets.
As part of the Pectra upgrade , EIP-7702 changes this situation by allowing a clean path for existing EOAs to obtain all of the UX benefits of smart wallet accounts and account abstraction, without the need for users to switch to a different account address. This represents a large User Experience upgrade for all Ethereum EOA users.
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.
A few examples
A wallet would get a passing rating in any of these cases:
It supports EOA accounts and can use Account Abstraction features via EIP-7702: Account Abstraction via smart contract authority delegation.
It supports smart wallet accounts using ERC-4337: Account Abstraction for smart contract wallets.
A wallet would get a failing rating in any of these cases:
It only supports plain EOAs without Account Abstraction features.
It only supports MPC wallets without Account Abstraction features.
Address resolution
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Ethereum addresses are hexadecimal strings (0x...) which are
unreadable to humans. Phishing scams and exploits have used this to
trick users into sending funds to invalid addresses, for example by
generating lookalike-addresses and tricking users into copy/pasting
them without noticing the difference.
Additionally, Ethereum's transition to layer 2s has changed user needs when sending funds. The hexadecimal address isn't sufficient anymore; the user needs to ensure that they are sending funds to the correct hexadecimal address on the correct chain, increasing the potential for mistakenly sending funds to the wrong place or the wrong chain.
Address naming registries like ENS partially solve this problem by
allowing more human-readable names like username.eth to be
automatically turned into the hexadecimal address. This is easier to
share and to accurately transfer by humans. Additionally, some address
format standards improve upon this further by including the destination
chain information as part of the address itself. Such standards include:
ERC-7828: Chain-specific addresses using ENS:
[email protected]ERC-7831: Multi-chain addresses:
user.eth:l2chain
Wallets that support either of these standards are able to automatically determine the destination address and chain from a human-readable string, and can bridge funds across chains as appropriate. This improves the user experience of Ethereum and its layer 2 ecosystem while reducing the potential for mistakes when sending funds.
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 informationERC-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.
A few examples
A wallet would get a failing rating if...
It only supports sending funds to raw (
0x...) addresses.
A wallet would get a partial rating in any of these cases:
It only resolves plain ENS addresses (
username.eth) which do not include a destination chain.
Walletbeat's database does not have the necessary information on Frame to assess this question.
Please help us by contributing your knowledge on our repository !
Web applications that want to integrate with Ethereum should not have to write code specific to the wallet that the user has installed. For this reason, the Ethereum community has defined web browser integration standards, which dictate how wallets and web pages can interact with each other.
By ensuring that wallets implement this standard interface, applications automatically support all wallets that implement the interface. This ensures compatibility across wallets, and ensures that the Ethereum wallet ecosystem remains competitive thanks to wallet interoperability.
Wallets are rated based on whether they implement the following Ethereum standards for web browser integration:
For multi-platform wallets, only the web browser version is assessed.
A wallet would get a passing rating if...
It implements all listed web browser integration standards.
A wallet would get a partial rating if...
It implements some but not all listed web browser integration standards.
A wallet would get a failing rating if...
It implements none of the listed web browser integration standards.