New (improved) definition of a Continuous Organization


#1

After digging more and more (and talking to many people) around the concept of Continuous Organization, it recently occurred to me that the definition of a Continuous Organization as it is today could be refined.

Indeed, I had a few problems with the actual description of what is a Continuous Organization. Here are some of them:

1. Governance

Governance is a probably the most difficult topic there is in any organization. There is no such thing as a perfect governance mechanism, there are just governance mechanisms that are better adapted than others depending on the context and the culture of the organization.

De facto, with Continuous Organizations, I did not want to mess with governance or try to (re)invent a better governance system. Some organizations have strong hierarchies, some are more flat, some are democratic, holacratic etc… COs should be compatible with all these types of governance and should not impose a new governance structure or model.

2. Trust

I was also having issues with the modifiability of the parameters of the smart-contract. If the parameters can be changed, it surfaces a lot of questions: Who can change them? How? Under which conditions? Etc… so having the smart-contract updatable basically required to then implement a governance model, which I did not want (see above). So the parameters of a CO should be immutable, a trust smart-contract in the purest sense of the term.

3. Simplicity

I am a big fan of simple things. Simple things can be explained easily. Simple things are also easier to create and to secure. If I can’t explain something easily then I have a problem. The current definition of Continuous Organizations is a problem because it is hard to explain. To make things simpler, there are 2 solutions: (a) actually simplify the damn thing and (b) find a good analogy (hence my interest in the Trust analogy). COs should be (reasonably) easy to explain.

So here is the new (hopefully) improved draft definition:


A Continuous Organisations (CO) is an organization (or several organizations) which delegates the management of its cash-flows (revenues and investments) to a Decentralized Autonomous Trust (DAT). A DAT is a smart-contract that automatically mints , burns and distributes tokens according to predefined immutable functions .

  • When a DAT receives an investment in ETH (or a stablecoin like DAI), the DAT mints new "DAT tokens" (DATT) and send them to the buying investor. The sum invested is in part distributed to the benefiting organization and in part saved in the DAT "buy-back" reserve according to a pre-defined immutable function I (for i nvestment ).

  • When the DAT receives revenues from a sale, the DAT mints new tokens and distributes them among the beneficiaries and the organization according to a pre-defined immutable function D (for d ividends ). The revenues perceived are in part distributed to the benefiting organization and in part saved in the DAT "buy-back" reserve according to a pre-defined immutable function R (for r evenues ).

  • When the DAT receives tokens (DATTs), the DAT burns the received DATTs and sends ETH back to the selling investor according to a pre-defined immutable function S (for s ell). The ETH sent back to the investor is taken from the DAT “buy-back” reserve and does not affect the organization’s cash reserve.

The pre-defined functions for minting and burning DATTs follow the bonded curve model, with sponsored burning creating incentives for investors to buy and hold DATTs while funding the beneficiary organization until it starts generating revenues.

Concretely:

  1. pre-revenue . Before the organization generates any revenue, the price appreciation of DATTs is due to investors’ speculation in anticipation of future revenues.

  2. post-revenues . Once revenues begin to flow, the price appreciation of DATTs starts being driven by the revenues generated by the organization. Those revenues not only apply a constant buying pressure but are also generates DATTs dividends for the current DATTs token holders.

Fully decentralized

The functions parameters of a DAT are immutable (i.e. they cannot be changed once the DAT is created) so there is (almost) no governance required. The main case requiring governance is the case of sub-optimal parameters . If the parameters of the DAT are obviously flawed and the token holders want to swap their tokens to a new DAT with better suited parameters. A new DAT can be created with parameters more suited for the organization and the switch from the old DAT to the new DAT put to a vote. If the vote passes, the old DAT will transfer its reserve and outstanding tokens to the new DAT and shut itself down.

Incentivizing long term investors

To incentivize long term token holders, the DAT have a dividend bonus mechanism that enable long-term token holders to enjoy a higher dividend than short term token holders. The proposed mechanism is the following: every month you hold a DATT gives you an increased dividend bonus until the maximum dividend bonus M is reached after holding your DATT for H months. When a DATT is sold or transfered, M is reset to 0.



#2

Very interesting. In regards to the old DAT token transfer, do you have an example of this being implemented in a safe way, programmatically?

The concern that I have, is that to include this transfer function, there needs to be a function somewhere that takes ETH from one contract, and moves it to another. Who/what gets to call that function? Is it an admin? What happens if the key gets lost? What happens if the admin transfers it to a new address?

I think there is much research to be done on proper upgrade patterns for a DAT. As of now, I find all of them to be to unsatisfactory from a programmatic safety perspective - and possibly open the door to liability issues.


#3

I agree with you: there is much research to be done on proper upgrade patterns for a DAT. I have no safe way to propose at this stage. This is why, until progress is made on that front, DATs will be fully immutable.
Thanks for your input (and sorry for the late reply)!