Episode 377 - Evolving ZK Identity from Iden3 to Privado & Billions

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week I chat with David and Alexander from Pado ID and Billions network. We dive back into the topic of ZK for ID with this episode. These projects and the team behind them stem from an earlier privacy project called Iden 3, one of the first ever to propose

the use of ZK for identity onchain. Iden 3 is also the team behind the circom DSL, a deeply influential and very much used language and tool set. We discuss how the project evolved through their time working within the Polygon team all the way to their current focus on Billions network. We discuss how their approach compares to some of the other ID projects we have covered this year and where they see the future of ZK and ID systems heading. Now before we start, I want to just let you know that we've just recently kicked off season 3 of the ZK whiteboard sessions. The ZK whiteboard sessions are produced by ZK Hack in collaboration with Bane Capital Crypto. Every two weeks we have our hosts Nico and GMO going deep into the key concepts in ZK. And you can watch

them over on the Xeron podcast YouTube channel. I've added a link in the show notes. Please do check them out. These are a great resource to learn about the fundamentals and techniques powering the ZK systems we often discuss on the show. Now, here is my interview with David and Alexander. Today I'm here with David and Alexander. Alexander is also known as Sasha from Pado ID and the Billions Network. Welcome to the show both of you. >> Hello. Thank you. Thanks Anna. >> So today we're going to be diving back into the topic of ID in the ZK world. So using ZKPs to create IDs, usually on chain. Um, we have an almost unofficial

series going on this year where every month I've had one ID team join us and so far we've had teams like RARO self the ZK ID team from PSSE we've also talked to teams like reclaim in the past we've talked to Pluto that are doing ZKTLS we've talked with Kustas from SUI who's done ZK login yeah the ZK email team all of those kind of projects touch on this idea of ID and so I'm very excited to jump into Pado and Billions network with both of you. In a way, it's one of the newer ID projects with billions, but actually it's one of the

oldest. As I understand it, this project and this group, you pioneered this back with Iden 3, which I think came out what 2020? >> 2018. >> So, oh wow, even earlier. Amazing. >> Billions for me is actually a new thing. So, I'm very excited to jump in. Let's start off by defining these two orgs. What's Pvado ID? What's billions network and is it the same team? >> Yeah, absolutely. Billions and privado is the same team. >> Okay.

>> Basically, Pado ID was the brand we created after spinning off from Polygon. >> Uh and I will come back later to the to the let's say phases of the project >> was basically the same project as 3 evolving down the down the line. But we wanted to create something that was able to create this kind of volume of users in a way some synergies some capacity to create the scale because pado is a technology stack. We we've been like a developer toolkit for years and that at some point so many teams were using part of our stack to build components things.

Some teams also contributed and we really appreciate that. But overall we wanted to see our project getting traction and getting used in the way we want this to be used. Plus we saw the opportunity to create a network of humans and AI agents because we have the technology to also include identity for agents in a way we think is the correct one. So there's other teams building the network of humans and we thought we had a good proposition and good technical stack to do this in a more usable friendly and scalable way. So is this what billions is then?

>> Yes. Billions is if you want to say in short it's a different approach similar to all coin humanity protocol if you think about it >> but with our technology stack. >> I see >> with the approach of mobile mobile first and progressive uh verification but in a way that's able to compose and you know use our technical st to do so many things and we'll discuss about this. Is Pado though still a product as well like or is it just a tool stack? >> Pado is a product. We developed a platform to do to connect issuers of trust, consumers of trust and users to connect them across multiple different chains and to have some payment rails and all of these respects users privacy

and we are able to deploy a lot of use use cases there several applications. Pado is the name because we are obsessed about privacy as you probably know since the beginning and that's has been our moto and the our way to do things all this time but overall this was not getting traction because development of business in B2B is complicated and the cold start problem is there when you basically >> want to have verification if there's issuers and the issuers were there we had like 50 plus issuers of trust >> uh including most of the well-known verifiers and KYC partners But then see if there's no volume if there's no mass of users critical mass that's difficult to to launch then billions came to solve

this this situation. >> Cool. Okay. So if I understand correctly PVA ID is I mean it's the original kind of spinout project but it's focused more on the B2B side of things and getting sort of the credential creators maybe to start using it. billions is meant to be more of like a is it like a registry of people who've validated their ID on chain or something like that or they're like unique users like yeah is it a blockchain I actually don't know what the even the container of this would be >> so in a way yeah it's a registry in scope of billions we have multiple issuers that we built ourselves that are issuing credentials for the users based

on their data their documents and that's one part that is kind of registry part but also we have a blockchain where user identities are created and managed and also we are working on different other blockchains and so on to to be able to to verify this data that user has collected in a form of verifiable credentials. So yeah, it's overall many things and a few of them are actually issuance of credentials by us in SDK way. Yeah, >> cool. I think it would be good to get to know both of you as well before we dive deeper into these two worlds. David, you've been on the show in the past. You

came on quite a while ago to talk about ZK EVMS. This is, I think, one of the first episodes when we were like introducing the concept back in 2021. You're on the show with uh Jordy. >> Yeah. >> So, in that show, we would have done a bit of backstory on you up to that point, but maybe it would make sense to share with us like what have you been working on since then? I mean, you just mentioned Polygon. We just recently had Maiden on the show as well, but yeah, tell us a little bit about what you've been up to since 2021. Well, we were working very hard on polygon security until we get the mainet done. This was in 2023. So that was basically the f the focus for us >> within polygon.

