Solana Foundation Validator Discussion - September 10 2026 transcript

All right, we are going. Welcome everyone to the Sonic Foundation validator discussion uh September 10th, 2026. So on the agenda today, we've got validator updates. Uh ready layer 1 is here to talk about Salana change log. Um he'll give you kind of an overview of what he's been working on and get validators to you know tune in. Uh a reminder about upcoming events 200 milliseconds scale or die block zero and breakpoint of course.

Uh then I thought we'd talk a bit about the governance process and ways we can improve and change going forward. Uh then any other discussion items. Um, yeah. So, maybe I'll open it up just to Anza first if you all want to give an update. Steve, if you're here, then I can fill in any gaps. >> Yeah, sounds good. I guess I'll try not to touch on or let you get those other items. So, um, looking at the list you sent me of stuff beforehand.

So, SIMD123, I guess, yeah, people are curious about that. I actually don't have any update. I think the people who have the absolute latest are likely asleep already um or asleep by the time the request came in. So I'm going to punt on that one, but maybe for the community call I'll try to dig something up. Um for test net failed restart, uh we're looking into that. I think us and fire dancer there was a few there were some fire dancer crashes which we don't think actually I think latest is that didn't actually impact the failed restart.

So we're digging around. uh people are are I think that was a result of um like the cluster failing to restart. So yeah, we're still digging on that. Nothing uh no use no news yet and we'll post like announcements when we want people to give it a go. But um you know this is test net working as intended. So um you know we're looking into the issue. I think it's ultimately I think it's something we might have observed previously where there's kind of like a mismatch of uh or like an inconsistent view of gossip when the cluster starts like some nodes start some nodes don't.

So anyways we're on it um looking for okay so uh rent reduction and slot time reduction. So yeah the mainet has the first rent reduction um and then the two out of four slot time reductions. So um I think the original plan was yeah just activate some and then you know kind of like or activate sit and wait and observe and then you know move accordingly. Um as far as slot times go I think we we are looking I I think like technically the validator can handle it.

I think there are some concerns about uh vote latency and like the nonhubs. Um so I think team's still looking um but for now you know we don't want to like kill uh or like punish people for you know in the spirit of decentralization like you know on like Southeast Asia or South America or whatever. So again teams keep an eye on it ultimately we don't want to um you know punish people for that. So um I think probably holding for for now but uh again just we'll we'll act as metrics uh tell us that you know it's good to go.

As for rent reduction, um yeah, not positive when we'll send the next one. Um this was similar is like you want to activate some and then kind of see how the network responds. This one's kind of different because you know like hypothetically a rent reduction should enable like some external thing like you know it's like people will be lured to build on Solana. So um this is one where like yeah we created a bunch of inter im inter immediate steps with the hopes that you know it might enable or you know enable new businesses or make other operations cheaper.

So um this one's a little more nebulous to me. I don't know exactly when we'll send the next one. So, um I mean the the second one's in the queue already or you know it's I think it's ready to go but um unsure but similar it's we don't want to like open the floodgates and then have to like you know have the cluster start sucking. So um you know just we're being cautious with it. Um there's a question about double disinflation.

So yeah I think the actual implementation itself is pretty trivial. Um, that being said, there was a precursor SIMD. Uh, I forget which number it is, maybe like 607 or something. Um, it was trying, we're trying to do some clean up along the way and get some floatingoint math um out of the path. So, I think that one I think we're going to try to get that done. Um, and then could do double this inflation, which was 558 if I'm not mistaken.

Um, yeah. And then the last one Tim asked me about was Alpenlow. So yeah, we're um still deliberating uh internally. Uh I mean, yeah, we've really hammered this thing. Um we've had, you know, a bunch of audits uh both internal and external. We had the bug bounty competition which, you know, we basically got hund, you know, many many external auditors. I think we'll eventually have a tweet where we release some cool numbers on that.

But overall, that bug bounty competition was a a big success in our eyes. Uh and then yeah, Ashwin and team have been hammering with the community cluster and obviously you guys running nodes. So um you know ultimately we are you know we want to be cautious and make sure that you know the cluster stays up. Um I think there was a failed restart that was due to uh I think there was a bug in Jetto that caused the nodes to start migration early.

Um, so I think we're I can't remember the latest restart attempt if we've gotten up with like the stake distributed on you know to match actual mainet like jetto and harmonic and etc because not everybody is actually running or not many people are actually running uh agave on mainet. So um yeah I think we're continuing to experiment still keeping our options open for 4.3 um so stay tuned for that I guess. Um, and then, uh, Tim, you also had a question about some permission collector stuff.

Um, yeah, there's a few PRs up for, I think, configuring those in the Salana CLI. They're they landed in master. I think we're debating whether to backport them to 4.3. Um, I think these are heavily I I might be partially mistaken, but I think these these were in line for CID123, so it wasn't clear to me if they'd have much utility beforehand. Um I'm but yeah that might be a misinformed take but either way uh it'll be in 4.4 maybe 4.3 um TBD on that.

