Giter VIP home page Giter VIP logo

iips's Introduction

IIPs

ICON Improvement Proposals (IIPs) describe standards for the ICON platform, including core protocol specifications, client APIs, and contract standards.

Contributing

  1. Review IIP-1.
  2. Fork the repository by clicking "Fork" in the top right.
  3. Add your IIP to your fork of the repository. There is a template IIP here.
  4. Submit a Pull Request to ICON's IIPs repository.

Your first PR should be a first draft of the final IIP. It must meet the formatting criteria. An editor will manually review the first PR for a new IIP and assign it a number before merging it. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the IIP as a whole.

If your IIP requires images, the image files should be included in a subdirectory of the assets folder for that IIP as follow: assets/iip-X (for iip X). When linking to an image in the IIP, use relative links such as ../assets/iip-X/image.png.

Once the first draft of IIP is merged, only the PRs from the owner of the draft will be accepted. Make sure that the 'author' line of your IIP contains either your Github username or your email address inside . If you use your email address, that address must be the one publicly shown on your GitHub profile.

When you believe your IIP is mature and ready to progress past the draft phase, you should do one of two things:

  • For a Standards Track IIP of type Core, ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future release. If implementers agree to include it, the IIP editors will update the state of your IIP to 'Accepted'.
  • For all other IIPs, open a PR changing the state of your IIP to 'Final'. An editor will review your draft and ask if anyone objects to its being finalised. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the IIP - they may close the PR and request that you fix the issues in the draft before trying again.

IIP Status Terms

  • Draft - an IIP that is open for consideration.
  • Last Call - an IIP that is calling for last review before finalizing. IIPs that has been more than 2 weeks in Last Call without any technical changes or objections enters either Accepted or Final state.
  • Accepted - an IIP that is planned for immediate adoption, i.e. expected to be included in the next release (for Core/Consensus layer IIPs only).
  • Final - an IIP that has been adopted. For Core/Consensus layer IIPs, the implementation has been adopted in the mainnet.
  • Deferred - an IIP that is not being considered for immediate adoption. May be reconsidered in the future.

IIPs

Number Title Author Type Status
1 IIP Purpose and Guidelines Sojin Kim Meta Active
2 ICON Token Standard Jaechang Namgoong IRC Final
3 ICON Non-Fungible Token Standard Jaechang Namgoong IRC Final
6 ICON Name Service Standard Phyrex Tsai, Portal Network Team IRC Draft
14 ICONex Connect for Mobile Jeonghwan Ahn IRC Final
16 ICON Security Token Standard Patrick Park, Justin Hsiao IRC Draft
25 ICON BTP Standard MoonKyu Song IRC Draft
31 ICON Multi Token Standard Jaechang Namgoong IRC Draft
35 ICON BTP Fee Gathering Heonseung Lee IRC Draft
40 ICON BTP Message Fragmentation Heonseung Lee IRC Draft
48 BIP-44 Path for derivation of ICON address from mnemonic seeds Fidel, Ben, Eric IRC Draft
49 ICON Provider JS API Fidel, Ben, Eric IRC Draft
52 ICON BTP Arbitrary Call Service Standard Jaechang Namgoong IRC Draft

iips's People

Contributors

bennyoptions avatar cordiallys avatar cow-hs avatar cyrusvorwald avatar fezbox avatar fidelve avatar han-so1omon avatar mksong76 avatar nymkappa avatar phyrextsai avatar sink772 avatar sojinkim-icon avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

iips's Issues

ICON BTP Message Fragmentaion

iip: <to be assigned>
title: ICON BTP - MessageFragmentation
author: heonseung lee (@leeheonseung)
discussions-to: https://github.com/icon-project/IIPs/issues/tbd
status: Draft
type: Standards Track
category IRC
created: 2020-06-14
requires IIP-25

Simple Summary

If the size of the relay message containing the block proof of the SRC chain exceeds the transaction size allowed by the target chain, define and add logic to fragment the BTP message from the BMC to handle this.

Abstract

If the size of Relay Message containing Block Proof larger than Transaction size of target chain, a problem occurs. To solve this, add the logic to fragment and assemble the Relay Message.

Motivation

Block proof of the ICON chain can be verified in the BMV of the chain using only the parts related to BTP.
However, in certain chains, it is sometimes necessary to receive and verify the entire Block Proof.

At this time, the ICON Relay Sender fragments the RelayMessage and delivers it to the ICON BMC,
and it is necessary to assemble and verify it.

For this reason, there is no issue for ICON Block Proof verification on target chain,
so BTP 1.1 implements it only on the ICON BMC.

Specification

Relay

Interface

segment
func (s *sender) Segment(rm *module.RelayMessage, height int64) ([]*module.Segment, error)
  • Description:
    • Fragment Relay Message as much as Transaction Limit size.
relay
func (s *sender) Relay(segment *module.Segment) (module.GetResultParam, error)
  • Description:
    • If the RelayMessage size containing Block Proof exceeds the transaction to be transmitted, the RelayMessage is fragmented and delivered according to the size.
    • If not exceeded, it is transmitted as a normal RelayMessage.
  • Definition of index
    • Indicates the sequence of fragment messages.
    • The first index is total message count * -1
    • The last index is 0
sendFragment
func (s *sender) sendFragment(rmp *BMCRelayMethodParams, idx int) (module.GetResultParam, error)
  • Description:
    • It indexes the fragmented message separated through the segment and transmits it to the targetchain.

BMC

Interface

handleFragment

void handleFragment(String _prev, String _msg, int _idx);
  • Params
    • _prev: String (BTP Address of the previous BMC)
    • _msg: String (Fragmented base64 encoded string of serialized bytes of Relay Message)
    • _idx: Integer (Index of fragment)
  • Description:
    • Concat the BTP messages that come with _idx in the order of _idx.
    • If _idx < 0, it is determined as the first message, and if _idx == 0, it is determined as the last fragmentaion message.
      • Eg)
        • -3, 1, 2, 0
        • -1, 0
    • Instead of verifying each time each fragmentation message is processed,
      it is assembled and verified when the last fragmentation message arrives.
    • Assemble fragments of the Relay Message and call by BMC::handleRelayMessage.
    • It's allowed to be called by registered Relay.