>> Within polygon. Yeah. Yeah. >> Yeah. >> Focus that basically took most of our bandwidth. Sasha will explain later what they were doing at the same time >> because uh the funny story is that the identity project continued on these years. uh after we delivered the the CKBM, I took the role of CTO at Polygon and this was a very interesting period of time because we wanted to transition the the services of Polygon to CK and it was >> pretty challenging but still transformation is there. Uh the next thing that Polygon launches is the layers as you probably know and interconnection of CK networks with this characteristics of security and this was pretty very exciting pretty challenging but at some point in time I turned my

attention again to identity and this was spin-off of Pado ID because Polygon ID at the time >> who was who was the name as Pado ID this happened in 2024 last year and uh what we did was to join hands with a team called Disco. Okay, >> this is lead by Evian McMullen who is an OG in the in the space and in Ethereum space and verifi identity and verifiability of data >> and u we gave this aspect of um you know not only getting CK but also applicability on on verifiable data and uh Evan has been the a co-ounder of this project of creo she's currently the CEO and we're working together on this

billions network right now but she's not she's not too much into CK because maybe the fusion of both teams made us better in terms of uh combining different capabilities and also different sources because the disco team basically came from the US now we are more global and we have a general different mindset uh because we are maso we are more based in Europe >> merging with disco team was very very good option for us was making us a better better team because getting people coming from a different angle of identity and uh different origin. They come from the US basically and Evan is very very expert on the identity matter and and the strategy was uh shifting a

little bit for us. So we are now more focus on on the growth and the representation of uh the new strength of the team is the the growth and the mind share we're having with the video support team. >> Um so we are very excited about this and yeah the next steps. >> Cool. So if I just just to follow kind of the story, we knew Iden 3 back in the day. That was the first time I think that this idea of using ZK for ID was even proposed. I mean maybe it was based on some earlier work. You were saying this is 2018. So you know quite a ways back. You also joined Polygon as part of Hermes >> but Iden 3 I guess went with you to Polygon became Polygon ID >> which was a one of the sort of ZK

projects >> and then you spun out as Pado ID merging with this project called disco.xyz at XYZ. Is that correct? Or did you merge after? >> Yeah. >> To create billions. >> No, no. Is going back in time. We founded Ident 3 in 2018. >> Yeah. >> The technical leader was Jordi and Jordi was who came with the idea and they convinced me to get into the space and and also Anthony to create this this technology based on Ethereum the centralized identity. At some point the protocol was cooking and Jordi said we need privacy and then his vision was you know developing development of sitcom and NJS libraries who are super wellknown and we were working on privacy all this time until it was impossible to verify anything on Ethereum. We pivoted

to scalability with Hermes. >> Y >> and then we were acquired by Polygon. >> I see you pivoted to to scalability with Hermes joined Polygon but yeah what happened to Iden 3 like it joined Polygon 2 though right? Ident 3 is an association who who owns a specific IP for this public good of sircoms and ident. >> So basically we joined polygon to build develop the toolkit on top of ident 3. >> I see. >> So this polygon ID and that is where Sasha and other colleagues started to work on the identity. Basically the identity protocol was pretty much at the beginning. So these guys finalized the protocol, finalized the application and then we started to build layers of

utility and the the finalization of privacy in terms of communications was also very important. After polygon ID we spin off as private ID join hands with disco and at beginning of 2025 we rebranded to billions to to have this new yeah network of users. So is Pado ID billions now or is there really two orgs because you do have two websites. >> No, it's the same. It's the same. >> It's the same thing. Okay, got it. >> We are the same guys. In fact, if you call us billions, it's also fine. it is still a brand. We have so a few collaborations with governments who were already ongoing >> uh like in the in the the department of labor in India >> and also some projects in in the meds that we started before the the billions

brand and we are working instead with Po as a brand still exist >> but billions is our focus and the team is basically billions today. >> Cool. So Sasha let's turn over to your background. We know you a little bit through the whiteboard sessions. you actually hosted back in 2022 one of the modules on ZKID. I guess you were talking about what it was at the time. Let's hear your story also kind of like what got you excited about this, what you worked on at Polygon and in within the Polygon ID team and how that developed. Yeah, basically I'm uh in the crypto space from 2013 and I started with Bitcoin and we were developing

applications that were working with Bitcoin. So it was like we started development of kind of payment processor. We we tried to build a project that was a competitor to Coinbase, you know, this this kind of things. Then finally it didn't work. um for us because we we couldn't solve all the legal stuff and so on. >> So we pivoted a bit. It's it's it's just my I I was a co-founder of small startup and we were building this stuff. We pivoted to build um network of Bitcoin facets.

>> Faucets you mean like where you get free Bitcoin? >> Yes. >> On a test net or on the main >> No, mainet. Mainet. >> Wow. that existed. >> Yeah, it it was in 2014 and um the funny story is that >> it was so popular that uh we were producing 2% of all the transactions in Bitcoin network. >> Wow, that's a cool claim to fame. >> Yeah, >> nice. We were in top 100 sites in Brazil and yeah it was interesting time but you know we we couldn't get a lot from this because you're giving away money you earn a little bit from ads so yeah we we

