...by Daniel Szego
quote
"On a long enough timeline we will all become Satoshi Nakamoto.."
Daniel Szego

Monday, December 12, 2016

Financial Framework for Decentralised Business Process Management


Setting up a financial framework for analysing DBPM (Decentralised Business Process Management) we are going to use the following considerations: 
From a unit economical point of view the most important element that directly carries the cost and indirectly generates revenue is an atomic t transaction. A p process is set up as executing and validating a sequence of t transactions.

In the business model, we distinguish two levels of the business. Core platform is responsible for executing decentralised transactions and processes. On the top of the core platform industry specific solutions can be delivered with the help of partner companies. On a long run industry specific solutions could be implemented directly by partner companies, however it is probably not realistic on a short run. As a consequence initial financial models consider both the development of the core platform and some of the industry specific solutions.
Costs structure is based on the following elements [Figure 1]:

1.    Variable cost:

a.  CoGS is mostly based on executing and validating the transactions on a decentralised consensus. It can be easily scale up or down depending on the customer needs. As opposed to a general Turing complete Blockchain system where executing a transaction might be pretty expensive due to the possibility of the infinite loops, at DBPM runtime of the atomic transactions are always limited from above, implying O(|T|) execution cost for a set of T transactions. The exact cost pretty much depends on the consensus mechanism, implying different numbers at proof of work, at proof of stake or at majority voting.

b.  CoGS is also influenced by storing the states of the validated transactions of a p process. It is manifested as a general storage cost that will be increased as the process itself is used. It requires further considerations if the whole state between two transactions is directly and fully stored in the Blockchain itself or rather off-chain solution might be used and only hash of the state is stored in the Blockchain.

c.  Supporting the system to partner companies or end-users is manifested as an additional variable cost.           

2.   Fix cost factors are mainly the SG&A expenses for running the company itself. As the primary focus is on the partner business, the most important is the professional business development as CAC.

3.    Investment: For a successfully start both the core framework and the first two or three industry specific solutions must be ready. They requires a certain amount of development and initial investment.

Revenue structure has the following factors [Figure 1]:

1.   Core services: customers get the value of using a certain business process itself. As executing a business process practically means executing a set of state changing transactions, it makes sense to charge money after transactions.

2.     Extended services might be possible as well, as providing training or consulting. It might be however a possibility that the company concentrates only core functionalities and every extended service is provided only by partner companies.


Figure 5. General cash-flow schema.