Um otherwise yeah the general plug. So yeah we started the 10% call uh or the 10% for 4.3 domainet. So appreciate the early adopters. Uh we are being better about getting our node upgraded early. So you know we're you know we're asking you to run the code so we're running it too. Um but yeah h excited to get mainet to 4.3 and you know keep the uh you know at this point in our eyes the welloiled release machine rolling and you know keep improvements and upgrades rolling to the to the cluster.

So feel like I've been talking for uh long enough so uh I'm going to cut myself there. Um yeah any other questions Tim or anything else any wants me to uh comment on let me know. Nothing from me. Curious there's questions from the audience. >> I'll keep an eye on the chat too if you want to push on and I can respond to stuff there too. >> Um, so a couple other things to fill in from mainet if there's no other questions.

Ah, question about the version floor. >> I'll handle that in the chat. >> Okay, cool. Uh, yeah. So, if you are running JTO, please upgrade to version 4.2.2. 2 as soon as possible. Uh for transaction v1 only 4.2.2 supports those transactions. Uh that will activate this Monday. So the start of epoch 1035. Um I don't know if I saw Alejandro if anyone from Gio wants to comment a little bit there on like uh context on why 4.2.2 is required.

Uh be helpful or if there's anything to add. Yeah, it's just because uh I believe the originally TXV1 was required for uh 4.2.1, correct? And and we didn't incorporate until 4.2.2. So that's kind of like the main reason behind it. >> Okay. Yeah. Um so yeah, anyway, TLDDR there is 4.2.2. Sorry, 4.2.2. Please uh upgrade as soon as possible if you're running JTO. Um sorry, I got a lot going on here. Um, and then there was an announcement for uh, Fire Dancer that maybe some of you saw in the Slack channel or just saw now in um, Discord.

I don't know if the Fire Dancer team is here or wants to comment on that. >> Comment. >> Perhaps they're here. Yeah. Any comments from you all? If not, I can fill in kind of the details. Yeah, I mean kind of what we said before, uh, Barancer now have a bunch of releases ready on mainet. Uh, frank will be end of life, uh, when basically Alpen go activates on mainet right up until the feature activation. Um, just a little too difficult for us to support two clients through that transition.

Um, and as well as you've probably seen with the two failed migration test migrations and helping, it's tricky to get right. Uh so cloudons will also not be participating um in the offload migration period but we'll have a build ready uh for immediately after that migration. So as soon as the migration completes there's no block packing or anything really happening in there anyway. Um soon as that completes you can switch back to fire announcer release.

Um yeah that's kind of the summary. >> Cool. Yeah thank you. Um, so yeah, again, thanks to all the operators for running Franken Dancer and especially those early adopters. Um, I, you know, was involved in getting a lot of the people to run the first Franken Dancer release way back when. Uh, so really cool to see it being deprecated in full fire dancer taken over. Um, any questions on that process? If you're a Franken Dancer operator, what you had to do? >> Go ahead.

Sorry if there was a hand or maybe I just heard a message. Uh okay. Yeah, sorry just a message in the chat. All right. Um yeah, so TLDDR uh Franken Dancens is getting deprecated. Uh Fire Dancer will be the only supported one after Alenlow. Please upgrade to Fire Dancer and during the Alenlow migration uh switch to Agave for that short period. Um, okay. Test net, I think we covered this already. Uh, test net's down. The restart is being investigated.

Uh, recommended versions are there. Um, I don't think there's much to say in addition. Any questions about test net or the restart from the update? No. All right. Then I will hand it over to uh ready layer one Jose who's on the call very late his time uh to to plug the change log that he's been working on and uh you know give you a little intro. >> Yeah. Uh hi everyone. So it'll be my first time talking to the validators as a whole.

Really happy to meet all of you because you guys kind of judge the chain. Um you guys are kind of the final judge and jury and happy to meet you guys. Um the motivation for me like talking about change log here is um I'd cover I'd cover like a change that would happen on a sim on a like on May and then I'd see kind of the same similar discussion happening around August and like the solo tech discord from a bunch of stakeholders and what I'd like to and one of the things I realized was that there is a gap between at least it's not clear who's responsible but there is a gap between comms between when these engineering changes happened and um whether concerns with from you guys get addressed right away.

And so I thought what could I do in order to bridge that gap between you and all these engineering changes? And the one thing I realized is that oh I've I've been doing this newsletter for a while and I've been working with Foundation to get this out there. why don't I just come on on this call and tell people what it's about and see if there's any value for you and see what you'd like to see and hear what you'd like to see from the change log so we could better cater to people who operate validators.

So just to give a rundown as to what the sections are about. Um we do this every week um 9:00 a.m. Eastern time on a Thursday and I do a live stream as well in case you don't want to read um walls of text. So the sections are well there there's the live stream link is there any major announcements of course v1 is this week any major feature gate uh releases on all clusters we also cover all of the major versions for a bunch of software so you know RPC 2.0 know any of the web clients, any programming frameworks and um any programs as well?

And I think more relevant to you folks is when new sims are out, I actually cover them and kind of give a brief rundown as to what that actually means for people for the network as a whole. And then any performance improvements on any of the validator implementations. So Agave Fire Dance and V3 I'll cover um this is actually a link to a PR. So if you're interested in this particular change, you can actually go um click on that link and it'll take you to the GitHub discussion.

