Ethereum Privacy Journey

Okay, great. First of all, thank you for having me here. I'm Antonio, co-founder at Fluidkey. And before entering in my Naur journey, a couple of things. First of all, if I ask you what is an Ethereum transaction, 10 of you probably, at the end we probably can get to a point where we agree on what an Ethereum transaction is.

Now, if I ask you what is privacy for you, I'm sure you can debate this and we will never end up to a single common answer of what privacy is. This is because it's a wide concept. And that's the first thing I want to keep in mind. The second, this is a journey and I want to show you how All of you are part of our, like many other product journey and play probably the most crucial role in the whole journey. Each journey starts with a problem.

You will be able probably to figure out a lot of problems. Problems are everywhere, every day. Problems are the reason why there are products often solving your problem. For us, the problem was that everything on a blockchain is public, kind of a known problem around the ecosystem. So balances are exposed, history is permanent.

That's I think even more worries than the balance is exposing. The history is permanent, connected to one address. And the analysis of the data is super cheap, requires no effort. One link to open, Etherscan, and you get it. In 2023, when we start working on FluidKey, the beginning of our journey, these were the vibes around privacy.

There was no clear UX path on how someone can get privacy. There was another case that got done less than one year ago and was scaring everyone that was investing and building products because it was not clear what was accepted and what was risky to bring you in jail. And there was a lot of confusion about ZK. I heard once people say, oh, there's a ZK roll-up, so there's privacy. Wait, time out.

No, it doesn't work like that automatically. So in this environment, once I got a friend tell me, but what do you need to build what you are building? Just use a centralized exchange. You will solve your problem of privacy. And to me, this should have been like a gift.

Imagine this. It's like, you know, keeping everything and put under a carpet. This is not how the problem should be solved. And this brings us to the next phase, often very connected. We might have a solution.

And I could have asked a better talk before mine than when Cassandra gave a second minutes ago. It's because I'm quoting the same, we didn't talk here before. We are quoting the same article he mentioned. And also if you, it's little, I can read it. One of the things that they said is, for example, to Ben DeFrancesco.

Ben DeFrancesco is one of the co-founders at UmbraCash, a product that inspired us a lot. And FluidKey would not exist if UmbraCash probably didn't start what they did. Just to give you a little how these connections are all super important. Start addresses were a known solution. No one invented them, at least none of these people that you see invented them in terms of concept.

The first one time we were mentioning, I remember reading it in a Bitcoin forum. And they're easily applicable to the cryptography also that applies to the EVM that we are not all familiar with. The next part of we might have a solution now, as salt addresses were known, I knew them. But one day Moritz, my co-founder, posted this on Farcast. I didn't know him yet.

And it's like, what if instead of EOAs, we consider those addresses owner or smart accounts? We get a guest sponsorship. We get batching. We get a lot of benefits of treating them as smart accounts rather than EOAs in terms of UX. And UX is going to be a good part of my talk.

And this connection, this idea, this connecting the dots brought us to the next phase of our journey. Still at the very beginning, this was mid-2023 in terms of timing. But does it work? And I want to introduce like a core piece in every process of building a product in blockchain, hackathons. Hackathons is where the magic happens, I say.

It's where you are forced to focus on an idea, on building an idea. You have two days and you need to figure it out how to solve the problem with the idea you had in mind. And for us, it worked. We had an encouraging outcome. We got support from SAFE and we got positive feedback from participants.

Probably you haven't noticed, but you are part of this journey twice. The problem is something that communities, people find out and we get positive feedback. If everyone was saying, oh, what you're building is useless, we would have done that more. We got encouraging. It was not what you're doing is perfect.

That's not. But that was like an important role for us. Hackathons, communities. This brings, though I still remember the day, it was not a specific day, but it was a period as a reality check, cold shower. We were super happy about the hackathon, but the majority of users won't care about privacy if UX isn't great.

What does it mean? Outside of the hackathon bubble, the time was global in Paris, no wallets queued to integrate us. We thought we had a super cool solution with smart accounts. We could build something to simplify that and no one wanted to integrate that in their system. So we took a decision.

We need to bring privacy with good UX. I've always been kind of a person that I like privacy. Before UX, I used to call it practical privacy. What does it mean? It means that it's something that we need to be able to use it easily.

If we build privacy in a way that only engineers can use it, we can't use it. The standard of the masses will be imposed to us too. That's, I think, something important. This doesn't mean that we need to build tools that don't follow our principles, but we might have to find a common ground that makes sure that we build privacy, but we build privacy with great UX. Again, UX was mentioned in the talk before and we didn't talk before preparing this slide.