Implementation

TBD

Copyright

Copyright and related rights waived via CC0.

ICONex Connect for Mobile

iip: <to be assigned>
title: ICONex Connect for Mobile
author: Jeonghwan Ahn (@a1ahn)
discussions-to: https://github.com/icon-project/IIPs/issues/14
status: Draft
type: Standard Track
category : IRC
created: 2019-01-02

Simple Summary

A simple protocol for 3rd party Applications that send transactions, ICX coins or IRC tokens via ICONex.

Abstract

This protocol enables the 3rd party Applications to send ICX coins, messages, and IRC Tokens via ICONex wallets.
Requests and responses are provided in JSON format.

Motivation

A service offers easy wallet management tools for ICON dApps and helps them to work more easily with ICON network via ICONex.

Specification

Types

VALUE type Description Example
T_ADDR_EOA "hx" + 40 digit HEX string hxbe258ceb872e08851f1f59694dac2558708ece11
T_ADDR_SCORE "cx" + 40 digit HEX string cxb0776ee37f5b45bfaea8cff1d8232fbb6122ec32
T_HASH "0x" + 64 digit HEX string 0xc71303ef8543d04b5dc1ba6579132b143087c68db1b2168786408fcbce568238
T_INT "0x" + lowercase HEX string 0xa
T_BIN_DATA "0x" + lowercase HEX string. Length must be even. 0x34b2
T_SIG base64 encoded string VAia7YZ2Ji6igKWzjR2YsGa2m53nKPrfK7uXYW78QLE+ATehAVZPC40szvAiA6NEU5gCYB4c4qaQzqDh2ugcHgA=
T_DATA_TYPE Type of data call, deploy, or message

Basic Transmission

All requests and responses follow the Basic API Convention JSON format as below.

ICONex Connect uses base64 encoded strings to Inter-App Communications.

Base JSON Format

  • Request
Key Type Description
data String Base64 encoded string of JSON Object
caller String A caller to receive the response from ICONex.
  • Response
Key Type Description
data String Base64 encoded strings of JSON Object.

Basic API Convention

// Request
{
    "id": $INT1,
    "method": "$STRING1"
    "params": {
        "$KEY1": "$VALUE1",
        "$KEY2": "$VALUE2",
        ...
    }
}

// Response
{
    "id": $INT1,
    "code": $INT2,    // if code == 1 success, else fail
    "result": "$VALUE1"
}
  • Request
Key Type Description Required
id INT Request Identifier Required
method String Method for current request Required
params T_DATA_TYPE Parameters for current request Optional
  • Response
Key Type Description Required
id INT Request Identifier. Exactly same as requested. Required
code INT Status code for response. if code == 1 success else fail Required
result String Contains message for current response Optional

Methods

  • List of methods
Method Description Required Parameters
bind Request wallet address -
sign Request sign for transaction version, from, value, stepLimit, timestamp, dataType(optional), data(optional)
sendICX Request send ICX from, to, value
sendToken Request send IRC token from, to, value, contractAddress

bind

  • Return selected wallet's address.
Parameters

NULL

Returns

Selected wallet's address. (T_ADDR_EOA)

sign

  • Returns the signature of the transaction hash.
Parameters
Key Type Description Required
version T_INT Protocol version ("0x3" for v3) Required
from T_ADDR_EOA EOA address that created transaction Required
to T_ADDR_EOA or T_ADDR_SCORE EOA address to receive coins, or SCORE address to execute the transaction. Required
value T_INT Amount of ICX coins in to transfer. When omitted, assumes 0. (1 icx = 1 * 10^18 loop) Required
stepLimit T_INT Maximum Step allowance that can be used by the transaction. Required
timestamp T_INT Transaction creation time. timestamp is in microsecond. Required
nid T_INT Network ID ("0x1" for Mainnet, "0x2" for Testnet, etc) Required
nonce T_INT An arbitrary number used to prevent transaction hash collision. Required
dataType T_DATA_TYPE Type of data (call, deploy or message) Optional
data T_DICT or String The content of data varies depending on the dataType. Optional
Returns

Signature of transaction hash. (T_SIG)

sendICX

  • Send ICX via ICONex and returns transaction hash.
Parameters
Key Type Description Required
from T_ADDR_EOA EOA address that will send ICX coins. Required
to T_ADDR_EOA EOA address to receive coins. Required
value T_INT Amount of ICX coins in to transfer Required
dataType T_DATA_TYPE Type of data (call, deploy or message) Optional
data T_DICT or String the content of data varies depending on the dataType. Optional
Returns

Transaction hash (T_HASH)

sendToken

  • Send IRC token via ICONex and returns transaction hash.
Parameters
Key Type Description Required
from T_ADDR_EOA EOA address that will send IRC token. Required
to T_ADDR_EOA EOA address to receive tokens. Required
value T_INT Amount of IRC token Required
contractAddress T_ADDR_SCORE SCORE contract address Required
Returns

Transaction hash (T_HASH)

Error Code

Code Message Description
-1000 Operation canceld by user. User cancel
-1001 Parse error (Invalid JSON type) Data is not a JSON type
-1002 Invalid request. JSON must contains required parameters.
-1003 Invalid method Invalid method
-1004 Not found caller. Could not found caller in request.
-2001 ICONex has no ICX wallet. ICONex has no ICX wallet for support.
-2002 Not found parameter. ('$key') '$key' is not found in params
-3001 Could not find matched wallet. ('$address') There is no wallet matched with given address.
-3002 Sending and receiving address are same. Sending and receiving address are same.
-3003 Insufficient balance. Requested value is bigger than balance.
-3004 Insufficient balance for fee. Insufficient balance for fee.
-3005 Invalid parameter. ('$key') Something is wrong with value.
-4001 Failed to sign. Error occurs while signing
-9999 Somethings wrong with network ($message) All errors while networking. $message may contains the reason of error.

Implementation

For more details, please visit ICONex for mobile.

Copyright

Copyright and related rights waived via CC0.

Ideas for soulbound token standard

After seeing Staky-io's soulbound token contract, and after discussing with Lucas, we are exploring the possibility of adding an IIP for soulbound tokens. This thread is to explore what that standard would look like

Idea

