 Since Dimash is on I suggest we put that first Okay, I can do a couple logistic things first just the hackfest planning an internship program update and then we'll have the borough proposal Q&A on GSL as well as the project tiering discussion So really quickly on the Hackfest side of things April 24th and 25th DC area I'm dropping the link into the chat window right now if you are attending. Please get registered as soon as possible Also, we have a draft agenda started Thank you to those that have been populating some suggested topics in there anything else. Please get it slotted in We'll get those all sorted out at the beginning of day one there on the internship program front On the update is we're working to finalize who the six interns will be We're working to close on that by the end of next week and get everything kicked off So we're in touch with all the mentors there and they're reviewing the proposals right now Any questions? Yes I mean, I mean, how is it going? Do you do did we get many candidates? Yeah Really well. There was fantastic response. There are around 40 people 40 students that applied for the program. So we're really happy with that To fill six slots. So really good diverse set of candidates across geographies and Interests as well That's great. Thanks. Yep Alright So Chris next up we have the borough proposal slotted I don't know if you want to do that or move to the GSL just since we're not at quorum quite yet Yeah, I wanted to give to much because we deferred him for like a month I think and yep, we keep running the clock and so I think the right thing to do is to give to much You know, maybe a couple of minutes to sort of refresh everyone's memory on the GSL Discussion and I think that you know at the end of his last presentation that there were still some remaining questions So I think this is the opportunity then to To discuss those so to Mars. Do you want to sort of recap the that the You know the prior discussion and then we can open it up for questions Yes, thank you So, thank you for this opportunity I I think that you or the I Presentation first of first a guide paper about the GSL where we introduced the concept and then or presentation on the GSL of how we think that this would Fit into an enterprise environment and especially in financial services and how this would be a very generic utility that we think is probably of interest also besides for industry and The while I did this presentation. I received quite a few questions and The to the chat but since we were at the end of the session I could not answer them and therefore choose to Collect those questions and give their the answers to them in writing the Maybe I just resend that document again to the the developers to the TSE this people that don't have to Search for it So the first question was where I can find the previous paper Instead of me recapping. I think it's best if you just refer to that You find you find the link on our website and this is The question that Q&A Q&A I just made The next question was is the GSL intended to replace parts of existing projects or a complementary project Or is is this a complementary project? We think that really GSL is a concept that is that decouples certain functionality out of existing platforms and It is it is part of an architecture. So the design of the GSL can be here can be hierarchical it is It basically creates an interoperability in the sense of Harvey structure a platform and also it is a tool of interoperability potentially as an eventually between Distributed ledgers or even generic Traditional ledgers The next question was does the GSL replace the ordering service of fabric or is it paralleled? Or is it a parallel commitment log Well, the concept of the GSL doesn't really Cover the the algorithms that I use to sequence transactions Actually could it could use hyper ledger fabrics It could also use In the next next question somebody asked it could also be used to implement a cordless notary service The next question was is there more information the cryptographic nature of the notification that we implemented? if you remember the GSL had Function of not only evidencing Contracts, but also a notifying parties That that notification that notification is done using Cryptographic primitives that ensure that is the notification is only understood by those who are concerned and For everybody else it looks like Random data and this notification mechanism is what the question was is based on our computation out of a shared secret between Sender of the notification and the recipient of notification. This is a well-known algorithm to derive a shared secret in an elliptic curve cryptography and We just use that to Tain and are And to create an offline protocol so an acrobat of a code that doesn't need a code An online cooperation of sender receiver, but just the fact that the sender knows the public youth recipient he can create a Shared secret and then use the shared secret to derive a sequence and notification tokens that are then distributed in the lecture The next question was Yeah, I just wanted if you could remind those of us that they're right in your paper probably a couple months ago Which notification that is that you're referring to? the Defined of a function of the GSL the capability to notify parties involved in a transaction Since we said that the GSL is evidencing Evidence in contracts or transactions Which are not Interpreted by the GSL but are interpreted by a high-level layer this means that Those who are connected to those participants who are connected to the GSL could then Basically need an additional Means of being notified that there is a contract that is that they are concerned that that they are involved in So they are because the the evidence itself doesn't carry any information on the GSL level of the contract and that notification mechanism is That I refer to and that is that we implement using that shared secret The next question was with the distributed ledger reference model that we promised released to the architecture of white paper work Certainly, that's that's our goal that we create this first draft and circulate and collect input from from major framework Also projects from external to hyper ledger before releasing it to a wider community, but it is We hope that this reference model can be validated by Mapping it to existing frameworks and if we if we manage that that could be a great confirmation And that's that's that's why this pre or step pre or step of validation on existence frameworks But yes, we will definitely do this The next question was whether we are proposing to We are proposing to create a Project with it or it will be incubated inside the hyper ledger. Well, we We don't know yet. If we don't do that yet to be precise at this time We are We are discussing this idea with vendors clients and then figure out if there is really an interest for such an independent project and the community deception of this reference model will definitely Influence that decision, but it makes sense to start such a project within hyper ledger I think these were the questions I received and if you have any additional Please Go on. I take this as no Then we can proceed in that game. Thank you very much. Okay. Thanks to much So next up is borrowed are we quarry? Yeah, yeah, we're at quorum now And then I think that Silas or Benjamin One of you want to share your screen I can give your presenter, right? Yeah Yeah, this is Benjamin. Yes, please start. I would be perfect. Okay one second. All right Let me know if this works if I go full screen Yep All right Well, first of all, thank you very much hyper ledger community the TSC We recently joined Hyper ledger as a general member and we're very Enthusiastic to propose the code base that we have Which we've dubbed hyper ledger borrow as a project proposal now to hyper ledger steering committee So a quick overview of what I'll briefly discuss I don't want to take too much of your time So so I'll briefly talk across what is borough which was formerly called RSDB And I'll give a bit of motivation and history of Monax why we built it and also why we're making this proposal I'll give a high level overview on the solution of what is the actual code base and I'll go from there Into how do we think that this can be valuable to the hyper ledger? community and other hyper ledger projects And then I'll try to leave time for questions So I'll try to not go in too much depth But if you have questions and also please feel free to ask them while or afterwards during the presentation So what is borough? It was formerly called RSDB part of the errors platform We think of borough as the permission smart contract machine. It is a full distributed ledger We've worked over the years to make it modular and Importantly it has a permission smart contract interpreter on top of it. This interpreter is built to the Ethereum Sorry It's built to the specification of the Ethereum virtual machine I don't know where I'm getting an echo from but It's muted now. Sorry about that. All right. Yeah, also a colleague opened a laptop So I was thinking was internal on our side. Sorry. And so it's carrying Picking back up the thread. So so importantly it has a smart contract interpreter That we've always built from the start in accordance to the Ethereum virtual machine specification so that allows us to leverage as much of the tooling from the active Ethereum community in Specifically the compilers and solidity coding language So code that is compiled with solidity will also run on on our Ethereum virtual machine and Then for the consensus engine we've worked closely with Tendement consensus, which provides us transaction finality and fully cryptographically signed BFT consensus So very recently in part in preparation for this proposal We've moved as a version 016 the code base from GPL 3 to Apache 2.0 And and that's a new step in its existence. So it has been remodeled and we an updated and improved over many years now since 2014 So this is a new chapter for for this code base But why have we built it this permission smart contract machine for us? The reason has always been on business value Optimization across the default chain For this we've felt that it's important that you have a very strong deterministic smart contract execution So that there's always a fully verifiable trace of all the transactions that have happened As a legal engineering company we put permissions first to observe both legal And and commercial constraints and so I'm highlighting those two points because I think that they will correspond to technical parts of the borough Code base that we think are potentially viable or valuable to the larger hyperledger project As a case in point, there is an older blog post where we wrote smart contract networks Which just so happened to currently reside on blockchains aren't immensely useful to Which really Hopefully brings down the point that we're interested in the higher level Application logic for for this wider range of technologies that is vastly evolving Um And so so as a company we built several things so we built industry specific legally engineered smart contract as the case We also provide blockchain as a service where where we help enterprises set up their pocs or production systems Um, but on the open source side, we built the monax platform So a large part of that is development tooling and it's important to Make it clear that this is not what we're proposing. Um, those libraries are g lp3 licensed But the full distributed ledger with the permissioned ethereum virtual machine Um, it's now a patchy license and this is part of the proposal to the hyper ledger technical steering committee So trying to move a bit on At a very high level borough can be seen As a stack of four major components at the very top the highest level of abstraction Is this permissioned ethereum virtual machine that is both stateless and it consumes an application state interface What we feed it into is a specific smart contract application engine Which Adds a new feature to to the ethereum virtual machine namely we have secure native functions From which we can derive a permission layer The ability that this gives us is that we have a sort of a super user ability that that Restrains what smart contracts can do inside the application so you can draw some analogy to to an operating system where Not all Actions are permitted Those layers themselves are abstracted out by The application blockchain interface and then as I mentioned Tenement is the consensus engine we run on and so that is A dependency of borough But the interesting point to us Is how would we look to build new value being part of the hyper ledger project? and so on the left side, I Put forward some points that I think are interesting to consider So at the highest level the permissioned ethereum is a stateless Piece of code that will transition state and so that can Quite nicely be thought of as well as a transaction processor in sawtooth or as chain code in fabric Then I've highlighted that we are interested in in this permissioning layer from legal compliance and legal engineering So there is an interest for us to to harmonize the permissioning layer across different distributed ledgers And hopefully we can bring some expertise to this field as well And then finally all the way down on the consensus engine We are not tied to any consensus engine So we've built this application blockchain interface to as much as possible abstract those two components out And it would be interesting to look at supporting proof of elapsed time there as well So bringing down this point we've always aimed at building or enabling ecosystem applications And for that purpose we've built tools and we've never tried to to set standards So we've Allowed tendermen to become its own standard or we've worked with the ethereum virtual with the ethereum community to To not introduce or compete on those standards and in the same sense It is interesting for us now to to look with other hyper ledger projects and work groups To really see whether we can have the permission devm run as an application engine on on different distributed ledger technologies Like I mentioned harmonizing this permissioning layer that we think is crucial for enterprise purposes There are obviously also questions But this might be ahead of time where we are like can we standardize or come together on network genesis and runtime configuration? And then there is some very interesting work also with sawtooth leap the transaction families that they have there So can we harmonize on standardize on transaction format? Or even rpc standardization where that might be applicable So a final note just tanking especially also dan middleton from intel and the whole sawtooth team for for interesting discussions so far and also for advising on in these early steps inside the hyper ledger community um Tanking casey my apologies. I should have Apologize for casey wanted to be here, but he Is on a flight to the u.s. So he couldn't make it um And then finally Well, obviously my team and silas is specific, but finally also um, andrea's throwing from tata consulting They have built on our platform And built their own platform in a larger extent and and over the past half years We've had interesting technical discussions and internal proposals on how to Uh build significant new features. And so they have expressed interest By the way, that was awesome. I also talked to casey. I don't are you guys going to be at the hackfest in dc on the 24 25 This is jonathan speaking Have I lost audio? Um, no, I don't know. Can you hear me? Uh, yes, but who am I talking to? It's jonathan levy. Uh, I don't know if you guys are going to be at the hackfest in Like next monthly in dc But I put I put some an item there that we can start playing with more collaboration like cross project kind of Collaboration try to do some hyper ledger with different consensus in kind of fabric or hyper ledger with You know, like sometimes something that combines a few projects So I don't know. It's gonna be nice to play with it. I lost the connection We must have lost the connection with uh Either yeah, I think this is silas speaking. I think we've had a bit of a problem I've just reloaded and um, I think we're back on sorry Could whoever was speaking last just to repeat the last couple of sentences for us Yes, sure. Sorry. I didn't know if you guys are gonna come I talked to casey before Ben and I was trying to see if you like it's gonna be interesting to try to play With some cross project integration like you suggested To try to play with sawtooth to try to look at prior to try to kind of combine Kind of a workflow that going through fabric, you know Tend to me. I don't know to try to combine some of this stuff. We can play with these ideas but yeah Yeah The one in dc I'll post a link on the chat This is uh, April 24th and 25th. Yeah Thanks. Sorry for the connection. I also don't know what happened, but I should be back online Twice now, I think that one sharing the screen one the audio So I I hope nothing fell out of the the Short presentation, but if you have any questions or if I should pick it up back from Got caught out Then please let me know Benjamin or how communities this is William. Have a quick question. Hello Yes, of course Um, Benjamin, is there any work being done with the rootstock? Um, in that in that relationship there? Um, no, no, we do not explicitly collaborate with rootstock. Um I I am aware that they move to the ethereum virtual machine as well. Is that correct? But um No, no, there's no collaboration Okay, just just asking just interested because I'm I'm I'm in touch with some some people the rootstock and It's interesting to know that if they are moving to ethereum virtual machine versus and at the same time parallel Waiting for segway and all the other progress that's being done in bitcoin Yeah, um, definitely and and I think this is in some sense Significant in the sense that there are not that many ethereum virtual machine implementations out there Um, and for better or worse, I think this is the first one licensed apache 2.0. So so it will Um enable easier collaboration on The ethereum virtual machine and at least that is also our hope for for the relicensing that we've done Great, but thanks for it You're welcome. Hi, this is vipin. Since you brought up the ethereum virtual machine, what is going to be? The relationship between you and the ethereum enterprise alliance and how does it Jive with your incubation in hyper ledger Um, so that's a very interesting question. Uh, and and we have a deliberate Um intention here namely that one we are a member of the ethereum Enterprise ethereum alliance um as we are also a member of the hyper ledger community now and Our interpretation is that the enterprise ethereum alliance is predominantly Right now it is playing the role for a standardization body for ethereum. Um, so With that, I think we can bridge the two communities and at least Especially for hyper ledger itself allow for a gateway into the enterprise ethereum Alliance, which currently is debating what the new standard should be But at the same time there exists Um An ethereum implementation that is part of both Now well not yet. Sorry I'm just to add to that. Um One of our one of our encourage Um, um Of the ethereum standard. So, uh, standardizing around the EVM On its own would be of interest to us Did we lose the connection? No I don't know. We can hear you. We hear you another question for you from vipin Could you go into, uh Some detail about the whole permissioning thing because, uh You had suggested that that could become a, uh Layer or an idea that would bind all of the different DLTs in under the hyper ledger umbrella Uh, yeah, definitely. And so so a lot of the, um I will all of the current, uh DLTs if I'm not mistaken are already permissioned DLTs What we've done specifically with the ethereum virtual machine and why it's referred to on the slides and in the proposal as a permissioned Ethereum virtual machine is that contrary to the public ethereum Uh, virtual machine implementations that exist We at every execution step Check for the permissions of the account Um before executing any steps. So so we will return additional errors If permissions are not observed, um, we've done this explicitly in the execution of the EVM Um, but the general concept is that it is important to have, um Certain operations that cannot be restricted, um, only By by by managerial accounts or allowed by managerial accounts um We so and so the general concept that we have there is our secure native functions, which are, um Implemented natively in the blockchain Um, but can be exposed to the smart contract layer um essentially through through a pointer contract um But they they are very different from the public ethereum where all where the permission list Um is provided for by the availability of of cryptocurrency to spend And so we don't have cryptocurrency Um inside the logic of our borough blockchain client Rather, we use the permissions to restrict certain actions on the network and others um What shape that Permissioning layer eventually takes across multiple Um blockchain clients is to me unknown But I think it is very important or or very useful at least from our perspective Um to to to have some standardization or some reflection on on what that would mean If you want to connect different types of technologies together for example It's maybe interesting for these permissions to to be able to carry over as well So if you're uh, if you're checking with every, uh, not every action, but Some significant actions. Does it, um Slow down, I mean have you observed the That there's a degradation in performance or is it? I mean what kind of um, so so these These checks are natively implemented And and there's no significant overhead on on checking these permissions The the permissions state is also just stored in the account state So for all loaded accounts, it's it's equivalent to read from the contract storage or to read its permission. So there's no significant, um overhead there So I I tend to think of permissioning in in two different kind of orthogonal ways. One is What nodes on the network are allowed to publish blocks? And I think that's maybe a very common way of thinking of permissioning. Who's who's admitted to the network? In a sense being able to to publish updates to the network And then there's the the kind of permissioning of what kind of transaction from a client perspective Is allowed more than rules on that kind of transaction Uh, so the the permissioning layer that that you're providing here affects that that first kind of Who's allowed to publish blocks on the network Goes in in borrowed two ways. So it extends Upwards into the application of what a transaction can execute But it is also Implemented downwards into the consensus engine and specifically for tendermint. We only have known part this known validators That sign off cryptographically And for them to bond a stake before they can start Exercising that voting power that they've bonded They need to have the permission to bond that stake. Um, so that is an additional restriction on who can commence Validating blocks as well Thanks, and then you would also be able to control that then with the with the transaction. So it's in in the sawtooth system we do that with Kind of admission transaction for what make it originally Advertised as the endpoint registry and we now call a validator registry, but it's essentially a table in that shared database It says who a valid Who a valid validator is Do it that same kind of Yeah, so so we both have the explicit transactions to bond which Are only valid if you have the permission to bond and That then will allow you to start validating who are the validators is stored in a specific section of the Patricia tree So that there's also a miracle proof of who is validating at what points in In the chain So in other words embedded in the blockchain itself, uh, so So there is a seamless view here. It's not an orthogonal view in other words Both the validators and the transactors are uh, sort of addressed in similar manner Is that correct or is is it my misunderstanding? That is correct. Um with the exception that we have a separate, um Patricia state of the root tree of the miracle tree that that registers also Additionally who are the validators? Um, and so that information is twice in in the In the full tree in the sense that they are also present as it comes in the system That might not have an answer. Sorry. Oh, sorry Did them was on or can I change gears for just a second? um, well, so before you go nick, um, so I want to make sure that we're not just sort of going, you know deep into, you know, what I would call a main coal Main coal is a rat hole that just it's a nicer place to be um, and um, that was bad Well, this is So I think I mean, this is all really interesting conversation and discussion and you know getting into the technical weeds But I don't know that that's really what we're here to review I think what we're really here to review is that the nature of the proposal, you know Are there going to be enough people around to to work on this? Is there interest in collaborating across all of those things have been sort of outlined here and I'm wondering if we should You know, I mean we can take some of this stuff offline and have conversations in chat or an email um, as we want to go deeper into the specifics of how it's implemented, but um, I think that You know, we should try and keep the The conversation up level where we're really focusing on Uh on the proposal itself and not on the technology. Does that make sense? Yeah, in fact the question that I was going to ask was You know, um, can you tell me a little bit about the community? Um, that's using this how mature is the technology? um so Where where do you stand on on use and maturity and How broad is your kind of contributor base right now? um, so the user base, um as an open source projects Starts of course, uh are predominantly I think startups um in in the sense that It's a free open source permission platform for them to work with Um, but that obviously from the commercial side is extended Um by both the the public partnerships that we have Which are Deloitte pwce y and with dose and eccentric Cognizant sorry, I'm getting business feedback here. Um And and the the partners that we've built projects with um Which are both uh commercial banks, um and other interest insurance companies Yeah, I'm getting a fee here And some logistics companies. So sorry for the fake answer. Um, but I'm getting fed this life um Uh, but then so so so that is our focus group, right? We were obviously In this game for the commercial uh market But we feel that this is technology that needs to be built in an open source non Not owned by by one company and so we've never aimed to to own this technology But we've always seen it as a need that it needed to exist And so the mid the whole blockchain technology itself is maturing And this is also why I think that that we're very Um Enthusiastic about the maturity and the fast growth of the hyper ledger community Is because we do not want to be the main maintainer of this code base and so far that has been the case We like I mentioned, we are very grateful for Andreas And and his group at tata consulting who have provided Technical discussions on on a regular basis. Um, but so far the code maintenance has been predominantly on our basis um And that is obviously something that that we would want to see change So as I understand it The code basis is something in the order of three three years old. Is that what what I saw in the in the proposal That you've been working on this for about three years. Yeah End of 2014 is when when it started And there are multiple pilot deployments that you have Um based on it Yeah, yeah, we we have multiple deployments. Um As of 2015, I think it was mid 2015. We started deploying this And and it's far from perfect and it has grown a lot, but There are components that we are think think provide a specific value Which I've highlighted is the ethereum virtual machine Other components have we have spin off spin off in in tendermint, for example Um But the whole distributed ledger as a whole is our current workhorse Um But it is not our intention to to be sitting on this code base or to keep it in the Current form that it has so so that's why We've also emphasized the the the possibilities of interacting with other hyper ledger projects here And one of the things that drove particularly early adoption was the quality of the tooling and the fact that um spinning up Different types of distributed services and running chains was it's not perfect with our tooling, but It's a lot easier than it than it certainly was um early on Uh, so there's maturity around our user base with quite a lot of deployments Um, but we'd like to see a lot more significant Uh meaningful contributions to the core code, which is which is why we're interested in joining Thank you jonathan for uh supporting us there in the chat is um Is Tendermint collaborating with you as well So so we definitely on a developer level work very closely with tendermint Their code base is also Apache 2.0 and already was So we have that as a dependency But it is not where we think the real value and the distributed space really lies In the sense that the value comes from the application that runs on it It is a requirement, of course, which is why we've helped build it But it is not where you produce the actual value And so tendermint is its own legal entity But as as developers were on frequent contact And just one more thing that um on the details just um, I know you did the license conversion Um, are you comfortable with the Apache 2.0 license? and then The legitimacy of the conversion of licenses on it Do you mean, uh, whether we we we've did you get all of them? All our yeah. Yeah. So so both are um investors and for uh for our Venture capital investors we've had these documents already So the work was quite light, but we've we've matured that everything Um is indeed compatible with the Apache 2.0 License that we now have and and the full dependency list has been searched Yes, and also all contributors all lines of code um are checked off Um and for two contributors that contributed as non-employees While uh, it was still gpl p3. We have explicit signed I don't know what the legal term is but things that say that they're okay with that Brian are you have you looked at are you comfortable with the licensing at this point? I have uh Not not scrutinized the code. I mean that's something we can do during the incubation process early on We have a license scanning uh tools as well That we could we could bring to bear earlier if we wanted to um so uh No, we we do even a more thorough check, but uh, I'm comfortable that Monax has taken the due diligence Uh required for this. I brought it up early and they reassured and we've all been through the the c++ Relicensing attempts as well. So I think I think they are appropriately focused on it What I haven't also looked at is dependencies. It does sound like tenderment of the pass the license Which is great. I didn't know if there are any others in there, but that's something else we can check Okay, so um in looking at the proposal. That was my biggest concern. So Yeah, so yeah, and it since it was uh, probably a common concern. I did take a look. I didn't Individually look at every single file, but I did kind of spot check around. So Uh, right at least looked at it. I think Uh, yeah, and I think that that's something that we You know, we probably should do and I don't know if we want to defer any kind of a vote or We want to vote and just make it Um, you know predicated on the license again and so forth. I think um You know, again, my concern was sort of what Mick had originally Outlined in terms of community and I'm only on my phone and so I can't I I'm unable to sort of get a look How many community contributors do you have? Roughly, I see there's about a thousand Commits In the heiress stp repo But I I couldn't derive on the phone how many individuals said, you know Well, it's looking looking directly at github. It's 11. Um, I'd say that's uh Yeah, that's that's a pretty shallow tail though. So I mean, we've had a few pretty useful bug fixes and contributions But we've had for example No major architectural feature Editions from people who haven't at some point been working with eris monax Okay, so this is honor speaking In keeping with the questioning on, you know, how much collaboration can we really expect here? And you know, don't take this as adversarial by any means. I mean, I think, you know This has been raised by several people on the tsc calls lately is you know, we keep getting these projects and we always Imagine the kind of cross pollination or integration We could work on and then the reality is it's not always easy to get it done And so my question is, you know, so you listed in your presentation several possible integration points Which, you know, sounds very interesting But so are you personally actually interested in this? In other words with monax take advantage of having You know EVM on so tooth or Poet on, you know integrated with any of this I mean, what's your level of motivation? Do you actually have a stake in having these integrations happen or is it just yeah, it would be interesting to do I I can share a few points. I think but I will maybe leave one to Dan specifically we are Legitimately interested One argument that I can present for that is that we are a Small startup that still has to watch its resources that it's been and so far we we have Always built the the open source platform as a cost sync It has been there as a necessity to enable our actual product And so so we have a very strong incentive to Uh Use more mature more funded stronger platforms where they are possible Um The points where we look to collaborate is where we think that it enables us to continue pushing our product Which is legally engineered smart contracts. Um, and we are more agnostic to to the actual distributed ledger that it runs on Um, so we definitely have that as a strong motivation um with permission from Dan One of the reasons that he is on the co-sponsor I mentioned as a co-sponsor is because we've had Um, very interesting early discussions already Um on how we could with minimal effort look to for example run the permission to evm as a transaction Um processor on top of sort with permission ledger So as much as I can prove this by just speaking. Yes, we are definitely motivated to To take these points seriously. They're not light heartedly put on on the presentation All right. Thank you Yeah, I can I can uh support what uh benjamin was saying there that uh when uh, I think it was brian probably first Uh suggested the possibility of of monax contributing Borough, I guess before it was even quite called borough a couple weeks ago uh Reached out and started looking where it would make sense to you know, where would this plug in Into the hyper ledger family and it seemed like there was a potential coupling on the apis that we've created recently for Transaction processing logic, which could include in this case an evm Hey, hey, this is morali from ddcc So just for to clarify or get an understanding, right? So some of the projects that Initially came into hyper ledger I thought at the incubation phase You could have certain level of contribution from maximum participants But it is at that incubation stage where you gain attention from other contributors And once you gain a lot of contributors from external entities, that's what matures you to the next level So isn't that the case that We should allow these ideas to Seed or You know have some incubation time for other teams or other Contributors to stick it out This is bright. It is it is true that the incubation period of time is a time for us to Draw other developers in and and build that case that it is a viable freestanding You know communities So so our threshold at this point should be is there a likelihood of developing that? Is it being bootstrapped with the right attitude? And enough of a critical mass to at least get to a second stage But I I feel pretty confident that as this comes in It will bring other developers from the ethereum community to it And and we can be opportunistic about the collaboration between it and other projects And I've heard the right messaging from the developers at note x and the right intent So I think that's a large part of what we might want to base our our decision on Right and I brian. I've actually heard the saying from Andrew and from joe. So, you know, I suspect that if this You know if we approve it that there is likely that you know, they may contribute some of that as well Do we still have quorum? Away from the end. So just wondering if we wanted to try to take a vote It looks like yeah, it's quite good before we start losing people Yep, are we everybody? Yep. All right. So running through the list, uh, arno Yes, chris, uh, yes, dan Yes heart Yes, mick Yes, morali Richard Yes, tamash Yes, all right. Uh, that's unanimous, uh, that's proofed All right, congratulations guys and thanks for Thank you very much The only other topic was around the, uh, projectarian structure top levels Of sub projects. I know we don't have time to dive too far into that, but if you guys just wanted to do a quick, uh Update or rehash still brian or chris Yeah, so there's there's been a lot of discussion on the mailing list The the last set of notes that I saw from arno and dan and heart and a couple of others. I think We're largely plus ones Uh, brian, I think you're Kind of the odd man out at this point because I haven't heard I'm ending it. I apologize for this morning. I haven't seen it if there's anything on the list but I think you were Not necessarily in the boat and but I haven't seen a response I'd like to continue the conversation on list. Um, I didn't yeah, that's what I thought That's what I thought the one I didn't get the same sense I was the only one kind of expressing the desire for the flat hierarchy which I think is is Kind of was kind of my main point was These projects should be treated equally and our focus should be on the community and the health of the community around them and Gatewaying one project through another from a governance perspective seem wrong. And maybe I was misreading hearts, but let me Maybe process. I think okay, so it's it's good You said that because I think you are misreading because I think everybody is basically saying the same thing that they're all But that they They sort of agree that there are some things that are dependencies and they agree to sort of take those Concerns and so forth under advisement and the tsc If we feel that there hasn't been enough of that sort of Discussion and and and so forth that we can sort of send it back and say hey go talk to those guys because You're sort of taking a dependency or you're you're building on top and you want to make sure you're aligned. So I think we're all saying the same thing, but Then then what the yeah, I had read uh, brian's notice is saying flat But I think something that's probably started to get lost as the thread continues is some other um Kind of unofficial criteria or hard to quantify criteria about what's What makes what is the substantive level that makes something be a project? right Yeah, there was some of that and then I think there was definitely the marketing thing and I think that You know, we need to work with dan and greg and and so forth on the The marketing aspect because I I can certainly appreciate From the hyper ledger perspective. How do you talk about the reason about these things to An external community isn't plugged in and and so that I definitely you know agree. We need to figure out So the one thing that Sorry, one thing that I was just going to inject in here is that as we change the roles And the relationships between the projects one thing that has to be clarified is what are the expectations for the tsc That was my biggest concern coming out of there and going well going into this Was that we are expanding the scope of the number of projects which makes it harder and harder for the tsc to Evaluate kind of Technical contributions that are a part of that so being clear about what the expectations are for the tsc For understanding also has to be exposed in this Okay Okay, all right. Thanks everyone and we'll chat at you all next week. Thanks for the good discussion Thank you