Digital Mutuals on the ledger
The world is changing…fast. And those of us who work with distributed ledgers are contributing to this change; we’re changing the shape of the business landscape.
We are replacing existing centralised business models with decentralised applications (Dapps). We see little point in backing these Dapps with a centralised business model, and are instead exploring decentralised governance.
Here, I’d like to introduce the Cordite Digital Mutual that allows us to bring decentralised governance to decentralised business networks. The Cordite Digital Mutual is part of the Cordite open source project. We have also created an FCA registered co-operative society, called Cordite Society Limited, which we are beginning to run on a distributed ledger.
You can watch a video of us running some of the business of the society on Cordite, running on Corda:
A brave new business world…
a shift in the business landscape
We are accustomed to having implicit business models whereby each company builds its own software. A cross-organisational system emerges that requires teams of people to help to reconcile the perceptive differences between the organisations. This is slow and expensive…and we can do so much better!
Cordite allows us to change this. Now we can build decentralised applications that share the code, share the shape of the data and allow us to choose with whom we partially share that data. To do this, though, we have to bring disparate organisations together to build, fund and run decentralised applications.
It is this task that represents a shift in the way that we organise ourselves in the business landscape. The brave new business world, if you like.
From Dapps to DMs
We believe that decentralised ecosystems require decentralised governance.
But organising disparate entities, often competitors, is really hard. How is the eco system funded? Who’s going to build the Dapp? Who’s going to make changes to it? Which set of changes should you make next? We have found it hard to make changes inside a single institution; can you imagine trying to get, say, 10 institutions to agree when to release the next version of the Dapp?!
The Cordite project identified this need. In very basic terms, the code we have built offers lots of different ways to bring institutions together to vote for things that can have a digital consequence. We call this the Digital Mutual module of Cordite, and it is a Corda Application (CorDapp) so it is, itself, a decentralised application.
The Cordite Digital Mutual, or DM, provides the foundation for creating governance, economics and membership models in code. It allows participants to propose and vote for changes to, say, a decentralised application, as well as propose and vote for changes to the DM and its associated rules.
The sky is the limit
So, what can we use these for? Well, anywhere you might want to bring a group of members together who would like to vote on certain sorts of proposals.
For example, imagine if you had a network map service that represented a business network. Since we don’t believe in backing this with a centralised entity, we could spin up a digital mutual to allow the members of the business network to propose and vote for changes to their NMS.
And this example only scratches the surface.
We found that the UK co-operative society is really close to what we were looking to do with a DM. These tend to be used when a group of people want to get together to achieve some thing, without any single one of them wholly owning that thing. And there are plenty of examples in the current world:
- Credit unions. These would be a really good fit now that we have tokens. We could even auto regulate these if we can prove the code that we are running conforms to the regulations.
- Agricultural co-ops. Pooling interests to take products to market together for greater efficiency and bargaining power.
- Investment societies. Where investment decisions are proposed and voted for by its members. Collective Investment Schemes (CIS) are an example of these.
A decentralised co-operative society
We have set up a real, FCA registered co-operative society that will run on Cordite. Its purpose is to govern Cordite, it’s called Cordite Society Limited and it has now been approved by the FCA. This was done with the help of Co-operatives UK, as well as BCB Group, Chronotis, LAB577, R3 and Royal Bank of Scotland.
You can now go right ahead and deploy a Corda node, download the Cordite Cordapps from the R3 marketplace and start your own digital mutual to experiment with digital governance. You can also issue your own tokens and start to define your economic models. Heck, why not come and join Cordite Society Limited? To start with you’ll need your own node on Cordite Test — any issues come and find us on Cordite Slack.
…and breathe!
We have written some open source code that you can use to represent any situation in which a group of members need to vote on something.
These Digital Mutuals represent a really elegant way of bringing organisations together to build, fund and run decentralised apps, without having to resort to a centralised company who is likely to monetise it.
In essence, we have provided decentralised governance. But what’s next?
We have started exploring economic models for these decentralised ecosystems, looking at what might make sense in truly decentralised business networks. From this, we are designing an economics plugin, which among other things, will allow us to vote to issue tokens. More on this, in future posts.
For those interested in developing with this, read on to explore some of the high level technical details of the Digital Mutual with some pretty pictures!
The DigitalMutual
The digital mutual is a CorDapp which means that it is, itself, a decentralised application. In order to be truly decentralised, we cannot have a “DM Node” and instead we have a DigitalMutual Corda State that is shared by the current set of members of the DM. This is shown by the “Implicit Digital Mutual” in the picture below.
At the moment this DigitalMutual stores:
· A name. This is just a string
· A key. This is the formal key for the DM — if you have two DMs with the same name, this will enable differentiation
· A bag of ModelData objects. These allow us to store DM related config (some of which we don’t yet know about yet)
I’d like to propose…
The ProposalState represents the lifecycle of a proposal. The act of voting for a proposal, and understanding whether it can be accepted, is essentially orthogonal to what you are voting for, and as such, the lifecycle is dealt with at the ProposalState level.
The thing which is being voted on, the Proposal, is an interface that can be implemented so that the Proposal represents something specific. For example, a MemberProposal that you can use to add or remove a member from a DM.
If only marriage proposals were this simple!
So, let us recap.
The ProposalState represents the lifecycle of a proposal: creating, voting and accepting. The underlying thing that is being voted on is a specific proposal like a MemberProposal or a ModelDataProposal.
The proposal has some methods on it that allow us to specialise parts of the ProposalState’s lifecycle. The handleAcceptance methods are run if the proposal is accepted, and the verify methods allow the ProposalContract to have Proposal specific behaviour.
For example, if a MemberProposal of type NewMember is accepted, the handleAcceptance methods make sure that the new member is automagically added to the MembershipState exactly once — and this consumes the proposal state. The MemberProposal’s verify methods allow the ProposalContract to check slightly different conditions for NewMembers and RemovedMembers.
My plugin, baby!
A design choice that is emerging at the moment is the plugin architecture. Just about everything in the DM can be thought of as a plugin at this point.
Each plugin:
· Has an instance of a class that implements ModelData. Think of this as a way of signifying that this DM uses a specific plugin, and also as a place to store plugin specific config (see later for minimum number of members example)
· Is likely to have some classes that implement Proposal. And these define what we’re changing or thinking about in a given plugin
· Can have some States in which to store information
· Can have some Contracts to verify the states
· Can have some flows to represent the behaviour. Usually these are run during the proposals’ handle acceptance methods
It’s worth noting that the various plugins are likely to depend on each other in some way, shape or form. We’ve put in a rudimentary eventing mechanism to help with this for the moment.
Currently, the Cordite DM uses the plugin mechanism for membership updates, model data updates, and for economics. There will be some refactoring, but it’s feeling pretty good at the moment.
A specific example might help here…
The MembershipModelData stores a couple of configuration parameters that are used by the rest of the Membership Plugin — the minimum number of members is one of them.
There is a MemberProposal that has a type of either NewMember or RemoveMember. On acceptance it kicks off the ChangeMemberFlow which updates the MembershipState in a way that is verifiable by the MembershipContract.
The handleAcceptance methods also fire a NewMemberModelDataEvent in case any of the other plugins need to respond to this event. This is currently the only event in the system and is listened for by the Economics plugin.
The nice thing about this setup is that anyone can write their own plugin and add it to their DM. Hopefully with very little code.
