A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
- John Gall, Systemantics: How Systems Really Work and How They Fail
We’ve been trying to answer the question “what is a DAO?”.
Sounds like a dumb question at face value. Our team has been working and building in the crypto space for years. If we don’t know what a DAO is by now we’re most certainly ngmi.
But: ask any random Crypto Twitter addict to answer “what is a DAO?”, and you’ll get different answers from one anon to the next. Those answers usually involve some kind of treasury. They usually involve some kind of voting mechanism. They usually involve one or more off-chain tools as well.
The answer is not so black and white. Nor should it be! The emergence of DAOs as organizational structures is still very new and raw — different models will evolve for different use cases, risk profiles, and community needs.
The core essence of a DAO is a structure that lives on-chain, is autonomous (duh), and describes a set of permissions.
That’s it really.
A DAO needs a unique identity. In the EVM world that means it needs its own unique address. A DAO is realized as a simple deployed smart contract.
A DAO could choose to own an ENS name that resolves to its address, giving it a truly personalized identity.
A DAO needs a way to perform actions on-chain, from the point of view of the rest of the contracts and addresses on the EVM.
Therefore, it should contain a function that accepts arbitrary data and acts as a proxy to execute that data. “That data” might be things like:
To tie the above points together (and infinitely extend its functionality), it needs to be the source of truth for a robust and flexible set of permissions.
Who can call this magical “execute” proxy function, which enables a DAO to behave on-chain?
Should it be a single EOA? Could be.
Should it be a multisig wallet? Could be.
Should it be a contract that implements quadratic voting? Could be.
Should it be some combination of those? Could be.
Should it be something no one has thought of yet? Could be.
What about when a “treasury”, or “fundraising”, or “payroll” functionality needs to get added to this DAO? Each of these modules can exist as their own contract, with their own design decisions and sets of concerns. The only thing that matters is that the DAO they’re attached to acts as the source of truth for defining how these contracts interact with each other and the core DAO, and that these contracts reference the DAO’s permissions (it is the source of truth, after all) when their code is executing.
This simple structure provides infinite use cases and functionality. Any complex organizational structure can be achieved by composing these Minimum Viable DAOs together and extending them with functional modules appropriately.
The Minimum Viable DAO is a DAO, distilled. Only when the purest form a DAO is understood, can useful organizations be built with it.