EIP Editing Office Hour #93 (EIP Only)

EIP Editing Office Hours · 17 Mar 2026 · 35:28

Meeting 93 of the EIP Editing Office Hour, held on 17 March 2026 and limited to core EIPs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process.

Topics

From EIP Editing Office Hours, hosted by ECH Institute.

Transcript

[music] >> In progress.

Welcome to EIP editing office hour. Meeting number 93. This has been added on ethereum/pmgethrepo repository on agenda number 1972. On agenda, we have a few last calls, miscellaneous, and draft. Uh we are joined by some authors. So, if you would like, maybe we can get it started with the uh the proposal that author is requesting. I I suppose the PR number is 11373, the first one in the draft section, and we are joined by Tom.

Hello, everyone. Great to be here. So, that's the PR number 11373. The EIP is uh 8182, but it's not It's unambiguous. Mhm. Do you have a link? Yes. Yeah, opening it up. Roger, right?

That's the right one, yes. So, yeah, I mhm So, I think uh you have addressed the comments that I mentioned. Uh the things looked fine to me. Great. I think I Yeah, I think I resolved both of those. For the uh contract, I put it to do, and then for um or TBD or whatever, and then for all the TBDs, I put the HTML comments in indicating uh where they are. So, as you know, this is mostly editing review, and uh without going into the technical merits of the EIP, which we believe

uh other people will review and uh sort of hash it out with you, including the contract that will go for it. This looks fine to me, so I'll just approve it. Great. Great. I mean, you know, while we're in here, and just in general, I know this isn't about the technical uh content, but if you have any thoughts, uh that would certainly be like super helpful and and useful, even if they're not like official or fully, you know, vague, just always looking for input. Uh so, are you looking for technical input or the input regarding how this like EIP is Yeah, like, you know, is it a good idea?

Do you like it? Do you think it's got, you know, what any technical feedback on how it Basically, any any reaction you you have is just, yeah, super super helpful and I mean, it's definitely helpful for uh canonical way to to to basically do cross-source private transfers. And but I I don't know what uh whether ethereum adopt it or not. That is something that is sort of, you know, you have to champion, and it is more political in that sense.

Yep. No, that definitely >> One thing is One thing that I would like to add is that I mean, it needs to be a bit more simple, so that you can champion it in an easier way. So, I think uh other things are mostly regarding uh the implementation, so Okay, cool. So, yeah, on that note, maybe I should ask for some advice to like, you know, my first EIP, and I felt torn in these two directions. One, as you mentioned, you got to keep it simple enough where someone can get excited about it and understand it, and at the same time, you know, it's not even fully specified even now in terms of having everything that a uh an EIP should have.

It has all these TBDs in it, so it's like these two pulls. So, what I was thinking, I don't know what most people do here, but I was thinking maybe the the thing that's really the proposal would be some kind of accompanying article or even like a website, and then the EIP would try to be as comprehensive as possible versus trying to uh make the EIP less comprehensive, which then, you know, makes it harder to imagine how you might, you know, implement it or what the details are. So, you know, is that you know, cuz of course the political side and getting people to be excited is, you know, just as important, more important as the technical. So, I just want, you know, is that what people do, or, you know, what what what do you think is is effective? What have you seen that's been effective?

So, I think uh it is good that the EIP should be concise, and uh still should explain the questions that can come up uh to a developer, right? A person who understands the protocol. Uh so, in that sense, I think it seems fine because you seems to You seem to have pushed uh the contract specification to a different section. And other things look concise to me. one of the other things is that, you know, regarding the idea how how you can uh how you can convince other members of ethereum community regarding this.

uh for that, I mean, for that, what really matters is that abstract and motivation, and that seems pretty clear to me. Another question would be, I mean, which I I don't think you have addressed over here, which you can add uh as a follow-up PRs, is uh how how does this particular thing compare with regard to other solutions? [music] And second would be uh why did you choose this particular technical parameters that you have chosen, right? So, if you explain that, I think uh that is what most of the developers who are interested in it, and then they start looking your EIP in detail,

would What would want to know that, okay, you know, how does it compare with regard to other ideas that are out there, and why you have chosen some particular set of parameters. So, this is something that you can add as a follow-up PRs, and you would need it You wouldn't need any EIP editing approval for it. That would That would automatically get merged. So, in that sense, yeah. Maybe should ask for like And so, sorry, not to take too much time. So, last question, just so like play that back and understand it. So, uh got to make the abstract and motivation sections as strong as possible. That would make sense. I'm I'll take another pass at that. Uh you mentioned like, okay, putting this in context, how does it compare to other solutions? I think this is super

