Rainbow

Wallets are evaluated on two closely-related aspects: their track record of published security audits, and their bug bounty program. The overall rating is the worse of the two, so a wallet must do well on both aspects in order to get a passing rating.

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 does well on this aspect if it has been audited at least once within the last 365 days, and all medium-or-higher severity flaws that were found across all audits (including older ones) are addressed. This applies to all wallet types, including hardware wallets.

Bug bounty program: Wallets do well on this aspect if they implement a comprehensive bug bounty program with:

• An active program accepting vulnerability reports
• Full coverage of the wallet's components
• Financial rewards based on severity
• Legal protections (such as Safe Harbor language) for security researchers
• A clear upgrade path for users when security issues are fixed

Programs with limitations (limited coverage, unclear rewards, inactive or paused programs, no legal protections) are rated as partial. Wallets with no formal process for reporting vulnerabilities fail this aspect.

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

• Sending funds to an address the user has never previously sent or received funds from before
• Sending funds to an address that closely resembles ("poisons") one already in the user's history
• 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
• Granting unlimited ERC-20 token approval

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.

• When checking whether a token approval is unlimited, does the lookup of the spender/contract reveal the spender address together with the user's IP or Ethereum address to an external provider?

  • Wallets can implement this feature in a privacy-preserving manner by maintaining a local set of known spenders, or by detecting unlimited approvals entirely from the transaction data being signed.

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:

ERC-7730 Calldata Decoding: The wallet's ability to decode and display calldata for complex transaction types using ERC-7730, including:

• Token approvals
• DeFi interactions (e.g. Aave supply)
• Safe nested transactions
• Complex nested multisend batches (EOA and Safe)

For software wallets, transaction details are evaluated according to the set of information they display:

• For transfers (ETH transfers, ERC-20 transfers, ERC-721 transfers, ERC-1155 transfers): gas, nonce, sender, recipient, chain, amount. Some details may be collapsed by default (e.g. 'nonce'), but all of them must be accessible through the UI.
• Non-transfer transactions (approvals, DeFi contract interactions, Safe multisig nested transactions): gas, nonce, from, chain. In addition, the wallet must explain the transaction outcome visually or in plain language; for example, for ERC-20 approvals, it should explain what token is being approved, for which contract, and for how many tokens.
• If presented with a transaction that will revert if included onchain, the wallet must detect that the transaction would fail and warn the user beforehand.
• If presented with a transaction for which the behavior would be nondeterministic based on predictably-changing parameters (e.g. block number), the wallet must detect that the transaction has a nondeterministic outcome and warn the user beforehand.

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
• Calldata digest (ERC-8213): Users can verify the calldata hash independently

Software wallets must also support calldata decoding for various transaction types, from basic token transfers to complex nested transactions, and must display the EIP-712 digest for typed message signing (ERC-8213: Wallet signature & calldata digest display).

Hardware Wallet Specific Requirements: For hardware wallets, the signature/transaction information must be visible on the hardware wallet device itself. Any data shown only in a companion app or browser extension is ignored for hardware wallet ratings.

Hardware wallets are evaluated on their ERC-7730 calldata decoding coverage. Decoding is only counted when it happens on-device: off-device decoding in a companion app cannot be trusted if the companion app is compromised. The benchmark transactions range from simple token approvals to complex Safe nested multisend batches.

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

The Calldata digest and EIP-712 digest (ERC-8213: Wallet signature & calldata digest display) must be shown on the device itself.

ERC-8213: Wallet signature & calldata digest display Compliance: A wallet fully implements ERC-8213 when it displays both:

• The Calldata digest for transactions with calldata
• The EIP-712 digest for typed structured data signatures

For hardware wallets, both must be shown on the device screen (not just in companion software).

Rating Criteria:

For software wallets:

• A wallet receives a passing rating if it fully supports ERC-7730 calldata decoding, displays calldata in all required formats (raw hex, formatted, copyable, digest), shows all essential transaction details, and implements ERC-8213 along with ERC-4361 (Sign-In with Ethereum).
• A wallet receives a partial rating if it has some combination of these features but not all.
• 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 on-device ERC-7730 decoding for complex nested transactions, displays all essential transaction details on the device, and provides comprehensive data extraction methods (QR codes and hashes). It must also implement ERC-8213: Wallet signature & calldata digest display (Calldata digest and EIP-712 digest on-device) and support ERC-4361 (Sign-In with Ethereum).
• 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 ERC-7730 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.

Up to four sub-evaluations are scored; the worst determines the overall rating.

• Key storage: Secure enclave or no on-device key = Pass; standardized KDF or OS sandbox = Partial; anything else = Fail.
• Secure RNG: OS CSPRNG = Pass; unverified library RNG = Partial; unknown/insecure = Fail.
• Deployment hardening: browser extension host permissions and web_accessible_resources scope; mobile app high-risk permission declarations.
• Passkey verification (if supported): well-audited library = Pass; less-audited = Partial; none = Fail.