Two token standards

  • Soulbound single token (derived from IRC-3, similar to ERC-5114)
  • Soulbound multi-token (derived from IRC-31, possibly similar to ERC-5516)

ICON Multi Token Standard

iip: 31
title: ICON Multi Token Standard
author: Jaechang Namgoong (@sink772)
discussions-to: https://github.com/icon-project/IIPs/issues/31
status: Draft
type: Standards Track
category: IRC
created: 2020-12-07

Simple Summary

A standard interface for managing multiple token types (fungible or non-fungible) on ICON network.

Abstract

This document describes an interface that can be used to manage multiple token types in a contract.
While the existing standards only support single type of token per contract, either fungible or non-fungible,
this standard allows for each token ID to represent a new configurable token type,
which may have its own metadata, supply and other attributes.

Motivation

Existing token standards like IRC-2 and IRC-3 only can handle a single type of token,
thus users need to deploy multiple token contracts separately to manage different types of tokens.
In some applications, notably games that may be creating thousands of traceable items and exchanging them between users,
this limitation is something that is hard to endure and costs much.

Inspired by the ERC-1155 Multi Token Standard,
we propose new functionality that is capable of transferring multiple token types at once and saving the transaction costs.

Specification

Methods

balanceOf

@external(readonly=True)
def balanceOf(self, _owner: Address, _id: int) -> int:
    """
    Returns the balance of the owner's tokens.

    :param _owner: the address of the token holder
    :param _id: ID of the token
    :return: the _owner's balance of the token type requested
    """

balanceOfBatch

@external(readonly=True)
def balanceOfBatch(self, _owners: List[Address], _ids: List[int]) -> List[int]:
    """
    Returns the balance of multiple owner/id pairs.

    :param _owners: the addresses of the token holders
    :param _ids: IDs of the tokens
    :return: the list of balance (i.e. balance for each owner/id pair)
    """

transferFrom

@external
def transferFrom(self, _from: Address, _to: Address, _id: int, _value: int, _data: bytes = None):
    """
    Transfers `_value` amount of an token `_id` from one address to another address,
    and must emit `TransferSingle` event to reflect the balance change.
    When the transfer is complete, this method must invoke `onIRC31Received(Address,Address,int,int,bytes)` in `_to`,
    if `_to` is a contract. If the `onIRC31Received` method 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
    `onIRC31Received` in `_to`.
    Additional `_data` can be attached to this token transaction, and it should be sent unaltered in call
    to `onIRC31Received` in `_to`. `_data` can be empty.
    Throws unless the caller is the current token holder or the approved address for the token ID.
    Throws if `_from` does not have enough amount to transfer for the token ID.
    Throws if `_to` is the zero address.

    :param _from: source address
    :param _to: target address
    :param _id: ID of the token
    :param _value: the amount of transfer
    :param _data: additional data that should be sent unaltered in call to `_to`
    """

transferFromBatch

@external
def transferFromBatch(self, _from: Address, _to: Address, _ids: List[int], _values: List[int], _data: bytes = None):
    """
    Transfers `_values` amount(s) of token(s) `_ids` from one address to another address,
    and must emit `TransferSingle` or `TransferBatch` event(s) to reflect all the balance changes.
    When all the transfers are complete, this method must invoke `onIRC31Received(Address,Address,int,int,bytes)` or
    `onIRC31BatchReceived(Address,Address,int[],int[],bytes)` in `_to`,
    if `_to` is a contract. If the `onIRC31Received` method is not implemented in `_to` (receiver contract),
    then the transaction must fail and the transfers of tokens should not occur.
    If `_to` is an externally owned address, then the transaction must be sent without trying to execute
    `onIRC31Received` in `_to`.
    Additional `_data` can be attached to this token transaction, and it should be sent unaltered in call
    to `onIRC31Received` in `_to`. `_data` can be empty.
    Throws unless the caller is the current token holder or the approved address for the token IDs.
    Throws if length of `_ids` is not the same as length of `_values`.
    Throws if `_from` does not have enough amount to transfer for any of the token IDs.
    Throws if `_to` is the zero address.

    :param _from: source address
    :param _to: target address
    :param _ids: IDs of the tokens (order and length must match `_values` list)
    :param _values: transfer amounts per token (order and length must match `_ids` list)
    :param _data: additional data that should be sent unaltered in call to `_to`
    """

setApprovalForAll

@external
def setApprovalForAll(self, _operator: Address, _approved: bool):
    """
    Enables or disables approval for a third party ("operator") to manage all of the caller's tokens,
    and must emit `ApprovalForAll` event on success.

    :param _operator: address to add to the set of authorized operators
    :param _approved: true if the operator is approved, false to revoke approval
    """

isApprovedForAll

@external(readonly=True)
def isApprovedForAll(self, _owner: Address, _operator: Address) -> bool:
    """
    Returns the approval status of an operator for a given owner.

    :param _owner: the owner of the tokens
    :param _operator: the address of authorized operator
    :return: true if the operator is approved, false otherwise
    """

Events

TransferSingle

@eventlog(indexed=3)
def TransferSingle(self, _operator: Address, _from: Address, _to: Address, _id: int, _value: int):
    """
    Must trigger on any successful token transfers, including zero value transfers as well as minting or burning.
    When minting/creating tokens, the `_from` must be set to zero address.
    When burning/destroying tokens, the `_to` must be set to zero address.

    :param _operator: the address of an account/contract that is approved to make the transfer
    :param _from: the address of the token holder whose balance is decreased
    :param _to: the address of the recipient whose balance is increased
    :param _id: ID of the token
    :param _value: the amount of transfer
    """

TransferBatch

@eventlog(indexed=3)
def TransferBatch(self, _operator: Address, _from: Address, _to: Address, _ids: bytes, _values: bytes):
    """
    Must trigger on any successful token transfers, including zero value transfers as well as minting or burning.
    When minting/creating tokens, the `_from` must be set to zero address.
    When burning/destroying tokens, the `_to` must be set to zero address.

    :param _operator: the address of an account/contract that is approved to make the transfer
    :param _from: the address of the token holder whose balance is decreased
    :param _to: the address of the recipient whose balance is increased
    :param _ids: serialized bytes of list for token IDs (order and length must match `_values`)
    :param _values: serialized bytes of list for transfer amounts per token (order and length must match `_ids`)

    NOTE: RLP (Recursive Length Prefix) would be used for the serialized bytes to represent list type.
    """

