# CROPS for the Ethereum wallet ecosystem | Polymutex & Michael (Berlin Ethereum Day, June 2026)

- Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup)
- Date: 2026-09-09
- Duration: 19:34
- Watch: https://streameth.org/watch/yt-2rIVB8WH_-I
- YouTube: https://www.youtube.com/watch?v=2rIVB8WH_-I

## Description

Ethereum is built around a clear set of values: censorship resistance, openness, privacy, and security. Users experience Ethereum through wallets, yet most wallets today don’t live up to these very values. Walletbeat is L2BEAT for wallets: an open framework that evaluates Ethereum wallets through CROPS values. Polymutex & Michael (Walletbeat) walked through how CROPS values map to wallets, what the current wallet landscape looks like, and what obstacles exist for wallets to fully embody Ethereum values. They covered where the Ethereum wallet ecosystem is making progress, where it’s stuck, and what meaningful CROPS alignment actually looks like in practice for modern wallets.

The Berlin Ethereum Day was a one-day event held on June 15, 2026, during the Berlin Blockchain Week, bringing together speakers from the Ethereum Foundation and the broader FOSS, privacy, and security ecosystems to explore the future of Ethereum and self-sovereign technologies - from technical direction and core values to the challenges and opportunities ahead.

Future Meetups and Events: https://www.meetup.com/berlin-ethereum-meetup/

More information on the speakers and the agenda: https://berlinethereumday.com/

## Transcript

