EIP-1559 Coordination Call (Breakout #11)

all right we're going to get started here i know we have limited time so i want to make the most of it i welcome everybody to this fourth 1559 coordination call uh fourth and probably the last ahead of the london fork which is next week i'm sure you're all aware of it um it's going to 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 um so i believe it put the agenda in the chat you can check that out if you want but this is a very open session um i think a few of the we have a few wallet teams here i don't know what it makes sense to start with um if anybody has any pressing discussion points they want to bring up before we get into some demos i'm open to hearing that richard you're unmuted so i said one quick comment i'm gonna take that as you want to talk go ahead i mean it's 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 uh tim is joined tim i don't know if you want to lead off with any general comments or links to anything i can share the rpc doc that you put together um yeah i mean if anyone has has like questions or things i want to bring up first we can do those but otherwise yeah we can uh we can kind of share some updates i guess from from our end and start that way yeah go ahead whatever you've got everything oh uh okay so there's a question uh from santiago we can start there uh so what are there's any gas price oracles the gas station get now yes now working on 1559 um i don't know if any of them oh yeah we have someone from eat gas station on the call two people yeah yeah so yeah i'm andre here yeah working for a target station uh so yeah indeed yeah we are looking into this uh yeah we've been working on this this month uh we probably won't make it exactly to the same uh yeah to the 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 so 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 uh because that's like your secret sauce that's fine but yeah yeah i think it's pretty much what's being shared on what this uh uh page i can't remember this uh yeah it's basically like uh pretty close to the pros uh pers approach we we we we have uh like checking the last 100 200 blocks uh and then trying to find like the uh the quantile out of it uh for the tipping uh field and yeah uh given certain quantile we we will share like forgiven like uh standard or fast or uh yeah ultra fast line for the next block for our transaction to get included in the block these details we we still need like two yeah to tweak some stuff and yeah those details the implementation detail we most likely share some of it so yeah as we get the thing like more clear and more like uh in shape then yeah we have more resources to share yeah i think one thing i think it was barnaby 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 fee moves so i'm not sure if that's something you're able to back test but um i think that would be really interesting like to see you know do you get better estimations if you look at like 10 versus 50 versus 100 versus even like something like five because um because the base you can basically double i think in like six blocks um and and and that means like if 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 you know if that demand spike is over the tips will probably go back down quickly um and again you'd want to with that quicker so yeah it 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 yeah thanks for sharing um chris i see you have your head down yeah um i'm with blocknative and uh we we're we've updated our gas platform to support 1559 it's also triggering on the 1559 fork block so that'll that'll go live when when 1559 goes live and it basically adds to our api you know a max a fee cap 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 um but then very quickly it's going to switch to our full models we just need to get actual data on those models and the 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 natives gas platform support nice out of interest do you have anything on boxton for that available already um our guest platform only runs on uh on mainnet we don't we don't really provide an api for the for the test nets for that but we do 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 want to 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 cool anyone else have uh comments or just thoughts on oracles they wanted to share before we move on i think um oh go ahead go ahead yes sorry so i also have some experimental but yeah that's been shared the link has been i see now i see and the link has been shared so i have so uh there's this uh fee history api that uh and i i i wrote some um some some javascript uh oracle using this this history api that's also supposed to be like capable so it's also theoretically capable of making suggestions for like more urgent or or less urgent and more economical uh fee options and everything but uh yeah so i believe we really need the main beta to to test these things and yeah but um at once minute launches uh i'd be uh very happy to like see some comments or issues opened on that repository if anyone uh wants to try this this this fee oracle thanks yeah thanks for sharing um and yeah it feels 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 uh full blocks usage um yeah cool anything else on the oracles i was just going to surface if anybody from gas now or tai chi or spark pool is here uh and you wanted to ask any questions um now would be a good time uh no no pressure if you don't have anything but yeah we do not have anything we just uh we have finished all the code uh uh revising and the review so we are just waiting for lunch and currently no uh from our site okay thanks all right yeah let me double check the agenda um again this is open so like if if you guys just have a question you want to bring something up just go ahead we don't really have to rely on the agenda strictly um 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 uh i'll go first on our end uh our kind of fee estimation stuff is expected to be ready on monday uh so that's not ready right now um and uh yeah as soon as that is ready i will share a share a link to um the branch along with any build instructions for anybody who wants that uh 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 and so that's no different to what we shared a few weeks ago uh inside the figma files so all of that stuff is pretty much exactly the same gotcha thanks uh kevin from metamask here uh we are live on private beta uh on our mobile apps uh which is ios and android with our desktop extension uh version we should be live next week sometime uh on private beta as well and when the london hard fork happens we'll we'll go to uh prague 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 uh 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 going to 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 um kind of what our ui we want to show essentially kind of uh yeah kind of trying to limit the multiple on the base fee um and being smarter about the the tip instead um so that we don't have like this long tail or this huge range um of like oh your your gas price could be some large amount that might be uh way bigger than what it ends up being in practice okay yeah and i think um 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 um or making changes in your ui so that's good um sorry i keep i i i keep i can only see a few names on this screen some apologies if i keep missing wallets who are in attendance but if there's anybody else who wants to say something just just go ahead i would just say briefly argent we're doing the same thing um as uh rainbow so we're holding off for now um i think we need to be a bit confident what kind of data sources we can use for the oracles um and it sounds like most of them are kind of fine tuning things and we'll be probably for a couple of days at least afterwards anyway um where you get to get it in uh with the ux that we already have we believe it suits the same model um but it's probably gonna be i'd say you know at least a week or so afterwards a week or so from here or from the uh after 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 um so i think we'll come back to it probably about a week after um london's gone live and then start digging into it and 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 uh leaky do you want to talk at all about i see there's some discussion going on about decimal to hex um does anybody want to bring that up verbally just so everybody's aware of it yeah there's a change basically in the fiesta it's just for the history so not for submitting um 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 um 1106 still uses decimal and the master currently which then will be released to 1107 users hexadecimal that's better 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 uh sorry which values are being changed so actually one of them is the input value and the other is so so 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 uh one on one side the javascript code could accept the return value both in both formats but 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 uh yeah maybe maybe that's that's the best way to go i think the main problem is basically the input values um because like i can i can as a client i can basically check um the value i get um no i mean the output values i can check basically what value i get and then decide on that but 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 note can accept both just in the transition period basically um for for a while we can also switch that off at some point um that would be nice because otherwise it's quite problematic yeah but right now so right now the the currently released version that only accept decimal so then the the proposed script should also like use a decimal value so maybe that sounds like we might just get stuck with that but uh yeah also if open ethereum and b2 already use hacks and when i think wrote that just now then it's one big good either so that's the problem that uh right now we have a release version of get that only accepts decimal and then we have other clients that that accept hacks or i don't know maybe do they accept both no they don't at least open ethereum when i tested it it was breaking um so they only accept hexadecimal is that right yeah uh-huh so it's not so easy yeah so then it's badly the race unfortunately yeah and it was probably my mistake and i'm sorry about it but yeah so i i then then i don't think we should release this javascript code in uh in a way that it uh uses a decimal value in the call because i mean for the free history input value the block count because uh that only that will only work in guess then and won't work in the other clients so are you referring to the json ap the so the json rpc api are you saying that the inputs to geth or you mean the results the input now now i'm i'm talking about the input so so so the so the api i'm i'm thinking about how about like from the north side some from the get a implementation site so by input i mean the fee history apis input value the block count and and that's now yeah so the currently released version of get accepts the decimal value there and the other clients accept the hex value and the master branch of get only or is already updated to hex so maybe i think most clients accept a quantity which is just a non-zero prefix uh hex right they know the the standard is everything to be hex and and then uh yeah yeah as the quantity values are right it's like yeah the quantity is a hex value yeah so so to me the issue with an ethereum is that uh really if if seven is not released i might have to as kef is the most popular client i might have to uh recreate a new market university with netherion that will support the the six and then release again when seven is out um because i kind of do the uh this guessing stuff like in javascript because it's all tight um so ideally if seven was out before that will be great is there a plan to release 10-7 before the hard fork or would this be after the hard work i believe after but somebody more somebody closer to the guest team can maybe respond actually i don't know yet okay i will reach out to the rest of the team and find that out yeah but uh yeah i i will try to find it out too but yeah i just don't know it right now but uh 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 uh like uh yeah so so accepting both uh both formats in get that just won't solve this 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 uh yeah i think the only way to fix this is to like do do do a at least a hotfix release for this issue and yeah i will 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 7 and to me works perfectly and hence i've released ethereum thinking that was gonna happen but yeah so if you just let us know or just in the in in the score chart you know so that i can plan ahead and i can i really think that being compatible with gas is you know at least will touch more more clients than the other way uh question for rigma related to this um is it possible that the uh get feed data um metal from ethers uh 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's suggested hard-coded one-way got it got it um but what i plan to do in the future is that there's a fee data structure um and so that's also rolling up like so in v6 there will be there will no longer be a provider.get gas price that'll be rolled into fee data as well so if you look at the result of fee data you get inside that the gas price if it exists the max fee uh per gas and the max priority fee per gas if those exist so in the future at some point once like the the dust is settled and we know exactly what what um v 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 uh 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 uh fast slow medium cheap something like that um but yeah for now then that exists that's just kind of like future plans for now it's going to there will 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 one way but soon it'll start pulling fee data and making some sort of educated guess based on that if that makes sense yeah perfect sounds good thank you for clarifying anything else on this topic actually that does bring up one quick question is that cert currently sufficient is the previous advice of hard way still i would say two is so one so the the background here um and i can share barnabas posts uh for people who want to read it um uncle mev is in my most red things um one going covers the opportunity cost of your block being uncold um if you just look at like transaction fees um but the the challenge is that since uh 1559 was developed mvv is now a big thing uh so the opportunity cost of being on called is not only you lose the transaction fee revenue and the block you know the block reward uh like the delta between like an uncle reward and the block reward but you possibly lose kind of your your mev 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 um and that gets much trickier trickier for two reasons one is mev rewards are very variable right they're not evenly distributed um and two is you don't actually want to like compensate for a hundred percent of possible mev right like when there's a 100 mev bundle it's probably fine for a user to wait a block to not like you know over tip that um so last time i checked like a two way default gives you basically uh compensates for roughly 50 of like historical med blocks so that means that and and mev blocks are only 60 of blocks right now so that means that um if you if you compensate for for half of those it's like there's 40 percent of blocks with lme v and then you're good in 38 of blocks so like roughly 70 percent of the time to go should be enough and i think three way was enough to compensate something like 80 or 90 of mev opportunities right now um and that probably means something like you know 90 plus percent of blocks so um two to three probably makes sense depending on like how aggressive you want to be um compared to you know the the prevailing mev numbers um and the thing i shared from barter bay has like kind of the formula that you you can use to plug in that um i don't think does it link the flashbots dashboard uh it does not um 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.flashbots.net website um and that'll actually show you historical mev um so that's what i kind of use and i i just like very roughly eyeballed it um and you know at the end of the day you're kind of debating between like one to three ways so it's not like it has to be a perfect estimation but yeah unless unless mbv changes a lot i think those numbers make sense i'll probably follow frederick's example then or frederick i don't know how to pronounce the name sorry uh 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 mev into account at all um and two is you know uh i know if you if you had like the concept of like a slow transaction two is probably like a good uh good value three yeah i had a question i had a question for fred 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 switch happens like is the bait the up to a given base fee is that hard-coded or is it based on some like trajectory or or um yeah you didn't butcher my name that was all good uh basically we we've set some hopefully same defaults uh so basically hard-coding it but we are we will be monitoring it and like changing them on the fly if um if it turns out that we are like completely wrong um 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 uh if anyone wants to read it i put it in the chat i can post it again [Music] are like definitely work in progress but our current fee estimation strategy all right i know tim had requested that we add um the discussion about requiring uh sorry i lost the agenda again requiring gas price uh and the expected deprecation let me link to the discussion tim if you want to touch on that sure so um right now guest and i think all other clients um currently return a gas price value for 1559 transactions in json rpc so to be clear at the protocol level 1559 transactions do not have a guess price field but because a lot of tooling depends on it um so guest originally kept it in the json rpc and i think other clients have have added it so far um and basically uh what it does is before a transaction is mined we can't actually know its effective gas price on the network because it depends on the base fee so before a transaction in its mind uh that gas price field in the transaction will return the max prior the max fee um so the maximum the transaction could ever pay um and then after the transaction in mind it'll return the effective uh the effective gas price which is uh basically the base fee plus the priority fee that was paid um so the the goal in adding that was you know to kind of act as a sort of backstop and to minimize uh breakage in the ecosystem um 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 the field changes based on the the status of the transaction um 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 what not um and one idea that we have was that we would deprecated the first release after the next hard fork so not london um but we're gonna need to have another hard fork in december even if just to push back the difficulty bomb so that that hard fork would still contain the gas price field for fifteen to nine transactions then the first release after that you kind of deprecate it so that means if you wanna stay on the old kind of release you can uh you can do so basically up to the too hard fortune now um so i was curious i guess to get all of your thoughts and rick has his hand up right so i definitely want it in place much longer than that the second that's removed every version of ethers prior to 5.4 will fail if you like for a lot of things if you just try getting a transaction just get transaction will fail if there's not a gas price there because the block like the the response is validated to 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 or it has to be like an integer value it has to be yeah i'm pretty sure yeah it checks um that was one of the changes in v 5.

4 was that it used to be big number now it's a allow null big number okay um and what 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 json rpc i mean this is also probably discussion have in the i think you're part of the other um 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 um uh because you can imagine if you went to like you know uh json like um 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 problem is right now you're there's there's no way to detect backwards that 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 whereas adding fields is kind of safe this is one of the first times i can think of where there's been an issue i can't remember for the the state route uh stat when we added status we did some state route but i think state route still exists right yep so i mean that's the important thing because it still exists and is like 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 because that way you can if you start receiving json or pc requests that are not versioned if you're not uh appending a slash v1 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 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.47 has a ton of downloads but 4.4.48 doesn't or 4.

0.48 doesn't so there's obviously a lot of these are probably deep nested dependencies in other things got it yeah yeah um what uh yeah oh go ahead i'll just say oh yeah yeah i was gonna say if say we introduced something like version json rpc around the merge right like we said you know like the json r because there won't be a ton of json rpc changes around the merge but there there will be and like the 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 step change in terms of functionality there um 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 that's what i mean yeah like well i think yeah one of the advantages of having a versioning system is so for example if currently your url is one two seven zero zero one colon eight five four five um if that's the url then the geth node should just still continue returning a bunch of legacy values in these things you know slash v1 then you have the opportunity to to exactly like you can drop state route you just don't you don't even need to include it you can just throw the window um you can then drop gas price and then at some point you know if at least then what i'm requesting without the slash v1 you can feed me back an error saying unsupported geth no longer supports version 0 or legacy version apis at least then there's a an error that the user is going to see the users 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 uh flaky yeah upgrade got it and in the meantime if we wanted to kind of self-deprecate it right like if you start returning -1 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 snares or minus one is going to cost people money because now they're 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 a better zero might be the least worst option um so yeah yep yeah i can see minus one or even the worst case is like if it creates some sort of underflow and right you know you're adding like all your balance as a max priority fee or something exactly exactly that would not be good yeah um yeah okay yeah this is really useful so i'll share that back uh on on the jsonrbc uh thread um does anyone else have comments on that yeah let's hope nobody divides by zero um i mean at least at that point it should fail right and not send your entire balance um divide by zero either gives you n a n or or if i actually don't know it might give you negative if for a negative number but um yeah divided by zero is going to be bad um cool uh and i guess yeah talking about jason rbc i think trent you mentioned this just at the beginning but like yeah we we put together a a quick document that specifies all of the changes uh coming in uh in london related to json rpc so if you just want to have one place to look this is pretty final um going forward now that we have a separate repo for json rpc and whatnot we'll probably be able to use branches and what not to to track those changes but we just didn't have those in place for london so um there is this this hack nd dock which uh which kind of just yeah explains like for every type of field you know what's changing uh for 1569 transactions and and mentions obviously fee history being the new api that's been added um aside from that there's another thing about the road map i'm not sure what the question was um i think you added that yeah i'm not sure let me see it was i think it was about um planning for shanghai or what's next just getting thoughts on that yeah um 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 um if not there is something else that's even more valuable so um the ethereum.org website wants to try to highlight which wallets support 1559 which ones don't um so they're kind of looking for a list of wallets that plan on supporting it around around launch um if that's the case if you can just leave a quick comment on the issue and say you know where wallet x and we will support it um yeah that would be pretty good because then users can come and know kind of at a glance if their wallet supports 1559 um yeah so if people just want to leave a quick issue there i could comment on the issue there um yeah and then um yeah for the roadmap stuff i mean the threat is linked in the issue and i think it's probably not for spending time on this synchronously but oh uh mike uh frederick uh just on the literally the issue i just linked uh above your your zoom comment uh so the ethereum.org issue um if you if you could just say you know we support it from my crypto um that's good enough and if we can get like a couple of those um yeah it'll be at least a good start and then it's much 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 um yeah and i guess yeah for the road mapping stuff just some context like we were discussing this on our core devs basically uh how should we go about naming upgrades um how whether there's value in trying to stick to a very strict schedule or trying to like uh i guess yeah this is probably the best question to ask here um when we're planning the upgrades um 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 in december whatever no matter what um and this way we can provide kind of more predictability in terms of like the 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 so we should just you know ship say london whenever 1559 is ready and make sure we give plenty of time to adapt um so yeah i'm curious if like the predictability of the time is more important for anyone here than um the kind of focusing on the biggest or most complex thing in the upgrade and and potentially delaying the upgrade over that um yeah and uh yeah this is the east magician's thread if people have thoughts they want to share on on this later um it's definitely a big discussion so no pressure if uh you wanna yeah provide your thoughts async yeah yeah cool um i think that's all we had on the agendas that yeah i think we covered everything uh including a couple other things which weren't in the agenda which is great um does anybody else have other discussion points um or lingering questions that they wanted to bring up hi uh i'm sid from coinbase i work on coinbase wallet uh we have a couple of colleagues here as well uh thanks for organizing this call super helpful uh i you know we're listening in we noticed that we are also amongst the wallets that are still working out our plans we want a i think it's a combination of if working through what we think the best ux might be but also having a bit of reluctance in in the sense that when the fork happens we want to see what the actual data and the gas price or 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 uh we wanted your feedback on a little bit of downside planning and risk planning what uh do you do you feel that there are any uh red flags here around something could go wrong and cause massive disruption to our clients uh to order 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 non-stop 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 coinbase 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 uh you know that everything is running smoothly and and then turn deposits back on and obviously if you see a consensus issue like the thing with consensus issues is like sometimes it'll take hours or days or what not uh to to happen so i'm sure you all have processes for like freezing everything if if if you detect one um so 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 and waiting for uh like for more information um yeah i think yeah just just to clarify you know we have obviously the main exchange and then we have coinbase wallet the non-custodial wallet oh i'm scared only about the non-custodial wallet app okay okay okay um yeah so i think then with regards you know like if you keep using legacy transactions the experience would all be worse than it is today right like the and 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 59 um but they shouldn't overpay by more than they already are um 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 um 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 feed goes back to your user whereas if you're just using legacy transaction that all goes to the miner um so you know i yeah it's not the end of the world if you want to wait a couple weeks um 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 uh the blocky utilization ratio and how frequent stuff like spikes are and whatnot so you you yeah 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 the base fee uh sorry the the priority fee and whatnot like you'll get all of that data um even if nobody was using 1559 you would kind of see that like you know we get spikes and we see that the the we see that the the basically 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 um 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 uh a priority fees that miners accept and if you just want to like you know use that as a reference that that'll be possible um yeah so i think yeah i i think you know it's not the end of the world if you wait um it it definitely doesn't like block the rest of the ecosystem um and the status you're basically kind of stuck at the status quo um yeah unless i'm i'm missing something but that's that's pretty much how i understand it that that's really helpful thank you so much yeah yeah and barnabas you have a comment in the chat i don't know do you want to uh 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 feed parameter to whatever you were going to set the gas price of the user and then tune down the priority fee to two or three so what you're doing if you're not using one five five nine 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 are 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 one any other questions i have a question about timing i just want to confirm i think uh mentioned earlier that uh the hard fork will happen on 12 utc on the fifth is that correct yeah so it's 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 uh but right now it's scheduled for um uh i think less than 12 utc more like 10 utc 10 pm utc um yeah it's actually been it's actually moved a bit in the past day so um oh it's it's moved that much it moved by two hours yeah in the future okay i thought you said if they said pm i was like whoa that's quite oh sorry oh yeah no sorry sorry yeah yeah um oh actually wait no that's still 12. um no you're right it's still scheduled for 12 utc um schedule yeah scheduled um but yeah definitely check this like within 24 hours of the fourth usually you have a pretty good like estimate down to the hour got it uh this is helpful thank you yeah and there's two uh ethernodes also has a countdown um so like and and they i think they kind of vary in which data they look at um 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 ethernet 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 um so like definitely the mechanism to change the base fee was was tested but it wasn't consistent which is what we'll see on mainnet which is like consistent usage and then spikes on top of that and not not run by a a spam bot um 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 um i really appreciate it and i think we turned up some some points which uh i don't think we had seen before so this has been really helpful um 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 weren't able to attend um so yeah the 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 um the other thing was oh it sounds like it would be helpful to have a call in a few weeks after london when we can have some data um maybe have a presentation from barnabas i'm sure he's got all sorts of great ideas about how to present this stuff and um we'll have a much better idea of how this is actually working out in the wild and get everybody to share their uh their progress and then there's the other things of the discussion on fee history and i think that was maybe maybe that was the only thing tim was there anything else uh yeah there's that well the json rpc gas price stuff so i'll make sure to update that thread uh based on your comment rick cool yeah thank you so much everybody for coming um 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 uh we'll make sure to invite them in the future cool cheers everybody see ya bye thanks bye