ApprovalForAll

@eventlog(indexed=2)
def ApprovalForAll(self, _owner: Address, _operator: Address, _approved: bool):
    """
    Must trigger on any successful approval (either enabled or disabled) for a third party/operator address
    to manage all tokens for the `_owner` address.

    :param _owner: the address of the token holder
    :param _operator: the address of authorized operator
    :param _approved: true if the operator is approved, false to revoke approval
    """

URI

@eventlog(indexed=1)
def URI(self, _id: int, _value: str):
    """
    Must trigger on any successful URI updates for a token ID.
    URIs are defined in RFC 3986.
    The URI must point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema".

    :param _id: ID of the token
    :param _value: the updated URI string
    """

Token Receivers

Smart contracts that want to receive tokens from IRC31-compatible token contracts must implement
all of the following receiver methods to accept transfers.

onIRC31Received

@external
def onIRC31Received(self, _operator: Address, _from: Address, _id: int, _value: int, _data: bytes):
    """
    A method for handling a single token type transfer, which is called from the multi token contract.
    It works by analogy with the fallback method of the normal transactions and returns nothing.
    Throws if it rejects the transfer.

    :param _operator: The address which initiated the transfer
    :param _from: the address which previously owned the token
    :param _id: the ID of the token being transferred
    :param _value: the amount of tokens being transferred
    :param _data: additional data with no specified format
    """

onIRC31BatchReceived

@external
def onIRC31BatchReceived(self, _operator: Address, _from: Address, _ids: List[int], _values: List[int], _data: bytes):
    """
    A method for handling multiple token type transfers, which is called from the multi token contract.
    It works by analogy with the fallback method of the normal transactions and returns nothing.
    Throws if it rejects the transfer.

    :param _operator: The address which initiated the transfer
    :param _from: the address which previously owned the token
    :param _ids: the list of IDs of each token being transferred (order and length must match `_values` list)
    :param _values: the list of amounts of each token being transferred (order and length must match `_ids` list)
    :param _data: additional data with no specified format
    """

Metadata Extensions

To provide rich set of asset metadata for a given token, smarts contracts need to implement the following method
to return an URI that points to a JSON file.

@external(readonly=True)
def tokenURI(self, _id: int) -> str:
    """
    Returns an URI for a given token ID.

    :param _id: ID of the token
    :return: the URI string
    """

Implementation

References

Copyright

Copyright and related rights waived via CC0.

ICON BTP Fee Gathering

iip: <to be assigned>
title: ICON BTP - FeeGathering
author: heonseung lee (@leeheonseung)
discussions-to: https://github.com/icon-project/IIPs/issues/tbd
status: Draft
type: Standards Track
category IRC
created: 2020-05-10
requires IIP-25

Simple Summary

It standardizes the structure in which fees can be charge from BTP network users to cover maintaining costs and activation incentives the IIP-25 (BTP) network.

Abstract

IIP-25(BTP) Network fee is charged to users and standardize about operation policy.
Defines the operating entity that gather a fee.
Defines Fee Aggregator (FA).
Defines interfaces related to FeeGathering BMC Message.

Motivation

In order to cover maintaining costs and activation incentives the IIP-25 (BTP) network,
a structure is needed to charge fees from users who send BTP Message.

The chain to which the entity operating the BTP Network belongs is defined as HUB.
The Smart Contract, which operates with fees from the BTP service, is defined as Fee Aggregator (FA).

The BTP network user pays a fee to the BSH that provides the BTP service of the chain to which he belongs.
The operating entity uses HUB's Fee Aggregator (FA) to collect the fees stored in each chain BSH and operates the BTP Network.
Through HUB's BMC.sendFeeGatheringMessage, you can request a BTP message that sends a fee to each chain's BMC to FA.

Specification

Terminology

  • HUB
    The chain to which the entity operating the BTP Network belongs.
  • Fee Aggregator(FA)
    Smart contract to to raise the necessary financial resources for BTP network operation by gathering fees collected from other chains connected.
  • FeeGathering BMC Message & HandleFeeGatheringMessage
    Interface that processes the logic that transfers the fees stored in the BSH to the Fee Aggregator (FA).

BTP Message Center - Extension

Ref. BTP Message Center

HUB's BTP Message Center sends FeeGathering BMC Message to each link when certain conditions are satisfied, and calls handleFeeGathing from the service managed each BMC of that chains.

Message Struct

GatherFee Message

send to all of connected BMC on BMC.sendFeeGatheringMessage on HUB

Name Type Description
_fa String BTP Address of Fee Aggregator
_svcs List of String list of name of service

When BMC receive this message, find the BSH using 'svcs' and then calls BSH.handleFeeGathering with '_fa'

BTP Service Handler - Extension

Ref. BTP Service Handler

Interface that processes the logic that transfers the fees stored in the BSH to the Fee Aggregator (FA).

Interface

Writable methods
handleFeeGathering
@external
def handleFeeGathering(self, _fa: str):
  • Description
    • Handle the FeeGathering Message.
    • Accept the error only from the BMC.
  • Params
    • _fa: String ( BTP Address of Fee Aggregator )

Rationale

Implementation

Copyright

Copyright and related rights waived via CC0.

Define a Non-Fungible Token Standard

iip: 3
title: ICON Non-Fungible Token Standard
author: Jaechang Namgoong (@sink772)
discussions-to: https://github.com/icon-project/IIPs/issues/3
status: Draft
type: Standards Track
category: IRC

Simple Summary

A standard interface for non-fungible tokens on ICON network.

Abstract

This draft IRC describes non-fungible tokens (NFTs) standard interface to provide basic functionality to track and transfer NFTs. NFTs can represent ownership over digital or physical assets, which can be owned and transferred by individuals as well as consignment to third party operators.

Motivation

A standard interface allows wallet/broker/auction applications to work with any NFT on ICON network.

