Cardano is well-designed for what it wants to become

Published 5.5.2023, updated 10.5.2023

I was just looking at the new Bitcoin standard for token minting and transfer, BRC-20. I have to admit that I don't like it technically at all. We'll get to the details in the article. It made me realize how important it is when innovation is wanted and well thought out. The IOG team could have learned from the Ethereum project and designed the functionality around tokens in a different way. Many members of the Bitcoin Core team did not want to enable NFT and token minting at the first layer. Yet, one Core developer from the team managed to deliver this functionality. I'm sure you've heard of the Ordinals project. Unfortunately, the resulting solution is more of a hack (some talk about source code abuse) than a well-thought-out design. BRC-20 looks to me like another hack built on a hack. Cardano, and Ethereum as well, have a few years ahead of Bitcoin when it comes to minting and token transfer. In my opinion, Bitcoin should not catch up with SC platforms and should remain simple. From a governance perspective, the Ordinals and BRC-20 project is a very interesting topic to study, as tokens on Bitcoin are a controversial topic that divides the community. In this context, it is important to realize the importance of CIP-1694.


The Ordinals project can be seen as a betrayal by the part of the community that wanted Bitcoin to be only a store of value and nothing else. Freedom is not the same as the inability to agree on the best possible solution. On-chain governance is essential to the mission of blockchain projects. The team must serve the community. In the context of the Ordinals, I see CIP-1694 in a new perspective.

When innovation is wanted?

Cardano has been built from the start as a social and financial platform for which the ability to mint and transfer tokens is essential. The IOG team thought carefully about the design of this functionality.

Cardano employs a so-called multi-asset ledger. It means that tokens and NFTs are stored directly in the ledger similar to ADA coins. Cardano has an accounting infrastructure for assets defined directly in the ledger model and can transfer tokens and NFTs natively. It is easy to track the ownership of assets or to audit them.

You can easily think of the newly minted tokens as separate digital units that exist alongside ADA coins and other tokens. No smart contract is required for token minting and transfer. This has many advantages, for example, transaction fees are cheaper than if a smart contract were required. Transferring logic cannot be customized as it is part of the protocol. All tokens are transferred in the same way. There is no unexpected behavior. It is not possible that the issuer of tokens accidentally introduced a bug.

Users work with tokens in exactly the same way as with ADA. They can insert multiple tokens into a single transaction and send them to multiple recipient addresses. The total transaction size and fee are smaller than if the tokens were sent individually.

When people want to mint fungible tokens on Ethereum, they can use ERC-20, ERC-721, or ERC-1155 standards. They are essentially smart contracts that define a common list of rules that Ethereum tokens should adhere to. Minting is usually done in a copy-paste of a chosen smart contract. A customized and deployed smart contract is then used each time tokens move from address to address. Transaction fees are more expensive due to contract usage. The advantage is that specific rules can be defined for a given token type.

Both approaches have advantages and disadvantages for specific purposes. The big advantage is that both projects allow the use of smart contracts to interact with digital assets (in the case of Ethereum, this is necessary) and the teams are trying to improve scalability at the first layer.

In the case of Bitcoin, tokens are not self-existing digital units, a smart contract cannot be used at the first layer, and the team does not plan to address Bitcoin's scalability. From a user's point of view, this brings many problems.

Ordinals and BRC-20

Let's first take a look at how NFTs and tokens work on Bitcoin.

The project has two layers, let's call them Ordinals and Inscription. The Ordinals layer is a system that assigns a sequential number to each Satoshis. This allows them to be tracked and transmitted. Satoshis are numbered in order of mining. The Satoshis thus get a kind of ID to which they can be assigned the content that is in the imaginary second layer, the Inscription.

The individual Satoshis are fungible and the project does not violate this principle. However, if you accept the Ordinals numbering, they become non-fungible tokens.

A Bitcoin transaction contains a Witness part into which any content can be inserted. This space was originally reserved as a repository for digital signatures. Separating the signatures from the transactions allowed for more efficient use of block space. The SegWit part has a size limit of 4 MB. All of this space can be used by a single Taproot input. So this is also a limitation for the maximum size of the inserted media content (image, file, or other digital media content).

