Draft NEP 26 and Draft NEP 27: New NEPs describing onNEPXXPayment callbacks

[roman-khimov]

Please add more implementation references.

[shargon]

Seems good to me, maybe we can use NEP-117 and NEP-111, something related to the parent? or we need to be consecutives?

[AnnaShaleva]

or we need to be consecutives?

Huh, we don’t have to. Seems that’s exactly the case of special numbers:

Assign a NEP number (almost always just the next available number, but sometimes it's a special/joke number, like 666 or 3141) in the pull request comments.

[roman-khimov]

I'd go consequently. #156 is 24, I'd leave 25 for #160 (it came way earlier), so it's 26/27 for these ones.

[shargon]

Please add more implementation references.

Burguer neo?

[roman-khimov]

Link? We can add everything we have, I think it's pretty popular.

[shargon]

Link? We can add everything we have, I think it's pretty popular.

https://github.com/neoburger/code/blob/beb433288bd7b0da9d2245e2a0ae5af5309da7ed/BurgerNEO.cs#L42

[roman-khimov]

Added bNEO and also added a note on ASSERTs.

[shargon]

It's good for me

[AnnaShaleva]

Also good to me, need to update status and add NEP numbers (I'm not allowed to resolve conversations in this repo).

[superboyiii]

@roman-khimov Could you update status and add NEP numbers? No.25 and No.26 will be OK.

[vncoelho]

@roman-khimov, the details look good to me, apart for the first motivation paragraph that I will comment there.

On the other hand, I thought there were additional recommendation in the semantics.

In such case I think you can do an append to NEO-11 or NEP-27.
This does not necessary need a number. There is no sense to me.

[Jim8y]

@roman-khimov, the details look good to me, apart for the first motivation paragraph that I will comment there.

On the other hand, I thought there were additional recommendation in the semantics.

In such case I think you can do an append to NEO-11 or NEP-27. This does not necessary need a number. There is no sense to me.

@vncoelho YOU DO NOT CHANGE ANY EXISTING NEP. ITS NEP, A STANDARD, NOT SOME DOCUMENT YOU CAN UPDATE AND UPGRADE FROM TIME TO TIME.

[vncoelho]

In my opinion it is a New Informational NEP or a documentation issue.

Do we have any place to classify the NEPs?

For example: https://eips.ethereum.org/informational

[roman-khimov]

1. NEP-11/NEP-17 can't be changed. They can only be replaced by some new standards.
2. Motivational part covers it all, try explaining "I'm implementing the token receiver method for NEP-11/NEP-17 and not NEP-11/NEP-17" quickly. Now you can just say "my contract is NEP-26/NEP-27 compliant".
3. See also Replace NEP-5 with NEP-17 #126 (comment)
4. There are some details there were not taken into account by original standards, like ASSERT.
5. There are new opcodes (ABORTMSG/ASSERTMSG) that we know about, but that people will be asking about if not for these standards.

[vncoelho]

Motivational part covers it all, try explaining "I'm implementing the token receiver method for NEP-11/NEP-17 and not NEP-11/NEP-17" quickly. Now you can just say "my contract is NEP-26/NEP-27 compliant".

Sorry it was not motivational part. It was below it. I already left some comments

[superboyiii]

@roman-khimov Please update readme. We can merge this first incase approvals are reverted. @shargon

will not apply