EIP Editing Office Hour #67 (EIP + ERC)

EIP Editing Office Hours · 29 Jul 2025 · 1:00:54

Meeting 67 of the EIP Editing Office Hour, held on 29 July 2025 and covering both EIPs and ERCs. EIP editors and proposal authors work through open pull requests and questions about the Ethereum standards process. This meeting covers ERCs heading to Last Call and Review, and EIPs and ERCs heading to Draft.

Topics

From EIP Editing Office Hours, hosted by ECH Institute.

Transcript

[Music] on. [Music] Hold on. [Music] I feel you.

[Music] Heat. Heat. [Music] Heat. Heat. N. [Music] [Music]

Mhm. [Music] Heat. Heat. [Music] [Music]

Heat. Heat. [Music] Yeah. Cool. Um, welcome everyone to EIP editing office hour meeting 67. This is issue number 1633 on Ethereum/PM GitHub repository.

Today we are joined by ERC editor Victor Joe. But this uh session will include the review of both EIBs as well as ERC's for consideration. Maybe we can start with the first PR for which we have the author joined here. I'm going to share the link here in the chat and the number is PR number 1140. The proposer is Anushka Yadav. She's on the call.

So Wter um please feel free to share your screen and we can go ahead with it. Yeah. Uh, one second. I I'm somehow tried to connect my screen to a different screen. Can you see my screen now? >> Yes, it's perfect. >> It's in EIP editing office hour, right? >> That's correct. Yes. >> Okay, let me go ahead and then I think we're uh reviewing 1124, right? No, we are looking at 1 140. Uh because >> Oh, because author is here. 4 >> that is the first one on ERC draft.

>> This one, right? >> That's correct. Yep. >> Okay. Purposebound ERC20. Uh since the author is here, I' love to kind of uh get author to briefly introduce this um this what this new proposal. Um hi is author here. Uh hi uh so like we are trying to uh build uh like time bound something on ESC20.

So we have created that interface. >> Okay. So you mentioned time bound and then it's uh I think showing on the proposal is purposebound right. So probably you in addition to time bound >> you also also expanded the uh the goal >> um to other things. >> Yeah. Yeah, a little bit more of an introduction about this proposal like it the key design, the key choice that you made, the key choice that you try to avoid basically like you decided not to put in is always something I've been I

look forward [Music] Uh, can you hear me? If you're speaking, uh, I I think we couldn't hear you, so maybe you need to unmute or check your audio input. >> Uh, yeah. Um Pu Puja can you hear them?

>> Yes we can hear you uh better very well. Anushka we are curious if you have any particular question for this proposal or you just want the be reviewed and get the number. >> Yes. Yes. I want that uh should be get reviewed. No questions as such. >> Thank you. Yeah, I was asking you to kind of give introduction about this this EIP maybe verbally um since you are here, right? Otherwise, you could have just sent it over through a link and then we'll begin reviewing it. So I was wondering if you can kind of introduce the design uh and then specifically it's interesting that what you choose not to do in in this design like we are also here to uh know the

process like what will happen after this uh review. So that's the reason we have joined. Actually >> I have a hard time hearing you. Okay. I if you if you won't be able to give a lot of introduction, I can go and start reviewing it. Um just the first thing I would look into is whether there are existing uh EIP or ERC's that's addressing the similar problem and whether you attempted to research and then um and then see if you want to reuse adopt them or if you have any um new proposal that's uh that's

different and then cannot be addressed by existing one. I think timebased is an like timebased locking is a uh common situation uh and we already have a few ERC's I think that is so if you have you done a research on these on on other ERC that's um addressing similar issues. Uh yes for time bound widget there are a few but for purposebased so we haven't found anything so >> so what is the difference between purposebound versus other ones

>> uh can you hear me? Yeah, I'm not sure if um uh oh, I think it is like co-authored by multiple authors. So, I'm not sure like if uh this individual may have all the responses. So, perhaps we can give it a look and if it fulfills all the primary criteria, may be able to provide them the number so they can iterate and we'll come back on when the proposal tries to move to the review section. >> Sounds good. Okay, I think I'll leave a comment on this one about um for a draft uh please uh research into existing ERC's that are relevant relevant uh and

