Crypto 2.0 Musings - Blockchain Business Models

My previous decentralised business models blog talked about how blockchain businesses are not only innovating technology, but are also experimenting with new business models. In this blog I want to explore some real world case studies and propose new business models to boot.

Let’s start at the beginning, and that’s Bitcoin. Its business model’s value proposition is an innovative payment network and a new kind of money with no central authority or banks. First, let’s explore why anyone would be willing to pay for Bitcoin’s products and services, and then why would someone choose Bitcoin versus it’s competitors.

Generally, businesses are willing to pay for money products and services, because as they create, deliver and capture value, they use money as a medium of exchange, a unit of account, a standard of deferred payment, and a store of that value. Money’s alternative is barter, but it has proven to be less effective than money.

Businesses mostly use fiat money today, that’s money that a government has declared to be legal tender. It means that if you are in debt to someone then you can’t be sued for non-payment if you offer full payment of your debts in legal tender. Businesses prefer electronic rather than paper form of fiat money, and as governments only allow banks to have central bank electronic reserve accounts, it is commercial bank’s electronic record of fiat money claims that is today’s most common form of money. Like an equity instrument, fiat money represents a proportional claim on the future output of an economy run by a government, faith in which being the key value driver, as it has no intrinsic value otherwise. Since common money is claim on a bank that itself is a claim on a government, it is exposed to operational, liquidity and credit risks introduced by both banks and governments. If those risks impact confidence in common money, they can devalue it, making money less attractive as a store of value or a standard of deferred payment for businesses. 

Bitcoin’s simple mitigation proposal is to use peer-to-peer technology to replace banks and governments. Miners, it’s operators, are incentivised through distribution of newly issued and fee charged bitcoins. Bitcoins are like equity shares in the network that can be used as a medium of exchange, whose value is driven by faith in the network’s developers and miners to operate money products and services. Some people place a lot of faith in the network, making it valuable, as they believe it to be a superior business model to create, deliver and capture value from money offerings as compared to one’s used by governments, private and public companies, partnerships and cooperatives, since it uniquely mitigates issuer’s inflation risk on business’s stored value and aligns customer, employee and shareholder interests in a for-profit manner. 

Now let’s take a look at Ethereum. Its business model’s value proposition is a decentralised platform that runs smart contracts, applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference. Just like in Bitcoin, Ethereum miners are incentivised through distribution of newly issued and fee charged Ethers, but unlike bitcoins, Ethers have a 2% annual monetary inflation rate and can be exchanged not just for money services, but for any application built on top of the Ethereum platform. Also, to speed-up Ethereum development, some pre-mined Ethers were sold by the Ethereum Foundation in exchange for Bitcoins to pay developers in the startup phase and others held back as an equity stake for the growth phase in an initial coin offering, or an ICO.

The Ethereum case study would not be complete if we didn’t take a look at an example application running on the Ethereum platform, so let’s study Lunyr. Its business model’s value proposition is a decentralised encyclopaedia platform. Lunyr distributes 80% of newly issued LUN tokens to encyclopaedia content contributors, reserving 20% for themselves to fund on-going development. LUNs are sold in exchange for advertising rights - a business estimated to be worth billions of dollars based on how much an average advertiser is willing to pay for Wikipedia like footfall. LUNs are implemented as an Ethereum token smart contract, and the rest of the platform is a mix of custom smart contracts and IPFS. 

Notice, that all three case studies are multi-sided platforms whose value is driven by network effect and that rely on crowd contribution of either content or compute resources i.e. much like AirBnB and Uber, but where the some of the network effect value is shared with contributors rather than fully captured by the platform owners. So what could a business model for an application running on Ethereum look like if it does not rely on crowd contributions and has no network effect value driver? Let’s take bond trading as an example. 

In order to trade bonds, people need to find bonds for sale. Developer Bob spots a business opportunity and develops an on-line bonds for-sale list website. Bond sellers can add a new for-sale bond to the list, along with their contact details. Bond buyers can contact the seller by phone or email and negotiate the sale. Once sold, the seller removes the bond from the list. All of the business logic for the bonds-for-sale list application is coded into an Ethereum smart contract, that stores every bond as value data under a unique key within contract’s permanent store. To earn money from the application, Bob’s smart contract charges a small Ether fee that must be included with every new listing transaction.

