Privacy on Chain: What Stealth Addresses Solve, and What's Still Ahead | ETHTaipei 2026

[music]

Thank you. Thank you, everyone. Thanks for coming. Let me adjust this. Okay.

So, my talk of today would like to focus on what I think is the current aspect of privacy on chain, especially around stealth addresses. Stealth addresses are the technology that I think most of the protocol wallets will integrate in the coming years. And you don't have to trust me on this. This talk will be exactly proving you this through my experience and what I see with the market out there. I didn't want to make it too technical, the talk.

Will be a mix of though and especially will be a path to show you where also I was coming from, where we are now, and where I see the space is going in in this specific technology. So, my background, I'm a CTO of Fluidkey that I co-founded. And Fluidkey is a self-custodial wallet that lets anyone invest and connect with traditional banking rails for international payments while holding all their assets on chain. Now, I read you this definition not because I wanted to tell you exactly what Fluidkey is, but just to stress one thing. I have never mentioned inside the word privacy and the word stealth addresses in what we do.

Even though Fluidkey is entirely 100% powered by stealth addresses. What does it mean? Every time you do a payment, that payment goes to a new address. So, when people pay you, they don't know how much you have, what you did in the past, where your assets are, what's the total, what did you invest, and so on. And this is important for this reason.

The reason is that blockchain needs to be an improvement in user experience, not a regression. If you speak with a person uh, with the what they usually do, they pay by card and the payment settles in second. They complete uh, payments very fast. They log in in a app and see the full balance. But most important and it's something given for granted in the space, they pay without exposing their net worth.

Now, if you go outside, you meet a person that's not in a blockchain space and you explain them a blockchain is great, but as soon as you make a payment, uh, someone is able to see all you have, this is like a an I'm I'm not game for someone that is not in the space because it's something that you know, I go with my bank and no one see how much I have in the in the money in the in the bank when I do a payment. And this is a big difference and this should be addressed as like an important part. First of all, stealth addresses is a concept, not a recipe. What do we mean by that? The concept defines the outcome.

It doesn't prescribe one implementation. So, there are many implementation. We will see through what is the most common one, what is the future one and where we we we come from, okay? So, a stealth address means that given two transactions and two addresses, an external observer cannot say that the two addresses are owned by the same user. So, on the left, this is the traditional thing that today happen.

One address, multiple transaction, everything linked. On the right, this is what a stealth address is, okay? So, you have two separate addresses, two incoming transaction, both addresses cannot be linked together just by looking at them on chain. They can be two different people as they can be the same person. Now, just to understand this stealth address is a concept that's important for the rest of the talk, I'll make a parallel to explain that.

Okay? I come from Italy and the parallel we'll make with a pizza. Okay? So, a concept that allows many valid recipes. So, pizza is a concept, recipes are the different way of doing that.

Okay? So, this is the concept and then we have different recipes inside. You can make Neapolitan, you can a Roman and you can even add toppings different on top. You can make deep dish. All of these are pizza.

They're made differently. A concept brings also boundaries. Boundaries means things that must be respected that otherwise break the concept itself. Pineapple on pizza breaks the concept. Okay?

So, it doesn't work. Okay? Now, um privacy is the concept boundary Instacart addresses. Okay? So, that's not negotiable.

UX is the product boundary that I want to give. Let me explain you what it means. It means that with Instacart addresses, I need I want to have a great UX, meaning that if I want to pay you, I don't need to call you before unless you know, knowing your username, that's that's it. You don't need to be online. Okay?

I can do the payment even with the other person completely offline and tell him later because this is how traditional finance works and UX must be respected. Okay? And the sender, so I do the payment. Of course, I cannot spend then the money of the user. So, what does it mean?

I cannot generate an address with a private key and then send a private key or I pay you there. That doesn't work. That's not the would be a an easy hack for that. Okay? So, let's see how we can get to a setup of Instacart addresses.

The first example are two obvious example and this is not what we normally do. But, I'm sure you're familiar with this setup. So, the first very one, I am the receiver. Every time I want to receive a payment, I generate a new private key. A private key is a new address.

If every time they pay me on a new address, uh Oh, the concept is kind of kind of match. Every Every transaction goes to a new address. The problem is that, uh it doesn't match the user experience. [clears throat] And also, it has a problem. I have to manage all these private keys.

