Blockchain networks are complex data structures. Transactions continuously crisscross the chain, creating digital footprints that require careful tracking and management to maintain the integrity and reliability of the underlying ledger.

Two major accounting ledgers exist in the blockchain space: UTXO-based blockchains (Bitcoin, for instance), and Account/Balance chains (Ethereum, and others).

Each of these crypto heavyweights differs in many fundamental ways, but this article focuses on their accounting models. Bitcoin uses an Unspent Transaction Output (UTXO) model, whereas Ethereum deploys an Account/Balance one.

Cardano sought to combine Bitcoin’s UTXO model with Ethereum’s ability to handle smart contracts into an Extended UTXO (EUTXO) accounting model. The adoption of EUTXO facilitates the implementation of smart contracts into the Cardano chain.

What is a blockchain accounting model?

Every company, firm, or commercial entity requires a balance sheet to keep an accurate record of profit, loss, cash flow, and other parameters. By maintaining careful accounting of all this data, companies can, at a glance, visualize their financial status at any given point in time. A company's accounting ledger offers another advantage: The ability to trace the provenance and ownership of funds.

Blockchain networks also require an accounting model to determine who owns what coins (and how many of them), track where those coins go, which ones are used up, and which ones remain available to be spent.

UTXO model v Account/Balance model: A brief overview

