Institutional Privacy on Ethereum by Oskar Thorén - DeFi Today Devconnect ARG
DeFi Today at Devconnect Argentina 2025 · 21 Nov 2025 · 24:27
Oskar Thorén, who leads the Ethereum Foundation's Institutional Privacy Task Force, gives a talk on institutional privacy on Ethereum at DeFi Today during Devconnect Argentina. The session addresses how institutions can use Ethereum while keeping sensitive financial details private, a topic at the centre of privacy technology and onchain adoption.
Speakers
Topics
From DeFi Today at Devconnect Argentina 2025, hosted by DeFi Today.
Transcript
Hi. Hi. Hello. Thank you for those who have stayed. It's it's very lovely to see that there's still some people here at for on the last day of Dev Connect. So now we'll have a final section on innovation and there will be two talks. The first one will be Oscar from the Ethereum Foundation who I'll introduce properly in a second and then the second one will be Austin Adams who is a researcher formerly at Uniswap and now at his own company called Wetstone Research. Um, I'm very excited for this one because it's more innovationdriven, more research, which is closer to my heart. And we'll start off with Oscar, who's the intentional privacy task force team lead at the Ethereum Foundation, telling us what privacy demands institutions have from Ethereum. Please give a big round of applause.
>> Hi everyone. Last day of Dev Connect. Glad you guys are all still hanging in there. So, my name is Oscar. Uh I'm leading uh the IPDF team at the Ethereum Foundation. So it stands for the institutional privacy task force and I co-lead it together with Mo. Uh it's a new team and I'm going to talk to you about institutional privacy on Ethereum. Uh there's three takeaways I want you guys to have from this talk. The first is that institutions they do want privacy on Ethereum. It's like the main blocker uh right now. And the second thing is in terms of understanding what these users actually need and uh in that direction we're building this open privacy market map of the space to sort of understand this better. And the third thing is that you can sort of contribute to this effort and help shape this.
So first of all why does this matter? Like why do we care about institutional privacy? H there's a few reasons right but like I think a very big one is just obviously these are like massive massive markets. We're talking like in the trillions of dollars and they do want access to these like public rails and open interoperability that Ethereum provides. And it used to be the case that regulation or regulatory clarity was the main blocker. If you've been in the space for a while, you know that a few years ago it was like that was like a no starter for a lot of these institutions. But nowadays and especially this year, privacy is actually the main blocker. Uh, and it's kind of not the fault for these kind of multistakeholder flows where it's not just sort of Alice sending something to Bob, but you also have
things like regulators and like custodians and all of these other sort of parties that has to have sort of some kind of privacy invariance that have to be uh kept. So what about demand from when it comes to privacy? So institutions are actively exploring and building on Ethereum. Uh, and when we look at Ethereum, there's obviously like stable coins and real world assets and DeFi that's dominating. Um and that's like one of the reasons it used to be right that regulatory uncertainty was a critical blocker but nowadays it's privacy and that's sort of what is stopping them from from building on Ethereum. How can we onboard institutions? Like what does it mean to onboard institutions and and I guess like how should we why should we care about this? Um if you look at for example like fixed income markets like
$15 market and crossber payments is like mindboggling like one quadrillion dollars a year. uh and more globally billions of users uh use some kind of form and payment methods like 80% of population and if you look at onchain activity it's definitely significant but it's basically a rounding area compared to these more mature markets uh like $300 billion stable coins in terms of market cap real world assets uh was around 30 billion it's gone up a little bit since then um and this is like a screenshot that you can see from institutions on ethereum.org that sort of shows sort of the dominance when it comes to Ethereum usage. Actually, this has changed a little bit. So, the last week or so, uh there's been more usage by, for example, Canton when it comes to real world assets. And I think this sort
of points to how a single institution can sort of tip the scale. Uh you should take those numbers with a bit of grain grain of salt. Uh but the point here is that we're trying to set up the defaults for next decade or so. and and privacy. If we if we sort of enable privacy, we're not going to get these like massive uh monetary inflows that that are possible uh leverage and impact. So just getting like one% penetration of traditional finance would sort of move like real volume and you would be able to increase real world assets when like 10 or 100x uh and just having a single major uh institution would touch millions of end users. And this is like not hypothetical. There's like various pilot and production rails that are already
announced and there's a lot more that's sort of going on and will be announced over the next six to 12 months. Uh there's a lot of overlap here with another initiative at the Foundation which is a trillion dollar security initiative which basically like how can we create infrastructure that sort of can meaningfully secure a trillion dollars. That could either be a billion users with $1,000 each uh or it could be like a thousand contracts with a billion dollars locked up in each. And we have like massive le leverage here and the time is very much now in terms of sort of providing these kind of uh affordances when it comes to institutions.
Why do institutions want privacy so unlike sort of the the roots of sort of crypto and bitcoin ethereum and so on. This is not like a philosophical moral question for them. It's very much about bottom line impact here. So in terms of like pricing and in execution and counterparty risk especially when it's doing larger transactions like you don't want to you don't necessarily want to leak that because you can get front run and this like measurably will impact them bottom line. Another reason is obviously like compliance. They are operating all institutions are operating in like a regulatory environment regardless of what jurisdiction that might be and they need to be compliant with their local uh laws and regulation.
This also ties into the idea of like operational certainty and familiarity because these large institutions they already have product market fit. They've been operating for decades and extremely mature and know what they are doing in sort of the business sense and also the legal sense and they basically want to take all of that institutional knowledge and and mental models and basically port it on top of of uh public blockchains. And that means that you have to sort of find a way to map these two very very different worlds. And finally a big one is also in terms of strategic confidentiality. So a lot of institutions they don't want to leak sort of the positions or monetary flows or kind of intentions like if you buy a bond or transfer or so on and it's like a $50 million you don't necessarily want to leak that to your competitors and the
same thing if you're doing something when it comes to supply chains that's like a competitive advantage. How does institutional privacy differ from kind of I guess more individual privacy? So there's a few ways they differ. Uh one major one is that there are often many actors. So it's not just about like Alice uh sending some money to Bob. It's one when one institution gets onboarded it will have sort of a massive impact on all of their users and it can even be like an end to end relationship when we talk about something like private trades. If you imagine like a stock exchange running on top of Ethereum then it would be like even more complex interactions. Another big difference is that there's very very high cost of violations. Like for example, if you as an individual buy a a cup of coffee, uh you might care a
little bit about privacy and so on. But in terms of the mental overhead, it's very very different from an institution that's maybe doing like a $10 million deal or so where that will like have a measurable impact, right? So the cost of violation can be measured in terms of dollar dollar value. And obviously auditability is mandatory as well. uh the way institutions think about privacy is like not the same as opacity. It's more about having some kind of scoped visibility of like who owns what uh when and under what specific circumstances. So like how can you control and fine-tune that when we think about like institutional demand you can sort of compare like public versus private rails. Uh and a big reason why a lot of insters want to move to sort of public networks like Ethereum is because of access to like things like liquidity, sensor
persistence, like 10 years of uptime and ultimately being kind of like a settlement selling point if you will for the space as well as all the network effects that come with it in terms of users and dev tooling and other types like block explorers and all of these types of things, right? Uh there are alternatives like private and consortium consortium chains uh and they exist but they kind of limit composibility and interroability and they can provide some they can be pose some kind of risk for these institutions that sort of are used to operating with very mature uh partners or on very sort of neutral infrastructure. Uh but in order for these institutions to actually move to a firm the ecosystem as a whole need to satisfy these institutional privacy requirements on public infrastructure. So how do we do that? Well, we need to understand
exactly what those requirements are. And this leads into this this uh work we've been doing on in terms of the institutional privacy map. Uh and just briefly a little bit of our team. So IPDF, we're a new team at the Foundation. It's been on for like two or three months. Uh so it's institutional privacy task force and what we're trying to do is helping institutions build on top of Ethereum. It's a very it's a very small team focus team has like business leads technical architects and researchers and it's kind of a collaboration between the enterprise team and the ecode cluster at EF as well as the privacy uh cluster um under EF with a sort of more focus on more the technical R&D side of things and what we do is we do things like workshops and various like deep dives and we
collaborate with institutions as well as vendors in the space and basically trying to demystify the space because what ends up happening is that you have these major institutions and they get approached by other products with very mature uh BD function and they get to told certain things but it's hard for them to know to what extent they should take that at face value and so on. Um and I also want to point out that these institutions some of them they don't know a lot and it's like a lot of education involved but others are extremely sophisticated that might have like an R&D R&D team that's been operating for many years and they have like 20 people uh and so on. they differ a lot in terms of majority but in general what they want is some kind of guidance and that's like one role we're
playing at EF and IPDF uh in terms of sort of surfacing these truths and explaining what is what exists in the ecosystem and how how they should think about privacy and and so on and the ultimate goal here right is that we're trying to onboard institution onto Ethereum and providing privacy that's performant secure usable and accessible specifically with a focus on institutions so how do work. So this is sort of not we sat down and thought about some cool ideas of like oh here's how enterprises or institutions can use Ethereum. These are like real world valid use cases.
These are some of the largest institutions in the world that we talk to and they tell us exactly what they want and sort of the conditions around that and and the various constraints can be sort of business related. They can be when it comes like legal requirements if they operate in specific jurisdictions. uh it can also be on the operational side and how they look at that and we basically take those real world requirements and business use cases and we try to sort of open source as much of it as possible to sort of show for the to the ecosystem what these requirements are uh and what we also do is like distill these kind of patterns so these are reusable building blocks when it comes to how to get these kind of privacy guarantees on Ethereum uh and you can think of these patterns as like
you can combine them and then create we call it like approaches so end to end uh composition so how do you address a specific business use case if it's for example like uh tokenizing like issuing a bond and then trading around it. How do you even think about that problem and what do you what are the building blocks that are needed for it? And then we deliver things like private specifications and kind of guidance playbooks and and PC's. And we're trying to do is like keep this public uh reference open while at the same time you know having some other context when it comes to these institutions because they come to us and and tell us certain things and and they want to be able to talk to us openly and we try to sort of as much as possible we try to open source it so that other people can can
see where the real demand is from institutions and this leads to sort of the first artifact that we've been working on. So this is the institutional privacy map and what we're trying to do is kind of frame the problem and like understanding where do these like privacy leaks uh occur and then what we do is on the we have the problem space and and sort of explaining what those problems are but then we're routing that to specific solutions. So those like patterns and approaches as well as vendors. So like kind of turnkey solutions or kind of businesses that uh solve these problems in some specific way and that also includes like understanding the maturity of them like how they perform and and so on and as I mentioned the methodology is like very much based on valid use cases from from major institutions and we are
aware of like many use many more use cases but we try to focus on the ones that we heard from multiple institutions sort of to focus the conversation a little bit. uh and they have a very specific set of requirements whether that's technical or legal or uh operational and so on and the ultimate goal is we want to sort of provide this kind of these playbooks and guidance to help these institutions make better decisions when it comes to building on Ethereum specifically with a focus on privacy. Another thing we're doing is trying to surface of areas where more work is needed. So there are definitely certain blind spots that the ecosystem has in terms of how to think about privacy at scale and we want to surface at the ecosystem. So there's an opportunity for everyone here and and the ecosystem at large of address them
uh so that institutions have confidence when it comes to building on Ethereum. It's very much a work in progress both in terms of coverage as well as depth and feedback is definitely welcome. So in terms of how we structure it, we have these like uses use cases. So these are business problems with these specific requirements and then we have these uh patterns. So reusable technical building blocks. These can be like specifications or kind of cryptographic primitives or ways of doing things. And then there's approaches which are sort of recommendations around like end toend solutions and how you combine these technologies together. And then we also have things like details on jurisdictions and these are like for example like regulatory frameworks or compliance guidelines and they differ a lot. So it's very different in US versus EU versus Japan or Hong Kong and we try
to capture that because it's really just like another set of requirements that you have to think about. We also have a documentation when it comes to domains. So we're focused initially a bit more on financial in uh institutions but there's also other domains when it comes to governments and NOS's and enterprises. Uh and these type of domains are things like payments or custody or trading and it basically reflects the actual like internal logic of these massive institutions and how they think about their business verticals. And then finally we have vendors. Uh so that's kind of neutral tooling documentation. So we've been talking to a lot of the the biggest sort of privacy vendors in the space and understanding sort of where they fit into there like what what they kind of capabilities they have what's the maturity how do they perform and so on with the idea sort of
ultimately being useful to these institutions and how you navigate it depends like a lot of what type of decision maker or role you have. So like if you're on the more in business side you might start with sort of business use cases and then look at specific jurisdictions are relevant to you and then finally look at how you might solve them with specific approaches. Whereas if you're more on the technical side, so you're on the research engineering side, you might start looking at sort of bottom up in terms of specific patterns or specifications and then see how how those are combined into approaches and then finally look at vendors and like maybe there's like a gap like no one has figured out how to combine these two two ERC's together in a way that actually solves a real world problem. And finally, if you're on the legal
compliance side, you might start at like the jurisdiction and see, okay, does this actually capture the legal frameworks and constraints I'm operating under and maybe there's something missing or to the extent it's already documented, you want to tie that back to the use case and then look at, for example, how should we think about disclosure mechanisms from a legal point of view. Taking a step back, if you think about sort of the life life cycle of these things, you can uh see like where does leakage happen. And one way you can look at is like pre-trade. So in terms of like intents or expos exposing order flow and how you address that and now this is in terms of the settlement layer. So you don't want to necessarily link uh who is making a transaction to the amount or the type of transaction.
And there's also things like principal risk. So there's a concept called DVP or PVP. So deliver versus payment. And basically the idea is that when you do a delivery of some kind of asset the payment of that asset has to happen at the same time in an atomic fashion. And you might think, well, this is a smart contract, but that's not actually how it works because what you end up with is that you have these different networks. So you might have like a clearing house, a completely different network that's offchain, and you need to have this atomic invariant that the delivery happens at the same time as as the payment. So this is like a strictly higher requirement than you might see in the traditional cryptonative uh world, for example, with bridging and so on.
And it's basically like a business requirement in terms of how to think about risk, but also a legal requirement that you need to make sure delivery versus happens at the same time as payment. even though it's happening on two completely different networks and you also want to do it on a uh in a privacy preserving fashion. When we think about post trade, there's also things like you don't want to leak positions or notes kind of visibility but at the same time you want to have some kind of audit needs. So you do want to provide certain information to certain regulatory uh bodies and so on and that again differs depending on specific jurisdiction. So current status uh use cases as I mentioned we have a handful documented we are of many we are aware of many many more uh but we have sort of some basics
in place approaches similar we have sort of an initial kind of spike in terms of how to approach them u patterns similar we have sort of some things covered but there's definitely more work to be done and vendors we have spent the last few weeks talking to I think 50 or to 100 vendors or so sort of try to capture the sort of hive mind that is the firm ecosystem and and document it in a way so we can sort of what are the capabilities of the fair making system as a whole and this is something we definitely need feedback and contributions uh on as well to make sure we're actually providing an accurate view to institutions think about like patterns to solutions uh so as to mention these patterns are these kind of reusable bidding blocks so it can be things like commitments or how
like a specification for dealing with atomic DVP or how do you deal with scoped viewing keys and so on and approach is how you would combine these different patterns to solve a specific uh business use case uh and I'll just this This is like a short talk so I won't have any time to go deep but I just want to come cover like a few topics at a very high level. So there are private broadcasting, private bonds, both sort of issues and trading and then payments and then trade settlement. So when it comes to private transaction broadcast uh private transaction broadcasting the goal is that you're trying to reduce pre-trade leakage. So these are dealing with things like uh front running or me or leaking strategies. uh and the way you might approach that is for example with encrypted to private lanes or some kind
of OTC submission and you might also have uh sort of some private rollup execution here and why it matters is because institutions often want sort of better execution quality execution quality while at the same time uh preserving composibility when it comes to private bonds sort of the both the issue side and the trading side and the problem is that you want to have some kind of confidential bond deals with a short settlement uh and this composes things like shield transfers as well as the atomic DVP I mentioned for and selective disclosure and and here you might for example mint on L1 but then you would do trading privately on L2 and these type of construct and outcome is ultimately you have some kind of complied confidentiality but still deterministic finality in terms of these bonds being settled because it has big implications when it comes to liquidity
private payments. So what you want is kind of stakeholder only visibility and stakeholders here are not just sort of Alice sending something to Bob. It also includes for example custody providers or regulators and regulators and auditors also need some kind of access when it's required and you can deal with this for example when it comes to sealed balances with with sealed balances and transfer transfers and some scoped viewing and optionally also like things like PVP or DVP when you're doing crossber transfers. So payment versus payment when you're actually transferring money across currencies and across borders and why it matters is because you want to have kind of operational privacy without having some kind of blackbox accounting. So you need some way of accounting for these things in including for external stakeholders.
Uh also a thing I want to mention on the private payments is that it might sound simple what you just send from one to another but if you look at these payment sort of this payment infrastructure and networks how they actually work under the hood they're extremely extremely complex and there's many networks and there's different custodians and different rules and and and ways of dealing with this. So it's definitely not trivial and there's like you can read books about how this infrastructure works. Uh, I also want to point out that it's very different what type of use case we're talking about here because it's one thing if you have a sort of limited set of institutions sending like $10 million to each other and it's like a known thing versus if you for example do a retail stable coin for 100 million users. Those are sort of very different
use cases that both touches on payments but they also have very implications in terms of the design and specific requirements and and how you would think about designing that. When it comes to private trade uh trade selement, the goal is you want to sort of minimize the linkage here again and reduce operations friction and it might touch on things like bonds or realwood assets tokenization derivatives and so on. Uh and there's lots of ways you can deal with this. For example, you can batch proof the commitments. Uh you have some kind of neutral settlement venue like L1. Uh and you want to have some kind of auditable logs for after the fact. And it matters because you want to have this kind of predictable cycles and clear reconciliation. And this again is very important for large institutions in terms of how to think about sellment and
reducing those times and still having certainty that you're not going to sort of lose your money somehow. And one way to think about this mapping effort is kind of like a decision path. So you might start by identifying the use case like what is actually business problems you're trying to solve and then you would apply jurisdictional constraints sort of what are the regulation regulation that that I am under and that sort of constraining me and then you would select specific patterns or approaches and sort of like what specific building blocks you're using and then you might evaluate vendors like what tools exist what's the maturity what's the performance of them uh and then you would sort of do these pilots right and learn from them and then you can sort of iterate on that and most of these paths uh are in incomplete and that's where you
love it if people in the ecosystem want help with out with it and this is something that a lot of people have already done. So where we headed uh we are sort of increasing the coverage across multiple domains uh because there's a lot of things going on here in the traditional finance market but also across other like identity systems in with governments and so on and we're trying to sort of go deeper on patterns and and approaches run books. So basically having more confidence that the things we recommend are actually things that ultimately solve institutions problems and what we're trying to do is create these kind of shared playbooks and best practices for Ethereum privacy when it comes to institutions.
So just to summarize, users want privacy on Ethereum. In fact, it's like the main blocker right now. And we're building this open shared privacy map of the space. And finally, you can contribute. So PRs and issues are open. And uh yeah, feel free to come talk to us. Uh we have a GitHub repo. You can scan the QR code that leads to the market map. Also have a very barebones uh website and Twitter account. And you can contribute things like patterns or approaches or vendor notes. And yeah, come talk to us. uh bring real constraints and feedback and uh that's it for me. Uh thank you. Any questions?
>> Thank you Oscar. I'm coming from behind and I'll ask you the questions. They've been put into the by the audience on the QR code. >> So the first one is what is the geographical distribution of institutions that you may talk to at the IPF and are there any institutions in LATAM? >> That's a good question. Uh I would say a lot of them are is it's a mix of like APAC uh Europe and US right now roughly equal. H we have had some initial contacts uh with with LATAM but not super deep yet. So that's something that we would like to go deeper into as well. Yes.
>> Okay cool. Then we have two more questions. The first one is is the market map that you've made useful for institutions that want to operate on the L1 or also for those that want to operate on L2s? >> That's a good question. Uh it's it's useful for both. So we've had uh workshops with institutions where they're trying to solve some specific business use case and they ask us a bunch of questions including how to think about L1 L2 and this this touches on things like you know what are the additional affordance I get with a privacy uh L2 uh how should I think about data availability and risk around that how should we think about L2 governance and so on so it's very much an open design space and I think different decision different institutes will make different choices uh depending on of what the action requirements are
and what we are trying to do is just explain those trade-offs and those properties in a way that they can make informed decisions. >> Yeah, that makes also sense. And then the final question that we have here is are the different privacy vendors composable with each other? >> Uh that's also a good question. So I think that's also why we put a lot of emphasis on patterns and specifications because as you know in the system we have EIP and ERC's and you have similar efforts in sort of the CK space as well. So ideally yes but unfortunately not all of them are composable. uh there are certain tricks you can do but but I that you can do but I think in general that's definitely a hard problem. Uh I in general I would say that what we want are sort of common standards so you can
have interrobability but in practice is also quite difficult I would say. >> That makes a lot of sense. Well thank you very much. Let's thank Oscar one more time. Thank you.