The Risks and Challenges of Tokenisation

Tokenisation is the process of digitally representing assets on a distributed ledger. Although there are many potential benefits, the technology is still at an early stage. In this note, we evaluate the risks and challenges that need to be resolved before wider adoption can materialise.

Scalability

One of the most prevalent challenges in achieving wider adoption of tokenisation is scalability. Bitcoin was designed to add new transactions every 10 minutes, with a bandwidth limit of 6 to 7 transactions per second. There are now ledgers which update within few seconds, and handle 10,000+ transactions per second. However, trade-offs still persist. 

The scalability trilemma specifies that it is difficult (if not impossible) to achieve the following three desirable objectives simultaneously: security, scalability and decentralisation. Security refers to whether a ledger can withstand a malicious attack, i.e. one that aims to corrupt recorded transactions. Scalability is measured by the number of transactions per unit of time that the system can perform e.g. transaction per second. 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, independently verifying the validity of the ledger. 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. The technology works by performing some computations independently, while still anchoring to the main ledger to maintain a secure and trustless environment.

Settlement Finality

Another technological challenge is settlement finality. When a transaction is recorded on a ledger, it is not deterministically final. This is because there is always the possibility that an alternative branch of the ledger becomes the commonly accepted version, which does not include this transaction. This can happen because of a malicious attack, or because there is a lack of consensus on a proposed change and a ledger fork is implemented. As time passes and more blocks are added on the ledger, the probability that an accepted transaction is removed approaches 0%. For example, it is generally accepted that after one hour, it is almost impossible to reverse a Bitcoin transaction. Although a transaction is never 100% final, the same is true for any transaction recorded in traditional ledgers, because they are also vulnerable to attacks and manipulation.

Accountability

Another risk is the potential lack of accountability. When something inevitably goes wrong, who compensates those who were financially damaged? If the ledger is permissioned, with clearly identified entities who control and maintain the network, accountability is more straightforward. However, a permissioned ledger introduces elements of centralisation, which may not always be desirable. In a permissionless ledger, anyone can participate in updating and maintaining the ledger of transactions. This could lead to a dilution of accountability. This is in contrast to good governance, where clear accountability should be planned from the start. Insurance can provide some protection to ledger users, but insurers still need to become more familiar with the technology to insure users of  DLT platforms at reasonable premiums.

Further, global legal and regulatory frameworks are still playing catch-up. For example, smart contracts are not yet considered legal contracts in many jurisdictions. Thus, if a dispute arises, formal legal resolution via the courts may be difficult.

Data Protection

There are now strict personal data and privacy laws, such as General Data Protection Regulation (GDPR) in Europe. Any market participant has the right of access, rectification and erasure (“right to be forgotten”). Failure to satisfy data subject requests and non-compliance with the GDPR requirements may trigger large fines. This can potentially be a big risk for a DLT project that issues and trades tokens on their ledger, especially if they represent assets with great value. It is alleged that the append-only, tamper-resistant or immutable nature of DLT does not comply with the data minimisation and storage limitation principles under the GDPR.

However, as we argue in the note “Blockchain and the General Data Protection Regulation”, compliance with GDPR can be ensured if the ledger is well-designed.1 For example, suppose that a token issued on a ledger is backed by real estate assets. If the addresses and the names of the people involved in transactions are recorded on the ledger, the immutable nature of the ledger would prevent the right of erasure, as directed under the GDPR. However, a different ledger design would only store links to the personal data on the ledger, which can be removed when requested, thus allowing for GDPR compliance.2

Know Your Customer (KYC) and Anti-Money Laundering (AML)

Related to the issue of privacy are the KYC  and AML requirements that token issuers need to comply with. This creates tension between the right to privacy, which is one of the components of decentralisation, and being able to satisfy AML and KYC requirements. A well-designed token needs to provide a fine balance between these two factors.

When Things Go Wrong

There are also potential risks if the DLT does not work as intended. For instance, if consensus is not reached on proposed ledger protocol changes, two competing groups can create two parallel versions of the ledger, known as a hard fork. In this scenario, an investor may have to choose which version of the ledger to follow. If a branch is subsequently abandoned, investors will lose the value of their investments on that branch. A ledger could also be attacked, for example using a 51% attack. The purpose of the attack could 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, an additional issue is that a smart contract may not work as intended. This can be caused by errors in the coding of the smart contract, or if an unforeseen contingency materialises. This can result in users of the smart contract being financially damaged.

How big are these risks? Historically, there have been many cases of forks and successful attacks on DLT 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 dominant branch of the ledger. There are few well-known failures of smart contracts, however such issues should decrease as smart contracts become more standardised and thoroughly tested through time.

Conclusion

The tokenisation of assets can be thought of as an evolution of securitisation, as it promises to deliver efficiency gains, by leveraging the unique advantages of DLT, such as decentralisation, automation using smart contracts and greater control of user and subject information. However, several obstacles need to be overcome before there is wider adoption. First, the technology need to be scalable and provide settlement finality, which is as good as existing mainstream solutions. Second, there is no escape in complying with the relevant regulatory frameworks, for example on data protection, KYC and AML. Finally, the network on which tokens are issued need to have clear accountability for when things go wrong, whilst still having some leeway and understanding amongst insurers for protection at a reasonable cost.

Footnotes

1 The report can accessed here: https://www.aaro.capital/Article?ID=b619f01e-eb93-4441-86cd-dee87104b085.

2 This 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.

Disclaimer

The material provided in this article is being provided for general informational purposes. Aaro Capital Limited does not provide, and does not hold itself out as providing, investment advice and the information provided in this article should not be relied upon or form the basis of any investment decision nor for the potential suitability of any particular investment. The figures shown in this article refer to the past or are provided as examples only. Past performance is not reliable indicator of future results.

This article may contain information about cryptoassets. Cryptoassets are at a developmental stage and anyone thinking about investing into these types of assets should be cautious and take appropriate advice in relation to the risks associated with these assets including (without limitation) volatility, total capital loss, and lack of regulation over certain market participants. While the directors of Aaro Capital Limited have used their reasonable endeavours to ensure the accuracy of the information contained in this article, neither Aaro Capital Limited nor its directors give any warranty or guarantee as to the accuracy and completeness of such information.

Back