Welcome everybody to another edition of the Helium community call. As usual we'll give a day few minutes as folks trickle in appreciate how many people here are volunteering their time or squeezing this into their workday so always want to give a small buffer for folks to be able to
come on and Join. We're gonna give it a couple more minutes as I'm seeing the audience number keeps ticking
up hope everybody is having a lovely Wednesday wherever you are in the world
and just looking for my note takers here Kenan and good bear making sure that we've got notes and that we are
ready for recording when we get started looks like alright, audio recording is already in progress. So
kind of get things a little bit up and running here. So welcome everybody. This is the May 2022 Helium community call welcome. As always, this meeting is recorded. So bear that in mind if you prefer not to speak on audio, we can use the voice chat text. So counting on a couple of our community managers to keep an eye on that. We'll try to incorporate the questions per topic. JM asking when dad jokes I should definitely have a couple of since I've got two over here and I'm not sleeping enough to have them at the ready right
now. But I'm open to them if anybody wants to tell him
Park I know you're in here somewhere How does a penguin build its house? That's JM I'm on the edge of my seat I'm waiting for I'm waiting for the answer and then we're gonna start this agenda
Okay, leave me hanging glues it together all. hashCode does not approve. Alright. Let's get things underway. We're five minutes in from the top of the hour. Thank you everybody for joining the May 2020 Helium committee call.
Jamie unfortunately will not be able to join us as he is off on other personal matters so you get me this month. As usual, keep to our pyrogen as best as possible, we'll leave room for constructive discussion, budget in force and around q&a. And we actually don't I don't think we have a completely full agenda. And we've got a couple of minutes to spare. So we'll keep tight on time. If we have the opportunity to go back and revisit any of the topics. Certainly, we'll try our best to do so. But as usually, we'll try our best to keep to the agenda, keep things organized, and make sure everybody has their
opportunity to speak. So with that in mind, unless there's anything else, I'll take another quick look at voice chat text,
if there's anything else that I see a couple questions coming in from Keith, our looks like we can adjust that on the hit 53 update. And then a question that may come in. Yeah, I think we can address both those within the agenda. Thank you for the submission. All right. On that note, let's kick things off. First thing we have on the agenda. Jeremy, I believe you are giving the formerly mock now MCC manufacturing Compliance Committee. So Jeremy, if you're here, I cannot find you in the list. But if you want to come on, stop, there we go. I think we can just make myself a member the stage Hey, good morning, everyone, or Kate, we are an international group. So happy day or night, whatever the case may be. So the giving guys an update from the MCC, that is the manufacturers Compliance Committee. The big news was we have a new committee member, John Richardson, you might know John on Discord as JR voice. And John joins us with a background in RF and network systems. And he's worked on projects, with VHF and UHF and those are, you know, wonderful radio terms. And these systems do for search and rescue and deployed microwave links. He's really interested in connectivity, resilience in that role. And you know, his experience and enthusiasm in RF design and performance mean that was really only a matter of time before he found Helium. This is John's bio, by the way, I'm paraphrasing from it. So all mistakes are due to my pronunciation and misery that John had a hotspot in November of 2021. She's actually pretty recently. And he's been learning about Helium ever since then. So in general, the MCC is always excited to welcome new members, the committee and there is a link where you can apply to be a member, we're looking people with all sorts of different experience that link is here in the agenda doc, on the very first page of you'll see it under MCC application, MCC member application form. So we're really do would like to have more members, you know, everybody from the community is encouraged. This is a community effort of the MCC. And it's a big part of our community and how we make this one wonderful network. So wonderful. So I think that's it for now and it back to you. Got Perfect, thank you so much generally, and welcome to our newest MCC member, again, echo that though, you know, we want to make sure we have diverse points of view and opinions obviously backgrounds that benefit everything on MCC with radio, anything Telecom, you know, certainly still want to make sure people are contributing on the crypto security side as well. So eager to see that committee continue to grow. Thank you, Jeremy. Next up, we've got Clarissa from the Foundation team with a grant program updates. So welcome, Clarissa.
Yes. Hi. Thank you, Scott. A lot has happened since our last call. And I'm excited to share a few highlights with everybody here. I'll start with a bit of an ecosystem update as we're continuing to support initiatives in open source IOT communities, and excited to spread the word about the grant program at consensus in Austin in a few weeks. So if you're attending that conference or stopping by the Helium House event, please come and say hi, yeah, come Come see the team. We've also seen quite a bit of development come through the grants program recently, so several grantees hit major milestones, but I wanted to specifically call out Kelly and GLAAD for wrapping up his project. With the support of grant funding. Kelly generated the maps that the blockchain consults to determine which frequency plan your hotspot should use. We love to see impactful work like this come directly from members of the community. So great work, Kelly. We've also recently accepted a number of new grant projects including another project from the team at crypto balloon for an open source As hosting management platform, this grant, this team is going to work on building an open source hosting platform that's easy to run, easy to extend and fully featured. This will allow individuals providing new valuable coverage to the network to have access to the tools they need to run burgeoning fleets. Our team at the foundation is pushing for more community tooling, especially open source solutions that the larger community can build on top of so excited to see how that grant project shapes up. I also wanted to give a big shout out to Helium geek a new team for the grant program that just won their grant this week, as a few of us in the Helium community have experience sometimes a new hotspot host sets up their very first hotspot with less than optimal location, antenna gain and other key factors, which affects their earnings and the earnings of their network neighbors. So this team is building a free and public communication platform to connect hotspot owners who wants to improve the quality of the network by collaborating to optimize the hotspot setup process. We have quite a few more exciting grant projects to share. But I'll have to keep you all in suspense while we get agreement signed. In the meantime, we are accepting new proposals to the grant project. And we have streamlined the process of applying for grants. So it only takes 20 to 30 minutes to submit an idea to our team, I'm going to post a link to our quick pitch submission form in the chat, so that you can take a look and maybe submit an idea or share the link to someone who has a great idea. Last but not least, I just wanted to say thank you so much to everyone who's contributed to making this grant program such a supportive place with amazing projects and, and supporting members of the community. That's it for grants.
Thank you, Clarissa. I know there's a couple more updates that are going to be coming down the pipe. So some other exciting things as far as new projects and some new kind of educational tools about the nature of the grant program itself. So I'm looking forward to it and excited for the community to see a lot of these things. Ah, and then as far as I think it also just came up, yes, Helium house at consensus in Austin. Coming up in just a couple of weeks. I looks like I did include the link in voice chat text, take a look. I think that that may be pretty close to capacity. So you know, certainly reach out if you haven't recently. And we can see we can do. I'm not the one who can give the go ahead and accommodating. But I will leave that with other folks. And we can kind of coordinate from there. And yes, that will be live students that will be available to hold committee. So if you are not able to make it from different parts of the world, we want to make sure we can certainly share a lot of the exciting announcements and activity that's going to be happening. All right. Next up, let's actually start with. So I know we got a couple of things here. So hashCode, why don't we start with light hotspots first, and then we can talk about the 51 after that works for you. Yeah, definitely. Can you hear me? Yep, go for it.
All right. I know a lot of the folks in the community had been paying attention to the announcements channel on the current status of how things are going with the light hotspot launch, there's been a ton of changes that were really appreciate the makers, the validator operators and hotspot owners, and everyone for both their patients and all the updates that they've been making. It's been really kind of awesome to see how everyone's sort of been supportive of this change. And, as everyone knows, you know, light hotspots is what allows us to scale to, you know, to millions of hotspots, right? We're only we're barely under under a million here. And then we really want to have coverage everywhere in the world, not just for LoRaWAN but also for 5g and other networks as well. And so I wanted to just give just a quick update on where we are today. You know, the last night, the core team released a change to hotspot firmware to try to address a bug, really configuration and a bug that we found through a community member actually. And then we sort of confirmed that it was a is definitely an improvement that would help a lot of hotspots. So that was taken up by we think about 70% of hotspots that are out there. At least that's our rough estimation based on makers who have sort of explicitly told us that they've updated the other things that are happening today. There is a set of performance variables that we can now activate now that validators, routers, Blockchain nodes, ETL, you know, all the sorts of different kinds of chain following components in the network. Now that they've all upgraded and had enough time and notice to upgrade, we can sort of activate those performance variables that should improve some of the block production times and validation times. And that'll allow us to do things like increase the the POC rate, and make sure that all POC activity is being recorded. And then the other thing, other major change, that's also going to be activated also, hopefully, today is the activation of h three 2x, which is HIP 54. And that should also have that'll have two advantages. One, it'll improve targeting. So this is how a hotspot gets selected to be weakened, to start beaconing. And then it also actually have some performance improvements as well, that come with smaller than the other performance changes that we're making today. But, you know, still, you know, we'll eke out as much performance as we can here. So we'll take it. Yeah, those are, those are the rough updates from from my hotspots, you know, happy to answer questions as a drop in chat. But, you know, again, really want to thank the community for, for working through
working through this with us. Thank you, that's good. I'm looking, I don't see any questions that are coming into this check. Anything that's the ordinary or not. So I think, as I see anything, nope, I can move right on to the next topic. And again, keep your eyes every other date, as you know, has been frequently posted in discord under announcements, you can see further updates online, it's best to keep in touch with what's going on. Next bit is a HIP 51 update. So first, I want to kind of at least cover from a foundation perspective. You know, there's been discussion on the topic for months, we've covered this across multiple community calls, we've hosted a couple amas in the matter. I'm personally incredibly excited about it. And so we believe that there is at this stage, adequate code and adequate implementation designed for us to move forward with a vote. So we're looking for, we're going to be kicking off the vote, targeting on Friday of this week, we'll have that run for 10 days to leave room for any other discussion around it and review. But I do want to pass it back to ash code to talk about some more those details of what you can expect on Friday, since there'll be some deliverables around the proposal that will be available.
Yeah, a couple of updates here. So HIP 51, this morning, actually late last night, and this morning, where we're making updates to the HIP, to really kind of map out what implementation of it would look like, you know, I think it's, you know, I want to acknowledge that the HIP is is large, right, it's got a lot of components to it introduces a lot of ideas. Some that, you know, some folks in this community may not be familiar with, like, you know, vote escrow locked tokens, and how that leads into governance, you know, that these are, these are things that are, you know, we've seen in other in other networks and other communities, we, you know, and so the the authors, we've sort of proposed a couple a lot of different ideas. That said, it's, you know, as a, you know, on the on the core team, like, we obviously want to paste this out, we don't think BIGBANG releases are great. We want to learn from past experience that we've had, of course, and we want to phase this out appropriately. And so there is some, some edits that there are some edits that are coming this morning, it's already actually in a PR, we're going to make some language changes to try to make it a little more understandable, and landed as part of the HIP. And then at that point, we think that HIP 51 Is, is ready for a vote, we've also started to as a core team, we've started to look at implementing this, some folks in the community have already pointed out that there's some PRs open, or at least, being worked on that sort of think about this idea of sub networks idea of new tokens on our existing chain. And we think that's probably the fastest way to get to a goal that I know a lot of people in the community have, which is how does 5g hotspot, you know, start to earn for their 5g side of things, you know, the, the freedom five hotspots that are out there, already earned for LoRaWAN because they're dual mining, or they're, they're the ability to do mine essentially. But, you know, we want to make sure that they're earning for the, for the 5g side of things, both for data transfer and you know, for a future version of proof of coverage. So, that's, that's what we've started on and hopefully by the end of the week will let us open up some fishbowl channels so you can see the development work being done actively. And yeah, that's that's our update right now, the other update from the technical side. The other update from the education side is that we really do want to sort of back to my point earlier, lots of new concepts. We're hoping to land some, some educational material for folks in the community to sort of get the get the, you know, maybe the ELI-5 version of what is what's, what's HIP-51. All about. And that's something we're also looking to lend.
Yep. And that has been a lot of discussion on having some more materials to kind of cover off, whether you're kind of more technical and been diving more deeply into HIP or just looking to understand a high level. It's a very exciting development for scalability. So I want to make sure that everyone, depending on their background, is able to digest this and understand conceptually at whatever level they are comfortable with. Just to clarify a couple of things. So this, this would be a binding vote. Again, the notion that there is sufficient code for review, we believe we can move forward this as a binding vote. So based on the pool good, effectively had go and move in this direction. HIP 52 and 53 are not up for a vote, again, with some of the more recent changes to HIP 53 that we are going to cover a couple of agenda items down today. Want to make sure, again, we give that the same amount of treatment as we have to make sure folks understand this questions and that digests are there. But stay tuned for more details, but you can expect the vote to go up this week. All right. Thank you, hashcode. Just quickly see if there's any other sessions that are coming in here.
So we can continue to keep moving on. See if we can get HBaguette up on stage. As we have a new HIP that's been submitted. This is I believe, 61. So HBaguette. If you are here. There we can see there we go. Get you up on stage here.
Hi, can everyone hear me? I can hear you. Welcome. Okay, perfect. Thank you. So my proposal addresses one of the major issues with the Helium network at the moment, besides flatlining, that is, which is spoofing. So real quick for the few people who don't know what spoofing is, is basically when a bunch of hotspots are all installed in the same room, in the basement, the bedroom or whatever, and they only witness each other, so they don't contribute in any way to the network. They don't increase the coverage of the network. And yet they earn plenty of HNT because the network doesn't actually know where they are. So unfortunately, now there is not much to address the problem. There's nothing stopping this practice from big to possible, there is the denialist, which is filled with some of these hotspots. But the denialist is far from being perfect. Hotspots need to be added manually to the denialist, which means that many of these spoofing hotspots will earn plenty of HNT before they actually end up on the denialist. And that is only for those who do end up on the list, which I believe most spoofing hotspots don't and therefore keep earning HNT. Another proposal that has been deployed recently to keep some people from cheating. The system is the one that invalidates witnesses, over 100 kilometers away, which in most cases, I believe doesn't do much to address that problem. It doesn't address the heart of the problem. So what can you do to address it? Well, my first idea was pretty simple. It was to outright invalidate all witnesses that share their IP address with either the beacon or another witness. Since these spoofing hotspots are all in the same room, they are also most likely connected to the same internet connection and therefore share the same external IP address. And while this solution may have indeed the potential to put a stop to this spoofing practice, it does come with a heavy drawback. You see as there there are hotspots that are that are participating in the network and that are 100% Legit, that still do share the same external IP address. The most obvious ones are those on the same internet connection, while still over 300 meters apart. There are also hotspots owned by a single person and spread all over town that were put willingly on the same VPN by their owner for practical reasons. Although one could argue that if it's not actually necessary for the benefit of the network, we could ask these people to find another way. But the one important case that I hadn't thought of before as Can you hear on Discord? And I want to thank digerati for letting me know about this is the case of hotspots using CGNAT connections and sharing the same IP, even though they are not, they don't belong to the same person. So basically, without going too deep into the technical details, most importantly, because I don't know them myself, it's a technology that basically has several devices sharing the same IP address, even though they are not owned by the same person. It's mostly used for mobile phones, meaning that hotspots connected to the internet through mobile phones, or other CGNAT routers, most definitely share their external IP address with other hotspots. And if they witness each other, with my first very simple proposal, these witnesses would be invalidated because they share the same IP. And I'm not sure that would be very fair, even though I don't know how many of these legitimate hotspots would be affected. And I'm pretty sure that would affect more spoofers, then legit and hotspots, that's not fair to them. So I connect with an other proposal a little more complex, that still affects spoofers. without causing these legit hotspots from losing their awards. It is still using this basic IP checking principle. But it allows legitimate hotspots to earn rewards in certain specific conditions. So in my proposal, a witness that shares its external IP address with either the beacon or another witness of that beacon, is called an irregular witness. That's just a word I use, it doesn't mean that it's invalid, not yet. It's just what I used to describe them. So basically, the idea is that for a particular beaconing event, an irregular witness is only considered valid, if it is matched with a valid witness is the balance with a valid witness in the same beaconing event. So imagine a beacon that had several witnesses, if there are say, for for irregular witnesses, these irregular witnesses will only be considered valid. If the same beacon also has at least four valid witnesses that do not share their IP address with with others. If we can say I has fewer valid witnesses than irregular witnesses, then not all irregular witnesses can be considered valid. If it has only three valid witnesses, then there can be only three irregular witnesses that be that are considered valid.
This works better than simply invalidating all irregular witnesses like I described earlier. And that it's much it's much more fair to honest miners. So if we go back to that particular case of CGNAT connected hotspots, sharing the same IP address and witnessing the same beacon with this proposal, as long as there are not isolated. If there are other legit hotspots in their area not sharing their IP with another end of the city, and the beacon is witnessed by some of these, then the mere presence of these valid witnesses will be enough to balance the irregular witnesses and make them valid as well. This is much more fair, and it doesn't keep as many honest miners from earning rewards while still affecting spoofing miners is the only case in which these honest hotspots sharing the same IP would be denied their rewards. If they are part of an isolated cluster of hotspots all sharing the same IP is probably it's probably extremely rare. But it can definitely happen that a group of hotspots sharing an IP connected to the same mobile internet provider and not attempting to cheat the system are too isolated from the rest of the network to be balanced by nearby valid witnesses. However, a few things to solve that. First, these cases, as I said, probably quite rare and enhanced to say but sacrificing these honest miners in order to put an end to spoofing is possibly in the best interest of the network. But even then, these rare cases are not necessarily lost causes, there are solutions for them to keep earning rewards. So the first solution and most complicated one would be to simply change location or setup, they can try to get closer to the nearest hotspot, not sharing the IP in order for them to balance their irregular status and be considered valid. This is not the most practical solution however, especially for people hosting their miners at home for hotspots that are being hosted in other people's houses. It's definitely feasible you just have just have someone else host your hotspots in a in an area that has more advantages. But for for people sending up their money at home, it's really not feasible. Another way to improve your setup without changing a location would be to get a better antenna or to get the antenna higher and again, that way you might be able to reach a witness as a beacon, you might be able to reach a witness in another cluster of hotspots that does not share your same IP and which will allow you to do validate irregularly irregular witnesses in your cluster. The second solution that comes to mind and that is probably much more feasible is to simply change their internet provider it's definitely more feasible. That way they will no longer share their IP with other hotspots in their cluster. And the irregular status should be displayed in the Helium explorer, allowing hotspot owners to know that their hotspot tends to be an irregular witness. And that will allow them to know that something should be done, like changing their internet provider. The third and last solution that I've thought of, and it's probably the best in the best interest of the kilometric, it's to simply and it's only doing that it's to simply encourage the installation of new hotspots in their area, preferably not sharing their IP obviously. First, it will increase the rewards for two reason. One, these new valid hotspots would balance their irregular status and allow them to earn rewards like they already do today. And to if the cluster only has few spots, which is probably the case since we are talking about isolated cluster of hotspots all sharing the same IP, then the increase in number of witnesses in the vicinity would also increase the rewards earned with beginning events. But the most important aspect of that solution is that it will increase the coverage of the Helium network, which is the whole point of proof of coverage in the first place. So not only does the proposal fight, spoofing, which is a huge problem, but it also encourages the spread of networks coverage in remote areas where irregulars witnesses cannot be balanced enough to be considered valid. Although, once again, this situation is to be quite rare as it's it's very improbable to have a cluster of hotspot isolated from the rest of the world and sharing the same IP. And that's it for my for my proposal, if have any questions.
Wonderful, no, thank you for giving the perspective on that, you know, from again, foundation perspective, certainly a very high priority to reduce spoofing through a whole host of approaches, you know, obviously, we've got the denylist, that's now active on the network like that the POC working group has kind of become the de facto body for anyone who wants to spend the extra time or really dive deeper on anything related to you know, anti gaming, spoofing and really just maintain the highest level of network integrity possible. That group analyzes, you know, both for submissions for the denial list. And also certainly keeping manufacturers honest, we actually do have another agenda item here today. More on kind of manufacturer accountability as well. There's a number of different points that came up here. hashCode, if you're still around, just to kind of give a perspective on some of the other work that's been done in this area to kind of speak to the proposal here.
Okay, yeah. Yeah, there's,
there's a bunch of sort of comments out there. I think it's, it's important. First one thing I said in chat, but I want to just reiterate, invoice is luck, like HIPs can come from anyone in the community, it is important for us to give people space to explore new ideas for the network, especially if they're sort of spending the time to frame it in an argument. That's like something that can be shareable to everyone as a HIP. So you know, I just want to be very, very, like, explicit about this publicly, that it is important that we sort of give people space for this kind of conversation. The second thing, you know, around IP address, I think I think there's, there's like work to be done here. There's already this notion of a Bloom filter that's on, the challenge is used to figure out and sort of correlate IP address between. Between like, sort of the challenger, challengee and the witness, that's some work that's maybe worthwhile to look at, before this HIP lens from PR to, to a sort of more formal proposal for discussion. And definitely, like, you know, POC discussion channel is a good place to chat about that, and how the Bloom filter works today. And like, you know, what kind of modifications that can be made to that. On IPs, itself, there's been some comments in the community around how, you know, IP addresses can change, for depending on the ISP with CGNAT, there's some comments around like, you know, the variation of agricultural settings, meeting, a different kind of IP setup. You know, as we move to light hotspots, you know, these, a lot of these sort of off grid setups, Will, it's sort of more viable to use those things, especially using cellular or satellite as a backhaul. And so we'll probably need to consider what that means from from an IP address perspective. And ultimately, like the validator is the one that's receiving witness receipts today. And it's their perspective of the IP address this sort of inbound IP address, that's going to be evaluated right on chain. So, you know, I think all these things are worthwhile to talk about, you know, probably a good idea to, you know, take this draft into, into the POC discussion channel, iterate on it a little bit, and sort of, you know, talk through the different ideas that are already out there.
That'd be my feedback.
Yeah, I think that's probably the best forum for further discussion is kind of socializing it within that group and then Submitting appropriately as you know whether that's with modifications as HIP 61. But no appreciate the input on this, again, anything that's related to reducing spoofing and boosting network integrity with getting rid of any sort of gaming errors here. We'll be having more than supporting on that the better. So open to multiple points of view, but just want to make sure we understand the implications. And if we're actually having a material.
Yeah, well, thank you for having me. I'm glad to be participating. I'll definitely talk about it and think about it more and submit an update if necessary. Thank you.
Okay. Well, I have a couple of folks from that POC working group to get in touch with you, as well.
All right, perfect.
Excellent. Thank you. Thank you have a good day. You as well. All right, next on the agenda. Sticking with the same theme, let's bring jerm back up on stage. As we have a new proposal around this has been kind of circling for a while. But the new proposal around a token lock for manufacturing and fleet. Managers, Jeremy, do you want to kick things off?
I have basically a PDF here of the proposed HIP and hasn't been committed to the repository yet for other people. Just the I wonder if I can shoot well, we can't really do video. So I will just read it out loud. Describe it. And hey hashc0de has a very good point pasting it there. It's big. I could probably do it with good old nitro see happens here on voice chat text, find that that looks like That's right. It's pasted as a txt file. And oh, my goodness, that is hard to read. So I'm going to step you through it. So this is a proposed HIP. This is a no code HIP. But it is still important here. Because what we're doing here is asking the community if they approve a policy that we in the MCC would like to adopt, right? So this doesn't really affect the blockchain. It's really a straw poll are really asking the community are you behind this if we adopted this procedure to force manufacturers to place deposits this way? And tribunal which we've already somewhat established for governing manufacture behavior? Would they support it? And if so, we would officially make this a policy and go through the steps of it. So what is well, we're calling it vendor HNT lockup. And the idea here is to one way to combat gaming at a large scale is that type of gaming, which is enacted by the manufacturers of hotspots, we of course, never want to see that. But it's something that manufacturers can, and as we've seen before probably have done in some cases, and it's hard to control, because although we have the ability to do the denylist, it's not quite central yet, you know, it's not really rather, on the final form we'd like it to have, and really suspect that the denylist over time is going to be a little bit slow to react to things. And this is really a way of combating what can be rapid movement on a manufacturer because their ability to add hotspots to the chain, they can do at a much faster pace than anybody else because they're given once they are approved, kind of in control their own onboarding, and can add keys, hotspot keys to be on boarded as rapidly as they can possibly tolerate. So this is a scheme to help counteract the powers that they have. And we simply require that each manufacturer has to deposit tokens HNT into an escrow account of sorts, that is controlled by a third party and have to deposit these tokens in the rate at which they're onboarding. If they fail to deposit the tokens at the appropriate rate, we revoke their maker keys so they can't onboard to the chain. It's a way of stopping them there. And the other side of this is that this deposit can optionally earn some sort of staking privileges, you know, it can be used to stake a validator or it could be depending on where they host it with. They could invest it in a way. And finally it is a deposit so it actually gets returned over time for evidence of what lack of evidence of bad behavior and it comes down to really how much should be deposited. You know, what's considered a good deposit to help counteract this gaming, privilege or ability that manufacturers have, you know, what is a good economic inst don't have to really say, Look, I'm in the interest of the network itself and not my own personal one. And given this scheme,
it's just better for me to simply take and deploy hotspots in a good way. So that's a lot of what the HIP is really about, and what we really would like community comments on if they think this is a good idea. It's specifically about amount. Now, there's much in this HIP about the technicalities of how the deposit timings work. And more importantly, there's a section in there about what to do if there is evidence of wrongdoing. And that comes down to what we call the tribunal structure, which we've actually already adopted for our previous hearing, if you remember with Deeper Network, a manufacturer that committee recused of gaming, or at least not using their key very well, and that tribunal structure is really important to this HIP because we're gonna use that same structure for slashing, the tokens that are deposited. If there is evidence of wrongdoing. So the tribunal structures there to make certain that slashing is a very serious thing that should only be done. If there's if it's warranted, that that's the punishment that should hopefully give this HIP all of the teeth that it needs to encourage manufacturers to behave well. And in that tribunal structure, there's a really good set up so that the MCC is a judicial body, members of the MCC will sit and hear evidence presented by what we call the prosecuting body, which is right now the proof recovered security working group, we found that that group is really good at doing investigations and really smart people in there. And you know, it's a community group, there may be a subset of that which is really charged with being the prosecutor in these cases, that's still up for debate how that wants to be organized. But in dividing these roles, we can hopefully get more of a approach to the truth of the matter. The judicial body should be the one that listens to evidence presented by both sides and then is convinced one way or another what to do. I found when I had to find evidence of wrongdoing, it's very hard to sit back and look at evidence of right doing and once you get into an investigation yourself, you get doggedly into it and you're looking for all sorts of evidence you can and you're you've actually start, you stop looking at evidence of to the contrary. So in dividing these two bodies up, I feel it helps make one decentralize the power, which was something we always want to do here. And also helps remove some of the biases that can enter into your mind when you're really working hard for one side or the other. So it sets up these, the tribunal and the standards for judgment under there, which we've already exercised when it came to deeper. So with that, really, I suspect there's going to be a few questions. Of course, you can't read very easily when I've posted that wall of text.
Yeah, I would say I mean, I'm just getting back on the text right now, but just kind of adding a couple of things. So one is, this is something that I've been a little bit involved in the periphery. And in general, I'm in favor of something here, because we do want to make sure we have some level, I think it's really important. There's some level of manufacturer accountability, as you continue to expand on the IOT network, and depending on the future of what 5g cellular and the other types of we need to have accountability measures for, you know, third party providers coming into the network. You know, incentivizing good behavior and making sure that we can protect network against anybody who's gaming. So one of the areas that's been in Jeremy covered this is how do we make sure we are handling that existing cohort of providers. On one hand, we don't want to penalize good behavior, we want to make sure there's again, that measure of accountability and it's something that feels fair. So I would love to see you know, more discussion around this in channel we can actually get the posted to get a little bit more community feedback on how she handled this and something to bear in mind of with that level of accountability and how tokens are either held in escrow or staked. something to bear in mind is, you know, it's not beyond the realm of possibility that manufacturers may pass that cost along to consumers. So for the community to bear in mind that implementing something like this may pass that cost along but the idea of having that level of accountability also good for overall network about so you know, kind of factoring that into that personal investment.
Yeah, I mean, I let that is a really important thing that needs So far to counter that, we certainly don't want increase the cost of hotspots. And that's why I do like Brad in particular helped add in the notes in here that should be allowed to earn interest of some kind, you know, that helps make it more attractive to really, maybe make it not as passed on to the end user. But
yeah, and I know that, yeah, that was actually there. Again, this is where I'd love more community feedback here on kind of the the treatment of a token lock of, you know, if, you know, the idea that tokens can be staked to a validator, where there is some yield that's being earned on that, obviously, with a cooldown period of time that manufacturers have to take into account as opposed to having the tokens simply doubled in some non yielding escrow account that might potentially be more easily returned. As far as the question on, you know, the all existing manufacturers need to submit or be grandfathered in. This is kind of the, you know, the proposal does address this, with some cap on how much existing manufacturers would have to contribute. I think it's really one of the probably the most important area where I'd love to see kind of more community feedback in general of what type of onus we put on our existing cohort who, again, if there's no cases that have been brought to date, or effectively, good behavior. That's until there's not good behavior. So we it's his past performance indicative of future or is there another provider that may have a case brought against them, I don't know what the stage that's saying that we're trying to account for. I'd love to see me personally, I'd love to see something like this move forward. But I think it's important to get socializes more community feedback, I'd love to see a couple of the honestly manufacturers, the fleet managers weigh in on this on what they can get behind again, the idea that they're long term aligned with the network that they should be on board with some type of provision that is guaranteeing more security of the network and ultimately, good for them in the long run. So we'd love to see that type of input.
And one other thing that has occurred to us while writing this, too, is you know, there was a HIP in the past. I'm not certain what the status is trying to establish the way in which if a manufacturer does abandon their fleet, that there would be the ability to support that fleet by third party. It's possible this could be combined with that, since these tokens would be staked, and if the manufacturer went away, you know, these tokens can be dedicated as a reward or bounty to someone taking over that fleet, if technically possible. That was another suggestion. I did hear from the community. And I liked the idea of at least exploring that.
Yeah, I see, JMF asking why not make it a fixed cost rather than variable simply locking up a fixed number of tokens for a license?
Yeah, so I can kind of answer that we do have to balance manufacturers sizes, some manufacturers are deploying a lot of hotspots and some aren't. But we did want to make it possible for a small volume manufacturer to be able to do work with this team. And also that the, the incentive itself, the incentive to cheat is kind of open ended, it's not a fixed amount, as far as we can determine it, right? You, if you can onboard rapidly, you could easily make more than the 25k to D that came out and suggesting or differently. If you're not onboarding a lot, your ability, the amount you could cheat with is much smaller. So that's one of the things we're trying to have trying to balance as we've gone through this. It's definitely worth discussing, should it be fixed or should it be based on one hotspot at a time? I definitely don't have an easy answer. But as we debate through it, which is why I think the real important thing to do is to get this up so that we can get a lot of comments on it.
Yep, I see. Phark just threw up as thank you for that that just throw it on but uh, just a little bit easier to read. So yes, we will. Let's get this into HIP format. I just want to make sure we can cover it on the call today rather than waiting another month. So thank you everybody for bearing with us on this one jerm appreciate you presenting on this. We will have the replay easily read through that we'll get a channel open because I'd love to see more discussion. balancing out this measure of accountability.
Happy to do it and I'll yield the stage. Feel free to call me back up and if there's anything you need.
looks like up to hash codes. I got lost there. Can everybody still hear me? All right. Great, not sure what happened there, sorry for the drop off. But yeah, just to summarize that we'll get into HIP format for easier reading soon, we will get a channel open. Let's get some more discussion on that. I think this is a good accountability measure where I'd love to see more important, we can move forward on this. I don't think this is one that we shouldn't need too long of discussion, but rather coming to some form of consensus more than a tip that can be voted upon. So thank you again to germ and other other contributors from the MCC on that. So my thanks as well, I don't know who to be named, who should be named. Exactly. So just thank you to the entire MCC, who also was contributing their more efforts around overall network integrity. So that's said, let me look at our next topic of discussion. So HIP 53. So there's been some very meaningful updates there. And, of course, if we have you would love to discuss the latest and greatest around hit 33 and the 5g subDAOs? I'm looking for you. I'm trying to see if you're raising your hand there we go.
It's fire everyone.
Boris floors, yours. Thanks for coming.
Yeah, sure. Thank you for inviting me. So as you mentioned, Scott, there's sort of a whole bunch of update that's been dropped in HIP 53. I was mining to share a deck that kind of explains the dynamic of HIP 53 As we envision it today. And the launch planned for it will have some dates. But I now realize that I can share in discord. So maybe what I can do is I can post the link to the deck in via HIP 53 channel, and I can verbally walk people through it. And you guys can follow along on as well.
Yeah, because I would say if you want to throw it in voice chat text for now since that's, I mean, we can copy it later to the HIP 53. Panel, but seems like everybody's kind of congregating in that voice chat text channel, either one.
Let's see. I'm gonna try and do it. Maybe in both. I'm sorry for being a discord noob.
No, and if you throw it in 53, We'll just copy it into that one for you. Whatever.
53 and maybe come copy it in the chat. Wherever that is perfect is one of our up.
There we go. Thank you.
Got it.
Yep, they get moderators to the rescue.
All right.
Hopefully the Google doc doesn't crash from so many people coming in, obviously. So first of all, the new name for the HIP 53 token is MOBILE. We consciously changed the name of the token from 5G or HGT or other such things to make sure that there is sort of longevity behind the DAO that we'll be launching, because 5g is a specific wireless protocol. But the way that we're currently looking at DAOs is to not necessarily focus just on the particular protocol, but focus more on the use case and the use case for this DAO is basic layer offload of the mobile data, which can be done using 5g It can be done using LTE, it will eventually be done using 6g and it also very much can be done using Wi Fi. So MOBILE is the new name. Now, I'm looking at slide one right now. And this shows this is kind of like a graphic representation of all of the economic and functional entities that are interacting with each other within this DAO and a high level representation of the flow of tokens for all the system. So at the top, you see the subscribers the subscribers are basically For the folks that purchase data plans them, they effectively, you know, use the network. Now the new entity that I know there's been some questions about, and I'm happy to field some of these questions. Over here we'll have time is the service providers. A service provider is basic layer in this DAO, anybody who is selling data plans and offloading data into the Helium network, we were kind of going back and forth a little bit on, you know, including the service providers. But ultimately, I think that probably this is one of the biggest and most material and also I feel like layup, the most impactful positive changes that we're introducing here in that service provider is instrumental to make sure this entire ecosystem works. I think, somewhat, unlike in the LoRa world, in the mobile world service provider is a very central entity, that issue SIM cards that supports the end users that maintains the network that in this case, also eventually is responsible for, you know, performing a variety of roles related to actually settling the like, with the network using the data credits. And what we wanted to do by introducing the service provider entity is create, almost like a competition among the service providers to offload more data into the network and including them in here was also quite heavily informed by some of the conversations that we've had with the service providers that we are negotiating, or floor deals with today. A lot of them, you know, were initially skeptical. But as they went deeper, got increasingly more interested in not simply participating in the Helium ecosystem as like a passive or floater, but like an active member. And the structure that we propose is such that the service providers will effectively only be compensated in proportion to the amount of data that they drive to the network. And we'll you know, compete with each other, to compete with each other for rewards to make the Helium ecosystem healthier. One other important thing that we are adding here is that will provide service providers that will offer service providers an opportunity to use the rewards that they're able to get from the DAO to incentivize the subscribers. So if a service provider wants to, for instance, like launch a crypto friendly
data plan, where a subscriber media participates in some of the rewards or the cost of the plan is offset by the, you know, certain amount of rewards that the service provider chooses to keep for themselves, will provide that flexibility. Going down from the service providers, there is a bunch of Oracle's Oracle's effectively proxy signaling data, like authenticating sessions, from the subscribers to the hotspot numbers, and they're kind of you know, this is it's like a distributed police sort of that that makes sure that we you know, keep all of the accounting and we settle the data with the blockchain and everybody has a good actor. hotspot Bounders effectively on equivalents of what freedom fi or bobcat is today for via mobile, you know, Helium mobile ecosystem. And hotspot operators are the hosts. And finally, on the bottom, if you look down at the bottom of the slides, we have this new entity called the mapper per HIP 53. A mapper is anybody that has a SIM card that's been authorized to map and that SIM card can either be inserted into a phone or it can be used with a dedicated mapping device. That can be like in many cases more effective at performing the mapping job than just the phone itself. So the rewards are split between all of these entities as kind of described in this picture. hotspot operators continue to Get the rewards for both the proof of coverage as validated by the mappers. And the data in a direct proportion to the basically price of per gigabyte of data that has gone through for their specific hotspot. And then there is a couple of technical constructs if you look on the left, which is the operations Fund, and the V. Mobile, as we'll call it, stakers fund. And these are the constructs that are directly kind of carried over from what I think has been already socialized in HIP 51. Now, this is kind of I felt was kind of a good representation of overall, you know, a number of fairly complex concepts that are described in the HIP. And now moving to the, I think the more interesting part is, you know, like, when rewards, right, we know that all of you have been eagerly anticipating starting to get a rewards for the deployment of your freedom, five gateway-rs, bobcats and then the small cells. So if you start scrolling through the deck, from slides three on down, it kind of shows you with specific dates. And, you know, I'm looking for also the support of the Helium TMM. A by on confirming that these dates are accurate, you can see how the rewards will start kind of coming online. So the first stage that I think is going to happen in Q2 of this year, and I'm hoping for the earlier part of Q2, but I don't want to make commitments on behalf of the engineering team is the first thing that will happen is the POC and data credit rewards will start flowing from the emissions contract. I think likely in July of this year. This way, everybody who is already invested in you know, the gear or maybe you know, has invested but not yet put it up is going to be able to start realizing the rewards. This reward structure is going to be based on like what were referred to as the eligibility rewards. And for you know a certain period of time, it's when when we start doing awards and one of the mappers will come up 100% of all of the emissions from the emissions contract will go for eligibility. Eligibility basically means that you have your small cell up and running without your pass the backhaul test. And we have a minimum QoS for the backhaul that I think we've outlined in the HIP and that your small cell is able to maintain heartbeat with the spectrum access system Oracle so we'll monitor all of that. And if you are eligible if you know your your you have good backhaul, if you're able to maintain the spectrum grant from SAS, you will be eligible for the further rewards. Next stage, likely September is going to be the introduction of the mappers. This again is going to be combinate with mappers like any sim that is then whitelisted to map initially, the first wave of a mappers launch will be a dedicated device. That dedicated mapping device will start receiving rewards on splitting the rewards with the focus operating the small cells display split right now that we're anticipating as at 3% for POC DC and 17% for the mappers and this is going to be the second stage like layup September timeframe. Next stage is going to be one will evolve him the first service provider or service providers and service providers will become like an official entity on the network. So this is not to say that we will not see service providers offloading beforehand. We already have a number of service providers basically integrated. You all know about gig Skype for instance The plan that we've launched a while back. But in Q1 of 2023, is when we expect for the DAO members to effectively like vote. For the service providers, the service providers will be required to stake a fair amount of mobile tokens to maintain kind of a service provider status, and they'll be required to get voted in by the DAO to kind of participate in the network. Next stage from there on forward is the implementation of the the operations fund and the veHMT or the MOBILE I guess, staking. And the final stage, which we expect is going to be probably mid 2023, is when we'll introduce the Oracles as the entity. So, initially, the work are related to actually proxying, the traffic most likely is going to be done by the Helium Foundation, upon launch. And we'll be ready to kind of distribute everything completely, and delegate all of the proxying work to Oracle's by q3 2023. So that's kind of the summary of, I guess, HIP 53, and most importantly, the launch plan. Maybe I can take questions if we have time.
For a stand, thank you, it was a very thorough overview on the implementation, I appreciate it. Yeah, there's been a number of questions that are in chat, I feel like a lot have been kind of answered in real time on the fly, I'm trying to do some blowback, my son could see what hasn't been addressed at this stage. Any questions that you want to come stage to discuss, to look for hand raising? There's been a couple discussions here around 52 and 53. Application to submitting to the Helium DAO versus those submitted as HIPs. You know, I think that at this stage, you know that that's why we're at least kicking things off with a focus on 51 of the overall framework and the overall design. There's certainly enough momentum from the core developers on this right now where we want to press forward and have a vote on that. And then 52 and 53 are implementations that effectively are in public view.
Yeah, a couple of additional notes, obviously, that, you know, this is, while I feel strongly about the sort of, you know, this as being the final final version of HIP 53, I think that there will be some still changes, minor changes, prior to it coming up to the vote. And all of that is subject to the community a vote on HIP 51. And, you know, obviously, 52 and 53 will need to be voted on as well. I do feel pretty good about though the final structure of it. A couple of contentious points that I've seen have been raised in the discord channel that we're still going back and forth on. And I think it would be useful to get further community feedback on it as whether or not to, for instance, include hotspot vendors in the pool of rewards as a potential option. There's pros and cons to that. Obviously, if this is to happen, this is not going to happen. Like sort of retro actively it's not like you know, you bought your barber or you bought your freedom five gateway, and you paid your money and all of a sudden, you know, now we just say that pay now in addition to what you've paid, you'll also need to share the rewards. But it could offer an interesting way for like me You think market opportunities where certain vendors, and maybe existing vendors have, unlike us offer cheaper hardware that is subsidized by some of the rewards and we can partake in sort of the success of the actual networks. So there can be different types of offerings on the market, and we can let the market regulate, you know, some people will prefer to buy from vendors that will just take money and pass 100% of the rewards to the hotspot operator. And some people will prefer to pay very little, but share most of it, you know, kind of be risk averse. And I think that there's value to doing that. But, you know, we kind of left it up to the community to have a little bit of a richer discussion on and come to some conclusion, we can probably put that up to the DAO vote later and add that, if that makes sense.
Yeah, one thing that I noticed was I got quite a horse. No, that's one of the other questions that people were I saw, it might have been a question about when service will be available. is sort of starting next year, when we will get POC before then this fall, does that sound like a fair premise from Keith? Now I know we already obviously through the agreement with gig sky there is service, again, with with its is covered in voice chat text here about you know, with the right SIM cards, there is existing service. But for us, I don't know, if you want to speak to anything else around, you know, in terms of when folks feel like they can actually be using the network, or you spoke to some of us in the room.
But so you can use the network now. And there's a couple of ways to do it. One is that you can get the data plan from GigSky. And a data plan gives you the West global coverage. And you're able to connect to the cells that you have deployed when you're in proximity to that cells. And when you leave the cell, it goes back to the global coverage. You if you're interested in you know, like global coverage from gig sky, I do realize is somewhat, you know, expensive, and it is kind of like a initial first pilot operator that is floating into the network. So what we have done is we have quietly at this point launched freedom fi SIM cards, and you can go to our website, and we sell those sim bundles. So if you if you wanted to get, you know, fairly inexpensive way to get access to the Helium mobile network only. You can go that route. And as service providers come online, we expect that there's going to be, you know, more options and more data plans that allow people to effectively experience the network.
Joey, I see you've joined us as well. Didn't if you had a, you're sharing questions in the community or had something of your own?
Actually, kind of my own question, I'm still, I guess, trying to wrap my head around the IOT token and mobile tokens? Well, I definitely like the name of them as sort of a go to market and sort of staking our claim for what this service does. In the longer term, what I'm confused about is their definition of these tokens as sort of all encompassing data transfer for mobile. And to me, that starts to push us back in the domain of trying to figure out where to get rewards from when we need to incentivize new protocols. So for instance, that move from 5G to 6G or Wi Fi offload and where those tokens would come from.
So I am trying to chime in with with an answer and if anybody else on the team has a perspective, please do that as well. So in thinking through the DAO structure, we initially layer and like each DAO
equals a wireless protocol. And we'll have a DAO protocol. And one of the things that I think we've run On into is that what we're trying to ultimately accomplish with the DAOs is to have certain flexibility in terms of structuring things like proof of coverage, or just the economic interactions between the different layers within the network. And what we've uncovered is that these like, you know, economic interactions are not necessarily dictated by what the protocol is, but what the specific use case is for the network. So, like a very vivid example is what we have been doing with our use case, which initially has kind of been labeled as like Helium 5g use case. And that use case is supporting mobile data offload. So if an operator be at an MNO, and MVL, wants to rely on the Helium community to provide an offload network, you know, they can do that, right. And that's the use case is not specific to a protocol, because like, the entity of a service provider, or the hotspot operator, or the hotspot vendor, and how technically you will distribute rewards between them. And the whole governance structure. It doesn't really change whether it's, you know, LTE, or 5g, or if it's Wi Fi, or whatever else has come in the future. It's the specific use case that dictates that where you have a service provider, and the service provider wants to find, you know, more cost efficient places to offload data are made to create infill coverage, and you have ecosystem players and then Helium, that that are, you know, creating that infill coverage. Now, if you go to IOT, it's not really like necessarily so much about it being like LoRa or you can use for instance, you know, also like MB, IOT, which is like an LTE based protocol for doing IOT, it's the same thing, you have a different set of economic players and a different set of incentives. And then you can have, you know, things like VPN, so you can have a use case around fixed wireless access, for instance. So fixed wireless access can be done with Wi Fi, or it can be done with 5g or LTE. But the way you would structure, the relationship between the different entities would be very different. So ultimately, I think that the current stance is to focus the DAOs on the more like the wireless, and maybe a lot of them down the line exclusively wireless use cases, which dictates the interaction between the different entities versus the protocols. So that was kind of maybe a long way to answer the question, which, but hopefully, that shed some light. And
I think I'm still coming around on it. Maybe if I can try and summarize just really quickly, we would have HNT. And we have IOT and mobile. And then for instance, under IOT, we would have a sub sub DAO sort of that tracks LoRaWAN, another that could track NB-IOT, those would both have their own distinct proof of coverage methodologies, that that treatment of data credits would be the same.
I think that the way that we're thinking about this right now is that it's like IOT is a subDAO. Mobile is a subDAO. Maybe there's going to be like a fixed wireless access or public Wi Fi subDAO. I don't think there's going to be like, multiple tiers. Let's put it this way.
Okay. And I think I have a lot more questions.
It's hard. It's hard to project for, like all the future cases. But I think that the simplest way to think about is if we have like our LoRa network right now, right? LoRa network is just, that's, you know, like, IOT subDAO is what we're gonna have coverage for the LoRa network, then we have via mobile offload Network, also known as Helium 5g, and that's going to be governed by the mobile subDAO. And then to the extent that there is other Cuellar proof of coverage, you know, sort of algorithms that we need to account for that can manifest itself in like other subDAOs.
So one other being other than IOT and mobile All
right.
So I want to be able to move on to some other questions that were coming out of the text. AndrewMD was asking Boris, can you speak to any beta testing success with any of the major MNOs and MVNOs without compromising your non disclosure agreements?
Well, I mean I'm trying to... here's... I can make the following statement that at this point, we are in, like, various stages are like engaged in technical trials with all but one MNOs in the US. And they're all sort of like a different stages, I would say. And moving at their own pace. But they are no longer just like high level conversations about hypotheticals, they're actual technical work that is being done.
Excellent. Exciting. I think that's satisfactory, given. There's probably a lot to do not disclose there. Another question that was from Anthony, were, does the emissions curve expect a certain amount of mobile minted per epoch, regardless of agency rewarded to the subDAO?
Yes.
All right. Looking back to see oh, I didn't see sorry. But I didn't realize that he would actually answer that. Other questions, or if anybody else wanted to pop up on stage, we do have we budgeted nicely on time today. So we've got another
eight minutes. Otherwise, if there can continue to discussion to the HIP 53 channel. But do want to make sure we thank scores for all the contributions and all the summaries here. I'm looking to see if there's anything else that's coming up, I don't see any hands raised. And I think a lot of expressions are kind of being covered and shipped. Right. So Boris, thank you so much. Appreciate all the detail.
Yep. Thank you, Scott. And thank you, everybody, for kind of bearing with us. I know, it's been kind of a long journey to make to figure this stuff out. And then, you know, kind of get it done. Right. I do feel that, you know, that was the time was wisely invested. So I feel like we are very close to, you know, kind of actually really taking this off and kicking off the rewards. So thanks, everybody, for bearing with us and kind of crunching for all the necessary complexity that we've had to deal with to properly structured as DAO.
Thank you. All right. On that note, again, I don't see anything else that we can cover up here. Otherwise, again, just a.
So looking at work from Ed here, the data stuff and economics between all super confusing more podcasts or videos, hopefully can get more of the understanding worked, extensively communicated well. So I think that, again, wow, we've been talking about this for multiple months now and been having a lot of different context around it. You know, if there's more demand for this, we can certainly open up for another spaces or another ama or just kind of an open forum for discussion during the voting period. I do feel like a lot of resources have been brought to bear on this. So we will be opening up for the HIP 51 vote on Friday. Again, that's going to be a 10 day period. So if we can carve out some time next week for further discussion, if if there's some demand for it. Anthony answer your question. No, this is not a temperature check. Again, kind of covering the fun some of the things that Abhay covered as far as um tokens on testnet open PRs review. We feel comfortable as this as a binding vote. Reminder again to everybody on the call. We do have Helium House coming up at Consensus in a couple weeks. Even though that is sold out please reach out to folks you know whether Foundation team Nova team if you're looking to get in I think we can probably squeeze a few more and hopefully I'm not speaking out of turn with some of the event planners, but obviously want to make sure some of our most aligned community folks, especially those who are joining for these monthly calls, have the opportunity to come in and join. It's going to be a really fantastic event. So looking forward to seeing everybody in a couple of weeks there. But as far as Yeah, any of the other for discussion, but you can certainly keep that in the Yeah, sorry. Bye. I'm definitely going to be sitting at the door. I will be there a lot of the other foundation, I think almost the entire foundation team will be there. And that will folks will also be there as well. Wandering folks away for over divided. Sorry about that. But yes, let's keep the discussions going. And I think we've covered a lot of ground here over the last few months. So if there is anything else, let's keep it in voice chat text, keep the conversation going right now otherwise within the HIP channels, but since we are approaching bottom of the hour. Thank you for everybody who was able to join today. For all the contributors, HIP authors, moderators, note takers, thank you as always, I would not be possible without all of your support. So thank you everybody and have a great rest of your day. Look forward to seeing you all in Austin or on our next call. So again, normally the point where we would be able to turn off videos and say goodbye, but I will say on everybody's behalf. Thank you for coming and take care everybody
