Merge pull request #248 from metaDAOproject/feat/doc-update

feat: update docs, images, adds alt, links, data

docs/SUMMARY.md

@@ -7,6 +7,7 @@
 * [Creating a DAO](using-the-platform/creating-a-dao.md)
 * [Creating Proposals](using-the-platform/creating-proposals.md)
 * [Trading Proposals](using-the-platform/trading-proposals.md)
+* [Value Resolved Decision Markets](using-the-platform/value-resolved-decision-markets.md)
 
 ## Futarchy
 
@@ -35,6 +36,13 @@
 
 * [Discord](https://discord.gg/metadao)
 * [X](https://x.com/MetaDAOProject)
-* [Blog](https://blog.themetadao.org/)
+* [Blog](https://blog.metadao.fi/)
 * [GitHub](https://github.com/metaDAOproject)
 * [Whitepaper](https://github.com/metaDAOproject/Manifesto/blob/main/Manifesto.pdf)
+* [YouTube](https://www.youtube.com/@metaDAOproject)
+
+## Careers
+
+* [Linkedin](https://linkedin.com/company/metadaoproject)
+* [WellFound](https://wellfound.com/company/metadao)
+* [Job Board](https://jobs.metadao.fi)

docs/book.json

@@ -0,0 +1,12 @@
+{
+  "plugins": [
+    "open-graph"
+  ],
+  "pluginsConfig": {
+    "open-graph": {
+      "baseURL": "https://docs.metadao.fi",
+      "defaultDescription": "Explore MetaDAO's documentation to learn about futarchy, a revolutionary decision-making system. Discover how MetaDAO implements market-based governance to solve traditional voting problems.",
+      "defaultImage": ".gitbook/assets/metadao-og-image.jpg"
+    }
+  }
+}

docs/examples/rubric.md

@@ -0,0 +1,28 @@
+# Example Rubric
+
+ACME Corp is the developer of an innovative L1 blockchain written in FORTRAN. To bootstrap its ecosystem, ACME funds teams who build applications with $100k grants. 
+
+ACME retroactively grades grants on two criteria: project completion and project adoption. Each of these is half the weight of a grant’s score.
+
+<figure><img src="../../.gitbook/assets/rubric-score.png" alt="Scoring Mechanism"><figcaption></figcaption></figure>
+
+## Completion
+Projects can receive a 0 to 0.5 completion score. Here’s how the number is determined:
+
+- 0: this project essentially ran off with the money, releasing nothing publicly.
+- 0.25: this project did not launch but it did develop part of the product; there’s a codebase that another project would be able to use.
+- 0.5: this project fully launched.
+
+## Adoption
+Projects can receive a 0 to 0.5 adoption score. Here’s how the number is determined:
+
+- 0: if it’s a consumer product, 50 people or less have used this product; if it’s a DeFi product, it’s acquired less than $50k in TVL.
+- 0.5: if it’s a consumer product, 500 people or less have used this product; if it’s a DeFi product, it’s acquired less than $500k in TVL.
+- 1: if it’s a consumer product, 2,500 people or more have used it; if it’s a DeFi product, it’s acquired more than $2.5M in TVL.
+
+## Methodology
+Grants are scored by a grants committee of 5 people, 3 from ACME and 2 from MetaDAO. The total score is computed by averaging the scores of the 5 committee members.
+
+## Timeline
+Grants are scored 3 months after the grant has been given.
+

docs/implementation/price-oracle.md

@@ -4,7 +4,7 @@ For futarchy to work, you need a way of extracting the price of a proposal's con
 
 The naive approach is to just use the spot price at the time of proposal finalization. But this is highly manipulable. For example, someone could pump the price of the pass market right before finalization in order to force the proposal to pass.
 
-<figure><img src="../.gitbook/assets/conditional-markets(3).png" alt=""><figcaption><p>Someone could bid up the pass price in the last minute to force a proposal through</p></figcaption></figure>
+<figure><img src="../.gitbook/assets/conditional-markets-dark.png" alt=""><figcaption><p>Someone could bid up the pass price in the last minute to force a proposal through</p></figcaption></figure>
 
 ### TWAP
 
@@ -16,7 +16,7 @@ However, TWAPs also have their flaws. Importantly, Solana validators can manipul
 
 We deal with this by using a special form of TWAP we call a lagging price TWAP. In a lagging price TWAP, the number that gets fed into the TWAP isn't the raw price - it's a number that tries to approximate the price but which can only move a certain amount per update. We call this an _observation_. Each DAO must configure the _first observation_ and _max observation change per update_ that get used in its proposals' markets.
 
-<figure><img src="../.gitbook/assets/image.png" alt=""><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/twap-chart.png" alt=""><figcaption></figcaption></figure>
 
 To take an example, imagine that MetaDAO's first observation is set to $500 and its max change per update is $5. If a proposal opens with a pass market of $550, it will take 10 updates before the observation accurately reflects the price. Assuming each update is spaced evenly and the price stays at $550, the TWAP after 10 updates will be $527.5 (\[$505 + $510 + $515 + $520 + $525 + $530 + $535 + $540 + $545 + $550] / 10). After 10 more updates, it will be $538.75.
 

docs/implementation/program-architecture.md

@@ -14,45 +14,45 @@ Blockchains like Solana don't allow you to revert transactions after they've bee
 
 Conditional tokens are tied to _conditional vaults_. Each conditional vault has a specific _underlying token, settlement authority,_ and _proposal_. In the case of futarchy, the underlying token would be either USDC or the DAO's token, the settlement authority would be the DAO's treasury, and the proposal would be a proposal to the DAO.
 
-<figure><img src="../.gitbook/assets/conditional-vaults.png" alt="" width="563"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/conditional-vaults.png" alt="Conditional Vault Program" width="563"><figcaption></figcaption></figure>
 
 Once a vault is created, anyone can deposit underlying tokens in exchange for conditional tokens. You receive two types of conditional tokens: ones that are redeemable for underlying tokens if the vault is finalized and ones that are redeemable for underlying tokens if the vault is reverted. For example, if you deposit 10 USDC into a vault, you will receive 10 conditional-on-finalize USDC and 10 conditional-on-revert USDC.
 
-<figure><img src="../.gitbook/assets/image (1) (1).png" alt="" width="563"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/conditional-vault-quote.png" alt="Conditional Vault Quote Asset Interaction" width="563"><figcaption></figcaption></figure>
 
 The settlement authority can either _finalize_ or _revert_ a vault.
 
 If the settlement authority finalizes a vault, users can redeem their conditional-on-finalize tokens for underlying tokens. Conversely, if the settlement authority reverts a vault, users can redeem their conditional-on-revert tokens for underlying tokens.
 
-<figure><img src="../.gitbook/assets/image (1) (1) (1).png" alt="" width="563"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/settled-market-conditional-vault.png" alt="Conditional Vault Settlement" width="563"><figcaption></figcaption></figure>
 
 There are two vaults for each proposal: a base vault and a quote vault. The base vault uses the DAO's token as the underlying token, and the quote vault uses USDC as the underlying token. For example, MetaDAO proposals have vaults for META and USDC.
 
 If the proposal passes, both vaults are finalized. If it fails, both are reverted.
 
-<figure><img src="../.gitbook/assets/image (2).png" alt="" width="563"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/conditional-vault-underlying.png" alt="Conditional Vault Underlying Asset Interaction" width="563"><figcaption></figcaption></figure>
 
 This allows us to achieve the desired reverting of trades. For example, if someone mints conditional-on-pass META and trades it for conditional-on-pass USDC, either the proposal will pass and they can redeem conditional-on-pass USDC for USDC or the proposal will fail and they can redeem their conditional-on-fail META for their original META.
 
 So we create two markets per proposal: one where conditional-on-pass META is traded for conditional-on-pass USDC and one where conditional-on-fail META is traded for conditional-on-fail USDC. This allows traders to express opinions like “this token would be worth $112 if the proposal passes, but it’s only worth $105 if the proposal fails.”
 
-<figure><img src="../.gitbook/assets/conditional-markets(1).png" alt="" width="475"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/conditional-markets-interaction.png" alt="Layout Of Conditional Markets Interactions" width="475"><figcaption></figcaption></figure>
 
-### AMM <a href="#conditional-vault-program" id="conditional-vault-program"></a>
+### AMM <a href="#amm" id="amm"></a>
 
 Decision markets are facilitated through a constant-product AMM.&#x20;
 
 Importantly, this AMM provides an on-chain time-weighted average price (TWAP) oracle that can be used by autocrat to determine when to pass or fail proposals. The oracle follows the same design as [Uniswap V2](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles), and uses several additional mechanisms to ensure manipulation-resistance.
 
-### Autocrat <a href="#conditional-vault-program" id="conditional-vault-program"></a>
+### Autocrat <a href="#autocrat" id="autocrat"></a>
 
 The last piece of the puzzle is _autocrat_, the program that orchestrates futarchy.
 
 Anyone can interact with autocrat to create a _proposal_, which contains fields such as a proposal number, proposal description link, and an executable Solana Virtual Machine (SVM) instruction. For example, someone could create a proposal to transfer 150,000 USDC to a development team to improve a product that’s managed by a DAO.
 
 The requisite conditional vaults and markets are created at the same time.
 
-<figure><img src="../.gitbook/assets/image (1).png" alt="" width="563"><figcaption></figcaption></figure>
+<figure><img src="../.gitbook/assets/autocrat-markets.png" alt="The Program Structure For Autocrat" width="563"><figcaption></figcaption></figure>
 
 After a configurable amount of time (3 days by default), anyone can trigger proposal finalization. In finalization, autocrat checks if the TWAP of the pass market is x% higher than the TWAP of the fail market, where x is a DAO-configured threshold.
 

docs/proposal-templates/business-direct-action.md

@@ -0,0 +1,13 @@
+Business Direct Action Template
+
+This is the template you can use for creating business direct action proposals. Just delete this part at the top.
+
+# Proposal x - INSERT NAME HERE
+
+## Overview
+
+A brief description of this proposal. Cover why it's good for the Meta-DAO.
+
+## Financial projections
+
+If you can, cover how this is projected to affect the cash flows and enterprise value of the Meta-DAO.

docs/proposal-templates/business-project.md

@@ -0,0 +1,25 @@
+Business Project Template
+
+This is the template you can use for creating business project proposals. Just delete this part at the top.
+
+# Proposal x - INSERT NAME HERE
+
+**Entrepreneur(s):** insert name(s) here
+
+## Overview
+
+Insert a brief description of the product being built. Be sure to touch on the following:
+- Who the target customer is
+- What problem the product would solve for them
+- How the product would monetize
+- What the key metrics would be (e.g., DAUs, MRR, TVL, volume, etc.)
+
+Also insert a very brief (1-2 sentence) description of how this project relates to the Meta-DAO's business:
+- How much value this could create for the Meta-DAO
+- An estimated budget
+
+## Problem
+
+Talk about what problem the target customer is currently facing. You can prove that this is a problem for the customer in a few different ways:
+- Citing customers complaining (e.g., publicly on Twitter / in DMs)
+- Showing that customers are using other products to solve this problem (in hopefully a worse way t

docs/proposal-templates/operations-direct-action.md

@@ -0,0 +1,17 @@
+Operations Direct Action Template
+
+This is the template you can use for creating operations direct action proposals. Just delete this part at the top.
+
+# Proposal x - INSERT NAME HERE
+
+#### Type
+
+Operations Direct Action
+
+#### Author(s)
+
+{name #1}, {name #2}
+
+## Overview
+
+A brief description of this proposal. Cover why it's good for the Meta-DAO. If the Meta-DAO has previously committed to taking this action, link that committment (e.g., a transaction signature of a passed proposal).

docs/proposal-templates/operations-project.md

@@ -0,0 +1,33 @@
+Operations Project Template
+
+This is the template you can use for creating operations project proposals. Just delete this part at the top.
+
+# Proposal x - INSERT NAME HERE
+
+#### Type
+
+Operations project
+
+#### Entrepreneur(s)
+
+insert name(s) here
+
+## Overview
+
+Insert a brief description of the project. Be sure to touch on the following:
+- What problem the Meta-DAO is currently facing or what metric this project is supposed to improve
+- What this project would do to address the issue or improve the metrics
+- What metrics others can use to measure success
+
+Also insert a very brief (1-2 sentence) description of how this project relates to the Meta-DAO's business:
+- How much value this could create for the Meta-DAO, if applicable
+- An estimated budget
+
+## Focus area
+
+Talk about what problem this project is intended to address or what metrics this project should improve.
+
+## Project
+
+Describe in 1-3 paragraphs what the project would consist of and why it would improve the relevant metrics.
+

docs/using-the-platform/creating-proposals.md

@@ -1,3 +1,18 @@
 # Creating Proposals
 
-TODO
+[Introduction To MetaDAO](https://blog.metadao.fi/a-futards-guide-to-the-meta-dao-7a6b8d66443a)
+
+[Explainer Blog Post](https://blog.metadao.fi/so-you-want-to-raise-a-proposal-2d83304c0b9d)
+
+Business projects are how MetaDAO converts financial capital into revenue-generating products. Business direct actions operate over those products, tweaking parameters in the pursuit of customer satisfaction and profitability. Operations projects and direct actions support the business, ensuring that MetaDAO has the right people and resources to create new products and manage existing ones.
+
+Each of these four proposal types has its own template. These are listed here:
+
+{% content-ref url="../proposal-templates/business-project.md" %} . {% endcontent-ref %}
+{% content-ref url="../proposal-templates/business-direct-action.md" %} Business direct action {% endcontent-ref %}
+{% content-ref url="../proposal-templates/operations-project.md" %} Operations project {% endcontent-ref %}
+{% content-ref url="../proposal-templates/operations-direct-action.md" %} Operations direct action {% endcontent-ref %}
+
+Project proposals should generally be raised by entrepreneurs who are accountable to the DAO for their execution. Direct action proposals can be raised by anyone.
+
+You can use any document app you want to create proposals.

docs/using-the-platform/value-resolved-decision-markets.md

@@ -0,0 +1,61 @@
+# Value Resolved Decision Markets
+MetaDAO's value based decision making program is adaptable for many different applications. In Hanson's paper he proposes we vote on values but bet on beliefs, therefore this is an iterative step in that direction. 
+
+In some cases the underlying value may not be directly measurable (value accretive to the business) but can be measured discretely within a criteria framework, or perhaps many values may be assessed in aggregate.
+
+Hanson's example of GDP, health, leisure, happiness and environment are all examples of measures which could be impacted through the use of this system. While you may not be able to trade health in any practical sense, these specialized contracts payout relative to a future measure against the value.
+
+These markets must be resolved to do so we propose an initial structure in line with current existing committees, boards or members within DAOs. These members would be responsible for executing the measurement as outlined within a robust framework or rubric.
+
+With the advancement of oracles and on-chain data there exists a certain future where the practicality of automated resolution is within reach. However the current implementation is designed around flexibility with the status quo.
+
+What ideas might you want to see evaluated or examples you'd be interested in experimenting with? Join the [MetaDAO Discord](https://discord.gg/metadao) and let us know!
+
+## Examples
+We've designed the product based on consumer demand, but by no means is it constrained to ONLY these examples.
+
+### Grants
+
+The following is a guide for use within a grants program and what will be required from you if you'd like to implement the system.
+
+<figure><img src="../.gitbook/assets/grant-summary.png" alt="Grant Process Overview"><figcaption></figcaption></figure>
+
+#### Pre-requisites
+First, MetaDAO will need the following:
+
+- Rubric: a rubric for evaluating grants’ effectiveness. This is what traders will use to price a grant and determine whether it should be allowed to go through. An example is [here](../examples/rubric.md).
+- Desired minimum liquidity: how much liquidity you’d like to see in a grant market at a minimum. We recommend from $2k to $20k, where minimum liquidity is at least 20% of the average expected size of grant. More liquidity means a stronger incentive to correctly price a market.
+- Desired grant size: how much grantees should be able to request, and whether this is fixed or if there’s a range that grants can request from.
+- Desired threshold: how effective you want the market to rate a grant before it's awarded, based on your criteria. For example, '50%' or '85%.'
+- Trading period: how long the markets will run for. We recommend 3 days.
+
+#### Grant Lifecycle
+<figure><img src="../.gitbook/assets/grant-flow-chart.png" alt="Flow Of  Decision Market For Grants"><figcaption></figcaption></figure>
+In our system, grants go through several stages:
+
+- Ideation
+- Decision market
+- Spot market
+- Resolution
+
+##### Ideation
+First, someone needs to come up with an idea for a prospective grant. Once they’ve determined that they’re willing to do it, they’ll write a grant proposal. This proposal can optionally follow your own template.
+
+##### Decision market
+<figure><img src="../.gitbook/assets/grant-ideation-decision-market.png" alt="Decision Market For Grants"><figcaption></figcaption></figure>
+Once a prospective grantee has written up their grant proposal, we help them create a decision market.
+
+In the decision market, traders trade on what would be the effectiveness score of this grant if it were given?
+
+People can bet that a grant will be effective by buying E-UP tokens. They can bet that a grant will be ineffective by buying E-DOWN tokens. This is analogous to prediction market traders buying YES and NO tokens. E-UP tokens pay out relative to the effectiveness of the grant, and E-DOWN pays out the inverse. For example, if a grant is deemed as 78% effective, E-UP will pay out $0.78 and E-DOWN will pay out $0.22.
+
+The market price of E-UP represents the market’s view on how effective a grant will be.
+
+After the trading period, the grant will be either accepted or rejected. If it’s rejected, all traders get their money back and no money is sent to the grantee. If it’s accepted, the money will be sent by whatever means you prefer (e.g., out of a Squads multisig).
+
+##### Spot market
+<figure><img src="../.gitbook/assets/grant-spot-evaluation.png" alt="Spot Market With Evaulation"><figcaption></figcaption></figure>
+If a grant is given, we leave the E-UP and E-DOWN markets open. This allows traders to liquidate their position if the market has already priced in their beliefs. This also allows the market to continuously evaluate the grantee.
+
+##### Resolution
+After the time period specified in the rubric, the grant is graded. Its score is fed into an oracle so that traders can redeem their E-UP and E-DOWN for cash. This concludes the process and the markets.