needed to shut down this then I was working on different blockchain projects with uh with the guys that finally work right now in privado and billions We were building mainly government use cases like proof of concepts for for governments like we we built a land registry for Sweden. Then we had been doing some something for banking for tax accounting and so on on private blockchains and one of the projects that we uh worked was actually self-s sovereign identity. So we started building a SSI solution based on

Ethereum. >> What year is that that you get into this? >> It was in in 2019. Yeah, in 2019. >> So Iden 3 was already around at that point, but you weren't working on Iden 3. You were working kind of independently. >> Yeah, it I was working a com in a company and there was a change in the company structure. They merged with another company and they changed a little bit direction. They had already the other company had already >> their own SSI team and they were working using anonymous credentials and you know this ZK stuff from it we so we tried to integrate both solutions. That's where I

I understood how this anonymous credentials and ZK stuff works there. M >> it was not usable totally because it's it's very slow. It was not working on mobile >> and we even develop something to make it work on mobile but in the end it was like >> it's too early sounds like. >> Yeah. Yeah. Yeah. >> So what at what point do you start to merge in with the Iden 3 folks? Did you just join Polygon or had you been part of the Iden 3 team before? >> Yeah, it it it was before. So yeah then >> after we finished this project like uh of of merger of these two identity solutions like uh we couldn't sell it our our company that we were working so

that's the point when I met David and he was looking for a team >> to continue working on Iden 3 protocol >> it was exactly that time when there was a change of the direction and concentration was mainly on the scalability. Yeah. Scaling >> and David and Jordi wanted to continue work on identity and that's where I I joined and brought a few guys that we were working on on the identity stuff and yeah that's that's how we started.

>> And then you would have gone on like into Polygon when that acquisition happened. Polygon ID what was that? Was that like a different team from what you were David? What you sort of suggested there was like yes the whole org went in but like you guys focused on the scaling part. Sasha were you leading the ID part in the meantime like was and was there a specific team on that? >> Yeah. So we were a separate team. We joined Polygon a bit later than uh Hermes project. So we kind of continued to work on the identity maybe for half a year or something like that. Then we finally started as polyhon ID. It was a

very nice period of time where we were expanding a lot not only developing the protocol but finally products on top of it. >> We built a lot of tooling. We built we expanded the protocol. We implemented a lot of very cool features on on the privacy side. Then bigger changes started to happen after we spun spin-off. >> I see. >> Yeah. Yeah. But the team the team was the same basically they started in 3 continued with polygon. We have the same team since probably 2020.

>> Yeah. >> In those earlier days of the privacy protocol and the ID protocol like you were sort of saying like there weren't the libraries or tools to really do what you wanted. So it was kind of you would kind of aim to build something but then you'd probably find out I'm guessing you'd find out you'd had to build so many things in tooling to get there and would you say like circom came out of the attempt to build IDEN 3 like was circom the the sort of one of those tools where you're like we need a DSL we're going to have to build a language that like and tool set and kit that can like that with which we can build ident 3.

>> Yes. Well, sir was a creation of Jordi. this here and he was >> at the time he he said we need privacy for identity and then he started I'm going to create a toolkit because >> okay >> the belma bma my libraries were not very practical and he said I need to do something >> more easy to implement some some some tool kit that makes more sense >> and then he closed himself for a few weeks and then he came out with >> circle >> so I mean there's a lot of contributions later in the team I mean Sasha and the team are they the current team that provides support on the identity channel for second. So this is uh how the the involvement we have today. But the the main vision and the idea and even the the first version was your distribution.

So full credit to him. >> The reason I'm actually bringing that up though is like I think a lot of listeners are really familiar with circom and this is just speaking to the origin story. And so what you're like from what I'm gathering it's like circom was originally really built for the ID use case but it's been since then used for all sorts of things, right? Like it's being used by lots of teams. >> Yes. Yes. Yes, because the initial process the thinking was Ethereum is going to help us to have the centralized identity and we were pivoting on the concept of an Ethereum account can be an identity and several ideas but at some point we started no we need a state transition state >> and then we came with the idea but where where do we put the data and putting data on chain is super bad idea even if

it's encrypted because it's there forever so how we minimize data that goes on chain but still you can you know refer to this information and Then you said there's this thing called CK that we need to to solve here. So sitcom is basically fully focused on privacy for identity >> for identity. >> That's part of identity. >> That's cool. I mean we did episodes I think I have an old episode just on circom with Jordy and we'll dig those up to add links if people are curious because I'm sure he talked about the origin story there too. But I guess for me, I had sort of forgotten that that was the connecting point and that this was the the use case that actually prompted that development. It's been super influential on all sorts of fronts. So very cool to to find that out

again. >> Yeah. And the funny the funny story is that we are still using the same technology ourselves. >> We've been going through so many optimizations which Sasha can talk a lot about but uh >> cool it's the same tech. >> Okay. So I think we should actually dive into the tech of the sort of the underlying stack and maybe you can share Sasha what what it was while it was like polygon ID and if it's changed in that sort of like transition out I mean you're saying it's similar it's you're using the same tool stack but like what have you been adding to it? What was it originally and like yeah what is it today? Yeah, originally it was ZK identity when when I joined the project, it was like a set of libraries and proof

of concepts, but it was not working with anything like decentralized identifiers or verifiable credentials. It was like just the pieces of information that were not kind of they were not standard ones and they were very custom ones. And like first thing we we started was trying to to make it standard compliant. So initially we started with decentralized identifiers and then we added support for verifiable credentials and that's that was a big part of work that we started before joining Polygon and but it was actually done during uh the time

