NEAR Contract Standards Working Group Meetings, 22 Aug 2022

Previous Meeting

⏯

youtube image

►

From YouTube: Contract Standards Working Group Meeting – August 22, 2022

Description

The first NEAR Contract Standards Working Group Meeting!

Today we introduced the updated NEP process & working groups and discussed NEP-359 – Non-Transferable NFT Standard.

Chapters:
00:28 Agenda
00:57 NEP process & working groups
03:50 Introductions
06:42 Discussion: NT NFT Standard (NEP-359)
24:52 Q&A

Learn about working groups and register for upcoming meetings:
👉https://neardevgov.org

NEP Process:
👉 https://github.com/near/NEPs/blob/master/neps/nep-0001.md

NEP-359
👉 https://github.com/near/NEPs/pull/359

Join NEAR's community:
Website: https://near.org/
Reddit: https://www.reddit.com/r/nearprotocol/
Discord: https://near.chat/
Medium: https://medium.com/nearprotocol
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
Dev Docs: https://docs.near.org/
Create a wallet: https://wallet.near.org/create
Apps on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Grants & Funding: https://near.org/grants/

#Blockchain #FutureisNEAR #NEAR #nearprotocol

A

Hi everyone and welcome to our first near contract standards, community working group meeting. My name is oriapobam and I'm a technical program manager from pagoda and I'm very excited to kick off this group and discuss contract standards today.

A

So to go over the agenda first, I will give a quick update on the nap process and working groups. Next, we'll do some brief introductions. As we have a few panelists joining us today, then we will get into the main discussion, non-transferable nft standard and, lastly, we will open it up to q a so if, at any time you have questions feel free to drop them in the q, a q, a button on the screen and we'll answer them if they're relevant or wait until the end.

A

Let's start with a little bit of background, so pagoda currently owns a lot of the software development for the entire near ecosystem, and we recognize that in order to make meaningful progress and make decisions in a more decentralized way, we need to make it easier for the community to get involved.

A

So the first step is that we've introduced a more formalized nap process near enhancement proposals earlier this year as a way for anyone in the community to submit proposals, provide rationale and build consensus, and, as we've been getting more nep submissions, we realize that we need a way to move them forward, to review them, make decisions and determine the next step so that they're not just sitting indefinitely.

A

So that's where the working groups comes in the the working groups really is a way to help operationalize the review of those naps and, in the short term, pagoda, has selected a few leading subject matter. Experts to help bootstrap the first two working groups, contract standards and protocol and putting these groups into practice will require a gradual approach and flexibility as we learn what works and what doesn't. But in the long term, as we iterate, we plan to introduce more groups to handle various ecosystem needs and empower the community to run them now.

A

Speaking of iteration, we are here today to kick off the first contract standards, working group and actually start bootstrapping this process. So before we talk about the actual steps, it is important to highlight the various roles that are involved in this process. So there are four key ones.

A

First, the author: this is the person who writes the proposal and presents it to the working group. Second, is the moderator, the person who facilitates the process and helps validate that the proposal meets the guidelines and progresses forward.

A

The reviewer, the subject matter: expert, the the person who reviews the technical feasibility and then the approver. Those are the working group members who make the actual decision and all of that may sound confusing. So here's a diagram to illustrate the entire process and basically, we have three main stages: draft review and voting and two outcomes approved and rejected, and all the roles mentioned before help move the nep through these stages and towards the outcome.

A

The thing that I wanted to highlight is that today we're trying to execute this process and look at a proposal that has been in the review stage and the goal is to have the author presented to the working group and ideally go into a voting decision, and today we're kind of demonstrating and talking about the process and and working through it, but in the future a lot of these activities will also happen uh very actively in the nep directly.

A

So before we jump in, let's do some some brief introductions. So I would like to start with the contract standards working group members and would like to introduce marcelo marcelo. Could you please introduce yourself.

B

uh Yes sure uh hi everyone, uh I'm marcelo from fornet from cuba. I am a software engineer at aurora, currently working at the leading the protocol team and have been involved in a new ecosystem for a long time, looking forward to see the whole movement moving forward and hopefully confronting this.

A

Thanks evgeny, do you want to go next.

C

Yes, I am evgeny kapoon. I am working as a software engineer at pagoda. I am working on security of near ecosystem also on the protocol and focused on cryptography.

D

