DAPPCON 2025: Real-World Encrypted Dapps With Shutter API - Luis Bezzenberger

DappCon 2025 · June 2025 · 24:37

Shutter Network's Luis Bezzenberger demonstrates building real-world encrypted dapps with the Shutter API. Speaking at DappCon 2025, he covers practical integration of threshold encryption for shielding transactions from front-running and MEV before they reach the public mempool. The talk treats encrypted transaction flows as production-ready infrastructure for Ethereum applications, not just a research concept.

Speakers

Topics

From DappCon 2025, hosted by Dappcon Berlin.

Transcript

you. Hello. Thank you for having me. So, yeah, I'm Luis with uh Brainbot, which is the uh core developer behind Chatter. Uh and um it is a threshold encryption DKG uh encryption as a service if you will. And uh today I'll talk about how sort of DAPs can easily add these types of encryption um features um with shutter API. Um sort of to to give a primer a little bit shutter is um ensures baseline neutrality. What does that mean? We um designed it in a way that it can um serve commit reveal use cases and it and it encryptting uh providing

encryption and then decryption keys um and it serves these applications uh of the encrypted meool which is already live on Nosis chain um and we're also um integrating it within the PBS uh transaction supply chain especially um right now into um me commit which is the builder and proposer commitment um framework together with um primev and eventually we're making the case that it should be really sort of part of the protocol uh to have this decentralized way of encrypting and decrypting and having crypto meool to level up base layer neutrality and and ensuring sensor resistance and front running resistance that's kind of track one and then we

have track two which is on the application lay layer the which what we call shatter API and there is more about providing Um, again, encryption as a service for use cases in the in governance, shielded voting, sealed bit RFPs, gaming, but but also just kind of everywhere else. Um, uh, we think it's sort of it, if you think about it, it's everywhere. You don't really see this concept of commit reveal because it is hidden usually, but we think it's kind of everywhere where there is trading and where there is like types of games. Just just like as an as a simple example, rock paper scissors.

If two people play rock, paper scissors and one of the two reveals or one of the two sees the hand of the other player before um before before they have to reveal the game is useless, right? Because then you see it and you react and yeah, but that's just the very principle and essentially it is it's everywhere, right? Because trading works that way. you you're if you see the other people's trades before before they're committed, you can leverage their information. You can leverage their sort of 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 um you can steal it essentially. And and so if you

have a commit reveal where you reve where you hide those moves or those trades and only reveal them after they are committed, you can achieve um information symmetry. And we think it's not just in trading, we think it's sort of everywhere if you think about it, right? And that's kind of the ca the the um so yeah and on a more detailed level it is basically we're on on this encrypted mele level we're encrypting transactions batching them together and then we're uh they are signed while it's still encrypted and the the block producer implicitly commits to including um the transaction and the order of the transaction without them actually knowing what's in them. Um and then decrypting and executing happens after

commitment. Um and that and that's that's very hard to censor or front run for for the rock producer and also for for anyone else. That's that the block producer usually has the the ultimate power to um to order transactions or to to censor. And if we can make them not censor a front run, hopefully the entire transaction supply chain can't do that. And then we use threshold encryption to not have a centralized sort of trust assumption there to encrypt and decrypt.

You could do this centralized, right? But then again, you're shifting the the uh responsibility to a centralized entity. And with this threshold encryption kind of having k out of n parties having to collaborate to generate those keys, we can um drust essentially the encryptor or decryptor. Uh and that's live on Nosis chain. Um uh it is sort of still in a little bit of an output out of protocol fashion, but it proves that in in principle it can work. We have 8,000 validators um and and we have um a couple of thousand CH transactions so far and we have a limited keeper set so far ironing

out some some kind of P2P communication issues. Um but that's kind of the state of it right now. Um it is also so now we're moving away a little bit from this sort of encrypted meool protocol level thing more to the application layer. Um it is also implemented into snapshot um v um governance right where it provides um shield voting. So encrypting the real-time results during the vote and only decrypting afterwards. And we do that again for information symmetry. So just like in real world elections, you don't want to show the real-time results during the votes because that really influences decision-m and simply

speaking people who vote later um have an advant information advantage over the people who vote earlier. Um that's why you don't do it in in the real that's why you don't show the real time results in real world. And in and in in the blockchain voting you can you can hide it like this and you can switch on shutter in the in your admin settings in your snapshot space and for example arbitum uses it for their elections uh and and shape shift uses it in some and some other bigger dows as well. Uh uh so yeah and then the case we're making here is with chutter API it is very easy really for dev developers to to implement this type of encryption as a service. Um again commit reveal and andor time time lock encryption also

some some level some some privacy applications as well um and then just a list of potential use cases um for example sealed bid auctions and I'll talk about something uh that we're building in this regard um bounty embedding platforms procurement tools again we have sort of a a little p there as well or little application that I'll show um onchain games especially simultaneous is move games. Um in the past we had um a game called Dowlomacy. So a diplomacy variant but using u but on chain and for for Dows and again using this commit reveal because similar problem if you have many players moving at the same time in one in one move in