at Polygon. So we transitioned from this custom data formats for for the credentials to verifiable credentials. >> Do you want to define verifiable credentials again because I think we've talked about this in a lot of these other ID CK ID focused episodes but yeah what what do you mean when you say that? >> Basically it's uh just JSON container. There are few containers that are compliant to um verifiable credentials data model. It's one of them is JSON LD JSON link data. So we are using this one. There are a few other just plain JSON files and GVT token or some some other flavors there. Yeah, but all of

them somehow are verifiable credentials. >> The funny part of the verifiable credentials is that we work on on the standards in terms of adoption. The W3C set up these formats for interoperability of data and they are used all over the place not only in crypto web3 but in any let's say transactional identity and the the DID and verifiable credentials was something we had in mind from the beginning to be interoperable. So that was very important step >> when you say that this year you just mentioned like the JWT tokens like you're talking about like Google O right like the Google signins and stuff like I we've covered this a little bit in like previous CK email episodes but what are you building cuz like are you more like

interfacing with existing verifiable credentials coming from existing systems or are you creating a system to create verifiable credentials? >> I would say both. Right now in billions we are doing both. >> Uh one is ingesting existing data and transforming into a format that is easily provable. So we our verifiable credential format has zk friendly signature schema and also revocation schema. So we have developed this part that makes standard verifiable credential Z friendly where >> re like existing other implementation they are not ZK friendly it's just

regular you know ECDSA signatures or RSA signatures with revocation statuses that are not privacy preserving like you need to reveal your identifier or identifier of the credential to make use of bit of of the revocation. >> So yeah, we we were developing all this privacy things and ZK friendly signature based on baby job elliptic curve that Georgie co-authored. >> So yeah, it's building blocks and we were targeting standards to be able to go to government use cases to to broader other than just web three to to broader

communities. >> Makes sense. Have you followed the ZK email or the ZK login work over at SUI? Like is it similar to what they're doing? Have you shared any of the work with them or taken any idea? I'm just curious if there's like a little bit of a collaboration there cuz it sounds I mean it sounds like a space that they've been working on. >> Yeah, we collaborated a bit with ZK email guys. We helped to resolve a few issues on circom side optimizing their circuits. Uh we have guys who are working a lot on the optimizing prover.

We have built rapid snark and made it work on mobile. So we we collaborated with a lot of teams including open passport on making it work like better on on on their side. Yeah. So, it's it's like smaller collaborations, smaller just casual helping uh guys, not that we were like official partners or anything like that. >> But you're it sounds like you're I mean you're working on the same libraries on some level. And just a note, Open Passport that you just mentioned, we had on the show Self. Open Passport was sort of the origin team that that kind of merged with a group out of Cello to

create Self. We did an interview with them. I'll add a link to all of those previous ID projects that we've had on the show. So, yeah. And and so what you're saying is kind of like the underlying libraries for a lot of these things. I mean, they're they're either coming from CIRCOM or there's like a lot of collaboration with CIRCOM and the ID work that you've been doing. Would you say like are you doing the same kind of products as they're doing or have you taken it in a different direction? No, it's pretty different because what we are doing is more like universal container to ship data >> whereas their projects are specifically built products that have implemented

specific cryptography to verify just Google login or just email that was sent. So it's purpose build very >> narrow basically >> narrow. Yes. Okay. >> Yes. >> Where we are building a protocol that is covering this use cases with a bit of work. It's possible to do to issue credentials produced from this data that ZK mail or ZK login or other doing >> actually we what we have done is we've taken a nonadhar circuits and we've built issuer that is converting data from the atar document into the

verifiable credential. So instead of calling a nonadhar circuit each time you need to prove something based on your atar card you are doing it once and then you have a verifiable credential in zk friendly format that you can use for whatever reason the verifier is asking you like we we support a lot of different things. So what real identity protocols are doing is that you can do for example selective disclosure. Yeah. So disclose some field from from the credentials that you have or you can do predicate proofs. You can prove that you have a credential that states that your age is over 18. Yeah. Without disclosing

anything from the credential uh without even disclosing metadata. Who have issued when is it expired or not? like this all all of these checks are done inside the case circuits and then verifier receives only proof that yes this user has valid credential from trusted issue and he's overrating >> that's cool >> I I wanted to this that uh generally our approach was always very broad in terms of the use cases we can support in the face of ident 3 we're building this public good as a protocol the CK language all these as the polygon ID the objective was to

do developer toolkits so they could build on the polygon ecosystem although it's CBM so they could build anywhere anyway with privado we wanted to create this marketplace and ecosystem where everything was possible and you could build this any kind of credentials on top of that we have tools to create custom queries that from a specific verifiable credential you can extract the verifier can on the fly ask you for specific CK proofs, composing credentials, so every sort of things that are very powerful >> but it always was open in a way that >> you can do so many things but what we do here no this teams has been more focused in solving a specific use case. So with billions this is the first time that we

are solving optimizing for something which is basically growth of a network of humans and AI and uh of course all these technologies out there and we will start reflecting this capabilities very soon and the product will be able to do very cool things but we we went from broad to narrow this probably happening now >> but yeah Sasha could talk about tooling if you go to documentation talk you will find so much so many teams have been contributing and helping but also using >> okay and actually this this leads me to a point where I wanted to do a little bit of a comparison between some of the projects that we have talked to so you've sort of shared a little bit about self and zk email being very focused there was another project called raramo