Bond buyers and sellers like the application so much that they ask Bob to enhance it, so that they can use it to not only store for-sale bonds, but all bonds they have. That way they don’t need to pay Derek, a securities depository agent, to manage bond record keeping for them. They also want Bob’s application to manage the bond ownership transfer process, once the bond sale has been negotiated. So Bob adds additional value data in his smart contract to indicate if a bond is for sale or not, which can only be changed by a transaction created by the current owner. He also adds a transfer function to his code that again only the owner can call, once the owner receives money in their bank account.

All is well, until a month later, bond owners call Bob and ask him when their coupon payments will be paid to them. Bob never considered this use case, and as he is in a rush, he decides to find a bond servicing business to partner with. He finds Sally, who runs such a business, and Sally is able to quickly take a data feed from the smart contract and process coupon payments off-chain, for which she of course charges a fee. This is when Alice, another developer, spots an opportunity to create an alternative to Bob’s application, which automates both coupon payments in Ether and bond versus Ether atomic transfer within the smart contract. She is not incentivised to collaborate with Bob, as he collects all of the fees, see DApp Centralisation.

Some people are willing to accept Ether as money and wish to transfer bond listings to Alice’s application, whilst others choose to stick with Bob’s application as they are only willing to accept fiat money. Everyone agrees that double-listing is a bad idea, so Terence proposes that he becomes a listing transfer agent. He writes a smart contract that allows an owner to transfer their bond records from Bob’s application to Alice’s in a way that guarantees removal of bond listing in Bob’s application, but only if and once it is listed in Alice’s application. So whilst Bob removed the need for Derek, a securities depository agent, and Alice removed the need for Sally, a servicing agent, she introduced the need for Terence, a transfer agent. She also split the for-sale list, making it harder for buyers and sellers to find each other.

This is when Eric decides to create an exchange smart contract, that will include bonds from both Bob’s and Alice’s applications. As some buyers will want to buy bonds from Mary’s application, but are only willing to use fiat money, Eric creates an e-money token smart contract and acts as a market maker, working together with Terence, to allow purchase of bonds in Mary’s application using fiat e-money instead of Ether and transfer to Bob’s application once completed.

What I have described above, is a simplified version of today’s market structure coded as smart contracts. Since many of the described transactions are still manual in the contemporary lifecycle flow, the process takes a long time as humans operate at a slower pace than machines, and typically only nine till five. Processes that are automated, are still often batch based, so dependent transactions that miss a batch window push out total time to complete the front-to-back flow. Even if all processes are based on automated and real time web services provided by different organisations, each web service represents a single point of failure, and no one participant has an overview of the front-to-back state i.e. it’s hard for an end user to figure out where something is stuck.

Simply coding current market structure as smart contracts can bring huge benefits. Smart contracts offer an alternative to web services as a means of functional decomposition i.e. it is clear which organisation owns which part of the process. This in fact mitigates nicely blockchain’s regulatory risk i.e. only regulator licensed transfer agent’s smart contract would be accepted for use. After all, regulators regulate behaviour of licensed agents not technology. Since all smart contracts run in full on all consensus forming nodes, you eliminate today’s single point of failure risks. As all inter-contract depended transactions that are generated in response to a user’s transaction occur within the same block, even highly complex inter-organisational front-to-back flows occur in near real-time, reducing settlement risk and freeing up liquidity and capital reserves. Since the entire flow is stored on chain and available to all nodes, users are never left wondering as to when and what went wrong where. This also means that regulators can dispense with running own monitoring solutions and instead verify that the smart contracts enforce their controls and rely on the self-auditing nature of blockchain networks to guarantee enforcement of those controls, plus they get near real time data that can be used to fight systemic risk build up.