One step more, they invented seed phrases. We all had wallets with seed phrases inside. The seed phrase is a a list of 12 words, there. What I did, I went behind. Okay?

It's a list of 12 words, inside, that from that you can generate addresses that looked from outside, that they cannot be linked to each other, unless, no, you control them, you move money between them, and so on and so forth. This is a better experience, because I have only one seed phrase, but still, there is no UX. Cuz I have always to send a new address to who pays me. This doesn't work. So, now we start getting to what is the current state of stealth addresses.

And And this slide, I'm going to show you how the current setup of stealth addresses works. So, we have a sender. The sender want to send me a payment. The first thing it does is look on a public listing, a phone book, okay? So, it's an example of a phone book, the old-style phone book, where everyone had a name and a phone address on it.

Okay, now will be the name, and what's called a viewing and a pub and a spending keys. So, two keys. So, two addresses for me, okay? One is called viewing and keep this term in mind, the other one is called spending and keep also this term in mind. But, it's public, so no one can everyone can see them, okay?

So, open the book, read my name, find that. What does this book mean means means that I as a person that wrote my information public information on this book I can have an infinite amount of mailboxes where send a payment. A mailbox is an address. I can have an infinite amount of addresses where that payment can be sent. Why this is great?

Because if it's infinite, no one can guess which is mine which is not. But, the sender looking this information the phonebook plus basically picks one of these mailboxes randomly, okay? So, he knows which are my mailboxes an infinite number of mailboxes and he picks one randomly. This randomly pick is put inside an announcement, a ticket, okay? This announcement along with the other announcement sent by other people using stealth addresses are published on the blockchain.

Of course, they're encrypted, okay? On the other side, there is the receiver. The receiver, like any other receiver, receive all these tickets and is able to understand which is theirs and which is not thanks to how cryptography works in in this sense. So, the receiver once understand, oh, I got a payment. Decrypting this announcement is able to see where the payment was sent in one specific mailboxes.

Otherwise, he will have to decrypt all the mailboxes and it would be mathematically impossible, at least not in the lifetime of the receiver. And using his spending private key is able to open the mailbox and get the money. This is basically the concept. So, I told you now more into the technical flow under the hood, the receiver register what they are called a meta address. Spending public key viewing public key.

Why two? Because the viewing public key is used to generate the address and the spending is used to control the address. Why this is important? Because if I want to someone to index these addresses for me or if I want to someone to audit or like no, do like accounting for me, I can share the viewing key is able to see all my addresses, but it's not able to spend money. This is why it's important to keep the two addresses separated.

I can rotate the viewing every year I generate a new viewing key and update the phone book, but I keep the same spending key under the under the hood. So, the sender derives the address we see before, the sender send announcement. This is done entirely on chain, it's an event on chain. The receiver detects the payment with the viewing key and takes control of the payment with the spending key. This is how dots are connect.

And this setup gives three kind of more benefit. First of all, you publish once your public key, the spending and the viewing public key, and you receive forever. The the chance that two people paying me pay on the same address of me is less than the chance than me and you picking two random atoms in the whole universe pick the same atom. Okay? Just to give you the idea how how that that the number and the math helps in this way.

There's zero interaction. The sender can do that by himself. Doesn't need my me to be online. And there is an an un-linkable payment flow. So, money goes every time to a new address.

The receiver, though, now has a problem. So, we solved the user experience on the sender. For example, we in Fluidkey, we connect on a public available ENS that every time returns a new address. So, the sender just need to have an ENS-compatible wallet, that's any wallet as of today, and it works. But now the receiver.

Why? Because the receiver has received money in a lot of different addresses. And what they Sometimes they tell me, "Oh, I can do this. I move all my money into one address." No.

No. This links everything. This un-unchains everything is visible. So, if all the money then goes to one address, well, you have not solve the problem because you link the all the addresses. Addresses are infinite and are free on the blockchain.

Use them. So, the right solution, okay, is having the money on this chain. And if I want to send 3.5 ETH out of those, combine the addresses that it's a kind of a UTXO problem, links the least amount of them for the final payment. It's It's still not the perfect privacy.

We will see how we can improve in the future.

[clears throat]

