EIP Editing Office Hour #70 (EIP + ERC)

Transcript

Heat. Heat. [Music] water.

Jesus. Thank you. Heat.

in progress. Welcome to EIP editing office hour. This is meeting number 70 and is added to Ethereum/PM GitHub repository 1702. We are joined by editor Sam Wilson. And in this meeting we are going to take a look over EIP plus ERC's pull request. Thank you Sam for joining us. Maybe we can start with proposals as listed there on the agenda.

>> Sounds good. >> Let's see what we're doing today. Moving to final semester should Okay. and oh sure so expireable NFTts and SPTs nonf fungeible and sobb tokens with expiration supporting a time limit yeah that works let's go take a look at the discussion thread And yeah, looks good. No changes. Okay. Uh,

introduces an extension for ERC 721 nonfgeible tokens and soulbound tokens that adds an expiration mechanism allowing to become invalid after a predefined period. This additional layer of functionality ensures that the expiration mechanism doesn't interfere with existing NFTt or SPTs preserving transferability for compatibility. Expiration can be defined using either block height or time stamp offering flexibility. Okay, that's great. Uh before the CRP NFTs and SPS implemented expiration mechanisms for your custom mappings. However, this approach presents challenges such as inconsistent integration with other smart contracts. The custom ERC implementations might misbehave when used in NFT marketplaces.

This approach presents challenges such as inconsistent integration with other smart contracts, the custom implementation. There's like a grammar error there. However, this approach presents challenges such as smart contracts and that the custom implementation is so does that read better. This approach presents challenges such as no just that such as the custom implementation. Yeah. Okay, that reads better when used in

refresh. And we'll flip to split. Uh might misbehave when you stand places. The CIP addresses these issues by providing a built-in expiration mechanism and interfaces that are compatible with the existing infrastructure. It supports both per token and epoch based expiry allowing developers to choose the appropriate expiry type for their use cases including access and authentication, authentication for identity access management, membership for membership management system and ticket and press for meetings and center travel conventions and exhibitions.

That's cute. when using with ERC 12 or 2135 okay so that looks final and then 7578 yeah it's also final nice um digital certificates contracts copyright okay loyalty program voucher coupon governance voting rights. All right. Uh compatible implementations must implement the IERC7858 interface and must inherit from ERC 721.

This interface all functions defined in the interface must be present and all function behavior must meet the Yeah. Okay. Uh so I'm just going to assume that they know how to write a solidity interface. Okay. Found some that inherited from sim must return all tokens even if expired. They still exist but are unusable due to Yep, that makes sense. For NFTs transfer from and safe transfer from must allow transferring tokens even if they're expired. This ensures that expired tokens remain transferable and tradable preserving compatibility with existing applications already deployed. However, expired tokens must be considered invalid and unusable in contract. Okay.

Expiry time must meet the type of expire used by the contract. Yep. used for retrieving the status of token ID must return true if the token is expired. Must revert if the token ID does not exist. True. If the token is expired, it must revert if the token ID does not exist for Okay, there's definitely something weird going on there. Um, okay. Is token expired is used for true

the status of a given token ID. The function must return true if the token is expired. It must revert if the token ID does not exist. For implementations that use custom error, no just implementations that use custom errors should revert with ERC 721 non-existent token following the relevant EIP. Yeah. And for implementation uh let's do other implementations implementations using solidity version

or that is preferring to use revert with string error. and implement. Okay. Implementations that use custom error should revert with following the real and implementations using solidity below version are those preferring to use revert with string error should revert with non-existent token. If the token is exist and is not expired the function must return false. Okay, that's better. So, start time and end time of token ID can be blocked at number, blocked at time stamp depending on expiry time. The start time must be less than end time and should

Oh, that that doesn't make any sense. And start time must be less than end time. Yeah, I don't really feel confident updating that one. Uh, so we'll just commit this. So that's on line 99. Should this be something like

and the start time can be blocked to member block type. The start type must be less than or equal to and should start time and end time of zero indicates that the token ID has no time.