How we solved this problem? Back to Hackathon. In this scenario, we were lucky. We were lucky because it was a good moment. There was happening in Rome, ENS was sponsoring the ship, and ENS was launching a feature called ENS Off-Chain Resolver.

Yeah, we have been lucky. If we had come up with this idea one year before, we didn't have all the support to find a good solution for providing acceptable, nice user experience. FluidKey is, and I'm using the name of our product, is an ENS that hides an infinite amount of addresses that are not yet deployed smart accounts that never are returned twice. From the address, you cannot go back to the ENS. Kind of privacy is protected, but for the ENS, you can get to the address.

This was able to, I can have an ENS, I can share with anyone. Even if I post this ENS on a social media and I can start collecting payments, who is paying it? Of course, see who paid, but I cannot say how much I made out of this donation. This has been used actually in real cases for donations because I can collect donations without showing everyone how much I am collecting. It's also great for use cases where, you know, there's sensible privacy on shares like that, so I don't want to connect all these donations to a public wallet that probably I own before.

Till now, we found a feature. We didn't find a product. Hackathons are not to make products. Hackathons are where you start working on features, ideas that solve problems. This is a feature.

Now, for us, the journey will start to be crucial. Now is where you need to start having necessity of having money because there's development that needs to be done around that. The easiest way in this moment of your path, and we are speaking about path for a privacy solution, is to collect feedbacks, ship a lot of small features and understand what I did is the right step or was I doing a step in a pond and have to go back and try another path. This is you, again, in the journey that needs to test, help, and support with feedback. The current phase is what we commonly call change product market fit.

This morning here, and if you didn't listen to that, I kindly advise you to go. There was a great talk on this by Alan from Railgun. They kind of found product market fit. I would say yes, recently, but it was not an obvious path for them. They started before the nest.

I don't want to repeat what he said because I think I would like to quote the whole speech he did here. Product market fit means revenue. Revenue means more features and more features means a better product. Product market fit is not magic. It's work, it's feedback, and it's support.

From who? From communities, but also from foundations. Being here for me to speak now is a great support that I got from the guys from Web3 Privacy now versus what we are doing, and I'm grateful for that, honestly. Me and all the other people, absolutely. Product market fit is building what users and communities want, not what we as developers think might be funny to build.

That's probably a side project, not a real product. The question is, what is revenue for privacy? I think that privacy and profitability are not enemies. This means, of course, monetized spending. That's just a very basic example.

Transparent business logic. But if we want a privacy-focused product to have success, we have to accept that they must make money because at the beginning, probably, they need to raise capital, and that capital cannot come just from grants or success. Who puts money that wants to return into the money? That's the world we are in. We don't have to be hypocritical around that.

So we need to accept this concept, but build it in a way that is fair, sustainable, and transparent. We can have a lot of different opinions on privacy, but that the transparency connects strictly with privacy, I think that's something that most of us probably agree on that. So what's then? I don't want to close this talk just thinking about a generic path for a product building in Ethereum over privacy. We touched on a lot of parts of the problem, the hackathons, the role of communities.

But then if we go down to the single individuals, so you, I would say, I think that now it's important of what you, we, as users, can do because I'm a builder in FluidKey, but I'm a user in hundreds of other solutions. Test, support, share feedback. You have no idea how many hours a month we spend to discuss the feedbacks we collect from users. And it's every project, a serious project does that. Builders are humans, not superheroes.

Okay, so sometimes you are not able to integrate feedbacks right away, especially we are a team of three, four people working on that. And please keep complaining about your problems. The more you hear them, the more faster we probably are going to solve it. Of course, it makes sense for just one person saying one problem might affect their prioritization, but it's crucial for us to listen what are the problems. Not, oh, someone just said, I don't have to repeat.

No, repeat it. It's important. It's another voice saying, we need that. This is not working. This can be done differently.

This is not enough private for me. That's all feedback that we think are important. And please vote. Be selfish. Vote to distribute grants.

There are a lot of problems who have things like quadratic funding to understand where people want money to go, which are the products that you want to go. Go on this platform, be selfish, and vote the products that solves your personal problems and help. And this is like a huge help over that. So before closing, and we will have time for a few questions, as you have seen, I haven't touched the technology under Flicky. It was more important on the journey, but happy to discuss and explore more around that if you're interested.

The main takeaways that I want to leave you from this talk are that for me, once you identify a problem, hackathons are the best place to build a feature, the worst to build a product. You don't build products there. You just figure it out how to solve the problems. Foundations are just entities with the role to facilitate the transition from ideas to products. They have expertise.

Not all the hackers are entrepreneurs. They need to be guided into that, and this is crucial. Guided in what can be a mistake and what is not. Communities, users, we need to ask, request, test, criticize what has been built. And finally, builders have the responsibility to recognize that the product is the result of many contributors.