This standard is inspired by the ERC721 token standard. Unlike IRC2 token standard, where we adopted the token fallback mechanism, we preserved the approve/transferFrom methods in this NFTs standard, because there can not be multiple withdrawals with NFTs as in ERC20 (see ERC20 API: An Attack Vector on Approve/TransferFrom Methods).

Specification

Methods

name

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

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

symbol

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

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

balanceOf

Returns the number of NFTs owned by _owner. NFTs assigned to the zero address are considered invalid, so this function SHOULD throw for queries about the zero address.

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

ownerOf

Returns the owner of an NFT. Throws if _tokenId is not a valid NFT.

@external(readonly=True)
def ownerOf(self, _tokenId: int) -> Address:

getApproved

Returns the approved address for a single NFT. If there is none, returns the zero address. Throws if _tokenId is not a valid NFT.

@external(readonly=True)
def getApproved(self, _tokenId: int) -> Address:

approve

Allows _to to change the ownership of _tokenId from your account. The zero address indicates there is no approved address. Throws unless self.msg.sender is the current NFT owner.

@external
def approve(self, _to: Address, _tokenId: int):

transfer

Transfers the ownership of your NFT to another address, and MUST fire the Transfer event. Throws unless self.msg.sender is the current owner. Throws if _to is the zero address. Throws if _tokenId is not a valid NFT.

@external
def transfer(self, _to: Address, _tokenId: int):

transferFrom

Transfers the ownership of an NFT from one address to another address, and MUST fire the Transfer event. Throws unless self.msg.sender is the current owner or the approved address for the NFT. Throws if _from is not the current owner. Throws if _to is the zero address. Throws if _tokenId is not a valid NFT.

@external
def transferFrom(self, _from: Address, _to: Address, _tokenId: int):

Eventlogs

Transfer

Must trigger on any successful token transfers.

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

Approval

Must trigger on any successful call to approve(Address,int).

@eventlog(indexed=3)
def Approval(self, _owner: Address, _approved: Address, _tokenId: int):
    pass

References

ICON BTP Arbitrary Call Service Standard

iip: 52
title: ICON BTP Arbitrary Call Service Standard
author: Jaechang Namgoong (@sink772)
discussions-to: https://github.com/icon-project/IIPs/issues/52
status: Draft
type: Standards Track
category: IRC
created: 2022-07-11

Abstract

A standard interface to make an arbitrary call service (a.k.a. xcall) between different blockchain networks via ICON BTP protocols.

Motivation

Adding a new service to an existing BTP infrastructure requires an audit of the code to ensure that the service does not have any malicious behavior, because the relay bears the gas cost of executing the service transaction.
To improve scalability and flexibility and to overcome the restriction mentioned above, we propose a new interface for invoking arbitrary cross-chain contract calls that can appropriately charge the gas cost to users triggering cross-chain transactions.

[DISCUSSION] ICON Multi protocol Arbitrary Call Service Standard


iip:
title: ICON xCall Standard
author: Anton Andell (@AntonAndell)
discussions-to:
status: Draft
type: Standards Track
category: IRC
created: 2023-04-24


Simple Summary

A standard interface to make an arbitrary call service (a.k.a. xcall) between different blockchain networks via any bridging protocol.

Abstract

This document describes an extension of xCall as defined in IIP52 that can be used to invoke arbitrary cross-chain contract calls between different blockchains networks using multiple protocols.
The existing interfaces between BMC and BSH (sendMessage and handleBTPMessage)
will be utilized for sending and receiving the requested arbitrary call payloads. Procols other than BTP has to be wrapped to implement the BMC interface.

Motivation

The motivation of IIP52 applies but to allow dapps to use multiple protocols and multi-protocol verification we need to generalize it beyond BTP. This will allow users and dapps to specify their preferred protocols and security models.

Specification

Message centers

xCall will connect to multiple MCs (message centers) implementing the BMC interface.

Encoding of the Calldata Payload

Encoding and decoding of the calldata are up to the DApps implementation.
xcall only passes the raw byte streams with the predefined method calls.
This is simple and easy to implement from the viewpoint of the xcall, and also the result can be sent back to the caller using the same sendCallMessage interface.

Addressing format

Network Address

A Network address is address representing a account on a specific chain and contains the chain native address prefixed with chain id represented as a string:

"<chainId>/<Address>"

Basic Interfaces

sendCallMessage

DApps need to invoke the following method of xcall on the source chain to send a call message to the destination chain.

/**
 * Sends a call message to the contract on the destination chain.
 *
 * @param _to The network address of the callee on the destination chain
 * @param _sources The contracts that will be used to send the message
 * @param _destinations The addresses of the contracts that xcall will expect the message from.
 * @param _data The calldata specific to the target contract
 * @param _rollback (Optional) The data for restoring the caller state when an error occurred
 * @return The serial number of the request
 */
@Payable
@External
BigInteger sendCallMessage(String _to, String[] _sources String[] _destinations byte[] _data, @Optional byte[] _rollback);

The _to parameter is the network address of the callee contract which receives the _data payload on the destination chain. If a Network address is supplied use the default protocol.

The _data parameter is an arbitrary payload defined by the DApp.

The _sources parameter is a list of addresses representing different connections.

The _destinations parameter is a list of addresses representing the connections of the receiving chain.

The _rollback parameter is for handling error cases, see Error Handling section below for details.

This method is payable, and DApps need to call this method with proper fees, see Fees Handling section below for details.

When xcall on the source chain receives the call request message, it sends the _data to _to on the destination chain through all protocols specified in the _to.

CallMessageSent

When xcall invokes sendMessage the following event is emitted

/**
 * Notifies that the requested call message has been sent.
 *
 * @param _from The chain-specific address of the caller
 * @param _to The The network address of the callee on the destination chain
 * @param _sn The serial number of the request
 */
@EventLog(indexed=3)
void CallMessageSent(Address _from, String _to, BigInteger _sn);

CallMessage

When the xcall on the destination chain receives all the call request through the message centers specified in the call request, it emits the following event for notifying the user.

/**
 * Notifies the user that a new call message has arrived.
 *
 * @param _from The network address of the caller on the source chain
 * @param _to A string representation of the callee address
 * @param _sn The serial number of the request from the source
 * @param _reqId The request id of the destination chain
 */
@EventLog(indexed=3)
void CallMessage(String _from, String _to, BigInteger _sn, BigInteger _reqId);

