update versioned docs folder (automated)

docusaurus/versioned_docs/version-v0.0.11/Glossary.md

@@ -0,0 +1,51 @@
+---
+id: glossary
+slug: /glossary
+title: Glossary
+---
+
+### Seeder
+
+A contract or address that sends reserve token to the `Trust` before distribution starts to bootstrap the ability to trade.
+
+After the distribution completes the seeder is refunded their reserve tokens plus an optional seeder fee.
+
+### Reserve token
+
+The token that exists before the distribution starts and is provided by the seeder to be the other side of the pair in the Balancer pool.
+
+This token is expected to be valuable and liquid so that the creator can fund their creation process with it.
+
+### Redeemable token
+
+The token that is minted by the `Trust` and distributed by trading during the distribution phase.
+
+The redeemable token is frozen (impossible to transfer) after the distribution phase ends.
+
+The redeemable token can be burned for a pro-rata redemption of any erc20 tokens the redeemable token contract itself owns.
+
+### Liquidity Bootstrapping Pool
+
+The 'Liquidity Bootstrapping Pool' (LBP) is a style of AMM developed by Balancer.
+
+It simulates a Dutch Auction through Balancer's spot price mechanism as a combination of weight and relative token amounts.
+
+Empirical evidence from the [PERP token distribution](https://medium.com/balancer-protocol/a-new-paradigm-for-token-distribution-c82de13626bb) indicates this is a decent mechanism to achieve a wider and 'fairer' distribution of tokens than a simple AMM listing.
+
+Fairness is hard to define objectively, but for our purposes we want to:
+
+- Minimise scalping, i.e. users buying early with the intent to sell at a higher price to users who want the token utility
+- Maximise the value unlocked by the distribution in terms of the reserve token
+- Mimimise whales, i.e. users who buy a significant percentage of the total token supply with the intent to manipulate the price paid by users who want the token utility
+- Allow for subjective valuation by users who want the token utility
+- Protect the interests of users who want to hodl the token for its utility
+- Avoid economic exploits that allow users to leverage mechanisms provided by other smart contracts to extract value from the pool for themselves (e.g. flash loan style attacks)
+- Allow for efficient price discovery
+- Mitigate 'front running' where a user (bot) sends orders in advance of (with higher gas than) another trade when it is visible in the mempool but not yet included in a block, in order to force the other user to pay a higher spot price and then immediately dump on this (almost) guaranteed higher price
+
+The [Balancer Whitepaper](https://balancer.finance/whitepaper/) outlines the formulas and proofs (relevant extracts in the comments in this codebase) used to define spot price in terms of amount and weight of each token in the pool.
+
+The target/final weights of the distribution phase give a spot price equal to the book value of the token _assuming no trades_.
+This means the maximum possible dump of the pool at the lowest possible weight (i.e. 100% of all tokens are dumped) is equal to the configured final valuation.
+
+The [Balancer documentation](https://docs.balancer.finance/) is the best reference for more details on how this works.

docusaurus/versioned_docs/version-v0.0.11/Introduction.md

@@ -0,0 +1,84 @@
+---
+id: introduction
+slug: /
+title: Introduction
+---
+
+Rain Protocol supports fair value capture for intangible or physical assets in a permissionless way in any decentralised environment.
+
+We use Balancer's [Liquidity Bootstrapping Pool](https://docs.balancer.finance/smart-contracts/smart-pools/liquidity-bootstrapping-faq) to distribute the tokens.
+
+The goal is to achieve something analogous to KickStarter where specific projects and events are made possible through a one-time fundraising.
+
+## Overview
+
+The basic process is:
+
+- The trust and pools are established with a freshly minted project/event token and some starting capital for trading
+- The liquidity bootstrapping pool is used to distribute the freshly minted tokens
+- The pool is closed
+  - Some of the raised funds are forwarded to the minted token contract
+  - The creator receives the bulk of the raised funds
+  - Some fees are distributed to other stakeholders
+- Any undistributed tokens are burned and all distributed tokens are frozen
+- The creator creates and distributes rewards over time in many ways:
+  - Creating claimable NFTs and other perks that require claimants to hold a minimum balance of the distributed token
+  - Sending erc20 tokens to the distributed token contract that require claimants to burn their tokens to redeem
+  - Hosting real world exclusive events etc. that require claimants to hold a minimum balance of the distributed token to participate
+
+The process requires a high degree of trust between the creator and their fans as there is no on-chain mechanism to enforce delivery of any perks.
+
+The token minting, distribution, burning is all trustless as the deployed `Trust` contract handles construction and ownership of the other contracts.
+
+As each `Trust` is dedicated to a specific project or event there are no admin or upgrade functions. Future versions of `Trust` will simply be picked up by new projects and events as they arise.
+
+The `Trust` has native integration with the `Tier` membership system included as a git submodule. Any account that does not have a minimum membership status cannot receive the distributed token and so cannot participate. This allows additional requirements to be placed on the participants by the deployer of the trust.
+
+## A note on regulatory compliance
+
+Any legal or regulatory requirements such as KYC/AML or securities law are the responsibility of the stakeholders.
+
+The stakeholders are:
+
+- The deployer of the `Trust` contract who provides all the initial configuration parameters and pays the gas for deployment
+- The creator who is raising money to create some new value in the world
+- The token holders who trade tokens during the distribution phase on the Balancer pool and then hold frozen tokens after the distribution finishes
+- The seeder who provides the initial tokens on the other side of the Balancer trading pool to bootstrap trading
+
+Without offering legal advice, one hypothetical way this could look (something like KickStarter):
+
+- The creator and deployer of the `Trust` creates a `Tier` contract that allows only close friends and family to hold a membership status
+- The creator, who is a crypto-enthusiast and musician, decides to hold an intimate "fans only" event, using signatures from the accounts holding a frozen token balance as tickets to her event
+
+As the creator knows all her fans, and the token balances are frozen (cannot be traded on a secondary market), and the reward for holding the tokens is a one-time in person event, it's unlikely to be considered a public sale of an investment contract (for example) or cause KYC issues.
+
+Another situation could be (along the lines of Kiva):
+
+- The creator of the `Trust` lives in a remote village in a poor country and needs a new roof for her house
+- She creates a small social media campaign for her own and surrounding villages to raise the money she needs, and airdrops a cute NFT to everyone who helped
+
+As none of the participants in the system are American, the SEC has no jurisdiction, and the raised money is being used directly to fix a private individual's home so it is not an investment. The NFT has only sentimental value as a "thank you" note between neighbours.
+
+Of course, the same system could be used to facilitate something that is probably regulated by the SEC:
+
+- An American creator and deployer of the `Trust` actively promotes sale of the minted tokens to a global audience
+- The creator uses the raised capital to purchase real estate and regularly airdrops the rent received to all token holders
+
+In this case it is hard to see how the fundraise is not simply a public sale of an investment contract, by an American, for Americans, but with weird extra steps by using `Trust`. The creator, as an American, would need to ensure (presumably offchain somehow) that they are meeting their local regulatory requirements.
+
+The nature of data in a public blockchain is no different to a public Google spreadsheet. That is to say, it has no knowledge of or control over what the numbers and balances it calculates represent in the real world. This can only be made visible and accountable through curation by humans. The `Trust` contract is simply tracking the flow of existing tokens towards the creator and newly minted tokens distributed away from the creator, then frozen so the creator can reference them later.
+
+## Roadmap
+
+Our goal is to build a free and open source system that makes it as easy and affordable as possible for creators to deploy `Trust` contracts that are secure and can meet local laws and regulations, without positioning ourselves as the gatekeeper of every possible use-case.
+
+The current roadmap towards this goal:
+
+- [x] Create the basic contracts needed to facilitate each phase
+- [x] Audit and open source everything in a combined public repository
+- [x] Create factory contracts that register deployed contracts and allow for automatic verification of the authenticity of a `Trust`
+- [ ] Create SDKs and incentives to foster global permissionless CURATION of raises across many independent GUIs, platforms and blockchains
+- [ ] Facilitate Token Lists and Kleros style layers of additional CURATION to protect users and platforms from illicit activities
+- [ ] More KYC/AML tools for creators
+- [ ] More distribution mechanisms
+- [ ] Data analytics and tools for better CURATION