So when the product finds a market fit, for example, don't have to forget, and there's a thing that I think is super important, give back. Give back to the community that helped you reach that scenario. Support other projects that are at the beginning of the path that you have been doing a lot. Even a simple feedback, even a simple, let's do a 30-minute call together is really a light in the dark for a project. So my side is full.

Happy to answer your question. Thank you, and if you want to try FluidKey, this is your code. You can scan the code on fluidkey.com. And this is us, the three of us, working on building FluidKey.

Thank you. I would open one from my side. It's kind of like information. I don't want to disclose. How were you from the start pressured from lack of finances, and how you approached the financial sources?

So at the very beginning, we were super lucky to get rents from Faith, from UNS. I can mention them. And that was like a life thing. So the first month, we were relying heavily on that. But soon we realized that to get a product, we need proper capital.

And we decided to go for a small preset that was allowing us to build a product. Because I think that it is personally a mistake that each of us has a limited amount of time, and that time has value. So even if it's your project, this doesn't mean that you need to overpay yourself and not think that. But it's important to give value to your time and to say, OK, if I have to do this and it will take one year, where can the resources come from if I want to take it seriously? And that was the path I went.

Still looking at the support from events, from foundation, being able to speak at events and collect feedback. So do that in a very way that is not always maybe mainstream. Questions? I have a question. One second.

Mic, mic, mic. So yeah, I have one question, and it's great to meet you and talk to you. And I think what you guys are doing is amazing, by the way. But one thing I've always wondered about, if I'm the more, I guess, what would you call it, paranoid type of user here, the one piece in your stack that I've always wondered about is the fact that I think you got this amazing, amazing UX from this as well, which is the fact that there's some off-chain infrastructure in order that powers this, right, these off-chain ENS resolvers. So yeah, sort of what are your thoughts on that, and is there any path to sort of sure up that infrastructure for a paranoid user like me to feel like I'm not relying on infra being run by one particular team in order for this approach to privacy to keep living on?

Great question, because today at lunch I was speaking with Tony Wachstadt, that was one of the others in the paper that we mentioned, and it was discussing about how to make sure that this centralized dependencies on generation of the RDCs can be as much as possible decentralized in a way where UX is not affected, but also we don't collect a lot of data, because trust me, we don't collect a lot of data, but we have the RDC generated for a user, because we need to index them on that size, and if I don't have them, I would sleep much better overnight, and that's a problem also for us. And we are working on that, for example, one will offer a non-chain resolution that the address return is owned by the user, and it's something we're already working on that. This still doesn't solve the problem that we have indexing them. For that, start to be a little bit more when it comes to, okay, I want maybe some automations around that, so we have featured that in a permissionless way, we automate, since there are smart accounts for our users, like, okay, I received money on one chain, automatically it's sent to another chain where I want to collect all this money. But I think that we can propose a trade-off where if you accept not to have all this probably automation, we can get to a point where the decentralization, like, the data we collect is completely, like, we just act as an anonymous indexer, we index data for you, but we don't know we're indexing data for you, okay?

Another piece of the puzzle to solve this is needed by the foundational standard, because you mentioned, for example, the events emitted on chain. One reason why we went to this user experience is because I don't want anyone to be forced to use FluidKey to send money to another FluidKey account, I want to send money directly from MetaMask, but I don't want to go on a website, connect MetaMask and send, I just want to send your ETH, and so embedding that into Wallet, probably, like this solution emitting an event while doing a payment, there was a proposal of doing that as an ENS standard, for example, if ENS returns as record, okay, then I have to emit this event as a Wallet, yeah, once we have that, we will be more than happy just to change this way of generating sell targets and go to more, even more permissionless way of generating them. We have a few minutes more before Julio, any more? I would ask the one that we cannot keep talking about, because at the conference, people try to flex confidence, they're geniuses, but I would rather ask you what things about the business, about the marketing, about building relationship with foundation, you didn't knew two years ago, that were really critical on your journey, sort of like the new skills you gained, the new habits you built and stuff like that. I was always being on the other side, you know, of the game, so sharing feedback, and on the other side, it was like, oh, I tell that, I tell that, but when you move on this side, I think that speaking with everyone from at any level on the stack, from the VC to users to foundations, gives you a completely better view of what you're building, and this is a kind of a skill, because it's not just listening, it's also listen and make the right question back again to the user.

This is, I think, the most important skill, the personal at least I learned, is questioning by the user, not in a way to argue with them, but just to really understand where is the problem you're seeing, and where we can help out, figure it out, so not being afraid of asking. That's, I think, in short, the best thing I learned so far.