executeCall

The user on the destination chain recognizes the call request and invokes the following method on xcall with the given _reqId.

/**
 * Executes the requested call message.
 *
 * @param _reqId The request Id
 */
@External
void executeCall(BigInteger _reqId);

handleCallMessage

When the user calls executeCall method, the xcall invokes the following predefined method in the target DApp with the calldata associated in _reqId.

/**
 * Handles the call message received from the source chain.
 * Only called from the Call Message Service.
 *
 * @param _from The network address of the caller on the source chain
 * @param _data The calldata delivered from the caller
 * @param _protocols The contract addresses that delivered the data
 */
@External
void handleCallMessage(String _from, byte[] _data, String[] _protocols);

If the call request was a one-way message and DApp on the destination chain needs to send back the result (or error), it may call the same method interface (i.e. sendCallMessage) to send the result message to the caller.
Then the user on the source chain would be notified via CallMessage event, and call executeCall, then DApp on the source chain may process the result in the handleCallMessage method.

CallExecuted

To notify the execution result of DApp's handleCallMessage method, the following event is emitted after its execution.

/**
 * Notifies that the call message has been executed.
 *
 * @param _reqId The request id for the call message
 * @param _code The execution result code
 *              (0: Success, -1: Unknown generic failure, >=1: User defined error code)
 * @param _msg The result message if any
 */
@EventLog(indexed=1)
void CallExecuted(BigInteger _reqId, int _code, String _msg);

Error Handling

In success cases, DApp users only need to invoke two transactions (one for the source chain, and the other for
the destination chain). However, there might be some error situations such as the execution of the call request
has failed on the destination chain. In this case, we need to notify the user on the source chain to rollback to the state
before the call request.

If a DApp needs to handle a rollback operation, it would fill some data in the last _rollback parameter of the sendCallMessage,
otherwise it would have a null value which indicates no rollback handling is required.

ResponseMessage

For all two-way messages (i.e., _rollback is non-null) the same protocols is used in both directions. When the xcall on the source chain receives a response message from the xcall on the destination chain through all of the protocols it emits the following event regardless of its success or not.

/**
 * Notifies that a response message has arrived for the `_sn` if the request was a two-way message.
 *
 * @param _sn The serial number of the previous request
 * @param _code The response code
 *              (0: Success, -1: Unknown generic failure, >=1: User defined error code)
 * @param _msg The result message if any
 */
@EventLog(indexed=1)
void ResponseMessage(BigInteger _sn, int _code, String _msg);

RollbackMessage

When an error occurred on the destination chain and the _rollback is non-null, xcall on the source chain emits the following event for notifying the user that an additional rollback operation is required.

/**
 * Notifies the user that a rollback operation is required for the request '_sn'.
 *
 * @param _sn The serial number of the previous request
 */
@EventLog(indexed=1)
void RollbackMessage(BigInteger _sn);

executeRollback

The user on the source chain recognizes the rollback situation and invokes the following method on xcall with the given _sn.
Note that the executeRollback can be called only when the original call request has responded with a failure.
It should be reverted when there is no failure response with the call request.

/**
 * Rollbacks the caller state of the request '_sn'.
 *
 * @param _sn The serial number of the previous request
 */
@External
void executeRollback(BigInteger _sn);

Then the xcall invokes the handleCallMessage in the source DApp with the given _rollback data.
At this time, the _from would be the network address of xcall and the protocols will be the sources specified when sending the message.

RollbackExecuted

As with the CallExecuted event above, the following event is emitted after the DApp's handleCallMessage execution
to notify its execution result.

/**
 * Notifies that the rollback has been executed.
 *
 * @param _sn The serial number for the rollback
 * @param _code The execution result code
 *              (0: Success, -1: Unknown generic failure, >=1: User defined error code)
 * @param _msg The result message if any
 */
@EventLog(indexed=1)
void RollbackExecuted(BigInteger _sn, int _code, String _msg);

Fees Handling

If a user wants to make a call from ICON to Target Network 1 (T1), he needs to pay X ICX, and for Target Network 2 (T2), he needs to pay Y ICX.
That is, the fees depend on the destination network address.

The fees are divided into two types, one is for relays and the other is for protocol itself.
For example, for a destination network T1, the fees could be relayFee = 0.25 ICX and protocolFee = 0.01 ICX.
And relayFee goes to relays, protocolFee goes to the protocol (eventually, to the Fee Handler).
In this document, we don't address how to deal with these accrued fees for distribution,but just define operational parts like how to get the proper fee amount before sending the call request, etc.

Here are getter and setter methods for the proper fees handling in xcall.
DApps that want to make a call to sendCallMessage, should query the total fee amount for the destination
network via getFee interface, and then enclose the appropriate fees in the method call.
Note that the protocol fee amount can be get/set via xcall, but the relay fee would be obtained from each MC.

/**
 * Gets the fee for delivering a message to the _net.
 * If the sender is going to provide rollback data, the _rollback param should set as true.
 * The returned fee is the sum of the protocol fee and the relay fee.
 *
 * @param _protocol The protocol used
 * @param _net The network id
 * @param _rollback Indicates whether it provides rollback data
 * @return the sum of the protocol fee and the relay fee
 */
@External(readonly=true)
BigInteger getFee(String _protocol, String _net, boolean _rollback);

/**
 * Sets the protocol fee amount.
 *
 * @param _value The protocol fee amount in loop
 * @implNote Only the admin wallet can invoke this.
 */
@External
void setProtocolFee(BigInteger _value);

/**
 * Gets the current protocol fee amount.
 *
 * @return The protocol fee amount in loop
 */
@External(readonly=true)
BigInteger getProtocolFee();

/**
 * Sets the address of Fee Handler.
 * If _addr is null (default), it accrues protocol fees.
 * If _addr is a valid address, it transfers accrued fees to the address and
 * will also transfer the receiving fees hereafter.
 *
 * @param _addr The address of Fee Handler
 * @implNote Only the admin wallet can invoke this.
 */
@External
void setProtocolFeeHandler(@Optional Address _addr);

/**
 * Gets the current protocol fee handler address.
 *
 * @return The protocol fee handler address
 */
