EIP Editing Office Hour #33

Transcript

welcome to EIP editing office our meeting 33 um we have added pupil request to be reviewed today suggested by community in the chat on the agenda for today's meeting thank you Sam for joining us here may you want to start with the PRS for final and last call yeah I can give that a go so um we're looking at ERC 792 which is going into final just going to make sure we don't have any active discussion here yes the last post was in January all

right this proposal introduces fixed income Financial bonds with key characteristics defined to facilitate Bond issuance in the primary Market okay this seems fine if fixed income instruments are wiely used asset class for corporations transitioning famar Concepts okay the following token interface as well the rc65 interface all right

okay that all seems fine to sh holders okay okay cross chain transfer okay that all looks fine

yeah this seems fun and off we go to final perfect next up we're moving to last call oh this is my own P request so I can't approve this I think it has already been approved by one of the authors or someone yeah it just needs one of the other EIP editors to approve it I can't approve my own so can we make it uh for the next meeting like EIP AP meeting or sure yeah just wait okay perfect I will add it yeah I mean it's not like a a pressing issue it just needs someone to look at it I can update

the date I guess while I'm here yeah I mean like we would like the proposals to for 14 days only not extend the period if we can um so yeah I will try to bring it to the attention of other editors okay so that would put us on the 26th then all right all right to review 7,7 okay so I had some comments on here they made some changes excellent let's give this a read

through okay okay okay let's give this a read then okay verif techniques okay that's great verifiable

great so the verifiable unique requirements Genera content enties representing models in a collection the standard provides interfaces T ml or op ml to verify whether or not the AI GC data for an nft should from a certain ml model with a certain input the proposed interface is for additional functionality related to minting verifying and enumerating a GC nfts Additionally the metadata schema provides a structure format for St information related to AIG GC nft such as the promp generate the content okay that's good two two pror types of proofs good zkl train model on ckp verifier to ethereum cool the

opml and claim input publish the inference tab can perform the inference and submit the inference output can challenge it okay let good defensive mint function okay so 165 72 y okay option inumerable that looks great okay

good MIT MIT MIT MIT looking good yeah I think this is great we can approve that and get that into review um Sam I think your screen font size is like really low maybe you can increase it a little bit Yeah that would be better when we are giving it in for recording all right so I think there are

couple of more for reviews if we can maybe take a look and miscellaneus then we have a few more um for which authors have already joined in here sure so erc's 252 right 252 hey L did you have any questions about this in particular or you just wanted somebody to look at it um L if you have any question with respect to p252 please add

here 7622 goodes 20 cool this proposal introduces a protocol aimed at enabling deposit and authorization within erc20 token payments of token funds us are empowered to preauthorize specific service providers deduct funds within predetermined limits ensuring smooth and secure transactions additionally users retain the flexibility to modify or revoke authorization for prot service providers okay

okay so how can I word this so what I'm trying to say here is that um I think for me somebody who's somewhat familiar with the rc20 um there's not enough information here explaining why appr proven transfer don't work um so I would like to see a little bit more detail about that um yeah so

for hopefully that's explains kind of my thoughts on that um and I'm not saying this is a bad proposal that like don't get me wrong it's just I think you need to justify it a little bit more um yeah there's a lot of prior arst doesn't mentioned that's a good point yeah okay service provider

register okay register authorization am is updated okay F authorization

for okay decision Bas okay compatibility find deposit and authorization traditional pay methods okay a preauthorization model us can improve a specific service funds with predefined limits enhancing transaction security

and control Okay so for

okay moreover the incorporation of a third party intermediary into the payment process introduces additional layer of oversight and accountability mitigating the risks associated with unauthorized fund deductions and enhancing trust within the ecosystem this intermediary role opens up opportunities for reputable organizations to participate in the payment process fostering social benefits such as and Community engagement R behind the choice 20

tokens okay reference implementation okay yep that's a reference implementation all right funds transactions checks for Service provid registration Security checks Okay cool so I think that's pretty much

for this one um from a uh like editor point of view I think it's it's well done I I don't see too many um like complaints that'll stop it from getting merged as a draft on like the content side I think you definitely need to spend a bit more time um convincing readers that this is better than just approv and transfer and I think you need to go into a little bit more detail about how it's meant to be used um but overall yeah I think this is this is good and I don't see any reason why it won't get in um into a draft all right so I think I saw that there were some more here so that is 266 266 yeah

okay balance extension what is a balance extension to include balance functionality similar to the erc20 okay and more

detail okay so I'm going to have to read 721 for this so let's start with that okay balance of so there is a balance of here so then you're definitely going to have to explain a bit more this extension def find interface that

adds balance functionalities to your c721 tokens enabling functions and events for balance squaring transfer and approval similar to es E20 tokens um yeah so I mean we have approv and we have transfer already so um and if uh if any of you catch that I'm

missing something obvious here please jump in and and tell me because yeah I'm separate maybe also how it differs from 1155 yep that's a good one yeah I'm always just like more prior art more prior art