And I do this every week. And then obviously RPC 2.0 uh all of the language clients and any of the program frameworks, any of the testing frameworks and other interesting things that don't necessarily fit in with um all those categories. So any talks given at rust conf like autofuzzer software uh VRF implementation and again rust comp so anything technical that shows up that might be interesting I cover right now it's mostly catered to devs but I understand that you guys there's a governance process now so you do vote on changes that happen on chain so I'm wondering if what what content could I add to this newsletter that would benefit you folks?

Um, be happy to hear your thoughts later in the Q&A section. But that's it for me. Thank you very much, Tim. And I hope you guys follow along every week so that um, you guys could be updated as soon as these things are out so that you guys could be more informed and you could make better decisions and we could eil as fast as we can. Thank you so much, Tim, for the opportunity. >> Thank you. Uh any questions or suggestions?

I'll put a link in there. >> You guys can follow um you guys can follow x.com salana_devs. That's the foundation dev account. I stream there and I post the article there as well. >> It's also on salana.com, right? >> Yes, it's also on salana.com. that there's a little bit of a delay because um I believe Foundation does a little bit of a check before they post it on the main Solana website for obvious reasons, but it's more or less the same content as well. >> Any suggestions for topics uh for the change log or feedback? >> All right.

Uh well, thank you and we will move on. Okay. Uh here's our regular plug for events coming up around Breakpoint. Uh so as always, we've got the 200 milliseconds uh slashdefi day rebranded 200 milliseconds. Um scale or die is on the 14th now, separate from Breakpoint. Uh so if you were in New York for this event before, this is a technical focused event where we're going to dive into like uh interesting products that are technically focused, not so much like the product side, more the you know what engineering thing was built.

Um core dev announcements, uh things like that, right? More more for the technical crowd, more for the developer. Um block zero of course on the 15th and then breakpoint the 15th to the 17th. Um, any other context or additions for any of these events? I know we have organizers on the call. >> Um, you know, one thing I'll add for all of you who've, um, submitted applications for block zero, uh, thank you. And we haven't started accepting or admitting people yet.

We tend to do that relatively late. Um, so don't worry if you haven't received a confirmation yet. it'll be okay. Um especially if you're a validator, like if you're a validator, you will get in. Um and uh but otherwise, don't be surprised if you haven't heard from us. Um and then I see Alejandro noted uh that we're still taking some uh submissions for speaking topics at block zero. Um, so talk to Alejandro also Chris uh from uh Chainflow and um yeah so I think that's that.

Um >> right I got a quick question. >> So people have been asking about the the London trip the to the cipher. What's the best way for people to sign up for that? >> Uh sold out already. Yeah. Yeah. Yeah. 12 went like that. Um, yeah. I'm gonna Let me check something though. Uh, there might be another plan B for people who want to who want to show up. Um, bug me offline and uh and we'll see what we can do there. But that Yeah, that one sold out like immediately. >> Yeah, not necessarily for me, but just people have been asking.

I've been like, "Oh, I'm like, "Yeah, DM Brian, but you probably don't want you're probably getting a lot of DMs about it." So, I'll let them know that it's full, then maybe something will pop up. >> Yeah. Yeah, I need to give that a think. Um, and for context, what what he's asking about is uh Bletchley Park uh to do a field trip on November 12th uh up to Bletchley Park. Um that's where in World War II, um the Allies cracked the Nazi Enigma code.

And it's just a really cool opportunity to be in the place where, you know, cryptographic milestones happened. And um so yeah, let me bug me on that, Brian. I we'll see if we can't figure something out here. >> Thank you. >> Great. Thanks, Brian. And yeah, please sign up. Uh all the pre-events, I think, are where the meta is at. So, you know, 200 milliseconds, scale or die, block zero are definitely events you don't want to miss.

All right. Uh, governance retro. So, um, just a reminder, SGP1, the salon constitution has passed. Uh, double disinflation, SGP2 has passed and SGP3 resource inclusion fee has failed. Um, I thought it'd be useful to talk a bit about the process and things that we can improve on. Uh Micaia is here from the Salana Foundation to talk a bit as well about potential changes that we might uh implement in the tooling to help support some of these changes.

Um so I think first I'll just kind of highlight a few things that I noticed uh give the floor to Micaia and then kind of open up discussion more widely. So some of the things that came up quite a bit when we were talking about governance is what is the process for an SGP change during the the vote? Um, obviously you don't want to change the SGP while the vote is happening because you're sort of alienating people that have already voted.

Uh, but there were a couple instances of changes that I think Kave wanted to do to his proposal. Um, we should come up with a process to allow that to happen at some phase. Uh, so we've got a suggestion for that. Um, the quorum and the criteria for passage were obviously heavily debated on the timeline. Uh so curious what people people's thoughts are there and then the vote timing. Um so because of the shrinking slot times um we actually had to fight a little bit to get the reduction from 350 milliseconds to 300 sec 300 milliseconds delayed by an epoch uh so it wouldn't affect the final vote.