solving uh similar problems identify them and see if you can if there is a chance to reuse existing one or if not uh in the uh state uh why this is a new approach, new problem or or new approach that um needs a new standard. How's that? Is is I I would usually leave it this way um as as my review.

Um, but if you can answer on the spot, that's easier because I've not seen uh significant research into prior YC's. Yeah, that that sounds good to me. I wonder if we would be in a position to assign any number like if this proposal doesn't seem to be a duplicate proposal, we could perhaps provide them a number even if it is not marshed so they can keep on working. Um, I would be a little bit uh cautious about assigning um a a number while it's an unfinished draft. So, >> hey Victor. Hello.

>> Am I audible? >> Yeah. But I love to to hear I love to hear uh >> so the response I'm I I I'm also one of the co-authors in the same uh ERC. So basically we wanted to know as Anushka told we just wanted to know the process right now and whether you assign the number or not that that's not a problem for our side like how it went from here to next steps and uh we'll be considering to iterate over.

>> Yeah. Yeah. Once you get the draft finished and then we will assign a number and then we will adopt it as a draft and we will uh include them in as a draft and publish it onto uh onto the uh our general uh output um um outlet uh like um your EIP.ethereum.org. Uh and then from there you will continue to uh attract people for review feedback and adoption until uh you feel like it's good enough to begin reviewing it as a like proposed standard and so that you at that time you move uh the status from review from draft to review continue to collect more feedback. Uh and once you

feel that's ready, usually usually a few weeks, uh you move you you filed a uh a pull request to move it to to last call. Give it another month and then uh we'll finalize it basically. >> Okay. Uh just to answer your uh starting question uh there were no duplicate around this and as Anushka told like there were some time bound things but there were none around the proposal bound things. So basically proposals are something like where uh you are given a you know uh something like a receipt or something and that will be you know diluted within some time. So that is something we are after. So we'll be

iterating over it and let you know. Yeah, I think it's more about researching into prior other ERC's and EIPs about what solutions has been has been done and then why this needs a new one just because it's a purpose uh is less convincing that it's it needs a new uh new new ERC's right like what does what specific uh approach this um could not be uh uh what what specific uh use cases would be a good one that only can use this ERC but not the time bound or uh additional other bounds. I think that's the that's the question. Yeah.

And the fact that uh that these uh research is limited here is making it a little bit hard for other people. the the whole whole purpose of having ERC requests for comments is that people will come together and try to adopt and move the entire ecosystem and and smart contract specifically forward like by everyone adopting standards and the purpose not always to create new standards. If there if something existing works uh new standards is not necessary uh and it can can definitely can sometimes be be harmful actually. So uh always research into what's available

and see if you can uh adopt the existing one and if not then it's I think the motivation is a clear state that that these existing relevant uh EIP ERC's are uh like restricting or limiting or doesn't address this problem uh that we're solving here and uh that's why we're proposing a new standard because the next step is getting people to adopt them and then when you ask people to adopt they will have a fair check of all other ERC's whether they're available or not and decide whether they will use them or not.

>> Understood. >> Yeah. >> Thank you Victor for your time. Uh we'll iterate over it and let you know in the com comments as well. >> Yeah, appreciate that. Yeah, >> thank you Victor. Thank you Pa. Cool. So when you finish up uh adding the comment here, maybe we can take up the next um PR here which is 1124 to move the proposal to the last call.

>> Okay, let me check. I'm sharing the link here in the chat for reference. >> Oh, okay. Uh let me share 7 913 right >> that's correct.

>> Yep. interface for verifying signatures by addressless keys. >> Um we don't have the author on the call. Um we can perhaps take a look for the changes and uh whether it is ready or not to move into the last call. I see Mercy has a hand up. Mercy, you want to add or share something here? Yeah, I wanted to add something. Um, in terms of adoption, just for >> Are you talking So, one second. Are you talking about this uh ERC 7913 or are you uh talking about something uh new?

