Create NEP-5 template for Neo3

[lock9]

NEP-5

• Mint tokens based in GAS / Token input
• Transfer tokens to smart contract
• Transfer funds from smart contract (verification trigger)
• Create new NEP-5 template (reference code)

From Native NEP-5

• Allow contract to accept Native Gas
• Allow contract to accept Native Neo
• Transfer funds to smart contract using MultiSig
• Withdraw funds from smart contract using MultiSig

From Neo-cli

• Neo-cli: Allow NEP-5 contract to be deployed and called

Note: This is not an 'ICO' template, only NEP-5 (for now)

[lllwvlvwlll]

If we are scoping the LTS and NEO 3.0 as different; should we also segregate (or designation a field in) NEPs to indicate which chain they will target?

[lock9]

@lllwvlvwlll as far as I know, everything from now on will be NEO 3.
Do you think we should change the NEP-5 to adapt to NEO 3? I think it is reasonable to have the 'compatible chain versions' in the NEP. Is that what you are proposing?
I know that the code itself will differ a little, but I don't know if, in NEP-5 specifically, we will need changes

[lllwvlvwlll]

Specifically, I think its good to list Chain Versions: for all NEPs moving forward (even if all future NEPs are 3.x) for clarity. In the template itself; we should have a comments header which indicates Chain Version: as well.

For NEP-5 specifically, there is a precedence for listing ICO template examples in various languages inside the NEP. I believe we should change this to have 1 NEP-5 template (not ICO template) for each language in the NEP instead.

[lock9]

@lllwvlvwlll I agree with you.
Would you like to open this "suggestion issue" in the NEP repository? Do you want me to do it for you?

[igormcoelho]

@lllwvlvwlll this won't be a problem, because Neo3 compiler will generate a NEF file (instead of raw AVM). This is more similar to other vm codes (like webassembly), so if someone tries to deploy wrong contract on network, that won't work (due to magic byte prefix).
And on general, I think all existing NEPs are broad enough to cover both NEO2 and NEO3.
We have so little of NEPs, and all are currently compatible to both networks, so it's just better to put an information of the next ones, if by chance they are platform-specific (NEO2 or NEO3).

Devpack can also create special namespace NEO3 instead of NEO.... to differentiate from other devpack (although package versioning may do this too, in a less visible way).
The point is: standard NEP-5 is the same, same functions, same functionality, what changes now is the implementation of it. Using UTXO or Native NEO/GAS doesn't change the way transfers happen, only the way ICO get resources.

[igormcoelho]

I don't think this is cosmetic, this is a very important issue.

[lock9]

Ops, sorry @igormcoelho.
I changed it to 'enhancement' since we already have a nep-5 template.

[shargon]

Mint tokens based in GAS / Token input
Note: This is not an 'ICO' template, only NEP-5 (for now)

if is not an ICO template, we should remove the mint mechanism, for now

[igormcoelho]

I think its ICO template @shargon, like neo2.. and mintTokens is on nep5 spec, right? So its needed... whole scoped witnesses story was enhancing protection on this 😂

[shargon]

Then we should remove the note "This is not an ICO template" 😆

[rodoufu]

It may have changed since I last deployed a smart contract but when I had to call a method I needed to call the main method and send the method name as first parameter and the other ones as array of object, are we going to improve that?
It very error prone, we don't have any compile time parameters check and it is a bit ugly.
(It may be a topic for the dev devpack project but I just remembered that while reading this issue)

[Tommo-L]

@shargon Could help close this issue, sine #187 has already been merged.