Privacy Onchain: Confidential Transactions, Zero-Knowledge Proofs and Financial Privacy | EBC12

Thank you very much for this applause and introduction. We have a very interesting panel discussion today, so I think we'll just introduce the participants and ask a few questions. I guess we'll start with the oversight bodies, since we have government representatives here, and my first question will be to Marin. As a supervisory body, you oversee many different projects. Some of them are startups, some are startups, some are institutional players.

I would like to know what is coming to your table now that MiCA is finalized, and what differences you see between these two types of projects. And especially with the focus on privacy: are there any privacy concerns when you oversee these projects? Yes, thank you for the question. I would say this is a fantastic time for a watchdog to be working because you see all these different models emerging, and I would definitely divide the newcomers into two categories. The first one is new startups that have just arrived, they are not very familiar with the regulatory framework, and you need to dive deep to understand what exactly they are going to do, what services they will provide, how they will work with data, and how the issue of data security is actually addressed in the company, including internal control systems.

And there is another category—mature companies that are already operating in the market. Previously, they were not regulated by MiCA, but were mostly focused on regulation at the national level. Among the 10 crypto companies we licensed this year in this short period of time, only one pays very serious attention to data, I mean the use of technologies like " technologies like " zero-knowledge proof." However, I must say that for us, as a supervisory authority, the most important issue is how the internal control system works. That is, how you work with data, how you manage your internal data.

Not from a GDPR perspective, but from a data security and information security perspective. From the point of view of compliance and control systems. And, of course, how IT systems actually work. So we're not just separating data security issues, but looking at data integrity—how it ensures the integrity of information within an organization. This is a key question and a key, I would say, area that we focus on in terms of data.

Thank you very much. Now let's move on to Estonia, which was so well presented before our panel began. So, as someone who works at the central bank of Estonia, I will say that there are several projects that the central bank is currently overseeing as well, mainly API and Pontes. So, bring us up to speed. What are these projects about?

Yes, thank you. And it's very nice to be here in Barcelona. Today I'm really presenting the infrastructure layer, that is, how we improve our target services. Yesterday, the participants in the discussion also talked about how to pay for transactions, based on the monetary component. Indeed, we are currently working on two projects at the Eurosystem.

One is called Pontes, the other is API. To briefly describe them, regarding the first, we clearly see the market need for settlements with central bank money on DLT platforms. This interest has actually existed in the market since I worked at the European Central Bank in 2019. All interested parties were already asking about it then. And in fact, right now, this quarter, this pilot project, the Pontes pilot, will become a reality.

It will connect DLT platforms and allow for settlements in central bank money in targeted services. This is the first part. In the 27th, we will develop the service even further, and in the 28th, we will offer it as a regular target service for all market participants, ensuring 24/7 operation and finality of settlements in tokenized central bank money. And this applies not only to settlements under "delivery versus payment" operations, but also to currency transactions. So, if you have DLT platforms that enable and improve cross-border payments, then that can also be used for that, and it will indeed emerge and be available quite soon.

Another thing, the Upja project, is a more perspective view perspective view , where we want to develop a specific plan for the development of services together with market participants. It is currently completely open what this will look like, most likely I expect that we will have multiple DLT platforms, and in Upja we will provide interoperability between them, including cash settlements on DLT platforms. Therefore, I call on all stakeholders in the room and participants in this conference to be active in the dialogue with the Eurosystem. Because we don't do it ourselves. We're doing this together, and we'll see what we get there.

But let's put it this way, in the market and why we're doing this—it's quite clear that we're seeing the emergence of different DLT platforms now. Yesterday there was also a conversation about what do we need? We need interoperability, we need standardization. But right now I see, let's say , too much fragmentation. It's like separate islands that arise and don't interact with each other.

In the past, we used T2S for securities to connect the settlement layer. And now, with DLT, we are essentially doing the same thing, but in a new technological environment. I'll dwell on this a little longer. There is a delicate question that we usually ask here, and there is a certain premise that I want to clarify. So are there any privacy protection requirements in DLT ?

And do these requirements push regulators to choose permitted registries over unpermitted ones? Hmm, this is definitely an issue worth considering when designing. There are no solutions yet, but in discussions with market participants we will work this out and then decide how to design everything. But regarding permissionless systems, we permissionless systems, we also discussed here yesterday that we actually need effective management and control. Someone must be responsible for the smooth operation of the network.

This is one side of the story. If problems arise, we need to have someone—supervisory authorities or financial market infrastructure supervisors—to turn to to get the situation under control. Regarding privacy, I would say that there are different levels, and for certain calculations, it is not necessary to see the entire transaction history because confidentiality is required for business reasons. You can't put all your business all your business decisions and secrets on display for the whole world. So technological solutions certainly allow for privacy or confidentiality, I would say, and that needs further study and development.

