Safe research The Fight For Self Custody

I want to talk about safe research and thank everybody here for joining us in the fight for self-custody, not against self-custody, for self-custody. And I think what I want to start with is why is self-custody key? Why do we need to fight for self-custody? And if we look at the blockchains and how we interact with the blockchains, then we have, all of us have an account, right? Like really, as Rahul mentioned earlier, we sign an interaction and then it creates a state change.

And this is where the accounts are the gateway. It doesn't matter if you use MetaMask, a safe interface, Trust Wallet, or any other wallet. These are the interfaces that manage your account. But the account in itself, that's what's the gateway towards blockchain. And to own this account, this is to own your Web3 identity.

This is what makes it permissioned. It's universal that you can use it. And this is your identity alone. Nobody else should have power over it. This is what got me excited when seven years ago I joined crypto, that I could program this identity.

I could do with this identity what I wanted and nobody else could stop me from this or control this. But if you look at the current state, then we have to acknowledge that self-custody is still broken, or it is broken. Ethereum is around for a little bit more than 10 years. And we still wake up daily to be reminded that there are security challenges that we have to fix, that there are UX challenges that we have to fix. We are still relying a lot when it comes to wallet and general infrastructure for Web3.

We rely a lot on centralized technologies that are single points of failure where we require option trust. And I'm not sure who has seen the talk on the first day of the talk, how easy it is to onboard into the blockchain world and then interact with it. We have to acknowledge there's no accessibility. It's still super painful to interact with Web3. We have not solved these problems in the last couple of years.

And then when we bring innovation, then it's most of the time just weirdly repackaged Web2 technology that we say, look how nice it now looks in the Web3 world. We have not really moved forward. It is broken. And we as a research team really want to commit to let's identify where is it fundamentally broken, where can we build the tech, the building blocks, how can we combine existing building blocks to really bring innovation. So as you know, we are self-custody maxis.

You have heard it from Lucas today. You have heard it from Rahul today. We have these cypherpunk values. We do not want to compromise on self-custody. And it's our mission to make self-custody easy and secure.

And Rahul even had a nice slide where he said it's even beyond this. We want to make it verifiable. We go back to the slides. Watch Rahul's talk if you haven't seen it before. And what we also want to do is there are Ethereum's cypherpunk values.

Ethereum has a cypherpunk soul. And the values in the cypherpunk soul is that we have security, censorship-resistant, and privacy. And security doesn't mean only that we protect the user or the account from external threats, from malicious parties that try to trick you into doing something or try to take ownership of your account, but also to protect the user from themselves. It is complicated. We have to give guardrails.

We have to provide them tools that they are secure. And censorship-resistant is at the core, right? Like if we want to have this neutrality that we all see in blockchain, that if we want to have this permissionlessness, this is where censorship-resistant is important. We have to remove these central points of failure. We have seen it over and over again that overly or too much trust in central life tech really is being abused by malicious parties, and therefore the censorship-resistance really becomes important.

And more than ever, privacy is also a point that we cannot keep as a later or secondary priority. With the rise of AI in the last one to two years, it becomes increasingly easy to analyze big data blobs to understand what is going on and how you can connect the different pieces in this big chaos of data. This big data problem becomes increasingly easy to solve. And what do we do in blockchain? We give this data.

We publish the data publicly. Everybody can see it and can analyze it and collect it. So really, these three points are what we want to focus on and build then on top of. But we cannot forget accessibility and convenience. They are closely interacted here.

And accessibility means that—no, we start with convenience, sorry. Convenience means that if you know the system, so you know how to engage with the system, that it's easy to use, that you know how to interact and that there are as little hurdles as possible to interact with the system. Where accessibility means that even if you have no knowledge about the system, how hard is it—or it should be—as easy as possible to engage with the system, to enter the system and really then start benefiting from the system. And there's a tight balance here between the core values, our cypherpunk values, and these convenience and accessibility. Because if you make accessibility—if convenience is too bad, then it also results in that there is no accessibility anymore.

And if we also overly optimize on convenience, it's very easy that we lose out on privacy. So this—not on privacy, but also on security. So this is really where we say if we look at self-custody, we have to make sure that these balance out. Self-custody needs to be easy. We need to be able to engage with it without having to compromise on these.

