Stopping Multisig MEV with Harbour

Transcript

How are we doing everyone? >> Come on, we're in Brenda's hair race. Come on, get a bit more energy. How are we all doing here? >> Yeah. Um, so I'm John. I work with the safe R&D team. Um, I'm we're primarily working on solutions related to security, censorship resistance, and privacy. And can I get a show of the of hands? Who here owns a multisig right now? So we have about maybe 50% of people. That's good. Who here knows what a multisig is? Okay. So I'm going to take the assumption everyone knows what one is. So yeah, a little bit about our team. We're a team of five people

primarily focused on building solutions for these three pillars. We're mostly inspired by Eric Hughes who wrote the Cyberpunk Manifesto back in the '9s. Vitalic has since taken quite some inspiration from that as well as um Prescarvio some security like experts within the space and we are aligned with these values and we want to be building solutions that address these pillars as well. I want to just outline the problem of this whole talk and kind of our building philosophy behind the solution that we created. Um right now in most multiig architectures your transactions can be watched. It can be creeped on before you execute and that opens up some attack

vectors associated with either minor extractable value or even critical vulnerabilities in your own protocol or critical vulnerabilities in your own operations. And I'll talk to you about two examples why this is actually a big problem as well. So why is this a problem? I think the first one the it's primarily like this happens this happens quite often but it's kind of goes under the radar but say Alice wants to buy 200 Alice tokens at $100 at the price because it's multisig everything involves like every action involves creating the transaction waiting for multiple signers to sign the actual transaction before it's executed

on chain and broadcasted to the meme pool. So this delay period while you're in the queue for your signers to coordinate, that's an exploit window for Bob to frontr run the transaction, back run a transaction or do both and sandwich the transaction. So if Alice Dao plans to buy, you know, 200 tokens, uh, no, 200 Alice Dow tokens at $100, Bob sees the transaction in their queue, Bob says, okay, I'll buy the I'll buy the token before I'll increase the slippage essentially. I'll increase the price that Alice has to execute on and also then I'll back run and I'll sell like knowing that Alice Dow is buying this. I'll then sell at the actual inflated price as well. I'm not going to go into too much me but the top 10 Dows

have been affected by this before. There are people that are sitting and watching what the top 10 Dows are doing and trying to make some, you know, multi-IG extractable value from it as well. I want to get scarier now because that is a it's a that's a problem but it's you know it's not the biggest problem. I think the biggest problem here is actually like emergency protocol operations and say Alice needs to now execute an emergency patch for a critical vulnerability in their contracts. Let's say there is a risk parameter in their D5 protocol that needs to be fixed otherwise you know it can be exploited or let's say there's something in their

governance process that can be targeted and this is a problem because I've seen in the past um from speaking with people that there has been transactions to literally fix DeFi um or transactions to fix a patch that have been left sitt sitting in a queue for hours or even days. And this is a app at app patch to fix a vulnerability that could involve millions potentially actually potentially even billions worth as well.

Because these pending fixes are publicly visible, you can deduce what that transaction is trying to fix as well. And that's why we have malicious actors actively watching protocol operation multisigs, seeing what they're doing, seeing whether they're trying to fix a vulnerability in the contracts as well. So this again this delay period that is the window for you to get wrecked if you're trying to fix something or cover up your tracks in terms of your your contract vulnerabilities or even your you know both off-chain and onchain vulnerabilities that have an interaction with the onchain world and with the contracts uh to give you I'm not going to name names but there was a critical D5 protocol was very prone to this having a

transaction in the queue for hours that could essentially cause a catastrophic um like you know knock-on effect of the entire industry and it's a yeah it's a top five protocol as well. So how do we actually address hiding this information? Um we want to hide the transaction details. We want it only viewable amongst assigners. So nobody that is a malicious actor can be viewing that information and waiting to make an attack based on that information.

The answer is AI agents. Nah, money messing. It's not AI agents. The answer is actually encryption. We have keys. We have private keys. Let's use them. Let's use encryption. We're in the space. We're in the cryptography space. We're in the cryptocurrency space. Let's use encryption. And this is where we've created secret harbor which is just what we call the solution and it is a way to encrypt multi transactions for safe but also for other multisigs as well. This is not specific to safe. This can be applied to other multisig architectures.

And what I mean what is harbor? It's just an alternative interface to safe wallet right now for making multisig transactions. And we've built it in a way that has minimal dependencies. So as censorship resistance as possible. Uh the transaction queue is 100% onchain. So there's no backend that hosts the queue or coordinates the queue. It's all on chain and we the signers communicate with sign with signing and signatures via wacku which is a peer-to-peer trustless protocol. So we're not relying on a centralized entity to coordinate the signatures as well. And you can you can do multi-ync transactions on it today. harbor.safe.dev um if you want to try it out. It's not

