ERC20 to Ignis
ERC20 is a popular Ethereum standard for token management, explained here https://github.com/ethereum/EIPs/issues/20
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.
This guide explains how to implement the ERC20 APIs using the equivalent Ardor and Ignis APIs.
Why Use Ignis
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.
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:
• 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.
• Dividend Payouts – Assets make it simple to pay out dividends on your digital assets.
• Zero Fees - Custom bundlers provide the ability for app and service owners to sponsor end-user fees associated with their specific users.
• DEX - A fully functional 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.
Developers can take apps and services to the next level by leveraging secure, Turing-complete lightweight contracts to automate more than 250+ APIs to create and manage digital assets, monetary systems, marketplaces, private messaging, voting systems, cloud storage systems, and more.
Each ERC20 token is represented as an IGNIS asset. Issue the asset using the issueAsset API. Each asset is identified by a unique asset id set to the transaction id of the issueAsset transaction.
Implementing the ERC20 APIs
To get the total token supply invoke the 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.
To get the account balance of another account with a given address, invoke the 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.
To send tokens from your address to another address use the 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 to add an additional layer of security to your transactions on the Ardor platform.
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 getAssetTransfers API
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 secretPharse specify the sender publicKey which you can obtain using the 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 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 automation
Various approval methods can be implemented using the Ignis phasing attachment, including the ability to approve a transaction only by an account holding a certain asset balance.
is not directly implemented by Ignis, by default the allowance is the available asset balance.
Trigger the ERC20 events
Events such as transfer and approve can be triggered by using the 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
Ignis also supports a different type of token through the Monetary System, called "currency.” Monetary Supplies differ from Assets in that their names are unique and a maximum supply must be determined up front. 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.
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 crowd funding, 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 euro-pegged tokens on the AEUR child chain by various companies – and each of these tokens have the potential to interact with one another.