But that's definitely better than the status quo. Okay? So, what does it mean in this case? That the sum of 0.8 plus 2.

8, the two address I connected, gives me 3.6. So, I have a little bit of dust that will stay in one of these addresses and the rest is going to the new payment that I want to do cuz if I receive money it's because sooner or later I want those to pay out. Now, how can separate addresses act together? We said we receive money in a lot of these addresses.

Now, if I want to pay someone else, I don't want to send them a lot of small transaction until I reach the amount of money I want to send them. I want to send one transaction. The other user wants to receive a 3.5 ETH, not a 2.8 plus a 0.

7 and needs to do the math. So, there are two ways to automate that. First of all, using EAP-7702, so using the EOAs as smart accounts. The other way is the address, the mailbox, okay? The address we generate is not the direct owner.

The address is the controller of a smart account. So, basically, it's what I call a smart stealth address, okay? So, again, it's an address that is controlled by one a one out of one EOA and that EOA controlling the address is a stealth address. Nothing change. The second setup gives more flexibility and we will see why in the future, no?

But, it is that this setup are account abstraction. So, all these transaction, multiple EOA moving money can be batch into one transaction and be sent and this is a good user experience for the payer that has to do one single operation for all of the money. And the money can go in one best transaction with gas sponsorship, that's another big advantage, and multiple stealth addresses can be matched together. But, there are still two problem left and this is where the future comes. The first problem is the key rotation and multi-sig.

So, um we said that all these addresses are generated even if they are not smart accounts, there is a hard-coded key controlling them. It's normal for a person that's not in the blockchain space to go to the bank account and say, "Oh, I want to add another person able to operate with me in this bank account." Or I want, you know, or I want to or rotate the key, change the credential to operate through it. Okay, you call the consentor and through like an identification, they change the credential. Now, if the key is a hard-coded in all of these addresses, that's a problem.

The second problem is address traceability. You probably already figured out yourself. Like, if you pay me and I pay someone else who pay me even for only the small portion of the money sent me, is still able to track what I do with that money. On the other side, if I receive my salary, okay, let's say I get like a few thousand dollars as a salary and I go to pay the coffee at the bar, I don't want to pay $1, $2, $3 out of my full salary, otherwise the person is able to see how much I'm making or at least know see like a large chunk of money that I have. And this is the other and the traceability that's kind of also related to spoke before when it was mentioning the privacy pools, for example.

We have a solution and both can be addresses with a new thing that we should add to control most of the addresses. Let's start from the key rotation problem cuz out of the two is the simplest to understand and also the simplest to understand the proposed solution. That's one of the most candidate that we have as of now as of now. So, till what I say now, it's everything possible, it's everything live, it's how Fluidkey works, but the way it's how other protocols work like Umbra Cash and so on and so so From now on, this is the problem we still have and how the the space is aiming to solve them. We have an existing account.

Existing account have received already different transaction on different addresses. That's how we said before. But now the the user said, "Hey, I want a new configuration. I want new owner key. I want to transform into a multi-sig."

Normal. This is going to be a mess because each of these addresses needs to be updated in its configuration. And you can say, "Yeah, it's a lot of gas, but technically you can do. There's nothing that blocks you technically." But remember that theoretical is a thing, practical is another thing because in practice happen also this.

That's there are people that share the address on an invoice and the invoice gets paid 2 months after. And the invoice contains an address that maybe no one remembers. So maybe the recipient needs to pay you, generate the address, and then pays you after a month or two. And then you rotate everything, you change the configuration, and the new address with the old the key, with the old configuration, pop ups with money on it. This is a problem.

Or other problems with like, "Oh, I pay you on this address on Ethereum. Then in the future I pay on the same address on another chain and the same address on the other chain was not rotated because was never used. So still has the original configuration of the smart account." A mess. So the solution is a very simple concept.

Okay? It's called a keystore. Actually was uh proposed by uh Vitalik uh I think 3 years ago. And at the end I will leave you a QR code. I created a page with some documentation and files around that.

Addresses, so all these addresses around, they don't have inside the configuration controlling them. All of them point to a registry. Okay, so one smart contract and we say that at position 10 of that smart contract it's written who is the owner. Okay? So, we have a a keystore.

