paint-brush
Time, Space, and DACs: The Way Aheadby@Distributed Governance
328 reads
328 reads

Time, Space, and DACs: The Way Ahead

by Kevin LiuJanuary 22nd, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

DAC would be the mainstream value creation entity in the Value Internet Era. It is a combination of the Token Economy, DAC Smart Contract, DevOps, Microservices, and Governance Protocol. DAC is a kind of Smart Organization, which means all the business activities in the DACs are programmable. All these tokens (XT and UT) will be evaluated and priced by the decentralized market. To regulate the relationship among different stakeholders in the collaboration, a new governance model will be introduced to the model (I will bring more details in the next article).

People Mentioned

Mention Thumbnail
Mention Thumbnail

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Time, Space, and DACs: The Way Ahead
Kevin Liu HackerNoon profile picture

While regarding how to form a DAC, people are too optimistic or ideal. It seems DAC will start from scratch by itself when connecting people (it's definitely not, remember the Guild that the Mandalorian has joined, it is a typical DAC, you can see how complicated it is), no clear path was given or discussed so far. DAC would be the mainstream value creation entity in the Value Internet Era.

In my last article, I talked about why the new DAC style organization should be the study focus of the Token Economy. As a new paradigm, we've also noticed that a lot of people have discussed what DAO/DAC is.

You know, just as people could incorporate a limited liability company in only a few days, there should be a handbook to guide how to establish a DAC so that people who have interest could follow the process, design the mechanism, and make it done.

So, today we will present a minimum viable model for building up a DAC, which is a combination of the Token Economy, DAC Smart Contract, DevOps, Microservices, and Governance Protocol.

Some context we should know in advance.

1. DAC will be the primary value creation entity in the value internet era, every of which serves to accomplish a clear business goal.

2. The competitive collaboration among multidisciplinary stakeholders in each DAC and among different DACs is the course of how the value will be created.

3. Although DAC is also a business organization, and I mentioned "forming" a DAC, DAC is not formed. DAC is an organic organization that will grow and evolves in the progress of value creation (stakeholders collaborate to reach consensus).

4. DAC is also a kind of Smart Organization, which means all the business activities in the DACs are programmable. The DAC digests value(input) and produces a new value(output), so the input and output value needs to be digitalized and tokenized.

5. Then, we need to redefine the scope of "Value" because, in the traditional business model, all the economic resources, no matter how many different dimensions they have, will be reduced only to one dimension, which is evaluated by Money. While in the DAC, all the various aspects of value can be recognized and represented (thanks to Blockchain and Cryptoeconomics). Generally speaking, we can define a model containing a simplified two dimensions of "value".

X Token (XT): the mapping of the value in the real world, which can be divided into three categories:

  • Digital Currency: the value representation in payment scenario, i.e., DC/EP, Libra, etc.
  • Digital Asset: the value representation of tokenized assets, i.e., Big Data, Real Estate, etc.
  • Digital Commodity: the value representation of tokenized commodities or its derivatives, i.e., vouchers for picking up, order deposits, etc.

Utility Token (UT): generated by the algorithm, which is the representation of values created in the cyber world.

  • It represents the benefits of DAC community members as the consideration of the work, time, or other resources the community members have contributed in the course of value creation. It also represents the privileges for the UT holding community members to exert in the community operation, governance (e.g., voting power), offering priority of service or products, and the use of data assets.
  • The generating of UT is dependent on the production, exchange, and trading process of XT, but UT is not directly related to the assets in the real world, it is a value-added value. For example, a community member will get a different amount of UT if he is in below value creation scenarios:

Example of UT releasing in different scenarios

6. All these tokens (XT and UT) will be evaluated and priced by the decentralized market, and the value of UT is restricted by XT's value to ensure the credibility of UT.

7. To regulate the relationship among different stakeholders in the collaboration, a new governance model will be introduced to the model (I will bring more details in the next article).

8. We will introduce different Microservice tools into the process to make the value creation activities programmable.

  • A microservice [1] architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use diverse data storage technologies.
  • So, the value creation activities in the real world would be defined as different Microservices, and the execution results will be stored as Data Assets, which are recognizable, auditable, and referable.
  • During the collaboration, community members will use a series of microservice tools to record and store the values they created, such as the open-source tools of data input, data management, data storage, collaborative software, wallet, real-world data connection, etc.

9. The traditional Smart Contract is only a blank template, which offers flexibility but also is very hard to use , just as Conner Brown said[2]. So we upgrade the traditional Smart Contract to the new DAC Smart Contract via introducing DevOps[3] methodology, which includes seven factors:

  • Context: Describe the time and space boundaries of the DAC;
  • Boundaries: When and How the boundaries of the previously defined "Context" could be broken
  • Goals: Mission Statement regarding the detailed problems that DAC aims to solve, and can be broken down to small goals in different stages;
  • Measurable Effects: Conditional statements of the observable implementation outcomes that satisfy the "Goals";
  • Input: Values input into DAC, including XT and UT;
  • Activities: Detailed implementation process, including the production, exchange, and trading of the values, executed by various Microservices;
  • Output: The output value of these activities, acting as the value input for the next step.

Triangle Logic Model

With all the context bearing in mind, the overall logic of growing a DAC is illustrated as a triangle model, in which Time and Space will be connected by the upgraded Smart Contract to trigger the evolution of the DAC.

A new paradigm to form the DAC

So, what do Time and Space stand for?

As for "Time", it means the values in the real world and the cyber world, will be regulated by the traditional law and governance methods (Auditing, Compliance, Tax, etc.), registered on the chain, and represented by XT and UT separately. In this mechanism, Time[4] is seen as an inaccessible coordinate, and the apparent passage of time arises as a consequence of correlations between the subsystems of a global state, while with the global consensus mechanism of the blockchain, these tokens are unique on the chain of time consequence and cannot be tampered with.

As for "Space", it means the business activities in the DAC, which are observable, auditable, and can be processed through various microservices.

The "Smart Contract" is used to connect "time" and "space" to complete the business activities in the DAC, but this is not a one-way process of assigning tasks and execution tasks, it's a DevOps process of continuous integration, delivery, and improvement.

DAC Smart Contract Template

It is a complicated procedure to accomplish the business goals for a DAC, and each step (containing one or more microservices) in the process can be administered by the DAC Smart Contract, with clear goals and observable, measurable outcomes, and the output will become the input for the next step, so all the business activities are connected, and that's the way a DAC can initiate.

In the value creation activities, the community members implement different tasks by contributing time and resources. As a result, they will get UT as the incentives, and the more they help, the more UT they can get.

UT holders will have the right to get involved with the DAC operation, governance, and the use of community data assets. This is a virtuous circle, which will incentivize people to join the community, to reach the consensus, and to contribute.

That's the way a DAC can grow its consensus community.

With the contribution and feedback from the participated community members, the complicated process will be templated and marked as data assets for all the members to refer, to optimize, which will significantly facilitate the communication and collaboration among community members, and that's the way a DAC can develop and evolve.

Token Economic Model of DAC

UT is generated during the process of microservices dealing with XT, so the relationship between XT and UT is not independent but coupled. Whether a token economic model is well-founded for a DAC depends on the interaction design between XT and UT.

DAC Token Economic Model

Firstly, UT can facilitate value creation for XT. With the existence of UT, the contribution of community members will no longer be measured randomly, and holding different amounts of UT will have different kinds of rights to exert over the XT, such as the priority in trading and picking up the products represented by XT, discount on transaction fees, etc.

So, UT will encourage community members to participate in the value production process of XT.

Secondly, the holding and trading of UT in the market will influence the pricing of XT, which means UT will act as a price evaluator for XT in some circumstances. If the longer in time, the more in quantity that a community member holds the UT, the more discounts he can get for purchasing the XT, then whether he would like to keep UT will be an index for judging the demand of XT, just like the interaction between the spot market and futures market in the traditional finance.

If a plenty number of community members would like to hold UT, which reflects in the market is the price of UT is getting higher, and it also shows that the demands for XT are also very high, then the price of XT will increase as well.

When people find it profitable for holding UT and XT, more and more people will join the community and participate in the value creation activities, and that's the virtuous circle.

So, key takeaways, to grow a DAC from the beginning, you will need to define the goals and measurable outcomes for the DAC, and what the XT and UT are within your DAC, what kind of business activities can be categorized as Microservices, what type of process you will follow in the execution of XT, and then compose these context into the DAC smart contract.

Of course, you also should design the token economic model to regulate the relationship between XT and UT. Just as the Mandalorian said, this is the way.

In the next article, I will give more details on the governance protocol, and also present two use cases. Please stay tuned!

References:

[1] https://martinfowler.com/articles/microservices.html#footnote-etymology

[2] https://medium.com/@Conner_/bitcoin-the-blockchain-for-truly-smart-contracts-f7100b73da01

[3] https://en.wikipedia.org/wiki/DevOps

[4]https://royalsocietypublishing.org/doi/10.1098/rspa.2019.0470

(Contributed by Kevin Liu from Metis Lab)