Mic check make sure that Discord thing gets turned off
all right. Hear me now joy.
Sounds great fantastic all right
let's see here. Two minutes pass. Give it a couple
more folks to trickle but otherwise we got plenty to talk about and all everybody wants to hear more details around the updates here proposal
Can y'all hear me okay? Yep, that's all right there. Yeah,
Mark can check in
by check, either.
Yeah. Seems to work. Yep.
All right. That's a robot All right,
I feel like I see the numbers are slowly increasing. But I think we just for the sake of time, and not to keep everybody waiting on the edge of their seat. might be good to get started. So hello, everyone. Scott from Helium Foundation side. So I've got Joey that you all know and love from Foundation team, and then over on the no side. America by him mark. So I don't know if a by you want to kick things off or Amir, when you guys want to
talk about again, it's kind of the
roots behind the proposal. And we've been talking about this now for you know, I feel like it's been almost a year since the original proposal from Freedom five that talked about, you know, scoring different wireless networks. And then we got into, you know, discussions around scalability. So this has been a, you know, at least in my perspective, a long time coming in a lot of discussion. So it feels like the combination of a lot of work and a lot of research. Yeah, I think,
actually, rather than me kicking off, I think folks in the community have heard my voice a lot on this on Discord and on Twitter. So maybe Amir can start us off and then Mark can jump into.
Yeah, happy to. And I've spent a bunch of time in the Discord over the last couple of days. So I don't think I'm going to be saying anything new, but maybe a slightly different audience. So I think like a lot of this goes back very, very far into like, Helium crypto adventure timeline. It's like I think now the environment is so different in terms of options and technology stacks that can be used, but when we started It's doing this part of things was probably remember Mark probably late 2017 or early 2018, or something like that
pretty much. Yeah.
There weren't really any, there was really nothing out there in terms of smart contract chains aside from Ethereum, we didn't know exactly how we would do it on a cerium, that we understood that the cost of storing data on the Ethereum Blockchain was very high, and the transaction fees were quite high as a result. I think we were also still, very early in our journey, we don't, we didn't know what we know. Now, of course, we didn't know how some of the architecture decisions would work out. So a lot has changed since those days. So first of all, the network grew to this enormous size. Which, you know, even for me being the most optimistic about Helium has been a surprise. We've learned a ton about the different kinds of problems and the different sort of modes of problems that arise from the different architectures that we've had, you know, so all the way back to hotspots being full nodes that did all the consensus and, you know, swapped around every now and then to validators to light Hotspot, you know, I think we've gotten a pretty good handle on what the difficult parts to scale are, and what the, you know, which parts are relatively straightforward. You know, then you've got, as I mentioned, sort of, at the start, you've got the availability of other stuff, right, so there's now Solana and polka dot and avalanche and Cardano, and JIRA. And as you know, there's like a million of these things out there now that are all perfectly capable, beyond capable of doing most of what of what Helium needs, if not all of it. And the other part, you know, that I think we've learned is, what really is important to people like that, I think that for at least for me, it was fairly unclear at the start of this journey. But for, you know, token oriented folks, consistency and reliability of proof of coverage, I think, has been a real pain point. Like the the rates of PoC goes up and down. Receipts vanish, no one knows why, you know, this, it's, it's a complicated system that's very, very difficult to debug. And then for users of the network, data reliability is critical. So we built a system called State channels, I think a bunch of you know, that is responsible for packet metering, and making sure that packets get delivered to the other side, and accounted for and that system also quite complicated, quite very novel, very clever way to solve the problem, but very, very complicated. And makes it again, difficult to debug where a packet is failing, you know, is it failing? Because there's RF interference? Is there a problem with the Hotspot? Is there a problem with the packet forwarder on the Hotspot, the problem with the sensor, you know, there's like so many places already that the that the packet could like, not show up from it, adding this little these layers of complexity makes it even harder to debug when something goes wrong. So that's sort of where we, where we sort of came at the problem from is that we've learned a lot, we understand what the problems are, and we understand what people need. So, you know, regardless, I'm just gonna ignore the sort of L1 Swap part for a second, because I know that that seems to get the most attention. The desire was, was really to try and simplify the architecture such that proof of coverage and Data Credit transfers were extremely reliable, right? So there was no ambiguity, for example, how often your Hotspot was supposed to be good, right? We just do that very consistently, like on an hourly time, or something like that. And so, so that reduces another sort of unknown point of the system, which is that you have this very complicated, challenging system today. So we wanted to simplify it all the way down as far as we could. We think the best way to do that, at least for now is to have a single article, that is sort of air quotes of the server that is responsible for
generating entropy, validating, receipts, you know, doing the pieces of PoC that are still important, similar to the way validators do today. But stripping out all of the consensus protocol stuff and all the complicated hard bits that make this very slow. And then doing the same thing on the other side for Data Credit transfers, is to try and simplify the architecture down there as much as possible. No longer develop our own proprietary LoRaWAN server. Try and make you know, the packet routing Oracle name probably needs a little bit of work, but compatible with as many LoRaWAN network servers as possible. So as I think a bunch of you know, there are several several different LoRaWAN network servers, they call these LNSs. AWS has one there's an open source, one called chirp stack, there's the things network there's industry Real sort of commercial grade ones like Senate and activity, we just wanted the packet routing part of the system to be compatible on the other side, so that anyone could plug any LNS in. And we think just simplifying it down to that level, making it more compatible with the rest of the LoRaWAN ecosystem is a good solution to reaching larger scale on the device side and again, takes us out of the business of building a proprietary LNS, which is largely undifferentiated from everything else on the market. So that's like an overarching terms just like trying to summarize a bit of the history and how we got here and what the goals are of this proposal. That's sort of the most of it, you know, having this Oracle architecture means that the stuff that ends up happening on the L1 level of the blockchain is very, very simple. Like there's not really that much going on there anymore. It's about creating HNT, it's about creating the subDAO token, so IOT and MOBILE for now. It's about taking input from the Oracles and then distributing HNT to the people or IOT or MOBILE to the, to the entities that deserve it, who did the work. And so that's all the L1 really does, like all the hard stuff like PoC and data transfer is now not inside the blockchain logic itself. And so you know, which L1 you pick, as a result of that architectural decision, I think matters a lot less, you could do this on our own L1, you could perhaps have done it on a cerium I think the fee structure, there's still a little bit of a problem. You could do it certainly on Cardano. Or, you know, it's doable on I think almost any L1, maybe not Bitcoin, because it doesn't have the idea of tokens. And there's a bunch of reasons that we we sort of went with the choice that we went with after looking at all the different pros and cons, which we can get into later. But the important part I think to take away from it is that the old ones function is very, very simple here. And so it kind of doesn't really matter that way anymore. It's not critical in terms of what it needs to do all the Helium specific bits are no longer not on the chain, and still built and maintained, or at least built in, designed by us. And that's, you know, I think the important part to take away is that the L1 function is significantly simplified. So anyway, I'll stop there. That's kind of a summary of how we got here and some of the thinking behind it, but happy to get into any questions or if mark or a buyer or anyone else has anything to add definitely jump in.
I think we should go straight to questions. Yeah, I agree.
So just for context for folks, we've dropped a form in the community chat text channel, where we've been collecting questions over the past few days. We can probably go ahead and open up the channel for questions a little bit later on. But in the meantime, I think marks a PI. Amir, do you all have access to this list of questions?
Do this Google Sheet? Yep.
I don't know if we want to let you sort of pick some that are standing out to you or are sort of happy to sort of feed you a couple of questions to kick things off here.
Yeah, what do you read out whichever ones look interesting. I guess I'm up. Do you want to do it? All right, where do we where do we start in here? Got any favorites? Sorry, I'm trying to
pull it up right now. So I have a little bit of issues on my site.
Sessions in here, so obviously, we're not going to get to all of these. So we're going to try and pick some stuff that tends to represent a lot of what what's going on we're seeing in the community. Let's go ahead and grab this first one off the list. So the question asked if Proof-of-Coverage and data credits will be moved to Solana, what will Helium validators and the Helium blockchain be used for just transactions will validators earn less than what they are earning today?
I can tell you take that one. If you want Mark just it's sure low is dumb enough for me to get. So one important thing to understand about this proposal is that moving to
a different L1. And
moving to this Oracle based architecture means that there are no longer Validators in the Helium ecosystem like that is not a that is not an actor in the ecosystem anymore. So that I think it's 6.85% of HNT that they are currently earning for the work they do that goes back into the, into the pool so that that 6.85% is no longer carved out. So I guess that does mean they earn less than what they're earning today, because they will earn nothing for the function of validating, there is a new form of staking and yield in in the system, which is called veHNT, votes escrowed HNT. So you can lock up your HNT earn a percentage of HNT that gets created. And in exchange for that you get voting power, effectively in the in the in the governance process. So it's kind of an interesting model, it is potentially useful in the sense that you no longer have to run a big server and you no longer have to put up 10,000, HNT and you don't have to actually perform the validation functions anymore, but you can still earn, you know, percentage of HNT that gets created and participate in the governance process there. So there's still a way for Validator operators and frankly, any HNT holder to participate in yield. That way, it's just different from running a server that validates transactions and creates blocks because that's now that's now going to be handled by another blockchain.
As a as a corollary, I think are the questions What if PoC and Data Credit move to Solana technically Proof-of-Coverage, like the actual beginning of losing, it does not happen on the Solana chain, or that is that happens, that happens off chain and the corresponding rewards that are deduced from that are Oracle back to this to the Solana chain. But the Proof-of-Coverage calculations contain the reporting all this stuff happens happens off chain.
Great, I think maybe just a quick follow up to that question is Will more rewards go to Hotspot? I didn't get a Discord handle from the person that asked that, but sort of related.
Yeah, I mean, the the, I mean, the distribution of tokens is now a little bit different after HIP 51, two and three than it is today. But I think in basic terms, yes, you know, the 6.85% that was going to Validators now goes back into HNT pie. But there are you know, there's other stuff inside HIPs 52 and 53. That I'll try not to get into in this call. But the distribution of tokens is definitely different than it is today. But in general, the supply of HNT going to Hotspot operators should go back up as a result of the Validator is no longer being there.
Cool. So Siegfried asked the question, will this move affect. Will the move to Solana affect transaction fees? If so, will they get lower or cheaper? Will voting on HIPs become cheaper? And that may be opens a little bit of a question just around voting generally?
Abhay, but probably worth you grabbing that one over? I've been talking the whole time already.
Sure. Yeah.
So as far as transaction fees, you know, one of the things that is that we know about is you know, Solana has significantly cheaper transaction fees, and than we do on our chain. And so there's actually been some interesting analysis going on in the HIP 70 channel around this, I think we should pin those posts. And I will do that in a little bit. But, you know, and sort of share a little more widely what these fees are gonna look like, as far as voting. That's actually a really interesting point. You know, today, when we vote on our network, the way we do that is by burning, you know, sort of a minimal amount of HNT into Data Credits in order to vote for a particular direction for HIP, you know, so, you know, there's a for and an against burn transaction that happens. And it costs about 35 cents. So that's actually kind of interesting. And with the, with a future model, you know, Solana has this concept called SPL governance. It's sort of a contract that was written by the Solana labs, folks. And, you know, roughly speaking, we're going to be using that plus some extensions to that to enable this vote escrow locking. And so if you have put escrow tokens all you're really submitting as a signature, and so, you know, it's all you really need to do is lock and now you can participate with with signatures. If you're familiar with systems like snapshot on Ethereum. It's very similar to that. Cool
off to learn a little bit more about those other voting mechanisms. I probably should have kicked off with this question. So pactra asked, Will this switch benefit the greater Helium community? The most? Or will it benefit the devs? The core team, the early investors of each entity, arrest of age and community? Do the majority of votes come from Hotspot owners? Do they come from early investors? So I guess there's kind of two questions in there. But one is who's benefiting from HIP 70? And why are we doing it any in that regard? And then the other is like, where are these votes coming from? We do voting?
Yeah, it's a good question. I mean, of course, our our belief is that it benefits the community. The most, I would say, I mean, it's all the work we do is really for that community already. So our our attempt to kind of optimize how things work, I think should be a benefit, right? So if I think of the three plus years since we launched, and so the the amount of time that I've spent on Discord and Reddit and stuff like that, just sort of understanding what people's issues and frustrations are, I think having more consistent PoC, for example, is a huge deal. Like it may not ultimately get to the point if I want more rewards, which is I think, what, pretty much everyone, that's like, really everyone's thing. But at least having consistency around how PoC works, you know, so that it's beginning consistently, and you're being witnessed consistently. And just that you understand how it works. I think that's a huge wins. So like, we need to kind of stay focused on that. And I think that's a massive, massive sort of win for the community and sort of all the participants. And then the same for stuff like data transfer, right? I mean, there have been times where some of the issues on the network have prevented us from being able to gain more users at time, just candidly, right, like, there are users that have been ready to use the network and excited and wanted to use the network and in decent scales, but have had problems here or there that have prevented us from being able to, to onboard them. So this kind of work is like a huge benefit in all directions, right? Like it's, it should ultimately increase like the reliability and performance of proof of coverage, it will allow us to spend more time on improving proof of coverage, so that we aren't focused on sort of the underlying, you know, the Belly of the Beast stuff when it comes to L ones. And just focused on the things that matter, like proof of coverage and data transfer. And the end result of that should just be a better bigger set of networks that are that have more utility, or like I think ultimately, hopefully we're all here for for the utility. And this should be a step in the direction of just making it more reliable, more compatible with more network providers and software, which ultimately, we hope would lead to more users as well.
Great, so sort of on the topic of network usage. There's a couple of questions, folks have latched on to chip stack being a part of this, folks have questions around the future of Helium VIP Console. Go ahead, and I like the ones where I can attribute the question to somebody not everyone puts their Discord handle and so neither of these have that. Let's go ahead and ask. We've integrated the Helium VIP Console already. Migration will be done in q3 2023. What is the impact us? How can we follow this change? Yes, so
for that group, so firstly, I realize it didn't answer the last part of the question, which was deducted from the from the last question, which was do the majority of the votes come from Hotspot owners or do they come from early investors core team values expired? Very, very Luna-like of HNT I mean, I actually don't know that the voting breakdown I'll I'll just say that in general 60 something 67% of the HNT is in the hands of hands of Hotspot owners. So if all Hotspot owners voted for example, like they would be the majority of HNT in general, I don't think the large wallets have turned out much in the in the votes like I don't remember a vote where one of the top 20 or 25 wallets by HNT count voted. Not sure if that's a good or a bad thing. It's just you know something to be to be aware of. So, but that is the distribution of tokens like 67 I think percentage percent of the tokens are in the hands of HNT of the Hotspot miner There's Okay, so that was that was one on the VIP Console question. I don't have a perfect answer for you here. Maybe Maybe Dal does, but he's not on this on this townhall other than to say that there is a process that will be coming. Oh, there is there is Dal, I'll let him answer. Did you catch that part of the question, Dal?
Yeah. Thanks. Yeah. Yeah. So, you know, part of HIP 70, as Amir mentioned, is really shifting focus on the team, so that we can build out this foundation for partners in ecosystem to really feel confident that data transfer is reliable and scalable. So that is the priority of the team. For people who have I think they said there was some integration work that they did with, with on the VIP. So today, Nova Labs is hosting a, a router Console service. And what we've discovered is that rather than us hosting this and being kind of like a, very much a, a bottleneck to on ramping devices, we want to really involve the partner and the ecosystem. And so what we're planning on doing is working with partners so that they are able to host their own LNS and provide the services to other organizations. If you're already working, and integrating with VIP, we will definitely like, let us know we'll work with you in terms of transitioning that two, to what we're focused on in terms of church stack is an LNS that we've standardized on. So this is this is an effort that we feel is really going to provide more usage on the networking. And kind of similar to, you know, if you think about with HIP 19, initially, we were the only ones that were building hotspots. And then it mighty came out, we opened up to other manufacturers, and then we really saw the coverage exploded. And this is the same type of strategy that we're taking with with this HIP seven in terms of focusing on the underlying foundation and making it very scalable and reliable for the
ecosystem. No, you're great. Thank you doll just trying to pick our next question here. So one thing, I
think we covered it a little bit. You know, there was a question about who is running it. It's not attributed but who was running the Oracles which American started to or couldn't reverse mirror by the stars that but as far as what processes there towards decentralization of them, how they are now very targeted, as far as security risks and how those are going to be managed.
To pay the total ticket per step some some of that is process driven. Obviously they are run on behalf of the Foundation. Just as far as ownership goes, operationally, just like running existing routers will be can both note the core team can run the like the oracles. Today. The intent is for those deeds. And that system is built off of three parts one of the injectors to ingest events, the verifiers, verify those events and generate either rewardable or invalid derivatives. And then the reward server. The reward server takes that and produces rewards.
robot I can switch the MOBILE I can try to
repeat I just was sounding like a robot.
Yeah, so So I think that the bits that he was talking about, Hank, were around, you know, who's responsible for the Oracles and you know, we're the proposal is that the the Nova Labs to building the Oracles and but the foundation ultimately would be responsible for them. And we'd be running them sort of on behalf at least initially. And you know, there's multiple different components for these Oracle's there's sort of the ingestion side of this thing, which is of this architecture, which allows, you know, all of the hotspots to be able to interact you with Oracle's they're sort of the data itself with storage layer, where all that all that sort of raw data goes in. And they're sort of a data pipeline that leads to, you know, ultimately to rewards being issued to, you know, Hotspot owners. So the, there's sort of the three different parts of it. And we, we sort of talked about at a high level, what that looks like, in the HIP, we didn't want to go too specific and say, well, then this thing's gonna live in s3, and this thing's gonna live in, I don't know, I'm gonna make stuff up now, Amazon Kinesis, or something like that if you know, data, stuff on Amazon. And the reason for that, as we wanted to follow up with, you know, here's how the Nova Labs plans to implement, you know, that should be kind of separate from the HIP. From from our perspective, right. Okay, so
the key is to like split the system up and really only have them constrained to accessing files that are really not changeable, right, security is sort of built in. Because the reward server only operates on what reportable events and purchase rewards into the blockchain which everyone at
all of market answers take extra 30 seconds to process in our heads. Maybe a follow up question for just talking about Oracle's so how will we know if an Oracle is functioning properly, if the transparency is gone, rewards will appear on Solana that cannot be traced to the origin of which PoC triggered the reward. So complicity asked for that from Discord.
So So I know that's the case for MOBILE today, we're working on rectifying that the actual, the actual logic advice he gave me.
Sure, yeah, I could, I could pick it up. Sorry, Mark's connection is not that great. So the data itself is all being today is all being stored in s3, and the code is in GitHub and our plans here to open source, essentially, all of it. So you know, you should be able to, or anyone in the community should be able to process raw heartbeats. These are sort of the the for MOBILE, or raw PoC requests and witnesses. For the case of IOT, you know, all of that data, we want to make it accessible. Initially, we're planning on being you know, just to maybe take a layer back towards the implementation side of things just for a moment, you know, we are planning to make that accessible to anyone, but in a way that you know, where the requester has to essentially have to ask for it and pay for it. And if they're pulling out of s3, and then you know, you can do the same exact processing with the exact same code base, right. So you should know, like, you know, that this time stamp, this particular version of the code base was used, therefore, you can generate the exact same kind of output and allows for anyone to verify, and we actually encourage it. You know, we encourage folks in the community to do that, and service providers in the community to be able to do that as well. And you should be able to, at any point, look, sort of, you know, here's the raw data, here's the sort of deduped data and with all the, you know, sort of garbage thrown out, and you should be able to access any of these kinds of buckets along the way. Hopefully, I rubbed you well, there, Mark.
Luck. Yes. Robot? Yes, I'll take it. And I think you answered that in their vibe. But will the Oracle code be open source or the be some API to fetch the proof of coverage details?
The Oracle code will be will be open source. Yeah. Cool.
Okay. I'm gonna mark that as claimed. So Reba asked that, thanks for that question as well. Quite Jonatha, when
I was actually missed, there was a follow up to the Oracle question, there's actually some new questions around some of the things I've learned the tokens. So pulling one from the HIPs is Sigfried means at the moment transactions on chain are paid in DCs with a relocation to Solana at least some transaction fees will have to be paid in SOL. what kind of activity and stakeholders of the network will require SOL? How will it be paid for? Will there be automated activities that require SOL buying? Etcetera, etcetera.
So, yeah, technically, if
I want to speak in Chrome here, but the idea is that not that we're going to be requiring SOL, so much is that everything is going to be moving on top of the Solana blockchain to the SPL standard. Abhay, do want to clarify? I just want to make sure I'm completely accurate
here. Yeah, sure. So, so, you know, because a lot of these transactions so, you know, everyone today transfers, you know, HNT, for example, right, and that requires There's a certain amount of Data Credits to be used. And that's because that's sort of the the Think of it like the gas fee on our on our network. The the equivalent is you'd be you'd be using some some number of lamports, which is like the sort of units of SOL to do that kind of payment. Right? So those kinds of things would, you know, you'd still need to pay on the on the Solana blockchain the same way that you'd have to pay for it on the Helium blockchain. So, so I think that sort of answers some of the, those kinds of questions, we still need to with parts of the design here that are that we need to work out are really around how the rewards get paid. Right. And and you know, that that will be part of the part of the design that we need to put together and we'll sort of share that with the implementation plans. And then also like how to Hotspot you know, effectively NFTs getting minted right how to Hotspot Hotspot is get on boarded on the on the Solana blockchain. Today, as a lot of you may know that when you onboard a brand new Hotspot, the manufacturer is actually paying the the staking fee, the server onboarding fee, and then for then also the initial start location fee. And that's usually I think most manufacturers kind of baked that into the cost of the Hotspot. So that's those are the kinds of things that will need to transition as well.
Scott, does that
answer the questions? I'm actually not looking at all of them. Yeah,
I think that covers that one.
See, another question here. Grinning grant.
The original design system was the original decision to require hotspots the authorized by a maker was a to be a quick fix to backers liable coverage now that in Oracle is the sole authority providing coverage assuming that the Oracle is not a bad actor and will not buy of a coverage. We should no longer need permission from makers to participate in the network creating more trustless permissionless network correct. This protocol should allow people to save the create their own nodes as the nodes are no longer in a position where they can buy is that correct?
Can take a shot at that one? That's definitely not correct. The thing that HIP 19 which is the the HIP that requires the approval process for Hotspot manufactures, the thing it was really designed to do by requiring like a hardware key and and you know, the stuff that sort of laid out there is to do what it can to prove that packets on the network or proof of coverage packets in particular, actually come from hardware devices and not software emulated devices. It's full of problems, right? Like, I don't think anyone's trying to pretend it's it's perfect. Certainly I'm not. But that's the intent of it right is the purpose of that process is to have some way where you can say like, okay, there's a packet on the network. And it almost certainly had to come from a real device, or at least the owner of the packet had to buy a real device that's about as good as we know. So you still need something like that there are all kinds of amazing ideas and thoughts that we've had over the years about ways that proof of coverage can be improved. Some of them are in HIPs. So for example, HIP 22, I think is a fantastic development, which has the idea of like a secure Hotspot or a secure concentrator. And those again, are like all things designed at like the physical level of of Helium, right? Not really anything to do with the blockchain part or the software part. This is like how do you do do something in the real world in the physical world to prove that hotspots are where they say they are, are they doing what they're supposed to be doing? So there's a ton of work that needs to be done there. Part of the aim, honestly, at least from my point of view, for HIP 70 is to free up a bunch of resources and time and focus that we spend on L1, Blockchain problems and redirect them to things like how do we improve proof of coverage? And how do we make it better? So, quick answer your question is unfortunately, not that doesn't. They're sort of unrelated problems that that, you know, having an Oracle doesn't really help it may allow us to go faster. Because we can iterate more quickly on the Oracle we'll have more resources, we'll have more focus, we'll be able to spend more time on Proof-of-Coverage. But HIP 70 on its own, does nothing to really solve that problem directly.
The same person who asked that question asked Can we? They said they were afraid that their questions will be censored or dodge. So I guarantee that grant, we did not dodge or censor your questions. I am noticing some other questions coming in. So thanks for folks adding more questions to this forum. I'm trying to keep up on those as they come in. If, again, anyone's joining right, there's the community called Chat, there's a link in there with a forum, you can add things as you think they are appropriate. And we'll try to try to include them. We are about to approach 100 questions, though. Scott, do you have a next question for us? No, I'm looking through
here. I mean, there's a lot of questions, I think, just kind of come back to you know, why Solana in general. As far as questions, you know, just just trying to get a better understanding from the core team on how the decision was made. I think that the so this was addressed on the call, but there's certainly a number of questions around concerns about reliability or chain halts. So I don't know if Amira buyer ever more if any three want to talk to that point a little bit, as far as you know, the Solana networks as far as overall reliability.
I can, I'm just trying to find a thing that I wrote actually community because I thought it was one of the better ways I had figured out to answer this question.
I think so firstly,
I think some of the statistics around Solana and it's, you know, ups and downs and, and problems are probably a little bit inaccurate would be my first sort of reaction to sort of looking at from the outside. It sometimes sounds a lot, a lot worse than it is. So that would be, you know, just sort of one one comment that I that I would have, like in general. think an important thing to think about. And it may be applies to like a lot of the different questions that have been asked here is that the L1 doesn't have to do a whole lot. So if you took the example, just for a second of Solana being completely dead, right, like it's unreachable for some reason. What would happen in that case is that mostly everything would continue onwards, right? Like the Oracle servers would still be there doing their thing. Maybe they're sort of a more decentralized cluster of Oracle's at this point. Hotspots would still be doing their thing, they would still be reporting PoC packets and data transfers back to the Oracle's that what would be delayed is updating of token balances, right. So if you imagine Solana was down for four hours or something like something catastrophic had happened. You had beacon for your Hotspot at Beacon four times during that four hours, the Oracle server like has all this information, it's still there didn't get lost. And so four hours later, when Solana comes back, you know, the Oracle server would, you know, say to Solana, hey, this not in the last four hours here, all the proof of coverage events that occurred here, all the receipts that I saw, they were all the witnesses, you need to update the token balances as such, right, like Person A should get paid X, person B should get paid why? And so it would happen, it would just happen later. And it's one way of thinking through this also is to think about because people have often asked like, Well, what about using Ethereum? It never goes down. The way Ethereum like protects itself against load is by increasing fees to the point where it becomes sort of untenable to submit transactions. And that sort of naturally bounced itself back out again, and load decreases. So in if Helium was running on Ethereum, we would basically run into the same problem, like we would have some kind of logic in the Oracle servers that would say like, Hey, if the gas fee is over, you know, X value, you need to like Oracle server, you need to wait until the gas fee comes down. And you can keep querying the chain or whatever, every 30 seconds to see when the gas fee is improved. And then you can submit the transaction when it's below a certain number, like you can't imagine paying like $200 or $300, or something for a reward transaction on on Helium would be, you know, it'd be insane, it would be untenable, I don't know where those fees would come from. So in that case, like whether the chain is down or whether the fees are high, like you actually end up in the same sort of logical state, which is that you know, it just doesn't, just doesn't work like that the Oracle server has to kind of hang out for a second and wait until they until it comes back. And so that's, you know, an important thing to think about in the line of questioning, like, why didn't you choose x blockchain or why didn't you choose y blockchain or what happens when the thing goes down? Is that like unless it's catastrophic? Like unless the thing is like dead for like weeks or something or days maybe not really a huge deal, like you're gonna lose token balance updates for a while, but data still gonna get to where we're supposed to go and proof of coverage beaconing and receipts are still going to be there, they're just you're just not going to know for a little bit. So that's kind of that's my casual answer for you know, why Solana and why not X, Y, and Z. But in general and Solana specifically, I think there's a bunch of good stuff that we like, you know, the fact that it uses Rust as a language I think is helpful. It allows us to write code that's sort of a little more error free, let's say that transaction fees are absolutely tiny relative to to any other chain, like whether that is sustainable or not in their own ecosystem. I don't exactly know but it for now, it's it's a phenomenal driver, the developer ecosystem is pretty good. Like you've got frameworks like anchor and stuff, like I found the wallet ecosystem to be quite good. So so I should probably not say sloped or something, because they just had that fee leak. But Phantom, I think, is a really good wallets, again, just more tools that people can use on the network. Their MOBILE project, I think is interesting to us. I don't know exactly what we can do with both the Saga phone and their MOBILE stack, but definitely well aligned with what we're doing.
And also the fact that the big exchanges have support for the SPL token standard, which is kind of like the ERC 20 idea on Solana is helpful, because that, you know, both exchanges, but also things like ledger wallets and stuff like that, I think mostly, you know, like, we've been stuck in this sort of experimental status on ledger for what feels like years. And so you get the benefits of all of that compatibility, basically. And that's true for some of the other chains too. But I don't think I don't think any other chain has that combination of stuff. And the fact that it feels almost real time with how quickly bought blocks get created. Maybe not a huge factor. But definitely kind of cool from a user experience point of view, when you're interacting with wallets and changing Hotspot locations, and asserting hotspots and stuff like that. It feels like you're using a web to app like it's very, very fast. So that's kind of my my point of view on Solana. Yeah, I
agree with everything Amir said and I think one thing just to highlight there is, you know, if five years from now, if, if this was the wrong call, let's just say, you know, we still have ledger state that we can migrate off. And because of all that Oracle state that we can migrate, like, that's, that's a possibility for us, right? So I think this entire architecture really, really is resilient to something that's, you know, catastrophic. So I think that that's something that also to think about here.
Great, thanks, guys, for the, uh, for the thoughtful answer. And, uh, by adding on there, some of the stuff that I think you know, there's a couple of things that are a little bit more kind of our individual host operators. So as far as you know, when you guys said HIP 70 proposed moving to Solana, does that mean, I'll be mining Solana instead of HNT, or I got that wrong. So again, just to this probably good one worth clarifying. You won't be mining for Solana, actually, you wouldn't be mining for agenti, you'd be mining for either the IOT token if you're supporting, providing LoRaWAN coverage, or you're going to be in mining MOBILE token if you're providing 5g coverage. So just to clarify, and again, the the idea with this proposal is that those tokens are just simply existing on the SPL standard.
See what else I
guess another one again, will I have to do anything for the migration? If this happens, will my Hotspot app update automatically and run forward on the new chain without the need to do any complex or manual updates? And when will this happen? Thanks in advance
since that, yeah,
yeah, you're totally
right. Yeah. So I can pick up the sort of user experience for HNT holders today and Hotspot owners today and, and folks like that. So as far as and so more to come, obviously, on the exact implementation of how this will happen. But, you know, one of the advantages that we have is that your wallets and you know, your seed phrases should turn into a predictable Solana address. So So you know, today, you can open up your wallet app on the Solana side, like phantom or solflare and put it in a seed phrase and generate a wallet that's compatible with the Solana ecosystem. And, and you know, we can essentially do a ledger import like we're going to be the way that this would actually be implemented as we'd be halting the Helium chain, figuring out everyone's balances and their assets like their you know, number of data credits that they have the number amount of HNT or MOBILE or, or, you know, the hotspots that they have and migrating that state into the, into the Solana chain. So that's, that's a migration that we'll do and we're going to be building some tools along the way, you know, once this HIP is approved, that sort of shows people, you know, here's here's your Solana wallet, here's your Solana address. And we can we can show you one of the things we've also been thinking about is making it possible in Solana test net, to just start to see your balances and start to play with it. I think, once you start to get a feel for these things, I think it becomes a lot less concerning I think. And so so we know, obviously, we intend to do that. Great,
keeping things moving. There was a question here. Is there any preferential treatment for existing validators? Who can directly directly convert to vote escrow tokens in terms of the agency received for a given lockup period? Or can all HNT holders convert to veHNT at the same rate? I believe that there's actually a HIP in progress around this idea, as far as the idea of just trying to find someone who is, you know, giving validators who pre commit some extra voting or staking power, potentially, I think that's HIP been progress enough by him if you guys know anything on that, or can speak to it, but I think that that's being fathered.
Yeah, I've I've definitely heard about this idea. I've gotten this feedback already. Actually. It's interesting. So I'll sort of answer this in two ways. One, when one of the advantages of using this field escrow token model is that anyone can stake, anyone can lock. So you don't need 10,000, HNT to lock up and be able to participate and earn for the IOT network or the MOBILE network, or participate in governance, right, you can put one agenti. And, and I think that's a that's a huge one for for a lot of the community who want to be able to participate in this kind of staking. So that's that's one. The other thing, I think, Scott, what you're talking about, and I've heard this feedback as well, which is, you know, it would be nice to be able to kind of signal that you are, you're going to be staking on the other side of the of the transition. And I have a couple of ideas of how we could implement that. So yeah, so if there's a formal proposal on this, I think I think, you know, it can be really, really interesting. I think it could really show that there are validators today who are interested in in staking and sort of locking the veHNT before this migration even happens, it certainly would actually make our jobs a lot easier, I think from a ledger export and import perspective, because we could, then the best time to do it is actually before we help the chain. Great.
Still looking through Yeah, certainly a lot of questions of the core Devs considering any other platforms, L2 roll ups, for instance, what are the trade offs? Consider, I think we've covered a lot on again, like how the how the team came to it again, the the idea that that is really not necessary, the needs from an L1 are very much simplified, given the components run by Oracles. So I'm just trying to see if there's anything that's kind of differentiates on those questions more. So I'm really going through the spreadsheet right now, Joey, if you've got another one handy, because there's an awful lot of these about just getting what specifically about Solana? Again, some of these things, I just want to, you know, at least emphasize from my side, it's not necessarily the technical merits off the fact that, again, you're talking about one of the fastest growing developer ecosystems. And I certainly know there are other L1 ecosystems that have large developer communities that are growing quickly. But as far as the, you know, the developer compute communities the significant composability of other tooling features that are available. Obviously, a benefit of you know, entering into a, an ecosystem that has a large defi ecosystem just opens up more utility for the tokens longer term. So there are certainly a number of things that align beyond just the kind of technical merits of the chain itself. Here's one's a little bit of what impact is there to those of us who are running our own ETL tools, our current data about rewards and witnesses punted to Solana level will this be made available
for free specifically, the term Big Sky
is it safe for you to talk yet, Marc, I know you were kind of waiting.
Depends on my robots feeling right now.
It's like, I can sense that it's there. But maybe maybe it's okay. Did you catch the question? Of course not. Please,
go ahead, Scott.
Sure. So it was what impact is there to those of us running our own ETL cells, our current data about rewards and witnesses punted at Solana level, we'd go blind, how will this be made available for free? It's actually the exact same question right next to it from normally on, which is for those of us stalling the chain by a note or ETL. How will we get new information and ensure consistency with historical records? Right.
Thanks, norm. Yeah, so we will work with will work with ETL to up update to basically ingest files from s3 buckets and update the work tables just like we do today.
Once Once the
change happens to an artist and chain is no longer active. Obviously, that data is you know, it doesn't doesn't.
Set the attempted thing to say there is that trying to get ETL, some equivalent version of ETL. That will exist. So people can consume both the Solana side of the chain, but also the Helium specific things like proof of coverage that or data and Data Credit information. So I'll feel roughly the same. I don't know if it will be one for one match, maybe? I don't know. But I think
I think it'll be really close. I think we get ETL pretty close to at least the PoC and backhand side. Hey, good. Yeah, cuz
there's another question again, similar line of questioning of why would we have to pay for s3 data, we run our own Routers and ETL and get data free? Why? Yeah, basically, people are just concerned about the transparency and being able to access these things for free that they're doing now.
Yeah, I'm open to other ways of doing this. The problem we've had so far is that we get tremendous abuse on anything that we offer for free, and we just had a really hard time like, like being able to justify egress costs the way we have so far. I'm very open to other ways of protecting insane abuse that people are are putting on API's and buckets of any kind that are being offered today.
Maybe we make hotspots IPFS pin everything on the chain as it gets generated?
Oh, yeah, that'll that'll help.
Yeah. There's a couple of questions in here, all sort of asking the same question, which is, how long will this take? So how long will the implementation take to move to Solana and off chain PoC?
I believe the off-chain PoC side of it and the packet, the packet offload side of that will happen in relatively short order. I think I think in the order of of the short the short few months and no guarantees. The actual offload is still on up, we'll probably take a few months to basically get everything everything integrated.
And when what at least?
Yeah, I mean, I think the desire is sort of year's end on on the Solana part, or by the year's end so something like something
like that range? Soon.
Yeah, it's, it's soon for sure. Right. So we think that these two parts can work in parallel. Specifically, the the Oracle side of things can be worked on by the Nova Labs team. And the then the foundation can drive the Solana migration. And, and I think that, you know, if we do this in parallel, you know, one of the things that I think, you know, really is possible is, you know, by the time we're ready to vote, like we actually have a fairly, like, sure way to, to build the off chain things. And, you know, we're actually well, we're actually started this work. I think a few folks in the community have noticed that we, we started prototyping and there's some sort of PR is going around and there's some, some PR is going around for the for the packet verifier. So, I think, you know, as you know, like everything we're building is open source. So it's all it's all out there. And we're already starting to think about this, really, mostly to try to, you know, validate our design that we came up with this is HIP
All right. And I'm only going to drop this in because looks like normally I would just put a follow up to his initial question. He said, to clarify, this is around the kind of the ETL. And the access to data, I said, we're not looking for tooling. We're looking to ensure open access to proof data, otherwise, there's no proof of value. And just confirming the data will be really available to consume from the network as opposed to data dumps or supported tooling. So just making sure that was clarified from Norman, who had the original question around ETL.
I think it's a fair question, I'd like to understand the difference between readily available data versus data dumps. The thinking is you'll have access to the raw ingest data for PoC beacon and witnesses, as well as the right versions of that that basically get get get rewarded. All that will be available, is there going to be like some high level sequel like API to it that I think that's that's to be seen men at a minimum viable industry for you to pick up and entertain whatever way you see fit.
That dropped off a little bit for me at the end there. Oh, good.
I think the summary is that all the data will sit in s3. And anyone can grab it run their own. Oracle, exactly. compare the results with the Oracle that's submitting transactions on chain.
Here's the question a little bit related possibly to the Solana platform. So will the implementation of this HIP affect the ability to utilize ledger wallets and give more access to quote unquote, platforms where tokens are exchanged?
Yeah, I mean, I certainly will. I mean, minimally, you've got all the Solana DEXs, you know, so the decentralized exchanges that are based around Serum. So I personally love that. I think that's that's like I think DEX, DEXs in general are super interesting development. And I think the best ones live on Solana today. And then as I as I mentioned earlier, just general sort of SPL token compatibility is, is pretty large. So HNT and MOBILE and IOT will will become an SPL token, which means that it could be compatible right out the gate with something like ledger, you know, any exchange that's ever listed in SPL token, which is, I think, pretty much all of them will be able to list HNT without having to do any other work. So we've had this challenge with wallets and, you know, like I said, we've, we have we built most of the stuff for Ledger, but we but we had to do it ourselves. And it's still taking Ledger a long time to actually approve HNT. So being able to see having to not do all of that work, I think is a huge win. And allows ideally for greater compatibility with wallets, exchanges, indexes, liquidity pools, any defy things, like could be anything, I've no idea, but it sort of becomes out of our control. It's just an SPL that that can be used like any other SPL on on Solana like USDC.
Here's a question that I've seen kind of come up a couple of different times, I think it's worth addressing the concern. With this change, will HNT become obsolete as a token?
The quick answer is no to really most users shouldn't even notice that it's on a different chain, you'll still have the same wallet app, you'll still have the same Explorer, you know, really you shouldn't notice anything other than your wallet address will be a little bit different. That's but that's about it. So otherwise, everything functionally will be the same agency, it will still be its own token and everything else.
Same same burn utility like yeah, the story we hopefully all know.
Yeah, exactly the same, you know, per what was described in HIP 51. And two and three, but that's Yeah, nothing really changes in that point from that point of view.
As a maybe a follow on to that. I did see some questions. I can't quite remember who to attribute them to, but folks are kind of wondering what their hotspots will be mining in the future. So of course, this opens the question of the IOT token and how it's involved in this change.
Without getting deeply into into HIP 51, I think The easiest thing to say is that the implementation on Solana is intended to be what's described in HIP 51. So LoRaWAN Hotspot would be mining IOT that is redeemable for each entity and 5G Hotspot will be remote will be mining MOBILE, which is also redeemable for agency. So the intention for the migration is to do HIP 51 and HIP 70 At the same time, such that what ends up on Solana is what's described in HIP 51.
I am noting we're at the past the top of the hour, I'd like to sort of fit in probably two or three more questions, I'm just trying to look through and make sure I'm not grabbing anything that's redundant. And there's still questions coming in. So I'm just reviewing those really quickly.
And by the way, as a reminder, this is we're gonna host another AMA sometime next week, I would expect I think we're looking at Wednesday for that. But we'll get an announcement out to the full community on Discord and Twitter for the exact time of that, and for kind of the next round of discussion on this.
And I've seen some comments in the chat saying, you know, this, this call has helped them understand a little bit more what's going on or feel a little more at ease with it. So definitely appreciate those comments and the team that's here appreciate y'all taking the time to jump on in and answer questions. I think we'll see a lot of these questions repeat themselves, it takes a while for this information to get around. For anyone who's listening in, we will try to get a recording of this together and shared. And hopefully you can sort of share some of this information more broadly, just make sure that the community has an understanding of what's going on.
And something else actually gives them also kind of scan to the check quickly. So for stuff like you know, I see some comments here on hacks on the Solana network. So something to bear in mind, again, like that the those are, at least the one that I'm thinking of is that you know, that's going to happen at the application layer, it's not something that was the base layer, to the best of my knowledge has not been hacked, I think we're talking about things that happen at the application layer where they were vulnerabilities around wallets. So that's not something that would affect again, that's not saying that would affect what we're looking to do here. Those are application specific versus network issues. So and this is just, you know, just saying to be mindful of for everybody, there's a lot of FUD that gets spread around Twitter for I mean, you know, really what L1 hasn't faced its own share of folks are kind of gaslighting or casting fear and doubt. So just make sure for anything that you're reading and reviewing that understanding where the real root issue was, if it was a network issue versus an application issue, just to make sure we're
all bearing in mind.
Joey, anything else? I'm just kind of going through the questions. So I think there's still a lot of things that were kind of again,
some Yeah, and I think Dal may have kind of covered this. And Dal, I don't know if you want to jump back in here. But there is a question that's asking, Is this switch going to make it easier to run a private Console for IOT devices? And reason I wanted to feel this is just of course, usage of the network has been sort of top of mind for folks lately.
Yeah. Thanks, Joey. Yeah, absolutely. If you think about it, right. Now, if you want to use the network, you're kind of restricted to this cultural router that we built. That is, frankly, unlike any other LNS that's out there. So again, how do we increase accessibility? How do we increase usage? This is what this new architecture is about. And so folks can take whatever LMS they they're using, whether it's church stack, whether it's another LNS and plug in and started using the network and so we're pretty excited about you know, the team is really able to double down and shift focus and and create the foundation to allow anyone high confidence to start using the network.
I'm personally excited about that. Yeah, I'm getting comments saying just that my head hurts. So it's definitely a lot absorbing all of this, so appreciate everyone taking the time to understand it. Here's a question from Hans that I wanted to throw in here. So what is the long term outlook for Oracle's? Are there any ideas to decentralize them similar to how validators work today
I don't think we have a perfect plan for this yet. My perspective on it is that priority number one is to make the transition to get, you know, proof of coverage and data transfer to be reliable and secure. And so I think there's a lot of like rapid iteration that is needed on proof of coverage, especially where we've had lots of ideas just kind of sitting, you know, we've got some tech is interested in building a secure, like, LoRaWAN mapping device. And like, you know, we've got so many, like, potentially interesting approaches, HIP 22, as I mentioned, there's also a bunch of data science stuff that we've been looking at that is also really interesting. And so being able to go quickly on that stuff is a benefit of, of, of having this Oracle model versus everything being bundled into the consensus protocol. So or being part of consensus, I should say, so that the, the goal there is to like, do that, right, get everything to be, you know, at least in a significantly better place than it is today, minimally be quite reliable, and then start focusing on like how to how to distribute that a little bit more, or open it in such a way that someone could, for example, state, a proof of coverage Oracle, and join the pool, just like they do with validators today, I think minimally, it's critical that the work that the Oracles do is verifiable and inspectable and observable. So that's kind of like a minimum requirement is that we have to, to ensure that that works. And I think the way mark described, it should make sense to everyone. And all that code will be open source and then fix, make it better make it faster and then spend the time on how do we how do we turn it into a sort of more permissionless Validator? Like, model? At least that's the that's the plan in my head right now. All right, I
think now that we're about 12 minutes after the top of the hour. Again, we're going to have more discussions on this making sure that we're addressing first question not just in Discord, but you know, creating the space for for
live discussions. So
we'll be at least an AMA. Next week. We'll get back to folks at time on that happy to continue the discussion between everyone on Discord but certainly I think we could keep going on and on. And a lot of the questions that at least I'm scanning right now do seem to be a little bit on the repetitive sides of the day that we didn't address and Miss obviously, there's a lot to go through here today. Let's get those going in Discord will try to get a another form out potentially ahead of the AMA to see if there's anything that's notably different that we need to address but I do appreciate everybody taking the time. Again, please read the HIP in detail allows for us to have more productive discussions. But thank you to Amir of I mark for the clarification on some of the development areas. Joey is my partner in crime from Foundation. Thank you for helping with moderating and running through the questions. And otherwise, I look forward to seeing everybody in Discord and also in a few weeks for those who are going to make it to New York.
