View source for ERC20 to Ignis

<languages />
<translate>
{{#seo:
|title=ERC20 to Ignis
|titlemode=replace
|keywords=ardor learning hub, ardor documentation, blockchain, proof of stake, ardor, ignis, jelurida, development, ardor wiki, wiki, tutorials, advanced tutorials, how to, ERC20 API, conversion
|description=How to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs
}}
[[Category:Advanced_guides]]
__TOC__
==Introduction== <!--T:1-->

<!--T:2-->
ERC20 is a popular Ethereum standard for token management, explained here https://github.com/ethereum/EIPs/issues/20

<!--T:3-->
The Ignis asset exchange on the Ardor platform already supports most of the ERC20 operations out of the box without the need to issue a smart contract. 

<!--T:4-->
This guide explains how to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs.

==Why Use Ignis== <!--T:5-->

<!--T:6-->
Ignis is the first public, permissionless, and fully featured child chain of the scalable, multi-chain Ardor platform. Ardor provides comprehensive solutions to the blockchain industry’s scaling dilemmas with a unique parent-child chain architecture, where Ardor functions as the lean parent chain providing proof of stake consensus for the transactional child chains beneath it. The ecosystem has been live since 01 January 2018. 

<!--T:7-->
In just a few clicks, anyone can issue a unique singleton asset and/or larger supplies of assets on Ignis. Note this article demonstrates the Ignis equivalents of ERC20 tokens; however, it is simple to replicate ERC721 nonfungible tokens as well. That topic will be covered in a separate article. Core benefits of building on the Ignis child chain include: 