>> No, something different. I'm trying to reference back to the previous um um ERC we just um reviewed. >> Oh. Oh, yeah. Sure. Yeah. So adoption is not required for draft. >> Adoption is not required for draft. Yeah. But uh the my uh feedback is to research it to >> I'm I'm trying to I'm trying to I'm I'm trying to um pass on a message if he's looking I'm trying to say if he's looking for um people yeah wallet devs to look into the hisces or other authors to other authors of if they're looking for people's opinion and also to get

more um what will I a in-depth technical review on ERC's he can actually go to the wallet um discord Ethereum wallets discord I think is being handled by Sam Wilson that's like a good place to >> props from that's a good place to get feedback >> y >> that's what I wanted to point out >> right good point I I I I think that's a very good suggestions for the previous one. Thanks for thanks for mentioning that Mercy.

Yeah. So, uh for the author group of the previous ERC, the goal is to get a uh to to have people work together. Like ERC is a way to get people to work together. So, um research in what's before you. uh and then you will also expect other people will research when they try to propose something after you and then they should also look at whether your your ERC already solved their problem. Uh mercy support suggested um is a good one. Uh the wallet um work uh work group is definitely something you can try to go and ask. Uh you should also ask other channels. This is a decentralized collaboration. So um many other venues

you can go and ask for feedback. >> Okay. Victor. >> Yeah. And specifically EIP and ERC editing is less about technical feedback like we actually don't give you like whether this standard uh is good or not whether like whether we should add this particular field or function or not like we're not in in a position of giving you this feedback here on this call or when we wear the editor hat. The editor ensures the process take into consideration of uh what needs to be in the ERC content, right? Like whether you

do research, whether you clearly define the interface and specification, whether you think about risk, like we want to make sure items and uh each um each of the content sections um have the content they they need to be in. And then we move the status once we see the consensus in the community. That's basically what we do. Uh when we give you uh technical feedback like hey maybe this could benefit from one uh additional field or one additional parameter. Maybe you should rename it it in a different way. These are optional.

These are not editorial. Editorial would block you from moving status but optional technical feedbacks are we are just peer giving you peer feedback. And usually I personally give it on uh ethereum magicians.org forum uh because um technical feedback happened there and you were the driver and champion uh to to make the tech technical decision. >> Understood. That's a great advice. >> Yeah. >> Okay.

>> Uh >> cool. Um, so if is is there any questions about the previous ERC which is unnamed? A way to name your ERC is that one when you don't have a number yet, you can give it a short one or two word describing what it is. For example, purpose-based ERC20 like you can give it that that name like as a placeholder. >> Yes. >> Yeah. >> Understood. Uh we'll keep that in mind and thanks for the discord link as well. >> Yeah, we'll check also.

>> Okay, man. Thanks. >> Yep. [Music] >> Uh okay. If no other question for the previous ERC, uh here is the new ERC I have chat. Uh and then also the discussion shows that uh people were implementing adoptions um and then um in open zap usually means that they also get good reputation and uh be adopted by additional other casma contract developers and and and and users.

So uh I think this is ready to go for the last call. The only thing is that the last call deadline probably needs to be another uh week or another four weeks. >> Yeah, >> two weeks. Yeah, 14 days more. >> Yeah, 14 days update to 14 days from now probably. So, I think it's August like something like 12 or 13. Yeah. Right. Yeah.

And other than that, um >> 12th of August. Yes. >> Yeah. Other than that should look good if this is the last call. >> Yeah. Should be good. Cool. The next one that we would like to review here is PR number 1125. And we are joined by the author here, Dario. Yeah.

>> Hi, Dario. >> Hey Tim. >> Uh 1125. Okay, you already put the link here and let me share. So 7943, right? Moves to review. >> Yeah, >> it's already got a lot of traction in the the magician. So I I guess it's time to to move to review already.

>> Nice. Okay, this is the part when I need to give a more detailed look. [Music] Universal RWA interface.

>> Yeah. >> Okay. Wait a minute. Does it? >> Uhoh. I don't know if this needs to be updated or not. It just got approved. >> Yeah. Um, >> I think the bot shouldn't shouldn't approve it right away. And so, uh, Pora, can you do us a favor to kind of ask Sam whether we should apply this date here because it got merged already?

