 Okay. We are recording. Yeah. So Trent, I see you shared the agenda. One thing you also you mentioned is that a couple teams have like mock ups and whatnot that they've been working on and I think they've shared with you. I don't know if it maybe makes sense for like teams who've actually like prototype stuff to maybe take five minutes or 10 minutes to walk us through it. I feel like that might be a good way to set the context. I don't know if, you know, now that it's recorded that changes things. Otherwise, we can we can kind of go through the agenda or just like the questions that people had. But yeah, I feel like if a team kind of wants to walk through what they've thought about so far and how they've kind of approached things that might be useful to make it a bit more concrete than just talking in the abstract. Yeah, I know I think that'd be great. And I think we have to mock ups from Jake and Carl. I think I've, I know I mentioned it to Carl but Jake I don't mean to put you on the spot but if you wouldn't mind just walking us through what your team has put together so far. I think that yeah that would be a good way to start. Yeah, for sure. Sure. Yeah. Yeah, and share your screen if you haven't pulled up or I can share it. No, I got it right here. One second. All right, so, so yeah we have, we've had a lot of conversations this is, this is very much a rough draft. We're, we're hoping to do some user testing really soon probably by the end of this week so we'll probably probably be iterating. There's probably a lot of things that are going to change or things that don't make sense. But here's where that. So, the scenario, this is sort of a stripped out view just to keep it simple. The scenario is focused on swaps we're showing uniswap here. Some of it like, we're thinking about what changes in different network conditions if, if traffic is increasing versus decreasing so this scenario is kind of focused on an increasing, increasing traffic so we're sort of estimating that fees are going to be going up, there's a little bit of a wider range. So, you go through you hit swap on uniswap. This is the revised transaction screen so there's really only two pieces we've we've changed. We're calling it an estimated gas fee. This is what we expect you to pay. And then there is a range. So that range would be if, you know if the network traffic didn't continue in the direction we did. Maybe it's a little bit less and then the top end would be sort of your, your max fee. And then down here we're showing the total. We're highlighting the estimated amount. I think a lot of that's going to depend on how confident we feel about that number we don't want to show a number and then pay something else but we feel confident about it showing highlighting that number and then showing it up to and then if you hit edit that brings you over into the edit view. So the, the way we're thinking about it now is trying to shift focus from speed and more towards, like, purpose like what type of transaction are you doing and then what how much should you be paying based on that. So some that we're going to have to have a good fallback so we're not always going to know that scenario of what somebody's doing but our hope is, we can, you know, sort of understand what they're doing so in this case they're doing a swap. And then we'd be recommending a higher setting since it's time sensitive. So we have high, medium, low, and I can dig into more details about some of these numbers if that makes sense but I'll just kind of skip over that for now. And then if they override that just trying to inform them maybe that's maybe that's not a good idea, we're still allowing them to do it. But part of it is just like education on what setting you should be picking. And so you're not just setting it to low every time. And then we have advanced we've spent less time on the advanced. But here's where it is now your gas limit max tip per gas max price per gas. I still think there's some room to improve this a little bit is specifically between how the next tip rolls into the max price and it's very intuitive here but we are going to need some error states we just have one showing here but there's definitely going to have to be some more thought on how we talk about this to the user if they're if they're putting weird settings in. So we're showing some of those stats that we have in the main screen to the fee range, the estimated fee. Wait time I'm, I'm just kind of putting in numbers here right now I'm not sure exactly how big those swings are going to be but the idea is the lower your fees. At some point we're just going to have to say unknown like we're not sure when it's actually going to process. I can pause there there's some more thought in the actual numbers but a lot of them just kind of making up for the time being stress testing the designs, but I'll pause there. Awesome this is really helpful to have. Does anybody have any initial questions or things that they want to clarification on. Are you. Yeah, absolutely that's one thing that we haven't tackled yet and to be honest we haven't like it's been in my head we haven't actually talked about it but this will have me will have to update pretty quickly. It's something we definitely need to take consideration in especially on this screen right if you open this up and you just sit here, and it's just like quietly updating and maybe you're not really paying attention so I think we're going to have to put some animation or some fade in some fade out something to make that a little bit more obvious. The, yeah how we estimate the range like we could potentially like pad it a little bit so there's a wider window where those numbers are. There's a sense but at the same time is like a balancing acts we don't want to show too big of a range. So it's still still a bridge to be cross. Are you going to allow people to submit legacy transactions. I'm not sure there's a use case for it, but they'll still be possible on the network. Yep, totally. Okay. Yeah, this is really cool. Christian, do you somehow detect if the current base fee on the network is really high and alert the user somehow or you always get send the maximum fee that's greater than the current base fee without alerting the user. Yeah, that's a good question we did in some of our earlier monks we did do a little bit more messaging around like the current network status right like hey it's it's really it's really busy right now like these are really high. So we should consider, like, like sort of prompting people to add a lower, lower max fee and waiting for it or, you know, running the risk of it. So that's not shown in these mocks like we're not testing that. I think we're kind of trying to strip it down to MVP but that is certainly something that I think is worth worth considering. Yeah, and if that feels important I might circle back and bring those back into the mock ups. Yeah, there's a comment about like, should we allow opt out that the user level to send legacy like I think it might make sense to preserve that but like there's no. The main advantage of sending legacy transactions for the users is the fact that it's like a 1559 is not supported say they use I don't know like ledger and ledger doesn't update. We want the network to be able to have their transaction or say they signed a transaction a year ago, right they've been waiting to broadcast it for a year, and they threw out you know whatever thing they use to sign it. We want them to still be able to send it so I, you know, I don't see a like use case for like allowing users like never like to not have 1559 transactions as a default but there might be some weird edge cases where like in the advanced settings you want somebody to be able to pick up and send a legacy transaction. But if you're like constructing the transaction on behalf of your users, there's not really a good reason to send a legacy transaction because that means they're just going to pay more gas, they won't get a refund. Like they won't get the difference between like their feet cap and the base unit tip refunded to them. That all goes to the minor. Absolutely. We've been talking about like keeping the old UI experience around for networks that don't support you IP 1559 etc. Yeah, sorry yeah that's the fear. Yeah, so for yeah for sure if you're obviously supporting like the theorem classics, or you know, like X di and like they haven't integrated the other what not like. Yeah, you'll need to keep the old UI. One question that we have and maybe if we have time at the end of the call after we get through some of the the UX stuff is just how do we detect support I know there's like an eat magicians forum thread that Dan Finley had opened about this but yeah. Yeah, the short answer to there. So there was a thread in the agenda about that. I think at this point that like easiest way is you look at the block header and see if there's a base key in it. Unfortunately, there's no way to know that like a network will support something in the future so you can't like say we announced the fork you know tomorrow. You can't like look at main net and know that 1559 is going to like happen on four block X. But once the four block passes the base fee that every single block will have a base fee. And so that's probably like the most reliable way to check it. Thanks. Anything else on the metamask box and tried to believe you said there was another team that had some. Yeah, I, let me, I think Carl is here from status. Yeah, I'm here. I'll start sharing now. Okay, can everybody see. Yes. Okay, great. So, trying to keep things initially as close to what exists now, rather than giving people ranges of fees when they're, when they're choosing the priority, which only showing them the maximum that they're going to be paying for that transaction. And kind of behind this we do have all of the custom, all of the customs stuff so we're giving them information about the current base fee, gas limit per gas tip limit and per gas price limit, and then calculating the maximum fee. But as a part of this, there are then a set of edge cases that that we need to kind of handle and watch for. So, if the, if the user sets a tip that is below the currently accepted tip, then we're showing them a warning around the, the minimum tip of the last end or last x blocks and the average tip that is being given to the miners. If it's above the minimum but below their average here we're giving them information about that. So, if the per gas price limit is below the current base fee, then again, that is going to do. We can guess that it's going to block that transaction. Anyway, if I go ahead a little bit further. And then there are an additional set of edge cases where if somebody sets a base fee that is that is above the current base fee but lower than the current tip, then again, we can assume that that transaction won't be accepted initially. And then again, an edge case for, for, for when the calculated tip is going to be below that average. So there are lots of more edge cases here that we need to be watching for. All of these edge cases then feed into the actual kind of simple interface where somebody just has a scale. Because on that scale, honestly, we have no idea what these ranges should be. So for example, what the, what the overall limit should be above the current base fee taking into account the tip, should it be one GUI or should it be like 10 GUI over that, we don't really know. And then if I just go a little bit further, if, if the base fee plus tip is going to be below the current base fee plus tip then we introduce some extra friction in this transaction to basically get the person to either go change the tip or change the limit. And then, yeah, there are also kind of combinations of these edge cases as well. So if the tip is too low and, sorry, I'm reminding myself of these screens as I'm running through them. If the tip is too low and the overall limit is too low, then we need to also show them information about what is happening in those specific situations. And then I guess the most helpful part of this would be, yeah. These are the edge cases that we're looking for inside that custom fee interface. So here we go to roll out. We had a discussion about this earlier today. And after reviewing the document around how it's going to be released and kind of initially having the one GUI base fee and still having the auction mechanism we at least imagine that keeping the current gas interface is going to be the best thing to do for let's just say 50 blocks and then switching to this, to this new interface, but really we don't really know what it's going to be best on day one or from the first block onwards. We've very much just kind of throwing ideas out there at the moment and seeing what will work. But yeah, I'll go back to the screens and if anybody has any questions. Happy to jump in. Hi, hi, Samuel here. Thanks for this. I was wondering, since like you would think there's a lot of part dependencies and different options are unknown. You have any plans to AB test this to your users or would it be a big bang. So what we, well, I mean, what I imagine us doing is basically being on call when this goes live. Ideally, we chatted about this today as well is we'd have a test room to make sure that all of this is going to work. We're not in a position to AB test this interface against the current interface, because it is going to go live and we need to accommodate for it. We can't have the current gas interface tested against the new interface just because the current gas interface doesn't cover all of the parameters that people can manage themselves. And that being said, somebody mentioned earlier, being able to switch the interface to use the current gas format, and I think that is something that we don't have in here and that's something that we probably should have in here. But yeah, AB testing, I don't think we're in a position to do that with this. Maybe we could help organize is just user testing for people on once the test net start to fork. We could probably get you some people to just start poking around and looking at things and that's, I think we could try to do it for most teams, but no promises. Yeah, yeah, that'd be, that'd be really helpful. I'm going to run through this, make sure that everything's usable and make sure that people understand what is happening. After we've got a initial build ready. The main things that I imagine is changing are going to be the copy that we're using in these edge cases. What we still don't know are. If I go here. We don't know how to estimate the priority fee. So what is low priority, what is high priority with we still need to figure out that part of it. And I'm not, I'm not sure how we're, how we're going to do that that that isn't really a something that I'm, I'm qualified to talk about but I don't think it's big enough until we start to learn after it goes live. So we have some values, I don't know if you saw the cheat sheet that Trent and I put together, and we have like some rough values for the priority fee that that that we've used. The challenge for the priority fee is you want to compensate miners enough that they, you know, it's worth it for them to add their transaction, and the more transaction miners add in the block the higher the risk of being called this. And this used to be quite simple to calculate but now a large part of the uncle risk is MVV bundles. So if a minor has an MVV transaction in their block that's like a high value time sensitive transaction so that the cost of these transactions is much higher. And so in the in the cheat sheet you can see there's like a graph basically that shows like a linear relationship between like what the average MVV in a block is and you know what should the tip be. Flashbots has a dashboard that kind of tracks this over time. There's no great like library right like there's no great way to like plug in that dashboard in wallets. You know if you want like a ballpark value to start what I would do is like looking at the flashback dashboard you know a week or two before the EAP goes live. And you just kind of you can kind of ballpark you know like what's the average MVV in blocks then. And then you know you can go back to the graph and figure out like what's like the right tip right now that value would be about two way. But they've anyway flashbots rolled up a bunch of optimizations that will allow for more MVV in each block so I suspect by the time it goes live, like a decent tip for most transaction is probably going to be like three way. Again subject to like how that the MVV evolves. The MVV stuff is another I have a really touch on that but I thought that was honestly a big unknown like how MVV would interact with this and what that baseline tip should be so that's really helpful. Thank you. Yeah, and like looking at it, you know if you can be like fancier like I'm just taking like an average right but if if you're like a wallet and you want to be a bit fancier, you could say maybe your fast transaction should be worth it for a minor to include you know in like the 20 percentile of like MVV blocks right and then maybe your optimal is like the average and you're slow. There's also I think right now there's only like something like 30 or 40% of blocks that have MVVs. So you're slow you can probably set like a tip to like two way which are, I forget if it's one or two way it says to the spreadsheet but I wouldn't say basically for blocks with zero MVV. So your slow can basically just be, you know you're wailing until there's a block that doesn't have MVV in it which you know on average should be two three blocks. Yeah. Okay. Well, so there's that and there's also the basically whether that basically I mean I know we can determine whether the basically is going to go up or down based on activity, but also like we then need to make a call on what a low priority basically is going to be versus a high priority basically and then hopefully in the future we can estimate time based on that but there are so many variables and so many moving past it it's really difficult. I can't right now say, okay we know what is going to happen ahead of time. So this is very much kind of the absolute minimum that we can do initially to cover for like the parameters and and everything that's required as a part of it and then hopefully in the future we can introduce that dimension on time. Yeah, just because there's so many so many different things to to to include. Yeah, and I think having on chain data, like, you know, like even like a few weeks of on chain data will be massively useful to see what, you know, what the right defaults are. Yeah, if you I don't know how much like, you know, tracking you do have like user data but if you're able to see like these transaction failed, or, you know, got stuck pending and and what not like. So that's a situation that I'm a little bit nervous about. And that would be, let's just say, day one, there's certainly high congestion, lots of people are trying to transact. We actually have a bidding wall and between yes, yes. On the status side, we don't want to be in a situation where our estimation is totally off and nobody can get transaction through from status using the simple interface. And yeah, I guess that's for us to figure out. Yeah, and I think that's, that's a really good. Yeah, that's a really good point so. So this was like the last thing I put in on like the cheat sheet but when 1559 goes live that basically is actually set the one way, which is tiny. So that means there will be a period where like blocks will be full just because you know there will be this bidding war. So I suspect the easiest way for wallets to get around that is to actually wait to display the 1559 UI. And you basically want to wait until like blocks are not like completely full again. And I, you know, I had some rough like ballpark numbers there it's probably something like, you know, 1530 ish minutes. And I had like better criteria but like, so I think once you have that initial spike, you'll probably get to a spot where like yeah, you are not you are no longer like a bidding war, and like prices are stabilized and so the 1559 UI should work. Yeah, yeah, yeah. Yeah, yeah, so when, yeah, the start of the call I mentioned we're going to possibly keep the current interface or the current estimation interface for the first 50 blocks and then switch. Hopefully that keeps things simple but obviously want to double check that that sounds right with everybody here. Yeah. So the trade off there is if you leave it just too long, you know, users might overpace likely on their transactions. So I think, you know, you could say like you want to be really safe and you put it for 100 blocks. So that means for like those, you know, second 50 blocks, maybe your users are overpaying a little bit but they're not, you know, potentially getting your transaction stuck so I think that's just like the. Yeah, the trade off you, like every wallet basically needs to figure out yeah. Yeah, we're almost like halfway through the call. We didn't have like a bunch of topics on the agenda but I don't know if just to make it like as useful as possible order like urgent questions or things that, you know, people here really wanted to bring up. Otherwise we can run through the different topics but yeah. Yes, I had a question. So, I assume most people are relying on gas API is right now, just to determine kind of what the best prices and there's various APIs. I know that the wallets are on this call I was wondering if you guys were having conversations with these various gas APIs to help provide estimations for for tip calculations when it gets to the point where we need to start bidding again against each other. Or like, if there are plans for that. Does that does that make sense. Yeah, I know, I know. ETH gas station is on the call. So they're thinking about how they're going to treat this. I don't know if there are other ones you had in mind. Cool. Yeah, I guess like the ether scan API also has either scan is yeah. Perfect. Who's here from is a Harith from ether scan. If you want to talk about what you're working on at all or what your approaches. To be honest, we don't really have a clear approach right now so if anyone who potentially will rely on our API have any suggestions or any comments to hear that. I think Barnaby had, like, done a bit of work looking at like how oracles should adapt after 1559. So, I don't know, maybe Barnaby there's like a few things you can share either here or after the call. Yeah, that can be helpful. I mean, so first thing to remember is, well, we don't have data yet, but there is a very strong intuition that these bidding wars, they will be very infrequent. And when they do happen, they will be very shorted because if there's a lot of pressure base fee raises and that's after some point it kind of stabilizes the system. So the role of the oracles to give you the tip is very different like the oracles as they exist right now we do this very long historical kind of analysis, the last 200 blocks of data. Here I don't actually think it's necessary first I think it's good enough to look at the 510 latest blocks and kind of look at the median fee, how people are, let's say over beating each other. And I think the complexity that currently exists in this if gas station oracles or any other oracle, you might, it might be useful to have something where you actually see the pending transactions, and you can see what people are currently planning to tip. But apart from that I feel that oracles in under 1559 they really don't serve the same purpose as they used to. And my point about oracles was more that these legacy users who maybe use outdated software. If they still rely on oracles the oracles will start very much converging towards the current value of base fee, and that makes it a pretty bad estimation for users who are still using legacy transactions but but otherwise I think oracles should either be sunset or very much like refold from from scratch into the 1559 environment. So just to be clear, we're talking about off chain. API is not on chain oracles. Yeah, that's correct. But, okay, at this point it seems very much less sophisticated on chain by on chain I really mean like the wallet itself could just keep in mind the last 510 blocks and make the estimation itself. And that might be good enough for 1559 and you wouldn't need all the machinery that exists in the current of chain oracles that we have to be. Okay, thanks for those that overview. Samuel, I'll try to find a link for you. So I think Barnaby has done some research, he has a big body of work on this stuff. Yeah, I'm looking through Barnaby's notebooks we pull right now but there's like 20 of them so Yeah, I remember Barnaby you had one kind of walking through the oracles and how like the data from even like how the data from the 1559 usage could even help set better oracles for like the legacy transactions. I just have no idea which notebook that is. I can share the link. Yeah. Yeah, awesome. Thanks. Yeah, I guess right now transactions they have very wide range even within blocks and so oracles they quote like the slow versus medium versus fast, they can be like a very large variance between the three different levels. And I don't think we see that in 1559 because by the nature of a mechanism which is like this base fee that everyone is paying plus a premium that everybody pretty much pays the same. You should find that your oracles start converging to to a good enough value. Yeah, I'll share really in the chat. And for the people asking about gas now I've had some difficulty communicating with them, or just like getting them on board with this stuff not that they're not interested but I think they're just doing other things so if anybody has like a existing line of communication with them and you can tell them to talk to me or connect us in some way that would be really helpful. One thing I was, I was wondering is feels like pretty much everyone is on the same page that from now on. Most of the estimation side will be on the on the wallet side, right, just looking at the latest look. I feel like that's kind of okay, but at the same time it will be cool if any API like either scan or whatever could provide that connection as an API do because polling blocks is fine but at the same time is maybe intense or depending on network connections not everyone has like, you know, perfect Wi Fi when like, there is more more chances to fail if you have to be to know something versus like just fetching one API call to an API and just get the number of what you will pay right now. I don't know just bring it up could be useful for the apps to so something that we have it will be good to have around. And I imagine it would be good if all these API follow the same standard. Yes. I was circling back to what Barnaby was mentioning about oracles and understand that all the discussion about gas price oracles for 1559 is around the, the minor tip, but does it make sense to also have an oracle for base fee to know if the current base fees extraordinarily high or something that that we're in a situation. I think yeah that would also be pretty simple to build right because you just need to look at the gas used. And if you know more than n blocks are full right basically the amount of completely full blocks tells you how high the gas he is on like an exponential scale. So it's like if you see you know one full block it's probably not worth it to is like pretty high and you know like five is like extremely high. Yeah, I, I don't know that there's oracles right there but like again it would be pretty straightforward to implement given that. Yeah, you just need to look at the gas use. Yeah, I think if you observe five blocks full previous you know that the gas fee is very high because, or at least not very high but very much as a very strong demand pressure, because otherwise like you couldn't have these double full blocks. Now that you have like this slack mechanism. So, yeah, five full blocks is definitely like an indication that a lot of people want to transact at the same time. And so the challenge there is obviously you don't know how sustained that demand will be right like you, you can't you know if you've seen like five full blocks, you know, it's hard to estimate whether or not you'll see five more full blocks or not. But the very least, you know, you can, you can know that you need to put like a very high tip you're basically back to a spot where you need to do like a kind of a bidding war on the tip, which is kind of our current system. And so that's probably make sense as a default response or you know to tell the user to submit this transaction and you know it's likely to be to be pending for a while until until this until this this clears. I think we should probably just try and get through the agenda. It's, it's not really. I hope it's not a ton of things but we should probably just go through it quick and then we can get back to open discussion. Sure. I guess, yeah, okay, so the first off was the Jason RPC changes. So, basically, I, I'll share the Jason RPC spec in the chat, just to make sure everybody has it. But we've added the changes to Jason RPC there. In short, you know, it adds the base sheet to the block header, and it adds the max fee and max priority fee to the transaction object, if the transaction is type two, so like 1559 style transaction. And that should, and that's basically the API that the different clients will implement. I think get has a different version of this and they have an open PR to implement to implement something in accordance with the spec but that's kind of Yeah, what all the clients will will implement in the next couple weeks. I don't know if there was any questions or comments on that. So we've amended minimum priority fee so we touched on this quickly. Again there I think the, the case where there's not like a sudden spike in demand, what you probably want is to just look at the ballpark, you know, average MVV in the last seven days. Follow Barnabays graph that's linked to that and you can use that to kind of set the default tip. You know with the values that we're seeing we would be around like 1.5 way per gas. Again I mentioned earlier flash boxes, you know doing some optimization work to include more bundles so I suspect by the time 1559 goes live like to go a per gas as a default tip probably makes sense to get your transaction included, you know, and like the, like you know, 75% of blocks unless it's like extremely high MVV. So just as a default option to go away as of today is probably the right amount. I'll just run through it if people have questions just please interrupt me. Okay so this is something again get has an open PR for, but the one challenge which we've seen tonight is you can replace transactions kind of costlessly. So if you just raise the fee cap, it doesn't actually mean that the user will end up paying more because you know they just pay the base fee and the tip they don't actually pay their entire fee cap. So because of that, it could be like an attack vector where like people could just stand the transaction pool raising the fee cap, you know every time and it's costless but I'm to do that. Whereas today if you if you raise your gas price and every transaction, obviously you're paying that highest price. So, in order to avoid that I believe what gets and other kinds are going to go with is you need to raise both the fee cap and the tips by I think 10% for it to be re broadcasted. So it'll be worth just like looking at like the get ready notes for that. But roughly, if you're if you're resubmitting a transaction with a higher fee, you want to increase both values, not just the fee cap. Yeah. I've got a question regards to that. Is this going to be part of the protocol or a client, because people could just Joe break their clients to take that out on still attacking. Just part of the clients. So like, sure, you can, you can, you know, jailbreak your client to submit the transaction but then nobody. I guess the other nodes will not replace the transactions in their transaction pool if they see that it hasn't been raised enough, right. And they'll probably just like mark you as a bad peer or something. So it's like you can, you can obviously hack, get and propagate whatever you want on the network but then other nodes will just not update their, their status based on that and they'll eventually disconnect you. Does that make sense. Yes. Thank you. Of course. And then we had London rollout. Yeah, we touched on this earlier I just added it. So we don't need to necessarily go over it again but like definitely these. Ideally, like you won't need to, if you're, if you're making the transition properly like regular users who aren't fee sensitive or, you know, are just sending basic transactions they don't necessarily don't always care about the advanced gas estimation tools. So ideally, like, you've worked out a transition plan, but in, in the case of, you know, a lot of crypto users they want to know how these advanced features work. And I'm sure everybody's already thinking about this like, you will need to communicate what all these fields are and maybe like recommended practices for how to set things during congestion. Yeah, this is, I mean, I don't need to tell people this but it's like, I'm not sure you're already thinking of how to communicate this to your users. And for the actual kind of UI switch so we talked about it earlier, you know, I think there's different, there's different approaches you can take either like easiest and like most naive one is just like adding a blocks buffer between the hard fork and when you turn on the UI. So like you'll know the hard fork block well in advance and you do like that plus you know 100 or plus 50. And then you just switch it on. If you wanted to actually base it on network condition. So for example, metrics you can look at the first is just the gas use in a block. So when we start seeing the gas used actually represent like 50% of the gas limit. So right now, you know, the gas limit is 50 million. It'll be 30 million after the fork. So you'd want to check you know, have I seen like a couple blocks of the gas use being like around 15 million rather than 30 million that's telling you that like, we've basically processed all of the things, you know, for a certain base fee in the base fee is not like a good gauge of demand on the network. If you want to just look at the base fee, you know one way to do that is like maybe just waiting to see like one or two base fees where like the parents base fee is like, you know, pretty close to the current base fee so you know whether it's like 5% roughly, it's telling you that like the blocks are pretty stable. And yeah, if you do want to just go with a number of blocks. I think I would just look at like what the gas price is basically when you're cutting the release for whenever your product is going to go live. And then you can calculate, you know, how long does it take to get from one way to there if the blocks are full and increases by 12 and a half percent every block. So the math, it was I assume like a 250 way, which is obviously higher than the gas price today. And I gave 50 blocks but you know you can just look at the blocks, whenever you're really close. And, you know, if you want to be extra sure you can like use like a combination of those rules you know you can set yourself like maybe a fairly short block limit like saying, you know, like 50 blocks in the fork. And, you know, you want the gas used to be between those two ranges before you flip on like the 1559 UI. And I guess what's nice is like, all those parameters are just in the block header so like you don't need it, you don't need to like actually look through like the full block to determine this. So it should be fairly straightforward to estimate if you have access to the block header. And if you don't, then I think just like a ballpark number of blocks is probably the simplest way to go. I think that's all we had like on the proper agenda so yeah. I mean while we're here, you might as well just say the last one. Oh, oh, sorry yeah so ERC editors. Okay, so this is not necessarily related to 1569 but kind of a quick pitch. I'm going to be splitting the EIP repo between EIPs and ERCs because there's just like such a different skill set from folks working on you know core EIPs and folks working on the interface level. If you are interested in helping to be like a potential ERC editor, please reach out to Trent or me after the call and we can chat about that but basically it would help you know, maintain the repo, make sure that there's like a good process for people to add new standards and whatnot. Light client is on the call, he's like a EIP editor so he can maybe also give some context on what it's like. But yeah it's something we're looking for and I think we're like the application layer can really help because you folks have like way more context on ERCs than most of the core devs who are working at the protocol level. The other thing, which is now stopping my mind. Oh, so there was this big conversation on the agenda about like detecting that a network supports 1559. Realistically, I think the only way to do that for now and likely for the next few months will be looking at the looking at the block header seeing if there's a base fee in there, and if so that tells you the network is supporting 1559. Okay, I remembered. It sounds like from discussion in the chat and just generally is that we may need to have another call or just coordinate a little bit better with API providers. I'm just gonna scan this here. And he's gas station but if that is a need and people want us to organize another call we can do that I know this was more focused on wallets but obviously that's very tightly linked to how you're serving data to people. So, maybe maybe just after this I'll reach out to those those teams and see if we need to organize something. Great. Yeah, and then we can just get back to open discussion if people have any questions or comments. Just want to just want to have a second second that there's chance there's chance. It's pretty it's pretty hard to. It's pretty hard to hear you Brandon. Maybe type it in the chat, or if anybody heard that. Please translate. Anybody else. Any type of question. Go ahead. Yeah, two things basically. The one thing was checking the block feels a bit brittle to to find out if you have 1559 is supported is the question is, is the train for for London already left the station or could there be like a simple in there basically. So it's already done. There is no core VIP that will be added to London. And it could be quite a simple one right so just return, basically, if you IP 15 or in the IP and then install start and then optional and lock number. So the challenge is that that actually doesn't help for all the networks that don't support it right, because it's like, first of all, I don't think we can add any consensus change to London right now, but even if we could. There's no consensus change right it would just be an RPC command extra. So then the RPC basically. So I guess the RPC command basically that returns an EIP and an optional start and start and optional and number. So like you return, you call like does this chain support 1559. And it tells you yes or no. It's more general basically not just 1559, but basically we will have the same problems in the future basically. Yeah, it was a challenge. Yeah, the challenge with EIP base. So the reason this is a hard problem is that clients, at least not all clients have the concept of like an EIP being activated, especially with mainnet, and that's led to having that concept has led the bugs before if you can say you know, I want to call it 1559Z, the problem is there's often a lot of interplay between them and so what clients will do is they won't say I support an EIP, they'll say I support a certain hard fork, right, they'll say I support like London, or I support Berlin or whatever. So the challenge with that then is like say Ethereum Classic adds 1559, their hard fork is not going to be called London, and they're even if, if they have, you know, their hard fork is not going to be called London, and it might not be the exact same hard fork at 1559 so for example, you know where in London we're also changing a bunch of gas costs, or sorry, a refund. For fork, like from the forks just really from the EIPs, which EIPs are supported from which block, so it would say. The clients don't know. So the clients themselves don't keep track of which EIPs is is activated. They keep tracks of which hard forks are activated. And like you could probably create a mapping from that. But I doubt that happens for London, but right now if you wanted to like easily expose some data, you could say you know, does get have London enabled, but then on the wallet side, you need to have like some mapping that tells you well London is actually 1559 and Berlin is actually 2930. Yeah, I don't really think that would help basically the defaults because there's so many chains out there, and they don't go around these forms in the combination. Yeah. So I think, yeah, like it could be done. But what I'm saying is like, it's not going to be an easy thing for client to implement them. And so I don't think it's possible for London. Yeah. All right. And the other thing was when implementing 1559 as like access list is currently on the end. And it would make it nicer if access list is basically before the gas limit, because then you could share a little bit more code, like in the RP. And currently like access list is basically on the end. And that makes it that you need basically, it's, it's more difference. So the code would be a little bit nicer if access list is before gas limit in the list. Is that too late to change it now or. I just noticed. Make the code like this that impact how the transaction isn't if it impacts how the transaction is encoded, then the answer is yes. Yeah, it impacts how the transaction is included. Yeah, I don't think we can do any consensus changes now for London. Yeah. All right. Thank you for the info. Yeah. And there's a question in the chat about the gas price. I'm actually not quite sure how it's been implemented. I don't know like client this, you know, if you have a mic. The only way that I implemented was I, I look at the last base fee for the block and I said, you know, just a pretty naive fee cap for the transaction is two times the last base fee. And that can be configurable with a flag to your depth client. And then for the tip. I'm just looking at what are the tips in the last block. And I will, and I try and calculate what was sort of the average, the median tip is in that set and then I return that so you'll have a very high chance to be included in the next block or two. Sorry, but what are we doing. So are you modifying the existing ETH gas price endpoint, or is that going to maintain on the legacy gas GPO calculator. And now I have the endpoint returning to different things depending on what the, the for configuration is on the client. So if it's not 1559 it's going to continue to return just a gas price. If it is 1559 it will return the estimated tip and be cap. So for get then ETH gas price specifically is a breaking change. Yeah, if you're relying on gas price it would be breaking up. So any wallet that currently uses that RPC call and still sends legacy transactions will start sending with the wrong gas price because that endpoint will return the data for 1559. Yeah, that's why I'm asking. Yeah, so I mean should we have two endpoints for have we done I don't think we've done that with any other Jason RPC endpoints to have a 1559 specific. Personally, like, if we're going to maintain legacy transactions we should probably maintain the legacy endpoint for them. We've had a lot of issues at Chainsafe because of GPO like miscalculations and stuff. Do you do the sampling, especially due to mev and I think like we should probably just not fuck with that. Yeah. But yeah, if you if you want to keep the same endpoint then you're gonna flag like a parameter that, you know, at least you requested the new way. If it's a false data weight is, if it makes things easier. I'm open to whatever, you know, consumers of Jason RPC would like to do. I don't have a strong opinion. Personally, I just like it to be in before because right now like London or not London Berlin like didn't have the access list or endpoint ready. So it'd be nice to have this like ready well before we go. Are people okay with adding a new optional parameter that sort of signals I'm looking for the new 1559 information and if not just default to returning just the gas price. It breaks less code that way. I'm okay with that personally. Apologies for being naive. What correlation does the access list have on the UX and gasses. I was, I was just making a reference to the fact that like we forgot about our PC, and it's like being dealt with after the fact and I've got users complaining that they've got broken contracts and they're trying to figure out how the hell to pull it off. So, I'm trying to avoid that early. So basically just to summarize, we add an optional parameter in each gas price which specifies that you actually want the 1559 style transaction at the 1559 style estimation. And if you don't have that parameter you just return the current behavior. Sounds good to me. Yeah, it's a little bit messy to stop kind of making breaking changes free parameters, but the alternative. Yeah, I mean, but it's backwards compatible, which is nice. And also gives flexibility to, to, like you guys, because you can have you can do some sort of flag configuration before and understand which one you want to actually trigger, you know, if you want to trigger legacy or if you want to trigger the current one, the code changes like one if statement and maybe a flag. And that's why I spent in terms of having a parameter versus another function name, like with starting to basically version an API by putting parameters on things. Yeah, also in favor wouldn't be too bad of an idea to actually implement it on its own. I'm easy. But I know there's a discussion kind of around this with Tim on an issue. Oh wait no that was something totally different. Yeah. I have a lot of stuff left and I just want to like hit a few things really quick before we wrap a first thank you everybody for coming out. Whether it's early or late for you really appreciate it we've got a ton of people from different wallet teams around the world so again thanks for coming and trying to resolve this stuff synchronously. Then a few other things. So this wallet cheat sheet we've mentioned a bunch of times this is where we're trying to gather resources aimed at people like you who are working on interface layer so please make sure to bookmark this and check it pretty frequently because we're going to be updating it with resources as people surface them or answering questions there. R&D discord is where a lot of this discussion is being hashed out so if you haven't joined there already please join. I'll grab a link and put it there unless Tim has already done it. And we'd really appreciate if people could engage there to 1559 channels. And that's where a lot of this is happening. And then Tim really quick do you want to give like maybe people already know this but like the timelines, tentative timelines for when this is. Sure. So we're going to actually confirm this on our quarter of Friday but assume, like, you know, this is the most aggressive timelines are probably what you should plan for so we suspect the first testnet will fork on June 9. So that'll be Robson, then we would fork Gordy a week after that so June 16 and then we would fork Rinkavy a week after that June 23. Assume all that goes well and you know we don't like find a big consensus issue. We're tentatively planning 1559 for July 14 on mainnet. But we want to see the first testnet go well before we actually initiate before actually set a block number for for mainnet. Yeah, I, it's not 100% sure that clients will be ready for the June 9 date so it might slip like a week or two. This is what we're going to be discussing Friday but you know, if you want to be ready for like the most, yeah, aggressive timeline then being ready for June 9 should be the goal. And most, you know, I think most client teams have mentioned to me they should have a release with 1559 ready and whatnot by by next week. So, like, a week before the testnet fork and then we'll have the mainnet releases probably closer to like a month before the mainnet fork. So, thanks again for everybody coming. We did record this so we'll upload it somewhere and then send out an email with sort of outcomes and links for next steps. Thanks everybody. Thank you.