polymutex.eth

OK, your analysis is better (sorry, I skimmed it before initially responding). We need a smarter way to aggregate the results when viewing data across variants for this attribute.

I have received permission to merge this into `main` from @mozrt2, so merging this now.

Hi! Agreed on all counts. EIP-712 data display seems like something that should be expected of all wallet types (both software and hardware), whereas use of a secure element only...

Yeah, it's a bit of a mess. It's not strictly separated by attribute groups, because feature data is used by multiple attributes across multiple groups. For example, the chain verification...

It's a good question. I think it may make sense to have them as a separate category; perhaps we can call them "hardware keys" rather than "hardware wallets". The use...

Agreed. I think we should have a "Guides" section, of which this could be one. Other guides worth having: - How to build *software* wallets that have reproducible builds -...

The ability to point the RPC provider to your own node is an option that users can use to verify the chain on their own, sure. However, the wallet should...

One thing the Chain Verification attribute _doesn't_ currently implement but _should_ implement are wallets that run a local Ethereum node on the user's machine by default. Such wallets inherently verify...

FYI in #185 I am refactoring this to be a bit simpler, by using `WalletType` rather than `Variant` as the primary way by which wallet-type-based exemptions are done. That PR...

> This may end up in a refactor of the attributes that make hardware wallets vs software wallets. I'd like to note here that the way attribute exemptions are done...