This is the keystore. This is the registry. You see, in the registry we have a a lot of configuration. Each slot is a different configuration. Another configuration for Mario, for Fede, for Jen, for Mo, and so on and so forth.

The keystore then itself, this is the technical part, hash all this configuration up to a root hash. Okay? This is basically see as a proof that the content of the hash under is what it is what it what it is meant to be. This is called the keystore root configuration. So, we have one contract on mainnet probably that has all the configuration.

Okay, so I have a one out of two safe and in position 10. I have a one out of three safe. I have a one out of one in position 12. And so on and so forth. Now, on the other side, the addresses of Mario don't contain inside that e this specific key is controlling this address.

They say, "To see the key, go and look on the centralized store." They reference. Of course, if they reference with a normal reference, there are no more stealth addresses because in the addresses it's written who is the controller and you can collect all these addresses. But with ZK, you can make this connection completely hidden on chain through an hash. So, in this way, you have all the addresses pointing to a keystore controlled by one position, but in a way that is not plain visible.

Okay, this is kind of the black magic of ZK. It's not black magic. Okay, if you want to deep dive, you can do it on that. So, the advantages is that the moment I update Mario configuration, automatically, instantly, all of this configuration gets updated because they don't need to go into each other's to update. The address reference the the keystore.

The reference makes makes sense that at the next transaction, they will see the new configuration. But, this is another advantage. This works also for the addresses not yet deployed. Because all these addresses keep as long as they keep reference the same as lot in the keystore, the um position, the configuration, who controls the address, is updated. Um what do we have to prove?

Of course, then comes the transaction to do. We have to do a transaction. What do we do in this transaction? We have all these addresses with money in it, and we need to prove the transaction. So, each of these addresses inside doesn't Usually, when you create a a smart account, you say, "Oh, this smart account is controlled by this address."

And you put the address. With the keystore works, "Oh, this smart account is controlled by this stealth account in it bytes." Okay, 32 bytes. Simple as that. That configuration hash is an hash that's the hash between the keystore position, position 12 of Mario, for example, and the shared secret.

The shared secret is the same randomness secret we saw before when we were looking in the phone book. So, the concept doesn't change. We generate a secret that I have to communicate with the announcement to the receiver. It's the same flow. It doesn't change.

It's just that I use the share sheet share secret together with the position to define a randomness to create every time a new address. And now the ZK proof needs to prove three thing when we want to do the transaction. That the receiver is the owner of the configuration, so has access to a private key and can make a valid signature. That the address is connected to the right hidden location. And that the secret plus the position hash to the secret location.

Now, if three things these three things are put in a ZK proof, you get a circuit that can prove transaction. Uh if you are technical, I will leave a also that a link at the end. We did a POC over that at Eth Dam in 2024, and it's an open source repo on GitHub. So, if you want to look how this circuit was was written. With Fidelic said before with the EIP 288, they're working on for example, what we've wrote in that circuit is not exactly what would be probably the future implementation because they they are trying to make ZK verification more efficient in the system.

This is why these things are not out yet because there's still a lot of debate around which is the most efficient way to put that on them on chain. Before finishing also the second uh uh link is the spend because even with the keystore, now we still have all these addresses traceable. We have changed We have solved the problem of key rotation, not the fact that if you pay me, then you can see where my money goes or how much I have if I connect another address for the future payment and so on and so forth. For that, we need a different setup. And there's already like a good amount of technology around that.

So, let's say you have received all these three transactions in three different addresses on stealth addresses. The best solution we have now is going through privacy pools or railgun, okay? Um They really are ZK native, so they internally they have circuit NZ technology, very expensive like Vitalik was saying before. But they exist. Um but they have a limitation at the moment.

They are manual. They are low. Uh they are very slow. They are um time-consuming. They cannot be automated super easily for the end user.

So, technically you can do already this today. No one does because to move like $12, it's going to take you more than $12 probably that you're going to spend and a lot of time. But the idea is this one. You have money on the left in stealth addresses and you put them on the right in different amounts on another stealth addresses you control. From outside, you cannot connect the input and the output.

You don't know if the output is someone else using the pool moving out money or you you using cleaning cleaning or like dividing the the total amounts. But we need automation. And now we can do that with a keystore. So, the flow of is exactly the same, okay? The flow is we have stealth addresses, go through privacy pool, and we get to fresh stealth addresses.

