Creating Dematerialized Assets using the Lean Startup Methodology

This is a guest post from Paul Sitoh of Blockchain Technology Partners. The original article was posted on Medium and is republished here with permission.

Introducing a Daml-Driven Lean Startup Methodology

Imagine a scenario where you are in the business of selling concert tickets. One of the major pain points is that you have to create physical tickets as well as maintain an expensive digital infrastructure, even if it is cloud-based, for your digital ticketing system. You then hear of this revolutionary technology called blockchain and, in particular, smart contracts that could disrupt your business. So how do you go about harnessing blockchain and smart contracts to deliver value to your customers, improve your efficiency and avoid your business being disrupted?

Try harnessing the power of a Daml-driven Lean Startup approach.

What is Lean Startup?

Lean Startup is defined as a methodology designed to help steer a business project that results in a product that meets market expectations. Getting your product to meet market expectations is often a hazardous process. The market that you are targeting may have changed or quite often the expectation you have initially predicted did not materialise because you misread the data. However, you can manage the process to avoid going down the wrong path through a process, as advocated in the lean start-up methodology, known as iterate or pivot.

A key element of the lean startup methodology is this concept of a Minimum Viable Product (MVP). In essence, an MVP is a hypothesis you have of the market expectations addressed by your product offering. In other words, you believe that these are the features that the market wants. But you need to put your MVP to test to be certain your hypothesis is true.

There is also a component of MVP, the ‘minimum’ part if you will. This means investing only in features of your product-hypothesis that will help you efficiently, without noisy distraction, discover if features meet market expectations. This means you focus on delivering core business value.

Figure 1, courtesy of Henrik Kniberg’s blog Making sense of MVP, illustrates a goal to build a transportation system to get something from point A to point B. You could start building a skateboard, a motorcycle or a car. If you had built a car to solve the problem when a skateboard would have sufficed or the market could only afford that, you would have wasted effort. Hence, another aspect of the lean startup methodology is to focus on building a solution that you are prepared to “throw away”, if necessary, and build a new product-hypothesis — i.e. iterate — or to offer what you have built to a different market — i.e. pivot.

 
0_hfHeIwcEGoJIUY5w (1)
Figure 1: MVPs for a transportation system.

Back to the scenario of a concert ticket seller, what is the core feature of your product?

Hold that thought for later section of this blog.

What are dematerialized assets and how do they relate to smart contracts?

According to Investopedia:

Dematerialization is the move from physical certificates to electronic bookkeeping. Actual stock certificates are then removed and retired from circulation in exchange for electronic recording.

For the purposes of this blog, I shall use the term dematerialized assets to mean any form of assets that can be represented in digital form without any significant change to its characteristics with no associated physical representation. Example of such assets are currencies, bonds, securities, employment contracts, etc.

Another key feature of dematerialized assets is that they are essentially contracts or legal instruments if properly offered and accepted, binds parties to rights and obligations. A share, for example, is essentially a contract binding its issuer (a company) to give rights to owners of the share, for example, a share in the profits of the company (dividend) according to the terms stipulated in the share’s agreement.

If we continue with the example of a company share, a non-dematerialized version would be a physical share certificate (essentially a token to serve as proof of ownership). In the past, share certificates were the only source of record of ownership and any terms and conditions associated with them. But nowadays share ownerships are digitised and share transactions handled electronically. For example, the London Stock Exchange uses CREST and SETS to register and trade shares respectively. Increasingly rules regarding the transfer of ownership and, for example, the dispensation of dividends are encoded as a series of computerised algorithms. For the purpose of current discussions, we shall refer to the combination of a digital record of ownership and one or more algorithms to enforce any contractual terms (also known as business logic) as a Smart Contract.

In the world of blockchain, you will often hear the term Smart Contract used in lieu of dematerialized assets. Examples of dematerialized assets, implemented in the form of smart contracts, associated with blockchain are cryptocurrencies and, more recently, Security Token Offerings (STOs).

How can we build a concert ticketing system using smart contracts?

Coming back to our concert ticketing scenario. In the tradition of lean-startup, the first step we need to take when building a smart contract based ticketing system is to identify our MVP.

Firstly, identify the rationale for switching to using a smart contract. What is the deficiency in the current system? For example, maybe the current system is too slow reconciling payment from ticket buyers to concert organisers?

Secondly, identify the core features that will make your proposed solution receptive to your target market. In this case, remember the core features of your product are the tickets that you are selling in dematerialized form. This means your initial focus is to get your smart contract business logic right, rather than worrying about the look and feel of the web site or, at the initial stage of your project, non-functional requirements such as security. These can be done later.

