Attributes describe wallets in self-explanatory badges. The badges can have five sentiment levels:

• Negative: red color with bomb icon - indicates that this attribute can be a dealbreaker or downright dangerous when picking which app to use, depending on your goal.
• Slightly negative: light red color indicating a lack of an expected feature, but is usually not a dealbreaker.
• Neutral: grey color - no immediate effect on impression or desirability.
• Slightly positive: light green represents a desirable feature.
• Positive: green with gold star, represents a very desirable feature or something few wallets go for in terms of user friendliness.

The blockchain allows us to exchange messages freely, globally, 24/7, without possibility of interference from bad actors. These messages can be communication (chat), financial (transactions) or content (web3). When we rely too much on someone else's service to facilitate this for us, we submit ourselves to their will - whether it be because the service relays all our messages, or because it's closed source and we don't know how much it relays and how much depends on their own servers.

In the context of mobile cryptocurrency wallets, censorship resistance means being able to use the blockchain to exchange messages even if the official entity behind the wallet disappears or becomes corrupt.

This attribute will indicate how web3-compatible a wallet is. A web3-enabled wallet will usually have an embedded browser which will allow you to access applications that require wallet access. These can but don't have to be "Dapps" (decentralized apps) - in fact, most Dapps still have a server-side component and require a regular account.

The attribute will negatively mark those wallets which support a modern blockchain (like Ethereum) but have no dapp support because that's clearly a missing feature in that case. It will not negatively mark those apps which only interact with a simple blockchain like Bitcoin, ZCash, Stellar and similar because web3 support isn't part of their end goal anyway.

UX is extremely important in the collective mission of making mass adoption of cryptocurrencies happen. Applications that are hard to use or aren't intuitive obviously score worse on this front than those who have had dedicated UX teams thinking about the interface from before a line of logic code was written. Excellent UX in this space is rare, and it usually only happens in applications that have been polished to UX perfection before and then only added a blockchain aspect on top - like the Opera browser.

Given if a wallet supports multiple incompatible blockchains.

A list of different blockchains wallets can support. We expand this list as we encounter more coins in wallets. Click each individual coin to find out more!

An extremely important feature of decentralization - being able to configure your own node to connect the wallet to. Connecting to a custom node lets you avoid potential censorship by the app, ISP, or the government and protects you from spying - if the app is only talking to your own server, you're as safe as that server. If it's sending your transactions and private keys to a third party server, you're constantly at risk.

Remember, not your keys - not your crypto; not your node - not your truth! Always run your own node if you can - it's cheap!

Which operating systems the app supports. Sometimes an app will have a desktop version, but this attribute will not be present in the main list on that app. This happens in cases where the desktop app differs from the mobile one so much they cannot be considered the same app, so the desktop version is ignored. An example is Opera and Status - both have desktop versions, but neither desktop version shares the wallet functionality of the mobile counterpart.

Indicates the level and type of support for the Ethereum Name System. The ENS allows you to enter an Ethereum address in the form of something like `bitfalls.eth` rather than `0x4da...523e`. This makes it much easier to send funds and avoid errors, and also protects you somewhat from impostor ICOs.

When developing dapps and playing with tokens and collectibles, especially when dealing with virtual items like those from video games, support for custom tokens in the app is paramount. The two standards most of us currently care most about are ERC20 - the typical fungible token like OMG, WETH, RLC, and others, and ERC721 - the non fungible token.

Decentralized Finance, also known as Open Finance, is a new movement in the crypto sphere, emphasizing full control over one's assets and finances - including loans and interests. DeFi support in a wallet doesn't mean being able to open apps like MakerDAO or Compound Finance in a dapp browser, it means in-depth integration with those apps to the point where the app becomes a person's DeFi dashboard and hub without ever having to open the apps in the dapp browser at all.

An open source app is safe because you can inspect it. When you have access to the source code, you know the private keys aren't being sent to anyone's server, and you know that no one is collecting and selling data about you. Granted, a full open source approach can backfire and copycat apps with the same UI and features PLUS a key hijacking mechanic can and do appear in app stores, but when open source apps provide verifiable APKs and binaries instead of relying on centralized distribution services, you get the holy grail of security.

The world of QR code scanning in the blockchain space is chaos, and that's putting it mildly. Several attempts at standardizing this have been made, most notably the successful BIP-21 proposal, but that's Bitcoin specific and while it's useful for the simpler blockchains like Bitcoin's, it doesn't work well for Ethereum which needs more advanced inputs.

In Ethereum, EIP-681 is the agreed-upon standard, but as the specification is rather clumsily written and the EIP further depends on EIP-831, very few wallets support it in full. We are preparing a detailed study into which format is accepted by which wallet and to which degree and will share it here as well as on Bitfalls.com.

Wallets.Review currently only states whether or not a wallet supports BIP-21 or EIP-681, with the latter having a positive and a negative state, and the former being neutral. Infrastructure for a more granular display is in place (and those detailed attributes can be seen below), but the layout on how to show this is still being debated. Keep an eye on this space, things will change soon™.

Some applications demand KYC procedures from their users. These will often involve things like talking to an agent in a videocall and brandishing one's passport or other form of government-issued ID. Obviously, this poses an enormous risk to end-users. Not only is there an implied privacy leak, but it also puts users in direct danger if this data is ever sold. Read more about this terrible practice in this post.

An application can support a user having multiple wallets on a single account, i.e. "Ethereum 1", "Ethereum 2", etc. This would be known as a multi-wallet single-account app. Some apps allow multiple accounts as well, which make it possible to have multiple wallets on different accounts, ideal for managing client funds etc.

This multi-identity approach has some pitfalls too - most notably, if an app does not clear browser cache between identity switches, a dapp (and anyone looking in from the outside) can track these identities and make the connection between them. You can test if your wallet clears the cache by using the Don't Track Web3 tool we made specifically for this.

Apart from just identities, some wallets also make use of the HD aspect of modern cryptocurrency wallets. HD wallets are explained in understandable detail in this Investopedia post. The TL;DR of it is, a single phrase can generate an infinity of addresses, so some wallets use this to auto-scan automatically-derived addresses for funds, so you can have many under a single identity, and some even go as far as generating single-use receive addresses using the deterministic paths.

Not your keys, not your crypto. If a wallet stores your keys on its servers, you're trusting it with your money. If you have your own keys and only you have them, then you're your own bank but can easily lose the key and access to your money unless you take the necessary precautions.

An app will be marked Risky here if it is partially closed source (i.e. the networking or storage parts) and isn't provably transparent on where data goes and when - this can mean they send your keys around, but also doesn't have to mean that. The only way to get rid of the Risky flag is to open source their entire app, or to have a respectable auditing firm audit the application at a specific version (identified by CRC or similar) and then explain to users how to perform the same CRC for the installed app. Once users can tell that the installed version is the same as the audited one, the app is no longer Risky.

How stable is the app? Alpha / beta apps will be negatively marked as they can contain bugs and privacy leaks or lack security audits.

Indicates how one can access their assets - is it password only, hardware-wallet supported, iris or face scan, fingerprint login, something else? No approach is more positive than the next (passwords can be forgotten, iris and face scans can be fooled...), but some people do prefer a specific authentication method.