icon-project/IIPs

Define a ICON Token Standard

Closed this issue · 6 comments

sink772 commented

The draft standard is under Last Call status. Please find the standard at https://github.com/icon-project/IIPs/blob/master/IIPS/iip-2.md

iip: 2
title: ICON Token Standard
author: Jaechang Namgoong (@sink772)
discussions-to: https://github.com/icon-project/IIPs/issues/2
status: Last Call
review-period-end: 2018-08-28
type: Standards Track
category: IRC
created: 2018-08-07

Simple Summary

A standard interface for tokens on ICON network.

Abstract

This draft IRC describes a token standard interface to provide basic functionality to transfer tokens.
We adopted the token fallback mechanism inspired by ERC223, that a token contract can implement to prevent accidental transfers of tokens to contracts and make token transactions behave like other ICX transactions.

Motivation

A token standard interface allows any tokens on ICON to be re-used by other third parties, from wallets to decentralized exchanges.

Specification

Methods

name

Returns the name of the token. e.g. MySampleToken.

@external(readonly=True)
def name(self) -> str:

symbol

Returns the symbol of the token. e.g. MST.

@external(readonly=True)
def symbol(self) -> str:

decimals

Returns the number of decimals the token uses. e.g. 18.

@external(readonly=True)
def decimals(self) -> int:

totalSupply

Returns the total token supply.

@external(readonly=True)
def totalSupply(self) -> int:

balanceOf

Returns the account balance of another account with address _owner.

@external(readonly=True)
def balanceOf(self, _owner: Address) -> int:

transfer

Transfers _value amount of tokens to address _to, and MUST fire the Transfer event. This function SHOULD throw if the self.msg.sender account balance does not have enough tokens to spend. If _to is a contract, this function MUST invoke the function tokenFallback(Address, int, bytes) in _to. If the tokenFallback function is not implemented in _to (receiver contract), then the transaction must fail and the transfer of tokens should not occur. If _to is an externally owned address, then the transaction must be sent without trying to execute tokenFallback in _to. _data can be attached to this token transaction. _data can be empty.

@external
def transfer(self, _to: Address, _value: int, _data: bytes=None):

Eventlogs

Transfer

Must trigger on any successful token transfers.

@eventlog(indexed=3)
def Transfer(self, _from: Address, _to: Address, _value: int, _data: bytes):
    pass

Token Fallback

A function for handling token transfers, which is called from the token contract, when a token holder sends tokens. _from is the address of the sender of the token, _value is the amount of incoming tokens, and _data is arbitrary attached data. It works by analogy with the fallback function of the normal transactions and returns nothing.

@external
def tokenFallback(self, _from: Address, _value: int, _data: bytes):

Reference Implementation

References

spood commented

Any thoughts on including a delegatedTransfer function to pay for the transfer fee, similar to ERC865? ethereum/EIPs#865

My thinking is this would allow two things:

  1. "feeless" transfers by allowing a contract to pay for the transfer fee instead of the sender.
  2. token transfer fees that are paid for by selling the token for ICX, so the sender doesn't require an ICX balance.

For the 2nd point, since it requires selling the token and I believe this would be a great use case for the DEX.

The motivation for this change would be the same as ERC865, which is to provide a good UX. This is accomplished by abstracting out complexities that add friction to the process, such as having to explain to token holders that they require ICX to make a transaction.

  • 👍2
deanpress commented

Will this standard as it is permit the holding and transferring of tokens between smart contracts? See my transferAndInvoke proposal for NEO here: neo-project/proposals#64 for reference

  • 👍1
sink772 commented

@spood @deanpress This token standard is the first proposal in ICON network to enable very basic functionality to transfer tokens. I don't expect much functionality to this basic standard. I think simple and minimal design would be outweigh other complex scenarios in current early stage. It's better to propose more complex token transfer scenarios as followup IRCs.

  • 👍1
deanpress commented

@sink772 The problem with extending an existing token standard at a later time is that smart contracts might handle equal things differently. For example if a dApp wants to make conditional transactions between users and smart contracts, and they integrate something themselves before a standard exists, then you will eventually find many different methods and operations that achieve the same goal. This will make things difficult when dApps want to integrate different tokens, and they have to apply lots of different methods for performing the same thing.

sink772 commented

@deanpress In general, I agree with your comment. However, I see your proposal has not yet finalized even in NEO community. ICON needs a token standard immediately and there is not enough time to discuss about more complex functionality. Furthermore, since we adopted the token fallback mechanism from ERC223, transferring tokens between contracts is possible.

  • 👍3
sojinkim-icon commented

IIP-2 becomes Final after two-weeks last-call period.

  • 🎉1