Awesome and I I'll join the crew. My name is lutz, prolof, I'm engineer manager at pagoda and I'm um I I joined the team quite early on and we worked on very different uh projects in the ecosystem. Bootstrapped a lot of things and I'm excited to see how in-app processes will benefit the whole community as a whole. Yeah thanks. Sorry.

A

Awesome thanks vlad all right. Next, we will introduce the moderators in the process and I will hand it over to max.

E

Hey everyone I'm max, um so I joined near as actually the first employee. I was here from the very beginning and yeah me and oria were launching this war group project, and so I'm here to facilitate it as much as possible.

A

Yes and I've already introduced myself, but I guess I'd like to also add that I am playing a moderator role in this process and very excited to do so. I just joined pagoda recently and yeah very excited to just kick off this, this nap process, so cool and then last but not least, I would like to introduce the nep author for the nep that we're reviewing so jasper.

F

Sorry, yeah hi everyone. My name is jasper tim, I'm a software developer working for kyc dao, mostly on smart contracts. uh We would use something like this non-transferable nft standard that we've proposed uh in our kyc platform. Basically, so that's why we're hoping to get it standardized so, looking forward to working with the rest of the working group.

A

Great well super excited to have you all here and I think now it's a perfect segue after jasper just spoke to actually jump directly into the the major discussion, which is the non-transferable, nft standard discussion. uh The link for that is uh is listed here and we'll also again post it after the meeting but yeah. Let's just jump right into this nep and I'd like to hand it over back to to jasper to provide a high level of this nep and why he believes it is important, so jasper take it away.

A

Thanks. Sorry,.

F

uh Yeah I'll I'll try and make it super short, because I'm gonna be under the assumption that, like a lot of you have uh looked through this uh standard proposal already and uh I'm familiar with it. So it's it's really just like a high level. Walkthrough then um yeah, but in summary, I I think, um there's a need for something like uh an nft that is not transferable.

F

It's gone by a lot of names on on the various chains, um stole-bound tokens and the countdown tokens just essentially something that looks like an nft that is intended for for one wallet and not to be transferred out of.

B

F

So that's that's! What this standard is is supposed to be for um yeah, essentially we're just trying to create a standard so that there's sort of like compatibility with the existing tooling. That's around, basing it off the nap 171 standards essentially and trying to make things like metadata calls and events that would be logged for all the standard events uh similar or, if not exactly the same as the existing sort of nft standard in that 171.

F

Just so that it makes things like compatibility with tools I like displaying in wallets as as simple as possible for those tools so that it kind of just uh carries on, and we get these things by default as much as possible.

F

um Yeah um we're trying to create your standard so that it means um tools get a hint as to yeah, essentially how to handle these cases that they know that there has been a standard created for these and that the intention uh with uh any sort of contract that's created with this standard- is that they're not to be they're not to be transferred uh and that there won't be any uh transfer, slash approval functionality uh in this uh in this contract, and so the the wallets know this and hopefully in the future.

F

If this gets adopted, then that the wallets can you know, for example, just display that they're not to be transferred, but um yeah, it's essentially what we're aiming for. Then. I hope that that covers it. uh As a summary and yeah there's been plenty of discussions in the in the thread already. I assume we're gonna get to that now.

A

Perfect, thank you jasper, yeah. So next vlad will summarize some of the benefits and uh and concerns that we sign the comments and the public comments on the thread. So I will hand it over to you vlad.

D

Yeah thanks sorry yeah, uh I'm I will serve as the um sort of moderator for for the working group uh right now, so I collected all the benefits and the uh concerns that they found in the nap during the all the discussions, including the old ones. So I just want to make sure that we are aware of the whole context, not only part of it.

D

So please bear with me so I'll start with the benefits, and the first benefit I saw was that it's a dedicated standard for a specific real use cases uh like pages ticketing and certificates. uh It follows the the second is that it follows the nft standard um methods like defined in nap 171.

D

um I will unpack it later on, uh so I feel like it's blessing curse um here and the third one is that uh standard itself is quite slim and it could even be uh viewed as a base of the original knapp 171, as it was suggested in the comments.

D

um I don't want to put any color on the on on the facts here, so I I present them as is, and I'd like to move forward to the next uh slide. Where I collected all the concerns, uh and uh the very first one, is that uh what what was rised is that it seems like uh this. Snap does not solve non-transferability property and it was stated in the app itself. So it's not a surprise to anybody.

D

