Decentralized Orgs - 3/x - DAOs
Next: Decision Making in Desentralised Organisations
It the previous post we discussed tokens that are used to keep state of a decentralized system. This is the first part of a 3 part post series on the DAOs.
TL;DR When you think about it, at core an organisation is really a shared budget, people with different roles and rights and a mechanism of making decisions.
Decentralized Autonomous Organizations are new ways to automate what middle and upper management does in a normal organization, that is the decision making part. DAOs work by principle that anyone can become a worker/contributor and will earn reward based on prelaid and coded principles. Technically DAOs are I code running on some execution environment (today usually blockchain) implementing these rules of engagement.
DAOs
DAOs are as already discussed code on the blockchain that orchestrates human (or machine) activity and sets the rules how rewards are distributed.
The DAO high-level structure is in the image below.
Developers create the user interfaces through which consumers consume the service and contributors make their resources available to users. Developers also write the smart contracts and change them. The DAO smart contracts contain the core logic of the service and handle payments and rewarding.
Payments are divided between the contributors and the Treasury. People who have governance tokens control the policies (for example how much contributors are rewarded vs. Treasury) and where the Treasury money is spent. Governance tokens can be distributed for example to contributors based on the income they have generated and smaller amounts to paying users to incentivise people to join as customers.
Changing smart contracts requires that multiple key holders accept the change as a security measure. It could for example be 5 out of 7 multi-sig meaning that 5 key holders can act together to change the code.
Minimum Viable Organisation
When you think about it, at core an organisation is really a shared budget, people with different roles and rights and a mechanism of making decisions.
Whether that is a governmental organisation or a private one or a short-lived association for a one-off event, they all share the same characteristics. The decision-making system varies, but there is a finite number of alternatives such as a portfolio board, direct or delegated voting and so on. A multitude of other technologies are needed depending on its activities (like manufacturing products, producing concerts etc.) but the essence of any organisation is those three things.
The image below shows the core of any organisation.
Two of the first things for any organisation are creation and funding.
There are two basic ways that DAOs can come about. The first one (product-first) is that we have implicitly been talking all about so far. In it a team forms around an idea and starts developing with own funding or with some seed funding. They usually need to secure additional funding to make the first version ready. Then launch the DAO with tokens and rules for participating with a guideline roadmap for future. In this option a common approach is to start a traditional company, raise funds and develop the approach with private investments to first launch version and then decide how topics like decentralizing decision making and future development ought to happen. This gives focus for the initial push to getting something done.
Second option is that someone starts a community (community-first) around and idea with no clear technical implementation or legal structure in mind. People gather together and collect funds. They also need to agree on the general method of making decisions – governance. Using the governance rules, they can collectively decide a desired direction. Community first sounds good, but getting a large, loose group of people who have never met, have understood the original stated goal slightly differently and may have strong opinions on minor details, to agree on a common plan is easier to said than done. It works best when the goal is really simple.
Funding
Whatever road the DAO takes, development needs money. To start the initial pre-seed funding. As mentioned above, usually initial team puts in their work for free, some of their own money and money from family and friends. If you are good at marketing, your group may also be able to get sizable donations.
More substantial funding comes from angel investors. This phase is called pre-seed or seed (the naming seems to vary and the sums differ greatly).
Many projects also offer grants as a tool to attract developers to use their platform. Your DAO idea may be eligible. Some grants are just free money (i.e, no requirement to use any particular chain).
Convertible debt is like the name says debt an investor gives to the development team. The rules say whether the loaner has rights to convert the loan to shares and in what ratio. SAFE (Simple Agreement on Future Equity) is a variation where valuation happens later.
SAFT is Simple Agreement for Future Tokens is a contract between the developer team and institutional investors about later transfer of tokens to the investors. It includes token model (how many tokens there will be, will the token amount be fixed or not, how tokens will be divided in future between stakeholders like initial team, initial investors, the contributors and users). Has been quite popular.
Token warrants is another option. Warrant is a contract giving right but no obligation to purchase tokens at agreed price. Token warrants may be constructed in many ways and may give both parties an optionality: for the team to issue tokens and for the backers to be rewarded for their contribution. The reason is that especially in early days of creating a new idea or product, it is very hard (read: impossible) to have a good idea how the rules of the token should finally be. During the process as the team gets feedback from market and observes how others in the same field are experimenting, the final model for tokens (called tokenomics) takes place.
When pondering between these options you need legal advice as these alternatives are with varying certainty considered securities subject to regulations. The above most certainly was no legal advice, just observations on current models. Note also that I am not a layer and rules differ between countries. In the US there is so called Howey test whether something is a security or not. https://en.wikipedia.org/wiki/SEC_v._W._J._Howey_Co.
Organisational form
The question what organisational form the DAO should take if any comes up towards the end of the first launch ready solution. During first phase the DAO may be developed inside an existing company as a potential spin-off, a team may have formed a company to develop it or it may be a loose collective of people developing something over the Internet.
A DAO is not recognised by existing national laws making paying taxes, opening bank accounts, signing legal agreements impossible. Without a legal structure it is an unincorporated entity where members are jointly responsible for its actions (at least in some jurisdictions). Members means at least people who write and deploy the DAO code and promote the project, but could also mean all people having governance tokens. At least one such claim is currently ongoing: A legal structure for the DAO provides limited liability to members.
Possible alternatives for the legal structure could be for example Swiss Verain, various LLCs in the US, registering unincorporated nonprofit associations (‘UNA’) in places that recognise such an entity form, Marshall Islands LLC or getting license in Malta.
A legal form also defines dissolution mechanism. What happens to assets when the organisation ceases to exist, how decision about dissolution is made and who makes it.
Now that a team has been formed and some funding is available, it’s time to focus on the actual arrow of action, the service the project offers, how people participate, get charged for using it, roles and responsibilities of participants, revenue split, common purse of the project and decision making.
Since services differ, it is hard to say anything generic except that it is normally crowdsourced and most rewards go to the people who provide the assets. If rules were unfair, someone would create a similar service with better compensations. The moat in web3 is around the community that you can gather around your service and you get it by fair treatment of participants and good quality of service you have. The barriers of entry for new entrants have never been lower.
Onboarding
Since the participants in a DAO can be from anywhere in the world and the number of participants can grow big, an issue naturally arises that how do we bring on new members. How do we transfer knowledge, motivation, customs, ways of working, project culture and so on to new members?
Some of the key constraints and facts are that the practical number of people that can work closely together and be effective is small. About 15 persons on a weekly basis and 5 in daily contact. Also, it is unrealistic that everyone is equally committed and interested in any given project.
A member journey needs to be thought of where people can just lightly try out being a participant and if the project looks interesting, to gradually go into deeper levels of participating. A path could be one where one starts as a participant or just user, then does some small contributions that lead to be a regular contributor and from there to a core team member,
To help in this type of journey a process needs to be created. One could be such that
Just by joining the communications server (usually Discord) you get some tokens
There is a list of small tasks and by doing any of them you will be rewarded more tokens. The easiest tasks would be individual learning tasks, or small helper tasks like translating small texts to a language that you speak
Gradually there are more and bigger tasks and your reputation in the community starts to grow. There may be also NFTs that you acquire as you have reached certain maturity. Remember that reputation is like radioactive waste and has a decay rate. If someone has not participated in say three years, their status is not quit the same as it was at the height.
The high level of transparency in DAOs makes information available but the sheer volume of it is a hindrance. A common practice is to have a messaging service like Discord where all ideas and proposals are openly discussed. When a new person joins, all of the past is available. This is a little bit as if all the internal emails between employees and managers in a company would be immediately visible to new recruits. To get started, some planning is needed so people need where and how to get started to participate in the discussions.
For organisational researchers the future will be easier than ever before as so much information will be freely available.
Token Engineering
How to design a good token model. Most projects so far have created their models with the traditional Stetson-method (It sounded good) or copied models already used. Not necessarily ideal but on the other hand taking inspiration and copying with pride from others are true and tried methods.
How the reward structures and decision-making models are set, and what roles and responsibilities participants have define ultimately the success and downfall of projects. Getting the models right is essential.
It is difficult to see from the models themselves how well they will work in real life. Are the behavioural patterns that allow some part of the participants to gain undue benefit or threaten the system somehow ?
In the crypto-space there is an emerging field called token engineering where the core concept is to put the rules of the system into a model and use simulation to try to detect weak points in the system. These simulations assume nothing about the behaviour of the participants. They do not expect all people to be well informed, make good decision or act in good faith, but with different probabilities to perform all actions allowed by the system. A fleet of simulations with varying starting conditions and probabilities for behaviour is run. The outcome of simulations tells if there are corner-cases disincentivizing good behaviour or rewarding bad.
It is a way of programmatically verifying that the model is sound.
As such the concept is extremely simple as shown in image below but modelling the environment correctly and developing realistic scenarios is the difficult part.
How well simulations can prevent undesirable actions remains to be seen. The assumptions made for the simulation are also programmed and there can be omissions and even errors in the simulation design.
In any system made of humans, the rules of the game are up for change. People form groups and groups combat for power. Once in power, power can be used to change the game as far as the original rule designers allowed and the overall culture of the participants permit (and on the web where people can act behind pseudonyms, come from different cultures and most likely never meet, the cultural barrier is low or non-existent).
Simulations show how the system works with current rules. That’s why rule systems need to be split into “constitutional” part that is on purpose difficult to change and operational parts that are much more flexible.
In later posts we’ll take a look at various mechanisms for voting that aim to solve some of the issues with concentration of voting power to one or few participants etc.
More at: https://tokenengineeringcommunity.github.io/website/docs/academy-welcome/
Payment
For the decentralised organisation to continue working, it needs to capture value created and distribute it back to the participants and perhaps take a small slice to itself for future development.
How this works depends naturally a great deal on the utility that the service provides.
On other hand there are setups like the Plantoid (for refresh see here). They are crowdfunding platforms that produce a series of one-offs depending on customer demand and have no permanent staff. The model is very simple and straightforward – wait->project->wait.
DAOs that produce a continuous service need a different model. Commonly a service is crowdsourced to contributors who bring in their assets for users to consume. The assets could be anything like physical resources (CPU capacity, electricity), funding, work (designing stuff, manufacturing stuff), digital goods etc. The contributors will get almost all of the revenue and small slice is set up for the Treasury. What the funds in Treasury are used for is then decided together at some later point.
Payment tends to be per unit of service – kWh consumed, hours spent, kilometres travelled, Mbytes or time on communications networks, loaned value, amount of purchased data based on data type etc.
Let’s take a short example. For selling a continuous service like water, the smart contracts can implement something called a payment channel. In payment channel, user makes first a deposit to a script address (essentially locking value to an escrow). Service provider checks that user has made a provisional payment and starts providing service. Then per small instalments the user signs receipts allowing the service provider to withdraw money from the escrow. The receipts are cumulative – “I approve 10 cents for water received so far, 20 cents, 30 cents …”. At any time if user is not happy with the service, they just stop signing receipts. Service provider uses the last receipt with highest charge to collect from the smart contract. This closes the payment channel and user gets unused amount back.
This is a trustless payment model where both parties are protected from risk.
That works for many services, but not always. At least it’s uncommon to sell physical paintings per square centimetre. A fixed unit price for them. But programmability of tokens allows all types of experiments - like continuous rewards for creators. Sometimes the price of works increases with time. A DOA that keeps the providence of art work and manages the sales could reward the original artist/author a fixed reward for every price increase (say 15-20%).
Many more experiments are possible. The sale of physical work and digital derivates can be separated. The Art Tuning Company (TATCO) can facilitate the sale of physical work as above and continue tuning away digital abominations for the booming NFT markets.
Your imagination is the limit what can be tried. The rights to design parts of a physical products could also be sold. A DAO selling rights to design PCB board, game engine, game controller, charging station, software for a game console. Buyer/designers earn %-revenue based on console and game sales. This gives incentive to continue improving the software (speed, functions, usability) and the physical design of next generation so that reliability is increased and manufacturing costs reduced.
Or a company selling rare language models (understanding spoken speech) gives models out to developers for free if they agree to a percentage of future sales. They could also give an old model as low priced “Budget Intelligence” so anyone can try out their language models for free and charges those who need a better variant.
Emergency Valve
DAOs can automate the process of governance (how proposals are created, processes and and how decisions are made). An example of a company providing such governance solutions is https://aragon.org/
The one important thing to remember when automating any processes is to let them have an emergency valve concept. One thing we can be sure about the future, is that it will surprise us. It is practically impossible to foresee every corner case, so there needs to be a way to in emergency situations to function outside of automation rules. And this emergency valve concept needs to be well thought so that it cannot be gamed during non-emergency times.
This emergency valve needs to rely on people to figure a way out.
As an analogue, if you (or your loved one) ever gotten bitten by a snake and a friend rushes you to a hospital, obeying speed limits wasn’t perhaps the foremost thought on your mind.
Many things can go astray in DAOs. That’s why you need to think about it at least a little bit. You might for example have a stop-flag in the smart contracts so that you can stop an attacker draining all funds from Treasury should there be a bug in code. This gives the community time to figure out what to do.
Another threat is that someone gains majority vote for the DAO and starts misusing their powers to change rules and drain the project of its funds.
It may be that a community action is the only solution. Blockchain based projects are essentially social contracts and in this ultimate case the, the participants can decide to create a copy of the project and move their project specific token amounts to the new project except the misuser(s). The old project remains but the people who gave it its value through their work and assets continue in a new project. This does not work in all automated scenarios (think of some infrastructure owning itself), but even in that case the society around it could find corrective actions.
To minimise the need for emergency valves, projects should develop defensively. A standard practice for smart contract changes is to first deploy them to a test network and run there for some period. Multi-sigs that require for example 5 out of 7 key holders to approve deployments prevent against any one core key holder being compromised so that attacker gets their keys. And obviously simulations (token engineering) is also a defensive practise.
In the next post we cover decision making models in more details and also cover various innovative ways to attack governance processes of a DAO.
Next: Decision Making in Desentralised Organisations