one round then you do not want to show those moves because again you have this front running issue where they other players can see what's happening. negotiation tools where you don't want to show stuff prematurely. Time lock time lock applications. Um what's not on here is yeah privacy essentially right. Um you can also use threshold encryption for privacy uh especially where you have applications where you would say you key key key management problems right where you don't where you are for example in fear of losing your key you might want to delegate the the your key custody essentially or the key handling to a

threshold sort of um and thus you can encrypt decrypt um without and and you can lose your key, right? And you can recover it. Uh and and things like a smart contract cannot you can for a smart contract wallet, you cannot encrypt uh yourself, right? Because you don't have 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 this threshold encryption mechanism could enable um privacy in this regard in that you the smart contract wallet would delegate the key custody to the to the threshold committee essentially um that this is basically shutter API docs

and this is four very simple um API calls um there's a setup sort of mechanism register an entity then you get your data for encryption use that to encrypt and then You just wait until the time has passed. Then you and then you receive the decryption key and and you can dec or whatever you can have the server to decry. But the point is at this point everything is already uh the the decryption key at that point is is openly available, right? Um 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 Cher API. Um so this was um for Chinese Luna

New Year called Shhatter Hung Bao which is these red envelopes where you gift money essentially in Asian countries and this is a um non-custodial way to gift um crypto and the recipient can receive it using uh a pass key w they can they receive it and in the moment they receive it they create a new pass key 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. Um, but especially here the point is it is time lock encrypted. The the gift in this case some tokens, right? Some some X die is time lock encrypted to Luna New Year, right? And would unlock only on

that date. We also wanted to um kind of turn this into a into a generalized birthday or just like time lock gifting app, but that's kind of state of it right now. You could use it for that. It's just maybe the we should maybe rebrand it essentially. Um so this is what it looks like. Countdown to unlock and then you would claim to a new wallet and it creates a new Pasc wallet. Uh uh yeah. Uh 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 they 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. Um so people use hashes for that. uh and then late then let's say three months later they they reveal and people can compare that can they can prove that they actually had this information there's some some big uh notable examples of this and Kobe I think sort of leaked the the impending pending uh FTX collapse and there was some some co predictions that people did um and Wikileaks uses this or people like associate with Wikileaks uses we built it as a not just with hashes we built it to um with encryption in mind so that the decryption would be false

because with the hashes you can just choose not to reveal right so you might have a prediction and then it it's not coming true. So you'll just not not um reveal it which you cannot do if it's actually encrypted um with threshold encryption because we have this kind of enforced unstoppable decryption process. So very simple have put your 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 a that um a Twitter bot that uh that uses receives the decryption key from the Twitter API and then decrypts um and and posts about it. And here's a really cool real world example of it um where

where this Twitter user Sky um tweeted the the results of the optimism future key experiment um for example and it was really cool. It just was re revealed two days ago so I kind I didn't wasn't able to include it but he correctly uh predicted the three top um the three top winners of this experiment. So I think it's a very cool overlap between the optimism future key experiment and this and this type of application. Yeah. Here's someone who tweeted about um something about white lotus season death prediction. Yeah.

Uh next use case is uh sort of similar to the snapshot uh shield voting use case is it's is for claros juror voting. Um you know claros is this arbitration mechanism. you have the I think around 400 euros that they need to agree on and the interesting part here is that Claras uses um a specific game theory to and which they need to incentivize their the jurors but it leads to the fact that um the it encourages voting with the majority. So essentially the if if you don't have if you have transparent voting people would just sort of see what other people are voting attached to that vote the same and would break the

whole system because yeah people would just vote what other people vote. So Claras needs um a reveal system and they have their own already which um which is not not optimal because it's sort of centralized in in this way. Um but but they're now also adding as an alternative or maybe default, I'm not even sure uh the CL uh shutter as a voting as a as a as a commit reveal system. Um and yeah, it's just already built. Um but we just need an upcoming PR to to include it.

Um there's another fun one. It is uh sealed RFPs. So request for proposals could be coming from a DAO or even like a non non Dowo real world organization that need that wants to get um something funded sorry wants to fund something wants to get pay for some type of work package uh and you when biders would um send the bids you you wouldn't want again them that to be transparent because then you see the one bit sees the already existing bids and they would say they would um try to strategically go lower go a bit lower so you a little bit like mess with the with the that

process that's why in the real world again these RFP or uh 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 use the encryption this threshold encryption uh mechanism to to do a decentralized right and dustrust a centralized entity here. And here we used it um ourselves to create a component uh for pedal battle which is an auction system uh and um yeah we we successfully received four uh three four bids and we selected one um to to build it uh afterwards. Right. Um

uh talking about pedal battle this is another uh application that we're bootstrapping I would say and that is an impact focused auction platform so you can so you can uh auction off uh stuff I would say so here we have ECC tickets we have physical things like the adap node home and then the proceeds go to uh a good cause and the good cause can vary and um we are experience 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 now. And you just saw the the RFP for that. So we haven't built it yet, but that will be kind of next. uh onchain shield voting is just