@External(readonly=true)
Address getProtocolFeeHandler();

Implementation

References

Copyright

Copyright and related rights waived via CC0.

Define a ICON Token Standard


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

Define ICON Improvement Proposal Process

Background

ICON is an open-source blockchain project. To promote and embrace community participation, we need an IIP (ICON Improvement Proposal) process.

Problem

We do not have one.

Solution

Create one.

Approach

Do not re-invent the wheel.
IIP-1 is about the IIP process. The first draft of IIP-1 will be heavily copied from -

The process of finalizing the IIP-1 will follow the IIP process to test, enhance, and confirm it.

Expected Result

  • IIP-1
  • Template IIP
  • README.md
  • Editor pool

ICON Name Service Standard

iip: TBD
title: ICON Name Service Standard
author: Phyrex Tsai <[email protected]>, Portal Network Team
discussions-to: https://github.com/icon-project/IIPs/issues/1
status: Draft    
type: Standards Track
category : IRC
created: 2018-08-06 

Abstract

This draft proposal details the ICON Name Service inspired by the Ethererum Name Service, which originated from the EIP137. This protocol and related interface definition is to provide extendable resoultion of easy-to-remeber, human-recognizable names to services and resources identifers from both centralized and decentralized systems, and only updated the names whenever the underlying resource (public wallet address, smart contract, content-addressed data, etc) changes.

It's common nowadays that using URI with certain convention mapping to the specific resources. With this experience, we utilize the advantage of blockchain to provide blockchain domain names as short, stable, and human-readable identifiers used to specify network resources. In this way, users can enter a memorable string, such as loopchain.icon, just like how we normally do on browser, and be directed to the appropriate resource. The mapping between names and resources may change in any scenarios, so a website may change the corresponding IPFS hashes, projects may update their smart contract, a user may change wallets, or a IPFS document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, the browser may resolve loopchain.icon to the IPFS hash to redirect to IPFS content, even resolve the same address to a smart contract.

Motivation

Hash is the fundamental of blockchain and used to represent an account of an identity, but the hash address is not easily remember for the normal user, by integrate the ICON Name Service will bring three following advantages:

  • Human-readable identity, users can easily catch up with the name like loopchain.icon instead of hash address.
  • Multiple services under a single name, such as a DApp hosted in IPFS, a contract address, and even a mail server.
  • Increaing the security by tamper proof of the accessing smart contract for the mapping address.

These three features will lower the gap of blockchain technologies and improvement the user adoption.

Specification

The INS system has thsee main parts:

Registry

INS registry is a single contract that provides a mapping from any registered name to the resolver responsible for it, and permits the owner of a name to set the resolver address, and to create subdomains, potentially with different owners to the parent domain.

Registrars

INS registrar is a smart contract that owns a Top-level domain, and allocates subdomains of it according to some set of rules defined in the smart contract code. For any available domain name, users will be able to purchase. The rules for the INS registrar smart contract will be interatly updated according to meet the benefit of whole ICON community.

Resolvers

INS resolvers are responsible for performing resources from a domain name, a resources can be a contract address, wallet address and IPFS hash. Utilizing the resolver smart contract enables users and developers using the decentralized resources easily bring more ideas and values to the ecosystem.

Reverse Resolvers

INS reverse resolver is a smart contract records that mapping from addresses to names.

Rationale

Registry Smart Contract

The INS registry contract exposes the following functions:

Returns the owner of the specified node.

def owner(node) -> Address: 

Returns the resolver for the specified node.

def resolver(node) -> Address: 

Returns the time-to-live (TTL) of the node; that is, the maximum duration for which a node's information may be cached.

def ttl(node) -> int: 

Transfers ownership of a node to another registrar. And this function may only be called by the current owner of node.

def setOwner(node, owner: Address) : 

Create a subdomain and the sets its owner to owner

def setSubnodeOwner(node, label, owner: Address) : 

Sets the resolver address for node. And this function may only be called by the owner of node.

def setResolver(node, resolver: Address) : 

Registrar Smart Contract

The INS registrar contract exposes the following functions:

Register a name, or change the owner of an existing registration.

def register(node, owner: Address) : 

Resolver Smart Contract

The INS resolver contract exposes the following functions:

Sets the hash address for node. And this function may only called by the owner of node.

def setAddr(node, addr: Address) : 

Returns the hash address for the specified node.

def addr(node) -> Address : 

Sets the multihash associated with an INS node.

def setMultihash(node, hash) : 

Returns the multihash associated with an INS node.

def multihash(node) -> str : 

Sets the text data associated with an INS node and key.

def setText(node, text) : 

Returns the text data associated with an INS node and key.

def text(node) : 

Reverse Resolver Smart Contract

The INS reverse resolver contract exposes the following functions:

Sets the name record for the reverse INS record associated with the calling account.

def setName(name) : 

Returns the hash for a given address's reverse records.

def node(addr: Address) -> str : 

References

[DISCUSSION] IIP #49:

iip: 49
title: ICON Provider JS API
author: Fidel (github.com/FidelVe), Ben (github.com/bkbooth), Eric (github.com/han-so1omon)
discussions-to: https://github.com/icon-project/IIPs/pull/49
status: Draft
type: Standards Track
category: IRC
created: June 25, 2022

Abstract

To allow communication between software wallets and web applications is necessary for these software wallets to expose an API via Javascript in the web page. For the wallets and web apps to communicate it is necessary the creation of dispatching and listening events using Javascript in the browser.

Motivation

To ensure seamless user experience and avoid implementation of several API communication protocols in each web application to support several software wallets, it is necessary to implement a standardized protocol for all software wallets and web applications to adhere to.

Procedure

Please review PR #49 and discuss here. Some discussions have taken place prior to raising the Pull Request in this Community Forum post. Please review the preceding discussion as well. Thanks!

ICON Security Token Standard

iip: 16
title: ICON Security Token Standard
author: Patrick Park (@cordiallys)
discussions-to: https://github.com/icon-project/IIPs/issues/16
status: Draft
type: Standards Track
category: IRC
created: 2019-01-21

Simple Summary

This document represents the standard protocol specification for the security token of ICON network.

Abstract

