Real-World Encrypted Dapps With Shutter API

Thank you for having me. I'm Luis with BrainBot, which is the core developer behind Shutter, and it is a threshold encryption, DKG, encryption as a service, if you will, and today I'll talk about how sort of dApps can easily add these types of encryption features with Shutter API. To give a primer a little bit, Shutter ensures baseline neutrality. What does that mean? We design it in a way that it can serve, commit, reveal use cases, and providing encryption and decryption keys, and it serves these applications of the encrypted mempool, which is already live on the chain, and we're also integrating it within the PVF transaction supply chain, especially right now into MEV commit, which is a builder and proposer commitment framework together with PrimeApp, and eventually we're making the case that it should be really part of the protocol to have this decentralized way of encrypting and decrypting and having encrypted mempool to level up baseline neutrality and ensure sensitive resistance and front-running resistance.

That's kind of track one, and then we have track two, which is on the application layer, which is what we call Shutter API, and that is more about providing, again, encryption as a service for use cases in governance, shielded voting, shielded RFPs, gaming, but also just everywhere else. If you think about it, you don't really see this concept of reveal because it is hidden usually, but we think it's everywhere, whether it's trading and whether it's types of games. Just as a simple example, rock, paper, scissors. If two people play rock, paper, scissors, and one of the two sees the hand of the other player before they have to reveal, the game is useless because then you see it and you react. But that's just the very principle, and essentially it's everywhere because trading works that way.

If you see the other people's trades before they're committed, you can leverage that information. You can leverage their trading intent or their trading information that they supply to the trading system, and then you can exploit them. You can get the advantage that they were trying to get. You can steal it, essentially. If you have a commit reveal where you hide those moves or those trades and only reveal them after they are committed, you can achieve information symmetry.

We think it's not just in trading. We think it's everywhere, if you think about it. That's the case. On a more detailed level, it is basically where we're encrypting transactions, batching them together, and then they are signed while it's still encrypted, and the block producer implicitly commits to including the transaction and the order of the transaction without them actually knowing what's in them. Then decrypting and executing happens after commitment, and that's very hard to censor or front-run for the block producer and also for anyone else.

The block producer usually has the ultimate power to audit transactions or to censor, and if we can make them not censor or front-run, hopefully the entire transaction supply chain can't do that. Then we use special encryption to not have a centralized trust assumption there to encrypt and decrypt. You could do this centralized, but then again, you're shifting the responsibility to a centralized entity. With this special encryption, having K out of N parties having to collaborate to generate those keys, we can detrust essentially the encryptor or decryptor. That's live on GnosisChain.

It is still in a little bit of an out-of-protocol fashion, but it proves that in principle it can work. We have 8,000 validators, and we have a couple of thousand shared transactions so far, and we have a limited keeper set so far ironing out some kind of P2P communication issues, but that's kind of the state of it right now. Now we're moving away a little bit from this encrypted mempool protocol level thing more to the application layer. It is also implemented into snapshot governance where it provides shielded voting, so encrypting the real-time results during the vote and only decrypting afterwards, and we do that again for information symmetry. Just like in real-world elections, you don't want to show the real-time results during the votes because that really influences decision-making, and simply speaking, people who vote later have an information advantage over the people who vote earlier.

That's why you don't show the real-time results in real world, and in the blockchain voting you can hide it like this, and you can switch on shutter in your admin settings in your snapshot space, and for example, Arbitrum uses it for their elections, and Shapeshift uses it in some other bigger dials as well. So yeah, and then the case we're making here is with Shutter API, it is very easy really for dev developers to implement this type of encryption as a service. Again, commit reveal and or time lock encryption, also some privacy applications as well, and then just a list of potential use cases. For example, sealed bid auctions, and I'll talk about something that we're building in this regard. Bounty and betting platforms, procurement tools, again, we have sort of a little POC there as well, or a little application that I'll show.

On-chain games, especially simultaneous move games. In the past we had a game called DAOplomacy, so a diplomacy variant, but using on-chain for DAOs, and again using this commit reveal, because similar problem if you have many players moving at the same time in one move, at one round, then you do not want to show those moves, because again, you have this front-running issue where the other players can see what's happening. Negotiation tools, where you don't want to show stuff prematurely, time lock applications. What's not on here is privacy essentially, so you can also use special encryption for privacy, especially where you have applications where you'd say key management problems, where you are, for example, in fear of losing your key, you might want to delegate your key custody essentially, or the key handling and thus you can encrypt, decrypt, and you can lose your key, and you can recover it, and things like a smart contract cannot, for a smart contract wallet, you cannot encrypt yourself, because there's not necessarily a key associated with that, not just one key with which you could encrypt associated with the smart contract wallet, so this special encryption mechanism could enable privacy in this regard, in that you, the smart contract wallet would delegate the key custody to the special committee essentially. This is basically how you set up your API, this is swagger docs, and this is four very simple API calls, there's a setup sort of mechanism, logisticality, then you get your data for encryption, use that to encrypt, and then you just wait until time has passed, and then you receive the decryption key, and you can decrypt, or whatever, you can have the server to decrypt, but the point is at this point everything is already, the decryption key at that point is openly available, right?

