ABS and DLTs

12/14

Introduction
ØNLI is a tokenized asset backed securities (TABS) platform, where securities means tradable financial asset of any kind. ØNLI is not an asset class, like Bitcoin. Rather, it is financial plumbing for digitally transacting in physical assets. We started nine years ago to build the platform from the ground up for this purpose. Consequently, we are fundamentally different from conventional blockchain deployments and distributed ledger technology (DLT). At the outset, we went in a different direction from the herd because representing physical assets such as gold, real estate, or stock requires a different solution.

While we utilized properties of blockchain, we created a different system from the ground up because true DLTs represent severe risks for an issuer of asset-backed tokens. First, the current governance system and upgrade mechanism of DLTs, mean the issue cannot be certain of the future of the token they issue. Second, it is almost impossible for the issuer to take responsibility for a DLT deployment (or a token deployed on a DLT, such as through ERC20) in a way that will meet the expectations and legal requirements of its customers.

To understand where these limitations and risks come from, we explain how DLTs are currently governed at a high level. That is, how the low-level systems of consensus and transaction rules are defined and upgraded. There is growing sense of anxiety about this high level decision process. In December 2017, Fred Erhsam, co-founder of Coinbase stated: “[G]overnance is the most vital problem in the [blockchain] space… . yet little research has gone into governance and it feels poorly understood.”

Background and Terminology
A DLT is a combination of at least four components: (1) a blockchain data structure that stores a ledger and cryptographically ties entries in the ledger together; (2) a set of rules running on client software for what types of transactions can be recorded in the ledger, and who can record them; (3) a community of nodes that each run the client software, store a copy of the ledger, and accept transactions as proposed additions to the copy; and (4) a consensus mechanism that decides which proposed transactions become permanent additions, critical as the proposed additions of each node’s copy begin to disagree. Finally, in cases where anyone can make ledger entries (e.g., a “public blockchain”), there is (5) a reward that aligns the node operators with the proper function of the consensus mechanism, usually through free distribution of tokens (e.g., mining).

Low-level Governance of DLTs
The consensus mechanism and any economic incentive that keeps it functioning is a form of “low-level governance.” The consensus mechanism is applied deterministically by the rules of the client software to resolve inconsistencies in the ledger and return the database to an agreed upon state.3 The important thing to remember is that low-level governance is kind of voting carried out by nodes through the strictures of the DLT’s client software.

The majority of blockchain’s intellectual energy has been spent on designing consensus mechanisms and economic incentives. For example, early debates centered on whether mining was necessary for private DLTs (aka permissioned blockchains where all nodes are authenticated). A continuing dialog weighs methods for node voting, including proof-of-work, proof-of-stake, and hybrids. Each approach has its own tradeoffs in terms of security, transaction speed, scalability, and other factors. However, all DLT projects share something in common. Any time low-level governance has to be changed a project has to upgrade its client software.

Simple Upgrades
DLT client software, like all software, has to be upgraded. Let’s look at what is required to fix a security flaw. A group of software developers writes an updated version of the client software. The developers post it where the people who operate nodes can easily find and download it.

The nodes will generally update quickly, sometimes through coordinated effort (e.g., at block number 491,407). Nodes failing to update will find themselves part of a dwindling network that users lose confidence in and stop sending transactions to. Updating the client software and the resulting divergence in the ledger entry history, is referred to as a “hard fork.”

Hard Forks
According to Wikipedia, a fork is where “a blockchain diverges into two potential paths forward, with regard to transaction history or a new rule about valid transactions.”4 Investopedia described a hard fork as “a radical change to the protocol that makes … a permanent divergence from the previous version.”5

In the security flaw example, you might have missed something if you blinked: a community of people come to consensus that the upgraded network is the “true network” that carries on the name of the old. A bona fide security flaw that could bring the entire network down is not a controversial update. Like a snake shedding its skin, no one questions which object is the snake.

But what if you want to change who can participate? Or tune the consensus mechanism to trade security for speed? Such changes often benefit one type of user at the expense of the other. Enter high-level governance, the political, people-driven process for deciding what code runs on the nodes and which version of the ledger history is “true.”

High-level Governance of DLTs
I refer to “high level governance” as the process by which people decide what the transaction rules are, how the consensus mechanism and economic incentives work, and which transaction history is the “true” ledger. High level governance of DLTs follows one of three patterns: (1) a weak or absent network sponsor, (2) a strong network sponsor, and (3) “on-chain” governance, yet to be realized.

Bitcoin has no sponsor. Changes are proposed by a community of developers through mailing lists. The community sometimes undergoes deadlock and debate across competing discussion forums. Clones of Bitcoin’s source code (e.g., Litecoin) may have an initial sponsor, but then transition to a similar dissipated governance structure. Similarly clones of Bitcoin at a given instance (e.g., Bitcoin Cash) also have a group of initiators who then fade.