But at the settlement level, I don't see the need to have a holistic view of all transactions. And in fact, we are doing similar things now with the retail digital euro. This is a kind of system innovation. There now, let's say , the payment information of a single transaction passes through the system. We do n't look at her.

But now, due to privacy concerns, we design it so that we physically cannot look at it cannot look at it . So, this is certainly confidentiality, privacy—this is of great interest to society as a whole, and we need to, let's say, develop the system so that people have trust in us and in the system itself. Because there is no, let's say, desire on the part of central banks, system operators, to investigate this data, and this should also not be on platforms where others see the business see the business operations of other companies. So, that gives me food for thought, does n't it? Knowing that there are mechanisms that offer options for selective disclosure disclosure .

I want to now move on to the industry and find out to the industry and find out what you think about it. Shirley, you have been working in this industry for some time now, and I understand you were also part of the Partisia blockchain. Tell us about the solutions that exist on the market. It's not just ZK- on the market. It's not just ZK- proofs, we offer much more.

Yes, I have been in the blockchain Yes, I have been in the blockchain space for over 8 years, and for the last 3-4 years I have been focusing on privacy-enhancing technologies combined with blockchain. Before joining Tor Wester, I worked at Partisia, a pioneer in multiparty computing, ZK, and fully homomorphic encryption. They've been doing this since the been doing this since the 80s. So, these are just some of the cryptographic privacy technologies that allow us to make transactions online, be it our data or financial transactions, without revealing all the information to other parties. There are certain use cases with ZK.

You can check something without showing the underlying data. And with multi-party computing, you can collaborate on sensitive data. So there are many options for use. And it helps comply with GDPR and other data regulation rules around the world. Yes, since the early 2000s, we have created many solutions, mainly for governments, NGOs, and financial institutions.

For example, Japanese company Digital Platformer, for whom we created a solution that combines AI, blockchain, and multi-party computing to help detect financial fraud and illegal activity between financial institutions across borders, as they are currently limited to analyzing only their own internal data. So, thanks to the combination of data exchange across borders and between financial institutions without revealing it, but simply through calculations and analysis, it is now much easier, faster and cheaper to detect financial fraud. We also had use cases for the Red Cross that we developed for crisis zone management and payment management. Payment was usually made in cash and vouchers, but because beneficiaries are in a vulnerable position vulnerable position , they become targets for criminals and potential attackers. We created a stablecoin- based payment solution to give the Red Cross full traceability and assurance that funds and donations are in the right hands.

And you can also implement an entire access control system where you can use these donations, vouchers, or aid that you send in stablecoins. So, thanks to privacy-enhancing technologies, we can conduct on-chain transactions and data transfers without revealing any confidential information to counterparties. We can empower citizens by giving them control over their own personal data personal data . After all, what Web 2 gave us was the emergence of huge monopolies huge monopolies . YouTube, social media, Google, etc.

They started monetizing our data. While we have become a commodity. So Web 3 took control back, empowering the end user and the individual. And, as I mentioned, privacy protection technologies have been in development since the in development since the 1980s. And only now are we seeing their implementation in real scenarios.

It's not happening as quickly as I would like, but we are moving towards better solutions. But if you wonder why businesses have been so slow to adopt blockchain solutions, particularly public ones, it has always been because of a lack of privacy. And now we have the necessary encryption methods. A quick question on this: you mentioned that the technology has been around since the the technology has been around since the 80s, and now the adoption has accelerated a bit. I want to understand what could be the obstacle.

Why are n't privacy issues being implemented so quickly? Is there no market demand or is it No, it was a matter of computational limitations and " limitations and " bottlenecks". As computing power and performance increase and hardware gets better. We see the potential for implementing this in real-world scenarios, and it becomes better, faster, and cheaper, because previously generating zero- disclosure (ZK) evidence was very expensive. It's still quite expensive to scale.

Just like with MPC. So it all depends on the hardware and GPUs GPUs . Thank you very much. Going back a bit to the questions about permissioned and permissionless blockchains, I want to understand your point of view. We often hear that many institutions prefer to choose, for example, Canton-type blockchains, and I want Jean to tell us more about the differences between these types of blockchains and why they are implemented there.

Of course, thank you. Good morning. Maybe let's talk about what's happening in Ethereum first, and then discuss the other option you mentioned. Privacy is a broad concept. Today we use the term " the term " privacy", but no one knows exactly what it is.