>> Uh, I suppose the uh the reason why it got merged is because there is no change suggested. In case of any suggested change, they would have uh like waited for the new date to come. >> Okay. I thought I gave suggested change. I I that was the my understanding too and then I thought that I I get suggested >> big change. Okay. Yeah. >> Yeah. And then Yeah. So maybe the the bot h works a different way today. Uh >> yeah probably what I what I saw from there is that you you left the comment but you also approve it.

>> Approved it. Yeah. >> Yeah. >> Supposedly approve it will wait for the uh the but that's fine. Yeah. I think it used to work that way that you can approve and then there was suggested change and then once of everything is addressed it's go through >> but yeah >> yeah unless we have any specific reason to maybe like withhold that proposal uh we can perhaps let it go and let's wait for the author to come back to make the proposal to move into final. >> Yeah. Yeah, that sounds good. We can block on the final side to make sure it waits for 14 14 days.

Okay. I noticed William >> Okay. >> is trying to mention something here. William, if you would like to chime in. >> Yeah. I just wanted to ask, I understand that you've got a good uh magician's thread. >> Frozen. >> Sorry, >> we can hear him. >> Yeah, you can hear me. Okay, fine. Uh I understand they've got a good they've got a good magician's conversation going. I am seeing that there is a another uh that there's another RWA proposal which apparently is >> I I think they're breaking up.

>> I'm breaking up. >> No, he's William is sounding fine for all of us. Victor maybe. >> Oh, so maybe that's me. So maybe you you can you repeat it for just for me. I'm sorry I for for a minute for a minute you were like on and off on and off. >> Oh, sure. Um, I was just saying that I there does seem to be another RWA proposal except now that I'm looking at it, it looks like it is still in draft as opposed to review. I hadn't realized the site puts uh also scripts the drafts these days, but I mean naturally kind of my first thought is how how many do we need? Um, it could be that there's significant difference, but I'm curious.

Are you aware of the of other standards that are implementing this like are trying to implement an RVA interface? >> So, here here's the thing. A lot of people come here with let's say a very generic word that's sometimes even over overloaded, overused in media and uh we're a technical community. So, um when people say RWA, they meant a lot of things. So a technical proposal usually give it a name that like describe the technicality of this proposal and then they can mention these media words in let's say the motivation for example um a real problem is that sometimes asset

needs to be froze frozen right so there would be for example an interface says like we should agreed on what what is considered they're frozen or not, right? How do people get notified for frozen uh activities? So, I think the the title could change uh in more generic because RWA is going to have a lot of behaviors that we need to kind of think, right? So, that's the first thing uh I maybe consider re retitle it is my feedback uh to more specific like technalities uh which is I think like uh description side is good.

Um now the thing is that for example for frozen you will find people use lock and then there's already ERC for lock maybe I don't know if you touch expiration but if you touch expiration there will be ERC that has expirations so you should come up uh with a strategy uh to consider adopting theirs and then maybe add upon them or says that this needs to be changed and uh because for example we believe you should order the user first instead of the token ID first etc.

Now one thing is that this adopt for 1155 right what if people want to do hierarchical um if you use a generic terms of RWA this is going to solve one thing for all for our RWA so I'm going to tell you okay this doesn't solve our RWA and so maybe you should consider let's change it >> requires 165 I think you should you should be able to use it agnostically now uh >> what so say it Yeah. >> Um, it only requires 165. It looks like it's it's token token standard agnostic.

>> Oh, >> yeah. This Yeah, this is >> you're talking about the interface the the the supports >> the 165 itself because he has to give an example, but if you look at the abstract and the the initial metadata, so it only requires 165. That's it's I mean, he states in the abstract that's agnostic. >> No, no. I think we're talking in a different problem. My problem is uh my question for you is that have you seen that you asked me if there's other relevant uh ERC's that that we know that that may be relevant to to this one, right?

Um I was my my primary my primary question there was directed at the author if if there's a possibility to fold this into uh other existing propositions proposals or >> yeah yeah whether you can use other expo proposals to to um to kind of use like let's say someone adopt another ERC that address lock or expiration or or force transfer. I don't know like have you checked that I may have to look into it but I think there's some ERC that's doing lock or lock extension for