Other networks have stronger sponsorship. Users of the permissioned blockchain Ripple de facto rely on the founding corporation for all upgrades and maintenance. The founding team of Etherium (though a non-profit) primarily introduces and curates software upgrades. This is a fine line to walk: the Etherium foundation is often accused of being a “central authority” at odds with its “distributed” mission statement.6 Other projects like Monero basically take the position, “trust us to develop it. If one day you don’t trust us, you can fork it.”

Finally, a few projects propose internal or “on-chain” governance. In 2014, the Tezos project set out to build a “self-amending” ledger where users and nodes could vote on upgrades on the ledger itself (after three years, it has yet to launch). A thought experiment called “FedCoin” proposed a DLT that gives some nodes more power than others to change transaction rules and issue tokens. Recent proposals describe possible “velvet forks”, where backward compatibility could allow for a slow transition in the network.

Summarizing to this point, users opt-in to the low-level governance rules of a DLT when they buy tokens and begin making transactions. However, all current DLTs rely on the consensus of people to make decisions on how to change and upgrade the low-level machine governance. DLTs must use hard forks to implement those high-level governance decisions.

Famous Examples
DAO. In 2016 a project called Distributed Autonomous Organization (DAO) built a smart contract on the Etherium network to act as a token-based investment fund. Etherium users sent Ether tokens to DAO worth $150M at the time. A flaw in the smart contract resulted in a hacker stealing $70M. Within 24 hours the Etherium foundation wrote a “software upgrade” that rolled back the theft. Most of the network upgraded, carrying forward the name “Etherium.” Hardcore decentralists protested at the exercise of central power, and refused to roll back their nodes, resulting in the “Etherium Classic” fork.

SegWit2X. By 2015, the original transaction rules of the Bitcoin network (which limited the number of transactions per period of time) was having a hard time keeping up with the network’s newfound popularity. An upgrade called SegWit2X was hammered out through two years of debate. It’s proponents attempted to implement it in November 2017. It did not receive enough support from nodes and failed.

Bitcoin Cash. A development group7 copied Bitcoins public ledger and made a few small tweaks to the client software. The copied ledger was initiated on a new set of nodes on August 1, 2017, seeding an entirely new network that could evolve independently of Bitcoin. Because the ledger copy was identical at the moment of the split, people who controlled private key in the Bitcoin network could use those same keys in the Bitcoin Cash network.

In all three of these cases it did not really matter which was the “true” network. All forks were valid, with user confidence in the fork determining size of the network and price of its token.

Known Problems
For many, the marketplace of ideas resulting from unstructured high-level governance and unpreventable hard-forks is exciting. It has yielded brave experiments and dramatic failures.

There are numerous known problems with this approach to governance. Briefly, it is difficult for ordinary users to contribute to the high-level governance discussion in a meaningful way. For example, the most recent influx of Bitcoin and Etherium owners don’t understand the network can fork at all, or readily confuse Etherium Classic and Etherium, Bitcoin and Bitcoin Cash. In the period leading up to the fork, there is uncertainty. SegWit2X, two years in the making, failed at launch. In the moment of a hard fork and for some period after, there is confusion. 8 Where the new fork successfully diverges, it can create security vulnerabilities for the progenitor fork.9

These issues have been generally discussed in the context of projects where tokens are their own currency created from nothing, like Bitcoin, Ether, or Ripple’s XRP. However, a growing number of projects and enterprises are seeking to issue tokens tied to real-world and physical assets. DLT high-level governance and hard-forking creates two major risks for these users that are not yet widely recognized.

Physical Things Don’t Fork
In the case of Bitcoin or Etherium, you can fork the network as long as people think both offshoots are valuable. But when the DLT representing physical assets forks … the physical asset does not. Which token represents ownership and control of the physical object?

As an example, say an enterprise wants to issue gold bars using Etherium as its issuing and transaction infrastructure. The company can issue the tokens by writing an ERC20 Etherium smart contract. The company owns a physical vault where they store physical gold, and allow for its redemption by users. Subsequently, Etherium undergoes a heated debate about which way to take the network. Rival camps bifurcate the network, possibly for reasons that don’t concern the gold token.

There is no governance mechanism to solve this issue because it is not an problem Etherium was designed to deal with.

The issuer is now forced to: (i) assets which fork is best for it and/or which is more likely to survive, (ii) issue a statement regarding which fork is the “true” ledger that will represent the physical assets in the vault, (iii) warn users to stop trading before, during, and for a period after the fork, and (iv) field angry complaints and/or defend lawsuits from those who sent or received transactions through the wrong fork. It is worth noting that the issued policy statement is a form of central control undermining Etherium’s decentralized value proposition.

