Confidential Systems for Institutional Ethereum | Oskar, ETHSystem | ETHTaipei 2026

Wait. Oh. Hello. We're at Oscar, uh Wuyong Ingwen, and Yian Zhang. Uh So, hi everyone.

Uh my name is Oscar. I'm going to talk to you about confidential systems for institutional Ethereum. Uh so, we recently spun out of the firm foundation where we worked a lot on institutional privacy and I have a new entity, a firm systems. And that's what I'm going to talk about today. A little bit of a context when it comes to what institutions are looking for on Ethereum.

Uh some proof of work we've done and how we can use the work we've been working on. So, last year I gave a slightly more uh philosophical talk. I was looking at different sort of uh movements in the crypto space. If it's uh like Cypherpunk movement, Decred, Luna Punk, Solar Punk, and so on. And how they kind of look at things from different angles and they care about different things.

Uh but oftentimes they have very like they have this like a narrow intersection as well in terms of the problems they care about. And this is usually related to trust. So, how do you trust at scale? How do you deal with things like authenticity, privacy, and accountability without having these kind of central top-down uh designs? Uh the last year I've been focusing on part of that problem, but so sort of a bit more narrow and practical when it comes to how institutions can build on Ethereum and how to think about trust uh trust problems and sort of building these trust-minimized designs.

So, one thing that's been happening over the last few years is that there's been a lot more regulatory clarity. Um so, that used to be a big blocker in terms of mass adoption, especially when it comes to sort of more regulated uh institutions. Uh last few years we've seen things like the the Genius Act. We have a MiCA in EU and there's various other efforts in Taiwan and in Singapore and Hong Kong, Japan and so on. So, while there's still a lot more work to be done on the regulation side and sort of legal clarity, we're in a much better spot now compared to a few years ago.

And from our conversations with hundreds of institutions over the last year, uh privacy is really the main blocker now, especially when it comes to moving onto public blockchains like Ethereum, because they have a system that already works. And when they want to build on public infrastructure, all of a sudden there's like a lot of assumptions that need to be challenged. And how to do them in like a rigorous way is like a big challenge. Uh and obviously Ethereum is good for all the reasons we like it, the decentralization. So, it's kind of like a shelling point uh for for a lot of institutions.

Uh there's no one sort of who controls the entire ecosystem, uh access to liquidity, uh settlement finality, and all that good stuff. So, the big problem with Ethereum is obviously that it's public. So, the ledger's public and it's very easy to see positions and relationships. And uh you can infer a lot of things from that. And that's a big problem if you're an institution, uh where sort of you can't really There's no difference between uh what a competitor sees and what an auditor sees.

So, that's that's like a kind of a big problem. In terms of how to think about this, uh there's like two classes or approaches you can think about. Like one is privacy by policy and the other is privacy by math. Privacy by policy is maybe what most people are more familiar with. Uh so, it's kind of like these data silos, kind of just trusting a third party, uh and relying on sort of rule of law and and goodwill and so on.

And while that can be useful in some cases, and we don't want to really dump completely, some of the things that's like interesting about this technology is that it enables us to trust these systems we build up. Uh sort of trusting the math instead. So, for example, using zero-knowledge proofs, uh sort of to verify certain things while only revealing a subset of And I would argue that if you're going to move on to sort of blockchains, it makes more sense and it's more interesting to go in the direction of like privacy by math, sort of actually take advantage of everything that sort of public blockchains allow. Obviously, it's not as black as white as this. There's like a lot of middle ground, but in terms of bias, I think the privacy by math is more interesting and what we are more focused on.

So, one thing we've been doing a lot the last year is trying to map the space and understand what it looks like. And when you we talk to institutions, oftentimes we try to understand like what are the specific problems? What are the business problems? And try to understand it how they think about it in their own terms, whether that's like business reality or legal constraints or other types of constraints. And we basically try to categorize that in terms of use cases.

So, these are not just use cases we sort of dreamt up and wrote a blog post about. This is based off conversations with hundreds of institutions. So, we This is an open-source resource that we have that you can look up into and sort of see these use cases. Then what we have is also like patterns. So, these are protocols or ways of solving certain problems that exist in the Ethereum ecosystem.

And as well as approaches, so like how to think about solving these problems. And that might not just be use this standard or use this library. It might also involve using certain vendors that come with, for example, SLAs and these sorts of things. So, this this this privacy market map, you can check it out. It has a lot of information about various types of use cases and so on.

