EIP Editing Office Hour #60 (EIP + ERC)

EIP Editing Office Hours · 13 May 2025 · 1:04:16

Meeting 60 of the EIP Editing Office Hour, held on 13 May 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 a batch of EIPs heading to Final, 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] Hey moving [Music] on. [Music] Heat. Heat.

[Music] are

you feeling? [Music] [Music] Hold

[Music] on. Hold on. [Music] [Music] Move

[Music] on. Hold on. [Music] Hello. and welcome to EIP editing office

hour meeting number 60. This is issue number 1540 on Ethereum/PM GitHub repository. We are joined by editor Sam Wilson here today to look into the open PRs on EIP as well as ERC GitHub repositories. We are also joined by some of the authors who may have questions. So starting with the first one, we have PR number 999 on ERC. Uh it is just uh there uh Sam, I'm not sure if it is there on the agenda, but we can perhaps begin with this one. Joined by the author. Yeah. Do you have any specific questions or just want to review?

would say uh to start a general review and then I do know uh later in the section I I had a couple questions regarding the uh optional uh reveal function and with uh the uh vents as well. Sure. See what's going on in here. Yeah. 7929. Oh, you haven't updated the file name. So, that would be one of the first things to to do.

Um, all right. Yeah, we we wanted to have the the history of the comments cuz if I change the the file name, I think the the history it'll keep them. Don't worry about that. Okay. Um, yeah. Um, and if you don't change the file name, it won't uh run the checks that it needs to run. So, uh, Got it. Yeah. All right. Okay.

So, start here. So, yeah. Okay. So, we could do something like this.

Um okay. Okay.

Okay, see you have that. Good. Um, yeah. So that comment still stands. Okay. So they stud tokens permanent gas bound tokens per specific token. Okay. So, let's grab

this and go here and And okay. Okay. Okay. Supposing multiple

assets. Yep. That's all good. Fragment value. All right. So just take the model. Okay, good. So ABT is the token interface specificity 827 or above. Color must handle false for trans success. Is this like um this is a note on implementers for

this, right? So this is saying or is this because none of these return? Yeah, I think that's a leftover when we had the the contract implementation together with the interface. Okay, so we should move that to the reference implementation section. Okay. Interface events. Okay. So these are bad. Okay. And do you have another

interface in here or is it just the one? Okay, it's just the ones. This is fine. Um, I should just go with events. Um, asset bound contract set event. displayed and bound to assetbound contract. the token ID is revealed that interface functions and I know uh specifically when it comes

to the uh functions and the events we spoke uh I think it was last meeting or the meeting prior um potentially leaving those out uh as you know mint isn't available um on other token standards I would my my thinking is we would retain those in there right now and have that optional because I do see that very useful um to other creators and as we uh go into draft and also the review stage and I start talking to more individuals outside of the scope that we've already spoken to and we would then make the decision to rather uh or retain that or then to remove that based on the general feedback that we receive if that's all right. Yeah, that makes sense.

Marvelous. It's completely up to you. That's just just a suggestion. Um, Friday.

Okay. Total supply get the total amount of the asset bound contract. Okay. Balance of NFTs that owner has function function may be implemented to allow pre-allocated tokens. Okay. Okay.

Yes. Data for the binding tokens contain the advantage manual. Okay. Cool. Alternative considered with option weight listing. Okay. Opture [Music] function. That seems good. Uh reference implementation. Cool. Good. Um Yeah. So, I'd say this actually looks

pretty good to merge. um you'll just need to adjust your uh file name and uh it will have some complaints the the the tooling will um but after that's all fixed it should be good to merge. Nice. Thank you. Perfect. So so just the title some of the adjustments and then we're good. Yeah. Okay. Perfect. Thank you so much. Oh my pleasure. The next one we are joined by author Solola and the PR number is 993 on ERC repo 993.

Okay. Yeah, I think you left some comments two weeks ago and I think I addressed most of them. Perfect. Yeah, just catching up on this. Okay. Yeah. Okay. Let's go take a look.

for month signature. Okay. For months for the others. Okay. And then next

Yeah. So, this seems great. No complaints for me. Um, I tried to vectorize the the the image. Um, for some reason it just couldn't make it into an SVG, so I just I just pulled it out. Oh, you can use PGs if you want. Like I I that's not a problem. It's just if you can provide an SVG, we we prefer it. Gotcha. Um yeah, so you can put them back, but um yeah, this is good for draft. Um do you have any questions about the process? You you know where you're going from here? Actually, I could use some help. Uh what do we do next? Sure.

Um sorry. Uh oh, Victor. Yeah. Um yeah, he left some really good comments. I'm really grateful. Yeah, he's uh he's pretty good on the ESC stuff. He's very useful. Um yeah. Okay, so uh process um it's mostly up to you. So uh during the draft stage, this is kind of like where you finish writing the proposal. If you have any like sections that you omitted or or thoughts that you're like are incomplete in the document, you you finish them at this stage. Um it looks like your proposal is pretty much done.