So I think that at least in Ethereum we now need to distinguish between what we call access control and, as you rightly point out, confidential computation. And I think that today, if you want to build an application on Ethereum, you can use access control: that means that bank A sees some data, bank B sees some data, and the regulator can see some more data. This answers the question of who can see the data. But is this really what we want? No.

We want to know how the system can confirm information without knowing the information itself. I'll give an example, because in finance it's easier to explain with examples. For example, collateral management. The bank needs to know whether the other bank has collateral to carry out the transaction. The easiest way for that bank is for that bank is to say, "Okay, look at my collateral."

"I have bonds, a lot of other things." Does the bank want to do this in a working order? Not quite. So, that's exactly what we're trying to achieve with confidential computing: to prove that I have enough collateral without revealing the collateral itself. So, access control on one side, and confidential computing on the other.

Ethereum is not yet ready for confidential computing. There are three categories, and I don't want to go into technical details because it's still early in the morning , but there is ZK-proof, first of all, it's zero- disclosure proof. What is this ? ZK-proof is a way to say, "Okay, I can be a participant in a transaction without revealing my identity." This is great.

This is a very powerful tool. The trade-off is that there are many parties involved in finance, and it is a constant exchange between banks; A transaction usually consists of many stages. So you can't do it with ZK-proof because it would be too expensive and the latency would be very high. So, some people have created so- called private pools for even greater anonymization, but that's not enough. So I think even Ethereum today recognizes that ZK proofs are not yet sufficient for confidential computations.

The second name sounds a bit barbaric. This is called FHE, fully homomorphic computation. And here, to simplify—I'm sure there's someone in the room who's more technically savvy than me— savvy than me— but the system could, for example, add two encrypted numbers, number A and number B, both encrypted, so the system doesn't know what it is, and it outputs the sum without revealing what it is . So, that's great too. This is very powerful.

You said, " powerful. You said, " Okay, we found it." But the problem is that finances are again very difficult. And it's not very scalable. And at this time it is very, very expensive.

So, with many participants, like in finance, it would be a bit too expensive a bit too expensive . That's why there are many startups, like Zama in France or Phoenix in Israel, they are doing very well and have created so-called coprocessors. They take all the calculations outside the chain and then return the answer return the answer . But again, there are a lot of tradeoffs, because what to do with key management? Who?

What kind of management is there? Who is responsible for the calculations? And the third option is multilateral calculations. So, essentially, here you break the information into many pieces, no one has all the information, and they agree on a certain state. Sounds great, but again , from a latency perspective, it's also expensive.

And from a management perspective too, because how do you choose who the parties that confirm the status will be? So, in essence, there is no ideal solution today. Again, with Ethereum access control—that's great, but obviously the infrastructure layer can see the data just as well as the application layer. Ethereum has made great progress in programmability and scalability, and privacy is the next step. We're not there yet.

We can't have a panel on privacy without mentioning the privacy issues that have occurred in recent days. There was a KYC data leak. I'm sure almost everyone has heard of it from Revolut. And it's not exactly a privacy issue online, but the leak still means that many Revolut users have been affected. Now the data is revealed.

So, my question to all the panelists is: How do you see the future of data protection? Will privacy really move to blockchain, and will regulators find these measures sufficient? Are there perhaps other ways to protect KYC ways to protect KYC data to protect individuals from disclosure and theft of their personal data? I can start if you want. I haven't studied Revolut specifically, but we're talking about Ethereum.

There are other technologies, and it seems that Revolut is offering another one of them. But I think we can't talk about privacy in general. We need to delve into the details. You just mentioned Canton and said, "Okay, Canton has privacy." Okay, but I don't think we can deny that, but what kind of privacy is that?

If you look at Canton, for example, there is privacy there, but through selective data disclosure. That is, I talked about access control earlier, but the information only goes to the parties involved in the transaction. This is very good progress. This is even better than the access control that exists now. But this is only a selective disclosure.

This answers the question of who can obtain the data, but it does not answer the question we mentioned earlier: how can the system provide an answer without revealing the information itself. Let me give you an example. Imagine an auction with an auction operator and three banks. Three banks will place their bids at the auction. None of them will see in the system what exactly the other bank provided, but the operator will see it.

What we are trying to do in Ethereum with FHE in Ethereum with FHE , MPC, and private pools is completely different. We want the system to be able to determine the winner even when the operator doesn't know exactly what was offered. Of course, for an auction, this is a bit extreme, but, for example, in collateral management, you don't want BNY, controlling a large infrastructure of bonds, to see who has collateral and who doesn't. Of course? So, selective disclosure, and I think that's probably what Revolut is trying to do, but it's very different from confidential computing.