You can transfer the whole um all the tokens. The account holds by selling the whole account so and the second uh very tied together to it is that what people brought in the comments? uh Actually many of them is that non-transferability is the property is itself is concerning, um and there are a lot of use cases where people still want to transfer their tickets certificates uh and uh and other stuff um just for for different reasons.

D

They are not immediately like it's not specifically trading, they just want to manage their assets, so this is the outstanding.

D

um These two are outstanding, whether like connected uh concerns uh there and the comment that was uh brought in the in the community was trying to argue that the nft itself as a standard should not define the transferability, uh while the map 171 actually did it.

D

But the state is the current state of the ecosystem that we already have one nav 171. So we need to unblock ourselves uh starting from here, um or can we move to the next page, awesome yeah? So the third concern I found was that the device ecosystem can be like a system. I mean all the tooling and the apps that were implemented uh using nap. The assumptions that map 171 will be not the only but well the only standard.

D

Interface and currently, with this current proposal, it could be a collision with the with the naming of the methods, uh while the json rpc json events are different, the method names I want to just remind everybody, the json, the interface method. Names are used the same as in app 171, meaning that, like it has nft underscore token and.

D

Yeah and and potentially the metadata uh was advised in the in the in the snap to be used exactly the same as in app 171, which uh makes it very hard to tell them apart um from map 171.

D

So if you have two contracts deployed uh following these two different standard, well technical different standards, uh it would be very hard by the tooling to uh tell them apart, and this brings us closer to the to this force. Point uh first concern about discoverability issue, uh which was also rised a few times that, while it's not solved for nft itself for nap 171, it's a it would be very beneficial and actually more comments.

D

More people brought the idea of necessity to have um a way to discover, availability of mint burn methods and the resolution there that was suggested in the comments was define how we discover nft interfaces, which methods are available, and that way it would be more generic version of this nte nfg standard and the the comment I chose here was from jasper that, uh indeed, like it was among one among uh many uh replies there that it would be indeed uh quite an interesting direction to explore.

D

um Yeah then, let's move on the last two um concerns I found were actually resolved or like irrelevant, and the the the fifth was about the fact that we could actually suffer from spam of ntnft.

D

uh That cannot be burned because well, burn interface is not defined, and- um and you cannot also- you can transfer it, but uh it seems like it's general issue for the whole nft ecosystem in general, and it should be solved outside of this. These two naps, so I I put it like irrelevant here um and the last one which was actually resolved.

D

Initially, there was a burn method implemented or defined as a standard, and the general consensus was that this standard should not define a strictly defined burn method, because there are different use cases and currently, it's sort of results.

D

So uh just to sum it up uh to you all the list, the whole list of um unresolved items, uh we can see them all on the list on the screen, and um basically there are quite some of them um or can you can you help me uh to navigate to like just to to the next stages? uh Here um after we summed it up.

A

Yeah absolutely thank you vlad by the way for for looking at all the the comments you know from from from everyone in the public thread and and aggregating them.

A

So basically, what we're trying to do in this meeting is we want to get into the voting stage right. We want to be able to uh decide if we want to approve the snap um or not basically, and so I think, based on these concerns that you know you have summarize flat, I would like to open it up to the rest of the working group members and basically uh ask sort of what what your thoughts are in terms of how you're leaning um as well as the reasoning for it.

A

So does anyone want to go first.

B

uh Yes, I can go ahead so yeah, so asan was writing before in the discussion. uh There is actually nothing preventing developers from having such nft with uh with non-transferability property. That's something that we cannot enforce uh at this level uh so and there are legit use cases of uh of this standard.

B

So it's in the best of our interests uh to have uh such a standard available for the community to be used, and so actually tools can support it if they choose to give instead that I do uh highly, I do think that um the main uh problem that this snap it's kind of supposed to solve is the discoverability like health, both on-chain and off-chain tools, uh that this is actually an unsustainable nft.

B

So they can react accordingly uh to this, so I think uh like uh having such a such a standard without discoverability, uh it's kind of trying to get ourselves ahead uh of the of the actual, so in general, my opinion would be the according to the nap guidelines. That would be the case, but, uh like I wouldn't say, I reject the standard. I would just prefer see this not included after uh uh the discoverable interface discover uh standard uh process. So maybe that means that in the short term, might lead uh towards a rejection.

B

But uh I do think that uh having this is better than not.

A

Okay, thank you marcelo evgeny. Do you want to go next.

C

A

D

So well just just bring some context uh about my experience with nft in general, like as in in the community.