okay sem D represent divisible ownership Stakes or shares of associated rights such as those pertaining to digital assets real estate or intellectual property the ability to ACC accurately query and exchange these shares is crucial for facility okay market operations however the absence of built-in support for token balances within the current ERC 721 standard yeah so I think I think we're definit so this definitely clears it up a little bit but just saying token balances here is odd because like ERC 721 tokens already have balance functionality

for okay so balance decimals number decimal places used for token balances yeah yeah so turns to sum of token balances in existence turns the balance of the specifi to yeah this this is going to collide with okay yeah cuz you're saying that it is

an ERC 721 so Returns the allowance Grant yep so these functions all already exist in erc721 so I'm I'm very confused B featur into each token we need about the see okay this is definitely

balance ener can be in balance transfer function um transfer from okay cool see 7628 that's good good is fully okay approvals upon ownership transfer good good that's fine those are all security considerations you have the right license in here good okay all

right so then we want 292 name registry extension add a time limited unique naming registry mechanism to ERC 21 tokens Okay so for

is okay this extension defines an interface that adds a naming mechanism Toc 721 tokens it allows each token to have a unique name with an a set expiration date the interface includes functions for signing updating query names in their Associated token show names that remain unique until they expire so

um okay f registry smart contract this the name registry okay so name specific tokens token is named okay so it looks like based on just this that it's limited to a specific token contract token minted with name right so is this meant to be attached to you okay so

okay docment it with name okay okay that's supposed to go on here there we go okay name of cool that

makes sense oh it only returns a byes 32 so it's limited to 32 okay interesting okay the Restriction is not expired so this is like reverse mapping token owner can set the name integeration right I think you can just get rid of this it's not super necessary you can just Dive Right into to it uh PR new okay token possess unique name have 21 compatible

restrictions okay I think that's yeah that's pretty decent all right um cool so there's a question in the chat Sam looks like 209 is not marging even if it is approved by you probably because the yeah this is still running so it should merge shortly um yeah all right this looks fine let's go take a look to receive and transfer erc20 tokens oh this one all right issues okay

blockchain this is going to review okay from ging digital Collectibles to decentralized finance allow to participate in complex mon Delon transactions okay with this extension composite transactions solving both funable and non-fungible assets become easier this functionality is particularly Val valuable for applications requiring intricate transactions yeah I think that's okay by yeah that looks great okay so let's look at the specification a bit here so the token received ERC 20 tokens how was

that was that admitted CH the token specific year C20 balance ah I see so you it only allows for pull that makes sense okay okaying sa

transer yep that makes sense okay good test cases good reference implementation uh hden logic yep caution yep inations use the message senders from their trans fre to okay and these are reasonable security considerations at first glance and uh transfer directly to the nft contract will be lost yeah okay that look fine to me into

review you go what do we have in chat here we have okay let's take another look at this [Music] one so what went wrong with this our reviewers have approved and then Auto mer oh when all conversations are resolved I don't know why that setting has been turned on it's it's very annoying yeah that was resolved resolve

resolve resolved resolved what conversation is not resolved okay everything's approved

I mean everything looks good to me I have no idea why this isn't merging yeah I'll just merge this by hand I I really have no idea why it's not merging um sorry about that I think there is another proposal which is 182 um if we can maybe take a look at that that is also all approved 182

okay so that's failing because of EIP validator oh this is changing a final EIP I think um yeah okay 77 this one's been approved did I approve this one did I think so yeah yeah I feel like I shouldn't have but uh let's turn off annotations

okay so that one's good that one's good that one's good that one's good and SE IP such as what is that so I mean that doesn't really matter so

that's fine okay I mean sure we can it's already approved so I guess I'll just merge this by hand I don't think it's oh right we need two people to approve this one for it to merge um so I guess throw this on the EIP IP agenda um okay we need to BU bug one of these three people to approve it um so that one's done that one's done so 6538 we are also joined by author for PR

178 maybe after this we can take that one oh let's do that one first so Yeah 178 we can come back to this one okay defines a specification so um

okay so this is new add RCS so there should be going in as a draft um you can immediately open a poqu uh you can immediately open a PO request to move it into uh review once it's merged if you're ready but it's easier think of one is a draft um okay so uh one second

sorry about that okay so this proposal introdu introduces a standardized framework for onchain interest rate swaps to propose standard a to facilitate the simulus in exchange of fictional floating interest rate cash flows between parties proval Finance applications um okay interest rate swapping to not dtive

contract one two oh okay yeah so I would just move this up um because you have the definition here it just be nice to get it a little earlier interest swapping to notes a derivative contract wherein two parties maely consent to exchange a series of forthcoming interest payments on a specified notional amount this financial instrument serves as a strategic tool for hatching against interest rate fluctuations the mechanism entails the utilization of a benchmark index to facilitate the exchange between a variable interest rate and a fixed interest rate despite its red wide spread use is currently an absence of a standardization framework that enables the representation of IRS contracts on blockchain platforms that's great perfect of a standardized protocol is

