CTRL/SHIFT - 14 06 2026 PARTHENOPE STAGE - EUGENIO REGGIANINI - IMPLEMENTING PRIVACY POOLS

So hello guys, thank you for being here on Sunday. It's very appreciated. The time also lunch is not uh the best, but I will try to keep it short and uh maybe fun for you guys. So a little bit of background about myself. I I have a legal background.

Uh I work across business and product and essentially I help uh protocols, institution, enterprises to build services on top of blockchain. uh and in a lot of my um background is about research and try to bring down to hurt use cases that of course face uh a lot of scrutiny about uh feasibility and regulation compliance and so on. So this is why uh a few months ago uh with Expo we decided to uh create this research to try to envision a way to provide institutional uh services within the Europe within the European regulatory context and you can see this as a possibility for running uh an ESP in within the European Union. So um I will let me see how this works. Okay.

So starting like in medias uh yes uh regulated institutions have to comply with a whole list of services uh hand requirements in order to carry out essentially the service that they do in the web to space. No. And one of the most intense uh requirement they need to satisfy is what's so called the customer due diligence or enhanced customer due diligence which force them to essentially in the traditional space to collect information about the customers and about and about the funds. Of course these have huge implication if uh the data on the customers is hosted within the web three technologies or with web three features. And so uh what I've been trying to do is to try to create a research which following a list of design that I will go through it and a system architecture try to address and to find a balance to satisfy those requirements.

So the design principles which I've been following uh of course uh creating onchain data minimization by design. So design a system that stores the minimal data on chain um addressing financial compliance uh how a whole set of regulation that comes and of course apply within the European Union and frame this within the European governance because of course uh blockchain is not just about uh uh let's say software services but it's also about infra and who operate the infra and around which rules right and so Here uh you see um a sketch of a an integrated architecture which has an offchains component which essentially collect data from identity and uh funds from the customers. You have a first permissionbased network which is uh EU trusted uh following Hyperledger Bizo Ethereum client and then it docks into uh Ethereum mainet following what is described as the expo privacy pool implementation V1 but you will see that there are at least some design principles that could be applied to the V2 as well. Um no. So what's the ecosystem under which the institution are working?

Um how set of regulation that you see here? Uh regulation which force uh the crypto asset service provider to share information even uh within a self-hosted wallet above threshold information that requires regulated entities to check information about funds and uh identity. um and regulation that requires essentially some trust in terms of authentication of the users and uh some requirement in terms of data uh controllership and processing throughout the services. Um all of this is framed into a governance uh model which see European agencies like ESMA or AMLA to check over financial uh regulatory requirements. uh uh market service provider like banks and uh infra providers like traditional cloud operators or blockchain cloud operators and association set providers which may be actually regulated entities that run these for to uh exploit um in in a nice way business services out of it.

Um and here of course Ethereum protocol can provide a connection to provide data portability across regions because of course legal requirement are enforced in the regions that uh they are valid to. Um so uh the design lives under two main product services. One is an identity layer. We are lucky because in Europe we have a lot of history lucky and unlucky uh because we have a lot of history on identity services and the European Commission uh few years ago started a project called European blockchain service infrastructure which at the end resulted to be an identity services uh that align that is aligned with uh European trust regulation and essentially use uh a traditional self-s sovereign identity uh model with some permission logic on top and uh below that I will tell you uh in order to provide let's say a trust chain of value of a user authenticated data uh this um is doable um let's say complying with two let's say permission design uh output one on top because uh of course the verifiable credential which is the digital certificates that essentially establish a proof of ownership over the ident the user identity um is let's say gated through a trust chain so there is a trusted issuer um I hope you are familiar with the whole concept of identity uh I will keep it uh short because otherwise we don't stay in the time um that essentially establish u in an objective way uh a proof of ownership over the data that has been authenticated On the other side, Ebsy following Hyperledger Bizo which has a proof of authority consensus mechanism establish a way to uh establish authorities over the control of the data which is stored on the nodes. Uh and we will see using zero knowledge proof uh we are able to prove the identity of the clients essentially storing minimal data on chain.

Um the other part is of course the privacy which uh the privacy layer which is of course a result and twist in a way that isn't matching ensuring compliance requirements. Uh I will keep short here because Mike already talked about it in his previous uh in his previous talk. So the evolution between mixers and ASPs with privacy pools is something that was also uh I think u an evolution towards a compliance uh oriented uh feature that of course facilitated the institution to play with more web3 tooling in trying to match the same level of compliance that uh the institution needs to have uh when already carrying out services in the web through Um, so the as the ASP is essentially the concept that was associated that is associated with the privacy pool is an offchain uh let's say policy risk engine that that enable an optin uh compliance tooling that was not possible uh with simply mixers and this uh we will see fit particularly well uh within an environment which required trust in order to carry out regulated services. Uh so how the system works uh you would you see here two data environment one which is connecting on chain and one which is offchain and you can envision an application that commu that allow in an integrated way these two uh product features working together the identity part and the the privacy pool part. And so you have a trusted issuer which is a bank which has an authority to issue a verifiable credential to the client.

