# Building a Truly Trustless Ethereum Wallet for Android | Dirk Jäckel (April 2026)

- Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup)
- Date: 2026-09-25
- Watch: https://streameth.org/watch/yt-EmC9nMLDQ0w
- YouTube: https://www.youtube.com/watch?v=EmC9nMLDQ0w

## Transcript

Hi, I'm Durk. I'm here to talk about a serverless and trustless wallet for Android, which doesn't exist uh at the moment. Wait, my clicker doesn't. So every wallet uh you have been using so far um did talk uh to a centralized uh JSON RPC server or another centralized server by the wallet develop provided by the wallet developers. Um, and that means in general that the wallet cannot verify what it gets from the JSON RPC server and it has basically to trust that server and um, yeah, the the wallets just don't care um, apparently because the data is there. They are not using it. Granted, it's not that simple, but I'm confident that I have a solution for this problem that I will present in this talk. what are what are the problems with centralized JSON RPCs or with RPC servers? So two companies basically are running most of the uh service and that is Infua and Alchemy and in 2020 for example they were pressured to refuse service to certain countries. In uh also in 2022 they were forced to not serve certain wallets uh that uh were on the off list of offic list. Um they can go down then they might not be available that also happened in 2020. Um they can surveil you. They basically you only talk to one instance usually and they get every every question you ask them. uh they know that you asked the question and they can uh record that. Not that they are doing this but they could and also they can deny your service on arbitrary because of arbitrary things that they think why you should not be able to to get data from them. But what about if proofs? Um if if get proofs can uh verify data for you. So basically, Helios works as a as a proxy um between your wallet and the uh um RPC server and it can uh ask for proofs from the um RPC server and then it can validate data that it gets. But what it can't do is it can't give you a transaction history in a verified manner. it uh it doesn't change the a availability problem and it doesn't change the surveillance problem. Bitcoin by the way solved this problem in 2008 already uh with SPV with simplified payment verifications. that was already in the weight paper. And in 2011, the first Android wallet was available by uh Andre Schar and also Electrum also a very uh um very popular sorry very popular wallet uh for desktop and uh also um Android was available also in 2011 already. So that was 15 years ago. Ethereum on the other hand has hundreds of millions of wallet users but they are all going through RPC basically and cannot verify what they get and what I already talked about. So no mainstream wallet runs trustless yet. And then there is the EF mandate which was already mentioned by Ino um which demands that uh Ethereum is censorship resistant, open source and free preserves privacy and security and I would add the P could also stand for permissionlessness. Um and yeah uh the mandate states crops must remain as an indivisible whole. the Cena Quanon of all Ethereum development priorities which cannot be displaced. So that's the the short version of the mandate. Um the mandate even talks about RPC directly and sees it as a problem. Let me give you a bit of time to read this because I think it's important. Okay. Um so in particular it mentions that for end every intermediary option there should be a non-intermediary option and called the zero option. Um so right now the intermediaries are alchemy and infuga and others. Um and now to the zero option. So the intermediate path is clear. The wallet talks to a server and that server talks to Ethereum. And um this is my proposal. So this project is my proposal for an intermediary free path. Instead of asking a centralized server, we ask the network. Instead of relying on two companies, we verify everything against sync committees. Instead of a choke point, we have Z the zero option. Why? How is my proposal crops uh native? Um it's uh there there is no vendor sitting between the wallet software or the wallet device and uh and the network. It's open source of course. Uh it preserves privacy a bit better than the RPC option. There's still privacy concerns because you are talking to other servers and they will know your IP address and but they will not not one server will get all the questions and give you all the answers but you will talk to tenth or even hundreds of servers and only they only get one question from you in the ideal case although that's random actually. um security. Yeah. Um uh everything is verified and uh leads back to um a sim committee. I will explain that soon. So what are the parts of this uh approach? Sun committee is the the basic the the yeah the trusted state route and block hash. A historical accumulator I will not talk about this in this uh talk is about verifying historic data premerge data or premerge blocks. Um the transaction history we will get via true blocks via IPFS. Um the block data itself we get via deferto and the state also via um the um execution layer via snap. And to submit transactions um we just broadcast the them to the um execution layer. So the trusted route is sim committees. It was introduced in the altera um hardfork I think already three years ago. Um the sim committee is a set of validators that are selected for every 27 hours. um they sign every beacon chain uh block header and and aggregate those signatures into a BLS signature and the wallet can decide to accept a twothirds majority of these signatures. So sometimes not everybody who is assigned to the s committee already really participates. So the number of signatures might be lower than than 512 but 2/3 is good enough. How does the bootstrapping work? Um the trust anchor is um a block um sorry is a beacon block route that uh at the build time of the application is baked into the application and with that trust anchor you can verify that you get um that that the bootstrapping sorry it's a bit complicated um so that the signatures you get really um sign what that you really get a signed state route and not yeah a state so umh I don't know how to how to phrase this um uh sorry um so you have the trust anchor that allows you to verify that the sum committee is correct that you get because you can check that it leads to this hash that you have in the app. And as a user, you could also add later hashes. If you if you don't trust the hash that I put in in the library, um you can also put in your own hash and have it verified against that. And then you get the sync committee at the time of that block hash and from that you can get the next. So one sin committee gives you the next sin committee and you can walk into the future up to to the present. Um this is done by light client updates. Um and this way you can you can uh verify the snap response that you get also from uh um from the execution layer. Um so how how is a snap? Uh so you get the for example the balance for uh a wallet address and a proof and you can walk that proof up the Merkel tree uh to the state route and you have the state route verified already by um the sun committee. So that's how how how it works and yeah how do you get the transaction history because that is not not available in a in an indexed way. Uh in Ethereum there is a project called true blocks that um creates an index from addresses to relevant blocks and transactions in that block. Um so you get a block number so you have your own address. you check it against the bloom filter and then you get um the blocks that are relevant for your address, the block numbers. These blocks you can fetch via um the execution layer and verify them against the block uh route um which you also got via the syn committee already um and then extract the transaction from that block and put it in a list that the user sees. Um this is all of this what I talked about is already implemented in my library. Yeah that's the next slide actually what's working. So the peer discovery is working the um talking to the peers is working talking snap uh state uh data is working the um the consensus layer client is working. um the verification is working of the proofs and the lookup of uh storage. So for for example, ERC20 balances is working. Um true blocks is already implemented and uh working and the bootstrap is also implemented. Uh what's not working yet is um the pre premerge accumulator. So verifying blocks that were premerge and also postmerge historical data. So Ethereum is pruning data that is older than a year currently and that data also needs a separate way of verification. Um yeah ENS resolution is also something that is not yet working. only parts of it are working on Android already, but I'm confident that I can port everything to Android soon. Right now, it's a demon running on my laptop, and I talk to the demon with commands like get, block, etc. Uh, yeah, background zinc is also not working yet. Um, and integration with the real wallet is also not not available yet. So, what are the trade-offs? Why why didn't somebody do this before? Um the bandwidth costs uh can be high. Um um you have to basically go from a trusted trusted route to the present. Um this might be three months or so. This that is uh not that much data but you still you need to keep up with with the chain. So my idea was to um check at night if the phone has unmetered internet and has is charging and then do the the daily sync so that when the user starts the app the next day it's already almost synced at least it's only missing a day. Um the disk space with because of true blocks is quite high. Um to mitigate this um it makes sense to when you use the wallet you create a new address send some funds to it then you don't have to go into the historical data that much. Um yeah cold start I already mentioned and maintenance is also a concern. So right now the uh RPC servers they follow all the hot forks but in this scenario um the developer of the library so me uh has to follow the hard fogs and do a release whenever whenever a half hard is imminent not and actually not necessarily only if the hard fog changes things that are relevant to the wallet. So not every hard fork uh uh requires this. [snorts] Um yeah, this is how you can try it yourself. Um at the moment I have to admit that it's a proof of concept level code, not production. So it serves as a proof that it that all this is possible what I claim. Um and how how can you help me? If you're a wallet developer, I I'd be interested in what you what you need additionally to what I already provide. Um, also there is an option to do this also for iOS. Uh, but that would mean that I have to convert all the Java code to Cotlin code because then I can use Cotlin multiplatform uh to yeah to also create an iOS app out of the source code. Um, what is already possible is to also have a desktop app. So I could generate from the same source code a mo an Android mobile app and also a desktop app. And yeah, that's it. It's about time we had an alternative to RPC at least for mobile wallets. That's what I'm trying to build. Thank you. [applause] Quest questions, of course. >> Maybe I have one. You mentioned the the things that are like not working yet. Um, is there anything that's like critical and you're you're not sure if you can figure it out or it's just about >> just I have to put in the time. >> Okay. I I have a clear idea for every and also this is not a for example the um merge accumulators they were already used in um in the portal network client and they worked there already so I know I can use them because I already used a portal network client in Java that had these uh so so it's just a matter of of really implementing it and also providing the data because the portal network was also providing the data that is necessary to do the verification but everything that I listed there's nothing that has a higher risk I would say I mean there can always be a risk >> and what's your plan for like you know if it's fully built like you mentioned the maintenance like in a long term like are you planning to turn this a product or like how is >> if I can't find wallet developers to use it I would probably take wallet for example it's the open source wallet and just put my data layer beneath a wallet and talk to League about that because it's his uh his software. Um or I could also imagine writing my own wallet uh application but for now I want to focus on the library. >> What would you say would be the main reasons for existing wallets or existing wallet developers to want to use it? Yeah, I mean they are probably happy with the RPC uh path that they or maybe they are not. I mean the the I don't know about the wallet developers. I only know about the Ethereum Foundation. The Ethereum Foundation now has this mandate and it basically says we should support this kind of solution. I hope they do. Um but as a if you look at Metam Mask or any others I don't know if they have an incentive it I think this incentive can only come from the users. So if the if there's one wallet that does it differently then users might demand from Metam Mask that they should also switch to a to a better solution. What would you say are like good phrasings to explain in a practical real world sense what the advantage for the users is to not have an obvious less exploitability. Um I mean since yeah probably the censorship resistance is is the more plausible path because I mean they they do not expect uh Infuruga or Alchemy to exploit uh this problem. Yeah, it's a tough cell. I >> So if if like at the unlikely scenario that they would be interested to exploit it, what would that mean? What what could how and what could they exploit? Um for example, they could fix the balance or or fake incoming transactions or uh yeah that's one >> there was al already an issue a few years ago and this is already a hot topic many like I mean I think it was actually metam mask that a lot of addresses were there was like a data leakage or something >> it's also because of privacy like you're more trackable like your IP address and everything you're disposed right >> so if you don't go through the RPC then it's more private And yeah. >> Yeah. >> Yeah. But also there is a case to be made that you can basically hijack any RPC especially in the jurisdictions like that that have very you know invasive DNS hijacking all that. So and there's there's always a question of how good your wallet is checking those kind of stuff. There's also ME because what if you are talking to Infura I think you get you can get [clears throat] M right probably. So there's a lot of things to discuss here a lot to to to use. >> Um if I could add a couple of questions. So my first question would be uh have you ever thought about adding so I think that it is either risk zero or 68 that are currently running uh proving for the whole Ethereum chain. So you can kind of save a lot of space potentially by using zero knowledge proofs of the uh of the chain. >> I'm I think I I don't understand how that would would that give me historical data or um has it to do with the state? you potentially you wouldn't have to don't they only >> check a lot of things beginning with three months back um and you know >> but what they are proving usually is that somebody executed the the um um the transactions like the um contracts isn't that what what they prove that they were executed >> uh >> that's how I understood it >> I think that they're currently able to be proving the whole so basically the execution layer and the consensus layer. So >> maybe we talk after the talk because I don't understand how how that would help me. >> Yeah. And my second question would be so I've taken a quick look at the repository and as you saying yourself you have a lot of stuff going on with Java and one of the problems as you said that with the hard forks you would be having to add the new implementations in Java for to support the hard forks. Um have you thought about probably just uh moving a part of the of that code to a well supported rust sort of stuff like alloy because you can quite easily integrate it into a mobile Java application >> actually I want to move to cotlin to be able to use cotlin multiplatform >> so I mean it's the same thing you can you can you know uh and then you get you just get all the updates out of the box because >> okay yeah I could I could embed a a native library and for example example with uh by using Nimbus which is a smaller variant of of the consensus layer actually it's a good thing I should talk I should I should think about yeah I agree but right now I'm trying to do everything in Cotlin and not uh not even Java I mean right now it's it's Java code but it's uh to be thrown away anyways I think so. >> Yeah. I also wanted to ask uh how is the how was it what was the connection to IPFS? I didn't really understand what was >> Yeah, actually that's a good point. It's uh so the true blocks index is currently residing on on IPFS but it could also reside in swarm or any other um data layer that provides um a hash that can be checked against the data. So that provides very that the data is not changed afterwards basically that's the the thing that it has to have which IPFS has has and a swarm I think also has so it doesn't need to be in swarm it could be also it doesn't need to be in IPFS it could also be in swarm >> yeah so is there like a mirror of the state of the IPFS >> no it's uh it's just the the index uh is from the account to the relevant and blocks and transactions in those blocks. That's the the index and a bloom filter in the middle to know where you have a hit and where you don't have a hit. >> Okay. >> It's basically a database uh in files on IPFS. Does that answer your question? >> Okay. Okay. Good. >> Yeah. And and perhaps also a second thing uh you mentioned that you might like if you want to shrink the disk usage that you have in the application you might as well just transfer all of your funds to a newer wallet address to like a newer address. Is this something you would be planning to do like >> internally internally without the user with us? >> Definitely not. Uh I would ask the user to do it themselves because I don't want to be uh responsible if something gets lost in the process. And also I would not recommend sending all your funds to the new address but only maybe a hundred euro worth of uh of ether or whatever as you do with your wallet that you have in your pocket. You also don't put your whole uh savings into your uh real wallet. That would be my recommendation. >> Yes. Um, is there something in the Ethereum road map that would change uh coming down the pipe soon that would change how you approach this whole pro uh project? >> So, not the whole project, but there are some some things that I suspect are getting easier. For example, the upcoming vocal trees might make it easier for me to verify stuff. And also, as I mentioned briefly in the slides, but I didn't talk about it. There's also pure e meta that would allow if it's not only available via RPC but also available um on the CL uh layer or the E layer um it would allow to get rid of two blocks for example because uh it it's a way to get past transactions basically uh but that is not even in the next hard fork so we will But my hope is that it will also be available in a nonRPC way. That would be really helpful because true blocks is really a big burden. If your wallet is very old, then it's really a data problem. >> Another question you uh your um whole presentation talks about on Android solution, right? uh and you mentioned that with cotling [clears throat] you would be able to uh create an iOS version as well. Uh is it also true that there's no such solution for iOS? >> Yeah, as far as I know every wallet either uses RPC or some self-made uh centralized server and also desktop wallets. I mean if you don't have a full note then uh you have the same problem on the desktop as well. >> See >> are you planning to um to have an entry in this market for browser extensions because I I think I have the impression that that most people or most people do a lot of stuff in browser extensions um like Metamas and web and stuff. >> I think that's the one platform I'm not going to cover. >> [laughter] >> I mean, somebody else can do it maybe in the same way as my project does it, but I'm probably not doing it. It's It's just not something I have much experience with. So, I mean, maybe I shouldn't rule it out. Given the right circumstances, I might do it. >> Okay. Thank you. Then you can chat with her after. So yeah, thank you. [applause]