that we had on earlier this year they're doing certificates passports bringing them onchain like what what is the comparison like let's now go past prov because I understand you're now focusing in So yeah in the focused part of the project are you are you aiming to be like those projects are they different? >> Yes we are building very similar product here billions >> as raramo or as self >> something in the middle like >> okay interesting >> it is it is we are taking self circuits and we have modified them to produce verifiable credentials. So one part of it is just verify a signature of the passport you know and the data in in it

that's where we are using open passport circuit self circuits >> but we are not verifying signature in ZK we are verifying signature inside trusted execution environment so >> in this we are close to Rimo >> okay >> how they are doing so they are also verifying signature using Oracle. In our case, it's a trusted ex execution environment and I I know Rimo team and Lasha since 2019. >> So you also knew them back in the day.

Okay, >> cool. >> So yeah, I I participated in hackathons with Lasha and we won a few. Yeah. So I know them for very long time. We collaborate on on different topics. Yeah. Hm. I think you actually reached out Sasha because of the recent episode we did with ZK ID from the Ethereum Foundation. So the episode was ZK PDF and ZK ID. Ying Tong was sharing with us sort of the PSC's work on the ZK ID front. Like one of the questions that came up there was sort of the revocability and that's kind of where you reached out. You're like, "Oh, we have a solution that does it, but how would you compare to what they're building?" And are you also targeting because their their whole goal was to

like fit within the European Union's digital identity effort. Are I'm assuming you're aware of that. Is that also something that you're aiming to be able to provide with billions? >> Yes. First of all, yeah, we tried to aim for this UD wallet and all the standards and we started standardization efforts and actually one of the results of the of this efforts was that just I think very recently a report was published by the Etsy group. It's uh like a standardization body in in European Union that was reviewing >> different uh approaches to ZK identity and and overall identity standards that

are out there. They uh included identity protocol and our signature schemas and our approach to the revocation also. >> Okay. So you are aware of the EU initiative. >> Yeah. Are you similar to what they're working on over at ZKID and PSC or would you say you're taking a different approach? >> So ZK right now looks like they are more in exploratory mode. They are looking into different directions what could work trying to one approach than another and so on. So we we have the solution and our approach was try to get this to work and make it compliant uh >> already. Yes.

>> Okay. Let's talk about this revocation because that was kind of what you had reached out on originally was like we have this way to do verifiable credential revocation that's different from the sort of I think you had sort of showed like a naive approach which is just like oh you have to reveal everything and then you can revoke. But here you've been able to do it in a privacy preserving way. How does it work? And for anyone who's not clear on what the revocation problem is, it's like you've registered, you've kind of signed up to be part of one of these ID systems, but now say you've lost your passport before its expiration date and you need to sort of recall it.

>> Yeah. So the concept is that there are three actors right in the identity ecosystem. One of them is identity holder who has this credential. Then there is issuer. the one who is creating credential for the user right and there is a verifier. So what verifier wants to do is verify that get some data verifiable data about the user and wants to know that this credential based on which it was generated is not revoked like passport or maybe it's a credential saying that you're an employee of a company or that you have control over

Ethereum address let's say. Yeah. >> Mhm. So how we solve it is that on the user side identity holder is generating zero knowledge proof that credential is not revoked and how it works is that in the verifiable credential we have a nons revocation nons it is a random number that issuer is putting into it >> ah the issuer so you're talking this is not the ID holder the issuer itself so like the government or something yeah >> it's adding something that says this is a it has not been revoked. This is a valid ID.

>> Yeah. So in in the credential itself there is just an identifier. >> Okay. >> And then issuer is maintaining a Merkel tree. >> Mhm. >> Where all the revoked credentials are added and then user needs to prove that his revocation nons is not included. >> Okay. Got it. And for this to work efficiently, another big part of the protocol of of the system is sparse Merkel trees. We're using sparse Merkel trees.

>> Another thing that Jordi initially contributed and created a way to to build efficiently like you can prove that you not only that item is inside Merkel tree but that it is not in Merkel tree. >> Yeah. proof of inclusion or proof of exclusion. Okay. The relationship you just described was between the ID holder creating sort of the initial registration making sure that it's not on a re revoked list. But what happens if the revocation happens after the registration?

>> Yeah, it's a job of issuer. >> Okay. >> To publish identity trees. We call it identity trees. One of them is revocation trees. There are two other identity trees in in our protocol. One of them is called claims tree where credentials could be added uh or more specifically hashes of the credentials and there is another tree called roots tree where older claims roots are going but it's it's more a technical thing. >> Okay.

>> Yeah. But overall issuer needs to publish a revocation tree. >> Mhm. And we have different options of how to do that. It could be onchain. It could be offchain by the issuer itself or we have a concept called reverse hash service where there could be a generic pool of hashes published. It's it's not even trees. It's just hashes with a pre-image sent and then you can resolve out of it your having just a Merkel root of a revocation tree. You can resolve the items that you want to get.

>> When this issuer would publish the new updated revocation tree, does it automatically check the existing registry to see if any of them match up? like would it would it prompt the revocation of some of these? >> Yeah. So, how it works on the verifier site, a verifier uh has a >> it's the verifier who's going to see this revocation tree. >> No, it's it's user who is checking this revocation tree to generate a proof. >> Yeah. >> But the verifier then receives only Merkel root and needs to check that it's pretty recent one.

