TG ZKP Task Force Meeting - 2026/09/15

Hello. Hello. How are you doing? >> I'm doing good. How have all of you been? >> I am great. Where are you located? I um I don't think I've ever captured that. >> I am located in the eastern part of India at a city called Kolkata. >> Oh, got it. Awesome. 9 and a half hours difference something like that >> from GMT we are 5 and a half off so it's around 8:30 in the evening. >> Yep. >> Hello. How we doing? >> Hi. Howdy. So I heard Dennis will not be able to make it and Drummond will not be able to make it. >> Okay. >> This might be those who can make it. >> So it's just us. >> Yeah. Potentially. >> Although this is full of surprises. You never know. >> Yeah. Shall I kick it off or anyone feeling intuition to wait a minute? >> Thank go ahead. >> Cool. Well, welcome everyone. I will point to the antirust notice so we're all aware and digging into the recap. Uh last week was the Berkeley session. They validated ADR00001 as our first proof to build. Uh the offline voucher problem, proving your voucher is a is a community member while they are offline uh is solvable and practical with blind signatures. And the loadbearing choice is the signature scheme, not the ZKP. uh it has to be postquantum and the hard part and it is the hard part to change later because it means reissuing credentials whereas the ZKP can be swapped. Um those were kind of encapsulating the the big talking points from from that call last week. So the the um the signature scheme does that have a um an impact on which ZK P family >> is is possible. >> Yeah. >> Okay. >> Yeah. The schemes based on lises have a particular set of proofs and then the schemes based on hashes. They both can kind of um fall within some of the more general CKPS but there are limitations and boundaries on either side. So just to understand the um because I think this is an interesting you know point the what would be the process of saying what's our use case based on this use case we need this sign signature scheme and because we need this signature scheme we've got these this family of zks available. Yeah, I think that's a fair process. And then the at each step there's um like a gated decision and one of the key decisions around the signatures is the the size and um the timeline uh of or like the importance I think >> like the the size of the proof or the >> well the the purpose of the signature like there's like not all signatures um need to be equal, right? Like if if one signature is just like a oneoff use kind of burner style disclosure of a particular face that you want to show. Um we don't necessarily need the bigger postquantum signatures. Um, >> but if this is something that is like securing the verifiable trust agents delegated authority or something, probably talking about a bigger signature, which means that that then changes the um the like time it takes to compute the signature in the proof or the multiple signatures in the proof >> and that timing is then the UX conversation. Sorry. >> Because it's like, yeah, can this happen on my phone when we meet in person or versus um is this something that I want to like run for half an hour in my family home in order to secure our um documents that are important. >> So, yeah, it's good that they're focusing on that question, too. And I think it's that I see this group has passed the creation of the spec um being sort of wisdom on that workflow when people start using trust graphs. Cool. Uh the first item we don't have Dennis but >> um any other sorry any other reflections on the Berkeley call. Um, >> yeah, I guess for me because and sorry because I I haven't been able to join the earlier calls and so I'm a little bit out of not up to date with what what's all happening, but they're working on a specific proof out, you know, independently that they think can be applicable for some of the stuff that that we're doing in the trust graph. >> Yeah. >> Or did they say we think we could do something that that you guys need? I think they are building something that we need. Um, however, yeah, that's what I was trying to get from they call it sounds like it's not in an academic sense anymore. It's more of like a deployable framework for um or there's kind of like two layers to it. there's the thing that runs the proofs and the like software that does it. Um, and I don't think they're doing that. I think they're working on like the types of constructions and the code that goes into how to run the proofs and they've identified that the ones for that are required for kernel at least as I was aware from the conversation is what they're working on. Um, so I assume it will be sort of folded into um that project and then become available, which was kind of why my action item I was hoping they would try and bring that into the spec document as soon as possible. >> Mhm. >> But yeah, thanks. I I think that does need clarity. That was one of my takeaways as well from the Berkeley call just like working out where it's a independent project and where it's uh contribution to trust over IP. >> There there was also a discussion on that call last week about I mean it should have some I mean I the reason I joined this call is because I want to learn more about ZKPs. So, I don't know anything about them or very little. And so, uh, but I did hear somebody say that, yeah, the are they going to adopt, you know, I know it's all math, but, um, are they going to adopt something that is new and hasn't been stress tested or battle tested or is it in a family that's well known and therefore this is just a little bit of a variation that that solves a specific issue and therefore there's confidence in that or is this a complete new, you know, new family of ZKPs? It's not a new family. Um, that's EKPS at least. I I don't think so. I think it a lot of the existing um techniques and proofs um are kind of well defined and that's not yeah that's not an area that >> I think we can play. Um >> so yeah um I think what we'll find is that these three categories that we've formed around like the house with no names or the just pairwise versus public um categories. is will be like um gravity to particular types of zero knowledge proof families and groups. So like the public ones we can use the battle tested in um long fellow um CKP that was donated to Linux whereas the um private pairwise ones we may have to use um like a combination of like the noir family and plunk CKPS or snarks um the sort of growth 16. But yeah, then um that's kind of that leads really well into the cookbook conversation or the ZK book conversation being a root of >> where I think this task force's contribution to bringing it all together and then >> allowing people like the Berkeley folks to have like specialized proof that then gets folded into the book. Um and when some when interested in trust graphs arrive uh and start adopting the credentials and discover that CKP's become a given for their use case. Um hopefully they have options but not prescriptions. Um at least Yeah. Thanks. >> Uh, hey there Vicas. How are you? >> Oh, good morning. >> Cool. >> Oh, go ahead. >> No, no, nothing. U, it seems like an interesting discussion going on. Thank you. I had to refresh my memory. You last joined about a month ago, I believe, in August. >> That's right, Scott. >> Cool. I mean, it didn't come from my memory. I cheated. I looked at an old page, but >> I wish I wish I had that in my brain. Uh, great to have you back. >> Yeah, thanks. >> So, um, if we're ready, teeing up the the cookbook and construction records conversation. Uh, in the past couple weeks, Mitchell has taken the cookbook from an idea to something real. Um, it's now a set of construction records in the ZKP spec draft. One board for one board uh row each and 12 so far and the ADR 001 is the first one composed. Uh, so Mitchell, I'll hand it over to you if you'd like to take the screen or otherwise. Yeah, there. Thanks. Okay, here's a familiar spec up T. Um this has had three sort of iterations so far and it has also like a audit system built within it where I kind of check the discussions on um credentials human trust um and a few of the other active repos is um so the this one um so this is still sitting in a pull request. Um, actually let's let's just populate some chat stuff right now. And the branch is oops book branch. So you can build this um using the CK book. And I guess this is kind of me showing what the initial um spec has looked like and where it's come from. So then we can get this to like an initial pull stage or at least cut down a bunch of stuff that's not needed or we find unnecessary for the first CKP spec. Um okay I need to go here. So high level um the abstract describes the purpose of the ZKP task force. It's a specification to implement the ZKPS and create these construction records and it's kind of the book framing. So we can scroll down here. Um but here are the records that I think originate in the liveless root document and also appear in the DTG credentials. So we have like >> which um sorry which um did you share the link of this document? >> Yeah. So this >> the first one has to be um so because this is a spec up it has to be built >> through the um >> branch here >> the zk book branch. >> Okay. >> Um >> okay that's fine. Yeah, but once we pull it in, I think it can um it will live here. >> Mhm. So maybe the rendered spec is on cable. >> Let me see is the one plus. Yeah, I'm not on that. >> Let's see if that work. Yeah, sorry. Yeah. Okay, it's fine. >> I think >> Yeah, I can um >> No, I've I think I've got >> That's fine. >> Give me a second. So, these are the sort of different areas of the spec that it cares about in relation to knowledge. So we need statements, witnesses. The method is the different what they call gadgets. Um in circuits, uh the public inputs tend to be the credentials. Um a disclosure set is like what parts of the credentials are being um shown to the verifier um or the prover. Uh this is kind of like the the uh justification of the boundary around what the proof is or is not. Um there's an adversary connection as well which we included in our original drafting notes and um time is also one adversary in the postquantum sense um which then is why horizon is included as another term. Uh this is answers that question Erica around the different families and what they do um include unlinkability which is a big question around the personhood version construction options. >> Yeah. >> On that gadget is gadget is that a term that's that's well defined in this space? >> Yeah. >> Okay. And a gadget is often so just to provide like an example, it's in the implementation, not in the math of the proof. And a gadget >> is so earlier this year um there was a flaw that was found in one of the um Zcash shielded pools called Sapling. >> Mhm. And that wasn't a flaw in the zero knowledge proof, but it was a flaw in the gadget that was checking information about the proof and providing a um statement saying that this is a unique um like this is a unique ZEC in the pool. So it didn't and that flaw had to be patched very quickly and then they migrated away from that pool because it was kind of like an infinite mint bug. And the reason that that is possible is because in zero knowledge you don't know like all of the checks and receipts within the pool but you have like a encrypted note that you can redeem in and out of the pool. But if a gadget is not recording those correctly in zero knowledge then we have that problem which requires crypto agility. So that's probably one of the most recent >> AI based well was it was a security researcher that used AI so required specific knowledge but sort of vulnerabilities um in uh one of the like most tried and tested zero knowledge um systems that is Ccash and it was a vulnerability in the gadget um which yeah is that term. So um issuance requirements and then the provenence records which I think guys understand um here has sort of the different states of within the repo of these like constructions. So, we have this request list um which I think will eventually live in the git discussions but then hopefully like fold in here. Um I haven't put this in yet but we have the a double1 is a request right and then there'll be another one which is a request. Um the carded is the term that I came up with for um these are the constructions that are a draft for answering that request. Um then the constructions is the actual runtime of the proof um before it runs and then you have the run. And then the vetted is if you guys remember the um ZK mage verification loop where you can run it on your own computer and then provide like a proof that you did the um circuit uh in our group. Um and then we get to published >> and this is the registry. That part up there was the registry that can be uh sort of the auditable registry just to to go back and see that the proofs did their job and there's no problems there. Um so is that on the so here is uh this >> this section is the the registry of kind of like the timeline of the request creation um run and then almost like audit of the the ZK book um within the trust IP ecosystem and kind of like a proposal for how we identify the states of where these proofs are at in the process of us um vetting and then publishing them within this spec. >> Okay. And so a construction record construction record carries a record state. So construction record is how the how the proofs are constructed and >> so what's what's in it >> and this and the record state is for um that's for internal to to okay >> so it's kind of like the governance of this document >> so then this document can create like a timeline of >> um we had this request from uh this project and this was the um construction that we came up with carded is just the draft and constructed is the after we've decided that's cool then we run it then it's vetted um and that creates like a verification loop and then we publish it to this spec and then sort of point the um request from the other trust over IP um like the e ecosystem input >> okay >> in that ction that kind of follows into um nicely to the relationship with other specifications. And this is the comment I made earlier, Eric, around like this pair wise directed and public um sort of trilma or uh like trinity of options that we've come to um in the credentials core spec uh all have specific relationships with the CKP spec. And remind me directed. So pair wise is between two. Directed is one. Um >> yeah so it's kind of um the >> the prover the approver. >> So it's like that mix between where you you can choose to disclose more connect like we would happily we would all have pair wise. >> Yeah. But we would then also disclose this like connection between all of us in the ZKP task force meeting right now. Um but we may not want to disclose that we're in another task force meeting. So it's like that in between the two, >> right? So it is a a um sort of very specific disclosure whereas public there's no you have no choice on who gets to see it. It's just public. >> Yeah. So these are like the community governance decisions of the um credential. >> Yeah. >> Like the shape of the graph, >> right? and that the shape of the graph if a ZKB is what lives on the the edge. So then information doesn't need to um the shape of the graph matters because that defines how many edges we're working with um and how strong the edge needs to be whereas like public the edge doesn't need to be as strong as pair-wise um because there's many more edges um we can't cover everything as public anyway um but we may want to have specific uh relationships that are private initially and then go public which is that sort of directed directionality. >> Okay. >> But everything starts with pairwise in the house with no names. So it's just like you and I, which means that it has to be um like a ZKP on the edge. Otherwise, everyone can see everything. If you and I um if they saw that you and I connected, they could see like the Yeah. >> They would be able to see my did. And if my did also connected with Scott and then my did also connected with Vicas and Sanka Shan and it's that problem. Um yeah. Uh so then this gets into the terminology point which I think is actually the most um productive part of this spec to review and and check and um its definitions. So it's going to help um quite a lot. Uh so this like chain resolve gadget is a gadget that chains like the information of the connection between the verifier and the proverment open gadget. This app for proving a public commitment can post construction is a record. >> So again, these gadgets run within a circuit or are they are they the things that run the circuits? So they're the things that run the circuit or are the thing is the software that either the verifier or the prover >> okay >> needs to um >> okay >> have I think this is alphabetical so there isn't any sort of I'm just going to keep scrolling. If you guys can see, we can stop on one if it needs clarity. Here's our gadget, a reusable circuit fragment. That proves the relation. That's that distinctness that distinctness gadget seems like it would be carrying a lot of weight depending on um if I'm understanding how that would be used. I probably don't. So how would that be used? >> Yeah. So this is useful for the membership VR. Um yeah PMC where you can choose like it's I'm not already in this registry like it's like a uniqueness. >> Um, do you have the inspector gadget? >> Yeah, I I almost said that. >> Sorry. or or a deeper reference have a guy named Penny and Brain or something. >> Maybe we can if we have examples um instead of Alice and Bob. >> Yeah, >> play with that. >> I have not seen that show in like 40 years, but I still know the name of the characters. It's crazy. I only know one >> sun's important too. >> Key binding gadget public key. So these are like little microervices of micro little. So like a construction is like a bicycle and a gadget is like the wheel and the pedals. >> Yeah. Oh, so you have multiple you can have multiple gadgets within a single construction. >> Mhm. But then that's kind of where the families diverge where you then have to do like a if you want to have this unique combination of key binding plus um like a membership proof >> and accommodate different signatures and and different proofs like if you have if you have a construction that has different cat gadgets that rely that need different proofs then you then it starts getting complicated and >> yeah and also not possible. All right. Why not? >> Um, so like some combinations that >> some combinations like the like you have to have a tradeoff um in the information between the verifier and the prover. So you can't just like put all the gadgets into one proof and it works, you know. nullifiers are also widely used. They often sit in most proofs. So this is like I hold the secret but you you can't know the secret. So the nullifier sits on the um prover. So prove that you have this secret without knowing. So the primitive construction is the only the one only gadget instructions. This one's also probably going to get used a lot. Um, this is a range proof. This is the whole like um it can prove I'm over 18 conversation. >> Mhm. long fellows that mostly. >> Yeah, they use that a lot in um improving your your um income >> when you're looking to rent like I can just prove you you make over 10k or whatever. >> Yeah. Yeah, that's actually quite a I guess point in that one. Um especially if yeah we get um like trust graphs that accept taxation records and those sorts of things. This one's unique to Aspec because it relates to that registry system that I established where there's like a an acceptance uh that you don't necessarily need to like review the circuit but as a member of this group by running the circuit um you your computer says that it's okay in I um set up an infrastructure, it's going to work. So, it's just a registry verifier. And I think that that role that actually is a trust task in of itself um that kind of connects the trust task um spec to the ZKP um governance. we spoke about, but this is that um people outside of the ZKP task force can request cards to be created. There's another gadget which is the set membership. So this is relevant to um if I want to prove that I'm part of the Linux kernel maintainers but not which one I am. Um another term that's important is transcripts. So transcripts are um like when you lay all the math out, that's the transcript that then the verifier reads. So the prover creates a transcript that this proof is done all of these gadgets and followed these instructions and it solves. And that transcript is then given to the verifier and the verifier says, "Yep, awkward. Now the proof is um made." >> So right this this is what the verifier gets. Is the transcript. Is it the only thing they get or one of the things they get? Yeah, practically the only thing they get other than the like um API call or the connection between the nodes that information. So then you get this presentation and the verifier challenges the the transcript and if it solves then it's proof. Okay. So that has like a bunch of the terms. I think that this is something that when we have like a new term introduced, we should do as like just a practice in this group. If you guys enjoyed it, um it's quite helpful from my side. Um >> yeah. And how I'm so not a GitHub expert. How would I generate this on my own to be able to review it? >> Yeah. So once we once it's pulled in um it should just live Oh, wrong one. It should just live on this domain. But if you go to the branch the um you can do some AI magic here and say go to the zkbook branch and build the um spec up t locally of this branch >> and then it will build it locally like what mus um I think there's also I think sangan might know a little bit more about this um than I do cuz I'm still getting used to how spec opt work works but um it may already be deployed just at a different branch as a renderer. Um >> so what do you do after you go to the zk book? Um >> so yeah the the zk book branch um >> yeah and then you do what and then This one. >> Oh, okay. >> Yeah. But if you just grab this link and ask cororpt to build the spec upt locally for you, it should be able to do that fairly easily. >> Okay. Um, cool. And what is um what would be what would to to whatever word you use to fold it into the right place. So it is just part of this what needs to be done. >> Uh so it's a pull request. >> Yeah. on the here. It's been mentioned in a couple of the conversations um >> already and I referenced it um in a few task force things and I also updated it cuz this was first pushed a week ago and then I have made some edits over the weekend to this um specific pool. But yeah, once we get that, but I I yeah, I didn't want to just be like this arbitrator that um pulls its own um spec into the root repo. So that's why I did the branch. Um, let me just double check where is there any Scott is there anything that I am going to miss if we continue this path for the next 10 minutes. Um the one thing that I had was calling out um that cross spec linkage and just confir I believe we just want to confirm as a task force that we would own 007 as the construction. Um, there was just a bunch of chatter around that and it felt like we want to decide if we want to own that in this task force. >> Okay. And it's in great spec issue nine. Yes, I think we do own the It's this one. Yes. Yeah. So, I think this is actually solved. Let me find uh SH has a question ADR1 and the specification with the impacted >> I think it's it's kind of linked to what we are discussing right now in terms of how the work of that is in this group is it do we see that as blocking uh the adjacent work or do we see that that they are going to fit some of uh in some sort of a synchronous manner. >> Um >> I'll give you an example. >> Yeah, I think asynchronous is where I'm leaning. Yeah. >> All right. Then I I kind of had the same feeling that the synchronous of what probably is going to happen at this point. Yeah, which is kind of why this spec does have that language littered throughout it which is like this is my proposal for the verification flow of information. This is like how I think we should do the registry system and how we had that thing above. Um this is also another kind of expression of that where the other groups can asynchronously go to this spec and kind of like form their document to the ZKP language and then we can go through in the task force meetings reviewing it and asynchronously um reply and build. Yeah, I think there are two parts that emerge. One is uh the ZKP group is going to get tagged in various implementation or specification details to review or provide input or give shape to things which has been happening since the past 2 3 weeks I guess. The other thing is that the group goes out and looks at what out there in terms of a composite set of specs flows and is able to provide a very considered opinion in terms of where it is sufficient or not sufficient and how it has to be addressed the gaps are going to be addressed. So that's the second part and and I think that's the more involved part where the where things start to get a bit more uh in project management terms into the go no-go zones. So that that's why I just wanted to have the clarification in terms of how the group sees the engagement and the involvement. >> Yeah, I understand. It's a good question. Um so just uh I have started doing that second um part where it's then you sort of observe the whole trust rover IP stack and make inputs rather than just accept at requests. Um and I have this like ZKP board book reader where it kind of gives me ideas of things that I should look at. um some replies that are like requiring things like that to happen. And I actually made a push today in the ZAB task force repo um with this document and then I wasn't sure that was appropriate. So I went back on it um after second thoughts. But I think having a document like this in a standard format could also be um a a good methodology where I can then do some sort of ceremony. So the way that I do the ceremony is um for the different comments and inputs is there's this like link to the open destination. This is a comment on credec 9. Um, this one like I read and I was like, we don't need to make this comment. It's actually solved somewhere else. But just to show you the flow, I say one hand proves two names. Two hands prove one name is the same. And the second is not the first. And that's kind of like a proverbial reading of what this post means. So that's like me doing a mental check. Um, I then copy the approved text, open the destination, and like as I mentioned, I thought that this one is kind of already been solved. Um, and we've had a few comments and back and forth. So, I don't need to post this long thing was my opinion after reading the agentic sort of read of the situation. Um, but if I was to post, I would then post and then I would export this view receipt. Um, and I've been doing these view receipts because I I think that's also like an interesting experiment of trust asks that we can um start giving to over a viable trust agents. So yeah, that's kind of how I've been trying to manage what I think Sangishan you're getting to with your your question of like there's this like this balance um that we're going to need to create um both for us as CKP task force people but also the agents that help us manage this. But yeah, if this is useful, I think I made a post in um the task force discussions. Yeah. This Yeah, Sangashan, if if you want, I can literally just post it. Um, I think the problem that I have with it is like it it struggles with time and it also struggles with um like it obviously doesn't have the specific knowledge of what I know Sanka to be working on or what I know um Jeff is working on. So, it kind of like starts just cherrypicking um stuff that I'm like, "Oh, he already knows the the answer to that." But it just wasn't addressed in that git discussion. Um or something like that. So, I need some refinement around that. But I think that's um yeah, I will stop talking about my little my little agent reader now. Um, back to the agenda. >> Cool. >> Oh, yeah. Okay. So, uh, where I was at was this record seven. Let's just go straight there. Cool. Just need to move your guys faces. See the the index. Okay, it's too fixed this one. No, it's further down. Here we go. So, this would be an example of construction 7, which is that answer to nine, which is common control across identifiers, which is that like I have all these credentials that mean that I'm a part of the kernel. So again, we've got this like key binding gadget being bound by the primitive construction. And the statement for this one is the verify checks. The two identities appearing with credentials um as a subject and issuer are pairwise. So we need a witness We accept two sort of pairways inputs and then we get that transcript. Identifier A's public key or commitment opens to A and identifier B is open to B. Both are equal same issuer. So that sort of pairwise key binding proving common control. So one controller is the disclosure set um the transcript gets disclosed um and the identifiers only as far as the card already discloses them which is not it's just the request. Then we follow that flow of information where it's like does not establish other constructions. We have that adversary on the horizon. Then we have some of our options cross one option running a circuit a circum gadget and then the other option here includes the one that was in the proof of person paper against This is kind of like the recipe. What are the ingredients? >> Yeah, I was going to say it felt like you were going through the cookbook and saying >> this is this is one of the >> here's the ingredients we would take. >> Yeah. >> Yep. And this part here is what gets hopefully it gets hashed away but um it kind of >> Are you intending to share right now? >> Huh? >> Are you sharing are you meaning to share your screen? >> I am sharing my screen on it. >> I don't think No. >> Really? >> Are you I'm on the wrong How did I do that? You are. How did I do? >> Okay. Okay. There's there's multiple tabs in Zoom. >> I freaked out. >> Freaked out. >> Can we Can we erase that from the transcript so I don't sound so dumb? Sorry. Continue. >> Oh, that was um so yeah, this this Providence graph uh early days um it lives here. Hopefully we then just hash this stuff and create this sort of chain of of governance that resolves to the trust graph um in terms of yeah who is responsible and what and I also think that this is helpful when showing people like the Berkeley folks that they um if they contribute their work there's providence written in um to the spec. This was the initial on Friday. So yeah, that was one construction answering 07. Um, and now this is one that you requested, Scott, actually the blinded binder. So I think in the next week if possible um have maybe like a specific like there's two things that I think we need comments on. One is like the structure of this because if we're going to follow this structure it then creates a template. um of like the cards that becomes really this is the recipe statement to people when they come in um format. So, I'd like that to be um scrutinized if possible and then um there's a lot more I guess general education in this spec around. So, right now we're at the constructions part of it. But in the book of ZKPs who jump down here to the bottom, this is actually pulling from both the mapping the paper but also some like independent research. uh that I've been doing. So, it's kind of like the more messy context and research at the bottom that will eventually get removed from the spec, but is useful when we have agents working on it. Um, so it just gives some like a place for me to put those sort of run times because there was a new proof that was actually introduced last week. Um, which is really quite cool. Um but it's for it's mostly for ZK EVM the virtual machines relevant later but um yeah I I want to make sure that we like have that in here even though we're going for the stronger ones we have some research area um and then the cryptographic background is like your one zk brought into the spec as well where it's like what is a zk AP, these are the things that matter. These are the trade-offs that we're always going to be um thinking about or trying to achieve. Um the different types of setups. So you've got the you've got the un uh the universal trusted setup. So this is the the blockchain uh and then the transparent CKS got the non-interactive ones field curves and this is where we start getting some mathematical um definitions into the spec. which is where it all starts getting a little bit too confusing. But I think it's >> Sorry, did you say that's where it starts getting too confusing? >> Speaking for myself. >> Yeah, that's that's so this one's actually fairly okay. Um we're at the end of the timing for the call. Yeah, I this was awesome. Thank you. The one thing I the the one item I just wanted to call out was we will be having um Leif from Ciros Foundation and the WW wallet joining us on the 29th. Um, and we'll be looking to see if we can get some uh developers on the call too just to get at the intersection of some of the they've been running Leif and Cyrus have been running performance tests across major ZKP families and they have some interesting intelligence to share and I I think we'll have good contributions to the the cookbook and these conversations we're having. Um, so that's in motion. Just wanted to call that out. Sweet. That sounds good. >> Yeah. >> Do you think the um prover or guys would attend as well at one point? >> Proverb. What is that? >> That's the the world ZK kit. >> Oh, the prove. Got it. Um >> no, >> I mean I met I met the engineer. He's very kind. I can ask him. Yeah. >> Okay. >> Well, let's start with that one on the 29th and then we can continue to >> Cool. >> have developers in. >> Awesome. >> Great. >> Well, thank you everyone. >> Thanks. >> Thank you. Thanks, Mitchell. >> See you. >> See you later. >> All right. Have a good day.