So you can open a pull request to move it to review whenever you're ready for other people to look at it. Um we don't really connect reviewers with authors. Um it's kind of on you to go out and find the people that would be using this um standard. So in this case it'd be wallets. Um actually we we have a we have a call coming up in a few days um all wallet devs. Um that's a good place to reach out to wallets. Um, if you'd like, I can put you on the agenda for that. Uh, would be DAB developers, um, talking to them, getting them to review it. Um, and once you're satisfied you've received enough review and you're happy with your your your specification,

you move it into last call. Um, that lets anybody know that, you know, you're ready to finalize and they have two weeks left to leave any comments. Then once those two weeks are passed, you open a pull request to move it into final. And, uh, then it's done. And that's the standard. Good. Sounds good. Yeah, if I could if you could put me on the agenda for for wallet disc. Yeah, sure. Gladly. Uh do you have um a Discord handle? Yeah, I'm in there. Uh I'll I'll need to find it. Um there. Thank you. Awesome. Yeah. Cool.

All right. Where are we off to next? Next, we are joined by Wamit and the PR number is 1031 on ERC repository. This should be very straightforward. La the last time we spoke you said when we're ready move it to review. Um because we're using it as cananan um I assume I can do that and that's all that's needed just to change that one file. Exactly. Yep. Let me just give it a quick read and we're good to go. Uh death. Yep.

Good. Must implement the bequathable interface 7818. Yep. Okay. Yeah, that looks great. Simple as that. That's it. And then um feel free to move it into last call when you're satisfied and then uh move it into final after

that. Thank you very much. Thank you. Take care. Byebye. Thanks. Bye. Well, we can move to the last call proposal here. Um, and we are also joined by a few learners here today. So, Sam, if there are any question, we will try to share it with you. Sure. Let's

see what's been going on here. Okay. Okay, cool. So, this did Yeah.

I probably should update the last call deadline too. So be the 27th. All right. 900 tokens support multiple. So let's put this in split. Okay. CC purposes a new standard for nonfgeible tokens that support multiple owners to do multiple owners reflecting the shared distributed major digital assets marshal in corporates mechanisms for provider to find transfer

of fees and ownership archiving flexible and collaborative ownership. Okay. Traditional fees enforces single ownership model which does not allow this includes provider fees and ownership and archiving enhances the utility flexibility digital assets and services. All right. So minting the function mint token allows creation of a new mo NFT. The caller becomes first the initial owner and provider of the token. Okay. New token ID is generated. The caller is added to the owner set and recorded as the provider. The balance of the caller is incremented. Um in terms of owners for each token world set duplicates allow efficient lookup. Uh the provider is the initial

uh owner who can set and update the transfer value fee under the provider can modify certain token parameters. Transfer. Okay. Owners can charge for the token to new owners using transfer from. The transfer adds the new owner to the list without removing existing owners and charges the transfer value fee to the provider. Okay. Okay. transfer the specified transfer value fee is provid provided. The contract must have sufficient balance. The contract must have sufficient balance. Okay, interesting. I guess it makes sense. Um, owners can mark themselves. Okay.

Sorry. Okay. Owners archive. They can no longer

transfer the token. When set the status can be reversed for digital asset platform can download the real asset directly. If it is not archive then it must be changed to archive first. Okay. Action set archive status token ID pool archived. Uh So this is technically a technical

comment and I should do it on the discussion thread but I'm lazy today. Do as I say not as I do. Um okay minting functions uh pelon [Music] okay transfer from safe transfer from. [Music] Um okay this is all fine. These should be headings. Um, this is kind of inconsistent.

Um, the ownership model inherited duplicate monthly owner model product distribution collaboration. Okay. archiving. Okay. [Music] Okay.

Okay. Sure. There's reference implementation. [Music] Okay, I need to see the rest of this. Okay, then there's all that that's being updated. Cool. So, this can move into last call.

There's just some formatting changes and a question, but otherwise, this is good to go. All right. Um, I need to step away for one moment. I'll be right back. All right. Sorry about that. Okay. So, I

guess we can move into these two reviews. Okay. So, what's going on here? We've got Okay. Proposing. Okay. But uh so none of the other suggestions I've made have been applied. So we're going to just leave this one for now. Uh 7858. Move to review.

Okay. Let's expand it all. Expiraable NFTTS and SPTS nonf fungeible and soulbound tokens with expiration supporting time limited use cases. Great. Uh introduces for ERC 721 nonfgeible tokens and soulbound tokens that adds an expiration mechanism allowing tokens to become invalid after a predefined period. This additional layer functionality ensures that the expiration mechanisms not interfere with current NFTs or SPS. Okay. Expiration can be defined using either block height or time stamp. Okay. Before the CIP NFTs and SPTs implemented expiration mechanisms for your custom mappings.

However, this approach present a challenge such as inconsistent integration with other smart contracts. The custom EFC 731 implementations might misbehave in NFT marketplaces. The IP addresses these by providing built-in expiration mechanism interfaces that are compatible with existing infrastructure. Cool. Yep, that's all good. So, we have an interface here [Music] 21. Okay, that all makes sense. Okay, so balance of that inherited from ER20. Uh, must return all tokens even if expired.