And now I'm just going to sort of run through a couple of apps we built just to showcase some of the functionality, and how easy it is to build with Shutter API. So this was for Chinese Lunar New Year, called Shutter Hongbao, which is these red envelopes where you gift money essentially in Asian countries, and this is a non-custodial way to gift crypto, and the recipient can receive it using a passkey, they receive it and in the moment they receive it they create a new passkey wallet, so it's kind of a non-custodial way to onboard and also to gift crypto to people who haven't used crypto before, just have a browser essentially, but especially here the point is it is timelock encrypted, the gift, in this case some tokens, some xdai, is timelock encrypted to Lunar New Year, and would unlock only on that date. We also wanted to kind of turn this into a generalized birthday, or just like timelock gifting app, but that's kind of the state of it right now, you could use it for that, it's just maybe the brand, we should maybe rebrand it essentially. So this is what it looks like, countdown to unlock, and then you would claim to a new wallet, and it creates a new passkey wallet. This one is another fun one, so maybe you've seen people post hashes on Twitter of information that they know today, but they don't want to actually disclose it today, so this might be because they don't want to influence some governance process, or maybe because it's sort of a leak, and they don't want to, maybe they want to benefit from the information by trading or something like this, but they still want to later prove that they had this information today.

So people use hashes for that, and then let's say a few months later they reveal, and people can compare that, they can prove that they actually had the information. There's some big notable examples of this, and Kobe I think sort of leaked the impending FTX collapse, and there was some COVID predictions that people did, and Wikileaks users did, or people like associated with Wikileaks users. We built it as a, not just with hashes, we built it with encryption in mind, so that the decryption would be false. Because of the hashes, you can just choose not to reveal, right? So you might have a prediction, and then it starts coming true, so you'll just not reveal it, which you cannot do if it's actually encrypted with pressure encryption, because we have this kind of enforced, unstoppable decryption process.

So very simple, put your prediction in, encrypt, commit to it on-chain, it's uploaded, it's sort of stored on-chain, and then at some point we have that Twitter bot that receives the decryption key from the Twitter API, and then decrypts and posts about it. And here's a really cool, really well example of it, where this Twitter user Sky tweeted the results of the Optimism Future Key experiment, for example, and it was really cool. It just was revealed two days ago, so I wasn't able to include it, but he correctly predicted the three top winners of this experiment, so I think it's a very cool overlap between the Optimism Future Key experiment and this type of application. Yeah, here's someone who tweeted something about a white lotus season death prediction. Next use case is sort of similar to the Snapshot Shield voting use case, it's for juror voting.

Clarus is this arbitration mechanism, you have I think around 400 jurors that they need to agree on, and the interesting part here is that Clarus uses a specific game theory which they need to incentivize the jurors, but it leads to the fact that it encourages voting with the majority. So essentially, if you have transparent voting, people would just sort of see what other people are voting, attach to that, vote the same, and would break the whole system because people would just vote what other people vote. So Clarus needs a commit review system, and they have their own already, which is not optimal because it's sort of centralized in this way, but they're now also adding as an alternative, or maybe default, I'm not even sure, a shutter as a voting, as a commit review system. And yeah, it's just already built, but we just need an upcoming PR to include it. There's another fun one, it is sealed RFPs, so requests for proposals, could be coming from a DAO or even like a non-DAO, a real world organization that wants to fund something, wants to pay for some type of work package, and when bidders would send the bids, you wouldn't want, again, that to be transparent because then you see the one bidder sees the already existing bids, and they would try to strategically go lower, a little bit like mess with that process.

That's why in the real world, again, these RFP or procurement processes are hidden, and in the real world, you just rely on some centralized entity to prevent it, whereas in crypto, the cool thing is we can, again, build a decentralized user encryption, the special encryption mechanism to do a decentralizer and trust a centralized entity here. And here we used it ourselves to create a component for Petal Battle, which is an auction system. And yeah, we successfully received three, four bids, and we selected one to build it afterwards. Talking about Petal Battle, this is another application that we're bootstrapping, I would say. It is an impact-focused auction platform, so you can auction off stuff, I would say.

So here we have ECC tickets, we have physical things like the AdaptNode Home, and then the proceeds go to a good cause, and the good cause can vary. And we are experimenting with auction types. So we had sort of penny auctions and other cool auction types, and then Shutter sealed bid auctions will be another one that we're working on. And you just saw the RFP for that, so we haven't built it yet, but that will be kind of next. On Shutter sealed voting, it's just bringing what we already built for, for snapshot, but bringing that to, let's say, OZ Governor, smart contract framework, and then also the Safe Azorius framework, a decent building there, a governance framework on top of that.