<!--T:8-->
• '''KYC/AML''' – This crucial process for verifying account owners and restricting the pool of individuals that can exchange specific assets is made simple with [https://ardordocs.jelurida.com/Features#Asset_control Asset] and [https://ardordocs.jelurida.com/Features Account controls]. 

<!--T:9-->
• '''Flexible Token Supply''' – Assets only require you to set an initial supply, allowing a flexible token supply. Asset controls can limit these changes to the supply. Singleton assets can also be used where unique, individual tokens are needed.  

<!--T:10-->
• '''Dividend Payouts''' – Assets make it simple to pay out [https://ardordocs.jelurida.com/Asset_Exchange#Get_Asset_Dividends dividends] on your digital assets.

<!--T:11-->
• '''Zero Fees''' - [https://ardordocs.jelurida.com/Tutorial_on_custom_bundlers_for_child_chain_transactions Custom bundlers] provide the ability for app and service owners to sponsor end-user fees associated with their specific users. 

<!--T:12-->
• '''DEX''' - A fully functional [https://ardordocs.jelurida.com/Features#Asset_exchange decentralized exchange] is built into the Ignis chain, as well as most other Ardor child chains. Since all child chains are compatible with one another, this means assets and monetary systems launched on different child chains have the potential to interact with one another. 


<!--T:13-->
Developers can make apps and services to the next level by leveraging secure, Turing-complete [https://ardordocs.jelurida.com/Lightweight_Contracts lightweight contracts] to automate more than [https://ardordocs.jelurida.com/API 250+ APIs] to create and manage digital assets, monetary systems, marketplaces, private messaging, voting systems, cloud storage systems, and more. 

==Issuing Tokens== <!--T:14-->

<!--T:15-->
Each ERC20 token is represented as an IGNIS asset.
Issue the asset using the [[Asset_Exchange#Issue_Asset|issueAsset]] API.
Each asset is identified by a unique asset id set to the transaction id of the issueAsset transaction.


==Implementing the ERC20 APIs== <!--T:16-->

===totalSupply=== <!--T:17-->
To get the total token supply invoke the [[Asset_Exchange#Get_Asset|getAsset]] API and supply the asset id. The total supply is provided by the "initialQuantityQNT" attribute, the existing supply, after possible share deletes, is specified by the "quantityQNT" attribute. Quantity values are always provided as integer values, the number of decimal positions to apply to these quantities is specified by the "decimals" attribute.

===balanceOf=== <!--T:18-->
To get the account balance of another account with a given address, invoke the [[Asset_Exchange#Get_Account_Assets|getAccountAssets]] API and provide the IGNIS address as the "account" parameter and the asset id as the "asset" parameter.
For example, http://localhost:27876/nxt?requestType=getAccountAssets&account=yourAccountId&asset=6789385243274909976 when using your own local node or https://testardor.jelurida.com/nxt?requestType=getAccountAssets&account=ARDOR-GHKP-XWB5-XMZB-CTUE3&asset=14378369355033436642 when using the Jelurida testnet public node.
The "unconfirmedQuantityQNT" attribute in the response represents the current account balance. The "quantityQNT" attribute represents the quantity available for use at the moment after taking into account balances locked by open asset orders.

===transfer=== <!--T:19-->
To send tokens from your address to another address use the [[Asset_Exchange#accordion77|transferAsset]] API, specify the recipient address, the asset id, and the quantity to transfer as well as your account passphrase, the transaction fee and transaction deadline. Consider learning about [[Transaction_Vouchers|Transaction Vouchers]] to add an additional layer of security to your transactions on the Ardor platform. 

<!--T:20-->
The transferAsset transaction is recorded on the Ignis child chain, and validated by the Ardor parent chain. You can later track token transfers using the [[Asset_Exchange#Get_Asset_Transfers|getAssetTransfers]] API

===transferFrom=== <!--T:21-->
This is specific to Ethereum. It deals with transferring tokens from a sender account to a recipient account in case the transaction issuer is not the sender and it is not directly supported by Ignis; however, in case you need to support it, you can implement the following procedure:
Submit a tranferAsset API but instead of specifying the sender secretPhrase specify the sender publicKey which you can obtain using the [[Accounts#Get_Account_Public_Key|getAccountPublicKey]] API by providing the sender address. As a result, you'll receive the unsigned transaction bytes in hex format. Send these bytes to the owner of the sender account - you can use a sendMessage transaction or send it off-blockchain. The sender account should then submit a [[Transactions#Broadcast_Transaction|broadcastTransaction]] API to sign the bytes with his passphrase and record the transaction on the blockchain.
The following procedure described above is suitable for [[Lightweight_Contracts|lightweight contracts automation]]

===approve=== <!--T:22-->
Various approval methods can be implemented using the Ignis [[Phasing_(f)|phasing]] attachment, including the ability to approve a transaction only by an account holding a certain asset balance.

===allowance=== <!--T:23-->
is not directly implemented by Ignis, by default the allowance is the available asset balance.


==Trigger the ERC20 events== <!--T:24-->
Events such as '''transfer''' and '''approve''' can be triggered by using the [[Blocks#Get_Block|getBlock]] API, iterate over the transactions included in the block and look for asset transfer transactions for a given asset (transaction type 2 subType 1).
Care should be taken to notify only on phased transactions with the attribute "approved".


==Additional Options for Migrating from Ethereum to Ignis Using Monetary Systems== <!--T:25-->
Ignis also supports a different type of token through the [[Monetary_system|Monetary System]], called "currency.” Monetary Supplies differ from Assets in that their names are unique and a maximum supply must be determined upfront. While this is a proof of stake environment, an option for creating “mintable” currencies exists, which mimics the supply increase you’d see with proof of work networks. 

<!--T:26-->
Among other features, a currency provides the ability to restrict token transfers so that they are allowed only between the issuer account and other accounts. This function prevents free trade of the token without the issuer permission, which is desirable in case of voting rights distribution and crowdfunding, for example. You can also launch currencies backed by reserves of the native child chain token. This means, for example, rewards points, loyalty points, and game tokens can be backed by any child chain by various companies – and each of these tokens have the potential to interact with one another.
</translate>