Wallets are evaluated based on their implementation of guardian-based recovery and on whether they periodically verify that users still have access to their account recovery methods.

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.

Separately, wallets are evaluated on whether they periodically prompt users to demonstrate that their recovery setup still works. Which check-ups are expected depends on the wallet's features and on how each account was created, since wallets can only drill users on recovery material that actually exists:

• If the wallet supports EOA accounts and lets the user export their private key, a private key check-up for accounts imported from a raw private key, confirming the user still has access to their private key.
• If the wallet supports EOA accounts derived from a seed phrase, a seed phrase check-up for accounts created from a seed phrase, confirming the user still has access to their seed phrase.
• Wallets without EOA support (such as MPC-based wallets) have no such user-held key material, so no key material check-ups are expected for them.
• If the wallet implements guardian-based recovery, a guardian account check-up, confirming the user still has access to each configured guardian account.

Wallets are rated based on the strongest duress protection they provide, such as support for a lock screen and duress actions.

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
• Railgun

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.

We evaluate default behavior using network requests and published data collection policies. The wallet fails if it sends browsing history by default. The wallet also fails if it uses product analytics without prior consent. It gets a partial rating when crash/error reporting runs without prior consent.

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 rated based on whether they allow users to inspect existing token approvals and revoke them directly from within the wallet interface. ERC-20, ERC-721, and ERC-1155 approvals are each evaluated; the worst result across all token standards determines the overall rating.

As Account Abstraction becomes more prevalent, this methodology will also grow to encompass the management of more complex account permissions.

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 and clear disclosure of any additional wallet fees. Fees may be aggregated down to one number. A breakdown must be available to the user within a single click. For built-in swap and cross-chain bridging flows, wallet service fees must be shown as a percentage or basis points when a comprehensive breakdown is available. Wallet service fees are platform fees charged by the wallet itself.

A wallet receives a partial rating if it provides an aggregate fee but does not let the user get a detailed breakdown. It also receives a partial rating if it shows a comprehensive breakdown on built-in swap or bridging flows. In that case, wallet service fees must be shown as a percentage or basis points. Absolute units (e.g. flat dollar or token amounts) are not sufficient.

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

Chain execution fees (gas, priority fees, L1 data costs) and external protocol fees are not subject to the wallet service fee unit rule.

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.

Four binary signals are assessed, grouped into two categories:

Basic:

1. Public changelog: the wallet publishes release notes or a changelog.
2. Dependency locking: a lockfile or equivalent pins all dependency versions.

Advanced: 3. Artifact signing: release artifacts are cryptographically signed and these signatures are published. 4. Reproducible or hermetic builds: independent parties can verify that build output matches source, or the build can run fully offline. Verifying this independently requires access to public source code.

A wallet passes when both basic signals and both advanced signals are present. Partial coverage earns a partial rating, based on which groups are satisfied. Basic signals alone score lower than advanced signals alone, reflecting stronger trust from advanced-group evidence. No signals at all earns a fail.

Wallets are exempt from this attribute when they are hardware wallets.

Software wallets that do not send pre-inclusion transaction data to external parties by default pass on this attribute.

Software wallets that share pre-inclusion data by default but do not auction orderflow pass when every default recipient uses an endpoint that is documented and independently verifiable as non-extractive. They receive partial when at least one default recipient does not. The evaluation names which recipient entities use extractive endpoints.

Wallets that auction orderflow by default are evaluated on disclosure prominence in the transaction UI (compared to the least clear basic-operation fee display), a linked orderflow practices page, and the contents of that page. The practices page should list recipient entities and what they do, explain that auctioning is enabled by default, document how users can change defaults (or state that defaults cannot be changed), and describe how users can verify onchain outcomes.

They fail when orderflow is not disclosed in the UI, disclosure is less prominent than fees, no practices page is linked, or the page omits required content. They receive partial when onchain verification is documented but not confirmed effective. They pass when all requirements are met.

If the Ethereum protocol later implements a native mempool encryption mechanism, wallets that use this mechanism to shield transaction data before it is included onchain would also pass 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.

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 receive a pass only if they support ERC-7828: Chain-specific addresses using ENS or ERC-7831: Multi-chain addresses (chain-specific human-readable addresses). Wallets that support only plain ENS, with or without onchain resolution, receive a partial rating.

For a pass, 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 whether they implement the following Ethereum standards for web browser integration:

• EIP-1193 JavaScript Provider API
• EIP-2700 JavaScript Provider Events
• EIP-6963 Multiple JavaScript Providers

For multi-platform wallets, only the web browser version is assessed.

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.