Merge Tribeca docs into Saber docs

docs/07-tribeca/01-intro/01-introduction.md

@@ -0,0 +1,25 @@
+---
+title: Introduction
+---
+
+## What is Tribeca?
+
+**Tribeca is an open source protocol for launching decentralized autonomous organizations on Solana.** It is heavily inspired by the designs of [Compound](https://compound.finance/docs/governance) and [Curve](https://curve.readthedocs.io/dao-vecrv.html) governance.
+
+The protocol runs on three programs: `smart_wallet`, `govern` and an electorate program (by default `locked_voter`). Together, these three programs are called **The Tribeca Trinity**. These are three separate programs that may be owned and governed by three separate parties. This system distributes the risk of failure across several components, maximizing flexibility and permitting upgradeability while minimizing smart contract risk.
+
+![alt text](https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdIVFli1E0ZyBv3c7e0Yh%2Fuploads%2FT3uiD4a3CPy259NEKRdB%2FTribecaDAO_1.png?alt=media&token=aa9601cf-01cd-46e5-a8ac-d630038d2c88)
+
+The Tribeca Protocol is built and maintained by members of the Tribeca DAO - which is comprised of members of Solana's leading protocols. The Tribeca DAO also maintains a frontend for DAOs to use at [tribeca.so](https://tribeca.so), which is free and open for any DAO to use.
+
+## Why Tribeca?
+
+Solana applications have historically been relatively centralized compared to their counterparts on Ethereum. Smart contract code is often closed source, and programs are freely upgradeable by teams. We believe the main reason for this is that it is simply too hard to create code in an open and decentralized way due to lack of common tooling for teams to use.
+
+Tribeca attempts to solve this problem by creating a powerful yet extensible framework for governance. The initial release of Tribeca features an on-chain voting system coupled with a system to create and manage proposals, similar to Compound. It also features an optional primitive for vote-locking tokens to encourage long term staking, similar to veCRV.
+
+Our mission is to increase the decentralization of the Solana network; that is, to make it cost-prohibitive to take down a protocol. By offering high quality governance products to all protocols, we believe that more protocols will default to giving more power to their users; that is, teams will launch tokens faster as the barriers to creating DAOs drop dramatically.
+
+## Disclaimer
+
+All claims, content, designs, algorithms, estimates, roadmaps, specifications, and performance measurements described in this project are done with the author's best effort. It is up to the reader to check and validate their accuracy and truthfulness. Furthermore, nothing in this project constitutes a solicitation for investment.

docs/07-tribeca/01-intro/02-tribeca-dao.md

@@ -0,0 +1,17 @@
+---
+title: Tribeca DAO
+---
+
+Tribeca is an open source governance primitive built and maintained by the Tribeca DAO, a decentralized autonomous organization (DAO) consisting of members of Solana's leading protocols. The DAO consists of members of Solana's leading protocols. At the time of writing, all programs are currently owned by the Tribeca DAO Smart Wallet.
+
+There is currently a plan to migrate the program ownership to the Saber DAO.
+
+All programs are deployed on `mainnet-beta` and `devnet` and are verified on the [Anchor verified build system](https://anchor.projectserum.com/).
+
+## Members
+
+The current members of the Tribeca DAO may be viewed on [tribeca.so](https://tribeca.so).
+
+### Joining the DAO
+
+If you are building a protocol on Solana and are interested in becoming a member of the DAO, [please fill out this form.](https://forms.gle/i1b8WNZvFEP637v96)

docs/07-tribeca/01-intro/03-comparisons.md

@@ -0,0 +1,46 @@
+---
+title: Comparisons to other governance systems
+---
+
+## Comparison to Compound-style balance snapshots
+
+The Compound snapshot-based model is not easy to implement on Solana: it requires balance snapshots to ensure that users do not obtain tokens, vote, then subsequently withdraw tokens. However, Solana accounts have a fixed-size: they cannot store a variable length array of previous balances to figure out how many tokens a user had at a specific block.
+
+There are ways around this, for example a paged account system; however, Solana storage (rent) is very expensive and this would make governance unusable for voters that may not have much SOL.
+
+## Comparison with SPL Governance?
+
+Tribeca differs from the [SPL Governance program](https://github.com/solana-labs/solana-program-library/tree/master/governance) in several ways:
+
+- **Built with Anchor.** Tribeca is pluggable with other Anchor-based projects and tools, allowing for simpler composability.
+- **Modularity.** Tribeca is built to be flexible and extensible, splitting out proposals/voting, transaction execution, and staking into three separate programs.
+- **Hosted.** The Tribeca DAO program is meant to be deployed as one instance of a program, similar to the [SPL Token Program](https://spl.solana.com/token). It is an open standard that any other project can build upon, without requiring teams to deploy their own DAO or giving custody of user tokens to Tribeca.
+- **Simplicity.** Tribeca does as little as possible, giving DAOs the freedom to choose how their governance system operates.
+
+Below is a quote from the [Architecture Overview](https://github.com/solana-labs/solana-program-library/tree/master/governance) of the SPL Governance Readme:
+
+> The program is modular and uses open/close architecture where individual parts of the program's behavior can be customized through external plugins.
+> For example the default implementation of the program takes deposits of the governance tokens in exchange for voting power but it can be swapped with a custom program implementation which can implement any custom requirements like token locking, token escrows, NFT voting or multi token governance structures.
+> The plugins are ordinary Solana programs and can be written using any supporting technology like Anchor framework for example.
+
+Crucially, it is worth noting that in Tribeca there's no need for a DAO to have to deploy its own instance of the entire protocol, but rather the DAO can edit the Electorate program **in isolation** to implement custom requirements. The govern and smart wallet programs are both **standard programs** for governance processes that **do not change across DAOs.** The aim is to operate similarly to the SPL Token Program, which is a widely trusted frozen standard that others can build on top of. SPL Governance has a default program, but it is not modular: it either requires being forked or being constantly upgraded to fit custom use cases.
+
+Modularity, however, is where Solana's largest benefit due to its stateless program architecture. Solana programs are meant to be deployed as singletons which serve as trusted code, rather than arbitrary code execution which causes most of the hacks on Ethereum.
+
+The Electorate determines what is defined as a vote, what is the requirement to activate a proposal, and is the **only contract that can access user-owned assets.** The govern program is a static standard that handles votes and proposals, then sends passed proposals to the smart wallet. The smart wallet executes passed proposals, and can be programmed upon creation and through multisig actions. **Static Standards are thus the best way to trustlessly provide security for the DAO ecosystem.**
+
+The recommended configuration of Tribeca has a **Locked voter escrow** as the default Electorate. It has parameters, such as min/max stake duration and voting escrow multiplier - which allow users to customize without having to deploy their own instance of the program. For more complex requirements- such as NFT-based voting or linear unlocks- DAO operators can use custom Electorate programs and still guarantee the safety of the static Tribeca Protocol instance it's built on.
+
+There are also a number of cryptoeconomic exploits on the existing default implementation of SPL Governance - such as MEV vote manipulation/ flash loans, and just-in-time voting.
+
+- **Just-in-time voting.** An entity may borrow large amounts of a governance token to vote a minute before a vote expires, then immediately pay them back. We have seen this type of voting in the Serum DAO, one of the earliest SPL Governance DAOs on Solana.
+- **MEV vote manipulation/ flash loans.** Colluding validators could be paid by a flash loan protocol to enforce loans of a duration of one block, and due to Solana having a known slot leader order, it is possible for validators to ensure that there are no blocks mined between their slots. Projects such as Jito Labs are already in development to make this possible.
+
+These attacks are not possible within the voting escrow system due to vote weight being a function of lockup duration.
+
+Furthermore, Tribeca possesses a few additional features out of the box:
+
+- **Gauges.** Integrations with [Quarry](https://app.quarry.so/) protocol allow users to vote on relative weights of emission rewards across mining pools.
+- **Payments.** Integrations with [Venko](https://venko.app/) allow proposals to issue grants by triggering token streams that are highly configurable (conditional, token cliffs)
+- **SAVE-tokens.** Instead of only having the option to issue normal governance tokens, Tribeca allows DAO operators to issue governance tokens that must be staked for a minimum duration. This reduces sell pressure from grants, and aligns SAVE recipients with the DAO.
+- **Permalocking.** Tribeca also allows DAOs to issue permalocked tokens, which can never be unstaked since the Tribeca DAO program will automatically refresh the voter escrow to the max lockup period.

docs/07-tribeca/01-intro/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Tribeca",
+  "collapsed": false
+}

docs/07-tribeca/02-governor/01-overview.md

@@ -0,0 +1,54 @@
+---
+title: Overview
+---
+
+A **Governor** represents a collection of votes on proposals, and determines which proposals may be executed.
+
+The Governor **does not** have custody of user-supplied assets: its only purpose is to create a standard interface for governance. This is an intentional design to allow the Governor to be composable with other systems. The electorate program which has custody of user-supplied assets, is the account which controls the Governor.
+
+The Governor also **does not** have the authority to execute proposals: it instead queues them for execution by a Smart Wallet. The Smart Wallet's owners handle the execution, so governance cannot execute.
+
+Governors are owned by the [Govern program](https://crates.io/crates/govern). Its program upgrade keys are currently managed by the Tribeca Alliance; however, it may be locked once Anchor is more stable. The Govern program is intended to be thought of in the same way as the [SPL Token program](https://spl.solana.com/token): it is a standard interface for voting and will eventually be frozen.
+
+## Parameters
+
+Governors are provisioned with _parameters_. The DAO may vote to modify these parameters in the future.
+
+### Voting Delay
+
+The number of seconds to wait before voting on a proposal may begin. This value is added to the `created_at` timestamp of a proposal to determine a proposal's earliest activation time.
+
+### Voting Period
+
+The duration of voting on a proposal, in seconds.
+
+### Quorum Votes
+
+The required minimum number of votes for a proposal to make the voting proceeding valid.
+
+### Timelock Delay
+
+Time delay in seconds from which a proposal's transaction can be executed after it has been queued. This parameter denotes the least amount of notice possible for a governance action.
+
+## Electorate
+
+The **Electorate** is an account which controls the Governor. It can perform two actions:
+
+- **Activate proposals**, which moves proposals to a state where they can be voted on
+- **Set votes**, which logs the number of votes a voter has made on a proposal, and which side of the vote that voter is on
+
+Electorates may be user-defined programs, since they perform signed cross-program invocations on the Govern program. One example of an Electorate is a [Voting Escrow Locker](../electorate/voting-escrow).
+
+## The Trinity
+
+The **Tribeca Trinity** refers to the three components of the Tribeca governance system: the Governor, the [Goki Smart Wallet](../goki/smart-wallet), and Electorate. These are three separate programs that may be owned and governed by three separate parties.
+
+The Trinity is one system existing in three substantial parts. This system distributes the risk of failure across several components, maximizing flexibility and permitting upgradeability while minimizing smart contract risk.
+
+### Analogs to Compound
+
+The three components of Tribeca are analogous to the three components of [Compound's governance system](https://compound.finance/docs/governance):
+
+- Governor = Compound's Governor
+- Smart Wallet = Compound's Timelock
+- Electorate = Compound's COMP token

docs/07-tribeca/02-governor/02-proposals.md

@@ -0,0 +1,39 @@
+---
+title: Proposals
+---
+
+A Proposal allows members of the DAO to interact with the blockchain. E.g., A proposal can trigger a variety of Transactions on the blockchain which can do any of the following:
+
+- Sign memos, attesting a message on the blockchain forever;
+- Create and manage payment streams for grants;
+- Issue or mint new tokens;
+- Change emissions rate for liquidity mining;
+- Edit parameters to governance program.
+
+Proposals may be voted on by locked voters. Proposals which pass the DAO vote are queued and executed in a Goki Smart Wallet. In other words, votes are defined by the electorate, but managed by the governor.
+
+The proposal's activator must hold more veTOK than the current proposal threshold, which is also called the activation vote #`governor.params.proposal_activation_min_votes`. The proposal's instructions must also fit within a single transaction.
+
+## Lifecycle
+
+### Draft
+
+Anyone can create a proposal on Tribeca. When a governance proposal is created, it is considered a "draft" and enters a review period, after which voting weights are recorded and voting begins.
+
+### Active
+
+Each DAO has requirements for who can activate proposals; a common way is to require the user to have a minimum amount of tokens. An activated proposal is one that is surfaced to the community to put up for voting.
+
+### Outcome: Succeeded, Defeated
+
+Voting lasts for a configurable period. If a majority, and at least quorum votes are cast for the proposal, it is queued in a Smart Wallet for execution by the other signers of the multisig.
+
+### Executed
+
+Once the transaction is queued in a Smart Wallet, the other signers on the Smart Wallet may execute the transaction. We suggest the following structure for the Smart Wallet:
+
+- 2-of-3
+- Signers:
+  - Tribeca Governor
+  - 1-of-n Smart Wallet Owner Invoker of trusted parties that will execute a proposal without frontrunning. This can be composed of the "core team" of the protocol.
+  - 4-of-7 Emergency DAO Smart Wallet that can quickly execute a proposal in case of emergency. This should be composed of trusted community members that will not collude.

docs/07-tribeca/02-governor/_category_.yml

@@ -0,0 +1 @@
+label: Governor

docs/07-tribeca/03-goki/01-about.md

@@ -0,0 +1,14 @@
+---
+title: About Goki
+---
+
+## Overview
+
+[Goki](https://goki.so) is a protocol building tools for Solana key management and security.
+
+They currently have two products launched:
+
+- [WalletKit](https://walletkit.goki.so), a wallet connector library
+- [Smart Wallet](./smart-wallet), a multisig wallet with Timelock capabilities which [the Tribeca Governor](../governor/overview) is built on
+
+Goki is a member of the [Tribeca DAO](../intro/tribeca-dao), and for simplicity, its documentation lives on the Tribeca documentation site.

docs/07-tribeca/03-goki/02-smart-wallet.md

@@ -0,0 +1,27 @@
+---
+title: The Goki Smart Wallet
+---
+
+## Overview
+
+The Goki Smart Wallet is a programmable multisig wallet. The program is based on [Serum's multisig implementation](https://docs.projectserum.com/guides/multisig).
+
+The Goki Team also maintains a hosted wallet management interface at [https://goki.so](https://goki.so).
+
+## Signing
+
+The Goki Smart Wallet is a _m-of-n multisig_: out of the _n_ owners of the wallet, _m_ of them must approve a transaction to have the wallet sign it. Owners may be defined upfront, and the owners of the wallet may elect to modify the signers in the future.
+
+_Note: if the owner set is modified, all previous unexecuted transactions are invalidated._
+
+The primary account **cannot** hold SOL, as its account holds data. You must use a derived subaccount (described in the next section) in order to transact SOL.
+
+### Subaccounts
+
+Goki wallets have two types of subaccounts: derived accounts and owner-invoker accounts.
+
+**Derived accounts** are accounts which require the Smart Wallet transaction to be signed off by members of the multisig according to the same rules as signing from the primary account. Only one derived account may sign a transaction at a time.
+
+**Owner-invoker** accounts are accounts which do not require approval from all owners of the multisig: any owner of the wallet may instantly invoke a transaction as any owner-invoker address. This is particularly useful for running cranks and other activities which you would want to avoid any account arbitrarily executing. For example, the recommended Tribeca DAO configuration uses this for executing passed proposals.
+
+Each wallet may have up to `u64::MAX` (or `2^64`) subaccounts of each of these types: subaccounts are associated with an _index_, similar to a Ledger.

docs/07-tribeca/03-goki/_category_.yml

@@ -0,0 +1 @@
+label: Goki

docs/07-tribeca/04-electorate/01-overview.md

@@ -0,0 +1,10 @@
+---
+title: Overview
+---
+
+The **Electorate** program creates an account which controls the Governor. It can perform two actions:
+
+- **Activate proposals,** which moves proposals to a state where they can be voted on
+- **Set votes,** which logs the number of votes a voter has made on a proposal, and which side of the vote that voter is on
+
+Electorates may be user-defined programs, since they perform signed cross-program invocations on the Govern program. One example of an Electorate is a Voting Escrow Locker. Another Electorate may be a modified Voting Escrow Locker - such as one where tokens unlock linearly instead of all at once. The Electorate may also be modified to allow a custom voting solution, such as by granting governance power for owning/depositing NFTs.