imperative to address this Gap um it's a little um flowery um consistent transparent methodology for depicting IRS contracts within the blockchain environment by doing so it would enhance the inability security and efficiency of interest rates swap transactions on just elect your technology I mean that's that's fine um it's kind of implied like if you're

writing an ERC like it's about moving a financial in instrument on chain um it's not a problem to leave it here it's just not always necessary to say it um okay depicting okay okay contract compli with the CC

must impl the following interface so I don't think interface needs to be capitalized here the contract must inherit the year2 from uh for

okay interest swaps 20 and swap okay must beever this contract is terminated okay the IRS pair to pay fixed interest um okay so bit of bike shedding on the there you are on the name of that um

okay okay agree to pay fixed interest okay um to pay floating interest yeah

so so pays pays yeah all right so uh please s so these are that code in the financial system so the the part who

pays the fixed rate interest is always go the the the payer and for the voting part it's always called the the receiver that makes sense um just nomination yeah it's just um in in because you're proposing a new standard you have kind of have the opportunity to fix or make things more clear than they would have been before um if you want to keep the names like it's not a requirement that you change them but it's just a suggestion as like a software developer if you wanted to make yeah but feel free to ignore the comment so swap right Bas Point Unit

um okay okay actually that would be a separate thing over here okay then we have another comment here

which is on Swap rate and spread um B points

for do still that open you have decimals okay now let me just make sure that you don't have uh another function in here that expl that that covers that um turn the contract similarly um I'm going to stop correcting agreed um if it shows up again just just fix it

yourself uh if the two parties agreed to S up interest rates in usdc then this function for return the uscc contract address okay okay turn notional amount two parties agree to swop interest rates in usdc maybe equal to okay Returns the notional amount in unit of asset to be transferred when swapping IRS this amount serves as the basis for calculating interest payments okay so in so if I understand this correctly the interest swaps have or the interest rate swaps have to be on a single token like you can't swap interest in die for interest in

usdc yes exactly okay why sorry why this because when we Define a contract so we are uh like defining um something to exchange just um cash flows for one currency we cannot I don't know we cannot Define one contract for two currencies if you want to Define to exchange interest for two currencies for example then you need two contracts okay because interest rate is a contract in financial system it should

be contract so this contract is to exchange a cash flow which cash flow yes it's cash flow related to a benchmark sorry a national amount which is a currency it could be something else like a bond but it should be one specific instrument okay that makes sense well I mean it makes sense as far as I understand anything Financial so um maturity date okay turns basis point unit okay

okay to the real time yes exactly okay gives agreement to swap

IRS the contract deployment prior to initialization of the first payment it is imper to invoke thefunction as an expression of their agreement H so it's IL legal okay okay because you you the two parties

need to agree uh before they can exchange uh interest finish um writing this comment but uh yeah that that that makes sense um yeah don't just reply to me just put it in put it in the document um can make a swap calculation

and transfers the interest difference okay cool um for mul process 12 contract but the pay and receiver must sign for the transaction sign so okay to interest pay associated with the IRS must be tokenized by assuring according to the terms of swap each token should represent a specific interest payment every time a swap happens swap function is called one token must be burned from each part

okay every time a swap happens the swap function is called one token must be burned from each party okay um okay what was that there so um

diagram process for contract deployment to okay The Establishment frch the critical okay so this is [Music] motivation okay traditional financial markets have

long utilized interest rate swaps as a fundamental derivative for managing interest rate risk the integration of such instruments within blockchain platforms yeah so this is also so yeah same here so okay just the r use the ABS send okay yeah so I think all of your ration is more suited to motivation so the

rationale should like um okay um um for

okay reference implementation can be found here Foundation good okay so unless you're mentioning code um don't do that but can do something like yeah do something like this if you want you don't really have to um yeah impation interest rate risk okay into account of risk

okay um just take a look at your header here you have erc2 in there good um good um then 165 okay

good um then looking at this so you have CC1 excellent good1 yeah no so that looks good so um Fe back um for

example was it proove I think it was it proove agree that's what it was um so you know I'm not an expert on

financial stuff so please take this comment with a grain of salt it's just um try to do as like little on chain as possible uh because it costs money and um like try to provide as many Hooks and and tools for other contracts to interact with yours so if you think about it as like you know people call it like money Lego all the time so try to like for example not providing um the go ahead

yeah not providing the um number of uh decimals is is um like like an example like it'd be useful for a human because they can think about an offchain but an onchain contract has no idea what the representation is so it's important to think about it from like a a programmer like connectivity kind of view um yeah but no like good standard um I think you you know um a lot of potential here and um yeah I think it's great I'm going to wrap it up here cuz it's we're like 13 minutes past time um I will see you all in two weeks thanks for coming up thank you thank you Sam there is just another request by one of the authors

who is present here on the call today maybe to take a look at uh issue number two P request number 284 if you get a chance to maybe take a look at it you think that would be great to have yeah I'll do my best thank you very well thank you everyone for joining us today hope to see you in two weeks have a great one