Um the suggestion there is to move from epoch times so we're not affected by uh faster or slower epochs to wall clock time so every vote gets let's say the same week of time to vote. Um so those are the things I've noticed. Uh I'm sure there's other topics uh but I think I'll pass it to Micaia first to talk about uh the first one changes to the SGPS. >> Yeah. So, um, currently when you create a proposal on chain, you have like a a description that's meant to be a link to the SGP repo.

Currently, it's it's kind of loosey goosey. You could just link to anything in the SGTP repo. So, um, you know, it's been pull requests in the past. So, one thing we want to do is just make that uh, it has to point to a a static markdown file and have it point to a markdown file at a specific commit. So, um, what's being voted on is a specific, you know, a specific change that is directly linked to and is static and can't change.

Um, and then adding a mechanism to update that link all the way up until the voting actually starts. So during the discussion period, if people you know are nitpicking about specific things in the document, the author can update it, merge it, and now there's a new commit hash to point to. There's an instruction where the creator of the proposal can there then go and update update the description uh update the link to a different document or a different um commit hash.

From there, once voting starts, that instruction will no longer work for the proposal. So pretty much all the way up until during the discussion phase, you can change the document as many times as you need to and revise it. Once voting starts, it's static. So everyone is voting on the same thing. At that point, if there are more little changes that need to be made, then it's it's another proposal. Um, but at least we have some mechanism to uh keep that document kind of living up until the vote starts.

So that's the current proposal for how how we plan to implement it. I'd love to hear any thoughts or reasons to not move forward with that. Um, yeah. >> Yeah. Go ahead. Um, Brian. >> Brian with an I or Brian with a Y. >> I think I beat the Y. >> Um, I I mean having that discussion period ahead of time, uh, you know, sounds fantastic. Um the only question I had is is there a process for the author to withdraw a proposal and then resubmit it later.

So let's say the discussion just like totally goes in a different direction. The the author the proponent says you know actually I like that different direction but I should probably withdraw this thing. Um do we have that in place? We don't I mean um when the proposal is created uh it's not just the discussion phase where things can um change it's also in the support phase right so before it even start begins the formal discussion you validators have to you know has to garner enough support I would think if if uh if it is so early on the STP that like so many details are changing then it's unlikely to get that support.

Um, but I maybe it's worth considering that the author can just uh pull it out. I don't know it at the same level if it has reached support that means you validators have signaled that this is worth voting on and then the validate the original author having the power to never mind I don't like where this is going. I'm going to pull the vote. That seems like maybe too much power for the author to have. Um, so it seems, you know, I think the the proposal garnering enough support that mechanism we have seems like a fair way to to, you know, gauge that. >> Okay.

Yeah, I was just curious. So, >> yeah, thanks. >> I hadn't really thought about it, but uh I'll think about it some more. >> I I can actually comment on that. So, when when I was at Star Atlas, we had I think we've done like 20 um proposals. There was a certain instances where the author if they felt like they weren't getting enough support, they would there was what happened one time where they pulled it. But the way that um these proposals work is you don't actually know if someone's going to vote yes or no.

And then you could see a timeline where someone's trashing your proposal and actually that's just one guy that doesn't actually represent the voters. So, I think giving them the ability to with withdraw actually might be detrimental because then they may see something and get worried and pull it when it may not be the case at all. And I also agree with Mai like if if we supported it and we should be able to go to vote even if that vote is going to be no because that really says no.

Um and then my original question Ma so part of the current review phase discussion phase is that people have enough time to review the SGP before they vote if authors can make changes all the way up until the voting period starts. And that means that about um stakers only have the voting period to review that the change what might come like let's say at the very last epoch. Are you planning on doing a discussion and then like a like a two period just like review so everyone has a chance to review and then vote or what are your thoughts on that? >> Um I think that as long as the voting phase is sufficiently long to review.

Um I feel like there's kind of two groups of people. There's those that are going to follow along in the discussion and then there are those that no matter how long the discussion phase is, they're going to be voting. they're gonna they're not going to look at it until it's time to vote and they've got three hours left to vote and you know so I I don't know if it's worth putting too much effort into you know having these separate phases as long as the discussion phase is long enough to argue about it voting phase is long enough to read it understand it ponder it vote I think that's that's the the most work we should put into it because otherwise it just adds to the complexity in a way that's you know hard to understand hard to manage and not worthwhile in my opinion Yeah, makes a lot of sense. >> Echo KV's thought there, too.

We also have the NCN snapshot epoch, so that could sort of function as that review phase before the vote because I would think you'd want to stop the updates before the snapshot anyway. >> Yeah. >> Um, cool. Nick, go ahead. >> Um, yeah. Um I for one I think I'm so glad we've got that change of being able to edit the proposals in that it's now a discussion period again. So we kind of discovered that fairly late on it's immutable.

So the kind of discussion period turned into a review period. So this makes it a discussion period again which is fantastic. I think um having some process around um there is a question about like if there's a significant change is there such a significant change that all of a sudden the the the kind of right at the death of the discussion period the you know has there been sufficient time to to look at it um but yeah I think the the change is really good I think we to Brian's point we did have an idea of a life cycle states of the proposals where withdraw was one of them.