Inscriptions use the Taproot updates. The data is saved via the Taproot spend script. SegWit has relaxed the limit on signature size (witness) and Taproot has made it easier to store arbitrary data in a Bitcoin transaction. The author of Ordinals thus made use of the old OpCodes, namely OP_FALSE, OP_IF, and OP_PUSH. He created something called an envelope for storing arbitrary digital media content.

Let's add that unlike data added to a transaction via OP_RETURN, the fees for data in the Witness part are up to 4 times lower.

Ordinals basically link the sequential number (ID) of a given Satoshi to the content in the Witness section. The digital content will forever remain stored in the Bitcoin blockchain. The combination of both layers allows using Satoshis to create unique (non-fungible) pointers to any digital content in the blockchain.

BRC-20 is an experimental fungible token standard that uses Ordinals and Inscriptions. Storing JSON data in the blockchain is used for minting and token transfer. In order to find the current balance of tokens at each address, it is necessary to aggregate all JSON data and extract the information from it.

The JSON data entry is used for the initial mint of tokens to the owner's address. Additional JSON data writing is required for every token transfer. Bitcoin transactions are used for all JSON data writes. In order to use the tokens, users need an Ordinals-compatible wallet.

Does this sound like a good design? The Bitcoin Core team didn't want to have tokens on Bitcoin. That is why it actively prevents some innovations. Tokens cannot be transferred through transactions directly like Cardano can do, but user data with specific meanings need to be snuck in. The Bitcoin protocol does not support Ordinals or BRC-20, which means the new features are clunky.

Although the author of BRC-20 warns that this is just an experiment, the token mania on Bitcoin is gaining momentum. Tokens on other platforms work very well and have stood the test of time. On Bitcoin, this is a new feature that will probably be of no interest to the Bitcoin Core team and they may even actively hinder further development. I don't expect tokens on Bitcoin to have a chance of mass adoption as technologically the current solution is years behind SC platforms. If tokens are going to be on Bitcoin, the team needs to start supporting this and allow for the development of other technologies and standards.

Projects, including Cardano, will always have better options in terms of minting and token transfer, basically for the very reason that the team is thinking about how to design it in the best possible way.

What I don't like about tokens on Bitcoin

SetWit and Taproot updates were not intended as an option for storing user content in Bitcoin. The developer essentially abused these features to create Ordinals. He created his own Satoshi numbering to get around the inability to create dedicated tokens. This made it possible to link Satoshi to specific content on the blockchain.

Satoshis have a dual meaning. They still have their BTC value, but alongside that, they can also be a token. I don't like this duality and I think there should be two unique digital assets with clearly defined meanings.

The Witness part is used by the Lightning Network (LN) to open and close channels. Ordinals thus interfere with this key functionality for Bitcoin. LN users will fight for block space with the authors of NFT and BRC-20 tokens. At the time of writing, it is recommended to pay ~10 USD to get a regular Bitcoin transaction into the blockchain within 6 blocks.

The teams of all smart contract platforms are striving for higher scalability, as expensive fees and long settlement times are not acceptable from a user perspective. Thus, the Bitcoin team may be forced to start solving a problem they want to solve at another layer. If the design is well thought out, block space can be better saved and functionality can be efficient in the maximum possible way. This is critically important in protocol design.

Writing NFTs (or other content) directly to the blockchain is not very smart. The author says he likes this solution much better than using tokens with a link to another repository. The link is immutable, but the data in the repository can be deleted or changed. From my point of view, this has other solutions. For example, the owner of the NFT can store the image on his computer and there can only be a hash of the data in the token. A minimum of data should always be stored in the blockchain as it is not a database. Ordinals have essentially made Bitcoin a very inefficient database.

Using JSON data to write the contents of BRC-20 transactions is very inefficient in terms of space requirements. Dozens of Bytes must be used for the information for which roughly 10 Bytes is sufficient. Protocols should transfer the minimum amount of data with the maximum amount of information possible. That's what standards are for, to define transaction formats. By following a specific format, everyone understands the content. BRC-20 is very inefficient.

NFTs and BRC-20 tokens have much less use than digital assets on SC platforms, as it is almost impossible to create regular DeFi services and marketplaces without smart contracts. A USD-backed stablecoin can now be minted on Bitcoin, but it will not be possible to create a DEX that would allow users to swap BTC with USDT. In many cases, tokens need decentralized applications for meaningful use.

