Update wallet listing policy

[samajammin]

Description

• Update wallet suggestion issue template
• Update our wallet listing policy

Preview of form

https://github.com/ethereum/ethereum-org-website/blob/wallet-listing-policy/.github/ISSUE_TEMPLATE/suggest_wallet.yaml

Related Issue

#6434

[samajammin]

I think we can remove this - this is covered in the security section:

Please describe the measures taken to ensure the wallet's security and provide documentation wherever possible

[samajammin]

Suggested change

	**Does the wallet support multi-chain networks?**
	**Does the wallet support layer 2 networks?**

Curious what folks think of "layer 2" vs. "multi-chain"? Or should we include both?

Ultimately I suspect L2 is what we care about. Users may want other EVM chains. There could also be user benefit in e.g. Bitcoin support in a wallet (like Ledger does).

[minimalsm]

Agree that we don't care about alt L1s like AVAX here but what about sidechains like Polygon?

[minimalsm]

Perhaps a better question: which L2s do you support? e.g. Argent supports zkSync but not Optimism. But Metamask supports custom RPCs.

[wackerow]

Yeah, I see L2 and multi-chain as two different feature sets... one is contained within the Ethereum security bubble, the other is many different security bubbles.

Yes, in general, it's about which networks the wallet can connect to... but someone who uses Ethereum may reasonably want to find a wallet that supports L2s so they can inherit Ethereum's L1 security and still afford gas.

Meanwhile, someone who uses many cryptocurrencies on many chains care that their wallet also supports these other chains.

So my vote would be to include both. We should ask what non-EVM chains are compatible, and also what Ethereum L2s are compatible, imo.

[corwintines]

I agree with the notion here, but my pushback would be from our discussions of what layer 2's are. I think a user would want to look at validiums or optimistic chains as well, which I would say still fall under the bundle of scaling Ethereum, but we don't classify it as a layer 2. That being said, I think that is more captured in the RPC importing question. Down for a discussion, but I think I agree with this suggestion.

[gatsby-cloud]

Gatsby Cloud Build Report

ethereum-org-website-dev

🎉 Your build was successful! See the Deploy preview here.

Build Details

View the build logs here.

🕐 Build time: 22m

Performance

Lighthouse report

Metric	Score
Performance	🔶 20
Accessibility	💚 100
Best Practices	💚 100
SEO	💚 92

🔗 View full report

[samajammin]

I wonder how important this feature is given that users could just swap for liquid staking tokens?

[wackerow]

Probably less important. There is still a difference between adding more ETH to the pool, compared to just buying someone elses stake, but I hear ya. I think it's still worth leaving this in.

[minimalsm]

I think we should be more explicit here. People often fluff this section with irrelevant information.

**Has the wallet's smart contract code been audited?**

<!-- If yes, provide a link to any audits. -->

**Does the wallet have an internal security team?**

<!-- If yes, please provide details. -->

**Any other security testing that should be noted?**

<!-- Please note any other security precautions taken. -->

The final point is potentially unnecessary but I think that it might help inform future iterations of the listing criteria.

[minimalsm]

@corwintines thoughts on this?

[corwintines]

Will put this in the security section.

[minimalsm]

Agree that we don't care about alt L1s like AVAX here but what about sidechains like Polygon?

[minimalsm]

Are we going to use this information? We should probably ask for exactly what we want if we are.

[wackerow]

I don't see this explicitly in the design right now. @nloureiro Was there a plan to include these?

For comparison to other areas of the site, we have the socials in the staking-products.json for each product, but we ended up not adding these to the product cards that get rendered. Agree if we decide to not include this in the design then we should probably remove the question.

[corwintines]

Im ok if these arent in v1 of this release, but I do think at some point showing this information would be ideal.

[minimalsm]

Im ok if these arent in v1 of this release, but I do think at some point showing this information would be ideal.

Then perhaps we ask explicitly? It'll save a bunch of time in the future.

Discord server:
Twitter:
what else?

[wackerow]

Open question for discussion: Should an active development team be noted as an absolute requirement?
Also, what defines active?

My take is this should be a requirement to keep users safe. Ethereum is still relatively young and has many upgrades being rolled out, and listed wallets should have developers maintaining the codebase and tending to bug reports.

Not sure what the cutoff should be though for an "inactive" project... Perhaps either an official announcement, or no code commits for > 6 mos?

[corwintines]

I do think an active development team is a requirement. Just last year there was the EIP-1559 upgrade that required wallets to upgrade as a single example where there are changes that wallets would need to support. If anything this is almost the main requirement out of all of this.

[corwintines]

Note: I can remove the markdown version of this if we are content with use the yaml forms

[wackerow]

The yaml looks great, really nice upgrade for those going through this. Would approve, but I assume we want to update the listing policy on the site with this PR as well... should this be in draft in the meantime?

[corwintines]

Good catch @wackerow , ill update that

[corwintines]

Actually was looking into the suggest product page, it just links out to https://github.com/ethereum/ethereum-org-website/issues/new/choose. I think we are ok in this PR. I do think we will make a separate wallet page as we get to the listing policy this sprint.