To make it a little bit more concrete, we'll follow one sort of use case when it comes to private stablecoin payments. So, first of all, when we hear private stablecoin payments, we might think, well, that's just simple. That's one thing. But actually, it's very different depending on what are we talking about. It's different in terms of the region, if it's US, if it's Europe, if it's Taiwan, if it's if it's a or whatnot, like the constraints that these system institutions operate under are slightly different.

And it's also very different in terms of what type of payments are we talking about. Is it like 10 banks that are settling millions among each other every day, or is it a retail payment for 100 million users where you want to enable end users to buy a cup of coffee? So, depending on the specifics of the use case, that has dramatic implications for the design. Uh but the general requirements might be something you want to hide the amounts or the counterparties. And then there's different types of approaches how you do that.

So, you might do a privacy pool on on layer one. You might have some kind of privacy L2 or use a plasma design and so on. And then what we try to do is we try to take these approaches and uh do like prototype work with them. Because often times what you see is maybe you hear about the new uh project and it sounds amazing, the best thing since sliced bread, but then you try to run the code and it doesn't even compile. Or they're like uh throughput requirement what they claim to be able to provide is that not at all what reality looks like.

So, it's very important to actually run this stuff and understand how it works in the real world. And one big thing that we noticed as we've been mapping the space is that there's really no silver bullet. And often times you come across projects and they might say, "Use Just use our thing. It will solve all your problems." And then you talk to 10 other people and they say the exact same thing, except that all of their solutions are different.

Uh so, what that tells me is that there's really no sort of silver bullet here. Uh you really have to think about like what are the specifics about your use case. And and it depends on a lot of things. Like for example, how you want to do execution, what your functional requirements are when it comes to sort of uh latency and throughput, uh what sort of disclosure requirements you are have, who's going to sort of operate it, how do you want to think about recovery, and so on. So, once you get into the details of what these issues actually need, there's like a lot of things to consider and there's not just one design that fits everything.

Uh also, one thing we have to think about is like two different kind of classes of problems, if you will. And if you sort of uh as an end users myself, if you look at news or crypto Twitter, whatever, you might think that most of it is like institution to end users. So, that's kind of like your retail stable coins and so on. And while that's definitely a thing and it's important, I would argue that in our conversations we noticed that most of the sort of interesting problems and so on is more on the institution to institution side. So, that's kind of the plumbing of the world like a lot of payment instructions and so on, which is you know, banks talking to each other or some kind of settlement infrastructure that's very much like in nitty-gritty and not something that you would get exposed to unless you actually understand the business problem.

Uh And I would also argue that when we talk to these institutions, to some extent they even care more about sort of the some sort of bank values like privacy and sensor resistance than like a lot of people in in sort of the web free native space precisely because it has a very massive impact on the bottom line. Uh they don't want competitors to see their their sort of payment flows and they care a lot about sensor resistance uh because often times these are bigger decisions and they put more thought into it compared to what an end users might do or might want to do. So, we we deal with both and they have slightly different dynamics, but we focus a lot also on the institution to institution side of things. Uh so, some things that we've been working on uh that's sort of public and open source just to see some work we've done. So, over the last year we've done uh 12 uh total POCs that are public.

So, these are open source code uh permissive licensing. They all come with like a specification and rigorous threat model. We also have write-ups for all of these. Uh I won't have time to go into all of them in detail, uh but I'll touch on some of them uh a little bit and give an overview and if you're interested, you can go to our website and read more. So, the first thing is private bonds where we tried three different approaches.

And private bonds is kind of interesting because we see a reasonable amount of demand for it um and basically it's a way to sort of simplify things for institutions where they want to issue a a a private bond and they can have a single register and they don't have to deal with like chain of custodians and it also gives them access to liquidity and counterparties and so on. There's a few different ways we approach it. So one was kind of private note model. So this is writing circuits run on L1. Another one was using privacy L2 Aztec in this case and a third one was with FCL and Summer.

And all of these there are more approaches by the way but these are three fairly representative approaches and they all sort of are valid but it depends a lot on on the specifics. So you have to think about the trade-offs. So for example when it comes to custom UTXO model it's good because you get full control but obviously you have to write the circuits yourself which is a heavy lift for a lot of institutions. Aztec is nice because it gives you private state by default but on the flip side you kind of are relying on sort of their their network model and the the throughput they can have and so on. Summer and FCL is good because you can encrypt on on encrypted balances and so on but you also have some issues when it comes to actual operations and decryption and so on.

