Thoughts on monetization in blockchain environments (Part II)

As we saw in Part I under an idealised public blockchain, companies will no longer control the whole stack from data to UX, meaning that getting paid may no longer be so easy. Having looked at the importance of the UX to generating income, we’ll now briefly investigate how companies might use smart contract development to do so.

The discussion expects a reasonably developed understanding of the notion of smart contracts, how they work and what they are capable of. We take two big assumptions.

Firstly, that there will be no segregated areas in the blockchain environment where access in and out is controlled by a single organisation. All contracts exist in ‘open water’. This means that certain things about them will be in the public domain — what methods joe public can call, what data you can send them, how much money they contain, etc.

Secondly, and more contentiously, a standalone smart contract app or autonomous organisation is not going to float people’s boat. Successful companies on blockchain will have customer support, marketing & PR, etc. They can be flexible, break their own rules, think outside the box and adapt quickly to new circumstances — at least compared to an app consisting of multiple smart contracts, that is. In short, the idea of a ‘smart contract as a company’ is not feasible. There will be an association of human beings around any service offered via smart contract.

There are two main ways to derive economic value from the production of smart contracts:

• creating proprietary businesses which protect access to and charge money for receiving the service of, their operations
• contributing to the blockchain commonwealth in working on open source projects.

Deriving value from protection of access

Unlike the data, explicit, mandatory smart contract visibility is not assured (it doesn’t exist on Ethereum, for example). It can be guessed at by looking at available information — the bytecode on Ethereum is publicly available by default — or openly shared to promote trust and visibility, but this isn’t normally obligatory. So, complex logic to deliver value can be protected and leveraged to get paid. Organisations could control the vertical and also build and control on-ramps (see Part I for further details), or they could open access to their smart contracts and focus solely on their own ‘platform’, with other organisations creating their own UX experiences that interact with it via APIs.

Quick aside: at this point calling it a smart contract becomes somewhat redundant. Smart contracts aren’t contracts if their inner workings aren’t visible. You wouldn’t sign a contract without seeing the text (or would be a fool to do so), so likewise a smart contract whose logic is not explicit ceases to be a contract. While the name ‘smart contract’ may be a misnomer, this will almost certainly be no barrier to adoption. Who does need to understand the logic behind an eBay transaction, or opening a savings account?

Another way to control access to our smart contract/app is via Patents and Copyrights. Certainly, these may be granted for innovations, but given the instant supra-nationality of blockchains, this could prove difficult to enforce. The government Country A may not have the will or the political means to penalise a company in Country B who is ripping off a patent granted by A, and this copycat could be online in mere hours. More likely is some kind of commission set at code level — pay to play for each instance of the smart contract.

Deriving value from open source projects

Currently almost all contracts developed in the open with a view to drive stability and adoption. Where it exists, most ‘public’ money is available for infrastructure projects, such as in the grants given by the Ethereum Foundation (examples here), though in no real sense could a business plan be formed on the basis of continuing receipt of such funds.

Another more innovative, but politically charged, solution, would be pay organisations to develop contract standards from ‘tax’ levied on transactions, for example. This of course implies some kind of centralised governance model for the blockchain, which can run counter to the founding principles of stakeholders. The governance discussion is a whole can of worms that won’t be opened here, suffice to say that this writer believes a lack of unified governance has stymied adoption of Bitcoin.

Then of course you have the risk of a de facto concentration of risk and responsibility in organisations who become responsible for driving development of the technical commons. Their failure may prejudice the whole shebang, their raging success might also.

Conclusion

Two types of contracts will emerge — blackboxed, where logic is protected (but guessing games can be done on these operations), and open-sourced. Most successful tech companies will seek to do the former, but there may be examples of organisations creating economic value for themselves with just a great UX based on open-sourced, generic contracts.

Interestingly, the UX layer and the application layer could completely diverge, with companies offering pay to access ‘platforms’ of smart contracts for which other companies make compelling on-ramps. Currently, in the absence of any truly huge players (despite what ICO valuations might suggest the size of many blockchain companies is) may suggest that successful companies will be ones that do focus on one or the other.