important, and I tried to do a lot of research on this, uh basically to position it well, so that we're not too similar or too different or whatever. And so, is that something that goes in the EIP? Like, it's almost kind of like market research really about like, here's the taxonomy, here's what other people are doing. Uh does that have a place in the EIP, or is that kind of a companion article or something? So, you have rational section for it, where you can add this thing. Okay, so rational would be how does it compare to other stuff that's relevant, and then also this why do we choose the parameters and to do it this way. So, basically, abstract, motivation, and and and rational, try to get this uh in there is is what you're saying. It always confused me, why is rational so down below everything else? It seems

like that should be about But, you got to say the spec first and everything. Anyway, super uh super helpful, definitely curious if you have any more thoughts, but don't want to take too much time, and thank you for for merging it. And then yeah, actually last one quick question, you mentioned if I want to do a PR for an update to the EIP, I just make that PR, and it will get like fast-tracked to being merged or something or is there is there any protocol for that I should be like aware of? Yes, so it will get auto merged if it passes all the checks unless you're changing the status of the EIP, which is something then again uh EIP editing approval required with it.

But uh just to, you know, further develop your EIP in draft stage, uh you can just uh make the changes, have discussions with other members of the community how to make it better, and a lot of things for example, you know, how you will learn that how to word them or what what are things that people motivate people get motivated with, and what are issues that you need to address. You will basically come to know when you will pitch and champion the EIP, so I mean that is So it is sort of an iterative process.

You you can't just make it perfect and then say that okay, then I will go and champion it. So you can start championing it with when with the current draft, and uh then you would automatically understand that okay, these are the things that need addressing because people will point it out, and I hope that in discussions to link there are already discussions going on, so that is your valuable source of information about uh what you need to do with regard to championing this EIP. Awesome. And last question, that makes so last question, will it now automatically appear on the EIP's website in that format of like looking like an official EIP, or is there another stage for that?

So it will appear on the draft section now. Great. >> don't need to do anything. Okay, well, I'm good then. Thanks so much. Really appreciate it. So just one last piece of suggestion here because this is a standard track core proposal, you might want to see it an upgrade, and as you understand Ethereum works on like multi-upgrade processes. So you would want to consider for which upgrade you want to champion this proposal, and based on the timelines that you can find at forecast.org, you can add your draft proposal for discussion of client reviews. Unless that is selected for any particular upgrade, it would not

make sense to promote that status. You could still do changes, you could still enrich the proposal as much as you want. Got it. That makes total sense. And you know, again, I'm like so super new to this. Off the top of your head, no pressure, do you have any suggestion for which uh if this were to make it, which would it would I be a good one to to target? I guess probably not the next one. Maybe the one after or It could be Hegota or beyond. So Hegota would be the earliest. Yeah, Hegota and beyond because Amsterdam is almost finalized, so you cannot champion it for that.

So the best way to champion it would be to basically get in touch with a client developer, and EL client developer in this case, and then pitch your proposal, and see what they say, right? So this is [music] how I mean you can go, and then basically you can pitch it in a ACD once you have a lot of context and a lot of things that a lot of feedback incorporated from the people that you talked to. and basically then you can do it uh you can propose it for a hard fork, and those proposals are basically then evaluated uh in the ACD one by one, where they are

selected or deferred, or rejected. Uh so so you will have to basically a bit a bit a bit more involved with the ACD process. Awesome. Sounds great, and thank you uh for this link. I I'm shocked I didn't know about it. I maybe I did know about this, but yeah, this is a great this is a great page. We are here. Wow. In history. Cool. Thank you. Yep. You're welcome. So you can follow because uh it's non-headliner EIP proposal has not started yet. It would be started after March 12th, so you should be seeing it in upcoming ACD meetings. As you follow that, you would get the dates when you can actually propose the proposal.

Awesome. Well, thanks so much. Thank you for joining. Yeah, so this one is yeah, my proposal. I just wanted to promote it as the upgrade has already been finalized. Yeah, yeah, I got that, and I think this just needs a some time >> re-run. Uh the previous one, which is because it must be depending upon that.