But since our addresses are controlled by a keystore and the the very the fact that two addresses are owned [clears throat] by the same position in the keystore can be proven through a ZK proof, we can automate saying that money can go from one address to the other through a ZK proof, making sure that the pool is moving money from the same owner addresses, so not sending money to someone else, without who triggers the automation be the owner of the money. So, that could be automated for the end user. So, the user ends up receiving money and instantly having money moved to one or more addresses he controls without even him opening the app and always keeping everything self-custodial. And this, you know, you can use that for split large payments, recycle the dust left in a in a wallet, break linkability among multiple wallets. What is still missing?

Well, I think that good primitives, we just said, uh the infra is connected to good primitives, what we just said that Vitalik was was speaking about, so I don't deep dive that more. And a standardized [clears throat] key store. This is something where probably we are more advanced into, but also all of this depends on an advancement on confidence and cost around ZK. The standard driving, I will just list there. Next slide will be the QR code I was promising you before.

As you can see, like for what concerns stealth addresses and smart accounts, all are green. They're final. What is not green yet is something around ZK and the key store. This is where the most of the work is done now. So, I thank you.

I'm not sure if we have time for questions, but I will be here around. I left also my contacts, both [clears throat] my email or my signal. And yeah, thanks for for coming.

Thank you, Antonio. I think we do have some a few minutes. Yeah, we do have a few minutes for the questions. So, anyone? I think Uh this one first.

Sorry.

Okay, thank you. Uh going back to the slide for pizza.

For pizza, okay.

Yeah, [laughter] for pizza.

So, go back a little bit. Yeah, faster. Sorry, yeah. It was a lot of animation.

was uh mozzarella cheese and the many many four kind of cheese pizza.

Now, say it again, sorry.

Yeah, we all like to eat pizza.

Okay.

Especially with many cheese.

And sorry, it's pretty behind. Let me faster.

Are you asking what kind of cheese he likes? [snorts]

Okay, thank you. Yeah, go go Okay, perfect.

Yeah, yeah, I think uh I think uh you you demos I think uh Forky is a Swiss company.

Yes, but I uh but we are in Lugano area, so south of Switzerland, and I live in a Lake Como area, so Italy. So, I'm Italian.

Yeah, yeah, yeah.

[laughter]

Nice to meet you, yeah. I I want to say sorry to you, yeah. Because here in Taiwan, we enjoy pizza with pineapple and ham.

[laughter]

I know. I know. I know. I know. I know.

I have Jennifer here that's part of the team. She always jokes with me about that. That's why I put it in the in the slide.

And I want to tell you, yeah, I very like your speech. Your speech is very clear about the data protocols.

Thank you so much. Appreciate it. Thank you so much.

We also put boba tea on the pizza.

Boba tea, okay. We have one question from there.

Yeah, let's have a real question. Yeah.

Pizza? No.

No, not pizza. Uh so, with the original stealth addresses, uh the idea was that you have you would just send it to an EOA, and then I could derive my own key to spend it. Uh are you saying with the upgradeable keystore that I'm sending it to a smart contract? Or am I send like because one of the beautiful things that I have the original stealth addresses was like it just mixes with the normal network traffic that you just sending money. But if the upgradeable keystore am I sending it to a contract where am I sending it?

You are sending to another a stealth addresses always but that stealth addresses is a smart account a safe smart account one of the millions of smart accounts of safe out there and it's a not yet deployed smart account. You pre compute the other way pre compute that's for like for example how freaky works otherwise the gas would be impossible and then send the announcement. So you as the receiver get the announcement said oh I got my to this address let me deploy the smart account and then you have that and then

Super dope super dope thank you. Yeah yeah so you're still sending just like a normal ETH transfer but instead of deriving the stealth address I'm deriving the deployed code

Exactly and this can be all automated through an ENS CCIP of chain resolver like freaky does. By the way we are open sourcing that we have a project with ENS will be open sourcing next coming months around that and this is also like to make sure that like even wallets can integrate that cuz I think this is how wallets is going to use them in the future.

Incredible thank you.

Thank you.

All right that's all the time we have. Thank you Antonio.

Thank you.