Um so I don't know if there's a potential for us to be able to um do some kind of repo based governance where we can tag them. The idea these were just tags where things were in like draft phase like a final draft which would mean it was like eligible for uh the authors are looking for it to be elevated. Uh so it might be just something that we can do um just in the uh in the proposal uh drafts themselves where you can just tag uh withdrawn or something uh prior to the elevation.

So the kind of uh there may be some something that we can do pre- the elevation phase um to withdraw or something like that. But yeah, we do have uh these this idea of a proposal life cycle in the um in the constitution. But yeah, super pleased with the with the update on that. >> Yeah, with the the possibility of withdrawing, I guess my question is if if it has reached a support threshold and then now the author wants to withdraw, do they do validators vote again to decide if it can be withdrawn? you know, because we don't want the author to be able to abuse that power to withdraw things because it's not going their way or they think it's not going to go their way, which yeah, as Brian Cole said, you really don't know.

We saw the double disinflation, but we didn't know what was going to happen until the last five minutes to that thing. So, uh, >> yeah, I was thinking actually the withdrawal thing would be pre-elevation, so there's just some some opportunity for like proposals to be sitting in the track before they go to elevation or something like that. >> Gotcha. Um, so yeah, I agree with you. I don't think they should be withdrawable once they go to elevation.

Uh, and yeah, it was uh I looked at this the other it was 22 slots in the end uh where >> Wow. >> swung it at the end which is it was close. >> Yeah. I I mean I wonder if um to your point like so currently when you create a proposal it is ready to start you know either if the time has started ticking for how much time it has to reach enough support to go to vote um but the proposal can be created in the STP repo any point and you don't actually have to create the proposal on chain yet um I wonder if it would be good enough to have a way in the front end to pull those in like in the you know you go to governance.salono.com and we have some like draft proposals that aren't on chain yet.

There's a place where it's like a central place to see all of these that isn't GitHub doesn't look quite as intimidating and um people can go and see oh these are all the proposals that are kind of being worked on and these are the ones that are you know in the support phase these are the ones in the discussion phase and voting phase etc. That that seems like a simple workaround that doesn't even we don't have to bother with anything onchain which I'm always a fan of.

I was thinking offchain stuff beforehand. Yeah. >> Yeah. I like it. I'll make an issue for that. It's a good call. >> We'll definitely have to place that for spam, but I think that will be a good solution. >> Yeah. Yeah. If if there's a tag on GitHub that um the maintainers of the SPGP repo can add, Tim, like if a you know >> Oh, yeah. >> you tag it as it's a it's a draft, you know, it's going to be voted on eventually.

We just haven't created it yet. and then it the front end pulls that. That would be perfect. >> Yeah. Yeah, good idea. Um, okay, switch topics a bit. Let's talk about quorum and passage criteria. Um, there was obviously a lot of debate after SGP 003 didn't pass. Um, I'm curious what people's thoughts are and kind of like where the the crowd wants to go. I think, you know, anyway, without giving my own opinions first, I want to get feedback.

So what are people's thoughts both on having the 33% quorum including for against and abstained and then the passage being for over against and abstain greater than 2/3. >> Uh yeah, Brian, go ahead. >> Um I'll I'll make the case uh that it should be a little bit harder uh to pass an SGP. um that we want our standards to be high uh you know before we make any changes to the L1 um that uh you know we need to set a pretty high bar and so for that reason um I would say that once quorum has been met that the proponent their challenge isn't to get the win of yes versus no their challenge is to get at least twothirds of the quorum yes and that's a higher standard right Um, and that does allow then for people to abstain.

Um, which is a valid vote for different reasons. Uh, and we could go into that as kind of a separate topic. Um, but yeah, in my mind, these things should be kind of hard. You know, we we should have the standards high. Um, in the case of SGP2, I mean, that was a legit win, right? I mean they they they worked it hard in the end and they got it in just slots before the uh the the um the whistle went off for the end of time.

Uh so the um so that was pretty cool and um yeah and again we can talk about extensions as a a separate discussion point but but that's my point here is I think these things should be hard. It shouldn't be too easy to to uh to change the L1. >> Yeah. Go ahead. >> Uh Nick, I think is next. Sorry, I've got too many screens going on. >> I'm happy to go last. Brian, I think. Do you want to >> Oh, I'm going to disagree with Brian Long here.

And I actually think that making it too hard is is bad because the chain has so many different interests. Like we barely passed the dis um disinflation because MERT was, you know, on Twitter calling up 500 people. I was messaging, you know, 500 people. Like we were all grinding the last half hour. And if we weren't doing that, it wouldn't have passed. And then what if if this isn't going to pass? what would pass like we're just going to kind of you know hold the chain hostage and I'd also say that there's plenty of stuff that passes without any votes.

So I'm not really worried about something bad happening because first it has to go through has to have a technical author, right? It it still has and once it's voted on, it still has to be implemented. So we have thousands of checks and balances. It's not like um you know the vote for one of the Dow governance where you know they voted and they automatically sent all their coins out because it was onchain automation governance.