D

Is I've been working on the tooling side uh quite extensively, meaning like off-chain and on-chain as well, and what I discovered there are indeed a lot of problems with discoverability and it's not solved for nap 171, uh but at the same time I see that with the proposed solution of having um an app that would just help, people to identify whether transfer, mint or and burn methods are available would be even more beneficial than having just a non-transferal nft standard as it currently states.

D

So with that in mind, I am leaning towards rejecting this uh standard as if it is today and strongly support all this future um effort in. In writing. This uh extended um an nft discount, interpreted, detection and nap going forward.

D

Yeah um worry, I guess overall, given that we are in the same like we have the. uh Currently, we have uh evgeny and marcelo um on the board and uh well uh again, do you want to uh to um to participate uh in in the voting uh today or do you prefer to.

C

Yes, I would agree, then, with other approvers that probably instead of having just two types of nfts in terms of the functionality, it's better to have some more generic interface. That would allow more flexibility in terms of what functions are present or not.

D

Okay, well, it sounds like we are at consensus that we can well officially move on to this voting process.

B

D

Ori, you can take a stage and just help us to make it more formal here.

A

Cool yeah, so as part of the the decision making step of this this nep process um we're looking for two third consensus, you know on either like we have two third majority to to approve or to reject. It sounds like, in this case, there's there's more of a majority even beyond that, but I want to just ask just to to make sure um that we have it on the call. So it seems like there's a leading there's, a consensus, leaning towards uh rejecting the current nep as it is written.

A

um If you, if I stated that correctly, please yeah please thumbs up. If, if you disagree with that thumbs down so yeah working group members.

D

I don't have a emoji here, so I'm using it's old school, okay.

A

Okay cool, so it seems like we have reached a consensus, then uh towards rejecting the approval. um The the proposal at this time and obviously we'd want to leave specific comments in the nep itself. uh You know, as we discussed on on what it would take, uh you know for a future proposal uh uh to look like so yeah. We will summarize the the discussion on the ndp itself and ask the working members to formalize their vote there after the meeting.

A

So okay great. So I think now it's time for q a- and I see actually there's quite a bit of chatter and questions, so we can go um yeah. We can go through them. So ben couric brought up a comment. I kind of disagree with the spam nfts being irrelevant irrelevant with the standard. This is a much bigger issue than it is for regular nfts. As with regular nfts, you can simply transfer them away.

D

Well, just just to briefly mention that uh why, because it was my decision to market as irrelevant, uh I feel that you, you won't battle with the spam spending your near just transferring something again like away, and usually you would find some way to hide them and that's much easier way to deal with those. So it's I feel that could be a separate standard that would basically have some blacklist or white list of contracts that will be part of wallet uh standards going forward. uh Yeah, you're, gay.

C

I want to say why this has nothing really to do with spam like this nepa.

C

The problem is that someone can make a token that implements the regular nft standard, but which is not actually transferable, like they have a transfer function that always panics, for example, and so you can't really fix this with a standard because spammers their adversaries. They can not follow standards.

D

And they even can set very high. You know gas uh expectations for that function. You they will burn everything you just.

C

D

A

Just panic yeah also from then is I'm also confused about the approval rejection process we're doing right now. If there are concerns that are unresolved shouldn't, we resolve the concerns and vote in the proposed resolutions. First, until most things are resolved and then approve the nep itself. That's a great question. Well,.

B

I do uh I do agree with ben. I think this is a lot of problems right now. Even it was uh rejected, but in general I just think that there are before we need to have a potential solution.

D

I guess worried the best way to describe it with with the diagram we had uh in the previous slides and ideally so today. As already said, it's our first meeting and we choose to force things a bit, but going forward we'll try to make sure that all the decisions are recorded in the nap itself and the meeting will be mostly used for a formal, final discussion.

D

If there is some tie or just uh out of order, work group meeting where we would have the who would this, we would ahead of time um agree that we need to have a sinkhole with with the community with the work group and discuss matters. So this to today call is a bit uh unusual. One.

E

I also want to add uh for everyone that one of our core goals of this workgroup meeting is to make sure that discussions that are started are actually ended and they are not ever never never end. In discussions, it's not not in anyone's interest to have a discussion on the proposal that just doesn't end and so um we're very we're open um for any suggestions how it can be achieved in general. So if you're on this call- or you see it later- as a recording, please suggest to us how you recommend to resolve this issue.

E

