Native tokens on Cardano; core principles and points of difference
In yesterday’s post, we looked at the purpose and value of tokens on Cardano. Here, we dig deeper into the four principles guiding our approach, and the key advantages
9 December 2020 Polina Vinogradova 5 mins read
Ethereum, custom (user-defined) tokens are implemented using smart contracts to simulate the transfer of custom assets. Our approach with Cardano does not require smart contracts, because the ledger itself supports the accounting of non-ada native assets.
Another difference is that Cardano’s multi-asset ledger supports both fungible and unique, non-fungible tokens without specialized contracts (similar to those required by ERC-20 and ERC-721 tokens). It can store a mix of both fungible and non-fungible tokens in a single output.
Cardano’s native tokens framework is based on four principles:
- unified process
The native token framework is based on a multi-asset ledger structure built around token bundles (values), A token bundle can contain a heterogeneous mix of ada and other tokens. These token-containing structures are stored in outputs on the ledger instead of ada, as previously. Each type of token is identified by its asset ID, which includes a hash reference to its minting policy. The minting policy itself is only ever checked during minting or burning, and is not itself stored on the ledger, which makes this approach quite lightweight.
The fungibility relationship is also captured by the asset ID in a lightweight way: tokens with the same asset ID are fungible with each other, but not fungible with those with a different asset ID. Unique tokens have a quantity of exactly 1 associated with their asset ID.
The asset ID identifies each type of token within a single token bundle and across the whole ledger. It also identifies the token’s place in the internal two-level map structure of the token bundle. This internal data structure enables fungible and non-fungible tokens to be represented uniformly. It also gives great flexibility to the kinds of asset use cases that can be tokenized in the system. It is straightforward to represent, for example, timeshares of a single piece of property, or a selection of unique pieces of art scoped under a single minting policy controlled by the artist.
The inherent simplicity of native tokens is further highlighted when we look at how transferring assets between two contracts works in Ethereum’s ERC-20. In this situation, smart contract code is required, which adds complexity, and with it room for error and cost. The structure of token bundles offers a rather lightweight approach to asset transfer, because different types of token can be transacted in a single transaction, with greater speed.
In an ERC-20 token environment, transferring any number of tokens between two peers requires the execution of a smart contract, which carries an execution fee (gas). By contrast, in Cardano’s native multi-asset ecosystem, the transfer of assets (tokens, ada, custom currencies, etc) does not require a smart contract, and does not carry any execution fee, which means greater affordability.
Native tokens feature a more lightweight and less costly design than that of Ethereum’s ERC-20 and ERC-721 standards. But these two features would mean nothing without a robust security layer to guarantee the integrity of the system.
In native tokens, system integrity is built around the ledger property of value preservation (that is, that the sum of all the inputs is equal to the sum of the outputs). All native token transfer logic is coded in the ledger, as opposed to user-defined smart contracts. This ensures predictable and uniform behaviour of the system, and does not require users to understand smart contracts, which can often be a point of vulnerability.
While accounting correctness is ensured by the ledger, minting and burning of tokens is regulated by their user-defined minting policies. A minting policy is permanently hash-associated to the tokens scoped under it, and there is no way to change this policy. This guarantees that the policy an issuer chose can never be changed to allow minting or burning of this type of token which was not authorized under the original policy. Whenever a minting transaction is added to the ledger, the policy for each type of token being minted is checked and must be satisfied. Each token in circulation, except ada (as Cardano forbids minting additional ada), necessarily has a minting policy and is guaranteed to have been minted according to that policy.
Therefore the only custom code required to manipulate tokens in Cardano is the policy itself. Tying the policy hash to the asset identifier means that there is no need for a global asset registry, so creating assets is cheap and easy. The system remains simple, lightweight and easy to use.
When native tokens are implemented as part of Goguen, the ledger will handle all tokens in the same way. And minting a token can only be done in one way, to reduce ambiguity and possible mistakes or bugs. This simplification in using a unified process will lead to faster development and a better development experience overall.
Pre-production environment incoming
Native token capability will be deployed to the Cardano mainnet following a protocol upgrade in Q1 2021 (known internally by the working name, ‘Mary’) opening up a new world of use cases and opportunity. To onboard new developers ahead of this date, we’re now finalizing the deployment of a pre-production environment for native tokens. So stay close to our social channels for the very latest news on deployment.
If you are a developer and want to get involved early on, visit our developer site, where you can get supporting documentation and resources. We’ll add to this over time; sign up to our developer survey on this page to express your interest and be alerted as soon as everything becomes available.
I started with IOHK in May 2018 as a formal methods developer working on two components of Cardano, neither of which involved writing Haskell code. Because of my expertise in logic, type theory, proof assistants, and theoretical computer science, I became part of the team without having much Haskell experience, even though it is the main language we use. So, I was surprised when my name came up last summer about who would be the teaching assistant for a Haskell course in Ethiopia this year. I had thought I would be a student, but then it became clear that loftier plans were being proposed for me.
While there were other qualified candidates, I imagine not everyone was willing to relocate to Africa for three months. Also, the Ethiopia 2019 class was distinguished from previous versions of the course because it was only open to women. For this reason, the idea of having a female assistant seemed particularly relevant. So, I found myself getting ready to learn, present in class, and assess material that was new to both me and the cohort of students from Ethiopia and Uganda!
I was living in Canada, and had yet to meet any IOHK employees in person. I knew little about Ethiopia. So, I got my inoculations, my one-way ticket — I was not sure when the course was scheduled to end and how much longer I was expected to stay on afterwards — my visa (with my name spelt wrongly), and headed off to Africa for the first time in my life.
Once I got to Addis Ababa, the thing that stood out was the amount of livestock in parts of the city. Donkeys, cows, and goats were grazing, carrying heavy loads, and wandering about the streets. After the first drive through Addis, Lars Brünjes, director of education at IOHK, and John O’Connor, director of Africa operations, and I sat down for a cold drink at the hotel where Lars and I were staying. We had some laughs, talked a bit about ourselves and the course, and it began to seem as if I would be very happy working with my colleagues here for three months — what a relief.
From the first day until the last, which was almost three months, I was really engaged with both the students and the material. The course started at the Ministry of Innovation and Technology and the students showed incredible perseverance. Two had to drop out in the first week, but the rest stayed on, no matter how challenging it got — and no matter the transportation time to class given the crazy Addis traffic!
Most of the students had a computer science degree, some also had a master’s or work experience. However, Haskell is different from anything they would have learned or used before. There were some difficult concepts to grasp, but Lars did an awesome job breaking down the material and providing plenty of relevant examples (as many as the students wanted, which was a lot).
There is a saying that the best way to understand something is to teach it. For me, this was true for the entire duration of the course. I learned a lot, answering questions, delivering lectures, grading work, and especially making up the questions and answers for the final test. It was a special treat to learn about smart contracts, Marlowe, and Plutus in the last two weeks, too — new material for me and a great addition to the course. This part was taught by Phil Wadler, one of the creators of Haskell, and at the very end he delivered a special lecture on propositions as types, which was particularly engaging and open to a wider audience than just the students — it was a very nice way to end the class.
Throughout the three months, but especially at the beautiful graduation ceremony, I really felt the importance of what we were doing — giving people the skills and tools to address their problems locally. The best part was getting to know the wonderfully enthusiastic students and watching them develop their skills in this unusual and interesting programming language. I look forward to having the opportunity to work with some of these women in the future. Finally, getting to know my IOHK colleagues as we arrived in Ethiopia was a real treat as well!
Read Lars Brünjes's blog - Training blockchain developers in Africa