They still exist but are unusable. Okay, that makes sense for NFTs. Uh, transfer from and safe NFT sorry transfer from while transferring tokens even if they are expired. This is your main tradeable preserving compatibility with just applications expire must be considered. Okay, so this is like a a completely add-on thing. Uh that makes sense. Going to need the block of time. Yes, token expired is used for returning the status of the given token ID. The function must return true if the expired must revert if it does not exist. Um, okay. That's good.

Um, epoch. Okay. And so fine. We add get remaining duration before token expired. Get epoch balance. Get epoch info. Okay, this is all fine. Yeah, that's great. Absolutely no complaints for me. Cool.

We have a few more review. Okay. So generally show right the first line doesn't really explain why we need purpose for money. Okay. All right, let's see what's changed. Okay, good. So, we got that

right in the beginning. Typo fixes, some use cases. Good. Okay, that's different. Um, good. Okay. Stuff [Music] there. Okay. Let's give this a read then. Okay. Um personal money and extension program. Okay. Hey person money token is wraparound and 1155 token

that can be used for limited activity. This proposal launch smart contract interface. Beautiful. It's a little long but that's okay. Purpose by money enables digital currencies can be spent making them especially useful in real world. Government vouchers, conditional dispersements, skills, future lending, Chris payments. Okay, cool. Stop [Music] token. Okay.

Good good good. Okay.

I'm just going to skip over that because we really don't have a good solution for how to deal with it. Like technically, this is an external link and we shouldn't be allowing it, but because you have to pay for ISO standards, there's no way that we can allow links to them. Also, do we want a CFI again for this? Like call for input or just um I'm just going to pretend I didn't see this. Um cuz like it's a really minor complaint. The alphabetic code is published like freely.

So, it's just going to be too much friction if I complain about it. So, I'm not going to uh has the option to define. But we do need a better way to deal with that. Um, yeah, sure. Yeah, good. That's good. Um okay.

Yeah, this seems fine. Good, good, good, good. None of that's changed. All right, you can go into review. All right. So that was 7291 7878.

Okay. Scan sand properties ready for review. Oh, it's already been merged. Mered. Yeah, we can go to 983. All right. Okay. Draft into review. Okay. The generations mechanism transfer counts how many times energy can be transferred. Okay.

Okay, there's the obvious comment I have to make about this if I haven't already made it. They have not replied. All right. 7634 Okay.

Yeah, I mean this seems fine. It's going to need some work before going into last column, but that's more on the technical side than the um formatting side. So and three to draft algorithmic transaction wrapper. Does this have an assigned EIP number? I would assume so.

Where did you get 7932 from? 9633. Oh, okay.

Cool. Um, transaction type app transaction signal. Oh, I remember this one. Yeah. Okay. This IP address new type transaction that contains another transaction and append signature data another transaction with selector. This coin computer is getting more advanced and large key sizes. Okay. If you plant [Music] Okay, this all looks good. Transaction

is invalid. Good. This is nice.

Nice. Good. Good. Okay. Then they have a Okay. Yeah. This is nice. This can go in. Awesome. So, margin token wrapper. Um 7909 79. Good. Okay. Okay, this first defense token wrapper contract that can convert any 207k to

corresponding margin token which is an ERC is lockable margins. Why I use concept training is collabor One second.

All right. Well, every 28 token wants to be supported by every Oh. Um Um, could be

a single um, what do they call their contract? Margin token wrapper. Okay. Uh I'll be implementing this.

Okay. Um okay. Um, [Music]

Okay. Um, okay. Then you have reference implementation. Sure. That's good. Okay. So, margin token wrapper. Let's go take a look at composite EIP712 signatures. I think we did this one already. Yes. Let's look at SE sustainable collaborative NFT collections. Has this one been looked at yet at all? Probably not.

a little bit. So, has this been changed since my last review? Okay good.

Okay. Then they changed that they have a Okay. Yeah. So now let's give this a a full read through. Okay. So 7832 sustainable collaborative NFT collections economically sustainable collaborative dynamic fees and generation based engagement. Okay. The CIA proposes stand for creating economically sustainable NFT governance for collections built on collaborative models based on 21 in dynamic minting feature control education based engagement model to enhance creator community interactions about scarcity.

Okay. Okay. So I would say So grab this.

Okay. Really recurring challenges face. Okay. Okay.

FE. Okay. Description two terms. Oh, I love chat GPG generated stuff. Um, fixing fees can often lead to hoarding and disproportionate ownership. Um yeah I mean, go for

it. All right, and with that, I'm going to wrap this up. Thank you all for coming and um, we'll see you all either next week or in two weeks. Thank you, Sam. And thank you everyone for joining us here today. I will upload the agenda for the next meeting on Ethereum/PM repo. So if you have any open PRs, please feel free to add your link there. Thank you [Music] everyone.

[Music] Hold [Music] on. Heat. [Music] Heat. Hey, hey,

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

Yeah, moving on. [Music] Hey. Hey. Hey. [Music]