The current way we're resolving it is that we put a firm deadline for any kind of proposal. We say by the end of two months: it should be either approved or if or it should be rejected like and you we can reject things based on right. This is the rest. Concerns are still being brought up, they're still unresolved. Maybe this is too raw, or maybe this is an indication of some kind of inherent flaw uh in in the in the proposal itself.

E

um So that's uh our way of of addressing it is that, if it not if cons, outstanding concerns are not results after two months, it can be indicated or, like maybe deeper, underlying issue, but, as I said, we are also open uh to anyone here to propose alternative solutions to it.

A

So there's another comment: would this mean extending nep 171 with an interface to check if the token is transferable or not.

D

Yes, sort of so we actually discussed on nap briefly, though, that there is a huge interest in knowing whether burn interface is available, whether mint interface. What what is the name of the mint function?

D

So uh it could be, as slim as just a boolean flag, but I hope to see if we can make it more generic and cover mint and burn methods as well. Somehow,.

B

I was actually uh even thinking to take it further if possible. I also don't want to just take this particular standard, but uh on a feeling there is an interface is total uh standard that allows uh contracts to tell which interfaces they implement, so it's possible for uh for a contract to implement several interfaces at the same time that are not related to each other. So maybe we can also have something like this in here and I think that's exactly what we could use in this case.

A

Yeah- and I saw that cameron just asked a question and it looks like max just responded to it max. Did you want to speak to this? The question is: is there a path to editing the proposal for it to be approved at a later date.

E

Yeah, basically, it's continuation. What I was saying is that if we reject it, then it can be either indication of well. They can't either concerns have been generated and not been answered, which might be an indicator of inherent issues, so maybe start again rethink it from the scratch or maybe just also an indicator of a lack of the interest from the community right.

E

If someone proposed an idea, but it was not developed by anyone, even if it was a good idea, maybe there is just not enough demand and no one uh took it over as a torchbearer and having polished it to the end. So uh just to keep things going, you know start another pull request.

E

It's really up to you, whether you, like literally copy the code and edit it or like copy the original request and edit it to address the issues or you start entirely from from the scratch yeah, but like the form, the formal part here is at the start, and you pull request.

A

Okay, so then uh another question from cameron is: what is the next nep that is going to be reviewed? How is this decision made? Yeah, that's a really great question, and- and that is something that we're actively still figuring out in the process. You know we have a list of neps and we're trying to figure out how it makes sense, and so I think we're actively exploring that like that way and would love ideas.

A

But I assume also just kind of uh looking at where there is uh activity is probably a good place to start kind of seeing like where, where is there seem to be a lot of interest and engagement? Again, as I think a few have mentioned earlier, we really want to start having more of this dialogue in the neps themselves, and you know once we have enough of a backlog of naps and we need like a very clear here's, how we protest that we will make sure to also specify that approach.

A

You know we have another um work group that we plan. We we picked another nep to try this experiment with and we will follow a similar sort of approach and then kind of gather all the the feedback and insights and continue to iterate from there all right. Does anyone have any other questions.

B

I do a question for jester: uh even it's uh and your main interest to have this standard is, are you or your team available to work on a following of any key that helped address current concerns, for which visual was rejected?.

B

So, just to just to check.

F

Our question that was a are we planning on working on a on a new nap for the same standard that like addresses the concerns. Is that what the question was.

B

Yes, I think in this case it will be about addressing the problems of uh interface discoverability, uh and it's wondering if.

F

Yeah, um maybe just if I could quickly slip in, I feel like just in the in the discussion. I guess then it yeah it feels like. I got the impression that there was a way forward with with this existing nap and, like I understand this is kind of a working working progress of how it works. But I guess I don't know somehow practically. I guess it feels like some sort of like on hold status or something like I understand you guys want to get through these naps as quick as possible, but just yeah.

F

It feels like there is a way forward. I guess then, but yeah I'll follow the standards and given that, I think it makes sense that, like once this interface detection is here that we would essentially yeah uh include that in a in a new net. For the same thing. So to answer your question yeah, I think we'd be happy to consider a net that would that would include that. I guess it just feels like we had it and we could have included it. But it's if it's in you and evidence- and you have this one.

B

Yeah yeah, I would recommend to actually write first, maybe in the near forum, uh to start a discussion there um yeah so such that we can actually get to some consensus and then become more of a formality than anything else of details. Technical details, yeah.

F

