Risks and Challenges of Tokenisation

Tokens are digital representations of assets that are issued and traded within a distributed ledger. In this post, which is the second in a two-part series, we examine the risks they face and the challenges they need to overcome to achieve mass adoption.


Tokenisation is the process of creating rights over assets, that are then managed and traded within a distributed ledger network, such as a blockchain. The assets that the token represents can be either real (off-chain), such as commodities and real estate, or digital (on-chain). Although there are many potential benefits from tokenisation, the technology is still at an early stage, and several challenges need to be resolved before wider adoption can materialise. In this second part of our two-part series, we elaborate on the risks and challenges of tokenisation, following on from the first part where we discussed the benefits.1


One of the most important bottlenecks is scalability. Bitcoin was designed to add new transactions every 10 minutes and there is a bandwidth limit on how many can be processed. There are now blockchain projects that can update every few seconds, with a substantially increased bandwidth. However, trade-offs persist. The scalability trilemma specifies that it is very difficult (if not impossible) to achieve the following three desirable objectives simultaneously: security, scalability and decentralisation. Security refers to whether a blockchain can withstand a malicious attack, one that aims to corrupt or reverse recorded transactions. Scalability is measured by the number of transactions per unit of time that the system can perform. Decentralisation of block production (DBP) is defined as the number of independent block producers and how easy it is for a new participant to become a block producer. There are many different ledger designs which achieve two out of three objectives satisfactorily, but not all three. For example, Bitcoin achieves security and decentralisation, but not scalability. Layer 2 solutions, such as the Lightning Network, provide an alternative way of solving for the scalability trilemma, particularly in terms of achieving greater scalability on various dimensions. These protocol projects work by performing some computations off-chain, while still anchoring to the main blockchain to maintain security and trustlessness. 

Settlement finality

Another technological challenge is settlement finality. When a transaction is written on a blockchain, it is not deterministically final, because there is always the possibility that an alternative branch becomes the main one, which does not include this transaction. This can happen because of an attack, or because there is a lack of consensus on a proposed change and a fork is implemented. As time passes and more blocks are added on the chain, the probability that the transaction is going to be void approaches zero. For example, it is generally accepted that after one hour, it is almost impossible to reverse a Bitcoin transaction. Although a transaction is never final with probability 1, the same is true for any transaction recorded in traditional ledgers, either off-line or online, because they are also vulnerable to attacks.


What safeguards are in place for when things go wrong and DLT does not work as intended? For instance, if consensus about a proposed change of the design of the blockchain is not reached, it is possible that two competing groups create two parallel versions of the database of transactions, which is called forking. In that case, an investor may have to choose which branch of the blockchain to follow. If that branch is subsequently abandoned, he may lose his investment. A blockchain could also be attacked, for example using a 51% attack. The purpose of the attack can be to falsify some of the transactions, or to take over control, in order to restrict the types of transactions that are recorded, or even exclude some members from participating. Finally, a smart contract may not work as intended if the coding is incorrect, or an unforeseen contingency materialises.

How large are these risks? Historically, there have been several cases of forks and successful attacks on blockchain networks, however these usually involve small projects with low intrinsic value. For example, Bitcoin has never been attacked successfully and, although there have been successfully Bitcoin forks, it has always been very clear which is the main branch. There are few well-known failures of smart contracts, however, this can also be due to their limited use up until now.


Another risk is the potential lack of accountability. If, for whatever reason, something goes wrong, who is responsible to compensate investors or firms? If the blockchain is permissioned, with clearly identified entities who control and maintain the network, accountability is more straightforward. However, a permissioned blockchain introduces elements of centralisation, which may not always be desirable. In a permissionless blockchain, anyone can participate in updating and maintaining the ledger of transactions. This could lead to a dilution of accountability. However, it is an element of good governance to outline at the beginning who is accountable and for what. Related to these risks is the fact that the legal and regulatory framework is still playing catch-up with the technological advancements. For example, smart contracts are not yet considered legal contracts in many jurisdictions, so if a dispute arises, it may be difficult to involve the courts to help resolve it. 

On the other hand, there are now strict laws about the protection of personal data and privacy, such as GDPR in Europe. Any market participant has the right of access, the rights to rectification and erasure (“right to be forgotten”). Failure to satisfy data subject requests and non-compliance with the GDPR requirements may trigger fines imposed on the controller (or the processor) up to EUR 20,000,000 or 4% of total worldwide annual turnover (whichever is higher). This can potentially be a big risk for a blockchain project that issues and trades tokens, especially if they represent assets with great value. It is alleged that the append-only, tamper-resistant or immutable nature of blockchain does not comply with the data minimization and storage limitation principles under the GDPR, which require the controller to do away with personal data that are no longer necessary for the processing operations originally envisaged; or with the obligation of the controller to rectify or erase data if requested by the data subject. 

However, as we argue in the report “Blockchain and the General Data Protection Regulation”, compliance with GDPR can be ensured if the blockchain is well-designed.2 For example, suppose that a token issued in a blockchain is backed by real estate assets. If the addresses and the names of the people involved in transactions are recorded on the blockchain, then its immutable character would clash with the right of erasure, as described in the GDPR. However, a different implementation would require each user to generate a public key, which links to their transactions. Ownership of the public key is proven through a private key. At the same time, the link between the public key and the users’ identity and address could be stored in a private, off-chain database. A user can then request deletion of his relevant data, which can be implemented by deleting the link between the public key and the record of his identity in the private database. Although the link is deleted, the public key and its relation to the user’s transactions is not. However, what if a user claims that a transaction should not link to his public key, because it was entered in error, or it is disputed that it ever took place? This is also possible, in at least two ways. First, a transaction can be reversed, by appending new transactions in the blockchain. Second, a blockchain can be forked, such that a new branch is formed. If consensus on that branch is reached, then whatever was recorded in the old branch becomes irrelevant, and therefore the disputed information is erased.

Finally, and related to the issue of privacy, are the Anti-Money Laundering (AML) and Know Your Client (KYC) requirements that issuers of tokens need to comply with. This creates a tension between anonymity, which is one of the components of decentralization, and having some information about the participants in your network in order to satisfy the AML/KYC requirements. A well-designed token needs to provide a fine balance between these two desiderata.


In this second part of a two-part series, we discuss the risks and challenges of tokenisation and DLT. The main obstacles in achieving mass adoption are scaling of transactions, settlement finality, putting in place safeguards for when things go wrong and increasing accountability. However, if these obstacles are overcome, the potential benefits are substantial. We discuss them in the first part of this series, emphasizing that they stem from the unique characteristics of the DLT architecture, such as decentralisation and shared ownership, automation using smart contracts and giving greater control to users over how their information is used.  


1 The first part, “Benefits of Tokenisation”, can be found here: https://en.aaro.capital/Article?ID=86baa610-e7a1-4412-a697-e031ebaf8f50.
2 The report can accessed here: https://www.aaro.capital/Article?ID=b619f01e-eb93-4441-86cd-dee87104b085.