This is not it at all. we don't have to have 80% yeses because we have so many checks and balances before and after. So, I'm I'm in favor of, you know, removing. And also, I just think abstain is just kind of kind of crap. Like, if you're going to if you feel strongly about something, vote no or vote yes. And if you're going to abstain, then then abstain. Don't be part of the decision-making. like pulling it out because if you abstain you are part of the process but you're just that's yeah that's my thoughts on that >> and my my quick response would be uh good job and that's actually what you guys did was an example of how to do it there there was enough controversy there or enough different points of view on SGP2 um but you guys you worked damn hard and you got it over the goal line in the end um and I would say that's an example of how we want this to work and um that if it is a really really tough decision uh we wouldn't want that to slide through uh due to apathy at a lower level.

So yeah, I'm I'm holding you guys up as the example for you know this was really constructive uh the way that it it all came down. So >> So what do you what do you think? >> So they're thinking about making uh votes private. If they're private, we would never be able to do that. So like what what would you think at that point? >> I mean that that's interesting, right? Um I mean having the public votes uh for validators to signal which way they're voting is important for stakeholders, too.

Um and the um yeah, some good questions, but I can see where individual stakeholders might value privacy. um that if they're overriding a validator, they may not want the world to know um you know that and um yeah, maybe we need to spend more time on that, but it could it could even be a hybrid solution. >> I know Nick is being patient here. He's waiting. >> Go ahead, Nick. >> Um yeah, so there's a I just want to kind of like give you a bit of context on on how we ended up at that.

For one, the uh the sequencing was a bit of a nightmare. Uh permissionless voting me mechanisms can fire at every time. So we were in a situation where like two and three had uh triggered before one, which was uh not ideal. Um so yeah, there was a a call to be made on how to calculate abstensions. After all of the constitution uh deliberation we did, we'd got to the end and I did a final check against the uh SVM gov contracts and the constitution and we hadn't accounted for abstains.

So yeah, I was uh worried about a low bar I think um on the kind of height of the bar if you like as a dynamic. So I'll just kind of like go over the sort of trade-off space. um if the the worst thing that can happen I think in one of these governance mechanisms is if too many proposals come through and it kind of delegitimizes the whole mechanism. So if if proposals get through that the network really isn't in strong support of and you would just know that um network sentiment isn't behind it then the whole mechanism starts to delegitimize and that's so that was the kind of main worry I had.

So I think the the high bar is necessary. Um the the kind of situation I was worried about was with let's say a quorum of um 33% where there's a lot of abstains which you can imagine happening with a very complex proposal which I think SGP3 picked up a lot of abstains because it was much more technical uh than the other ones. So that that's a possibility. You can have a super supermajority passes with lots of abstains with like 3% of network state for example.

So that's the kind of scenario that I was kind of worried about. Um so I think we should find a mechanism that um avoids that. Um I think there's a few levers to play with. Um if we um do not count abstains um at the moment abstains count in the quorum but and also in the votes. Uh you can have them count in the quorum uh and then not in the vote. Uh or you can have um the abstains not count at all. So it's like do we want do we want abstain to be meaningful?

I know Brian was saying like abstains don't matter that much. we don't it's in the mechanism but we don't necessarily need to lean into them too much. Um so yeah I think the possible levers are we could have just yes no votes count to quorum. So in the um uh SPL gov contracts we have on chains kind of our uh enshrined um DAO contract abstains don't count towards quorum which avoids this um really low supermajority thing.

Um, so yeah, I think there's there's some levers we've got to play with. I think this bar should be high to avoid this um uh scenario of too many uh proposals coming through and then we just stop ignore uh um justifying the voting mechanism. Um but yeah, I'm keen to sort of thrash this out. I think we can have a more detailed um sort of debate about it in the uh maybe the next community call, but there's a there's a bunch of possible ways around it.

But I'm totally happy for Abstain to come out. I know a lot of people didn't like it and I I think um on on the kind of point of SGP2 it was controversial. So yeah, it just passed but there was a lot of network stakeholders that didn't want it to pass quite directly because it infect affected their businesses. So I think um it did pass with a what I call hard supermajority. It was very legitimate. I think everyone is fully on board with that.

Uh I think if the stains weren't in there then SGP3 would have passed um with a landslide actually about 73% pass which I don't think that was an accurate measure of network sentiment and I do think that the outcome was great actually. I think um we're going to have a revisit of SGP3 and I think it'll come back a better proposal. Um so yeah I think outcome was great but um certainly keen to um find the voting calculation solution that everyone's sort of happy with.

Uh Chris, >> thanks. I I'll keep my response shorter because I think it's just echoing a lot of what you said. I think I think what I've seen in the past with many governance systems is people interpret the governance systems as a yes mechanism. It's like, okay, we're just putting up a proposal. It's a formality. Everybody should be voting yes for the good of the chain and that's that. And I think that really sells governance systems short.