Bitcoin does not natively support tokens, so on-chain validation is not possible. All operations with JSON data take place off-chain.

Anyone running a full node must download all existing NFTs and tokens. If it is a relay node, i.e., a node that redistributes blocks over the network, it must keep the Witness data.

Bitcoin has always been seen as a project where the team will innovate slowly and conservatively to avoid any unintended mistakes. The Ordinals project has rewritten history and delivered functionality that a significant portion of the community never wanted on Bitcoin. Part of the community argues that Bitcoin is free and that anyone can do whatever they want. Therefore, the Ordinals project should stay on Bitcoin. The other part of the community and a significant part of the Core team argues that this is an attack on Bitcoin.

NFTs and tokens allegedly threaten the project's original mission of becoming a store of value and, over time, a medium of exchange. This goal may be more difficult to achieve if the fast and cheap sending of BTC is hindered by the use of tokens. On the other hand, miners are happy for higher rewards and new functionalities can save the declining security budget.

What can be done at this point?

The importance of decentralized governance

The Ordinals project may be seen as a betrayal by the part of the community that wanted Bitcoin to be a store of value and never anything else. Is this mission in jeopardy if Bitcoin gradually becomes a platform? There is no clear answer to this now.

This brings us back to Cardano and on-chain governance. From my perspective, it is important that the mission of a decentralized project is in line with what the majority of the community wants. Most members of the Cardano community know the mission of the project and know that smart contracts and tokenization are an integral part of adoption. The IOG team is doing exactly what most of the community expects. Innovation and technological advancement have been in the DNA of the project from the very beginning.

To keep it that way and to prevent the community from finding itself in a similar situation as the Bitcoin community is in now, it is important to clearly define who is responsible for what and who decides what.

Freedom and the inability to agree and make a majority decision are two different things that the Bitcoin community may misinterpret as the same thing. My perception of the situation is that part of it wants to prevent the existence of Ordinals, while the other part does not. Because it is impossible to agree, many Bitcoiners talk about the right of Ordinals to exist (in the name of freedom), but at the same time wish for the end of this project.

In my view, new functionality must be developed in the context of other changes and capabilities of the protocol. The team must think about decentralization, security, economic sustainability, the project mission, and many other things. Unexpected changes can shatter all existing concepts. That's why projects like Ordinals can be seen as an attack on Bitcoin. The interests of the team and the community must be aligned. It is dangerous if someone is able to abuse some functionality and thus change the functioning of the protocol.

What makes Cardano fundamentally different from other projects is the ability of the community to make decisions through on-chain governance. If it ever happens that a project's mission is compromised, either by someone abusing a feature of the protocol for something the majority of the community doesn't want or by other problems with decentralization or the security budget, it's important to make the right decision that the majority agrees with.

CIP-1694 is the first step into the Voltaire era. Cardano needs to be what the ADA holders want it to be. It can't be that the team is thinking about how to remove (or add) some functionality from the protocol just because they think it's best for the future of Cardano.

As a Bitcoiner, I feel a certain hopelessness about the Ordinals. Holding BTC doesn't allow me to make any decisions, and it's impossible to profitably mine BTC in our landscape. Without a hash rate, I cannot vote. On the other hand, as an ADA holder, I have hope that I will make the decisions I think are best for Cardano.


You may be surprised to see that the article discusses the differences in minting and token transfer on Bitcoin, Cardano, and Ethereum, only to end with the topic related to decentralized governance. I think those who only follow Cardano should have at least a basic understanding of how tokens work on other platforms. Think about what a huge difference it makes when a team and a community want to achieve the same goal, or when they are in ideological conflict. If the team prevents the innovation that part of the community is demanding and someone can sneak new capabilities into Bitcoin, it is very likely that the result will not be very good technically. Moreover, there is a risk that the team will resist further development with the argument that the other part of the community demands it.

I don't think the best approach for the Bitcoin community is to tolerate the existence of tokens under the false guise of freedom. The best approach is to be able to agree in such a way that as much of the community as possible can vote. This is exactly what CIP-1694 brings to Cardano. The team needs to meet the demands of the community, not have an opinion and enforce it non-transparently from a position of power.


Related articles

Did you enjoy this article? Other great articles by the same author