it's experimental beta release right now. We haven't fully audited but I've been doing this. I've been dog fooding it. We have others dog fooding their transactions as well. It's a way to uh use it with minimal dependencies and also I will talk later encrypt your transaction details. So Harbor's Q is all on chain and public to anyone. So we want to make it secret harbor i.e. we want to hide this queue with encryption. And what Secret Harbor is is a key exchange server. It's all on chain. It's all hosted on chain um for encrypted communication. So that means signers can create secret transactions and other signers can then receive the transaction, decrypt the secret

transaction, understand the transaction details, sign it, and eventually execute it on chain as well. And again, this is all on chain. We're not using some, you know, centralized crappy backend hosted by AWS. I want to talk to you about the key exchange server. So the signers need to exchange encryption keys to enable this and unfortunately Ethereum uses public addresses and not public keys. So you can't im like you can't necessarily do encryption with your public Ethereum address. There are workarounds but a common security practice is to decouple what you s the key you sign with with the key you encrypt with. And I'm not a hardcore cryptographer, but it is a

common practice to decoupble those two to increase the security of the overall solution as well. What we use to create a separate encryption key is just a simple X25519 uh enabled Diffy Hammond curve. It's a public key. It's widely supported. There's fewer security assumptions and it's 32 bytes. And essentially creates you your public key, your public encryption key here as well. To create entropy, i.e. To create enough randomness, we we derive a key with sign in with Ethereum signatures and that gives us a encryption key to sign with and also decrypt and encrypt transactions.

So the flow I'm not going to dive into too much details here, but Alice simply registers her encryption key at the top with Secret Harbor on the right hand side. Bob registers, Charlie registers, so they all have their own public encryption keys. Alice when creating a transaction will retrieve the encryption keys from secret harbor creates the transaction based off Bob and Charlie's own encryption key public address incqes the transaction Bob and Charlie are listening to Alice um and see when Alice has ex has cued a transaction they retrieve uh the encryption key they get the context they decrypt the transaction and begin once they decrypt the transaction they can begin signing the

transaction and eventually Everyone signs and executes the transaction at the end of the flow. So here is Harbor creating the public key. Here is where you can create an encrypted transaction. So they say you just want to send simple ETH transfer or do a more complex contract interaction. This is you signing and encuing the raw transaction with your public encryption key and using your signature of your own address. And then this is simply Bob and Charlie then sign into transaction because they have their own encryption key that matches what Alice has wrapped. They can

decrypt it, understand the transaction details and eventually execute. And what that means is only Alice, Bob and Charlie can actually view this information. No one else can view this information. And that's it. That is essentially secret harbor. And I want to make a very like this is a really really important point is we call this secret harbor. But don't don't think this is everything everything you're doing is secret, right? We're just using basic encryption to encrypt the cues the cued transaction data. Once it's executed on chain, it's public. People know what you did essentially. and we're leaking metadata.

So like it's not a full privacy solution. People will still understand who is like you know who is signing, how many signatures remain um and what multisig is transacting. So this is like your your transaction details are secret but the metadata associated with your multisig is still public and known. So that's why this is a very specific solution when you want to stop doing you know when you want to stop preventing uh multiigme with high values of like high value transactions or you have some critical protocol updates that you want to do and you don't want anybody in the crowd or anybody in the world seeing what you're trying to patch up or what you're trying to execute between the queue and

eventually executing on chain. We are bullish on solutions like rail gun and Bermuda for achieving full multisig privacy. So privatizing the signers like so no one knows who the signers are. Privatizing the multisig address so you don't know the multisig address and also the multisig configuration. Is it a two out of three? Is it a five out of seven? Because what do that does is kind of obfiscates as well. It's security by obfiscation. it's harder for you know malicious actors to identify ah this is the security critical uh protocol multisig that I need to watch and I need to you know

monitor and think of potential attack vectors for so you're actually offiscating that details and that is helpful for um for security as another tool in the actual toolkit not a foolproof solution either and yes uh that is essentially what we've built. Please try it out yourself on harbor.safe.dev. Um, again, this is again minimal dependencies and a way to, you know, privatize your queue. And also, yeah, if you want to know more about the solution, reach out to me on X. Sean McEnglish, it's my name in Irish. Reach out to me on X as well if you'd like to speak about Secret Harbor. And yeah, I'm happy to take questions if anybody has

any as well because we have a bit of time. So yeah, if you have any questions about safe, any questions about security or privacy, I'm down to I'm down to discuss. >> Hi, hi, good morning. Um, my question is, can you integrate this into an existing safe for a governance for the governance of a protocol? Yeah. So if you have a safe right now, you can simply import your safe to uh harbor.safe.dev.

So any safe that has been created like version one, version 1.1, 1.3, 1.4, this is all this all can be used. So treat it as like a a companion essentially for your uh for your current like multisig as well. If you want to do some like, you know, we don't expect like everyone to be using this, but on certain use cases, we do expect people to try it out. No more questions. Thanks everyone for listening. Um, and catch me after as well. Thank you.