Thanks for coming. We're going to be talking about crops for wallets and how crops values applies to the Ethereum wallet ecosystem trying to rate it on its own values. What are crops? I'm sure that the letters have been defined to death at this conference. I'm not going to go over them again. They are at their core a reformulation of Cypherpunk values in the blockchain era. And at this core they're all about user control. You are digitally self-sovereign. You do not work for the system. The system works for you. &gt;&gt; And why do I matter? So, wallets are how users experience Ethereum. Crops in the protocol is great and necessary, but if wallets don't adopt them, then users won't effectively experience them. So, no crops in wallets means no crops for users. &gt;&gt; Why should you listen to us about wallets? Well, we're both contributors to the project named Wallet Scorer, which we'll define in a little bit. My name is PolyMinter, and I want to see Ethereum fulfill its Cypherpunk mission. That is why I'm working on Wallet Scorer specifically, and I've been working to define the methodology that we use to rate software wallets. &gt;&gt; My name is Michael. I want to see the Ethereum wallet ecosystem grow. I'm a contributor at Wallet Scorer, and I mainly focus on wallet attributes and development. &gt;&gt; With that out of the way, let's actually get into the crops values and how they apply to the Ethereum wallet ecosystem. We're going to go backwards for the letters, so we're going to start with the S for security. At its core, security is about ensuring that your account remains yours, right? And we're going to symbolize it with this lock icon at the top of the slide for reasons that will be obvious in a little bit. How can wallets embody security, the S for security? One way in which they can is clear signing. I think this is fairly uncontroversial, right? This means that as a user you should be able to understand what the transaction you're about to sign is going to do before you sign it. This is how we avoid situations like the BitPay hack, which was literally the largest computer hack in history as defined by amount of lost funds. And the firm foundation has launched the Clear Signing Initiative and make sure that they're the party for the registry as a result of this. Beyond Clear Signing, the wallet has a responsibility for alerting the user if they're about to do something that looks deceitful through a variety of heuristics. Uh this is things like scam contract databases, this sort of thing. After that, you also need as a user to be able to air gap your keys, right? This is through the use of hardware wallets. So, software wallets have to be to integrate with hardware wallets to make sure that user can do that. This adds defense in depth. As a highly secure and sensitive piece of software, wallet needs to be able to be audited to make sure that their code is secure. This is through security audits. It's also for bug bounties to ensure the security researchers have eyes on the code. And it aligns incentives to ensure that the wallet is secure. Wallets have a responsibility to protect their users. This includes being thrown into ratchet attack type of situations. And while that's never a pleasant experience for the user, then we can still do things to make sure that the damage is minimized. This is things like decoy wallets. This is things like unlock codes. This is things like spending rate limits. Similarly, to avoid the minus 100% API case, there is the account recovery so that if you forget your seed phrase, you're not completely out of your funds. And lastly, since wallets, as I mentioned, is a highly secure and specialized piece of software, it needs to be to be developed in a ways that follows the best practices of secure software development. This includes secure random number generations, secure key material handling, and locked down permissions for Android applications and Chrome extensions and the like. That's it for security. Let's move on to the P for privacy. Privacy is all about selective disclosure, making sure that you you a user is the one who gets to decide what you share and what you don't share. How does that map to wallets? I think the most obvious and least controversial is that there needs to be private token transfers in wallets, not just as an option, but by default. Right? This means that you and the recipient are the only ones by default that get to know what amount got transacted on chain. But beyond that, there are other aspects of privacy. So, one for example is that you should not be able to be tracked across applications as you use Ethereum. Right? In the same way that a web browser doesn't let websites track you across other websites. And in Ethereum that's not the case yet because you reuse addresses everywhere. And that needs to change. These two privacy aspects, the uh private token transfers in I buy solution, together require that we move beyond the current model of one address per account to one where uh accounts are are a set of addresses together. And that itself adds UX challenges for sure, but also privacy challenges. One of those challenges is that uh even though those addresses themselves are public, they must not be linkable to personally identifiable information about yourself because otherwise that ruins the purpose of making them private. And similarly, because you have many of them, then you need it to be the case that it is not possible for someone to correlate those addresses together as belonging to the same account because if that becomes possible, then there was no point in using multiple addresses to begin with. Is that not everything for privacy? Another thing is simply that uh wallets should not be spyware. You know, controversial opinion, I know. Uh but you know, some wallets right now will uh leak your browsing history or your signing history to their centralized wallet providers. Or they will account they will include um libraries for user tracking for like, oh, this user clicked this button at this time. And uh you know, it's through services like Sentry, which you might remember in 2022, the Slope wallet on Solana included and the part of the information that was sent to the Sentry platform that they used was the seed phrase of the user. Which uh you know, I'm not saying that that was on purpose, but it's very easy for this type of thing to happen accidentally because wallets deal with a lot of sensitive information, and so that sort of thing needs to be limited if not uh removed by default. Next, let's go to O for openness. Openness as it relates to wallets means that the way in which the the wallet behaves must be transparent to you as a user. What does that mean in practice? The most obvious is that you should be able to read the code of the wallet and understand it does, right? That's fairly uh self-explanatory. But beyond being able to see the code, it's even better if the code is licensed under a free and open source uh software license because it means that you have extra software freedoms, the freedom to mix, to share, to adapt, to make sure that the software is more meaningful to the users as new. There are There is probably a wallet development entity behind the wallet you're using, and it's also important that the way that that entity is funded is transparent to you because this lets you ensure that their their incentives are aligned with you as a wallet user. On a day-to-day basis, one way in which this manifests is that you will pay fees as you use the wallet. This is through things like built-in swaps, built-in bridging, and so on, which the wallet may charge a fee for, which is a fair practice to do as long as it is transparent to the user that this is what you're paying for, and now you should be able to see where each part of your ETH is going. Also, similarly to fee transparency, another thing that you do as you use Ethereum is you create MEV. And similarly, in TradFi, the way that payment for order flow works as a business model for for transactions, wallets have a similar model where they are able to take fees out of the MEV that you generate. And if they do, then in the same way that they should disclose fees, they should also be able to disclose the way in which they treat your order flow data because that's valuable, and that's another form of fee taking. Lastly, on openness, the way in which the wallet itself is developed and released needs to be transparent as well. This means public change logs. This means reproducible builds, hermetic builds, pinned dependencies, all those sort of things to make sure that the wallet that you're actually running matches the one that's in the repository that you can see. Lastly, in the CROPS acronym is the CR for censorship resistance. Censorship resistance is all about making sure that no one can stop you from using Ethereum. How does that map to wallets? Probably the most obvious way is that you should be independent from any centralized dependencies. The L1 RPC provider is probably the most obvious example. You should be able to run your own node and point your wallet at it or at least use like an alternate RPC provider. This makes sure that you're not dependent on the on the wallet's default. But that's not enough because wallets modern wallets these days rely on way more than just chain data. They rely on things like price quotes and bridge bridge aggregators and asset price listing and asset icon registries and scam alert databases and account recovery services and account backup services. All those are non-chain data and they're all either need to be optional dependencies or they need to be dependencies that you can swap with self-hostable alternatives. Otherwise, you're still dependent on centralized providers. You need transaction inclusion for censorship resistance both at L1 and L2. All L2s, at least by the definition of L2Beat, have a forced inclusion transaction mechanism. But again, you need to solve for the last mile problem of wallets, meaning that the L2 itself may have that functionality, but if the wallet doesn't let you use it, then users in practice do not get that benefit. And for CROPS to make it all the way, we need that in the last mile. If the wallet provider that you the wallet entity that is behind your wallet turns evil, you need to be able to move to another wallet. This is what account portability means, but it's not sufficient that you can just import your account in other wallets. You also need to make sure that the previous wallet you're exporting from cannot retroactively rug you, which could happen for example if you were to delegate your account to a smart contract that was under the control unilaterally of the previous wallet that you were using. So, it's important to make sure that you don't do that to begin with. Similarly, when you give other applications your permissions to spend your funds, you need to be able to revoke that and manage that to make sure that you cannot be rugged for the same reason. And lastly, you need to minimize your trust on centralized operations. Uh this is things like light clients for L1 and L2, right? L2s should also support light client verification. That's not currently the case for L2s. Again, this is a last mile delivery problem. It's great that there's all this research that goes into the protocol to make sure that those things are possible in theory, but if they're not actually done in practice, then users do not get those benefits. Beyond CROPS, I'm sure that there are a few things that you will agree are valuable for wallets to have, but they don't neatly fit into any of the CROPS letters. And they're all generally around making sure that the wallet plays well in the Ethereum wallet ecosystem. This is things like browser integration to make sure that wallets integrate with apps in a way that's transparent, open, and competitive that ensures that the ecosystem has open competition that wallets are all on a level playing field. Similarly, for hardware wallets, it's important that you as a hardware wallet user has a have a variety of software wallets that you can use with that hardware wallet or vice versa. If you are a software wallet user, you should be able to use a variety of hardware wallets with it. Address resolution, right? Browsers have supported resolving DNS domain names since forever, and some wallets still don't support ENS resolutions. Like, what are we doing? Chain abstraction, we live in a multi-chain world, and that adds UX challenges and complexity and fragmentation that the wallet has a responsibility of dealing with. And there are so that's things like trustless bridging that needs to be done in the wallet level. Account abstraction. Uh the last few Ethereum protocol upgrades have added a bunch of account abstraction features. Again, there is a last mile problem where yes, the protocol might support them, but if wallets do not do that, then wallet then users do not get those benefits in practice. You need to solve for the last mile. What are those features? One of them is transaction batching, the ability for a single transaction to contain multiple actions so that you can have better UX for DeFi and whatnot with token spend permissions being bundled together with the same action that happens. If you take this all together, uh this is a pretty diagram of a lot of things that matter for crops in wallets. And if you squint hard enough, it looks kind of like a cherry blossom flower, which is the uh you know, infinite garden references here and also the inspiration behind the wallet beat logo, which I will now let Michael talk about this approach. &gt;&gt; Hello. So, thanks for the new text. And with all of that being said and described, this framework to measure crops in wallets is actually existing. The same values that crops stands for also lives within wallet beat. We introduced ourselves earlier as contributors of wallet beat, but what is wallet beat? Wallet beat is a rating system for Ethereum wallets. So, we we use a framework to evaluate their wallets across five dimensions: security, privacy, transparency, ecosystem alignment, and self-sovereignty. The same exact values that crops stands for. Now, let's take a look at where we are today and see and see how these current attributes uh are rated based on different wallets. For this comparison, we'll be looking at three three attributes. First, source code availability, L1 provider independence, and private transfers. We'll also be looking at wallets such as Ambire, MetaMask, Rainbow, Rabby, and Safe. The reason we've chosen these attributes because they reveal interesting patterns across wallets. And also, please note that this is not any form of of endorsement or criticism of any wallet. We've chosen these wallets because they have relatively complete data in Wallet Guard, which allows for more meaningful comparison. Source code availability. So, I think in this area the ecosystem is doing relatively well. Most of Most of the Ethereum wallets right now are open source projects, so I think for the wallets that we are looking at today, they all pass. And for L1 provider independence, this is the attribute that allows users to configure their own L1 RPC provider before doing any requests. And if you can see at the results, it's a mix of par, pass, partial, and failure. And one interesting observation here is that most wallets today have a partial rating, meaning while they allow configurable RPCs, it would only be after a certain amount of requests made to by the wallet's default provider. And for a wallet to pass the L1 provider independence attribute, the wallet should be able to configure the L L1 RPC provider before any requests are made to the default provider. And lastly, for private transfers, I think this is an area where the ecosystem is a bit flag lacking. Most of the Most of the wallets today doesn't support private transfers because Ethereum itself is transparent by default. But nevertheless, it's still possible. Technologies like stealth addresses, Tornado Cash Nova, privacy pools, Railgun make this all possible and hopefully via Kohaku soon. Well, you might be saying, well, this data are all nice, where do we go from here? We need to answer the question, what does a crops wallet look like? Well, thanks for pulling me to this discussion earlier. We have a little bit of context on how to answer this question. First, a wallet should be verifiable. Users should at least be able to verify the wallets they're using. But, verification is not the only case here. Wallet should also implement the foundations of a proper Ethereum wallet. Should provide basic security, privacy, and also lets users take control of their full account. After that, a wallet can now move on to becoming an Ethereum standard wallet. A wallet that follows ecosystem standards, embraces interoperability, and adopts ecosystem practices. Lastly, a wallet can now move on to be to being a trust minimized wallet, where users rely less on the wallet provider, and still retains the properties of being transparent, secured, and self-sovereign. And what we have here is not a it's not just a checklist. We move from verifiable foundational to Ethereum standard and trust minimized. What we have we have What we have here is a maturity framework. Stage zero, stage 0.5, one, and two. And this is the stage system of Wallet Beat. So, Wallet Beat took inspiration from L2Beat's stage system. L2Beat's &gt;&gt; Uh Rollup. &gt;&gt; Yep. Rollup maturity framework, wherein Wallet Beat introduces the same about same stage evaluation framework, but for Wallet Beat, it would be for wallets, Ethereum wallets, rather. So, what is the role of Wallet Beat? &gt;&gt; All right. I'll continue on. &gt;&gt; All right. The role of Wallet Bytes is to push the Ethereum wallet ecosystem forward and a good example of this was we went by there a few months ago now where as part of Wallet Bytes research into L1 provider independence, we showed that a few wallets don't get this right. One of them was Empire. They actually had a partial rating which means that you could configure your L1 RPC provider and the wallet would use it and would also support basic functionality with it. But you could not do so before you actually create an account and before requests are actually sent to the default L1 RPC provider by default to do things like check your balance and what not. We published this and shortly afterwards this the CEO behind the wallet development company behind Empire who realized that yes, this is something that they should have probably taken into account and then they promptly fixed it. And so now Empire is rated as green on the on the on the Wallet Bytes rating framework for L1 provider independence. Shortly afterwards MetaMask more quietly fixed a similar issue where while you could configure your L1 RPC provider, you could not add tokens if you were using such a mode and you and you remove all connectivity to all services beyond the L1 RPC provider. They fixed it. Now you can actually send tokens without anything but your own node in MetaMask. I'll go ahead. &gt;&gt; So with your values, your values only matter if users actually experience them. Your value values have always been existing since the beginning. But the challenge has always been making these values measurable, visible, and actionable. And Wallet Bytes brings that to wallets. &gt;&gt; Thank you for your attention. This is all the socials if you want to contribute. Please visit walletbytes.info to learn more to see where we're currently are. We can always take contributions for data about wallets. We also have a very neat wallet testing playground that Michael has worked on quite a bit. You can test your wallets, just click around. It'll test things like do you have clear transaction signing? Does your wallet alert you if you're about to do a scam transaction and all that? And then you can turn this into data that you can submit to Wallet Scrutiny to make our database richer and have it all feed into the ratings that Wallet Scrutiny uses to produce its ranking. Thank you for your attention and let's do crypto wallets. &gt;&gt; [applause]