Uh in case start time is non zero but the end time is zero start time is not zero but end time is zero. Now let's do a case where start time is not zero but end time is zero. Also considered H the case where start time is not zero but end time is zero.

Tokens with a non-zero start time and a zero end time are also considered. No. The token ID does not exist. This function must revert the does not exist. This function must revert in the same way as okay.

Start time and end time. A token ID can be blocked out number blocked out time dependent on expiry type. The start time must be less than or equal to start time and start time should be strictly less than end time except when both are set to zero. A start time and end time of zero indicates that the token has no expiration. Tokens with a non-zero start time and zero end time are also considered to have no expiration. If the token ID exists, this function must revert in the same way as this token expired. All right, so I don't think that changes the meaning of any of that. It's just better worded. So, I'm okay not restarting the last call deadline, but we'll see what the author says.

okay. Um, supports interface for IERC 7858 is blah. >> So, how would this work? Is there a plan to force merge or we would leave it as comment and expect the author to merge it? >> Yeah. So, this one this one I'm not entirely sure that I'm correct on like this is a bit more of a involved change. So, I'm not going to just make a commit.

I'm just going to leave a a pull request review. >> that sounds good. Yeah, because this is to move into final status. Yep. >> Yeah. Yeah. Exactly. Um, how about 165? I think it's supports interface,

isn't it? Yeah. Okay. Token expiry updated must be when

the token is minted or when its expiration details are updated. Okay. Um, epochs represent a specific period or block range during which certain tokens are valid. Borrowing concepts from 7818. Represent period specific period or block range during which certain tokens are valid.

I guess tokens are grouped under an epoch ensure the same validity duration for implementations that require epoxation management. Okay, that's fine. Assume that you wrote that correctly. Adding a header. That's fine. Unexpired balance at epoch must return unexpired or usable balance of tokens held by an account at the specified epoch. must return only unexpired or usable

tokens. Current epoch um length between epox time in seconds. Okay, is about okay cool. uh these optional function that developers may choose to implement based on their specific wire requirements use cases. Yeah, that's fine. Remaining time or blocks before the given token ID is expired.

That's fine. Uh, that's good. 721. Okay. Yeah, that's fine. Okay. Nice. >> It took longer than we expected. Impression is proposal moving to final is in like perfect shape and we could just merge it. Nevertheless, uh Sam, we are joined by an Arthur and if you would like to maybe take a look at his proposal, the PR number is 1149 on ERC repository. It seems you have reviewed this proposal earlier but still

waiting to get merged as draft. >> Sure thing. Let's

put you back here. 801. Okay. Minimal single chain multiart agent coordination using heap 712 stations. Okay. Good. Defines a min single chain program for multi-party a coordination initiator post intent and each participant provides a variable acceptance at testation which the required set of acceptances is present in fresh the intent is executionable the standard specifies type data life cycle mandatory events. Okay. Which privacy reputation threshold policies those are expected reference and specification. Okay cool.

uh agents in D5 MAV often need to act together without a trust coordinator existing intent standards define single initiator flows and do not specify multi-party agreement 8001 provides general onchain perimeter for this case and initiators ERP 712 intent plus per participant acceptances uh the intent is only executable when the required Center of acceptances is present and unexpired. Privacy thresholds bond in question.

Okay. Cent. Must use the E7 domain version one verifying contract should expose the domain 5267.

Okay. Some types, some hashes. Yep, that's all fine. Single intent nons per agent implementation should revert.

Okay, that's fine. And this should be there isn't actually this file here. Um, 01 slash

contract. Okay, that's fine. This needs to be the exact one from the template. Good.

Yeah. And then everything else looks fine here. So, boop. All right. Um, did you want to look at 1140 next? >> Yes, it seems like it's requested, but uh, I don't know, for some reason author got disconnected. Maybe internet issues or what, but we can definitely look into that. >> Sure. Oh, that is a lot of description.

So some uh as we noticed earlier in EIP IP meeting that some of the older PRs are missing description. Maybe this is not for this one particular we can take it in a separate meeting. Should we add something or should we just copy title over there >> like for um for example ERC20? >> That's correct. Yes. >> Yeah. So, like I we could maybe move the simple summaries into the description, but I think the the policy so far has been just not to touch old proposals unless we have to.

