Define what "stage 1️⃣" means for a wallet

[polymutex]

Follow-up on some of the discussion in #79, we should probably come up with some definition for "stages" in a similar way as L2BEAT defines them.

One naive way would be to simply port over the ratings to correspond directly to "stage 0️⃣/1️⃣/2️⃣":

• FAIL rating = stage 0️⃣
• PARTIAL rating = stage 1️⃣
• PASS rating = stage 2️⃣

... and then each wallet would get the lowest stage as defined by the above. But I think this would make it unrealistically difficult for any wallet to get to stage 1️⃣ from the status quo, which means none of them would be motivated enough to get there in the first place.

One way in which L2BEAT has addressed this problem is to start with looser definitions for stages, and then tightening them. We could do the same thing at the per-attribute level, by making PARTIAL be easier to achieve. However, I also think it is impossible to come up with defensible evaluation logic for something like, say, a PARTIAL on light client support that any wallet would pass right now (other than ethOS, of course, but that one would fail on many other attributes).

So even if we decide to loosen some of the PARTIAL ratings to be easier to attain, we also would still need some definitions of stage 1️⃣ that is looser than "wallet gets at least PARTIAL rating on all attributes" in order to get anywhere with stage 1️⃣.

This issue is about defining what "stage 1️⃣" specifically means. We should aim high, but that definition should also be such that we would be able to point to at least one wallet that implements >80% of what this definition. This would act as "evidence proof" that stage 1️⃣ is reasonably attainable, and not some unsustainably high standard.

[polymutex]

My proposal.

Guiding principle for definition: Stage 1️⃣ is a long-term commitment for a wallet to Ethereum principles. But it is also only a start. "Ethereum principles" means being secure, respecting user privacy and self-sovereignty, being transparent, and implementing features critical to furthering the Ethereum ecosystem's goals.

These are the same 5 pillars that Walletbeat rates as attribute groups. Not a coincidence!

Stage 1️⃣ therefore needs to include minimal yet meaningful features and commitments on all of these principles.

Here's what this means to me. For stage 1️⃣, a software wallet MUST:

• Security:
  • Have passed a security audit in the last year
  • Support a subset of hardware wallet types
  • Something about account recovery that we have not yet fully defined as an attribute, but should be part of this stage criteria list too
  • Verify L1 state (either via light client or own node)
• Privacy:
  • Integrate at least one type of private token transfers
• Self-sovereignty:
  • Follow established key derivation standards
  • Support aiming the L1 RPC provider to a user's own node
• Transparency:
  • Be open-source (FOSS license)
• Ecosystem alignment:
  • Support cross-chain bridging
  • Implement some basic EIP-7702-enabled features (batching etc.)

This subset seems quite reasonable to me. The one that nearly all wallets would fail today are light clients and private transfers (and perhaps account recovery). The rest is widely achieved already.

[polymutex]

