 All right, we're gonna get started here. I know we have limited time, so I wanna make the most of it. Welcome everybody to this fourth, 1559 coordination call, fourth and probably the last ahead of the London Fork, which is next week. I'm sure you're all aware of it. It's gonna land around, I think 12 UTC on Thursday, August 5th, depending on the block time. So I'm sure we're all very excited. I know I am. So I believe I put the agenda in the chat. You can check that out if you want, but this is a very open session. I think a few of the, we have a few wallet teams here. I don't know what it makes sense to start with. If anybody has any pressing discussion points, they wanna bring up before we get into some demos. I'm open to hearing that, Richard, you're unmuted. So I'm gonna take that as you wanna talk. Go ahead. This is just a very quick thing. I think it's useful if everyone changes their name in this chat to the project they're working on. Sure. If you want to, you don't have to, just a suggestion. Oh, I see Tim is doing, Tim, I don't know if you wanna lead off with any general comments or links to anything. I can share the RPC doc that you put together. Yeah, I mean, if anyone has questions or things they wanna bring up first, we can do those, but otherwise, yeah, we can kind of share some updates, I guess, from our end and start that way. Yeah, go ahead, whatever you've got. There we go. Oh, okay, so there's a question from San Diego. We can start there. So, what are there's any gas price oracles if gas station get now, gas now working on 1569? I don't know if any of them, oh, yeah, we have someone from each gas station on the call, two people, yeah. Yeah, so, yeah, I'm under here, yeah. Working for a gas station. So, yeah, indeed, yeah, we are looking into this. Yeah, we've been working on this this month. We probably won't make it exactly to the same, yeah, to the next week, but yeah, pretty much like maybe the week after or something. So, yeah, the idea is to give some tipping, minor tipping estimation for the coming blocks to get included. Pretty much what we got so far, but yeah, with the tipping change. I'm curious if you can share this publicly, but like, how are you approaching like adding, like, how are you approaching estimating the tips? And if you can't share it because that's like your secret sauce, that's fine, but yeah. Yeah, I think it's pretty much what's been shared on what is this page, yeah, I can't remember. Yeah, it's basically like pretty close to the first approach we have, like checking the last 100, 200 blocks, and then trying to find like the content out of it for the tipping field. And yeah, given certain content we will share like for given like standard or fast or ultra fast line for the next block, for, yeah, to get included in the block. These details, we still need like to tweak some stuff and yeah, those details, the implementation detail, we mostly share some of it. So yeah, as we get the thing like more clear and more like in shape, then yeah, we have more resources to share. Well, yeah, I think one thing, I think it was Barnabay who brought this up before, but like that potentially looking at like a shorter block horizon makes more sense after 1559 because of how quickly the base key moves. So I'm not sure if that's something you're able to back test, but I think that would be really interesting like to see, do you get better estimations if you look at like 10 versus 50 versus 100 versus even like something like five because the base key can basically double, I think in like six blocks. And that means like if we're in a spot where it's doubling really quickly or going up pretty quickly, the tips will be going up quite fast obviously and you'd want to adapt quickly to that. Whereas like, if that demand spike is over, the tips will probably go back down quickly. And again, you'd want to adapt quicker. So yeah, I mean, it'll be interesting to see the actual like live data for that. But I think as you're maybe working on like a V2 or an upgrade to it, like comparing different history ranges and trying to see what's like the best estimator could be really interesting. Completely, yeah, completely. Thanks for sharing. Chris, I see you have your hand up. Yeah, I'm with Block Native and we've updated our gas platform to support 1559. It's also triggering on the 1559 fork block. So that'll go live when 1559 goes live. And it basically adds to our API, you know, a max FICAP recommendation as well as a tip recommendation. It also reports on the base fee, just if you want to get it through that source instead of asking the block. And initially, it's a little bit heuristic based but then very quickly it's gonna switch to our full models. We just need to get actual data on those models and the behavior that we saw for 1559 on the test nets really didn't give us anything that we could build a model off of. So it just wasn't used enough but that's the plan for Block Native's gas platform support. Nice. Out of interest, do you have anything on Bobston for that available already? Our gas platform only runs on main net. We don't really provide an API for the test nets for that. But what we haven't done yet is show what the API changes are for that. So hopefully over the weekend, we'll have that. We're just doing some testing now and I wanna make sure the API is reasonably solid. The payload changes are reasonably solid before we publish that. But hopefully by Monday, that'll be available for anyone to see the API, not to actually get the data. Anyone else have comments or just thoughts on oracles they wanted to share before we move on? I think... Oh, go ahead, go ahead. Yeah, sorry. So I also have some experimental code but yeah, that's been shared. The link has been I see now, I see the link has been shared. So I have, so there's this fee history API that and I wrote some JavaScript oracle using this fee history API that's also supposed to be like capable. So it's also theoretically capable of making suggestions for like more urgent or less urgent and more economical fee options and everything. But yeah, so I believe we really need the main data to test these things. And yeah, but once a minute launches, I'd be very happy to like see some comments or issues or pand on that repository. Anyone wants to try this fee oracle? Thanks, yeah. Thanks for sharing. And yeah, I feel like a lot of this stuff, the data on mainnet will be kind of a much better indicator just because all the test nets don't have sustained like more than 50% for blocks usage. Yeah, cool. Anything else on the oracles? I was just going to surface, if anybody from gas now or tight to your spark pool is here and you wanted to ask any questions, now would be a good time. No pressure if you don't have anything, but. Yeah, we do not have anything. We have finished all the code that are revising and reviewing. So we are just waiting for lunch and currently no from our side. Okay, thanks. Yeah, let me double check the agenda. Again, this is open. So like if you guys just have a question and you wanna bring something up, just go ahead. We don't really have to rely on the agenda strictly. Are there any wallets here who would be bold enough to share any screens or demos of what they have so far? I know we have MetaMask and status here. I don't mean to put you on the spot, but it would be really, really amazing if we could see anything from you guys. I'll go first. On our end, our kind of fee estimation stuff is expected to be ready on Monday. So that's not ready right now. And yeah, as soon as that is ready, I will share a link to the branch along with any build instructions for anybody who wants that information so they can jump in and play around with it. The kind of interface side of things is done. It's just not plugging into anything. So that's no different to what we shared a few weeks ago inside the Figma files. So all of that stuff is pretty much exactly the same. Gotcha, thanks. Kevin from MetaMask here. We are live on private beta on our mobile apps, which is iOS and Android. With our desktop extension version, we should be live next week sometime on private beta as well. And when the London hard fork happens, we'll go to prod soon after. I was reminded we have Rainbow and my crypto here. So if either of you would like to share some thoughts or a quick update, that would be cool. Hey, this is Jen from Rainbow. We decided to hold off and wait until we get more data to be able to figure out what sort of decisions we want to make for our users just because our goal is kind of to limit the range that we're gonna be exposing to users because there will be kind of like a vast range going up. And so we've kind of mapped out a few different scenarios and situations and are still debating what our UI we want to show. Essentially kind of trying to limit the multiple on the base fee and being smarter about the tip instead so that we don't have like this long tail or this huge range of like, oh, your gas price could be some large amount that might be way bigger than what it ends up being in practice. Okay, yeah, and I think Tim has mentioned this before. It's not unreasonable to wait and see how it plays out a little bit before deciding how to present things, making changes in your UI. So that's good. Sorry, I can only see a few names on this screen. So apologies if I keep missing wallets who are in attendance. But if there's anybody else who wants to say something, just go ahead. I would just say briefly at Argent, we're doing the same thing as Rainbow. So we're holding off for now. I think we need to be a bit confident what kind of data sources we can use for the oracles. And it sounds like most of them are kind of fine tuning things and will be probably for a couple of days, at least afterwards anyway, where you get to get it in with the UX that we already have. We believe it suits the same model, but it's probably going to be, I'd say, at least a week or so afterwards. A week or so from here or from the... Yeah, I think until we can start looking at it properly and we've got gas oracles with good estimation models there's not much we can do. So I think we'll come back to it, probably about a week after London's gone live and then start digging into it and then seeing what technical changes we can make. Great. So it sounds like it also might be helpful to have another call in two weeks just to share everybody's learnings. But we'll plan that after the fork. Leaky, do you want to talk at all about... I see there's some discussion going on about decimal to hex. Does anybody want to bring that up verbally just so everybody's aware of it? Yeah, there's a change basically in the fee history. It's just for the fee history, so not for submitting. And it's a bit a sad situation because for the clients, it's a bit hard because you don't really know what to use. So if you use the wrong one, you get an error and so you need to check the client version and depending on your model that's a bit strange. I hope we can accept both. So the current release, 110.6 still uses decimal and the master currently, which then will be released to 110.7 uses hexadecimal. Actually better using hexadecimal. It's more streamlined because hexadecimal is used for blocks in other places but the problem is the transition basically because as a wallet, what do you actually then use? You know what I mean? Sorry, which values are being changed? So actually one of them is input value and the other is the block count input value and the oldest block return value are both changed from decimal to hex now. So yeah. And this is tricky because on one side the JavaScript code could accept the return value both in both formats but then also the client has to accept the input parameter, the block count input parameter in both formats, which is possible but it's also not how it's specified now. So yeah, I'm not sure. But yeah, maybe that's the best way to go. I think the main problem is basically the input values because like I can as a client I can basically check the value I get. I mean the output values. I can check basically what value I get and then decide on that. The problem is if I need to send a request and not really know what to send that's a bit of a sad situation. So yeah. If the node can accept both just in the transition period basically for a while we can also switch that off at some point. That would be nice because otherwise it's quite problematic. Yeah, but right now the current release version that only accept decimal. So then the proposed script should also use decimal value. So maybe that sounds like we might just get stuck with that. But yeah. Also if an open Ethereum and Visu already use Hex and when I think wrote that just now then it won't be good either. So that's the problem that right now we have a release version of get that only accepts decimal and then we have other clients that accept Hex or I don't know maybe do they accept both? No they don't. At least in open Ethereum when I tested it it was breaking. So they only accept Hex to decimal is that right? Yeah. So it's not so easy. Yeah, so then it's bad either way. Unfortunately. Yeah, and it was probably my mistake and I'm sorry about it. But yeah. So then I don't think we should release this JavaScript code in a way that it uses a decimal value in the call because I mean for the free history input value the block count because that will only work in guest then and won't work in the other clients. So. Are you referring to the JSON AP? So the JSON RPC API. Are you saying that the inputs to get or you mean the results? The input. Now I'm talking about the input. So the API I'm thinking about how about like from the north side some from the get the implementation side. So by input I mean the free history APIs input value the block count. And that's now, yeah. So the currently release version of get accepts a decimal value there. And the other clients accept the hex value and the master branch of get only or it is already updated to hex. So maybe. I think most clients accept a quantity, which is just a non zero prefixed. Yeah. So that's a quantity value. Yeah. That's a quantity value. Yeah. Yeah. Yeah. The quantity is a hex value. Yeah. So. So to me, they say with an Ethereum is the. Really. If seven is not released. I might have to ask F is the most popular client. Yeah. Yeah. Yeah. Yeah. So I think as Gaff is the most popular client. I might have to recreate a new more creative version with an Ethereum that will support the, the six and then release again when seven is out. Because I kind of do the. This guessing stuff like in JavaScript because it's all tight. Yeah. So ideally seven was out before that will be great. Is there a plan to release 10 seven before the hard fork or would this be. Found to the hard work. I believe after, but somebody more somebody closer to the Gaff team can maybe respond. Actually, I don't know yet. I will. Reach out to the rest of the team and find that out. Yeah. But yeah, I will try to find it out too, but yeah, I just don't know it right now, but yeah, it would be, it would be from this for this issue. It would be nice if we could, if we could do, do a fix release. At least. Because yeah, I don't think so I don't think that. Like. Yeah, so, so, so accepting both both both formats in get that just won't solve the situation because the situation is already there. And if we can do a release, then we can just change it to hex and the, and then it will be hex everywhere. And that's like the best outcome. But yeah, I think the only way to fix this is to like do, do, do a, at least a hot fix release for this issue. And yeah, I would try to talk to Peter and the guys and maybe, maybe we can do it. Or maybe they have this plan too. Yeah, I don't know. I have been testing on, on, on 10 seven and to me works perfectly. And hence I've released a period thinking that was going to happen. But yeah, so if it's just let us know or just in the, in the. Discore chart, you know, so that I can plan ahead and I can, I really think that being compatible with get this, you know, at least we'll touch more, more clients than the only way. Question for rigmo related to this. Is it possible that the get feed data metal from ethers does not accept any parameters right now. So right now I don't use feed data at all for ethers. I'm still using Micah suggested hard coded one way. Got it, got it. But what I plan to do in the future is that there's a feed data structure. And so that's also rolling up got like so in v6 there will be a there will no longer be a provider that get gas price that will be rolled into feed data as well. So if you look at the result of feed data, you get inside that the gas price, if it exists, the max fee per gas and the max priority fee per gas, if those exist. So in the future, at some point, once like the, the dust has settled, then we know exactly what, what. The history is going to return. There'll be something else in there for that, but I'm also planning to make that object, an actual object that has, for example, a method so that you could, for example, have get priority fee per gas, like get priority fee as a method that you can then pass in. And that's still up in the air, whether it's going to be a number that represents a number of seconds you're targeting or whether it represents, you know, fast, slow, medium, cheap, something like that. But yeah, for now, the none of that exists. That's just kind of like future plans. For now it's going to throw away, there will be a, a max priority fee per gas, which is kind of like the best estimate we have, which is currently hard coded to get priority fee per gas. So that's just kind of like the one way, but soon it'll start pulling fee data and making some sort of educated gas based on that, if that makes sense. Perfect. Sounds good. Thank you for clarifying. Anything else on this topic? Actually, that does bring up one quick question. Is that certainly sufficient? Is the previous advice of. Hard. Yeah. Way still. I would say two is so one. And I can share Barnabas posts for people who want to read it. Uncle M E V is in my most red things. One way covers the opportunity costs of your block being uncle. If you just look at like transaction fees. But the challenge is that since 1559 was developed, M E V is now a big thing. So the opportunity cost of being on cold is not only you lose the transaction fee revenue and the block, you know, the block reward like the delta between like an uncle reward and the block reward, but if you possibly lose kind of your, your M E V bundle that's included in your block, right? So what you want is you want the tip to basically offset that potential loss as well. And that gets much trickier trickier for two reasons. One is M E V rewards are very variable, right? They're not evenly distributed. And two is you don't actually want to like compensate for 100% of possible M E V, right? Like when there's a hundred E M E V bundle, it's probably fine for a user to wait a block to not like, you know, over tip that. So last time I checked like a two-way default gives you basically compensates for roughly 50% of like historical M E V blocks. So that means that M E V blocks are only 60% of blocks right now. So that means that if you, if you compensate for, for half of those, it's like there's 40% of blocks without M E V. And then you're good in 38% of blocks. So like roughly 70% of the time to go should be enough. And I think three way was enough to compensate something like 80 or 90% of M E V opportunities right now. And that probably means something like, you know, 90 plus percent of blocks. So two to three probably makes sense. Depending on like how aggressive you want to be compared to, you know, the, the prevailing M E V numbers. And the thing I shared from Barter Bay has like kind of the formula that you, you can use to plug in that. I don't think does it link the flash spots dashboard. It does not. So the other thing that, yeah, that I've used is there's like this dashboard. If you just want to like eyeball it, there's this dashboard dot flash spots. Got net website. And that'll actually show you historical M E V. So that's what I kind of use. And I just like very roughly eyeballed it. And, you know, at the end of the day, you're kind of debating between like one to three way. So it's not like it has to be a perfect estimation, but yeah, unless, unless M E V changes a lot, I think those numbers make sense. I'll probably follow Frederick's example then or Frederick. I don't know how. I'm sorry. Example of using three for now, and then we can dial back later. Yeah. I think, yeah, one is likely to be too low because it won't take M E V into account at all. And two is. You know, I don't know if you, if you had like the concept of like a slow transaction to is probably like the good one. Good value three. Yeah. Perfect. I had a question for Frederick. Sorry if I'm also mispronouncing your name from my crypto. So you mentioned in the chat that you default to three way for the priority fee up to a given base fee. And then you start using the fee history. I was wondering like, how do you determine when that's what it's like, is the bait the up to a given base fees that hard coded or is it based on some like trajectory or. Or trade. Yeah, you didn't butcher my name. That was all good. Basically, we, we've set some hopefully saying defaults. So basically hard coding it, but we are, we will be monitoring it and like changing them on the fly. If it turns out that we are like completely wrong. But we've, we've just tried to, to come up with something that, that would hopefully make sense. Okay, cool. Thank you. All right. If anyone wants to read it, I put it in the chat and I can post it again. Are like definitely work in progress, but our current fee estimation strategy. I know Tim had requested that we add. The discussion about requiring. Sorry, I lost the agenda again. Requiring gas price and the expected deprecation. Me link to the discussion, Tim, if you want to touch on that. Okay. So right now, yes, and I think all other clients currently return a gas price value for 1559 transactions in Jason RPC. So to be clear at the protocol level, 1559 transactions do not have a gas price field, but because a lot of tooling depends on it. So guess it originally kept it in the Jason RPC. So basically, what it does is before a transaction is mined, we can't actually know it's effective gas price on the network because it depends on the base fee. So before a transaction, it's mined that gas price field in the transaction will return the max priority, the max fee. So the maximum the transaction could, could ever pay. And then after a transaction, it mined it or it returned the effective, the effective gas price, which is basically the base fee plus the priority fee that was paid. So the goal in adding that was, you know, to kind of act as a sort of backstop and to minimize breakage in the ecosystem. But it's obviously not ideal for a few reasons. Like one, this field doesn't actually exist in the transaction. Two, it's a bit sketchy that they don't have to do that. So one of the reasons why this field doesn't actually exist in the transaction. Two, it's a bit sketchy that the field changes based on the, the status of the transaction. So on all core devs last week, we were talking about, you know, what do we actually do about this? When do we possibly deprecate it and whatnot? And one idea that we have was that we would deprecate it. The first release after the next hard fork. So not London. But we're going to need to have another hard fork in December, even if just to push back the difficulty bomb. So that, that's hard fork would still contain the gas price field. It gets into transactions. Then the first release after that, you kind of deprecate it. So that means if you want to stay on the old kind of release, you can, you can do so basically up to the. Too hard for now. So I was curious, I guess to get all of your thoughts and Rick has his hand up. Right. So I definitely want to in place much longer than that. The second that's removed. Every version of ethers part of 5.4 will fail. If you, like for a lot of things, if you just try getting a transaction, just get transaction. We'll fail if there's not a gas price there. Because the block, like the, the response is valid. Make sure all the fields exist and are correct things. And that was a required field back then. So I definitely want it longer than just the next hard fork. So. I mean, if you put a dummy value, like if you put negative one in there, I actually, it'll work. It'll be fine. It's just, it has to be there. Okay. So it would work if. Okay. If it returned, like, would it work if it returned like null error has to be like an integer value? It has to be. Yeah. I'm pretty sure. Yeah. It checks. That was one of the changes in V. V 5.4 was that it used to be big number. Now it's a allow null big number. Okay. And what's, what do you think would be like a. Reasonable deprecation schedule to like remove it completely. I mean, in my mind, if you're changing. Like. The Jason RPC. I mean, this is also a prior discussion in the, I think you're part of the other Jason RPC. Steering API calls. Yeah. Yeah. I mean, that's almost something I would expect. This is one of the reasons I guess why we also need a version field or something inside. Because you can imagine if you went to like, you know, Jason aren't like, right now you go to your URL slash whatever and you just post something. If it was your URL slash V2, if there was some sort of versioning on the API, because right, the promise right now you're, there's no way to detect backwards. So I think that's the, the backwards compatibility is going to be impacted. So I mean, in my mind, until there was some sort of versioning, it should still be present. Okay. Like removing fields is backwards breaking where as adding fields is kind of safe. Yeah. This is one of the first times I think think of where there's been an issue. I can't remember for the, the state roots. Yeah. So I mean, that's the important thing is it still exists and is like a, a thing. So I mean, I guess in my mind, I don't really want to see this go away until there's some sort of version field. Cause that way you can, if you start receiving Jason or PC requests that are not versioned, depending a slash V, V2 on the end, you know, this thing is broken. At least return them something. Gas price related. Yeah. But again, I was looking the other day. There's still, I think about 50% of the users that are still on like, you know, antiquated versions of ethers. And so it will break a bunch of, and it's also very spotty. Like you'll see like version 4.4.4.7 has a ton of downloads, but 4.4. 8 doesn't. Or 4.0. 4.4. 8 doesn't. So there's obviously a lot of these are probably deep nested dependencies in other things. Got it. Yeah. Yeah. What? Yeah. Oh, go ahead. Yeah. Yeah. I was going to say. If say we introduced something like version, JSNRPC around the merge, right? Like we said, you know, like the JSNR, because there won't be a ton of JSNRPC changes around the merge, but there, there will be. And like the block format will probably not change, but like some fields are kind of being set to zero forever and whatnot. Like, it feels like logically, you know, we, there is kind of this big set change in terms of functionality there. Do you think that would be kind of a reasonable time and, you know, probably say like Q1 next year, if we have a new versioning system. Well, I mean, yeah. Yeah. So one of the advantages of having a versioning system is so for example, if currently your URL is 1-2-7-001-8-5-4-5. If that's the URL, then the geth node should just still continue returning a bunch of legacy values in these things. But if it's, you know, slash V1 slash, then you have the opportunity to, you know, exactly like you can drop state root. You don't, you don't even need to include it. You can just throw it in the window. You can then drop gas price. And then at some point, you know, if at least then when I'm requesting without the slash V1, you can feed me back an error saying unsupported geth, geth no longer supports version zero legacy version APIs. At least then there's a, an error that the user is going to see the user that, you know, when they're, when their application blows up because some deep dependency is using an old version of ethers and it can no longer get the, the gas price. At least they see a human readable thing seeing like the back end you're connecting to is a flaky. Yeah. Upgrade. Got it. And in the meantime, if we wanted to kind of soft deprecated, right? Like if you start returning minus one, then it means nobody can actually rely on that field, but you potentially don't break things. Right. I mean, for me, minus one is fine. I can imagine a lot of scenarios where minus one is going to cost people money because now they're going to, they might be, they might be taking that and adjusting the fee for something. And now they're subtracting, subtracting. So they're actually adding some value. So maybe zero. Is it better? Zero might be the least worst option. So. Yep. Yep. Yeah. I can see minus one or even the worst cases, like if it creates some sort of underflow and like, you know, you're adding like all your balance as a max priority fee or something. Exactly. Exactly. That would not be good. Yeah. Yeah. Okay. Yeah. This is really useful. So I'll share that back on, on the Json RPC. Thread. Does anyone else have comments on that? Yeah. Let's hope nobody divides by zero. I mean, at least at that point, it should fail. Right. And not send your entire balance. I mean, divide by zero either gives you NAN or, or if I actually don't know, it might give you negative if for a negative number, but. Yeah. Divide by zero is going to be bad. No. Cool. And I guess you're talking about just an RPC. I think Trent, you mentioned this just at the beginning, but like, yeah, we put together a. A quick document that specifies all of the changes coming in. In London related to Json RPC. So if you just want to have one place to look, this is pretty final. Going forward, now that we have a separate repo for Json RPC and whatnot, we'll probably be able to use branches and whatnot to, to track those changes, but we just didn't have those in place for London. So. There is this, this hack MD doc, which. Which kind of just, yeah. Explains like for every type of field, you know, what's changing for 1559 transactions and, and mentions obviously fee history being the new API that's been added. Aside from that, there's another thing about the roadmap. I'm not sure what the question was. I think you added that. Yeah, I'm not sure. Let me see. It was, I think it was about. Planning for Shanghai or what's next. Just getting thoughts on that. Yeah. I'm not sure this is like the most valuable thing. So I feel like it's, I think it's the most valuable thing. I'm not sure. I'm not sure what the question was. I think you added that. Yeah, I'm not sure. I'm not sure this is like the most valuable thing. So I feel like if people have other, anything else they want to discuss, we should probably get. Through that first. Yeah. If not, there is something else that's even more valuable. So the theorem.org website wants to try to highlight which wallets support 1559 at which ones don't. So they're kind of looking for a list of wallets that plan on supported yet around around launch. And if that's the case, if you can just leave a quick comment on the issue and say, you know, we're wallet X and we will support it. Yeah, that would be pretty good because then users can come and know kind of at a glance if their wallet supports 1559. Yeah. So if people just want to leave a quick issue there. I could comment on the issue there. Yeah. And then. Yeah. For the roadmap stuff. I mean, there's a link in the issue and I think it's probably not worth spending time on this synchronously, but oh, my Frederick, just on the, literally the issue I just linked above your, your zoom comment. So the theorem.org issue. If you, if you could just say, you know, we support it from my crypto. That's good enough. And if we can get like a couple of those. Yeah, it'll be at least a good start. Yeah. I mean, it's easier if there's like, you know, four or five already there. We, you know, you can just tell people to like submit a PR to add their, their wallet in the future. But just so we can start with a, a handful of wallets. Yeah. And I guess, yeah, for the roadmap and stuff, just some context, like we were discussing this on our core devs, basically. How should we go about naming upgrades? How, whether there's value in trying to stick to a very strict schedule or trying to like, I guess, yeah, this is probably the best question to ask here. When we're planning upgrades from an infrastructure or just like tooling perspective is the biggest pain point actually adding support to the upgrade, which in this case feels like it is, but I'd be curious just like more generally, if you look back at like Berlin or Istanbul or whatnot, or is the biggest pain point kind of the timing of the upgrade, because some people think we should kind of have upgrades happen at these times and, you know, like one upgrade in June, one upgrade in December, whatever, no matter what. And this way we can provide kind of more predictability in terms of like the tooling that's dependent on Ethereum and whatnot. And there's the other point of view that's basically if you're doing an upgrade, most of the work is actually adding support for the EIP show. We should just, you know, ship, say London, whenever 1559 is ready and make sure we give plenty of time to adapt. So yeah, I'm curious if like the predictability of the time is more important for anyone here than the kind of focusing on the biggest or most complex thing in the upgrade and potentially delaying the upgrade over that. Yeah. And yeah, this is the eighth musicians, right? If people have thoughts they want to share on this later. It's definitely a big discussion. So no pressure. You want to provide your thoughts async. Yeah. Yeah. Cool. I think that's all we had on the agenda is that. Yeah, I think we covered everything, including a couple of other things which weren't in the agenda, which is great. Does anybody else have other discussion points or lingering questions that they wanted to bring up? I'm Sid from Coinbase. I work on Coinbase wallet. We have a couple of colleagues here as well. Thanks for organizing this call. Super helpful. I, you know, we're listening and we noticed that we are also amongst the wallets that are still working out our plans. I think it's a combination of working through what we think the best UX might be, but also having a bit of reluctance in the sense that when the fork happens, we want to see what the actual data and the gas price oracles are staying. And so we're holding off maybe for a couple of weeks post launch. And it sounds like there's a few other wallets in that boat as well. We wanted your feedback on a little bit of downside planning and risk planning. What do you, do you feel that there are any red flags here around something could go wrong and cause massive disruption to our clients, to our users or anything that we should watch out for from the do nothing path for the first week or two, where all of our users are either getting stuck transactions nonstop or they're massively overpaying. So yeah. So I mean, there's two different things, right? One is just like the hard fork itself and just like, like any hard fork, you know, if I wear a coin base, I would like freeze deposits, you know, an hour before and like, you know, monitor the situation and, and, you know, wait and see what, you know, that everything's running smoothly and, and then turn deposits back on. And obviously, if you see a consensus issue, like the consensus issues is like sometimes they'll take hours or days or whatnot to happen. So I'm sure you all have processes for like freezing everything. If, if you detect one. So I'm at a high level like, yeah, I just say like monitor the hard fork closely. If you see anything weird, you're better off freezing things and waiting for like, for more information. And I think, yeah, just to clarify, you know, we have obviously the main exchanges and we have Coinbase wallet, the non-custodial wallet. Oh, okay. Got it. Tell me about the non-custodial wallet app. Okay. Okay. Okay. Yeah. Yeah. So I think then with regards, you know, like if you keep using legacy transactions, the experience will not be worse than it is today, right? Like the, and all of the gas price oracles, I think will still keep reporting gas price estimates based on like the historical data and blocks and whatnot. So you will like, you will still be able to like submit legacy transactions. What happens is like, you know, when we say like your users will end up overpaying, they're overpaying today, right? Like they just, they will not get the benefit of 1559. But they shouldn't overpay by more than they already are. Yeah. Just because you can still kind of estimate based on the data that was included in historical blocks and you're basically back to like a first price auction. And the only difference is like when you have a 1559 transaction and you set your max fee, whatever you, the difference between the base fee, your tip and the max fee goes back to your user. Whereas if you're just using legacy transaction, that all goes to the minor. So, you know, I, yeah, it's not the end of the world. If you want to wait a couple of weeks. And it also doesn't, there's some comments in the chats about like if everybody waits, then like, we don't get good data. That's not necessarily true because what you do get data on is the block utilization ratio and how frequent stuff like spikes are and whatnot. So you, like we were talking at the very beginning of this call, like how far should you look back in terms of blocks to estimate, you know, the base fee, I'm sorry, the priority fee and whatnot. Like you'll get all of that data. So even if nobody was using 1559, you would kind of see that like, you know, we get spikes and we see that the, we see that the base fee goes up, you know, on average, every like hour or every day and these spikes tend to last an average of like three blocks or five blocks. And that's all pretty useful. And you'll still be able to look at blocks. You know, some people, there is an economic incentive to use 1559. So some people will use it and you can still look at blocks and look like, you know, what's the, what's the like lowest quartile of a priority fees that miners accept. And if you just want to like, you know, use that as a reference, that'll be possible. Yeah. So I think, yeah, I think, you know, it's not the end of the world. If you wait, it definitely doesn't like block the rest of the ecosystem. And the status, you're basically kind of stuck at the status quo. Yeah. And unless I'm missing something, but that's, that's pretty much how I understand it. That's really helpful. Thank you so much. Yeah. Yeah. And Barnaby, I see you have a comment in the chat. I don't know. Do you want to share some thoughts as well? I mean, yeah, briefly, like, if you don't want users to overpay and you want to keep using today's infrastructure, but you still think 1559 is pretty nice. You could just, just set the max fee parameter to whatever you were going to set the gas price of a user and then tune down the priority fee to two or three. So what you're doing, if you're not using 1559 is your legacy transaction is just converted like the gas price is taken for the max fee and for the priority fee. So you're not getting the benefit. So you could just, yeah, whatever gas price you were going to set, just set that as max fee and use a very small priority fee, something like two or three. And most likely, I mean, you will never pay more than the max fee, which is the gas price anyways. And most likely you would pay less as well. Cool. Any other questions? I have a question about timing. I just want to confirm. I think Trent mentioned earlier that the hard fork will happen on 12 UTC on the fifth, is that correct? Yeah. So it's always tricky to estimate those. The closer we get to it, the better the estimates get just because of the proof of work drift, right? But right now it's scheduled for, I think, less than 12 UTC, more like 10 UTC, 10 PM UTC. Yeah. It's actually been, it's actually moved a bit in the past day. So. Oh, it's, it's moved that much. It moved by two hours. Yeah. Oh, okay. I thought you said, I thought you said PM. I was like, whoa, that's quite. Oh, sorry. Oh yeah. No, sorry. Sorry. Yeah. Oh, actually wait. No, that's still 12. No, you're right. It's still scheduled for 12 UTC. Scheduled. Yeah, scheduled. But yeah, definitely check this like within 24 hours of the fourth, usually you have a pretty good. Like estimate down to the hour. But this is helpful. Thank you. And there's two ether nodes also has a countdown. So like, and the, I think they kind of vary in which data they look at. Because they tend to be off by like one or two hours each. So like if you want to, if you want a good window, you can basically set, you know, both the ether nodes and the ether scan one and you have like a high probability that it's between those two. I'm just seeing a comment from Matt about the test net stuff. So we did spam the test nuts, but so like, definitely the mechanism to change the base view was, was tested, but it wasn't consistent, which is what we'll see on main net, which is like consistent usage and then spikes on top of that. And not, not run by a spam bot. Organic demand is always going to be a little different. Sorry. I think that's everything. And we're right at time. We filled up the hour with. Delightful discussion. Thank you everybody for coming. I really appreciate it. And I think we turned up some, some points, which I don't think we had seen before. So this has been really helpful. This will be uploaded where the other videos are. I think that's the Ethereum foundation YouTube channel. And we will also have notes for it as well for you to share with your colleagues who were unable to attend. So yeah, the last thing I think Tim mentioned a while ago is if you are a wallet that is supporting or when you do, just leave a comment on. The Ethereum.org repo mentioning that you support this just so users are aware of their options. And then. The other thing was. It sounds like it would be helpful to have a call in a few weeks after London when we can have some data. Maybe I have a presentation from Barnaby. I'm sure he's got all sorts of great ideas about how to present this stuff. And we'll have a much better idea of how this is actually working out in the wild. And get everybody to share their, their progress. And then there's the other things of the discussion on. Fee history and. I think that was the only thing Tim, is there anything else? Yeah, there's that. Well, the Jason RPC gas price stuff. So I'll make sure to update that thread. Based on your comment. Cool. Yeah. Thank you so much, everybody for coming. And if I emailed you, that means I have you on a list. And if you want to add any of your other colleagues, just let me know. And we'll make sure to invite them in the future. Cheers, everybody. See you. I think it's fine.