147 lines
4.2 KiB
Markdown
147 lines
4.2 KiB
Markdown
A DAO is a group of cooperating entities.
|
||
|
||
If we're running our own network, it probably makes sense to consider nodes as the participants.
|
||
|
||
If we're running as smart contracts, it probably makes sense to consider individual addresses as the participants.
|
||
|
||
These schemes overlap, since both involve asymmetric keys.
|
||
|
||
Each node must validate the work of the other nodes
|
||
|
||
Our protocol will be a peer protocol, and will rely on signatures.
|
||
|
||
Therefore we arrive at a requirement for nodes: they must be physically secured so that private keys are protected.
|
||
|
||
We also arrive at a requirement for our network protocol: It must be possible to sign messages and verify message signatures against known public keys.
|
||
|
||
The network protocol MAY support asking peers about other peers / telling other peers about peers.
|
||
|
||
IF we support this IT SHALL BE linked with each node's reputation.
|
||
|
||
CAN WE SAY that each node MUST maintain A VIEW of THE ENTIRE / (THE CURRENT) / (ALL / CURRENT) HASHES / MERKLE TREE / -- World state, History
|
||
|
||
CAN WE GET AWAY WITH ONLY SAYING that each node maintains its own view.
|
||
|
||
WHAT is our protocol for evaluating the perspectives offered by peers?
|
||
|
||
- If one node perceives consensus among many others, that may sway their opinion.
|
||
|
||
- There may be opportunity during "informal voting" / non-binding validation pools (low tokenLossRatio) to gather this sort of information.
|
||
|
||
- If there is exact agreement, we have a very efficient case.
|
||
|
||
- If there is the HOPE of exact agreement, mistakes and attacks can be costly
|
||
|
||
- If there is an EXPECTATION of exact agreement, there must be externalities supporting that agreement, i.e. a common protocol and governance of that protocol.
|
||
|
||
---
|
||
|
||
# Internal operations
|
||
|
||
## Expert starts new DAO
|
||
|
||
```mermaid
|
||
graph
|
||
|
||
subgraph EOA
|
||
expert(Expert)
|
||
end
|
||
|
||
subgraph Contracts
|
||
forum(Forum)
|
||
pool(Pool)
|
||
end
|
||
|
||
expert -- Post --> forum
|
||
expert -- Fee $ --> pool
|
||
|
||
```
|
||
|
||
## Expert joins existing DAO
|
||
|
||
```mermaid
|
||
graph
|
||
|
||
subgraph EOA
|
||
expert(Expert)
|
||
peers(Peers)
|
||
end
|
||
|
||
subgraph Contracts
|
||
forum(Forum)
|
||
pool(Pool)
|
||
end
|
||
|
||
expert -- 1. Post --> forum
|
||
expert -- 2. Fee $ --> pool
|
||
peers -- 3. Stake ℝ<br />to approve --> pool
|
||
```
|
||
|
||
## Expert submits governance post
|
||
|
||
A governance post can be considered one that is respected in some way by the operations of the [Client/UI](./client-or-ui.md).
|
||
|
||
This is a broad class of posts.
|
||
|
||
Each type of governance post can be individually (or by category?) handled by the business contract for a given DAO.
|
||
|
||
```mermaid
|
||
graph
|
||
|
||
subgraph EOA
|
||
expert(Expert)
|
||
peers(Peers)
|
||
end
|
||
|
||
subgraph Contracts
|
||
forum(Forum)
|
||
pool(Pool)
|
||
business(Business)
|
||
end
|
||
|
||
expert -- 1. Stake ℝ on<br />governance post --> business
|
||
business -- 2. Post --> forum
|
||
business -- 2. Fee $ from<br />internal fund? --> pool
|
||
peers -- 3. Stake ℝ<br />to approve --> pool
|
||
pool -- 4. Validate --> forum
|
||
```
|
||
|
||
Forum usage is open-ended.
|
||
DAO protocol consists of core contracts + client behaviors.
|
||
Core contracts provide resilience to attacks, since reputation minting is financially backed by future income
|
||
|
||
Question: What does the DAO do with funds it receives?
|
||
Awswer: Distributes the funds to members immediately upon resolution of the reputation effects of a funded validation pool.
|
||
|
||
---
|
||
|
||
Before we delve into example use cases, we need to talk about the [Client/UI](./client-or-ui.md), and make sure we have
|
||
a sound understanding of how client/ui behaviors interact with the core of the system.
|
||
|
||
---
|
||
|
||
The forum, pool, business, and availability contracts all work together to express a single DAO.
|
||
|
||
Each post in the forum can be its own new DAO
|
||
|
||
What it would take for that to happen:
|
||
|
||
The seed of the new DAO becomes the tokens minted by that post DAO when it receives fees.
|
||
|
||
When will it receive fees? When submitted to its business contract interface.
|
||
|
||
What happens then? Work is assigned via availability stakes.
|
||
|
||
Meaning that someone has staked reputation.
|
||
|
||
Meaning that they had previously been awarded reputation.
|
||
|
||
The business contract, or the DAO, or the seed post, must be able to accept an initial fee
|
||
to mint the reputation of the first expert.
|
||
|
||
Then, that expert can stake their reputation on availability to perform the work expressed by the post and its associated business contract.
|
||
|
||
These operations can be consolidated.
|
||
|
||
When submitting a post to the forum, you may include an optional fee
|