>> Okay. that user has referred. >> So there is a validity period during which there could be changes different changes to to Merkel roots but still the one that user have used is considered valid. It could be like verifier could say okay I'm I'm okay with >> 2 minute delay for the you know >> or maybe if user is yeah offline and he have fetched all this data and then proving offline something then maybe a week is okay.

>> Yes. >> Okay. So, the ID holder has to generate these proofs, I guess, more regularly. Like, it's not like a one-time thing where you register, you have a proof, and then you can use it as much as you want. This is like you'd have to be doing it, I guess, on a certain cadence, and then the verifier would only accept it as long as it's still not in that revocation tree or as long as the nullifier is not in that revocation tree. >> Well, it it depends on the proof. No, because if you need to prove you are over 18 years, this proof maybe like forever >> don't expire. But depends if you want to prove that you have access to the diretorial server, you might want to do this every time. So proving on the mobile device is taking know 5 seconds,

3 seconds, something like that. So it's very convenient. >> But going back to that example of like why do we need a revocation? Like what if you lose your passport? You lose the initial certificate. So somebody else out there might have it. you don't want someone else to use it on your behalf to prove that they're over 18 when they're not the the fake IDs. But yeah, like what would you do? Like I guess it depends on the system though. It depends on like how frequently they're actually needing to to update and make that connection to the new revocation tree. So the idea here is that we are not imposing this restrictions or user does not need to do this proof set special cadence or

whatever. Verifier sets requirements to to the proof and then user generates a proof according to this requirements and one of them could be freshness of of the revocation status that was used to to prove it and in some cases it is okay and verifier could even say that I don't care about revocation for example you had the valid credential that you were an employee you No, it's still after you move to another job, it still has value because you can prove that you worked at Google, you know.

>> Fair enough. Okay. So, sometimes you don't need to do like this updated revocation, but other times you do. >> Yeah, we have the whole protocol to do this interactive queries between verify user and user visual. So, the privacy is still kept. >> Is that all within billions though or does billions make choices? Like I'm sorry I'm still trying to figure out like how billions builds on the stack. Like is Billions saying okay we're going to set a revocation period for this particular system but that the underlying more general purpose could be used in all these different ways.

>> Exactly. >> So billions does make decisions. >> Yeah. Billions make some decisions because the level of verifications to consider you a human or a unique human or a fully verified human might require different set of verifications and we might want fresh documents. We might want this specific support for passports but in terms of uh extension to different use cases then as Sasha is saying the the fire will say all this technology is available there in the underlying stack. So we'll make it use as convenient. I'm just trying to make a bit of a distinction though between that general purpose tech stack which as you said can do anything but also the billions network itself like if you are in billions what's your revocation

period like have you made a decision on that is it something that you check every 3 minutes or every week or >> no regarding revocation it's uh up to the verifier to to specify how fresh proof should be. >> Okay. >> Yeah. including revocation part but if we are talking about other things then it's not to billions itself but to the issuer >> who is issuing this credential so we have a few issuers integrated we have KYC providers we have uh proof of uniqueness based on biometrics and it depends on on their business decisions basically it's how they how

often They check that passport is not revoked and we are building for example now ML checks together with this KYC providers >> and it would be depending on the use case would be different period of validity for credential. I see. >> And they would check on a regular basis is this person in sanction list or not for example and then it could be that they are checking once per day then as soon as they discover person in sanction list they revoke a credential.

>> I'm just trying to figure out how like customizable interfacing with the billions network is. So what you described there you're working with a KYC issuer. They internally may have different use cases where they want a certain revocation period to pass to prove that these things are still valid. Does that mean that like they're they're interfacing only with the billions network? They're not creating their own stuff like they are actually using this network but there are sort of like levels that they can set for those individual cases. Is that how it works to interface to like work with the billions network? It's kind of decoupled a lot like we are not imposing any restrictions on how often they are

issuing, how often they are revoking things. It's basically open marketplace and everyone could be an issuer and everyone could be verifier and identity holder. >> Mhm. >> Including AI agents, they could also have identity and that's another direction that we are building right now. M >> but it's more like a framework for everyone and billions have only a few things that we have decided is when we are issuing credentials ourselves and >> okay >> it is passport credentials at harsh credentials and in the future we would have a few more that we would be issuing in a

similar to TLS you know this kind of >> ZKTLS that isn't really ZK >> or MPCTLS. >> Yes. Yes. >> Okay. So, you're also like you will potentially also be able to do things like prove something about a website like oh yeah, you have a login to this bank and that would also contribute to your KYC like your identity on billions. >> Okay, that's cool. >> This and and we also work on reputation on top of identity. Okay.

>> So coming from at stations from members of the network plus also some process of uh activity based on interaction based on even on chain interaction. So I will work on reprod the the project of billions has three phases is the first one is building this human and AI network is developing the growth >> uh and this foundation of identity and privacy between them. Second phase is reputation. So we need to build this to provide rich interactions in a way and the last one is to support open economy use cases. So we >> we can just lean on this verification and reputation as an extension of verification. So peer-to-peer interaction with privacy can be more

