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

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.

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.

Please add more implementation references.

Burguer neo?

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

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

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

Added bNEO and also added a note on ASSERTs.

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

@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.

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

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.

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

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