>> Mhm. >> Um >> Okay. >> Yeah. I don't really feel strongly about it. >> Yeah. Because you know, simple summary for your C20 is simple, but not for many other it could be a paragraph over there. >> Yeah. >> There we go. Um, so we can probably make this a little bit better here. Okay. Purposebound ERC20 with multi

condition unlocking there there. Okay. So, I will just turn off the annotations for this. Um, but you will have to fix all of those before we can merge this. Um, okay. Okay, the CRC extends the concept introduced in E 7291 by namely ERC20 compatible tok multicondition unlocking constraints combining temporal identity and usage restrictions into a programmable structure. It aims to support controlled dispersement of tokens where funds are only accessible under predefined auditable. Perfect.

Um EIP 7291 introduced purpose by money by restricting how and where tokens can be spent. How many wearable applications require multiple conditions to be satisfied simultaneously before tokens can be used? Examples include let's make this Okay. This was generalized such use

cases for layering unlocking conditions on top of the RC20 standard. there's an interface So, unlock condition.

It's fine. Cool. Okay. So, let's take a look at 1160.

Did we already look at this one today? No. Okay. Uh, change from draft for review. Okay. All right. Um AI agent NFTts met okay for NFT specifically designed for AI agents where the metadata represents agent capabilities and requires privacy protection unlike traditional IF standards that focuses but defining unified interface for

different val verification methods. 11:57.

All right. This is >> 4337 is back. >> Nice. So there are two open PRs for this uh particular proposal. This and the next one as well just to let you know.

>> Okay. Are they both moving into review or? >> I think so. Yes, both are moving into review. I don't know why there are two. There could be conflict. We might want to check. Okay. So, they're Yeah, they've just Yeah, this one's replacing the other one. That makes sense. Okay. Uh countraisens protocol changes. Yeah, that's perfect.

Remove that. Good. Yep, that's all fine. Okay. Most of this I don't think has

changed. They removed that. Good. Yeah, I think this is fine. Okay, so that's 4337 7908. Move from draft to review. What are we doing here? Okay. A lot of treasury systems.

Where did I see that? Let's see if this is short enough to fit here.

Oh yeah, definitely. This proposal aims to provide a standardized method for onchain treasury management or institutional assets, ensuring secure private key generation, hierarchical management, departmental permission, isolation while supporting assets. security and transaction efficiency multi-chain environments by defining a unified duration path and security mechanisms. This proposal offers an efficient and secure solution for treasury management with the rapid

development of blockchain and defy secure management of onchain assets become critical. Traditional private key management struggles to meet the security demands of large organizations in complex scenarios where hierarchical key management permission controls and multi signature mechanisms are essential. This provides station. I mean, I guess I could just do Yes.

needs to be linked. 44 to indicate 44 compliance.

Think we use space for bips. Yeah, we do. Okay. Uh NC identifier to department identifier should be emitted. Yeah.

Not. Okay. Can I just like get the permal link to

this? There it is. That saves some time. That's 32. That's 44. All right. So that's 7908. So 7829

All right. Bring data assets online digital products NFTs to ensure there. Yeah. Okay. Cool. This professor extends the RC729 standard to support data assets which refers to digital products created by creators. proposal datability layer that

safeguards aren't changed. integrity preventing value discrepancies caused by option date loss temporary expiration. Okay, here you see 721 proposed NFTTS consent. Yeah, that seems fine. Go for it.

All right, I think I'm going to call it here today. Um, thanks everybody for coming out. Hopefully, uh, this helped move your proposals forward a little bit. Um, I guess we'll see you in a couple weeks for me. Um, are we doing an EIP one next week? >> Uh, yes, we are hoping to. We will, uh, check with editors. Um, otherwise, yeah, uh, we'll be happy to have you. Thank you, Sam, so much for taking our time and reviewing all these proposal. This definitely helps. >> It's my pleasure. Take care. >> Thank you everyone. Take care. Bye-bye. usual thing. Jesus

Christ.