valuable to everyone. >> Interesting. I mean that that idea of reputation isn't something we've talked about much with any of the other teams so far. back in the day we like you know a few years ago we had Sismo on and they had been talking about this onchain reputationbased ID which I loved. Yeah. So, it's it's kind of fun that to hear that you're bringing that back as as something else that could like maybe it's never gone away, but it's >> but bringing it >> as something else that can kind of like validate that you're an individual that you will work in good standings beyond like real world certification like sort of off-chain certificates. Yeah, for us looks like the natural path because once

you see everything we can do with the protocol, you see there's a lot of opportunities to to build things on top of that and we don't even need to be ourselves building everything. So >> there's going to be we have a lot of tools and space to design things once we are opening this kind of network to the to other teams to build on top of that. So you mentioned some of your customers or like planned customers, so potentially KYC issuers. You had mentioned governments, but I wondered if that was more on the prao B2B side of things. Like do you expect these entities that could use I don't know IDed people to be customers of billions? Like I'm just sort of curious

like how what what is the relationship between them and your network? Like I'm assuming you would have a lot of the register. So like the the people who are actually creating little IDs on chain is happening within billions. But how does the rest of the world like how does a company interface with that? Do they have their own segment that they have already checked? Do they have access to the entire thing? >> Well, the network is a registry of users. They can interact with any applications they want of. I mean you can have a company application and you share a link with these users and the users proactively can just approach this and the objective of developing the network is to create more and more use cases that benefit from the scale of

reusing credentials. >> Mhm. >> So a company can issue an application that's for employees only and they issue credentials. Credentials may be even you know I'm I'm an employee or I have an access to a specific door and these credentials may be revoked when you cease to be an employee employee there. Mhm. >> So that's one use case and and the same the same person can have billions credential to do something else. >> Okay. >> It's a framework and an ecosystem that we we aim to have you know accessibility but not to the data because data is private. It's basically you offer things to the users and the users may decide because it's about the usability. If if I have I have verified my passport once and I'm able to prove I'm over 18 and I

am citizen from a specific country. If taking application is compatible with that, why would I need to do this again? >> Okay. And that's exactly the problem you're trying to solve for because we find ourselves constantly sending our passports around >> in like plain text. It's super scary. But in this case, you picture sort of what it sounds like is you would do one a one-time registration for the document. you might be able to add to your identity. It sounds like for specific use cases if some maybe one company is asking like cool passport's good but we also want proof of address or we want proof that you've lded in this DeFi protocol or something.

Exactly. >> You would be able to sort of like add to your ID within billions. >> That's the power of our stack. You can add as many credentials for user for application for interaction >> and users might have like might hold like a wallet in the phone with different credentials. >> Yeah. >> To access different services. >> What about if you like don't want everything on one identity though? Like what if you want to start again? Say you're >> I love this question. >> Say you're like you're not a bad actor, but some bad things have happened. I don't know. And you sort of want a fresh start. Like what do you do? Are you forever tied to this thing?

>> Yeah, we have a very cool feature that SA can explain. Okay. >> Of dive identities. >> Yeah, first of all, we are limiting exposure of the identity. So we for each interaction with different third party, we are generating different identifier for the user. So >> if it's doxed, it's it's just one identifier of you like you have thousands and you can generate another one and still be able to use all the credentials that were issued to you by all the other issuers and so on.

>> Yeah. But still, like if you're talking about sort of this reputation score though, I mean, I think there's an example where like you're a bad actor and you get a bad reputation and it's good that that's attached to your identity, but what if like you're interfacing with some organization and that organization gets strange and starts to like give bad reputation just by in by by having been connected to it? I mean, you're saying that you have individual identifiers, but could that still affect an overall reputation? And if so, how would you ever like clean it up or switch or start again?

>> One way to solve it and we are doing that is that we are using like user is using private identity, private profile. >> Mhm. >> Wherever user can and then if you need to expose some data, you are limiting exposure. But also what we are building is public profiles that you can share with someone and that's where reputation would be collected in a way >> and yeah you can close it and use another one you you would be able to prove that still you're unique you're real human you can start over without losing all all of your data that you

have already collected. H >> any identity can create a credential or issue attestation over other identity. So basically trust is based on who is the issuer of this claim or this of this credential. Basically we see this in a positive way. Users might want to collect the credentials they are interested in in their wallet so they can reuse. But if you have noise and you know undesired interactions and this might be there but nobody can identify you anyway. >> So it's not tied to to you. is not a burden for for users. Basically, users they use whatever credentials they are interested in >> okay proving >> and it could be like an opt-in. You could share your reputation if if it makes sense in that particular case.

>> Yeah. Kind of reputation is linked like for example how do you know is it a bad actor or good one on on X? Yeah. You just have his handle right and then this reputation is somehow linked to to this handle. And if you start over then there is zero reputation. You need to build over all the reputation and yeah it could be bad or could be good like but you at least have this chance right? >> What's the breakdown right now of the companies that want to interface with billions network? Are you seeing mostly web 2 KYC teams that now want to like add a I don't know a verifiable

component to it? Is it banks? Is it onchain products? Like I'm I'm sort of trying to picture what kind of customer base you have or you envision and I'm guessing they pay you, right? Is that how you actually make money to the like >> Yeah. >> If a DeFi product wants or if some team wants to do like an airdrop, would they be somehow paying billions network to be able to use this KYC? >> Yeah. Yeah. Yeah. >> Okay. >> Exactly. >> Yeah. >> So there's two components to it. Billions will have a token in the next few months. Uh >> so we will create the the toconomics and the model. So so the the whole participants and the project itself benefits in a way this is based on growth and usage the way we assume that