So a lot of it depends on the timeline and exactly the kind of requirements you have. And this is something we noticed as well that institutions they differ a lot in terms of their capabilities. So some of these institutions they have their own R&D department with 30 people and cryptography PhDs. So they know they've been following this space for a decade. They know very well what's going on and what's possible and what's not.

But on the flip side you also have people or institutions that maybe just started looking at this last year and they have one person and they want something that's more like a white label thing. They just want a vendor they can trust who does things for them. So these these differ a lot as well in terms of the type of infrastructure they're willing to run. Private payments is another example that I mentioned. Um and a lot of this sort of stems from sort of Zcash and the shielded pool abstraction, which later on come to came to Ethereum with things like Tornado Cash and and also Railgun privacy pools, Bermuda, and so on.

Uh so you have a base shielded pool, um sort of gives you some privacy guarantees there. Uh this is also like a compliant version, so it's attested in terms of entry. And then we did uh two different extensions. So one was how you can hide sort of wallet reads using private information retrieval, and also how you can do some performance optimization to solve one of the problems when it comes to nullifier growth. Uh we also did a compliance extension where basically you can ensure that private notes are inside a pool uh stay compliant uh for the cycle, so not just on entry and exit.

And then we also prototype a version when it comes to plasma and int max, which is like a different way of uh solving this problem. So one big thing here is institutions, regulatory institutions, they're very different from sort of your web three crypto native uh sort of fully permissionless um actors in that they're operating under different constraints. Uh as a regulator financial institution, you do have certain sort of um laws and so on you need to abide by. And it's not necessarily a moral thing, it's just a matter of the the regular framework that they operate under. And this is varies a lot as well depending on where they're situated.

And if you talk to institutions, they often sometimes do like regulatory arbitrage and these sorts of things to find a more favorable uh jurisdiction where they can do more things. But in general, uh often something they care about is who's able to take part in this kind of uh shielded pool. Uh so you want to do some kind of KYC or something like that. Uh you might want to have a running total where you have a certain threshold that can't be you want to alert things if something happens there. Uh you might want to have some audit trail and so on.

So, this is not sort of your permission to put permission in this pool. It's something that's like on top that works for these regulatory financial institutions. Uh I won't go too much into detail here, but basically it's a similar kind of model to to silo pools where you are able to sort of hide this transaction on L1 and so just do things inside the silo pool and you generate a proof and then that's verified on Ethereum. Uh another POC that we did was when it comes to atomic settlement and specifically delivery versus payment. So, delivery versus payment is a kind of legal term, if you will, where if you have some asset, the delivery of the asset and the payment of the asset has to happen at exactly the same time.

And this is strictly speaking a bit more involved than like a swap between two ERC-20 tokens because oftentimes this can happen on different networks. So, one might be a crypto network and the other might be a completely different system that's like outside of the the the web free and crypto space completely. Uh but the core idea is that you need to make sure it's atomic. So, the delivery of some of an asset has to happen at the same time as the payment. So, we did this with bonds and cash and using TE as a as a coordinator to make sure you keep this kind of invariant.

That's settlement. Another thing that's quite common is having some kind of private business logic. Uh this is we call it like a do it do it yourself validium. So, this is more towards like sync-a-sync style constructions where basically you have some private state and then you have some arbitrary business logic. So, maybe you want to do insurance or you have some specific set of conditions that have to be met and you don't want to write this in a circuit.

You just want to write normal business logic code and then you use sort of a CKV M here to create a proof that then gets verified on L1 while still keeping state private. Uh and in our POC we also had this idea where users can force withdrawal. So, if the operator goes rogue, you always have a way to sort of go back to the L1. So, those are like some examples of some POCs that we have done. This sort of shows how to solve some of these use cases.

And if you're interested, definitely check out our website where you can read the write-up uh with full details, also with the code and the specification. Uh, a little bit about how you can sort of use this. So, I want to go back to the map I mentioned in the very beginning. Uh, the map process is a very powerful tool and is actually a kind of feedback loop. Because we start off with institutions' use cases.

So, these are real requirements often that we've heard from several institutions. And then we're able to sort of anonymize them uh and and put them into the map. And then basically, of the most pressing ones or more interesting ones, we do POCs and specification works. Uh, and then as part of that, we also do more research to sort of fill up and make the map more complete. So, sort of catching up to the state of the art.

Uh, and doing a write-up as well. And then sharing that with the ecosystem. So, the ecosystem can sort of build and find the gaps that exist. So, that can either be for protocol developers to understand what are sort of a new API that would be useful. What is like how can we use MPC for this custody problem?