Feedback from the call on 2025-06-22: the current level of software wallet integration with hardware wallets is not great. This topic came up in the context of inclusion for stage 1️⃣. While we agreed that this problem needs to be addressed and hence tracked (filed #200 about this), for the purpose of stage definitions, we came to the consensus that this level of better integration can be a later stage than stage 1️⃣, and that stage 1️⃣ can be simply about number of supported hardware wallet manufacturers.

[PatrickAlphaC]

IMO a stage 1 wallet could/should be the most basic implementation of a self-custodial wallet. Where it can "do" everything you need it to do, but without any advanced features. This is quite different from L2beat, where a stage 1 L2 is really "not quite an L2" or "and L2 with training wheels". Whereas here, we are saying a stage 1 wallet is "a decent wallet". We could go further and have a stage 3 wallet be like "a super wallet", a stage 2 be a "good wallet" and a stage 1 be "not quite a wallet".

Sorry I'm late to the discussion.

If we say a stage 1 wallet is "a wallet that's pretty good":

Here's what this means to me. For stage 1️⃣, a software wallet MUST:

 * **Security**:
   * Have passed a security audit in the last year
   * Support a subset of hardware wallet types
-   * Something about account recovery that we have not yet fully defined as an attribute, but should be part of this stage criteria list too
-   * Verify L1 state (either via light client or own node)
+   * Can extract all calldata at least in its raw form for intent verification
+   * Key is stored in encrypted form
  
 * **Privacy**:
-   * Integrate _at least one_ type of private token transfers
 
 * **Self-sovereignty**:
   * Follow established key derivation standards
   * Support aiming the L1 RPC provider to a user's own node
+   * Allow for exporting and importing of private keys (or account transfer for AA wallets)
 
 * **Transparency**:  
   * Be open-source (FOSS license)
 
 * **Ecosystem alignment**:
-   * Support cross-chain bridging
   * Implement some basic EIP-7702-enabled features (batching etc.)

If we say a stage 1 is "a wallet with training wheels":

 * **Security**:
   * Have passed a security audit in the last year
-   * Support a subset of hardware wallet types
-   * Something about account recovery that we have not yet fully defined as an attribute, but should be part of this stage criteria list too
-   * Verify L1 state (either via light client or own node)
+   * Key is stored in encrypted form
  
 * **Privacy**:
-   * Integrate _at least one_ type of private token transfers
 
 * **Self-sovereignty**:
   * Follow established key derivation standards
-   * Support aiming the L1 RPC provider to a user's own node
 
 * **Transparency**:  
   * Be open-source (FOSS license)
 
 * **Ecosystem alignment**:
-   * Support cross-chain bridging
   * Implement some basic EIP-7702-enabled features (batching etc.)

Then, for a stage 2 (aka, an awesome wallet) we could say:

 * **Security**:
   * Have passed a security audit in the last year
   * Support a subset of hardware wallet types
-   * Something about account recovery that we have not yet fully defined as an attribute, but should be part of this stage criteria list too
-   * Verify L1 state (either via light client or own node)
+   * Can extract all calldata at least in its raw form for intent verification
+   * Key is stored in encrypted form
+   * A history of good security hygiene (idk what this means yet...)
+   * Uses a threat intel service like blockaid to warn users (scam prevention)
+   * Bug Bounty Program

  
 * **Privacy**:
   * Integrate _at least one_ type of private token transfers
+   * Option to not collect IP
 
 * **Self-sovereignty**:
   * Follow established key derivation standards
   * Support aiming the L1 RPC provider to a user's own node
+   *  Bring your own RPC
+   * Allow for exporting and importing of private keys (or account transfer for AA wallets)
 
 * **Transparency**:  
   * Be open-source (FOSS license)
+   * Display all fees
 
 * **Ecosystem alignment**:
-   * Support cross-chain bridging
   * Implement some basic EIP-7702-enabled features (batching etc.)
+   * ERC4337 support

[polymutex]

IMO a stage 1 wallet could/should be the most basic implementation of a self-custodial wallet. Where it can "do" everything you need it to do, but without any advanced features. This is quite different from L2beat, where a stage 1 L2 is really "not quite an L2" or "and L2 with training wheels". Whereas here, we are saying a stage 1 wallet is "a decent wallet". We could go further and have a stage 3 wallet be like "a super wallet", a stage 2 be a "good wallet" and a stage 1 be "not quite a wallet".

I think we should have the stage numbers follow L2beat's general level of "sophistication", in order for both the L2 and wallet parts of the ecosystem to have an easier time communicating the value of their respective efforts. What L2beat calls "stage 1" is quite advanced already, so it would be good to have "stage 1" also reflect that for Walletbeat. Makes for easier messaging, even if we think L2beat started numbering stages at the wrong offset :)

So from that perspective, "stage 0" should IMO be "the most basic implementation of a self-custodial wallet". IMO that also includes being source-available, because (a) it's not really possible to ascertain that a wallet is actually self-custodial if you can't see what it does, and (b) it's impossible for walletbeat to actually review much of the other dimensions without seeing the source code.

Your other definition of stages seem roughly in line with what I have in mind as well, however I think we need a less-subjective definition or "limiting principles" for the stages, versus "a pretty good wallet" which is highly subjective. The one I propose above is for "stage 1" to mean "minimal yet meaningful advancement on all 5 attribute groups". I recognize that's still subjective, but I think that's an improvement on removing subjectivity out of it.

That said, your suggestions make sense to me. Namely:

 * **Security**:
   * Have passed a security audit in the last year
   * Support a subset of hardware wallet types
-   * Something about account recovery that we have not yet fully defined as an attribute, but should be part of this stage criteria list too
-   * Verify L1 state (either via light client or own node)
+   * Can extract all calldata at least in its raw form for intent verification
+   * Key is stored in encrypted form
  
 * **Privacy**:
-   * Integrate _at least one_ type of private token transfers
 
 * **Self-sovereignty**:
   * Follow established key derivation standards
   * Support aiming the L1 RPC provider to a user's own node
+   * Allow for exporting and importing of private keys (or account transfer for AA wallets)
 
 * **Transparency**:  
   * Be open-source (FOSS license)
 
 * **Ecosystem alignment**:
-   * Support cross-chain bridging
   * Implement some basic EIP-7702-enabled features (batching etc.)

• Security:
  • Key is stored in encrypted form: Makes sense to have this as a basic level of security.
    • Will add.
  • Can extract all calldata at least in its raw form: Also makes sense, otherwise there's not even a way to know what you are signing, so that would make the wallet not-really-self-custodial from the user's perspective, as they cannot be sure they are keeping their assets safe.
    • Will add.
• Privacy:
  • Removing Private Transfers: I would strongly object to removing this. Private token transfers seem like a very baseline level of privacy that the ecosystem should strive to achieve. I realize we're far from achieving that today, and that's all the more reason to keep it there IMO. Additionally, the removal of this criterion would mean that there's no attribute requirement under "Privacy", which goes against the "minimal but meaningful" principle for the stage definition.
• Self-sovereignty:
  • Allow for exporting and importing of private keys: Agreed. That was actually the intent behind the "Follow established key derivation standards" requirement, but you're right that the real benefit here is account export/import.
    • Will remove "Follow established key derivation standards".
    • Will replace it with account portability, which is more general and covers AA wallets while keeping the same user benefit.
• Ecosystem:
  • Removing Support cross-chain bridging: Hm, perhaps. I don't have a strong opinion here. In practice, I think most multi-chain wallets will implement this anyway, because it's a money-maker (via taking a cut of bridging fees) and it's a clear UX improvement, so perhaps Walletbeat doesn't need to push this very hard.
    • Will remove.

Thanks for the suggestions! I will implement make the changes in #206, and will repost your suggestion for the "awesome wallet" tier on #195. Let me know your thoughts on the above or on the stage 1 PR.

[PatrickAlphaC]

I like your commitment to the cause! Sounds good to me.