there will be network fees because we we bait a lot on web3 space and onchain interactions. That's one. Second part is we provide just services of integration of uh companies governments. We provide the support to teams currently they want they we're supporting airdrop campaigns. So basically we provide proof of uh proof of human proof of uniqueness that we have a portfolio of options to these teams. They they decide what's the the kind of uh choices they make in terms of distribution of incentives. Uh basically we avoid bots to get aird drops if the team decides so and we get paid for that. We have a connection with we have all these marketplaces there.

have the marketplace of issuers. We have the marketplace of uh verifiers. We also ourselves we have some basic credentials inside of billions. >> So teams decide was the recipe for the service and they they do that. So there's a past interactions with banks we've been polygon this trajectory we've been uh we directed with governments with lobing with the European Union. We we are in a sandbox currently in the European Union for race verification with another partner. We have you know here and there you you you get funding you get compensation but our strategy is now very focused on web3.

>> Okay. >> With billions primo has been more like over the place >> but with billions that the idea is to get the excellence of privacy for web 3 in the use cases of web3. So that's why we talk about a lot of AI identity a lot of partnerships happening today and if you follow our Twitter you will see >> several of them AI teams basically partnering with us because our deep trust framework is an implementation of Asian identity that you can provide some kind of accountability because humans and and AI need to interact in a way that's that makes sense because >> we are solving the problem here of you you receive contact from an agent you don't know who's decision representing how it's built, how it's

trained. There's a lot of teams that that uh are super happy to to work with us. But this is these are more long-term relationships in in the short term. We want to have uh development of human network. It's pretty clear and of course if we can develop AI agents also looking forward to have our sweet spot is to optimize for onchain interactions and we create this kind of support of economy on chain. I have a question on the AI agent point specifically like are you picturing creating a registry for AI agents as well? Like do you want to define oh you're a human not AI or you kind of like you also want to define AI?

Do you want those to have their own category? Because I think there's teams that do want agents to interact with them. They're not it's not about like blocking bots. It's actually about like engaging with with these but just maybe knowing what they are. So it would be possible to distinguish is it human. You can prove that you are a human and you can have an identity and see that it's it's a AI agent and who is a author who is this agent representing and so on. >> We are creating a network where humans only >> because protocol is very rich. We can ask agents also to have an identity and seek proof things. We got to allocate

credentials to to an agent. They can do the same kind of interactions plus there's all this world of reputation about other stations experience who training models. I'm not a nice expert on AI but all these teams are so upet. So this means we we created something interesting. Plus in terms of a regulator we have discussed with some of them and there's nothing the regulation is completely do on the AI topic. >> Yeah. >> Because AI agents are already there. >> Yeah. Not only our our mission is to save the internet with in the age of AI agents because you need to recognize what what interactions you have with an AI agent but in terms of operations there's a legal framework that needs to have some kind of accountability. If

someone wants to sue an agent what you do >> then you can be scammed quickly by an agent. There's more and more interactions agents trading for you agents selling you something. >> So all of this needs to be sorted. Uh that's our framework also in in place. >> I'm just sort of trying to picture a case where like an AI agent tries to interface with one of these protocols, but because it almost like is lacking the proof of humanness, like some certificate, a passport with an issuer, like the issuer's kind of proof that that's a real passport. That would basically mean the AI agent doesn't pass that ID test in a way because it's lacking some identifier, but it might have other identifiers. So if it's like,

oh well actually it's not about KYC for an investment, but actually we want just users to start playing with this tool and we want to know who they are. The AI agent may have whatever credentials it needs within billions to actually pass through that test. I'm guessing >> exactly. Maybe there's another use case where there's an application that Anna can access or an agent that represents Anna can also access. >> Okay. So I could almost like delegate authority to an AI basically. Okay. >> Exactly. You have the agent that represents you and you are if you are you know a specific employee employee of this company. So my agent can also do the same thing.

>> Or you can >> interesting >> you know set up a meeting with an agent that represents you in a way. So you know who you're talking to. In a way this kind of uh delegation of identity is also supported and the agent can can see it proves something about the person that represent or the organization that represent. >> Nice. Well I want to say thank you to both of you Sasha David for coming on the show sharing with us sort of the evolution of Iden 3 to Polygon ID to Pado to the billions network explaining a little bit more clearly what the billions network project's goals are and the revocation story. I also I like the fact that we've talked in this episode about the AI agents something we I mean so it was brought up once with like we had an interview with Costas from SUI

and Tun as the co-host the episode was about access control to accounts >> but Tun's example had been what if you have all these AIs how do you give them access or not have them have access and it was kind of an interesting question I don't know if the team at the time had been thinking that much about it sounds like you are yeah in the ID space I hadn't really I hadn't thought about like the AI agents and how they should be labeled but would you say like are you already today offering this AI agent component or is this sort of a future build >> we have it already yeah we have an implementation we have SDK we haven't yet open sourced it but it's it is close

to it yes >> cool well that's very interesting yeah thank Thank you both for coming on the show. >> Thank you. Thank you, Anna. >> Thank you, Anna, for having us again. It was great to spend some time with you and always we always learn from even from you. Thank you so much. >> Cool. I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Hector. And to our listeners, thanks for listening. [Music]