Remember you are a ticket seller not a web or cloud development company and your focus is to ensure that your ticketing business logic is up to the mark. If your ticketing terms and conditions do not meet expectations in terms of enforcement, no matter how fantastic your UI is, it will not fulfil your primary mission.

Thirdly, having identified the core features of your product, how do you go about using the most minimal effort to quickly validate the smart contract works as it should? Is there something I can use to enable non-programmers and programmers to understand each other with minimum misunderstanding?

Have you considered using Daml?

Daml is a high-level business process modelling language that is designed to help you create smart contracts. It was created by Digital Asset who also provide developers with a Daml SDK. Digital Asset recently open sourcedDaml and provided a Daml Integration Kit to enable third-party ledger developers to implement a Daml Ledger on top of their distributed ledger or database of choice.

Digital Asset’s Daml-on-X strategy means that a Daml developer can validate their smart contract using a sandbox to simulate transactions then port this so that it runs on their preferred distributed ledger or database.

To use Daml, the first step is to model the semantics behind a contract. Using the ticketing scenario as an example, Figure 2, models an aspect of a contract that is common between parties for all monetary transactions — i.e. cash.

It is worth noting that the cash you use every day to transact for things of value is essentially a contract (typically with three parties involved Central Bank, Payer and Payee).

In Figure 2 below, we assume that once ownership of cash (dematerialized) is transferred between parties cash value is deemed to been have transferred.

template Cash<br>  with<br>    issuer : Party<br>    owner : Party<br>    amount : Decimal<br>  where<br>    signatory issuer<br>    controller owner can<br>    Transfer : ContractId Cash<br>    with newOwner : Party<br>      do create this with owner = newOwner

Figure 2: A Daml representation of a cash-based monetary value.

Next, we model the contractual nature between parties to the concert ticket. This is shown in Figure 3 below. In this case, we have to capture the fact that once someone takes ownership of the ticket she is implicitly entitled to attend the concept. You can add more logic to your smart contract such as entitlement to occupy a certain seat but this is beyond the scope of current discussions.

template TicketAgreement<br>  with<br>    organizer : Party<br>    owner : Party<br>  where<br>    signatory organizer, owner

Figure 3: A Daml representation of a contract between the organiser of the concert and the concert attendees

Finally, to complete the model, we need to capture the contractual relationship between the buyer of the ticket and the concert organizer. In any legal contract, for it to take effect, four elements have to be fulfilled; an offer, acceptance, consideration and intention to create a legal relationship. For the purpose of illustration, Figure 4 models acceptance and consideration as simply one when cash is exchanged, the contract is deemed valid and the parties implicitly create a legal relationship.

template TicketOffer<br>  with<br>    organizer : Party<br>    buyer : Party<br>    price : Decimal<br>  where<br>    signatory organizer<br>    observer buyer<br>    controller buyer can<br>      Accept : ContractId TicketAgreement<br>      with cashId : ContractId Cash<br>      do<br>        cash &lt;- fetch cashId<br>        assert (cash.amount == price)<br>        exercise cashId Transfer with<br>        newOwner = organizer<br>        create TicketAgreement with organizer;<br>        owner = buyer

Figure 4: A Daml representation of the rules governing the offer, acceptance and consideration of a contract.

Figures 2,3 and 4 are in essence your smart contract. However, before you unleash the contract in a production system you will need to test it thoroughly. For that, you can use Daml’s sandbox and create scenarios as shown in Figure 5.

validateTicketPurchase = scenario do<br>  issuer &lt;- getParty “Issuer”<br>  organizer &lt;- getParty “Organizer”<br>  buyer &lt;- getParty “Buyer”<br>  cash &lt;- submit issuer do create Cash with issuer;<br>  owner = buyer; amount = 20.0<br>  offer &lt;- submit organizer do create TicketOffer with<br>     organizer; buyer; price = 20.0<br>  submit buyer do exercise offer Accept with<br>  cashId = cash

Figure 5: Daml scenarios for execution in a sandbox environment.

As you can see, using Daml you can quickly and with minimum effort create and validate your smart contracts. In the ticketing system scenario, this is, in lean startup speak, the MVP. Something you can quickly use to demonstrate the business logic behind the smart contract, unencumbered by the need to build expensive computational infrastructure to perform validation.

Using Daml you can apply lean startup principles of iterative development (produce something that represents the essence of one’s product but not to a point where it is too expensive to be thrown away) or to pivot to a different use case.

Getting Started

To find out more about Daml and to try it for yourself, download the Daml SDK


Acknowledgement

I would like to thank Duncan Johnston-Watt for his help to complete this blog.