example lockables right for example let's say if someone adopt that would that um ERC would your ERC stops working like if people adopt yours they would not work with with that one or vice versa so that's the question you need to answer right I think >> I I suppose Dario and Mercy has a hands up. Dario, you want to add something over here? >> Uh yeah, sure. I uh from what I understand from the question is that there are many RWA standards out there being proposed. So prominent ones probably are the 36, 43 and uh 7518.

uh but it's mentioned in the in in in my IP uh proposal there is uh all in the motivation uh a justification of why this is apart from the already existing one and mainly it's because it it's it is compatible with main token standards not just one compared to others and there's also a section in the in the description about uh choices on naming to make it more compatible with already existing standards that overlap a uh but you can follow up on the Ethereum magician because there's an active discussions on how to make it the most compatible with other existing propositions without reinventing the wheel again.

>> Awesome. Yeah. Yeah. That's the that's the purpose like uh let's try to work together on the standards and then let's try try to not reinvent the wheel. So let me double check the review feedback. >> Okay. Um I have a random question. Is there like uh can we have something that bundles all these EIP ERC's rather together to help authors and then reviewers and people that are actually interested in the ERC process to >> quickly quickly differentiate between >> various ERC's that we that we already have so that we don't keep reinventing the wheel somehow because I've seen

cases where I think I had this discussion with SAM where there was two ERCs are literally more like they're the same in a way. So it's yeah a way to like streamline the process where we can it will be easier for the authors to skim through the years the already implemented or ERS are already maybe they are in progress of implementation so that they can like have a quick look because most of the time it won't be easy to tell an author to go through all the existing ERS. I think that would be a tedious work or I don't know if I'm making sense on this.

Yeah, I think if there's a way to bundle these ERC's that that that would be great and that was the purpose like if comes in and then uh start a new ERC's for the same problem and almost the same solution just different just different slightly different naming or different uh different strings of the function or parameters orders that's not only unproductive but also damaging because uh it's reduced the chance that people will use the same way, right? Assuming someone come in and with ERC20 and then another one someone come in as with ERC21 and one is transfer, one is send. Um they should work together like unless

there's a compelling reason to have another Yin21 addressing the same problem. Uh the um they should try to work together. That's the purpose. And then if they couldn't agree then the agreement the disagreement should be made very clear that's why they choose to have a separate ERC. So yeah this is a lot of uh discussion and let me see okay Javier and time dino is responding.

Okay. So at this point I would go and uh get a um get a chat GPT to summarize the opinions the people expressed on this let's see so that I can have a faster uh view uh minimum. Okay.

Can you see my screen? >> We can see the fellowship of Ethereum magician page. Yes. >> Okay, cool. I think the uh amount of people's response is good enough to call this as a uh as a review because the goal is to get people to start reviewing them and um whether you have actively updates.

Okay, two weeks ago. So this should be stable enough now, right? I will have some technical participation on this as well. But as an editor, I think this is good enough. I would encourage you to add more motivations uh in mentioning other efforts uh that you can potentially reuse or choose not to reuse because that makes your argument better. But uh for the moving to review, I think this is good. >> Yeah, thanks. That's that's the whole purpose. Yeah, I I I already gathered some feedback, but I want to have this in review so I can push for more engagement and more feedback from all over the ecosystem. But yeah, thanks for that, >> Victor. Unfortunately, we are seeing

just the blank screen. I don't know if you would like to reshare. >> Oh, thank you for reminding me. Mhm.

By the way, do you feel there's the need to to mention other ERC's in the EIP itself or or in the it magician alone? >> You can in so you can mention it in ETH magician in the main page. Ideally, we should add it to the to the con the the actual content of the ERC. Now the technality of this part is that um if you add something that's not like it a status uh later than you you will get blocked from moving to that status. For example, if someone else is having something in draft and you me you quote them here, it's going to block you from moving it to the next step, which I personally don't think it's a good idea,

but that's how our bot currently works. and and so um you should at least add them to the to the discussion and I've seen that you've add them to the discussion. So that's good. Consider like summarizing and updating your main uh first section because everyone is going to add to the first section. So you can always treat it as a source of place for source of truth of like the latest version and what's considered. >> All right, makes sense. >> Yeah, thank you for the great work. I think this is a great uh starting point for people to start realize okay RWA needs effort together um yeah and then need a standard.