I was really happy to see the level of constructive debate that happened around these proposals. I mean, I think it was largely constructive and didn't really devolve into name calling and personal attacks, which I think was really, really, really positive. So, you know, echoing what Brian Long said, I think, you know, because the quor, you know, because the passing threshold is so high, it's going to take work to to pass changes.

And I think that's the way they should work. You know, I think we should be debating things. I think people should be able to express dissenting opinions and you know that's what happened here and you know I think the network's better off because of it. So I also think that you know we should keep the bar pretty high to pass to make a change. Um because otherwise what I've seen so many times in the past is that a governance process just becomes a rubber stamp.

Yes. And it just defeats the whole purpose and really delegitimizes the entire process. And then briefly on the abstain idea, I mean, I really like the idea of keeping the abstain in there because in a world where everybody needs to be an expert on everything, I think it's refreshing when somebody can say, "Hey, I'm not an expert on this. You know, I don't have a strong opinion or maybe I shouldn't have a strong opinion." But I think abstain allows people to signal at the same time that, you know, they're still paying attention.

So, I think I think there's a very legitimate use of abstain. Um, but then as Nick said, how it gets counted is probably something we should revisit and we could definitely add this to the next community call in a couple weeks. >> Okay, go ahead. >> Oh, is that inverting? >> My bad. Can you hear me? >> Yeah. Yeah, go ahead. Yeah. I I do wonder if uh part of the reason we had a high level of abstains is the front end does not currently communicate well what that means.

Like people might not have known that them abstaining is counting as a no when it actually goes to vote and uh I think doing a better job to communicate that in the front end like m maybe it's I guess not worth making this decision until we've done some more votes to understand how how often are people abstaining and is this an actual problem. You know, we've only done three votes with a kind of a V1 test trial, and it just seems like we need more information in my opinion at this point. >> You say that, but there's a good chance that people won't read the tool tip that you put on the abstain. >> I know.

I know. >> Sorry. Sorry, Tim. No problem. I I was just going to add my opinion. I think for what it's worth, I I really like the idea of quorum being just for and against. It seems like a nice happy medium to me. So if you have quorum be just for and against, not abstain, then the bar for like getting a vote over the line is still pretty high because you know at least one-third of the network is actually voting, one-third of stake.

Um and then a problem I saw a lot when I was talking with uh different validators helping them vote especially on the institutional side is that for whatever reason compliance or the clients they're working with or whatever they wanted to abstain but the semantics they thought that they were voting for was not abstain means no. It meant what they thought it meant was abstain means I'm just not involved but I I'm like signaling that I'm paying attention to this process and I care.

I'm just for whatever reason voting to abstain because I can't participate legally or because my uh clients don't want me to participate etc. Um, so I I think that I'd like that semantic to be carried forward go, you know, like I'd like that to be how abstain actually works personally. And Tim, I think that makes sense because if if institutional um stakers are voting uh they if they can't vote because for legal reasons, but then they abstain and that actually affects the vote, then they're actually kind of going against their mandate.

So for me, if they're just there to say, I'm paying attention, but I can't sway the vote either way, then that should be in my mind. That's how abstaining should work. It shouldn't affect the yes no vote. It should be there, you're there, I'm here, I'm paying attention. Sorry, I can't vote. I can't affect it. And that would actually fall in line with their legal, you know, their legal team saying, you can't vote on this. >> Yeah.

And with uh with Tim's comment about having yes plus no equal the quorum. So, you got to get up over a third stake for those two combined. Um, then yeah, the bar is still sufficiently high. Um, like Tim said, um, what's interesting though, uh, so Brian with a Y. Um, would SGP2 have actually passed with that standard or would it have fallen short? I think it would have fallen short. >> No, it would have. It would have passed. >> Oh, great.

Okay. >> Yeah. Yeah, it would have. Yeah. >> Yeah. the the only danger is the kind of edge case that you get kind of low just let's say threshold turnout at quorum and you get just bare supermajority you can get a yes on 22% network stake so you you could um there's an argument for maybe we should raise the quantum threshold if we do that I think that's the how many yeses do we want for a vote to be considered legitimate uh in that scenario and then you can like we we got over 50% of quorum uh on on each of them.

So I think there's potentially 40% or or maybe even higher for the quorum could do it. Uh but that means that at threshold uh what is the passing what is passing yeses. So 22% at threshold currently maybe want that bit higher. I think that's the kind of design space. >> Makes sense. >> All right. One more topic I'd like to sneak in before the call ends. Uh, sorry Matias, we haven't heard from you. Go ahead and >> I was just going to add a final point which uh was Can you hear me? >> Go ahead. >> Um, yeah, you can't partially vote with with your stake, right?

Uh, under the current system. So, >> you can you can >> you can >> Yes, you can split your vote. Uh you can split your vote, but you have to vote with all of your stake is my understanding, >> right? You can't like >> you could split it to abstain. If we uh if we make abstains kind of like not not in the denominator, then you can split 20% yes and then abstain for the rest. >> Yeah. So if I had like >> you are right currently it's a kind of de facto no abstain.