Uh, or maybe a vendor like that that sees that actually this is a big problem and so on. And and the the result of this feedback loop is that institutions get better design that actually takes advantage of all of these affordances we have in the firm ecosystem. And the ecosystem also gets ground truth. Because traditionally, it's quite difficult for a lot of these uh ecosystem teams to get access to institutions and understand what they actually need. Another big thing that we work a lot on is specifications.

Uh, and I would say that we're kind of past this YOLO phase of crypto where you can just put out some DeFi protocol and get hacked the next day. Uh, you have these massive institutions and they already have product market fit. They have billions of dollars that they want to move on chain and they want to make sure it works and it's secure. So, having technical specifications is very useful for this. I think the Ethereum ecosystem is very good at it when it comes to the base layer protocol, but it's not as good as when it comes to sort of the more application layer.

So, we want to sort of try to elevate the space a little bit there and being very rigorous about like what are what are sort of the assumptions, what are the the threat models, what are the actual security guarantees and being very sort of clear about those uh guarantees. Uh so, that's something we're pushing out as well and sort of trying to harden it and act as a useful resource for the ecosystem. Another thing is kind of these building blocks and open source libraries. Um so, as we do these POCs, we notice that there are like common problems um and based on that we sort of extract these model libraries that can be used by anyone uh whether you're working with institutions or just working on some kind of privacy uh thing on top of Ethereum. Uh and these are very simple, small primitive libraries with permissive licensing and sort of hardened.

So, also like very bare-bones so you can use them in a secure VM context as well. Uh one example that we released a few weeks ago is router tree uh which is kind of a Merkle tree construction uh and it's written in Rust and we were able to sort of compared to the TypeScript um baseline and make it like 40-50 times faster. Obviously, compare Rust TypeScript is not is not apples to apples uh but it's still like a useful thing um for a very common operation, especially as you scale these systems up. Another library we released recently is seal ring uh which is a way to make sort of uh these encrypted notes which is a common primitive uh more modular and and also more robust because oftentimes you want to use it and maybe you want to change the curve you're using or what not and this makes it easy to do so. Uh and we have a few more things coming out and it's all under permissive licensing so you can use it for whatever you want, whatever you want.

Uh so, I mentioned a lot about like POCs and so on. And and one thing is obviously a POC doesn't take you all the way to production system. Uh there's like a lot of other things you have to take care of when it comes to the whole flow, when it comes to wallets or uh how you do operation, recovery, how you interact with the rest of the business, and so on. Uh that's less on the open-source side and more something that we do in private engagements uh with institutions, but it's important to point out as well. Uh one way we think about sort of our role uh is that you have these institutions with business problems and sort of existing demand, and we try to sort of uh translate and take those requirements, anonymize them, bring them to the Ethereum ecosystem, and the Ethereum ecosystem provides all these protocols and and research and tools and and products and so on, and try to document them and sort of show institutions how they can use them, and act as this feedback loop that I mentioned before.

And obviously, we're just one of many actors doing this, uh but because we are able to both focus on

[snorts]

the sort of technical execution side, but also talk to these institutions, uh we can help translate between these two worlds, especially because they traditionally speaking, they don't speak to each other and uh they don't really speak the same language as well. So, there's like a lot of translation work in terms of like business uh requirements or legal constraints that has to be mapped to technical requirements and technical capabilities. And the way we think about ourselves is like being pragmatic and principled, so we think that institutions will build these systems anyway. Uh a lot of finances and other institutions are moving on chain over the next few decades, and it will happen with or without us. Uh and basically, what gets built today will sort of set the defaults for decades to come, and we would rather be a part of that as opposed to ignoring it.

Uh and I think those of us in Ethereum who care about these guarantees should help design them and sort of get this adoption. Uh we want to be pragmatic about the constraints, but also be very principled about the guarantees that we can provide. Uh and being rigorous and and honest about sort of the trade-offs in terms of specifications and and what properties they actually have. Uh some calls to action. If you're an institution, definitely uh check out our map and maybe you can also come talk to us and we can see if we can help you out somehow.

If you're a builder or vendor, uh definitely read our our POCs and check out our libraries and write-ups. Uh maybe there's also room for you in the in the privacy map and it's quite a useful tool because a lot of these users actually look there. So, if that's something you're interested in, that's a good way to get exposure. Uh and if you're more on the Cypherpunk sort of individual side, definitely read our specifications and threat models and and challenge sort of the assumptions, security problems we have, and help us keep on us honest honest. Uh that's it for me and everything I just shared is public, open source, uh write-up, specification, code, everything.

Thank you. Any questions?

[music]