Decades ago, accountants used physical ledger books with handwritten entries to keep records about the movement of funds. Nowadays, companies use electronic versions of the same thing. Blockchains use transactions as records (much like entries on a ledger book) to track provenance and ownership. These transactions contain a lot of information (where the coins come from, where they're going, and whatever change is leftover from these transactions).

Here’s a brief overview of the UTXO and Account/Balance models:

UTXO

In a UTXO model, the movement of assets is recorded in the form of a directed acyclic graph where the nodes are transactions and the edges are transaction outputs, where each additional transaction consumes some of the UTXOs and adds new ones. The users' wallets keep track of a list of unspent outputs associated with all addresses owned by the user, and calculate the users’ balance.

UTXO is, in many ways, similar to cash. A good analogy is this: Imagine you have $50 in your wallet. This amount could be made up with several combinations: two $20 bills and one $10, four $10 bills and two $5 bills, and many others. But regardless of the permutations, the amount ($50) remains equal. UTXOs work in the same way. Whatever balance you have in your blockchain wallet (say, 150 coins) could be made up with many different UTXO combinations, based on previous transactions, but the balance amount remains the same. In other words, the balance held in a given wallet address is the sum of all unspent UTXOs from previous transactions.

The concept of 'change' in UTXO models

Much like cash transactions in any store, UTXOs introduce ‘change.’ When you take out say a $50 bill from your wallet, you cannot tear that bill into smaller pieces to pay for something that costs $15, for example. You have to hand over the entire $50 bill and receive your change from the cashier. UTXOs work in the same way. You cannot ‘split’ a UTXO into smaller bits. UTXOs are used whole, and change given back to your wallet’s address in the form of a smaller UTXO.

The advantages of UTXO models

By checking and tracking the size, age, and amount of UTXOs being transferred around, one can extract accurate metrics about the blockchain’s usage and financial activity of the chain.

UTXO models offer other advantages. Better scalability and privacy, for example. Also, the transaction logic is simplified, as each UTXO can only be consumed once and as a whole, which makes transaction verification much simpler.

To sum UTXO up:

• A UTXO is the output of a previous transaction, which can be spent in the future
• UTXO chains have no accounts. Instead, coins are stored as a list of UTXOs, and transactions are created by consuming existing UTXOs and producing new ones in their place
• Balance is the sum of UTXOs controlled by a given address
• UTXOs resemble cash in that they use ‘change’, and are indivisible (UTXOs are used whole)

The Account/Balance model

As the name indicates, blockchain models that deploy an Account/Balance accounting model use an account (which can be controlled by a private key or a smart contract) to hold a coin balance. In this model, assets are represented as balances within users’ accounts, and the balances are stored as a global state of accounts, kept by each node, and updated with every transaction.

In many respects, Account/Balance chains (such as Ethereum) operate in a similar fashion to traditional bank accounts. The wallet's balance increases when coins are deposited, and decreases when coins are transferred elsewhere. The crucial difference here is that, unlike UTXOs, you can use your balance partially. So for example, if you have 100 ETH in your account, you can send a portion of that (say, 30 ETH) to someone else. The resulting balance will be 70 ETH remaining in your account, and the address where you sent the coins to will increase by 30 ETH. The concept of change does not apply in Account/Balance accounting models as it does in UTXO ones.

To sum up the Account/Balance model:

• This accounting model resembles how a bank operates
• Users have accounts that hold their coin balance
• It is possible to spent partial balances
• The concept of change does not apply

Tomorrow, in the second part of this analysis, we'll discuss how each model deals with transactions, explain the rationale for developing the EUTXO model for Cardano, and provide an in-depth explanation of what EUTXO is and how it works.

At the end of March, we’ll reach another milestone for Cardano when we’ll see d, the parameter that governs what percentage of transactions are processed by the genesis nodes, get to zero. At this point, responsibility for block generation will be fully decentralized. In other words, Cardano’s network of 1,800+ community pools will be solely responsible for producing blocks.

D=0 day will be a landmark moment in Cardano's continuing journey. When we deployed the Shelley update back in July 2020, d was set to an initial 1.0, meaning that every block was produced by IOHK’s network of federated nodes. Of course, this was the antithesis of decentralization but a wise (ie, secure) approach for the near term while the stake pool operator (SPO) network got up and running.

Preparing for d=0 day

Over time, we have gradually reduced d at a rate of 0.02 per epoch (in other words, an increase of two percentage points in community block production every five days). On the day this blog is published, we are at d=0.12 with 88% of blocks being produced by community pools and just 12% by federated nodes.

Simply put, as d decreases, more blocks are created by the community, and more stake pools can produce blocks. As d ticks down, the network's diversity and geographic distribution expands.

On March 31, at the boundary of epoch 257, d will reach zero. That day will be special because while d may be small, its significance is huge. In this context, that zero heralds the most important outward indicator of decentralization, a parameterized symbol supporting a core tenet of our philosophy – d=0 pushes power to the edges.

As we continue transitioning to full decentralization, it is also a good time to reference the other parameters governing the Cardano network’s evolution, and review some of the changes we have seen.

The d number is just one of more than 20 parameters that govern network operation and health. This set of parameters are ‘levers’ to manage and steer the effective and natural operation of a decentralized proof-of-stake system. The community will ultimately drive Cardano's evolution via Voltaire governance rules, but until then, it's our job to manage this set of parameters. Our guardianship requires that we make adjustments as required to build and sustain the health of the network.

Why the k parameter is special

Aside from more technical considerations, we remain committed to supporting smaller stake pools, because we believe this approach aligns with our long-term goal of creating the most decentralized and economically sustainable ecosystem of stake pools. This is further reflected in our delegation approach, which throughout 2021 will aim to support stake pool diversity.

Last year, we made the first significant adjustment to network parameters when we moved k from 150 (meaning a system optimized at launch for 150 block-producing pools, even though other pools could produce blocks) to k=500. This came about after extensive debate, both within IOHK and the Cardano Foundation and with the SPO community.

The move to k=500 was a balanced decision based on the need to create opportunity for more pools to produce blocks (by encouraging the flow of stake from saturated pools into new pools), while supporting the pools already creating blocks, and minimizing disruption for their delegators. Overall, it has proven successful – let's dive a little deeper.

The change to k=500

Prior to the announcement that k was changing, 54.6% of all delegated ada was represented by the 10 largest stake pools and 45.4% of ada represented by smaller pools. Following the change to k=500, those numbers have reversed: 55.9% of ada is now represented by pools other than the 10 largest.

This was a dramatic change directly linked to the change in k.

It is a great start, but our goal is to continue to optimize the network. So we observed what happened, gathered feedback, and incorporated everything we learned into making the next round of changes.

Pools will split when it makes economic sense to do so. For those pools with a greater proportion of pledge, the more pledge they have, the more valuable it is and the more reason SPOs have to keep their pledge together. Conversely, if a pool has a low level of pledge, there is very little reason not to split it further to start additional pools.

While there is a cost associated with running a small pool, and given the current appreciation in the value of ada, we believe that the financial incentive for splitting pledge is even stronger now. Increasing k – for example to 1,000 – without addressing this first, would not lead to a more distributed and diverse ecosystem which, to be clear, is the objective. We will simply see many of the same operators just running twice as many pools.

Changing pledge

The a0 parameter rewards SPOs for concentrating their pledge into a small number of pools. This has been effective in encouraging pools with high levels of ada pledge to consolidate that into large private pools (as we at IOHK do) and therefore give smaller pools greater opportunity to attract delegation.

However, we believe the current system can be improved, so for some time now, we have been discussing and modeling options to make pledge more effective at addressing pool splitting for lower pledge levels.

The current structure of the rewards formula does not give us the flexibility to tweak the impact by a simple parameter change; we will need to modify the rewards formula, which is something our research team has been working on for some time.

Several promising candidates have come out of that evaluation process. We’d like at this point to acknowledge the valuable work from community contributor Shawn McMurdo in his Curve Pledge Benefit improvement proposal for helping to develop the thinking in this area.

Our research team is in the late stages of finalizing an approach. They will soon present their findings, and we will update the community then. However, the team has now concluded that a0 should change. We believe this change will greatly benefit the network, making the system more sustainable, widely distributed, and globally diverse. It will also increase the earnings of all public pools (ie, those that are not already fully 'saturated' with pledge).

While it has been a matter of considerable internal discussion, we have also concluded that any change in k should come after changing the formula for a0 to deliver the desired results (especially encouraging stake to flow to smaller single pools rather than split pools). Since this is a full formula modification, and no longer a simple epoch boundary change, it needs to be released as part of a hard fork. Given our product pipelines and the team’s current focus on continuing the Goguen rollout and available dates, we will be looking to making this change in the third quarter of the year.

Other considerations

Other factors need to be considered. Chief among these is the availability of multi-pool delegation, to allow ada holders to spread their stake across a number of pools from a single wallet. This requires significant backend work from the core development team, along with a new interface and business rules adjustments. We would also like – if possible – to offer better pledging options for SPOs from Daedalus in a similar timeframe (currently only available via CLI or AdaLite), which means additional development work not only for internal teams but also for the Ledger and Trezor wallet companies.

We will also continue researching other parameters such as the minimum fees (implemented to prevent a ‘race to the bottom’ yet skewed against smaller pools) while continuing benchmarking and optimizing node performance as smart contract functionality rolls out. Our responsibility and commitment remains to achieve a delicate balance between the stability, scalability and overall health of the network with a flourishing ecosystem of pool operators and delegators.

Evolving into the future

As we promote the health of the network and stake pool ecosystem, we continue to monitor and research other important parameters and values. This work considers both the tactical and strategic approaches we may take.

With the increase in the price of ada, implementation of native tokens, and anticipating smart contracts, we also continue to assess and review the Cardano fee structure. For example, based on community feedback, we are considering the tactical approach of immediately lowering some fees. The minimum fixed fee of 340 ada for stake pools is one strong candidate for change; network transaction fees and deposits for smart contracts are also under discussion.

Our researchers and analysts are also working with an external economic consulting group to formalize an optimization approach that ensures fees will remain stable and predictable over the longer term. The results of this review will include a governance model with a clear mandate about when and how fees should be determined in the future as we develop, optimize and scale the network. We’ll be sure to keep the community informed and involved as our thinking develops.

I’d like to thank and acknowledge Francisco Landino, Lars Brünjes, Aikaterini-Panagiota Stouka, Aggelos Kiayias, and Tim Harrison for additional input to this article and feedback throughout this evaluation period.

At the end of 2020, we announced our devnets plan to support the longer-term strategic goal of opening up Cardano to multiple development languages – as outlined in the ‘‘Island, Ocean, Pond’ video. This week, building on the Ethereum Virtual Machine, we’re rolling out a new development environment to support the Glow language.

François-René Rideau of Mutual Knowledge Systems is the creator of Glow, a DSL that will allow anyone to write verifiable DApps from a single spec and deploy it on our EVM network. We caught up with Rideau (also known as Fare) to hear more about his vision for Glow and the Cardano journey so far. The following is a distillation of his thoughts from our previous interviews.

We first introduced the community to GLOW and MuKn at the end of last year when we announced our devnets approach –  but maybe you can remind us how you began working with IOHK?

I started as a researcher in formal methods for programming languages and distributed systems. But I wanted to build systems actually used by many, so I moved into the industry where I notably worked on proving the correctness of a centralized payment protocol and creating an airline reservation system. After a few years at Google and Bridgewater, I decided life wasn’t worth working under dysfunctional hierarchies, so I started my own cryptocurrency companies. Charles invited me to speak at the IOHK Summit 2019, and I realized how much I like the Cardano community: we have a similar focus on building robust software for the long term. That is why I wanted to port my domain specific language Glow to Cardano.

Tell us a bit why you started your company Mutual Knowledge Systems, or as you call it MuKn (Moon)?

Over three years ago, I was reviewing whitepapers. Most papers (about ¾) had interesting techniques but made no economic sense. Most of the rest (about ⅕) made economic sense but had no technical content. Only the top few (about 5%) actually made sense both technically and economically. At some point, I realized I could do better, so I designed a scaling solution using lessons learned from working on Tezos. Arthur Breitman challenged me to use smart contracts instead of trying to modify his protocol.

While trying to prove his challenge absurd, I instead found that he was right and I was wrong—and I finally understood why and how to use smart contracts. I started a company around the resulting scaling solution, raised money, pivoted into building the scaling solution after the language capable of generating it from specification, fought with and fired my then-partner, became my own CEO, started a new company, and, after much struggle, finally found the right founding team. Together, we built Mutual Knowledge Systems around this new programming language, Glow—designed to be much better than existing languages to write decentralized applications.

When you say ‘better’, what do you really mean?

Writing a DApp is the single hardest thing to do in the world. This is because you can’t afford a mistake, or your users may lose significant funds. Furthermore, you are not confronting random situations, but active adversaries bent on attacking your code, who will contrive the very worst case scenarios to exploit for their profit. Yet, unlike the military, you can’t hide your code or protect access to your networks: all the critical pieces are necessarily public. On top of that, extant programming tools are not designed for these constraints and even traditional formal methods lack essential concepts to express the issues at stake.

Thus, we decided to make new tools fit for the challenge. Our domain-specific language (DSL) drastically simplifies DApp development, by abstracting away all the common blockchain infrastructure, so you can focus on your problem domain (trading, derivatives, insurance, supply chain, etc.). Your DApps can be thousands of lines of code that your users can afford to audit, instead of millions of lines of code that require leaps of blind faith. And the programming model will enable developers, auditors and automated verification tools to reason at the level of abstraction of participants exchanging assets, rather than at that of packets of bytes shipped around the Internet.

What is it about Cardano and its community that appeals?

I started like everyone else, on Ethereum, because its ecosystem is already mature. However, the Ethereum community has this attitude of building as fast as possible experiments that are good enough for now, but lack conceptual integrity and won’t last; I see a lot of value in that approach and have tremendous respect for those who can thrive this way—for I cannot. When I met the Cardano community, I felt much more at home because we share a common attitude. We want to do things that are correct by construction and will keep working in the long term. We build concrete towers on the bedrock, not stick shacks on the sand. At times, this can be frustrating because things go slow, but I am happy with the attention to detail and quality in the development of Cardano. Is it perfect? No, it’s not. But it’s got great fundamentals.

Can you talk about how you hope Glow will change the DApp developer experience?

Glow is portable. Today it works on Cardano and Ethereum but in the future it will work with any blockchain that is sufficiently advanced to support smart contracts. That means that you can write your DApp once and it will run on whichever platform has the users and the liquidity you seek. You don’t have to make a guess about where liquidity will be in the future then sink heavy investments to develop on a single chain that you bet your house on.

With Glow, developers can run their DApps on all blockchains. Glow will commoditize blockchains. Blockchains will then compete on technical and economic merits, not on user lock-in and inertia. And the value brought to users will increase.

What can the community expect from Glow?

We have launched this early version of Glow on the Cardano EVM Devnet with a command-line interface. In many ways, it is not yet ready for use by end-users, but it can already demonstrate simple applications. Users can also see how they may write a 6 line application in Glow that would require hundreds of lines in a combination of Solidity and JavaScript. We have a roadmap over the next few months to add a lot of features: from ERC20 tokens (and, on Cardano, native tokens), to generalized state channels, to a web interface, to a more robust runtime, etc. Eventually, we want to become the development environment for all blockchain projects. And Glow is of course an open source software open to the community.

We’re rolling out the integration with Glow with our EVM and devnet program, so what are some of the benefits of this?

The Cardano EVM side-chain will enable arbitrary contracts to run on Cardano that use the mature EVM platform, without waiting for Plutus to deliver its promise, to achieve feature-parity, to be considered stable, etc. And Glow can run on this EVM side-chain and provide the simplicity, safety and portability in DApp development that were not available before.

What is the rollout process like and how can our community get involved if they want to?

Glow is still in development. There are some things that it can do already and some it can’t do yet. We invite DApp developers to join the Glow community and use the language for what it can already do, and otherwise help us build the blockchain development environment of the future. You can build the missing features you need yourself, or contract MuKn to build them for you. Even if you can’t code and have no budget, you can help write the documentation, or even just tell us where it isn’t clear yet, or what features you need most so we know what to prioritize. Together, we can build great DApps that you just couldn’t have achieved safely and within budget with previous tools.

If you’re a developer, we encourage you to get involved with Mutual Knowledge Systems and Glow. See our full conversation with François-René Rideau and a demonstration of Glow during Cardano360.

In Douglas Adams' classic The Hitchhiker's Guide to the Galaxy, a Babel fish is a creature that allows you to hear any language translated into your own. This fantasy of universal translation ensures meaningful interaction despite the myriad different languages in the galaxy. 

In the cryptocurrency space, smart contract platforms enable the development of a myriad custom tokens. Is it possible to interact with the platform using your preferred token? If only there was a “Babel fees” mechanism to translate the token you use to the one that the platform requires for posting a transaction. 

Common wisdom in blockchain systems suggests that posting a valid transaction must incur a cost to the sender. The argument is that, without such constraint, there is nothing to stop anyone from overloading the system with trivial transactions saturating its capacity and rendering it unusable. Given the above tenet, a frequently made corollary is that in any blockchain system where user-defined tokens are supported, it should be prohibited to pay transaction fees in such tokens. Instead, transactions should carry a fee in the native token of the platform that is accepted by all participants as being valuable.  Arguably such a restriction is undesirable. But how is it possible to circumvent the ensuing – and seemingly inevitable – vulnerability? 

The art of the possible

Cryptography and game theory have been known to make possible what seemed impossible. Celebrated examples include key exchange over a public channel, Merkle's puzzles, and auctions where being truthful is the rational thing to do, like Vickrey's auctions. And so it also turns out in this case. 

First, let us recall how native assets work in Cardano: Tokens can be created according to a minting policy and they are treated natively in the ledger along with ada. Cardano's ledger adopts the Extended UTXO (EUTXO) model, and issuing a valid transaction requires consuming one or more UTXOs. A UTXO in Cardano may carry not just ada but in fact a token bundle that can contain multiple different tokens, both fungible and non-fungible. In this way it is possible to write transactions that transfer multiple different tokens with a single UTXO. 

Transaction fees in the ledger are denominated in ada according to a function fixed as a ledger parameter. A powerful feature of Cardano's EUTXO model is that the fees required for a valid transaction can be predicted precisely prior to posting it. This is a unique feature that is not enjoyed by other ledger arrangements (such as the account-based model used in Ethereum). Indeed, in this latter case the fees needed for a transaction may change during the time it takes for the transaction to settle, since other transactions may affect the ledger's state in between and influence the required cost for processing the transaction. 

A thought experiment

Let's consider the following thought experiment to help us move closer towards our objective of Babel fees. Imagine that it is possible to issue a transaction that declares a liability denominated in ada equal to the amount of fees that the transaction issuer is supposed to pay. Such a transaction would not be admissible to the ledger. However it can be perceived as an open offer that asks for the liability to be covered. Why would anyone respond to such an offer? To entice a response, assuming the token bundle concept already present in Cardano,  the transaction can offer some amount of token(s) to whoever covers the liability. This suggests a spot trade between ada and the offered token(s) at a certain exchange rate. Consider now a block producer that sees such a transaction. The block producer can create a matching transaction absorbing the liability covering it with ada as well as claiming the tokens that are on offer. 

By suitably extending the ledger rules, the transaction with the liability as well as its matching transaction become admissible to the ledger as a group. Due to the absorption of the liability, the set of two transactions becomes properly priced in ada as a whole and hence it does not break the ledgers' bookkeeping rules in terms of ada fees. As a result, the transaction with the liability settles, and we have achieved our objective. Users can submit transactions priced in any token(s) they possess and, providing a block producer is willing to take them up on the spot trade, have them settle in the ledger as regular transactions!

A concrete example

The mechanism is of course conditioned on the presence of liquidity providers that possess ada and are willing to issue matching transactions. In fact the mechanism creates a market for such liquidity providers. For instance, a stake pool operator (SPO), can publish exchange rates for specific tokens they consider acceptable. For instance an SPO can declare that they will accept tokenX for an exchange rate 3:1 over ada. It follows that if a transaction costs, say ₳0.16, the transaction can declare a liability of ₳0.16 as well as offer 0.48 of tokenX. In the native asset model of Cardano this can be implemented as a single UTXO carrying a token bundle with the following specification (Ada→ -0.16, tokenX→0.48). Note the negative sign signifying the liability. 

Suppose now that the SPO is about to produce a block. She recovers the liability transaction from the mempool and issues a matching transaction consuming the UTXO with the liability. The matching transaction transfers 0.48 of tokenX to a new output which is owned by the SPO. The resulting block contains the two transactions in sequence. The matching transaction provides the missing ₳0.16 in addition to the fees that are needed for itself. In fact multiple transactions can be batched together and have their fees covered by a single matching transaction. 

Figure. Alice sends a quantity of 9 tokens of type X to Bob with the assistance of Stacy, an SPO, who covers Alice's transaction liability and receives tokens of type X in exchange. The implied exchange rate between X and Ada is 3:1. 

New measures of value

The above process is entirely opt-in for SPOs. Each one can determine their own policy and exchange rate as well as decide to change the exchange rate for the various tokens they accept on the spot. Moreover, there is no need for agreement between SPOs about the value of a specific token. In fact, different SPOs may provide different exchange rates for the same token and a user issuing a liability transaction can offer an amount of tokens corresponding to the minimum, average or even maximum of the posted exchange rates in the network. In this way, a natural trade off arises between settlement time of liability transactions and the market value of tokens they offer. 

This illustrates how native assets, the EUTXO model, and the simple but powerful tweak of introducing liabilities in the form of negative values in token bundles can accommodate Babel fees empowering users to price transactions in any token supported natively by the system. It also shows the unique advantage of being an SPO in such a system. It should be noted that SPOs need not be the only entities in the network offering to cover liabilities. In fact, an SPO can readily partner -if they wish- with an external liquidity provider who will be issuing the matching transactions. In addition, third party providers can also act on the network independently and issue matching transactions. Nevertheless, the benefit will remain with the block producers; SPOs can always front-run matching transactions and substitute them for their own if they wish so. This is a case that front-running transactions is a feature: it makes it feasible for SPOs to be paid in the tokens they prefer for their transaction processing services.

The mechanism of negative quantities in token bundles can be implemented in the basic ledger rules of Cardano at some point following the introduction of native assets with the Mary Hard Fork. Beyond Babel fees, the mechanism allows a variety of other interesting applications, such as atomic swaps for spot trades, that we will cover in a future blog post. It is yet another illustration of the power of Cardano's approach and its ability to support a diverse and entrepreneurial community of users and stake pool operators. 

I am grateful to Manuel Chakravarty, Michael Peyton Jones, Nikos Karagiannidis, Chad Nester and Polina Vinogradova for helpful discussions, suggestions and comments related to the concept of Babel fees and its implementation in the Cardano ledger. We also have a video whiteboard walkthrough covering this topic.

With the ‘Mary’ protocol upgrade, which will be implemented using our hard fork combinator technology, native tokens and multi-asset capability are coming to Cardano.

On February 3, we upgraded the Cardano public testnet to ‘Mary’ for final testing. We plan to deploy the Cardano update proposal to mainnet on February 24, which would therefore deploy ahead of the boundary of epoch 250 and take effect on March 1. If we need a few more days of testing, we'll deploy ‘Mary’ the following epoch instead, which will take a five-day period required for updates to take effect. ‘Mary’ has been successfully running on our testing environments for several weeks, so our confidence level remains high. As always, however, we’ll follow a strict process (developed and honed over the previous Shelley and Allegra HFC events) to get this right.

Once the code is successfully deployed to mainnet, we’ll release a new Daedalus Flight version for user testing, which will be our first Cardano wallet with integrated multi-asset capability. Once we are happy with wallet performance and usability, we’ll deliver the Daedalus mainnet release bringing the full-fat native token experience to every Cardano user.

Why native tokens?

Native tokens will bring multi-asset support to Cardano, allowing users to create uniquely defined (custom) tokens and carry out transactions with them directly on the Cardano blockchain.

The use of tokens for financial operations is becoming ever more popular. It can cut costs at the same time as improving transparency, enhancing liquidity, and, of course, being independent of centralized entities such as big banks. Tokenization is the process of representing real assets (eg, fiat currencies, stocks, precious metals, and property) in a digital form, which can be used to create financial instruments for commercial activities.

Cardano will provide many tokenization options. With the ‘Mary’ upgrade, the ledger’s accounting infrastructure will process not only ada transactions but also transactions that simultaneously carry several asset types. Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. This means that the accounting ledger will track the ownership and transfer of assets instead, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency.

Future and utility

Developers, businesses, and applications can create general purpose (fungible) or specialized (non-fungible) tokens to achieve commercial or business objectives. These might include the creation of custom payment tokens or rewards for decentralized applications; stablecoins pegged to other currencies; or unique assets that represent intellectual property. All these assets can then be traded, exchanged, or used as payment for products or services.

Unlike ERC-20 tokens that are based on Ethereum smart contracts, the tracking and accounting of custom tokens on Cardano is supported by the ledger natively. Because native tokens do not require smart contracts to transfer their value, users will be able to send, receive, and burn their tokens without paying the transaction fees required for a smart contract or adding event-handling logic to track transactions.

Working with native tokens on Cardano

In creating an environment for native tokens, we have focused on simplicity of working, affordability, and, of course, security.

Depending on their preferences and technical expertise, users will be able to choose from three ways to create, distribute, exchange and store tokens:

• Cardano command-line interface (CLI). Advanced users can currently access the CLI via a dedicated testing environment. We will deploy the CLI on the mainnet when we hard fork.
• A ‘token builder’ graphical user interface (GUI). This will follow the native token CLI launch, providing an easier way for creating tokens.
• The Daedalus wallet. Daedalus will provide support for sending and receiving custom-created tokens. Daedalus Flight will test native token functionality in March, which will be shortly followed by the mainnet release.

Let’s dig down a little into each option.

Working with Cardano CLI

Advanced developers can use the native tokens testing environment to create (mint) assets and send test transactions to different addresses.

The nature of working with the CLI assumes that someone is familiar with setting up and operating the Cardano node, and has experience in working with transactions and managing addresses and values. To create native tokens using Cardano CLI, one would need to:

• Set up and start the Cardano node
• Configure a relay node to connect to the native tokens testing environment
• Start interaction with the network (prompt Cardano CLI)
• Construct a monetary policy script
• Create tokens using the monetary policy script
• Finally, submit and sign transactions to transfer tokens between addresses.

Native token tutorials and exercises are available on our Cardano documentation site to help developers mint tokens, create monetary policies, and learn how to execute multi-asset transactions.

We are already seeing particular interest from stake pool operators for this. So far, hundreds of test tokens have been created, and we continue to improve the CLI based on feedback. We welcome your comments and encourage community testing.

Token builder: a user-friendly GUI for token creation

The CLI requires a certain level of development prowess. So we have devised other ways for less technically proficient users to create tokens. To achieve this, we plan to launch a token builder after the mainnet CLI launch.

The token builder is a graphical user interface that makes token creation easier. If you’re interested in creating tokens for your decentralized application, wish to tokenize your property, create NFT collector cards represented as specialized assets, or want to create a stablecoin pegged to the value of other currencies, the token builder can help with that.

To create a token you would just need to fill in:

• The token name (eg, Hello World)
• The token symbol (eg, HEW)
• The token icon (generated automatically)
• Amount to create (eg, 1,000)
• Cardano wallet address (your address to host newly created tokens).

The token builder generates the monetary policy automatically – you won’t need to define it yourself. This streamlines the token creation and simplifies it for a non-technical user.

Figure 1. The prototype token builder dashboard

Initially, the token builder will be supporting only fungible token creation (while non-fungible tokens can be created using Cardano CLI). In time, we’ll extend the functionality to allow creating non-fungible tokens and changing the monetary policy according to specific preferences. This means that users will be able to specify the conditions under which tokens are minted (or burned), or who has control over the asset supply, for example.

Finally, when tokens are minted, it will be possible to mint more by clicking the ‘Mint more’ button. This can be done based on the same policy to create more tokens of the same kind, or you can create other tokens that represent different values based on a different policy. For example, you can create more Hello World tokens, or, starting from scratch, you can create 500 ‘test’ tokens that will be used for other purposes (these will have a different minting policy).

The token builder aims to reduce the complexity of token creation and also focuses on the enhancement and visual presentation of functional processes. As an outcome, we aim to provide visibility around all the tokens created, their values, quantity, and addresses between which they are being transferred – all in one place.

Daedalus

Those users who do not wish to create their own tokens but who want to use existing ones for payments, purchases or exchange, will be able to use such wallets as Daedalus, and later Yoroi.

The Daedalus team continues to work on integrating the wallet backend with the user interface to support the native token functionality. Users will be then able to hold native tokens in their wallets, send and receive them as they would do with ada.

Native tokens are uniquely identified by two hexadecimal numbers stored on-chain ‒ the Policy ID and the Asset Name. Considering that these numbers are not 'human-friendly', we have created fingerprints for easier identification of native tokens by users. Fingerprints are 44 character long alphanumeric strings beginning with the prefix 'token'.

Additional token data displayed in the wallet UI (name, description, and acronym) will be provided by the Cardano token registry, administered initially by the Cardano Foundation.

Figure 2. Daedalus native tokens UI

Native token lifecycle

When all the necessary components are deployed, the native token lifecycle will be complete. It consists of five phases:

• minting
• issuing
• using
• redeeming
• burning.

Figure 3. Native token lifecycle phases

During these phases, asset controllers will be able to define the policy for the asset class and authorize token issuers to mint or burn tokens. Token issuers can then mint tokens (for applications, for instance), maintain their circulation, and issue them to token holders. Finally, token holders (eg, individual users or exchanges) will be able to send tokens to others, use them for payment, or redeem them when they have finished using them.

What’s next?

We launched the testing environment in December 2020, laying the foundation for native token development. We also added a staging environment to enable initial testing by exchanges and stake pool operators. It features a faucet and allows a network of nodes to be built while connecting to the relays.

Follow our Cardano status updates to see our weekly progress. As we expand the capabilities of the native tokens, and add tools and interfaces, we’ll be providing documentation and tutorials to encourage people to get involved. Naturally, the codebase is open source and we have already seen a number of interesting community projects emerge (around digital collectibles, for example).

So a lot will be happening in late February and early March, from final testing and the HFC event, to native tokens on Cardano within a brand new Daedalus wallet experience. Exciting times ahead!

Find out more by joining other community members to discuss native tokens in the Cardano Forum's dedicated native token section. And don't forget to sign up for our devnets program.

Additional technical input by Olga Hryniuk.