So um yeah, you are contri contributing with full stake at the moment. >> Yeah. So you're contributing full stake. So, let's say like I I had 1% of my stake that wanted to vote. They called me up and said, "Can you vote yes for me? Now I have to vote with all of my stake, right?" And so what I'm pretty sure there were validators in that situation where like now I've got like I have to vote one way because one of my delegators has asked me to vote.

I can't piss them off. Now what do I do? I like do I vote abstain with the rest of it? That means no. and and many of them weren't even aware of that meant no. They just thought, "Okay, I'll I'll vote. I'm staying." Um, you know, under our current system, you have to take you have to get a calculator out and sort of split your and work out, okay, 66% of the rest of it means yes and 33%. It's just it's really difficult.

It's very like confusing for people. So, it's kind of two issues there that I'm talking about. One is that we should allow partial voting of stake. That would be useful, I think. And then two is that just having abstain mean no was like really confusing. We spoke to a lot of people like personally I don't think SG SGB2 would have passed without Mr. like it was very close even with all of the effort that we put in there.

So um internally at Helas we we think like abstain should mean abstain. >> Yeah I agree. I agree and that's a really useful um sort of user story. I think we can make it uh abstain be really abstain um if we just have yes no as quorum. >> One more topic I'd like to bring up uh with the last five minutes. So like I mentioned the the epoch timing is not a great metric because um you know for example it's it's hard to calculate when a vote will start.

Maybe it'll start on like a Friday and end on a a Wednesday the next week, right? like it's it's a little um just not ideal to have epochs as the timer me mechanism for the actual vote. Um so one thing we were talking about is switching it to wall clock time. Um that leads to some issues around when the NCN snapshot should happen. Uh so I'm curious just if people have thoughts or feedback on epoch time versus wall clock time and um yeah what what people think what people prefer there.

Even though we don't have an onchain trigger yet, I don't know. I guess I agree that epoch time is messy, but for some reason, at least to me, it seems to fit with what we're doing here, especially because we're taking a snapshot in time based on an epoch. And maybe looking to the future, if we were to trigger any kind of change based on a vote, it would probably be based on an epoch boundary, too. So, even though it's not perfect, I guess I would vote to keep it epoch for now. >> Yeah, just echoing that uh Trent's opinion was very against epoch timing.

I I think it may be somewhat of a special case, but one thing to consider is with the shorter slot times coming up, uh it if a vote does happen to be happening at the same time that core dev wants to ship, let's say 250 millisecond slot times, uh we'd again have to have this argument with them about when to actually ship that feature gate, which is not ideal. Um yeah, any other thoughts? Um, I I like the epoch boundaries just in the uh it's a nice way to chunk the uh the the schedule of the different parts of the it's a bit cleaner than um having you know it could go it effectively down to the second right when um uh so there's good shelling points epoch boundaries but I also think uh since you know we're the IB VRL thing and block times are compressing, then it's it might ne be a necessary move.

Um, so yeah, I I understand both sides of the argument there. >> Fair enough. >> Yeah. Uh, sorry, Brian, do you have a comment? Brian Cole? >> No. Okay, Blake, go ahead. Well, I think the issue with this that I think a fe didn't a feature activation get held up. So, I think if we use epoch time, we have to understand that like if slots change, we have to stick with the original epochs, which may I mean, you may lose time on that.

I mean, I didn't think it I didn't think we lost enough time where it really made a difference. I guess as long as people have that understanding that they may not get x amount of days. Like if you're using epochs, it's going to be epochs. It's not going to be like you can't always translate that into wall clock. So people need to understand that if we stick with epochs. >> Yeah, epochs did get shortened slightly. I think we went from 400 at the start of the tooling down to 350.

Um so epochs were a little faster. Uh we delayed the 350 to 300 so that the last epoch was not rugged because we would have cut something like five hours off the last epoch. >> Yeah. Five hours doesn't seem like I mean if people are I guess people probably are waiting till last minute, aren't they? >> Yeah. >> Oh my god. >> Literally came down the last minute which would have been um sort of cutting off the daytime. So, you know, a lot of people got the communication that I think it was Thursday during the morning is when the vote would end.

Um, and then if all of a sudden it was, you know, 6:00 a.m. instead of 11:00 a.m. or whatever the difference was, that would have been a pretty big communication blender. >> We were we were chatting. It was like, okay, San Francisco is going to wake up at 8 a.m. Then Salana found Salana Foundation's going to vote. Like, what's going to happen when everyone starts waking up? If we had lost, that would have been 3:00 am.

And >> yeah, >> well, it is kind of also a specialized I mean, I don't think we're going to be changing slot times that often. I I don't know. Maybe we don't have to worry about this much going forward once we get to 200. >> Maybe we're going down 100, going down to 50 alpha. Yeah, we could also pad the vote a little longer um just to guard against maybe shorter slot times in the future. Yeah, agreed. All right, any closing thoughts?

Uh good discussion. I think we'll probably continue some of this in the community call in a couple weeks. Cool. Guess not. All right. Thanks everyone. Remember, sign up for all the events coming up around uh Breakpoint and see you all in two weeks. >> Thanks, Tim. See you. >> Thank you. >> Bye.