The security token standard describes how to represent full ownership or split ownership of a particular asset.
This standard is compatible with standard IRC2 token IIP-2 and inspired by several security token standards such as EIP-1400, EIP-1410.
A standard for the Partially Fungible Token (PFT) was additionally written for grouping tokens into partition sets, and each partition is represented by a key-value format consisting of a unique key and balance.
Through this standard, ownership of certain assets can be divided and represented, tracked, viewed, privately owned and transferred. It may also be entrusted to a third party provider and may be controlled under strict authorization.

Motivation

The objective is to securitize and liquidate assets on the ICON block chain, by issuing and managing security tokens.
The standard supports legal document asserting the rights of tokenized assets on a block chain, partition management with partially fungible tokens in tranche, and interfaces for managing operator privileges.

Specification

1. Partially Fungible Token Interface

class PartiallyFungibleTokenStandard(ABC):

    @abstractmethod
    def name(self) -> str:
        pass

    @abstractmethod
    def symbol(self) -> str:
        pass

    @abstractmethod
    def decimals(self) -> int:
        pass

    @abstractmethod
    def totalSupply(self) -> int:
        pass

    @abstractmethod
    def balanceOf(self, _owner: Address) -> int:
        pass

    @abstractmethod
    def balanceOfPartition(self, _partition: str, _owner: Address) -> int:
        pass

    @abstractmethod
    def partitionsOf(self, _owner: Address) -> dict:
        pass

    @abstractmethod
    def transfer(self, _partition: str, _to: Address, _value: int, _data: bytes) -> None: 
        pass

Methods

name

Returns the name of the token.

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

symbol

Returns the symbol of the token.

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

decimals

Returns the number of decimals toe the token uses

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

totalSupply

Returns the total token supply

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

balanceOf

Retruns the account balance of an account with address _owner.

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

balanceOfPartition

Returns the balance of the partition with _partition.

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

partitionsOf

Returns the partition information of an account with address _owner. The information of partition consists of a unique key with _name and token amount in partition with _amount

@external(readonly=True)
def partitionsOf(self, _owner: Address) -> dict:

transfer

Transfers or splits _partition to a specific account with _to. You should call self.msg.sender when the _amount of the _partition is sufficient. The @eventlog should be called on transfer call. ( See implementation as below). The transfer method can be managed by the operator specified in the Security Token Standard below.

@external
def transfer(self, _partition: str, _to: Address, _amount: int, _data: bytes = None) -> None:

2. Security Token Standard Interface

class SecurityTokenStandard(PartiallyFungibleTokenStandard):
  
    @abstractmethod
    def setDocument(self, _name: str, _uri: str, _document_hash: str) -> None:
        pass

    @abstractmethod
    def getDocument(self, _name: str) -> dict:
        pass

    @abstractmethod
    def isControllable(self) -> bool:
        pass

    @abstractmethod
    def isIssuable(self) -> bool:
        pass

    @abstractmethod
    def issue(self, _partition: str, _owner: Address, _investor: int, _data: bytes) -> 		None:
        pass

    @abstractmethod
    def redeem(self, _partition: str, _investor: Address, _amount: int, _data: bytes) -> 	 None:
        pass

    @abstractmethod
    def authorizeOperator(self, _operator: Address) -> None:
        pass

    @abstractmethod
    def authorizeOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) -> None:
        pass

    @abstractmethod
    def revokeOperator(self, _operator: Address) -> None:
        pass

    @abstractmethod
    def revokeOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) -> None:
        pass

    @abstractmethod
    def isOperator(self, _operator: Address) -> bool:
        pass

    @abstractmethod
    def isOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) 		-> bool:
        pass

Methods

setDocument

Sets information of document identified by the unique with _name. Raw documentation is organized in offchain. _uri and _document_hash are stored in blockchain to prevent forgery and falsification.

@external
def setDocument(self, _name: str, _uri: str, _document_hash: str) -> None:

getDocument

Returns information of document with _name.

@external(readonly=True)
def getDocument(self, _name: str) -> dict:

isControllable

Returns whether token is controllable.

@external(readonly=True)
def isControllable(self) -> bool:

isIssuable

Returns whether token is issuable.

@external(readonly=True)
def isIssuable(self) -> bool:

issue

Distributes the issued token to _investors through _partition as _amount. Specific metadata can be treated with _data. _partition should be issued as _amount within the totalSupply quantity, The _partition and balance quantity of the _investor must be changed together. The issue method must be controlled by the Operator as below.

if self.isIssuable() and self.isOperator(self.msg.sender):
#issue

The @eventlog for this method should be triggered when calling the issue method.

def issue(self, _partition: str, _investor: Address, _amount: int, _data: bytes) -> None:

redeem

Redeems the _partition of a specific account by _amount. At the time of redemption, _investorโ€™s __partitions should be reimbursed by _amount and _investorโ€™s total balance should also be changed. The redeem method must be controlled and issued by the operator. When invoking the redeem method, @eventlog for this method should be triggered.

def redeem(self, _partition: str, _investor: Address, _amount: int, _data: bytes) -> None:

authorizeOperator

Grants _operator access control to issued token. The _operator and self.owner can control the token. The @eventlog must be triggered when granting access control.

def authorizeOperator(self, _operator: Address) -> None:

authorizeOperatorForPartition

Grants _operator the _partition access control of _owner. The @eventlog must be triggered when granting access control.

def authorizeOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) -> None:

revokeOperator

Revokes the access granted from _operator. Only self.owner and _operator can call this method. The @eventlog must be triggered when revoking access control.

def revokeOperator(self, _operator: Address) -> None:

revokeOperatorForPartition

Revokes the _partition access control of _owner from _operator. Only self.owner and _operator can call this method. The @eventlog must be triggered when revoking access control.

def revokeOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) -> None:

isOperator

Returns whether _operator has access control to token.

@external(readonly=True)
def isOperator(self, _operator: Address) -> bool:

isOperatorForPartition

Returns whether _operator has access control to _partition of `_owner.

@external(readonly=True)
    def isOperatorForPartition(self, _owner: Address, _partition: str, _operator: Address) -> bool:

Implementaion

https://repo.theloop.co.kr/sto/icon-sto-standard/tree/master/score

Copyright

Copyright and related rights waived via CC0.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.