Picking the wrong fork, the one that will die out, is a nightmare scenario. The issuer either stops its business until it is sure the fork will survive, or prays it picked correctly. The company cannot directly benefit from new users and economic activity on the fork it didn’t pick. It cannot switch to the successful fork because it cannot call up customers who redeemed tokens for physical gold ask for the gold back to align the state of the physical world with the other fork. If the issuer guessed wrong, its digital tokenization breaks down and its business halts.

Inability to Take Responsibility
This type of loss of control is an unacceptable risk for an organization. It is analogous to designing a product that critically depends on a rare element found in a single politically unstable country. By definition, a DLT is outside of the responsibility of anyone. Rather, it is everyone’s in accordance with (a) the predictable low-level governance system and (b) the (un)predictable high-level governance system.

Enterprises that want to issue tokens generally want to maintain and build relationships with their customers. On the one hand, they may want to market that they cannot improperly exert influence over their issued token. On the other hand, they want to leverage their social capital and expand trust in their brand. These are incompatible objectives with most DLT technology because the company has little control over its infrastructure.10 Unlike vendors with contractual obligations to the enterprise, the DLT (and the community that develops it) has no such obligation.

For example, before FinCen stopped the practice, several companies used Bitcoin as a low cost “payment rail” to remit money from the United States to foreign countries like the Philippines. A sender would bring cash into a convenient store in the USA. An operator would accept the cash, buy Bitcoins (unbeknownst to the sender), then transfer the Bitcoins to wealthy buyers in the Philippines. A family member of the sender would pick up cash in a Manila bodega. If the Bitcoin consensus mechanism hiccuped and the sender’s value was lost, the convenient store operator could not say the sender assumed this risk. It was firmly the operator’s responsibility.

This is an obvious example. But think again about gold token issuer and its hard fork dilemma. The typical consumer purchasing a bar of tokenized gold will evaluate the credibility of the token issuer. They will probably not see risk in the political dynamics of network nodes operators ultimately reasonable for safekeeping their ownership records and who have no obligation to the issuer or its customers. When the price of gold is plummeting, it will be difficult for the token issuer to explain it’s inability to liquidate because a virtual kitten game is clogging network capacity. Regardless, the token issuer will be held responsible because they selected and marketed their token on the shared infrastructure.

Companies seeking to protect themselves will end up writing a good amount of legal documentation in an attempt to offset this risk. In doing so, they may plaster-over the elegance of DLTs that otherwise function well among peers who don’t need to be responsible for infrastructure and who don’t care about representing real-world assets.

Only ØNLI
ØNLI is a different system based on a theory of actual possession, where value is not stored in a ledger at all. A mint computer generates unique tokens that can be tied to physical assets, and each receives its own blockchain data structure that is physically transferred between owners. Transactions are centrally validated and cleared, while Onli tokens are stored in electronic vaults in control of users upon each transfer. Any physical asset the token represents can be held by an independent assurance provider.

In this case the issuer controls its infrastructure. It runs the marketplace servers that facilitate buying, selling, and trading, and the exchange server which acts as an on-ramp and off-ramp. The issuer can change the rules of trading, and update security flaws easily.

Users are protected in several ways. First, the issuer cannot confiscate or re-allocate tokens because the users physically possess them. Second, users have access to a distributed validation network (DVN) stored by user nodes. The DVN can optionally be implemented as a DLT. However, in contrast to most DLTs, this distributed database stores evidence of ownership that can be utilized in any dispute. Here, the DLT does what it does best — immutably store something that happened without overstating its meaning or disclosing current ownership. Finally, the user can redeem the physical asset from the assurance provider — without the issuer — by presenting a token and matching it to the publicly distributed DVN data.

This approach overlays perfectly with existing legal documentation and consumer expectation. There are no hard forks: the issuer develops the network as is best for its business model and token holders. Customers sign clear terms of service when they download client software used to buy and transfer tokens. The issuer can halt trading of a fraudulent actor to protect the reputation of the token. The issuer can integrate KYC procedures into its exchange. Evidence of ownership (that does not violate user confidentiality) is maintained by users and becomes immutable.

Conclusion
Low-level governance is the consensus mechanism, participation rules, and transaction rules of a DLT. High-level governance is the mechanism that determines and changes low-level governance. Currently, high-level governance is conducted through hard forks. The possibility of hard forks makes representing physical assets challenging and risky. Attempts to negate this risk introduces significant burdens, uncertainty, and breaks down the decentralized value proposition. At the same time, decentralized systems, especially if susceptible to chaotic high-level governance, prevents an enterprise from controlling or taking responsibility for its infrastructure in contrast to customer expectation.

ØNLI is an entirely different system based on actual token possession, checks and balances, and existing legal frameworks. The system is intuitive for the issuer, its regulators, and its customers. It has been designed from the beginning for tangible asset tokenization, able to protect the interests of both an issuer of asset-backed tokens and its customers.

Leave a Reply