From a regulatory perspective, I would say that when we talk about privacy, we mostly focus on whether it's a technological issue technological issue or a legal one? Because from a technology perspective, regulation is technology neutral, so it doesn't matter what technologies you use. The key thing in this equation is how exactly you adhere to the regulation itself. If we are talking about data and privacy, let's take AML regulation for example. There can be no privacy for the regulator here.

We will see everything because it is important for us to understand exactly how transaction traceability is ensured. So even companies that use ZK use ZK technologies will still give us access to transactions. We will gain access to the chain. We will receive chain. We will receive , understand and be able to analyze all the data, as it is important how these KYC or AML solutions are integrated into the company.

Of course, companies can use open source solutions from libraries for this or outsource these services. And here we come again, from a supervisory perspective, to another risk associated with DORA regulation and how those risks are actually managed. Because if this type of service is critical to your business model, it means you need to invest more in people, in additional security, and in data integrity. And of course, we invested a lot in people in the two years leading up to MiCA and realized that there are a lot of connections between AML and fraud issues. And we move on to fraud.

So, here we are back to privacy again. Only a very limited number of companies or institutions can gain access. What about the company itself, how do they organize internal investigations? This is very important, especially if it later comes to enforcement or legal action. It is important to understand how the company works with internal data within the AML framework, from the perspective of DORA, RegTech, and the principles of data confidentiality, integrity, and availability.

I will add from the side of the central bank: it is important to note that banking secrecy must be protected to the maximum extent possible. This is the responsibility of the banks, and the supervisory authorities check whether all necessary measures have been taken. And when we now talk about all the DLT talk about all the DLT platforms, which in some cases also provide services to banks, the key question is how much data is there and whether it is sufficiently protected. Because if a bank uses such a platform and it gets hacked and data gets leaked, then in reality it is also the bank's responsibility. And it is obvious that banks do not want to use such solutions that are not sufficiently secure not sufficiently secure , because otherwise they will be checked by supervisory authorities and, most likely, sanctions await them.

So sanctions await them. So , this clearly demarcates these two things, and indeed these two things, and indeed , technology gives us different options. I already said that at the infrastructure level, we don't really need to transmit all the information. There are other options, but certainly the payer side, payer PSP and payee PSP need to receive data related to the transaction, and certainly the payee bank does not need to receive data on all transactions. So this is kind of a maybe misconception that comes from the fact that in DLT platforms and blockchain, everything is on one chain, is traceable, etc.

But now, I think the industry is mature enough to understand how to actually implement existing infrastructure on new technology, and also meet the criteria that regulators are putting forward for banks, as well as financial market infrastructure supervisors, to protect the integrity and security of the system. So, when the GDPR guidelines for blockchains were implemented in the spring of 2025, we—there's a YouTube video from the Crypto Valley conference— Crypto Valley conference— proposed our architecture that would be GDPR and data protection compliant, combining a private network and a public network, i.e. permissioned and permissionless, along with privacy-enhancing technologies. Because we did it; we borrowed a niche from Web2, as it's resolved in the Web2 world with intranets and the Internet, where the Internet is a permissionless network, intranets are private networks, and in between there are all these access control tools, firewalls, and security protection mechanisms.

So what content does is very similar to this ideal solution, but still, when you're dealing with centralized databases with permissions, there's always the possibility of data leaks and hacks, so fully distributed systems are of course better. But yes, under GDPR, it's very difficult to achieve anything close to ideal in terms of security because there's this right to delete data. And this is impossible for a public, permissionless blockchain. So that's why we need this hybrid model: public—for traceability, audit, and access. And private—to keep data under control and, if necessary, delete it.

Surprisingly. Thank you. We have two more minutes. So I'll just ask the audience if there are any questions. We have one.

Can you repeat the question on stage? Did you hear that on stage? Did you hear that ? Do you mean we are compromised? I would say we are compromised because of data protection rights .

Because of the criteria and requirements that require the use of centralized solutions. And therefore, no personal data can be in the chain. Yes. I mean, they can be stored in distributed storage along with privacy-enhancing technologies. But most public permissionless blockchains do not have a jurisdictional management system.

That's why at Parity we tracked which jurisdiction all node operators were located in, as GDPR requires data to be processed within geographic boundaries. So I don't know of any other blockchain where this is implemented. Speaking of public permissionless blockchains. So, yes, there are certain architectural criteria that need to be met, and yes. Thank you very much.

If you have any more questions, I'm sure you'll be able to find the discussion participants after it's over. Thank you very much for answering all the questions, enjoy. Thank you.