 All right, welcome everybody to the September 21st hyperledger technical oversight committee call. As you may be aware of you've been on any hyperledger calls before there's two things that we have to abide by the first is the antitrust policy. So it is worthwhile to note that there are a number of different people on the call from potentially different organizations and we need to make sure that we are not participating in any activities that are prohibited under any of the antitrust and competition laws across the world. The second thing that we have to abide by in these meetings is our code of conduct, which is linked in the agenda. In general, just be respectful of others and their ideas and opinions and thoughts. So for announcements today we have the Dev Weekly developer newsletter that goes out each Friday. If you do have anything that you would like to include in that newsletter. Please do leave a comment on the wiki page that is linked in the agenda. The second announcement that we have is that we have a how to create a currency management application and deployed on a hyperledger fabric network workshop, and it is scheduled for October 12. And there is a registration link in the agenda. So if you're interested in attending that please do register for that particular workshop. Any other announcements that anybody would like to make today. Actually, a small announcement from me, since we are switching the way we are conducting the weekly meetings in Eroha. Essentially, I was asked to do an email subscription. So I guess I will share the link in to see if anybody is interested in your letter which will be be weekly as well. Please subscribe in the form I will provide the link for. Okay, thank you so much Victor. Any other announcements. Okay, if there's no other announcements then we'll go on to the quarterly reports. We did get the hyperledger firefly report that came in last week. I think we'll have had a chance to review that and there's been some back and forth on that particular report. But I did want to see if there was any questions that anybody wanted to bring up today on that report. Okay, if you haven't had a chance yet to read the report, please do so. And we'll make sure that we get that one merge in when we either reach everybody having reviewed it or two weeks has passed. All right, for upcoming reports today, we're expecting the base you and the color caliper reports to come in so we'll keep it a lookout with those. We also have the start of the Q4 reports that I've included in here even though they're not due for another couple weeks but I did want to make sure that cat die and fabric that they're quarterly reports for Q4 we're going to be doing due here October 12 so you've got a couple weeks before you have to do that but just an FYI that's coming. Any questions on reports before we move on to the main agenda. Okay, so for discussion items today we have two graduation requests we have the cat die graduation request and we had the firefly graduation request. We'll start with the cat day one since that one came in first and then we'll move on to the firefly one. So, Rama Pete well I guess it's probably Rama you're probably going to present today since Peter's at the airport. Did you want to take over and do that. Can you hear me. Yep, we can hear you just fine. You can see my slides. Yes, we can see your slides. So, before I start, as I mentioned on the discord channel. I uploaded these slides to the TOC issue that Peter created and also open to PR and my pleasure. Okay, so I'm going to run through the different criteria that was outlined in the incubation exit criteria and go through first the mandatory criteria and also then go through some of the other Ancillary attributes of the project and the benefits of the graduation. So, first legal obligations and license things a code is licensed and Apache to and we've combined with this for since the project for open source both cactus and be able to go to the lab. We're covered by Apache to and declared as such. We also have a check configured and this only covers packages and files for entry packages at the point but it does tell you whether at least that part of the code base is covered by Apache to license. You can see this on the main repository page. Community support. I think this is pretty, this is pretty healthy. We have three major companies that are actively maintaining the project in a very collaborative manner. And there's no imbalance between, between them. Everybody is the. Significant significantly to the code and to the peer reviews of the project. Or at least IBM since we, since we were in talks with cactus to most of the project and since then we've had the code contribution from this is just what I counted recently. We have like 75 unique contributors since positive exception. There is a cactus exception and includes the leader. Around 10 to 15 depending on where you draw the line needs a chance contribution. And as I mentioned, quite balanced. We have weekly calls that. We have the calls almost every week. We have the calls. And the recording the program YouTube for everybody to do. There's pretty high volume activity on the Cacti discord channel, especially users and the contributed channels. This is from the stats up from a couple of days ago. And it starts and a very large number of clones and downloads. So, I think this project requires a fair amount of interest. It's also been a popular target for hypergeometease. We have five this year. We had five previous year and two before that. Hopefully, I'll be the strategy. Maybe it'll play to me. We have a unit test covering all configured for all individual packages and modules. We actually go to see the GitHub actions. You see a list of several unit test as well as bunch of indication test and all of them are required for any peer to pass. At this point, we don't have a unified test coverage report, but we are planning to generate one and report the table showing the coverage for each package. But otherwise, with inspection, we can actually see that the code coverage is pretty high and we enforce that for PR. The documentation, so both the cactus and the weaver, then they were separate. They had their own documentation and that is pretty well maintained. And it allowed people to use the build and deploy the packages both through local web server and also it was published to GitHub pages. It contains details of how to set up the system, how to pull the packages, report the packages, install prerequisites, and then run experiments that is end-to-end sample runs. So we are working on an integrated cactus documentation website. So this is there just working on the cleanup at this point. And the PR and working on PR like right at the speed. In fact, let me just show you what this looks like. So this is published at this point to my GitHub account. So you can see this follows the template that the McDonald's template that Tracy had created earlier this year. So we have a bunch of pages. So not all of the pages are completely full, but all the relevant documentation that we had already for the latest cactus and weaver packages and the respective pipelines are all present here. So users won't have any trouble navigating through the repository and getting hands on with the code and the sample. Let's go to the slide. Yeah, and we have copious amounts of documentation. Otherwise, the specification of the cactus site paper, there are a bunch of RSEs covering all the view features as well. The project is well aligned with the Hyperlegion's mission and the goals, the use cases, etc. It is like Acti are well documented and read me as well as by paper and a theme and the tutorial doc. This project was divided to promote and enable the interoperability. Sort of by definition, Acti confirms to and not just focus, but focus, but also augment the Hyperlegion architecture and mission because we imagine you can have two different Hyperlegion systems. Let's say by using the existing DLT stack of the two applications enables them to carry out cross-scene transactions. So in a sense that it both follows the architecture and also augment it. Also, we support non-hyperlegic DLT as well, like Corda, and there's an ongoing work to support Polkadot as well. And in the future, we'll also be using Calipers for performance benchmarking and as a related project, we'll make sure to try to ensure interoperability with Firefly 2. We've been making periodic releases. At present, we have two Alpha 1 and the final two is targeted to be released very soon. And we're using Hyperlegion standard release taxonomy and we have automated pipelines to publish packages in various languages, JavaScript, Go, Java and Rust. That can be triggered by tagging particular commit with the updated version, I believe. The infrastructure, I think, is a lot of content here, but this should be... We fulfilled all of the essential requirements from the get-go, even when projects were labs. So by default, CACTA inherits that infrastructure from the existing code bases. So when CACTA is renamed to CACTI, then all of the different Discord channels that are positive are all renamed and the mailing list is renamed accordingly. The two code bases have been merged and it's quite seamless and we have one common repository location at the point. Of course, maybe we might figure out the split later on, like other projects have. But at this point, it makes sense to keep everything non-depository and we have a common package. The CI pipelines of the projects have been integrated and the packages are all published under a common CACTI namespace and the documentation is updated accordingly. We are making steady progress with the deeper integration which involves eliminating redundant components and merging shared features into one single library and put it in a single package. But that's kind of a longer term activity and we will keep making mental progress in everything. Also, we learned some lessons from the when you're merging the project and you produce and collaborate with the Linux Foundation and Exhaustive Checklist for other project maintainers who may want to merge two projects like this in future. So you can find that in the hyperlisiopathy. The security vulnerability reporting guidelines are in place. The security of the file is being there in the root folder of the CACTI and previously CACTI small story for whatever. And the states, the hyperlisiopathy policy that's largely negated upon, the TOC represents debating and finalizing the new policy and reporting template. And as in when that gets finalized we will state that, we will put that in the main report. And CACTI already has a spark for security reporting, Peter, and he subscribed to the security meeting list and he participates in hyperlisiopathy and security discussions. Menable we have the new policy, we will add extra sparks from the meetings list at that point. We have an open list of best practices which are your combat, calm down, your combat. You're good Rama, go ahead. Okay, so yeah, we have an open list of best practices batch and as you can see, I mean, you'll find this on the, if you go to the CACTI repo, you'll find this at the top of the page. And yeah, as you can see, we check out the criteria. We also, again, having manually looked at the Appalachia TOC best practices, the guide language, Dave let the darking off earlier this year. I think we follow all of the preconditions that stood there. Of course, the TOC can go and check that and corrupt it up and happy to answer any questions about that. So moving on from the, I think this was the last listed mandatory criteria listed that going on to other additional considerations that's been called in the incubation exit criteria document. We have several examples of real-world view. So Fujitsu, as he drew from the call, thanks for joining us, very late in Japan. So Fujitsu, together with ConsenSys, Arc3, and Surinitsu, delivered a POC for a cross-border security settlement system. So demonstrating a security delivery with a payment across permissioned Ethereum, Corda, and IROHA ledgers and used CACTI for that. And several links here, articles talking about this particular POC. In 2021, IBM delivered a POC for the Bank de France and HSBC, creating an experimental CBBC suite of applications that was built under the Digital Zero Initiative, which is something that the Bank de France is very interested in experimenting on. And we demonstrated data sharing and delivery of payment that is the asset soft across the fabric of the Corda ledgers. And as you all know, this was also presented at the CBBC workshop in the last Global Forum in Dublin. There's some new articles and links here. Another experiment or a POC that was talked about in the same forum was the DDP between a capital lab network and a fabric network. And this was demonstrated in Davos earlier and again talked about it in Dublin. Here's the link as well. There's also a usage of various connectors from CACTI in the climate action and accounting sake. This is something that Peter is talking about. So the Corda is built on very modular lines and composable scenario. What that means is that you can build different transaction pipelines and you can pick and choose different modules and different libraries and compose them. And build an end-to-end scenario that way. So this is the selection with modularity. The architecture is based on plugins. We create new plugins for particular narrow scenarios for particular use of particular DLTs as in when we want more extensibility. And to compose any use case, you can select a particular plugin or a set of plugins. This components can all be downloaded and reported directly either from Dr. Herb or from Git, MPM registries or Maven, etc. Or you can build them directly from source as well by doing their possible. And there will be instructions and scripts provided to help any user to do that. Stalability. By design, we have enabled both the legacy cactus design and the lever design. They are built on APIs and modular architecture. So the interoperability is enabled through a combination of REST APIs as well as some applications that are running on existing DLT stacks. If you are connecting a fabric network to the base network or a core network, we are not asking for any modifications in those DLTs. We just run applications that they were designed to by those DLTs designers. And then there are some external components that incur minimal processing overhead and impose very minimal transfer print. We haven't conducted a formal benchmarking study yet, but there is an ongoing mentorship project around benchmarking bridges. And Peter is a mentor on that particular project. And this will be expected help to benchmark cacti components and the end-to-end protocols that are supported. We believe that the framework and toolkit are intrinsically scalable because the APIs are designed to be horizontally scalable. And there are some informal TPS and latency measurements that we conducted on relay modules a couple of years ago when we were doing the benchmark experiment. And it indicated that the relays of the communication between networks were clearly not a bottleneck in any sort of costume scenario. It was the end networks processing time that was at the moment. And cacti is just a glue between different BLT systems which have their own particular scalability challenges which tend to dominate whatever extra modules cacti with them. We are closely involved in aligned with the most prominent standardization efforts in the probability area. Cacti maintainers and contributors have been are actively involved in the interest efforts. The most prominent one is that there is an official IETF working group. This is established in early 2020. That is approved by the IETF's characters to and authorized to draft RFC. And these working groups have somewhat narrow scope which can be expanding as time goes on. So at this point we are engaged in trying to draft protocol to enable the secure transfer of an asset from a network. So this is one of the interoperability scenarios there are those. But we're trying to solve this particular problem standard so it creates a reference for developers. And later we will expand the scope to asset exchangers and other kinds of interoperability scenario. And I am involved in this as well as Raphael Benchio who has been a long time contributor to cactus and cacti. And an early version of this protocol was implemented by Raphael and his colleague Andre. It's the Podap-Pomis plugin. You can see that it's one of the packages that was under cacti. And the latest version of this particular protocol is being implemented in a mentorship project this year. And that's going on right now. It's making good progress. Another standard forum that we're involved in is focused on it's run by a group called Soda Public Money. They call it Soda Interop Group. And it brings together various labor providers and also interoperability solution providers as well as people who are working with standardization. And it's focused on creating high level APIs and advising maybe governmental bodies on the legal regulatory aspect of interoperability. And both Hart and I have been participating in this particular forum. And Hart is not at present a cacti maintainer but as you all know he is one of the co-founders. So also as we are embedded in the ecosystem we are going to be ensuring that the cacti code confirms to all these emerging standards. And also this is the cacti's visibility and value in the community making it sort of go to place for anybody seeking interoperability. Which leads to my final slide. The code is already suitable for production usage and proven by various real world use cases that I talked about a few minutes ago. And gradually it will give enterprises and various DAT providers who are looking for a generic interoperability tool. That if they are not already tied to a particular vendor or a particular solution. They can find a canonical location to look for these tools and also help co-develop for contributing features. And also gives them more confidence in the maturity of the code base. And new contributors should also be more enthusiastic about using and contributing. And we have received some communication interest from some companies. Graduated cacti project can also create a part of a hub of innovation in the interoperability. And also act as a reference for other projects that either are trying to work in the same phase like the you in Hagonia lab. And also in who are interested in how interoperability works like. Okay, thanks. Alright, thanks Rama. Any questions for Rama thoughts on the graduation room. Thanks Tracy thanks for the detailed presentation and it's great to see the community growth and the way you're put forward all the information that we need. Quick observations. Right are probably like few things that might help us would be. I still feel like some of the documentation are referring to older code base. I'm not sure if the documentation is currently updated. That's one thing. And other than that, I really like the way cacti project itself was incubated and then the way cactus project was initially like incubated and then the way we were joined, and then the way white papers were published and the way collaboration happened across. So this is a really good role model an example that the project has set forth forward and all the best with that. Thank you. It would be also taken. I'm sorry. Right and one more thing that might help us would also be not necessarily like needs to be done immediately. In terms of one of the court thing that will one of the comp from within the security domain right one of the thing that we were looking at is putting up a framework through which we can evaluate the risks associated with usage of certain things, and the way with cacti when we talk about interoperability across multiple blockchains. There are certain things that people want to adopt blockchain for, and then those guarantees may have to be looked into from a different perspective, when we choose a common node operator kind of concept. An evaluation like that, eventually in the projects roadmap would help people who want to adopt a project. Sure, I think this is referring a bit to the, I think I alluded to this a bit when I talked about like trust footprints and minimal external components. We can definitely talk about the implications of using cacti on the administration of a particular network and how it will impact the potential network security and how much overhead and we have different ways of enabling that. So you have the, if you look at the division diagram in the cacti, the main page, you can either connect to networks via node server, you can connect them via relays, depending on what your risk kept right is, what your user view requirements are, you can pick a particular particular model, one of them being somewhat bit more centralized, one of them being a bit more decentralized. So, I think, and yeah, we can, we can talk about the, the, you have probably bought this in the past, I think you have written some stuff about it as well. Potentially, we can write like a blog article something that addresses the, and of course we will put that in the documentation as well. The question around. No, Rama, thanks for that. Right, and just the documentation, let's see, I mean, see the project team can update if any of the relevancy can be updated over there. Yeah, in terms of what can be updated. Oh, the documentation I find may not have been updated for a while. I see like older princess of characters and those information. Yeah, we're going to be publishing that documentation. I just showed you a screenshot of what they have, but yeah, just cleaning it up. Thank you. Yeah, thanks. I just want to say, but in Toronto is a strategic area for enterprise. The LT use cases. So really happy to see Apple and you're leading with tech time and excited to see it applying for graduation. That's all thanks. Thank you. Any other thoughts, comments, concerns? Are we ready for a vote? And if we are, can we have a motion and a second motion? Thanks. I'm not supposed to go right. I'm the guy. I'm sorry to ask the question. Are you supposed to vote? Yeah, I think the guy is not supposed to. No, you guys will vote. We just need a second though, before we get to vote. I second. Thanks. Thanks. Sean, will you take us through the boat? Sure thing. In the matter of the hyper ledger cacti graduation. I'm going to call the name of the TOC member. Please respond for. If you're for the motion against, if you're against the motion or abstain. Marcus, how do you vote? Or. Peter, how do you vote? Peter, you muted. All right, I'll jump to somebody else. We'll get to Peter in a second. Jim, how do you vote? It's for. Stephen Cran. How do you vote? For. Bobby, how do you vote? I vote for and Peter left a message in discord that he votes for. Because he's boarding a plane. Okay. Rama, how do you vote? I will do it. Yes. Arun, how do you vote? I vote for. Tracy, how do you vote? For. Okay. On the matter of cacti graduation. Of the TOC members present. We have unanimous for. So congratulations cacti team. Congratulations. All right. So from here, we'll move on to the firefly graduation. So Nico, I don't know if you're the one taking us through this. Thanks. Yeah, I'll be, I'll be the one talk doing the most of the talking today. Thank you, Tracy. Thank you to everyone. I'm going to go ahead and share my screening real quick. I just have a couple of slides to take us through. And then I would like to take a look at the report as well. So. Just, I don't plan on talking for too long and I'm going to try to keep an eye on the time here as we go, but. Can you all see? Okay, great. So basically, I just want to. I want to start off with introducing a couple of our maintainers that we have some new TOC members since the project started. And we also have some new maintainers. And so I want to just do some brief introductions. Some of them are actually here on the call today. I want to provide just a couple of quick. Highlights of the project and some recent changes. Just kind of updates in case people haven't been following the project all the way since the beginning. Real. Very briefly touch the highlights of the proposal that we put together and then leave some time for feedback and discussion afterwards. So that's kind of what I would like to take us through right now. So, first of all, I would like to introduce a couple of our maintainers that we have as we'll see as we get into the proposal and some of the highlights. We have maintainers representing three different companies now on firefly. First we have the node from fidelity and Dennis from one off and each of them has made significant contributions in the blockchain connectors and the blockchain specific protocol code within firefly and plugins within firefly core. Each of them have made significant contributions to the project and wanted to recognize those contributions. Call them out here today and just give them an opportunity to say hi. Just very briefly kind of what area of project they're involved in and just put a name and a voice to the base and to the GitHub handle. So Vinod, I would like to introduce you first. Feel free to say hi real quick. Thank you, Nico. So Vinod Damley has introduced work for fidelity investments being a contributor to Firefly ETH Connect as well as the Firefly Sino projects and looking to continue being actively involved following all the progress and the outside contributions that Firefly is receiving day in and day out. That's it for me. Thank you. Thank you so much Vinod. And next I'd like to introduce Dennis. So Dennis has been the key developer on a brand new blockchain connector for Firefly, the Tezos Connect blockchain connector. And he's been working on that connector and the corresponding Firefly core plugin that have both been recently added to the code base and I just wanted to give him a chance to say hi to everyone here as he's relatively new to the project. And so Dennis, glad to have you here today as well. Thanks, Nico. Hello everyone. I'm Dennis, software engineer at Instinctals since recently my tenure of the Firefly. One of currently working with one of company on implementation of the Tezos Connector for Firefly. In our opinion, Firefly is a great project which allows to increase development speed and easily send and manage transactions for different chains. That's why we chose it to use for integration of Firefly application with various chains. Glad to be here. Thanks. Awesome. Thank you, Dennis. Just a couple of quick highlights before we go through the proposal in case you haven't been following the project since the beginning. Firefly has been an incubating project since September 2021. So we're almost exactly two years now. It is up to over because this doesn't include the new connector that was just contributed 752,000 lines of code spread across 20 repositories. It's so many repositories because it's a very modular and pluggable microservice architecture. So there are some shared libraries and there are many different microservices that can be combined and composed in different ways. Over the course of the history of the project, we've had 245 unique contributors, 84 of those being unique code committers to the project, and we now have 12 maintainers representing three different companies. We have a very active community and discord community calls, Github. And the discord channel is like literally every morning when I wake up, there's five questions from five different people waiting for me there about how to use Firefly or somebody with an idea or a question. And it's just, it's super exciting to see the level of engagement on a recent community call. A new community member joined and said, hey, I heard about Firefly. It looks really interesting. It's really exciting to see the community contribute. And that was last week, I believe, and they've already had code merged into the project now. So just super exciting to see the continued growth and continued acceleration of that growth. There's strong global adoption in enterprise production use cases. This is something we're just really proud of. Just the number of companies that have seen the value proposition of Firefly and are using it in the future. And given some of these, kind of the recent changes in maintainership and just the continued growth and acceleration of the project in the community, we feel like now is the right time to come forward for moving to the next stage from an incubating project to a graduated project. And so I want to just real briefly walk through the proposal. I don't have this in slide form, but I have the proposal here and I'm not going to go through it and read it out. The TOC has had a chance to read it and kind of has thoughts or questions on it that we can discuss afterward. We've got some great feedback on the PR already, some of which I've tried to comment on there and some of which I think this is a great venue to discuss here today. So some of this I've already covered is kind of the background. Many of the requirements here are just sort of checkbox requirements that just have to be there because they're just a hybrid ledger and those were many of these were satisfied back when Firefly first moved even into labs or from labs into incubation as well. So I'm not going to spend a ton of time just rehashing all of that stuff. Some of the some of the highlights though that I'd like to touch on is just as I've talked about for the very active community, the active community calls, the Discord channel and it's actually been overwhelming in a good way the number of pull requests that we've had from from different community members across all the different repos and I love seeing it. It's great just seeing people like seeing areas where the project can be improved or they can just jump in and provide value and I'm just really, really excited about that. We've had, as I said, 84 different independent committers that have moved into the project and this is a key area now that we have maintainers from three different organizations and I know there were some questions about this particular topic and I plan to discuss that a little bit in detail. Tracy and others had questions about sort of this the idea of this maintainer pipeline that we discussed here in the proposal and I'm going to show a picture of that in detail here in just a little bit. But in terms of other aspects of kind of areas that need to be considered in the project test coverage, Firefly is in really good shape. We have very high standards for test coverage. All of the critical path code in Firefly Core shared libraries, the transaction manager library, transaction manager-based connectors all of these are very high standards for test coverage. There may be some individual repos that are kind of on the edges that don't have 100% test coverage. They do have tests and there's a very robust comprehensive end-to-end test suite that runs as a part of every pull request and runs out against a live running system. I won't spend too much time on that. It's really interesting to look at. The doc site has a lot of documentation on it. I'll actually just pop over there real quick just to walk you through a couple of the pages because some of the other things in the proposal talk about architecture is how this fits into the broader hyperledger picture as well. So we really see Firefly as it's not a DLT, it's not a blockchain, it's a platform to accelerate the development of blockchain powered apps. So it provides APIs, it provides these technologies that Web2 developers are used to using like HTTP REST APIs and WebSockets and makes those readily available to access things that are traditionally more challenging to develop against like blockchain nodes. So Firefly is this middleware layer that sits in between your DLT and provides lots of the really important but also really difficult to get exactly right plumbing pieces that connect both the chain and off chain storage and provide a robust, durable event bus to connect your application to all of these things. I don't want to spend too much time talking about what Firefly is because I hope by this point everyone is familiar with it, but just one of the highlight that if you're not familiar with it one of the requirements is having good documentation and I feel like we have some excellent documentation that you can go and learn about what Firefly is, all the different pieces that are inside it how the blockchain connector framework works, how that works with Firefly Core and how this makes it easy to extend the hyperledger Firefly architecture with new blockchain connectors like Dennis has done recently with the Tezos Connect connector and use this framework to rapidly build that new connector. So there's lots of great pages in there to look at if you're interested. I don't want to spend a ton of time walking through all the docs though. In terms of alignment and integration with other projects even Rahm touched on it will be great to see even more collaboration between Cacti and Firefly in the future. We absolutely agree and the question often comes up like hey it looks like both Firefly and Cacti are interop projects which one should I use and we see them both being very complimentary where Cacti focuses on sort of the on chain interop between different blockchains and being able to link the chains specifically Firefly's focus is while it does let you connect to multiple blockchains at the same time its focus is a little more broad in being a common platform, an open source platform that can be a standard for development of Web3 apps which can most certainly be used with Cacti to directly connect those two chains together for instance would be one really interesting use case. Additionally Hyperledger Firefly comes with connectors that are both compatible and heavily tested with Hyperledger Bezu and Hyperledger Fabric it ships with the Firefly CLI comes with options out of the box to spin up simple networks either a Bezu network or a Fabric network on your local machine and makes it really easy to get started with using both Firefly and Bezu or both Firefly and Fabric together locally on a dead machine. A bunch more just kind of checkbox items here in the proposal we have a passing open SSF best practices badge I think the other thing that I really wanted to touch on here though was the requirement of sufficient real-world use and I think this is an area that Firefly really shines in I won't read all the details here but Firefly is in production in use by tons of different companies this is just a small list of some examples of ones that we can talk about here today but we see several different consortiums that represent many different companies in different market segments such as healthcare, insurance, finance and all kinds of things like that so we have Synaptic Health Alliance the Institute's risk stream the SWIFT did a CBBC sandbox CGI Federal DFCRC one of has launched an NFT marketplace with WarnerMedia that was recently demoed on a community call with Firefly a send bit and lag chain have all built things that are in production on Firefly today and there's more to the list goes on so this is like I said just something that we're really excited about just to see the level of adoption and both the number of companies and the wide variety of companies that are using Firefly and have embraced the value of it there's some more comments here on testing and performance and those sorts of things but that's kind of the main things that I wanted to walk through on the proposal I did want to just very specifically address some of the feedback that was left on the proposal particularly around maintainer diversity and there was a specific question if there's a requirement in the exit criteria that I can actually just scroll to it here today see that there's no single company or entity that's vital to the success of the project and there's concern that if Kaleido were to not be involved in the project with the project still live on we believe that the community is in a very healthy state we believe that there are enough companies and enough people that are both using Firefly both engaged in the project in the community and contributing code and maintaining code now that if any one particular company were to step away from the project the project would live on and it would still be able to be successful we feel confident the community is at that point and it's ready to move forward I'm going to point out that the empirical measurable requirement that's stated here three legally independent committers we do meet that requirement so we believe we meet minimum here and we also are confident of the more subjective requirement as to a single company being vital to the success of the project we believe that we have sufficient diversity within the project today we're confident that that is going to continue increasing we're excited about our maintainer pipeline and the number of companies that we have in that pipeline Tracy asked about what does that look like and what are some of the companies in it this is a snapshot of that starting on the right we have the three companies that are currently maintaining Firefly and one of being the most recent example of a company that just is kind of like the textbook case of moving through the pipeline seeing Fireflies seeing yep that's the solution I need for my project building a new connector for it contributing that back to the open source project and then becoming a maintainer moving a little more toward the left we have lots of different companies that are engaged in the community and have either made contributions or have expressed interest in making contributions including code contributions and potentially even maintainers in the future moving further to the left just a list again of just examples of companies that are using Firefly there are many more and many of these are crime consortiums of companies as well and sort of thinking about anybody that's using Firefly is a potential candidate for moving through this pipeline and becoming a maintainer at some point hopefully the more they're investing in using the project they're considering investing in contributing back to it and one day maintaining it as well so I'd like to wrap things up there I know we're running short on time and I'll leave a little bit of time for questions feedback or comments that people may have but thank you for letting me just walk through that and kind of laying out kind of where we're at in the project right now and our vision for continuing to move forward thanks any questions comments concerns Arun? Thanks Tracy thank you for the presentation and thank you also for answering much more questions in a separate call scheduling that and following through all those it's great to see the progress the Firefly team has had and one of the things that I keep quoting everywhere is the way the positivity that team carries the Firefly team carries and I've seen this from the time of first proposal and the way project team took the feedback from the team back then TSC and then went through the lab process and then did set up the community calls have been part of some of those calls at least initially I used to be regular onto those calls and it's just great to see the way progress the project has made the progress just to understand some part of it again I'm not currently that familiar with the latest update so and I believe I also asked you this question in the separate call can you reassure or confirm the license part that wasn't one of the open question back then with the EVM part of it I believe sure yeah there was a question way back when we were considering moving into labs around licensing around an Ethereum a Go Ethereum specific library that was used by one of the oldest code bases that was donated as part of the project there was work back then but I believe before the project even moved into labs to remove the dependency on that library and bring in some other code and bring in code in a different manner that made the hyper ledger code base and the hyper ledger repo patchy to compliance and we're not bringing in the GPL library that was previously required before the code was donated to hyper ledger thank you sure Bobby yeah I just have to say to reiterate a little bit of what Arun had just said with the welcoming nature of the Firefly community they are always willing to listen to new business cases new contributors just the way they go above and beyond coming to calls inviting people to their calls it definitely is a great example of what a community should look like so thank you thank you Bobby I appreciate that thanks Bobby other questions comments concerns I would like to bring one up if nobody else has one so alright so I think the work that Firefly has been doing is great the number of adopters thank you so much for presenting that pipeline I think that's a really interesting view into what may come for Manehainers and those sorts of things but it would be if I didn't bring up the comment that was in the chat about the number of Manehainers from Kaleido and the question I guess I have or maybe it's more of a comment but there's a concern that I specifically have with a number of our projects not just Firefly that are maintained by a single organization or have a majority of Manehainers from a single organization in that there's sometimes a challenge that exists and having those other Manehainers voices heard when it's very easy for that single organization that has the majority of Manehainers to basically override the voices of those other Manehainers and so obviously we have other projects that are graduating in the state already but I do want to make sure that the Firefly community is thinking about this and looking for ways to change this as we move forward because I think it's so important for everybody's voices to be heard and for the community to allow for those single voices if you will. So I guess it's not necessarily a question but it is just something to point out and something to be thinking about moving forward. So Jim I saw you raise your hand probably in response to that. Yeah definitely Tracy having lived through this experience since the very early days of Hyperledger I definitely know what you mean and this is something I've been telling the team that to build a proper community sometimes we just have to slow down by doing all the communications all the decisions or architecture discussions not within laws, right? But it's something that we we're not 100% of course we're also used to describing people in their decisions but this is something that's on the top of our head because to build a strong community you have to do it this way. There's no other way so yeah definitely appreciate that feedback and it's something we've been striving to do for a while and hopefully the recent additions of new committers is a testament to that practice. Great thanks Jim we have like 5 seconds left any comments, questions can we, are we ready to vote? I'll make a motion for Firefly to move to graduated status. Bobby thank you. Seconded? I think that was Steven Thank you for that Sean. Cool we'll do this quick I will call your name please announce whether you are for against or abstaining to vote in the matter of Firefly graduation Arun how do you vote? I vote for it. For Rama how do you vote? Bobby how do you vote? For Steven how do you vote? For Jim how do you vote? For Peter Marcus how do you vote? Tracy how do you vote? Yeah I vote for Peter also voted for in the chat so we can count that as well. I will count that as well that is unanimous of the attending TOC members on Firefly graduation I'm sorry unanimous decision to graduate Firefly to move Firefly to graduate status. Great thank you so much and thank you Nico thank you my task there you go throw the hats in the air thank you all so much alright thanks everybody sorry for running along we will talk again next week thank you everybody have a great day bye thank you bye thanks