Yeah, I think it'd be handy to to get some consensus going in a in the forum first. I guess then, as to what would be required uh so that when we, when we submit the net the next time that like we know that they'll be that they'll do some backing from the approvers that those that those concerns won't come off again. So yeah that'll be helpful.

D

Yeah one thing I want to mention is that I I I personally hate to like reject snaps, because I know how hard it is to to make those been been there done that and been rejected a couple of times for different reasons, um totally not fun. But overall I feel like uh we are guardians of the ecosystem health here and this, like especially breaking other tools.

D

I know how, like I've been on the other side as well, where implementing tools you need to then create a lot of uh custom code to just avoid, detecting the thing that you don't want to take into account.

D

So uh definitely it would be like we will need to think through of some faster way to get semi-consensus, as you mentioned, so we don't spend so much time um talking through it. um I I personally wanted to just make some progress, even even if it's harsh- and you know, uh feels um and like that, we are so strict and decided to reject for sake of rejection. It wasn't the case. It was very hard decision, as I mentioned in all my comments.

D

A

Yeah and jasper in that doc, in that link, that's actually on this screen. There is a whole part about like yeah the the front end of the process and, like you know, kind of engaging in the governance form, but I will go and actually try to make a really explicit sort of idea that you mentioned, because I think it's really good.

A

Oh, and I see that max just answered cameron's question about the next nep that we should review max. Did you want to speak to that.

E

Yeah uh definitely this is the beginning of the process for nomination. So someone needs to speak up and say hey what about this snap, so thank you, cameron for bringing it up. As we said in the future, we're gonna have an actual pipeline for this, but right now this is exactly how we have this nap surfaced.

E

um We gonna look how it stacks against other neps, so we need to look and see whether anything is on fire right now and we need to discuss something urgently there. If not, then this is a really good nomination to discuss multiple fungible tokens standard next.

E

Regarding your next question of uh which of the pull requests, slash naps should be uh discussed uh yeah. If you feel very passionate about this nep, then please help us by deduping them uh either close such as the closed one merge them together, whichever um that will certainly make our life easier to focus on one nap instead of two.

A

So, ryan, just posted one, depending on your schedule, for how frequent these meetings are another one or more than one that will come soon, will be from j code l relating to some important important partnerships: okay, yeah, please reach out. I don't know what this really means, but yeah definitely reach out. If you have any questions, thoughts, concerns ideas.

A

B

uh One question of my own audi: is it supposed that every nfp should go through this process of approval in a meeting yep? Okay,.

D

So there will be different work groups, as is already presented in the very beginning, that we will also have a protocol working group which will be using the same nap process same repo, but there will be a different people in charge of reviewing those and there there even could be a stricter process there, and we believe that uh protocol is uh super important uh to make sure that those features are actually implementable and will lend eventually and uh contract standards are of a different nature and it's more like finding how the tooling should fit into the table so expect all those working groups focusing on different aspects being more or less uh strict about their requirements.

D

But overall, like I, I work with worry closely these days and I see a lot of work put there to make sure everybody on the same page and the community can have certain expectations which is like which contributes to transparency at the end of the day and um yeah. Or do you want to speak uh there? Yeah.

A

No, I totally agree and um yeah we're just going to continue to try to iterate on this and would love ideas, concerns uh participation because that it's gonna it's gonna, be a collective effort right to figure to figure this out and really the goal is to create more more movement.

A

You know on these neps that a lot of them have just been sort of sitting in an idle state and we really want to give them the attention that they deserve, because everyone has, you know, great ideas and we want to to align and help evolve the ecosystem, so yeah cool. So with that, I want to thank everybody for for attending. Today, uh especially, you know, jasper the author, thank you for taking the time to submit the the nep and engage in this process that we're figuring out.

A

uh You know as we go, and also thank you to the working group members, the panelists who joined today and who have been involved in the actual forums and and in here and then, of course, to the community and everyone else who has been engaging. That's super awesome and we hope to to see that continue.

A

Just in terms of next steps, so we will be posting this meeting, uh recording and summary and github. We also have a website that we put together for the working groups that will list the upcoming meetings that are coming up and as well as links to previous recordings.

A

So we will have the protocol working group meeting most likely happened in september, we're actually actively discussing uh you, know nep right now uh in the forums and I hope to figure out the best one to to have this this this process uh tested with but yeah other than that. I think this concludes our our first working group session. So thank you, everyone! So much and hope you have a good rest of your day or evening wherever you are so take care.

A