And when we—what we currently see is that if accessibility and convenience are ignored, then it's not that users only shun and go away. No, most of the time, users yolo through the process and do stuff that they don't understand, and in the end, lose a lot of points. And for us, this is the basis really that we want to build on top. We want to show how can we generate security utilizing features from smart accounts, using guards that allow us to bring in external co-signers that allow us to build policies and utilize threshold signatures? How can we use modules to really build recovery tools that provide security to the team and really make it accessible also to the non-Web3 OG users that can program everything themselves?

I mean, I enjoy this, but my wife could not do this. Then also, how do we really build a decentralized stack that does not feel like a burden? I can remember when we first started using IPFS, people asked us, don't you have a centralized gateway? Don't you have a centralized solution or alternative to IPFS? Because I don't want to wait the 20 seconds that it requires to load from IPFS the data.

And this really we have to show, how can we utilize ENS? How can we utilize IPFS and on-chain registry to have something that is censorship-resistant, that has no central points of failure, but still is convenient to use and has a high end user experience? And privacy, I mean, it kind of is depressing to talk about privacy because we pushed it so far back and now that it's in a world where privacy becomes more important than ever because we see increasingly prosecution based on public information, we really have to double down on it. We really have to say, look, how can we utilize them? We have the technology for this.

How can we put these pieces together? How can we use zero-knowledge proof, homomorphic encryption to really get out of this world where we don't control who can get access to our data? Yes, now I have to think what is next because... Too much to say, to be honest. Yes, important, right?

Like, how do we approach this? Because I talked with a couple of people here at the venue and actually calling it safe research set some expectations, right? And what we want to say here, safe research is not about that we publish papers. It's not about that we have this nice 30-page scientific paper. This is new cryptography.

You have to think about it like applied research, right? How do we use tools? How do we build something? How can we generate a prototype that I can give to everybody in the And this should not be motivated by, okay, how can we turn this as a next step in a super-profitable business model that we can make money off? This is something that, when it comes to broad research, held us back in the past.

This is why we started out, we have enterprise trade and this is very explicitly from our research part where we say, here, we really want to look wide. How can we solve this? How can we bring the future closer to us? So to really showcase a little bit where we went to, we started this like a month, two months ago, max, right? So we started off with this quick ideation.

We want to be fast, a little bit scrappy, but still something that can be used. And one of the first things that we worked on was, hey, let's look at how can we use existing tech, especially new existing tech like 7.7.0.2 to solve some of our existing problems.

And one of the problems that we often see is like, how do we support new chains? I'm not sure if we have any people in here who know how our process is to support a new chain. I saw the Protofire team being around. We interact quite closely with them. But how the process actually looks is there is one private key that deploys one very specific factory contract, and this is fully controlled by the safe team.

Nobody else can see it. It's a denial of service reason why we control this case key, but this is really where we as a safe team are a central point of failure. If you launch a new chain and you are not using one of the stacks that deploy it by default, you rely on us that we do this for you, or we theoretically could censor you in this regard. So the solution here is that actually with 7.7.

0.2, there are some fancy ways where you can generate a 7.7.0.2 signature that this cannot be blocked by us anymore.

It cannot be blocked by anyone. We basically make the deployment of safe accounts, the fundamental infrastructure of safe accounts, available in a trustless manner. We wanted to share this. We pushed actually an ERC for this because most of the factories nowadays still have this permission. Even other factories like CreateX have this private key that is managed by the team and is not public, and we really want to go away from this.

We want to push for a world where we don't have these central points of failure, not these layers that can control the system. So here also there, we would love if you engage into the project, if you support this, but this was one of our very initial initiatives that we wanted to push. Another one is that after the Bybit incident, it became again, it was a repeated reminder that delegate calls are cool. I love delegate calls. I'm a developer.

Delegate calls allow me to do everything with my smart account, to program it how I learned it. But if you don't know what you're doing, as a user, it's hard to understand what is exactly happening. How do you verify it? And it's a flexibility that needs to be controlled. And this is really where we said, it's actually not that hard.

We have the tools laying around. Let's push for it. Let's work together with SafeLabs and push this to the users that we say, hey, how can we restrict what delegate calls can do? This must be easy, right? Like safe accounts are flexible.

And this is also where we pushed a solution with a simple guard. It's permissionless. Nobody controls the guard. It's not up to us that we say, oh, this is a good delegate call. This is a bad delegate call.

But rather we say, you know, for 90% of the use cases, it's exactly one specific contract to batch transactions that is being used. So it's a very simple, trustless solution that massively reduces the risk of malicious state transactions. So this is a very pragmatic approach that we want to showcase. But we have also some more, let's say, visionary long-term initiatives where it's more about really this maximalistic cypherpunk values of decentralization. And one of them is our queue.

