How deep is your (technical) love? (Tokenisation Part 4)

In part 1 (here) of this series of posts on tokenisation, I looked at the possibilities opened up by tokenisation of assets using cryptocurrencies and in part 3 (here) I looked at some specific implementations of asset tokenisation and reviewed the benefits (or lack thereof) of creating a platform for asset tokenisation. In this post I intend to look at other specific aspects of implementation, considering the risk impact of how the technical the asset tokenisation process is, given the state of the technology.

Generally speaking the issue at large is how much of the process of raising ICO funds you want to carry-out on-chain, i.e on the blockchain and how much do you want to do off-chain?


When picking technical choices for your tokenisation, you need to consider how deeply you will commit to a particular technology/ a particular blockchain and how mature the technology in helping the process along. Letting the technical tail wag the requirements dog is a dangerous temptation that needs to always be resisted.

At this time, although cryptocurrency blockchains have been around for a few years, token standards like ERC20 on the Ethereum blockchain have been formalised for less than a year. Therefore it is not unreasonable to expect things to change in the specification, bugs to be fixed, and wallets to be improved.

As the more interesting and sophisticated functions in the smart contracts that create cryptocurrency tokens are battle tested, it may be important to keep your use of the technology simple for two reasons, viz. a) because large amounts of your/investor money are at stake b) the implementation of those higher level functions might change.

Yes, perhaps you can reissue your smart contract but how much risk and effort do you have to engage just to keep technically compliant and low risk in a rapidly changing landscape?

You may even consider being blockchain agnostic, crafting a strategy that allows for a future migration to another blockchain as a base for your token.


The issue of technological maturity dovetails concerns about security. How secure is your overall platform when it is based on components of a technical base that are subject to ongoing change? How likely are you to be hacked like the infamous DAO hack that created the ETH/ETC split in the Ethereum blockchain? Security concerns may  go much beyond malicious activity. In November 2017, a bug in a popular ethereum wallet froze millions of dollars in funds across the world. A popular ICO lost 90 million dollars in funds (see For your ICO, you will need to carefully assess what amount of funds you are putting at risk by committing to your technological choices. If you are locking up funds in a smart contract, are you clear about the risks to those funds from code change, malicious activity, and non-malicious bugs? To mitigate risk, you could consider narrowing the component of your financing process that is done using the blockchain and keep the rest of the process “off-chain” and not hostage to the technology.

Real versus Crypto

You may also wish to take a step back and decide what portion of your raised funds you want to hold in cryptocurrency at what stage in the process. Blockchain enthusiasts may want you to hold funds in wallets on the blockchain, locked in smart contracts subject to conditions, held in escrow and then used as security for borrowing real world funds to your tokenisation. Blockchain enthusiasts may want you to give up your first-born for the glory of the blockchain. However, that perspective may require a pinch or a mountain of salt. Tokenising real word assets in a cryptocurrency token is about building a bridge between the real and crypto worlds. It is about venturing out of crypto. Tokenisation can provide real world activity such as asset purchase and dividend return, access to efficient cryptocurrency fund transfer mechanisms but it can also provide real world stability and a hedge against crypto volatility. Holding excessive money in crypto after it is raised may not achieve the risk profile you need, and additionally, as I discussed in Post 2 of this series, it may also reduce your expected rate of return, thus impacting your business model.


Issues discussed above relating to software maturity, commitment to technology, holding money “on-chain” within your platform of choice, must be carefully considered in your design choice around your tokenisation process. You may move your goalposts around based on your appetite for risk, but it is important not to blindly follow the technological hype while ensuring that you still benefit from the opportunities brought forth by the distributed immutable ledger of blockchains. In another post here, I will discuss how some of the design choices of your token fundraising may impact your fundraising costs and evaluate some of the ICOs in the marketplace.