bringing what we already built for for snapshot but bringing that to um say oz governor smart smart contract framework and then also the uh safe aorius um framework decent are building their are building their governance framework on top of that um and we have implementation guides for both of these for for oz governor and then also for um aorius and safe uh we also sort VIP code a little onchange header rest voting PC. So um very easy now for anyone to to implement that and um yeah we're uh we're working on this with tally and and decent uh any dows that are interested in this should should contact us and

then we can we would build it right. Um uh we are about to launch this Ethereum time capsule. So that is in celebration of the 10th Ethereum's 10th anniversary. We want people to be able to um come up with a story or a some experience or something that they connect deeply with Ethereum to and and a photo as well or a picture uh write that down um 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. Um sort of a community bottom up effort just to just

to celebrate the 10th Etheum's 10th anniversary. Um yeah, would be awesome if as many possible would of you guys would be interested in sharing your story. Uh and that leaves me to the fact or saying essentially it's very easy to build apps with API but um just a fun sort of outlet I think um also uh dabs are dead um 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 meool uh and it just from the normal Claude, you can just interact

with um the Nosis chain and then also the encrypted meool on Nosis chain and just send a encryption transactions and we want to do the same for shutter API wrap essentially shutter API into an MCP and then it would enable anyone to use those I would say like more advanced um cryptography primitives just from their sort of cloud and chat GBT. So I think it's a really cool outlook for crypto in general that that that this this UX paradigm really makes can make everyone a power user um and use things like advanced cryptography, right? Um some other things we're working on uh is event based and more generalized decryption 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. uh at some point we want to and this is actually not at some point we're actually relatively close to to having that um is being able to homorphically count the votes while they're still encrypted so we can have um 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 and and more scalable. So that's what we're hoping for here that this is actually um feasible on chain. Um yeah and some other things as well.

So um with that just want to leave you here. I think if you either are building a DAP and are interested in adding these types of encryption features um again could be privacy time lock commit reveal um talk to us um DM us basically uh you can scan the QR code and DM us uh and then sim similarly if you are if you are with a chain or if you are 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 it would be cool to to add shutter API to sort of the tooling stack of that chain a little bit like chain link has maybe the oracles on a

chain. You could have this uh the chain could have this um threshold encryption time lock encryption gadget on chain and then just make make it more easier for dabs on top to to build. Um yeah, that's it. Thanks [Applause] questions. This may be too much for this talk, but um 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 are synchronized with the blockchain and yeah. Oh, so there's a bunch of keepers that unlock it. Yeah. Yeah. I didn't I skipped over all the details of like how actually it works, right? This is more like a DevX I would say and DEAP focused talk, but yeah, essentially there is this this committee of decentralized keepers and always sort of a subset of them have to collaborate to generate encryption and decryption keys. um and they have to sync with the blockchain and yes and there is a threshold trust assumption right so they could coll if if enough of them collude and they can decrypt early um and kind of break a little bit the system uh yeah that's something that comes with that primitive I would say

right and is un uh maybe not 100% unavoidable there are some some cool game theoretical things you might be able to do for certain use cases but in general that's um you have a trust assumption that comes with the cryptography. Yeah. Okay. Thanks. And then someone else you want to ask for? So I heard that like Nosis chain has this at the base level I think um like has threshold encryption. Is that like every validator on Nosis is one of those uh keepers?

Is that why I can't go back? Uh yeah. No. Um not yet. So um so first of all it is two sets. So we have the the validators and then the keepers. We could potentially overlap them but it's currently it's not really feasible. It's too many. Um and then also it is not a necessarily resistant set the validators. So it's wouldn't really be possible to overlap them right now. So it's two sets and it's currently seven keepers. And then um we have 8,000 of the of the 300,000 validators on Nosis chain. Um it's not it's not about sort of like adopt the we have all the interest from from the validators to to uh adopt it. It's more

that we still have some some P2P connection issues um that we want to iron out before we would want to scale it to the full set. But currently have a small set of the validators that that do it. So if you send a transaction now it just takes a lot a little bit of time until there is a slot that is shutterized basically. Cool. Thanks. So maybe from from me I didn't know but like you can use clothes with your wallet and you just drop your seat phrase. Yeah. Yeah. So yeah, that's is fully custo I mean the MCP server can run I run in this example example I ran

it locally. So in that case it is not 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 you it doesn't just execute but that maybe you get a signed then you sign. Yeah. And then you sign. Yeah. which is cool because you just have to say like I want to do this figure out the steps. Yeah. Yeah. I think it's a cool thing for all all sort of APIs or protocols that maybe are as a certain kind of complexity level where where maybe it's easier for the user to have this translation layer of the of Claude or HGBT between it to to Yeah. And I guess like these advanced

cryptography primitives are an example. Yeah, it's cool. Apps are dead. I agree. All right.