The Occam.fi Technical Series: On Cardano Native Tokens and ERC Tokens
This post is the second in Occam.fi’s technical series and it begins with an outline of the current state of token creation in the Ethereum ecosystem, and a crash course in how to create an ERC token. We’ll provide a non-exhaustive list of possible ERC token standards one could adopt and the overall drawbacks of developing a token on the Ethereum blockchain.
We will then introduce the Cardano Native Token (CNT); we will look at how one might mint their own CNTs and how they interact with the Cardano ecosystem. We will compare CNTs to what Ethereum’s ERC tokens have to offer, understand how they are a marked improvement on various Ethereum standards, and why developers should heavily consider building their projects on Cardano instead.
The Ethereum Token
We begin this article with a general reminder, Ethereum tokens themselves ($ETH) are not ERC-20 tokens, or any other ERC standard, and its best to understand the Ethereum blockchain as an operating system (OS) that is powered by $ETH. The individual ERC-20 tokens are merely programs that are able to interface with $ETH and the Ethereum block chain but can not act as a substitute for it.
At this point, let’s take a step back as you may be asking: What does ERC mean, what are these ‘standards’, and how does all of this work in relation to Ethereum? To begin with, any token utilizing one of the ERC standards is a smart contract with an internal ledger which says which address owns how many tokens. Thus, when transactions occur with that ERC token, the internal ledger is able to track the exchange and change the respective account balances accordingly.
The Ethereum community has adopted a plethora of standards, such as ERC-20, to streamline projects and make sure the ecosystem is generally interoperable across multiple venues of use, ensuring smart contracts and DApps are still functional regardless of who or what implements them. Standards are typically introduced via the Ethereum Improvement Protocols (EIPs). Should a party have an EIP they wish to introduce to Ethereum, they would follow the flow pictured below in figure one. An EIP begins as an ‘Idea’ then progresses along until it reaches the ‘Final’ stage, where it is accepted by the community and implemented into the Ethereum Blockchain.
ERCs or ‘Ethereum Request for Comment’ are a division of EIPs which handle application level standards. EIPs generally deal with smart contracts, their format, and use. Currently, there exist around twenty-one ERCs that are in the ‘Final’ stage and are actively used by the community, on top of those there exist another few dozen that are in various stages of review.
The most important thing to understand at the end of the day is that with any ERC standard and token, you’re essentially dealing with an Ethereum based smart contract that has different features depending on which ERC was chosen. All of the various possible token standards that exist all boil down to being smart contracts with internal ledgers, it is just the behaviour allowed by the code of these smart contracts that differs across the many standards.
Creating an Ethereum Token
Creating a new token on Ethereum is a rather straightforward but lengthy process, there exists options where a user can simply use a program to create their token but generally it is better to custom write the solidity code necessary to bring their token to life. For example, when creating an ERC-20 token the user will need to define:
- Their token’s max supply cap (if there is one),
- The balance of people holding the token,
- The allowance or the minimum amount required to transact,
- The approval function which ensures counterfeiting is impossible,
- ‘Transfer’ which handles users moving tokens,
- ‘TransferFrom’ which deals with automatic payments.
Once the user fills all of the code out they simply connect their MetaMask to either the token generator software or have their IDE deploy the code directly to the Ethereum blockchain to be able to access and utilize their token, assuming there were no errors.
Though the process is thoroughly explained by guides online, in the end it is up to the token creator to read up on the various ERC standard options and select whichever best suits their project. The creator must then build their code to fit that specific standard as many standards are not interoperable with each other.
Lastly, it’s important to understand that the vast majority of DApps are ERC-20 compatible but not necessarily compatible with the other dozen plus ERC standards that are available to use. This is a vital distinction, as the choice of something other than ERC-20 may result in noncompliance and compatibility problems with most of the smart contracts that exist on Ethereum today.
List of ERC Standards
Finally, we’ll now discuss a list of just a few of the potential ERC standards that a token creator has the option of choosing from. This list is not intended to be exhaustive but merely showcases a few tokens one could choose from and what each ERC offers.
- ERC-20: By far the most common of the standards and the most widely used and developed for. It is fungible, meaning its tokens can be used interchangeably with each other. It was also the first standard to be accepted and as a result, it does have some bugs inherent in its design. For example, if a contract address does not accept ERC-20 tokens and a user sends it tokens, they will be lost forever and unretrievable, much like the incident in this article where roughly $300 million Ether was lost due to a “series of a bugs in a popular digital wallet”.
- ERC-223: Is an improvement upon ERC-20 and is designed with the idea of preventing accidental loss from occuring when users send tokens to a specific smart contract address, this is known as ‘token fallback’. Additionally due to its design it has reduced gas costs but its implementation would require exchanges, centralized and decentralized, and DApps that intend on using it to modify their protocols to be able to interface with it effectively — currently a huge undertaking.
- ERC-721: This was another landmark standard within the community as it introduced the concept of nonfungibility, and thus kicked off the NFT craze. Each token that falls under the banner of ERC-721 has a unique token ID that gives it its unique nature, and is what many projects use to identify their NFT.
Cardano Native Tokens
Now that we have familiarized ourselves with the large volume of information regarding Ethereum, ERC token generation, and their list of potential token standards, let’s introduce Cardano. Building on Ethereum’s innovation of smart contracts, Cardano revolutionizes the token creation space with their introduction of the Cardano Native Token (CNT) made possible by the Mary hard fork.
Cardano simplifies the process of creating tokens on an existing blockchain, and more importantly, significantly increases the security, safety, and functionality of all the tokens developed on the network. With Ethereum, projects had to familiarize themselves with the variety of ERC standards that they could choose from. Each ERC standard has its own potential for human error and risk of not being interoperable with the wider Ethereum ecosystem. Cardano solves this with the single Cardano Native Token (CNT).
Creating a Cardano Native Token
One has three options when trying to create CNTs utilizing the Cardano Command-Line Interface, the Token Builder Graphical User Interface, using the Daedalus Wallet, or even using a site like ‘Cardano-Native-token.com’. Whichever route the user chooses to take, it is markedly faster than the rather drawn out process that requires the user to think through their use case and code the specific token smart contract on Ethereum.
With the tools provided by Cardano and the community, users may need to spend only five to ten minutes at most creating their token, before directing their attention back to their projects as their main focus.
The CNT differs immediately from an ERC token in that it is not inherently dependent on a smart contract. This is a major difference, because as ERC tokens rely on smart contract interaction, this introduces human coding errors into the equation. Besides, the more complex the token, the higher the cost of transacting with it — as every line of data increases the required gas to process the token. Moreover, since the ERC tokens are not native tokens on the Ethereum block chain they must be accounted for with custom smart contracts to ensure that they are able to be used. With Cardano, the CNT inherits all of the major traits of ADA by using the same underlying token logic, it is recognized by the internal ledger, and it costs significantly less to transact with these tokens as compared to their ERC counterparts.
When it comes to interacting, transacting and using these CNTs, users already have native support offered by Cardano wallets such as Yoroi and Daedalus. These CNTs will be able to work seamlessly with many of the projects that are in development right now during the runup to the Alonzo hard fork. Projects focused on yield-farming, DEXs, and even CEXs which wish to provide access to these CNTs won’t have to adjust much of their underlying code — as CNTs are already treated like ADA.
If one would compare this to the Ethereum ecosystem it’s a different story. On Ethereum, if a project sticks to the common ERC-20 they’ll generally be fine, the issue is when they want to get off the ERC-20 standard. If they wish to increase the security of their token or really improve it far beyond what the ERC-20 standard can do, they’ll have to work with every project they want to partner with and build out custom infrastructure just to deal with their new token standard. Cardano reduces this headache massively, allowing projects to not worry if their token will be available on DEX ‘XYZ’, and instead focusing on building their protocols.
ERC standards not being native tokens within the Ethereum ecosystem is important because it reduces overall network security, and stability because of the introduction of human error into the equation. Human error, as it relates to the ERC token concerns the skill and quality of the underlying assets’ code. Since an ERC token is not a native asset but a smart contract with its own internal ledger, it requires developers to write the code, whether simple or complex, and if the developers of the project lack the foresight to see potential problems with their token or aren’t rigorous with the testing of their token then it leaves the door open for error.
This error could range from inability to interact with certain smart contracts and DApp services like DEXs; to a flaw which siphons value from the token or prevents transacting with it — many issues are possible. Conversely, on Cardano, all of that is done away with as any CNT takes on the same security and safety of the original ADA token.
When projects create CNTs they are creating tokens explicitly, not smart contracts that require specific coding and planning to ensure they’re functional. This is a huge benefit to developers working on Cardano, because it allows them to focus their energies on writing their specific smart contracts and developing protocols, with less worrying about how bad actors might exploit flaws in their token code.
Furthermore, once the Alonzo hard fork occurs and smart contracts are fully accessible on Cardano, the door will be opened to deeper customization of CNT Monetary Policy scripts. Currently people are able to mint, burn, send and receive CNTs, but with the Alonzo hard fork that will increase the options for people aiming to create CNTs aside from the four aforementioned actions.
This is ground breaking, as even with these custom token policies that may be vastly different from project to project, they are still treated the same within the Cardano ecosystem. Add to this mix research by Professor Aggelos Kiayias, who has introduced the concept of ‘Babel Fees’, which essentially allow users to pay Cardano network fees in their preferred CNT — allowing users even more options for simplistic utility.
Conversely, on Ethereum you can transfer any token you like, but in the end gas is paid only with Ethereum. Instead, with Babel fees, so long as the CNT has some market value, users can use those to pay for the already minimal fees.
Conclusion
When it comes down to it, creating a CNT and developing on the Cardano blockchain is a much more streamlined process. It has less room for error and provides both the developers and users with a more efficient end product. It sets the project up to be prepared to scale from its inception, and makes it readily available to be used by any party within the Cardano ecosystem.
Now, with features like Occam’s ADA to ETH bridge, these benefits become accessible to other ecosystems and developers outside of Cardano. Creating a Cardano Native Token ensures a project is prepared to meet its future demands while laying a foundation of stability, robustness in the here and now.
Read more articles in the Occam.fi technical series below:
