-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace NEP-5 with NEP-17 #126
Conversation
@shargon @ixje @roman-khimov @vncoelho @EdgeDLT @igormcoelho @neo-project/ngd-shanghai |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First off, happy to see this new NEP 👍 I think an extension to NEP5 could have done, but completely superseding is fine with me as well.
Note that there is a downside to removing the name
function for light wallets. Currently a light wallet can create a single script and use a single invokescript
RPC call to fetch the name, symbol, decimals and totalSupply. Changing this requires another RPC call (getcontractstate
) and fetch the name from there (I'm guessing from the extra
field, of which the content aren't standardised)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add transferFrom
and allowance
?
@shargon, what would be |
you |
With |
|
||
==Abstract== | ||
|
||
This proposal outlines a token standard for the NEO blockchain that will provide systems with a generalized interaction mechanism for tokenized Smart Contracts. This mechanic, along with the justification for each feature are defined. A template and examples are also provided to enable the development community. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be interesting to also invite previous authors of NEP-5 to join this NEP-17 for discussion, or even, authorship (if they agree too).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P.S.: just noticed you informed that on the TODO list, requiring people to submit Pull Request. That's fine then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping @lllwvlvwlll to discuss with other authors of NEP-5.
Then we'd better add |
They can be in |
public static BigInteger totalSupply() | ||
</pre> | ||
|
||
Returns the total token supply deployed in the system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we also need to limit it for the same reasons (at least to int64), and balanceOf
as well.
Co-authored-by: Igor Machado Coelho <igor.machado@gmail.com>
Should we add the |
@chenzhitong |
If a receiver doesn't implement the In addition, should the manifest of the NEP-7 method must be written "permissions": [
{
"contract": "*",
"methods": "*"
}
] , because it needs to call the |
|
那一个合约(ICO合约)想接收别人给他转账,是不是要在 manifest 中这么写 |
For example, if the ICO contract needs to receive neo, it has to trust neo. I don't think an ICO can accept any type of tokens. |
When will it be merged to master. The proposal seems is already implemented in native ocntract. |
Merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's OK to merge.
2cce389
Celebrate🎉 |
Differences from NEP-5:
onPayment
call if the receiver is a deployed contract.payable
check. It has been replaced byonPayment
.name
method, because it should be in manifest for all the contracts, not only for the token contracts.transfer
event to capitalize the first letterTransfer
.