>> Thank you for your feedback. >> Yeah, appreciate that and thanks for the contribution to the community. >> Very well. We have two more proposals for last call. Maybe we can begin with the PR number 1134 which is there to be moved to the last call. >> Yeah. And do we have authors to to this one or do we have other authors on this one that we should prioritize author being here? >> Um I we don't have author for this particular PR and I wonder if any new author who has just joined are waiting for their PR to be reviewed. Please feel free to drop it in the chat.

Yeah, if you are here in person and uh we will prioritize you because it's more productive to discuss with you while you are live. Okay, if no one yet uh let me go ahead and review the last call. Last call. >> I've shared the link in the chat. The PN number is 1134. >> Yeah. Okay. Let me share the screen. inheritance. Um, I'm not sure. I don't know if that needs a separate

uh ERC's, but it goes to last call. So, let me get Oh, okay. So, it's wheel. Okay. Handles. the inheritance of our token set. Okay, there. So, it's it it actually get entire wheel stuff. Yeah, that that dude needs a a um an ERC. So, let's see back compatibility test cases reference implementation.

Yeah, this probably needs to be in the quad. So, yeah. Let me check the reference.

implementation. This is a little bit weird. Let me see. [Music]

[Music] Okay, all these are not in the it seems not in the reference implementation. The reference is reference implementation was out of date if I understand it correctly. Would that matter if the reference implementation is out of date because we just need to share an implementation for reference?

I think reference limitation is part of the the uh part of the the the ERC. If you share the reference limitation like it's okay that your reference implementation is not right but the the interface that you share in the reference implementation uh contradicts your final uh version. So that needs to be updated. So if you if you can see this I think uh 7878 right okay sorry about that uh

maybe I saw the wrong one okay so this actually is the one so let me go and check yeah okay so that's this seems right because the previous one was weird. Yeah minor. That's okay. Yeah. Oh, it's so Yeah. [Music]

[Music] Yeah. Okay. Seems like uh

this is good. Let me go back to the last call and uh prove it. All righty. Congrats. Very well. >> Okay. What about the next one? >> So, we have one last one here for the last call review. The PR number is 1138. >> Let me go to my link. >> I shared it in the chat. Yeah. This is very relevant to the to the the

pre this one as well. [Music] [Music] I think this is no one is actually

reviewing it. [Music] This probably needs more review feedback. [Music] Yeah. To to to move to the net to the last call. Currently there is not very limited be back on match. Magi consider lacking reviews.

Please solicit more reviews. Ideally, adoptions or people willing to adopt. Yeah. Well, actually that's my Yeah. Yep. That's the response to this feedback this this uh uh ERC.

>> Very well. So, we have got one more proposal to be reviewed or to be moved to the reviewed um status. The PR number is 1095. >> 1095. >> Yeah. >> Okay. Okay. Draft to review. Okay.

Draft to review. [Music] That's when it's uh read data assets online digital products to NFT. Ensure their integrity through digital data asset and number. >> Victor, we can't see your screen here. >> Okay. [Music] Uh me present [Music] Yeah, I would they go and check for

other ERC's. There's definitely more ERC's addressing the same problem. >> Can you see my screen? >> Yes, we can. Very well. uh then perhaps we can drop our note and uh keep it for today. Um because we are approximately reaching time we may not be able to finish the next one. Please research into existing ERC's or um relevant topics and uh add to the motivation.

Yeah, >> that's my feedback. >> Thank you so much, Victor, for joining us here today. And for people who are watching this, we would come back with another editor's office hour next Tuesday at 1600 UTC. In the meantime, you can reach editors on EC Institute's Discord. The channel is EIP editor or maybe leave your PR for the next agenda and comment. Thank you everyone for joining us here today.

>> Thank you Puja. Thank you uh is uh Cat Herder. >> Thank you. Bye-bye. [Music] Oh yeah.

Heat. Heat. [Music] [Music] Hey, [Music]

hey hey. Heat. Heat. [Music] [Music]

Hold [Music] on. Hold on. Heat. Heat. [Music]