And we have implementation guides for both of these, for OZ Governor and then also for Azorius and Safe. We also sort of vibe-coded a little on-chain Shutterized Voting POC, so very easy now for anyone to implement that. And yeah, we're working on this with Tally and Decent. Any DAOs that are interested in this should contact us, and then we would build it. We are about to launch this Ethereum Time Capsule, so that is in celebration of Ethereum's 10th anniversary.

We want people to be able to come up with a story or some experience or something that they connect deeply with Ethereum, and a photo as well, or a picture. Write that down and encrypt it and store it in this Digital Time Capsule, and then a year later, it'll be automatically revealed. That's going to be coming up very shortly to the community, bottom-up effort, just to celebrate the 10th, Ethereum's 10th anniversary. It would be awesome if as many of you guys would be interested in sharing the story. And that leaves me to the fact of saying essentially that it's very easy to build apps with Shutter API, but just a fun sort of look that I think also the apps are dead, because we have now this kind of agentic MCP way of interacting.

And this is here an example where we implemented an MCP server for the encrypted mempool. And just from the normal cloud, you can just interact with the Gnosis chain and then also the encrypted mempool on Gnosis chain, and just send the encryption actions. And we want to do the same for Shutter API, wrap essentially Shutter API into MCP. And then it would enable anyone to use those more advanced cryptography primitives just from sort of cloud and chat-gbt. So I think it's a really cool outlook for crypto in general that this UX paradigm really can make everyone a power user and use things like advanced cryptography.

Some other things we're working on is event-based and more generalized encryption triggers. So not just time-based, but then any event could trigger a decryption, which enables a lot more of these privacy use cases as well. And this is actually not at some point, we're actually relatively close to having that, is being able to homomorphically count the votes while they're still encrypted. So we can have votes be hidden forever. So FHE in general is very expensive, but some operations, if it's very specific, it can be more efficient and more scalable.

So that's what we're hoping for here, that this is actually feasible on-chain. Yeah, and some other things as well. So with that, just want to leave you here. I think if you either are building a dApp and are interested in adding these types of encryption features, again, it could be privacy, timelock, commit reveal, talk to us, DM us basically. You can if you're with a chain or if your app is on a chain and you want that chain to have Shutter API natively sort of deployed, same thing, would be awesome to get in touch and would be cool to add Shutter API to sort of the tooling stack of that chain.

A little bit like Chainlink has maybe the oracles on a chain. You could have this, the chain could have this special encryption, timelock encryption gadget on-chain and then just make it more easier for dApps on top to build. Yeah, that's it. Thanks. Questions?

Hi, this may be too much for this talk, but how does it know about time when time is relative? Is it based off like the block number? Like how does it know when to decrypt the information? Yeah, it synchronizes with the block, exactly. Yeah, so the keepers synchronize with the blockchain and yeah.

Oh, so there's a bunch of keepers that unlock it. Yeah, I didn't, I skipped over all the details of like how actually it works, but this is more like a dApp focused talk. But yeah, essentially there is this committee of decentralized keepers and always sort of a subset of them have to collaborate to generate encryption and decryption keys. And they have to sync with the blockchain and yes, and there is a threshold trust assumption, right? So they could, if enough of them collude and they can decrypt early and break with the system.

Yeah, that's something that comes with that primitive, I would say, right? Maybe not a hundred percent unavoidable. There are some cool game theoretical things you might be able to do for certain use cases, but in general, that's a trust assumption that comes with that whole cryptography, yeah. Okay, thanks. And then, someone else?

You wanted to ask a follow-up? I heard that like Gnosis chain has this at the base level, I think, like has threshold encryption. Is that like every validator on Gnosis is one of those keepers? I can't go back. Yeah, no, not yet.

So first of all, it is two sets. So we have the validators and then the keepers. We could potentially overlap them, but currently it's not really feasible. It's too many. And then also it is not a necessarily cyber-resistant set, the validators.

So it wouldn't really be possible to overlap them right now. So it's two sets and it's currently seven keepers. And then we have 8,000 of the 300,000 validators on Gnosis chain. It's not about sort of like adoption. We have all the interest from the validators to adopt it.

It's more that we still have some P2P connection issues that we want to do it. So if you send a transaction now, it just takes a little bit of time until there is a slot that is shatterized basically. So maybe from me, I didn't know, but like you can use closed with your wallet and you just drop your seed phrase. Yeah. I mean, the MCP server can run in this example, I ran it locally.

So in that case, it's sort of self-custodial, at least the MCP server. But yeah, I think that's, I would say, ongoing work that needs to be done to make that non-custodial or to make it so that it doesn't just execute, but that maybe you get a sign. And then you sign. Yeah. And then you sign.

Yeah. Which is cool because you just have to say like, I want to figure out the steps. Yeah. I think it's a cool thing for all sort of APIs or protocols that maybe are at a certain kind of complexity level where maybe it's easier for the user to have this translation layer of cloud or HTTP between it to, yeah. And I guess like these advanced photography primitives are an example.

Yeah, it's cool. Yeah. Absolutely. I agree. All right.