Yes. Yes, that was the blocker. Yes. Maybe we can move on to the next one and get back to 8135 back again after some time. Yeah, you should be able to re-trigger it yourself, right? It generally does not work. So if it does not work, then maybe we'll have to check with Sam. Okay, I mean Or maybe you can close and open, yeah. Maybe you can close and open, and that might work.

Well, I mean even my Okay, did not restart this particular thing. No, it does not. All right, it seems to have triggered the workflow. Hopefully it should merge Okay. So next are some miscellaneous proposals. They are some content changes on the proposals and some other changes that might require editors review.

I mean this is not really an editor because this is my EIP, and uh this guy must have uh proposed technical changes into it. So yeah, I mean as an author, you can perhaps add comments there. I mean I moved this EIP into stagnant, so I don't know. I mean it's not a good idea to update the stagnant proposal unless they intend to revive, but yeah, because you're an author, it's your call.

This seems like Yeah, do we want to wait for other authors' approval in this one? Yeah, I mean this is anyway flagged to other authors. This is not even waiting for us. Unless your filter has labeled it wrong, it should not >> Yeah. Yeah, I think Yeah, I think it's a mistake. It is anyway author waiting for authors, not for editors. Yeah, we can go to the next one.

PR number 11048. So basically this requires two editors' approval here. Seems like something is changing in RSS. XML XML file. I have added at least we can get one editors, and we can bring it to the next editor. Or else if you prefer it to be moved to EIP EIP, I'm open to do that.

I mean the question is that if this is this the change that we want. I've kind of approved it and leaving to Sam. Yep. Okay. Uh the next one is also the same, RSS related. >> I mean

this is changing something more. This is basically changing the way things are rendered. Because seems like changing a last [music] call to no near zero. I'm not sure what impact this is. So Maybe we can skip this one. Because this is more than simple. You can still approve it and because by the time wouldn't wait for anyone else. Yeah, that makes sense.

With that way we will move on to the draft proposals. The first one is already reviewed so maybe we can move on the next one. The PR number is 9374. And this is also merged. Okay, yeah. The next 11303.

So I think I left some comments over there where the author has not uh addressed. So once [music] these are addressed then it can be merged. Very well. So the next one is 11330. Uh it's supposed the author has responded to comments and fixes that was requested earlier.

So I think I reviewed this and then I did not approve because I saw this particular comment by Sam and he has also basically requested changes. So I would basically let Sam take a call on this. I can just write the comment over here. Cool. And I will add it to the next office hour with just going to be by So the next one is by Greg. Um

this is like I I I guess this is the third office hour in which we have added this. Uh from the previous office hours editors has concerns that whether this should be added as a as an EIP or not. Um Yeah. So I saw that uh Sam mentioned that this could be taken as informational EIP for design issues. Something like that. Yeah. Um I mean we didn't get any clear yes or no. He says that as per template it

looks good but not very sure whether it should be part of Ethereum EIP. After that uh Greg has made some changes. I'm not sure if after those changes it should be good enough to be merged as draft, yeah. So Sam, I mean it could make sense as an informational EIP that basically design that explain the design. Uh but yes, I would sort of agree with Sam that uh historical context doesn't need to be there. They just need to understand what is the current design.

Yeah, I mean this section doesn't need to be there. Historical context. Yeah. I mean it's it's difficult to have

to have this something something like this as an EIP in the sense that design changes all the time, right? So Mhm. So who will basically update this? Will this become a living EIP or will this become [music] a final EIP? if this has to become a final EIP then it should uh it should mention that it should anchor itself into some hard fork, right? So it should say that at this particular hard fork is what this informational EIP is talking about.

>> could add that also. Yeah, we we need more consensus from editors team on that part. >> Next we have the proposal for lucid. I

guess it is still waiting to be merged. So yeah, we are waiting for the author to provide a discussion to link. Which is why you can see this red flag over here. Which has already been flagged.

>> [laughter] >> Okay, I will inform the author here. Okay, cool. That makes sense. All right, I think that's pretty much it for today's meeting. I'm looking at the PR 11417. I don't know why it is still not [music] merged, still running. But hopefully it will be merged after that. But other than that, I think we are good for today. We are trying to make [music] the PRs as relevant as possible, although I found two errors today itself.

But I think we are good for today. Thank you so much. Yeah, sounds good. Thank you so much Gajendra for joining us here today, and people listening or watching this call. [music] We'll be back with the EIP plus ERC reviews in the next editing office hour on Tuesday at 1600 [music] UTC. See you all. Bye-bye. >> [music]