EIP-1559 Wallet Interfaces Call (Breakout #9)

okay we are recording um yeah so trent i see you shared the agenda um one thing also you mentioned is that a couple teams have like mockups and whatnot that they've been working on and i think they've shared with you um i don't know if it maybe makes sense for like teams who've actually like prototype stuff maybe take five minutes or ten minutes to walk us through it um i feel like that might be a good way to set the context um i don't know if you know now that it's recorded that changes things um otherwise we could we could kind of go through the agenda or just like the questions that people had um 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 uh yeah just talking in the abstract yeah i know i think that would be great and i think we have two mock-ups from jake and carl i i think 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 uh source yeah yeah yeah and share your screen if you haven't pulled up or i can sure no i got it right here just give me 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 um 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 um there's probably a lot of things that are going to change or things that don't make sense um but here's where we're at uh so the scenario this is sort of a stripped-out view just to keep it simple the scenario is focused on uh swap so we're showing unit swap here um uh some of the 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 uh increasing traffic so we're sort of estimating the fees are going to be going up there's a little bit of a wider range um so you go through you hit swap on unit swap this is the revised transaction screen so there's really only two pieces we've we've changed um we're calling it an estimated gas fee this is what we expect you to pay um and then there is a range um so that range would be if um you know if the network uh 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 um 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 and then if you hit edit that brings you over into the edit view um the the way we're thinking about it now is trying to shift focus from speed and more towards um like purpose like what type of transaction are you doing and then what how much should you be paying based on that so some we're gonna have to have a good fallback so we're not always gonna know that scenario of what somebody's doing but our hope is um we can you know sort of understand what they're doing so in this case they're doing a swap um 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 um and then if they override that just trying to inform them hey maybe 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 uh 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 um but here's where it is now your gas limit max tip for gas max price per gas i still think there's some room to improve this a little bit specifically between how the max tip uh rolls into the the max price i don't know if it's very intuitive here but we are gonna need some error states we just have one showing here but there's definitely gonna 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 uh so we're showing some of those stats that we have in the main screen so the fee range the estimated fee uh 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 fee is at some point we're just going to have to say unknown like we're not sure when it's actually going to process so i can pause there there's some more thought in the the actual numbers but a lot of them i'm 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 um does anybody have any initial questions or things that they want to clarification on um are you deserving to be updating like some like every 20 or 30 seconds to like update those two ranges 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 i mean we'll have to update pretty quickly um and that'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 gonna 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 uh those numbers make sense but at the same time it's like a balancing act we don't want to show too big of a range um so it's still still a bridge to be crossed [Music] are you gonna allow people to submit legacy transactions i'm not sure there's a use case for it but um they'll still be possible on the network yep totally okay um yeah this is really cool one question do you somehow detect if the current base fee on the network is really high can alert the user somehow or you always get send a maximum fee that's greater than the current templates fee without alerting the user yeah that's a good question we did in some of our earlier months 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 fees are really high um we did consider um like um 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 um 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 um yeah and if if that feels important i might circle back and and bring those back into the mock-ups uh yeah there's a comment about like uh should we allow opt-out at the user level to send legacy like i think it might make sense to preserve that but like there's no the the main advantage of sending legacy transactions for the users is the fact that it's like if 1559 is not supported say they use i don't know like ledger and ledger does an update uh 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 uh 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 to 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 dig up and and send a legacy transaction um 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 uh like they won't get the difference between like their fee cap and the base unit tip refunded to them that all goes to the miner yeah absolutely we've been talking about like keeping the old ui experience around for networks that don't support eip 1559 et cetera yeah so yeah that's the thing yeah so for yeah for sure if you're obviously supporting like ethereum classic uh or you know like x die and like they haven't integrated yet and whatnot like um yeah you'll need to keep the old ui uh 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 eve magician's forum thread that dan finley had opened about this but uh yeah yeah the short answer to there so there was a thread in the agenda about that i think at this point the like easiest way is you look at the block header and see if there's a base key in it um unfortunately there's no way to know that like a network will support something in the future so you can't like say we we announced the fork you know tomorrow you can't like look at mainnet and know that 1559 is gonna like happen on for block x um but once the fourth block passes uh the base fee the every single block will have a base fee and so that's probably like the most reliable way to check it thanks cool anything else on the metamask box and trent i believe you said there was another team that had sent yeah i let me i think carl is here from status yeah i'm here um i'll start sharing now great okay can everybody see yes okay great um so trying to keep things initially as close to um what exists now rather than giving people ranges of fees when they're when they're choosing the priority uh which only showing them the maximum that they're going to be paying for that transaction um and then kind of behind this we do have all of the custom uh all of the custom stuff so we're giving them information about the current base feed gas limit per gas tip limit and per gas price limit um and then calculating the the maximum fee um 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 um 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 n or last x box and the average tip that is being given to the miners um if it's above the minimum but below their average here we're giving them information about that um if it's below the current if the per gas price limit is below the current base fee then again that is going to to we can guess that it's going to block that transaction um initially anyway um if i go ahead a little bit further and then there are an additional set of edge cases where if somebody sets a a uh a base fee that is um that is above the current base fee but lower than the the current tip then again we can assume that that transaction won't be uh accepted initially and then again an edge case for for uh for when the calculated tip is going to be below that average um so there are lots of more edge cases here that we need to be watching for um and that all of these edge cases then feed into the actual kind of simple interface where somebody just has a scale and because on that scale honestly we have no idea what these ranges should be um we don't know for example what the what the overall limit should be above the current base fee taking into account the tip should it be uh one gui or should it be like tengui over that we don't really know um and then if i just go a little bit further um if if uh the base feed plus tip is going to be below uh the current base v plus tip then we introduce some extra friction in this transaction to basically get the person either go change the tip or change the limit um and then yeah there are also kind of combinations of these edge cases as well so if the tip is too low and um oh sorry i'm reminding myself of these screens as i'm running through them if the tip is too low and the the overall limit is too low um then we need to also show them information about what is happening in those specific situations um and then i guess the most helpful part of this would be yeah um these are the the edge cases that we're looking for inside that custom fee interface um with regards to romo we had a discussion about this earlier today um and after reviewing the document around how it's going to be released and kind of initially having the one queen 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 the initial let's just say uh 50 blocks um and then switching to this um to this new interface but really we don't really know what what is going to be best on day one or from the first park onwards uh we're very much just kind of throwing ideas out there at the moment and seeing what will work uh but yeah i'll go back to the screens and if anybody has any questions uh happy to help you jump in um hi hi um samuel here and thanks for this i was wondering um since like there's a lot of part dependencies and different options do you have any plans to a b test this to your users or would it be a big bang so um what we well at least what i imagine us doing is um basically being on call when this goes live ideally we chatted about this today as well is we'd have a test room uh to make sure that all of this is going to work uh we're not in a in a position to a b test this interface against the current interface because it is going to go live and we need to accommodate for it uh we can't we can't have the the the current gas interface tested against the new interface just because the the current gas interface doesn't um doesn't like cover all of the parameters that that people can manage themselves um that being said somebody mentioned earlier uh being able to switch the interface to use the uh 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 a b testing i don't think we're in a position to do that with this i think one thing maybe we could help organize is um just user testing for people on once the test nets 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 um but no promises yeah yeah that would be that would be really helpful uh we are gonna run through this uh make sure that everything is usable and make sure that people understand what is happening um after we've got a initial um build ready um and but but the main things that i imagine is changing are going to be the the 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 we still need to figure out that part of it um and i'm not i'm not sure how we're how we're gonna do that that isn't really a um something that i'm i'm qualified to talk about but um yeah i think it's bigger gnome until we start to learn after it goes live so we have some values i don't know if you saw that she sheet that trent and i put together we have like some rough values uh for the priority fee uh that that we've used so basically 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 uncold is um and this used to be quite simple to calculate but now a large part of the uncle risk is mev bundles so if a miner has an mev transaction in their block that's like a high value time sensitive transaction so that the cost of um the opportunity cost of these transactions is much higher um so in the in the cheat sheet you can see there's like a a graph basically that shows like a linear relationship between like what the average mev in a block is and uh you know what should the tip be um flashbots has a dashboard that kind of tracks this over time uh there's no great like uh library right like there's no great way to like plug in that dashboard um in in wallets um but 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 eve goes live and you just kind of you can kind of ballpark you know like what's the average med in blocks uh then and 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 um but they've anyways flashbacks rolled up a bunch of optimizations that will allow for more mev and each block so i suspect by the time it goes live like a decent tip for most transactions is probably going to be like three way um again subject to like how that the muv evolves and yeah yeah the mev stuff is another wait i haven't really touched on that but um that was honestly a big unknown like how mev would interact with this and yeah and what about what that baseline tip should be so that's really helpful thank you yeah 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 are like a wallet and you want to be a bit fancier you could say maybe your fast transaction should be worth it for a miner to include you know in like the 95th percentile of like mev blocks right and then maybe your optimal is like the average and you're slow um there's also i think right now there's only like uh something like 30 or 40 percent of blocks that have mevs so you're slow you could probably set like a tip to like two way which or i forget if it's one or two guy it says that the spreadsheet but that'll compensate basically for blocks with zero ibv 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 um yeah um it does come okay well so there's that and there's also the base view whether our base i mean i know we can determine whether the base b is going to go up or down based on activity but also i we then need to make a call on what a low priority base fee is going to be versus a high priority base fee and then hopefully in the future we can estimate time based on that but there are so many variables and so many moving parts that it's really difficult i i can't right now say okay we know what is going to happen ahead of time um 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 estimation on time um yeah just because there's so much so many different things uh to to include yeah and i think having unchained data like you know like even like a few weeks of launching data will be massively useful to see what you know what the right defaults are um yeah if you i don't know how much like you know tracking you do of like user data but if you're able to see like this transaction failed or you know got stuck pending and and what not like so that's a situation that um i'm a little bit nervous about um and that would be let's just say day one the suddenly high congestion lots of people are trying to transact and uh you essentially have a bidding war then between different wallets and what i i on the state decide we don't want to be in a situation where our estimation is totally off and nobody can get the transaction through from from stateless music using the simple interface um and yeah i guess that's for us to figure out but yeah and i think that's that's a really good thing yeah that's a really good point so um on so this was like the last thing i put in on like the cheat sheet but um when 1559 goes live the base fee is actually set to one way which is tiny um so that means there will be a period where like blocks will be full just because you know there will be this bidding war um so i suspect the easiest way for wallets to uh get around that is to actually wait to display the 1559 ui um and you basically want to wait until like blocks are not like completely full again um and i you know i had some rough like ballpark numbers there it's probably something like uh you know 15 30-ish minutes um and i had like some 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 um yeah yeah yeah yeah yeah so what yeah at 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 box and then switch um 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 over pay slightly under 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 transactions stuck so i think that's just like the yeah the trade-off you like every wallet basically needs to figure out yeah um i guess yeah we're almost like halfway through the call um we did have like a bunch of topics on the agenda but i don't know if just to make it like as useful as possible are there like urgent questions or things that you know people here really wanted to bring up otherwise we can run through the different topics but um i guess i had a question uh so i assume most people are relying on gas apis right now uh just to determine kind of what the best price is and there's various apis um i know that the wallets are on this call i was wondering if you guys were having conversations with uh these various gas apis to help provide uh estimations for for tip calculations when it gets to the point where we need to start bidding again against each other um or like if there are plans for that does that does that make sense maybe yeah i know i know um each gas station is on the call um so they're thinking about how they're gonna treat this i don't know if there are other ones you had in mind okay cool yeah i guess like the etherscan api also has etherscan yeah maybe um who's here from is it harith from etherscan if you want to talk about what you're working on at all or what your approach is uh to be honest we don't really have a clear approach right now so if anyone who potentially uh will rely on our api have any suggestions or any comments i'm happy to hear that and i think barnaby had like done a bit of work looking at like how oracles should adapt after 15.59 uh so i don't know maybe barnabas there's like a few things you can share either here or after the call um yeah that could be helpful sure i mean so first the thing to remember is well we don't have data yet but there is a very strong intuition that um these bidding wars they will be very infrequent and when they do happen they will be very short-lived because if there's a lot of pressure basically 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 they 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 five ten latest blocks and kind of look at the median fee how people are let's say over beating each other you don't need i think the complexity that currently exists um 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 i feel that yeah oracles in under 1559 they really don't serve the the same purpose as they used to and my point about the records was more that these legacy users who maybe use outdated software um 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 um but otherwise i think oracle should either be yeah sunset or or very much like we thought from from scratch into the 1559 environment just to be clear we're talking about off-chain uh apis not unchained 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 five ten blocks and make the estimation itself i feel that might be good enough for one five five nine and you wouldn't need all the machinery that exists in the current of chain oracles that we have today okay thanks for those that overview um samuel i'll try to find a link for you uh to i think barnaby has done some research where he has a big body of work on this stuff yeah i'm looking through barnabas notebooks repo right now but there's like 20 of them so uh yeah if 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 um i just have no idea which notebook that is i can share the link yeah yeah or something yeah i guess right now transactions they have very wide range even within blocks and so oracles they they quote like the slow versus medium versus fast there can be like a very large variance between the three different levels and i don't think we'll see that in one five five nine 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 records start converging to to a good enough value um yeah i'll share the link in the in the chat um 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 cool one thing i was i was wondering is uh it feels like uh pretty much everyone is on the same page that from now on uh most of the estimation side will be on the on the wallet side right uh just looking at the latest vlog uh i feel like uh that's kind of okay but at the same time it will be cool if uh any api like etherscan or whatever could provide that estimation as an api i do because uh polling blocks is fine but at the same time is uh maybe a bit uh 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 polling constantly to know something versus like just uh fetching one api call to to an api and just get the number of what you will pay right now um i don't know just bring it up could be useful for the apps too so i don't know um something that we have it will be good to have around and i imagine it would be good if all these apis follow the same standard yes okay and sorry i'm circling back to what bernabeu was mentioning about oracles i understand that all the discussion about gas price circles for 1559 is around the minor tip but does it make sense to also have an oracle for base fee to know if the current base fee is extraordinarily high or something that uh that will vary on i think yeah that would also be pretty simple to build right because you just need to look at the gas used right if you know more than n blocks are full right basically the amount of completely four blocks tells you how high the gas key is on like an exponential scale so it's like if you see you know one full block it's probably not worth it two is like pretty high and you know like five is like extremely high so um yeah i i don't know that there's oracles right there but like again it would be pretty straightforward to implement uh given that uh yeah you just need to look at the gas used 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 there's 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 yeah and so the challenge there is obviously you don't know how sustained that demand will be right like you it you can't you know if you've seen like five full blocks uh you know it's hard to estimate whether or not you'll see five more full blocks or not um but at 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 um 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 uh until this this clears yeah 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 um i guess yeah okay so the first stuff was the json rpc changes um so basically uh i i'll share the json rpc spec in the chat just to make sure everybody has it um but we've added the changes to json rpc there um in short you know it adds the base sheet to the block header and it adds the maxi and max priority fee to the transaction object uh if the transaction is type 2 so like a 1559 style transaction um so that should and that's basically the api that the different clients will implement i think geth has the different version of this and they have an open pr to implement uh to implement something in accordance with the spec but that's kind of uh yeah what all the clients will will implement in the next couple weeks um i don't know if there was any questions or comments on that um recommended minimum priority fees so we touched on this quickly um again there i think the the case where there's not uh like a sudden spike in demand what you probably want is to just look at the ballpark you know average mev in the last seven days um follow barnabas graph that's linked in that and you can use that to kind of set the the default tip um so right now you know with the values that were seeing we would be around like 1.5 way for gas um again i mentioned earlier flashbots is you know doing some optimization work to include more bundles so i suspect by the time 59 goes live like two way for gas as a default tip probably makes sense to get your transaction included you know and like the like said you know 75 percent of blocks unless it's like extremely high med so just as a default option to gui as of today is is probably the right amount um i'll just run through it if people have questions just please interrupt me transaction replacement so okay so this is something um again get has an open pr for um but the one challenge with 1559 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 basi and and the tip they don't actually pay their entire fee cap um so because of that uh 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 it's cost less for them to do that whereas today if you if you raise your gas price on every transaction obviously you're paying that highest price um so in order to avoid that i believe uh what jeff and other clients are going to go with is you need to raise both the fee cap and the tip by i think 10 for it to be rebroadcasted um so it'll be worth just like looking at like the get release notes for that um but roughly if you're if you're resubmitting your transaction with a higher fee uh you want to increase both values not just the fee gap um yeah i've got a question in regards to that is this going to be part of the ad protocol or a client because people could just jailbreak their clients to take that out and still attack them yes just part of the clients so like sure you can you can uh you know jailbreak your client to submit the transaction but then nobody um i guess the clock other nodes will not replace the transactions in their transaction pool if they see that it hasn't been raised enough right um so 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 tenfold thank you of course um and then we had london rollout um yeah we touched on this earlier i just added it um so we don't need to necessarily go over it again but like definitely these um [Music] 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 necess they don't always care about the advanced um 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 um yeah this is i mean i don't need to tell people this but it's like i'm sure you're already thinking of how to communicate this to your users yeah 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 uh the 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 and then you just switch it on if you wanted to actually base it on network condition um one you know there's a couple metrics you can look at the first is just the gas used in the block so when we start seeing the gas used um actually represent like 50 percent of the gas limit so right now you know the gas limit is 50 million um 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 the gas used being like around 50 million rather than 30 million that's telling you that like we've basically processed all of the transactions you know for a certain base fee that basically is not like a good gauge of demand on the network um 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 bases where like the parent space fee is like you know pretty close to the current base fee so you know whether that's like five percent roughly it's telling you that like the blocks are pretty stable um and um 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 it increases by twelve and a half percent every block um so when i did the math it was i assumed like a 250 way which is obviously higher than the gas price today um and i gave 50 blocks but you know you can just look at the blocks whenever your release is closed um and you know if 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 say you know like 50 blocks since the fork and you know you want the gas used to be between those two ranges before you flip on like the 1559 ui um and i guess what's nice is like all those parameters are just in the block header so like you don't need you don't need to like actually look through like the full block to determine this um so it should be fairly straightforward to 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 i mean while we're here you might as well just say the last one oh oh sorry yeah so erc editors um okay so uh this is not necessarily related to 59 but kind of a quick pitch um we are going to be spilling the eip repo between eips and ercs um because there's just like such a different skill set from folks working on you know core eips and folks working on the the interface level um if you are interested in helping to be like a potential erc editor um please reach out to trent or me after the call and and uh we can chat about that but basically it would help you know maintain the the repo make sure that there's like a good process for people to add new standards and whatnot um light client is on the call he's like a uh eip editor so he can maybe also give some context on on what it's like um but yeah it's something we're looking for and i think we're like the application layer can 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 cool the other thing which is now slipping my mind oh so there was this big conversation on the agenda about like detecting that the network supports 1559 um realistically i think the only way to do that uh for for now and and likely for the next few months will be uh 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 um 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 know etherscan is here and eat 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 um so maybe just after this i'll reach out to those those teams and see if we need to organize something yeah that'd be great yeah and then we can just get back to open discussion if people have any questions or comments i just want to just um it's pretty hard to hear you brandon maybe type it in the chat or if anybody heard that um please translate anybody else any type of question go ahead yeah uh two things basically um the one thing was um checking um the block feels a bit brittle to to find out if um erp 1559 is supported is the question is is the train for for london already um left the station or could there be like a simple eip in there basically so it's already done there is no core eip that will be added to london and it could be quite a simple one right so um just return basically if eip150r in eip and then install start and then optional and block 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 it wouldn't be consensus change right it would just be an rpc um command extra so then the rpc basically so i guess we command basically that returns um an eip and an optional star uh and start an optional end number so like you retur you call like does this chain support 1559 and it tells you yes or no yeah it would make it more more general basically not just uh 559 but basically we will have the same problems in the future basically yeah so the challenge yeah the the challenge with eip base so the 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 the having that concept has led to bugs before if you can say you know i want eip x y and z um the 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 um and the the challenge with that then is like say ethereum classic ads 1559 their hard fork is not going to be called london and um they're even if if they you know their heart work 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 uh or sorry every refund but for fork like from the forks just really from the eips which eips are supported from which block so you would say that 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 right um and like you could probably create a mapping from that uh but i 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 29 30. 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 faults 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 and and so i don't think it's possible for for london yeah all right and the other thing uh was um when implementing one five five nine as like access list is currently uh 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 um and currently like access is basically on the end and that makes it that you need basically um it's it's more different 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 that it's not impacted so like does that impact how the transaction is if it impacts how the transaction is encoded then the answer is yes yeah it impacts uh all the transactions they call it there yeah i i don't think we can do any consensus changes now for london yeah all right thank you for the info yeah um 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 if you know if you have a mic the the only way that i implemented it was i i look at the last base fee for the block and i said you know just a pretty naive uh fee cap for the transaction is two times the last base fee and that can be configurable with a flag to your guest client and then for the tip i'm just looking at what are the tips in the last block and i look and i try and calculate what sort of the average uh the median tip is in that set and then i return that so you'll have a very high chance of being 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 right now i have the end point returning two 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 15 59 it will return the estimated tip and feed cap okay so for geth then eath gas price specifically is a breaking change um yeah if you're relying on gas price it would be breaking yeah okay so every any wallet that currently uses uh that rpc call and still sends legacy transactions uh will start sending with the wrong as price because that endpoint will return the data for 15.

59 yeah that's why i'm asking yeah so i mean should we have two end points for uh have we done i don't think we've done that with any other jason rpc endpoints to have a 1559 specific i personally like if we're gonna maintain legacy transactions we should probably maintain the legacy endpoint for them um this is like for i we've had a lot of issues at chainsafe because of uh gpo like miscalculations and stuff do you do the sampling especially due to mev and i think like we should probably just not with that yeah but yeah if you if you want to keep the same main point then you you're gonna have like a parameter that you know at least you requested the new way and by default stay the way it is if it makes things easier i'm open to whatever uh you know consumers of the jason rpc would like to do i don't have a strong opinion um personally i'd just like it to be in before because right now like london or not london berlin like didn't have the access list endpoint ready um so it'd be nice to have this like ready well before we go okay 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 but what what correlation does the access list have on the uh ux and the gases 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 no worries thanks so basically just to summarize we add an optional parameter in each gas price which specifies that you actually want the 1559 uh style transaction the 1559 style estimation and if you don't have that parameter you just return the current uh behavior sounds good to me yeah it's a little bit messy to start kind of making breaking changes through parameters but the alternative yeah i mean but it's backwards compatible which is nice um and also gives flexibility to to like you guys because you can have you can do some sort of flag configuration beforehand to 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 yeah that's right in terms of having a parameter versus another function name like we're 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 i'm easy but i know uh there's a discussion kind of around this with tim on an issue um oh wait no that was something totally different yeah so we only have one minute left and i just want to like hit a few things really quick before we wrap first thank you everybody for coming out uh whether it's early or late for you um really appreciate it we've got a ton of people um a ton of different wallet teams around the world so again thanks for coming and trying to resolve this stuff synchronously um then a few other things so this wallet cheat sheet we've mentioned it a bunch of times this is where we're trying to gather resources aimed at people like you who are working on the 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 the r d discord is where a lot of this discussion is being hashed out so if you haven't joined there already please join um i'll grab a link and put it there unless tim has already done it and i would we'd really appreciate if people could engage their two 15 59 channels um 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 um tentative timelines for when this is yeah sure uh so we're gonna actually confirm this on all court ev's friday but assume like you know this is the most aggressive timeline so probably what you should plan for so we suspect the first test net will fork on june 9th um so that'll be roxton then we would fork gordy a week after that so june 16th and then we would fork rinkavi a week after that june 23rd um assume all that goes well and you know we don't like find a big consensus issue we're tentatively planning 1559 for july 14th on mainnet but we want to see the first test net go well before we actually initiate before we actually set a block number for for mainnet um and yeah i it's not 100 sure that clients will be ready for the june 9th dates so it might slip like a week or two um this is what we're going to be discussing friday but uh you know if you want to be ready for like the most uh yeah aggressive timeline then uh being ready for june 9th um should be the the goal um and most you know i think most client teams have mentioned to me they should have a release with 1559 ready and whatnot uh by by next week uh so uh like a week before the test net fork and then uh we'll have the main net releases probably closer to like a month before the the main network yeah and that's it thanks again for everybody coming uh we did record this so we'll upload it somewhere and then send out an email uh with sort of outcomes and links for next steps thanks everybody thank you