Safes are multi-signature accounts. So you have to collect the signatures together. And currently, because it's very easy, very convenient, these are collected in a centralized service. That's totally fair. Don't get me wrong.

I think the convenience part is awesome. I use the centralized service. But we have seen in the Bybit incidents where we had to then recap our security mechanisms of our services, where we had to take down our service, that this reliance on our service can come to an availability problem where you are blocked out when we have a technical problem. And this is really where we say, okay, what is the extreme other side to this? Like currently we have only centralized service.

What is the complete other side to it? And it's let's push everything on chain. Is it good or bad? Doesn't matter. Let's just build it.

And this is what we did here, where we said, okay, let's take all the information. We push them on chain. It's actually we push all the information for all chains, all on GnosisChain. So we basically really use GnosisChain as a safe chain-like tool. And then this is really a public layer, a public service where you can collaborate with your other signers and collect the safe information.

And the advantage here is you only require an RPC endpoint, nothing else. So that means if one RPC endpoint is down or if we are down, it doesn't matter. Switch to another one and you get the full experience still and can continue. Definitely here, this is the starting point is still where it's just, okay, you push it. That means you have to pay for pushing it.

But there, this is the basis for a lot of innovation where we say, how can we integrate encryption into this? How can we make this public queue private? How can we create economics that allow us to sponsor the interaction with these queues? How can we also integrate co-signers into this where we say we publish this information in some way that co-signers can access it? And also these co-signers signatures are being pushed through these queues, allowing you a secure interaction.

And co-signers are an interesting topic. This is the last initiative because co-signers are on one side trivial and on the other side not. Co-signers have been around for a while. We have seen them in a couple of other incidents where actually co-signers were set up, but it's really this, okay, you have to trust an external party or if we would run the co-signer, then you have, it's in the same infrastructure ecosystem where if this one infrastructure ecosystem gets compromised, multiple parts get compromised and we are back to the central point of failure. So how do we get away from this?

How do we build a network of co-signers? And this is something that we started last year thinking about. It was you can use co-signers in different means and last year we said we want to use co-signers, build a co-signer or a co-processor network and really say this is safe net. This is how we started, what safe net is, but more for the utility of cross-chain interaction. And now what we saw is really that, hey, security, this has to be a focus.

It's like self-custody needs to be secure and this is where we say let's take our co-signer approach. Let's utilize actually the guard contract from safe net and look how can we utilize this to build a co-signer that you can host yourself. You don't have to trust us, you don't have to trust some centralized entity, but you can host it yourself. You define your own rules and it runs in some infrastructure to already start co-signing to showcase the benefits. And what was the goal here is to make it as easy as possible to host your own co-signer.

Because if I pick a random person out of a crowd, I'm not sure how many of you know how to set up a service that is constantly running and checking that data is available on our backend. Who could set this up, such a service? All right, nice. We have at least five to six people. Awesome.

The rest of you, no co-signing for you. Sorry to say. And this is really where we say, okay, can we find a middle ground? And in this prototype, we really said, okay, let's use GitHub Actions. GitHub Actions is still a co-signer set up on GitHub that starts checking your account.

It works right now on your safe account. The prototype was forgnosed as Shane. It uses actually formally verified contracts because it's a safe net contract. So this is really something where we wanted to show even with very simple tools with existing blocks, you can increase the security already. So who are we actually?

We're actually a very small team. We are all quite OG people in the safe ecosystem. And we are just five to six people. And we do not, we want to stay this. We really want to stay a small team that can iterate fast, really push innovation.

And we pledge to really research in the open. We will share everything that we have. We will push everything that we have open source. And we want to collaborate. We are a small team.

We want to work together with other people. We want to hear your burdens and self-custody. We want to figure out how to solve them. So reach out to us. Write us.

We set up a domain, like the very traditional email communication channel for now. And yes, we would love to hear from you. If you want to hear more details on this, we have a manifesto for this. And yeah, feel free to read it up. I hope the QR code works already.

It's timing purpose. Yes. And here's the last thing I want to say. I think self-custody is very closely related to how do we handle private keys. Later today, we will talk about how we can kill the private key to improve self-custody.

It's at four. So join us there. There will be Francesco from Metamask, Christoph from Pimlico, and Dror from the Ethereum Foundation talking about how we do this. Thanks so much, Richard. We have a lot of time for questions.

Oh, no questions. That's good. There's the question. No, I welcome questions, obviously. Hi.