The client is using uh is verifiable credential which is stored in the user wallet. So at the at the application level to generate zero knowledge proof to proof um the um identity uh and is membership uh within the bank client. And uh this information is specifically hosted in uh the EPC node. Upon the proving we relay the deposit on the privacy pool contract which of course is authorized based on the off the offchain that is happening of the policies which are correlated to the services of the bank. For instance, I want to access a lending service.

Okay. So I need to prove that um me as a client and me as my funds and my client account I am complying with the policies that are associated from the bank side in order for uh the bank to carry out the lending the service itself. So the ASP does the check and essentially combining the proof uh coming from the ASP and the one related to the EPS node. I myself as an institution able I'm able to carry out the lending serving the lending service successfully. Um so what are we proving here?

Here essentially we are aggregating two zero knowledge proof one coming from the user identity and one coming from the user fonts and with these we prove three uh let's say unique characterist the three three characteristics one is existence so I made an action I am essentially a European citizen I made a deposit uh over these funds a membership I am an Italian citizen or I am a member of a bank and uniqueness uh it's me authenticating the uniquely for these requiring services and it's me uh requesting uniquely these lending services at this time um how is the user journey uh in general this is of course it is target to the v1 so it's like uh it requires you to get the credential to relay the deposit do the checks and then allowing the withdrawal for the specific business service that uh the bank is uh carrying you out. But uh potentially um this if we go back to the to the design uh and this this is my personal opinion also the V2 could uh apply quite uh smoothly because the V2 use a multisig approach with a smart contract account that can have a validator that can check uh the identity data on the EC node signature and the results over the privacy pool and then executing once the l the lending services which can even call multiple smart contract if for instance I'm needed. So this is to say that this research was written having the V1 in mind but also the V2 I think high level applies um what kind of business services uh because I've been using lending but lending is a general term you know you can do different kind of lendings and different kind of policies so at least three uh big areas came to my mind the first is kind of instit in institutional institution initutional so infra institutional I would say you can have banks that essentially share um do exchange commercial papers let's say and share uh trade notional leg uh without disclosing the full trade uh of their position. You can have private payrolls of essentially having companies using organizational identifiers to pay in a uh more private but still compliant way their employees. And you can of course enforce uh merchant payments uh working with merchants and uh payment service provider that uh um acquires um uh the user credential and based on this uh retrieve uh the payment uh to from the payment service provider through the merchant um from operational perspective.

So I I use this slide usually to ask why don't to build these apps specifically on Ethereum only. Um because institution needs an anchor where offload the trust that they need. um institution uh have huge data sets of chain and they need a data point that essentially uh anchor all the requirements uh we call it in a in a web3 space all the policies uh that they have on chain in a permission environment then the I think it's safe to say that of course upon this you can connect to permissionless environment and um benefit of the fullfledged composibility that blockchain and ethereum can offer you uh by requiring multiple services doing batch of transaction and blah blah blah. So this is an operational framework that I have identified. So you have uh an offchain governance environment.

We have this uh digital consortium called Europium Edict which is hosted by different member states that essentially is maintaining uh or doing some effort in maintaining the epsy protocol. But also there are national um national epsi protocol network like like for instance in Spain that collects more than 400 members across administration, universities and so on. Um we have the VC trust identity framework which is based on open source standards and then of course we have the network infrastructure which is EPC the Hyperledger BU permission environment and the connection with privacy pools and other solutions on Ethereum mainet in a permissionless way and why these solution matter for institution and privacy pools because it increased the the level of compliance and regul regatory certainty. uh it established two clear data sets environment uh uh over which PII is either stored or minimized and of course at least uh comply with a list of principles that are framed in uh the GDR GDPR regulation uh especially when it come to uh onchain data minimization or uh clear rule of uh data control uh um data establishment and um yeah so we are going to in terms of uh operational perspective this is a little bit uh different dimension of what I've been telling you before so offchain governance uh opensource permission environment uh where you have different uh identity network hosted on different uh nodes in different European uh union member states and the permissionless environment. Um, a little bit of review before ending.

These are the main benefits which I see uh coming up from this design. Uh, the GDPR compliance, I already talked to you about it a little bit. Uh, the no having no row data on chain, the ensuring the right to erasure by removing the credential. So breaking the links with the credential metadata between uh with the onchain commitment and a clear data controllership setting with the ASP and the FC node. Uh a clear data environment differentiation between the offchain and the onchain sorry a balance and compromise between trusted and trustless environment.

So a trusted setup for institutional data manage with in the in a trustless environment and of course the fact of having anchain governance environment uh helps institutions to set clear rules for uh IT maintenance and probably combine them with what is provided in terms of stewardship uh from permissionless protocols. So I thank you and that's it.