This is great, but can we do better? I think we can! As you can see, current market model introduces a lot of friction due to data silos e.g. need to transfer listings, but data silos occur naturally due to competition. Data silos are much easier to reconcile on-chain then in today’s world because essentially all data is in the same database, so reconciliation is between contract stores, as such data availably is not an issue, but still inter-contract data transfer is required, and that costs Ether. Can we better model to promote for competition and yet eliminate silos and associated friction? 

Let’s explore how you create a house sales contract today, to inform our approach. You can create the sales contract yourself if you know what you are doing and have the time, but most of us don’t. So instead, you talk to a lawyer, he asks you a bunch of questions, the answers to which he uses to fill in a template, the product of which is the sales contract, that he hands over to you for a fee, and which is yours to keep and use how you see fit. This is in stark contract to most of today’s on-line services that bundle business logic and data services together, allowing them to monetise your data and making it hard for you to switch service providers. But on-chain, the operators of the platform are different to application developers, so you can de-couple the two and give back data ownership. 

Just like with a paper contract, you can write our own smart contract, assuming it is an un-regulated activity, but you may not have the expertise or time to do so. So instead, you find a distributed application, most likely accessed as a website, that collects in our example your bond details, and passes them to a factory smart contract, that charges a fee and spits out a new smart contract with your bond details baked in. The created smart contract and it’s data now belongs to the bond owner, and the creation fee includes code usage license. Actually, since many bonds are regulated, you would have to use a distributed application written by a regulated entity. The regulators could even create a registry smart contract to track approved by them factory smart contracts, so you are sure that you are using a regulated one.

Just like today, different organisations can compete to write the best possible bond smart contract factory. They can also differentiate themselves on the quality of guarantees, warrantees, liability, support, jurisdiction coverage etc. The bond contracts themselves should be highly modular. For example, instead of implementing all corporate actions into a single contract, the bond contract should use what I call a Registry-Controller-Delegate pattern. Under this pattern, the bond (controller) contract allows a delegate contract to perform a limited range of approved lifecycle event actions. This way, if a transfer agent developer creates a better transfer contract, it’s easy to revoke grants to current transfer delegate contract and assign them to a new one. As new events need to be handed, new contracts can be easily plugged in as delegates. Each delegate contract can charge it’s own fees for specific transactions.

To find all regulator approved bonds, you could query the regulator’s registry contract to find all approved factory contract addresses, and then find all bond contracts that have been created by those addresses. As a convenience, each factory provider could also create a private registry for quick look up. However, just because anyone with a full node can access the data, it does not mean they have the right to use it, as under my proposal the bond owners, own the data and the code license to operate that specific data set. 

This opens up huge data monetisation opportunities. Let’s say someone wanted to advertise something to bond owners. Like Lunyr, someone could create a new service, BondAds, and a new coin that would have to be purchased by advertisers in order to advertise to bond owners. Whilst BondAds could just spin up a node and scrape data to populate their dataset, they would be in violation of data owner’s rights and litigation would follow. On the other hand, BondAds could create a registry smart contract, and invite bond owners to register their bond smart contracts in return for coins. By registering the bond contract, you in effect assign rights to monetise the data in return for share of generated advertising revenues. 

Notice, since BondAds would only register the smart contract address, not hold it’s own data on it, you eliminate data reconciliation needs. In fact, the same bond smart contract could be registered not just with the BondAds registry, but also with Bob’s, Alice’s and Eric’s applications, which are in effect all types of a registry contract that holds contract links, thereby eliminating reconciliation. Of course each registry may require a different set of methods and privileges from a bond contract, but that’s trivial to achieve by simply adding new delegate contracts to the bond smart contract, all operating on the same underlying data, but in a controlled manner. I am sure a bunch of standards will emerge to ease integration pains.

In this way, registry smart contracts on blockchain in effect become the securities depositories, each deposit being a bond smart contract. Regulation is not violated, as it’s easy to prove that registry, bond and delegate smart contracts, which together manage bond’s lifecycle were created by regulated entities. Some lifecycle events end up migrating from current model but are performed by smart contracts instead of by humans and web services, whilst others, like transfer events, are entirely deprecated. Logically at least, I can see how under this model, it’s possible to achieve competition, yet eliminate data silos and associated friction, whilst keeping mentioned benefits of migrating to blockchain.