I return. So a question, one of the aspects you mentioned is on-chain queue. I remember it being one of the original features of the multi-stage, and it was removed. And I was actually very sad when it was removed. Can you perhaps touch on why it was removed originally, whether the same considerations still hold, and why you think it can now be reversed?

Yes, I can touch on that because I made the decision to remove it. So when we look back at the original Gnosis multi-stage, everything was on-chain and you had no choice. When we started developing on-phase, it was very much Ethereum as the chain, and actually gas prices, it was high. Ethereum price was high, and paying $100 to propose a transaction, and yeah, your XY is maybe not so feasible. So this is where we said, okay, remove it.

We proposed off-chain for us, or for me especially, the Ethereum mainnet or the blockchain is a settlement layer. You push what you want to do there to induce a state change. Obviously, this comes with a trade-off because you still somehow have to coordinate this. So what has changed since then is that we have to see we now have multiple or like a large universe of chains, all with different properties. And it is feasible to collect and store this information somewhere else in a decentralized, in a blockchain state way.

Would I do this on Ethereum mainnet? Probably still not, but you can use some other chains to basically achieve this. And this is where really what I mentioned earlier, having everything on-chain, having it on each of the chains, that is very much the other extreme of everything having off-chain, and probably we have to find the trade-off. So this is part of the research, what are the trade-offs? Not all of our transaction information actually has to stay on-chain forever in this proposal.

Should we use blob space that just leaves after 18 days? Maybe. Maybe that is a solution that we have a really a state, that we have a safe chain to collect safe transactions that forget transactions. And this is really where we have to start looking into where we said, you know, this is complicated, this is complex, that's why we pushed it to the back, but now that's why we have to research and really figure out, okay, how do we find this balance? How do we use this crossfader that I will introduce earlier?

I don't see anything, so if anybody puts hands up. Perfect question. It's just a quick follow-up, how is it actually done now? Do you have like a centralized service, or how do you do it now? So how it works right now, we have the safe transaction service, and if you want to propose a transaction to the transaction service there, I mean, the default way is that you propose the transaction and one signature that's of an assigned transaction.

With this, we on the server side know it was proposed by a party that has access, and actually when you receive it on any client, you can double check that the signature belongs to the safe transaction, and that it's verifiable. And there's also the way where you can skip the signature, that generally puts it in an untrusted state. So this all happens off-chain, it all happens in our services, and it has the advantage that we can utilize all the magic that we have in Web2 to make this a performance, a nice experience, available on mobile and push information, so it has its benefits. But it also comes with, again, trade-offs that we have to do, when it comes to availability, also you have to trust us, what we do with your data, and I think this is where safe, also because the on-chain part by default is so simple, we can provide alternatives, we can allow the user to choose, we can look where can we have, like Rahul said, we want to modulize the stack so that we can really say where can we apply our safer punk barriers. But yeah, currently for, especially as we mentioned earlier, we come from the serial mainnet world, where putting everything off on-chain is expensive, that's why everything happens off-chain there, until the point when it has to be executed.

Yeah, thank you. More questions? Yes? Thanks for the talk. Regarding the delegate calls, I assume it's like modules, registries, what contracts can be called, the function signatures, do you assume that most of the users won't even know what they shouldn't call?

And are you going to create like a marketplace on top where you can delegate that responsibility of choosing what contracts should be called through delegate calls? Or do you assume most of the users will be smart enough to understand every function signature and contract for whitelisting? So, I don't think there is the one answer. Generally I say I would not trust the user. I know we should not say this, product company, yada yada, but the user is stupid, so this is one of the base assumptions that we kind of have to go with.

And I think we talked last year at Procoborg, I talked about this safe core protocol, we called it, where it was really, can we inject, like, can we utilize SCARs to inject a registry where we say we have some form of registry, but then you go down the road, right, like who manages this registry, how can we build tokenomics around it, we have TCRs, and also this will be part of the research. And I think sometimes we overthink, right, like let's start with, let's assume I want to use it for myself, I know who I want to whitelist. The next step would be we have address books, maybe we start out with you somehow can link your address book to it and say only your address book, right, and then we can somehow go into the network effect, but I think we often try to jump like the canyon and don't try to do smaller steps, and this is really, yes, we have to figure this out, I think the end goal, if I want to onboard my family, if I want to onboard people on the street, they should not have to manually whitelist stuff, whether they need a good default that works, but especially also if we think about enterprise models, for enterprise teams or even for OG crypto teams, we can assume that they have at least one person that can come up with a whitelist.