From 9d6b8aac00bba29a0cf1b813d317efee13101037 Mon Sep 17 00:00:00 2001 From: JafarAz Date: Thu, 28 Mar 2024 05:31:27 +0000 Subject: [PATCH] docs-migration-tres --- SECURITY.md | 6 +- docs/docs/concepts/picasso.md | 23 +- docs/docs/governance-&-token/governance.md | 209 +----------------- docs/docs/governance-&-token/opengov.md | 199 +++++++++++++++++ docs/docs/governance-&-token/use-cases.md | 34 +-- docs/docs/intro.md | 14 +- docs/docs/technology/ibc-overview.png | 3 + docs/docs/technology/ibc.md | 27 +-- docs/docs/technology/mantis/mantis1.png | 3 + .../docs/technology/restaking/mantis-games.md | 2 - docs/docusaurus.config.js | 9 +- docs/sidebars.js | 1 + docs/static/img/favicon.ico | Bin 2424 -> 4286 bytes docs/static/img/logo.svg | 3 - docs/static/img/picasso-dark.svg | 3 + docs/static/img/picasso-light.svg | 3 + docs/static/img/thumbnail.svg | 3 + 17 files changed, 270 insertions(+), 272 deletions(-) create mode 100644 docs/docs/governance-&-token/opengov.md create mode 100644 docs/docs/technology/ibc-overview.png create mode 100644 docs/docs/technology/mantis/mantis1.png delete mode 100644 docs/static/img/logo.svg create mode 100644 docs/static/img/picasso-dark.svg create mode 100644 docs/static/img/picasso-light.svg create mode 100644 docs/static/img/thumbnail.svg diff --git a/SECURITY.md b/SECURITY.md index 34a15077c3e..ee8fc13aa88 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,6 +1,6 @@ # Security Policy -At Composable Finance we are always striving towards writing secure and stable code. If you have found a critical bug or a security +At Composable, we are always striving towards writing secure and stable code. If you have found a critical bug or a security vulnerability, you can simply report your findings to us. @@ -15,7 +15,7 @@ When you report a security vulnerability please include: The more information you provide the better. We recommend submitting a report where you describe the vulnerability, show us how you found it and provide reproducible code samples. Providing mitigation advice is also recommended. -**The report should be submitted to reporting@composable.finance.** +**The report should be submitted to security@composable.finance.** ## Responsible Disclosure @@ -29,4 +29,4 @@ What is currently in scope is finding bugs in a our code base running in a local ## Rewards -Rewards are granted depending on the severity of the vulnerability, ranging from $50 to $30.000, payed out in PICA tokens. +Rewards are granted depending on the severity of the vulnerability, payed out in PICA tokens. diff --git a/docs/docs/concepts/picasso.md b/docs/docs/concepts/picasso.md index 26bbcf7d4a8..3fdc6e58a42 100644 --- a/docs/docs/concepts/picasso.md +++ b/docs/docs/concepts/picasso.md @@ -18,7 +18,7 @@ There are plans to modify the consensus of Picasso to Kauri, a Byzantine Fault T The IBC Protocol is used for trust-minimized communication between different blockchain networks/ecosystems. It relies on security at the consensus level of the two transacting chains, and this is a large reason why IBC was selected as a cornerstone of Picasso's efforts to connect ecosystems, in addition to its performance and standardization. -Originally, IBC was tailored for native connections between Cosmos SDK chains. Extending this to include more networks required significant development effort. In fact, IBC on Solana, Ethereu, Polkadot and Kusama all require respective customization from implementation of light client to achieving state proof (finality), in order to not rely on any centralized intermediary and uphold the IBC standards and values of censorship resistance. +Originally, IBC was tailored for native connections between Cosmos SDK chains. Extending this to include more networks required significant development effort. In fact, IBC on Solana, Ethereum, Polkadot and Kusama all require respective customization from implementation of light client to achieving state proof (finality), in order to not rely on any centralized intermediary and uphold the IBC standards and values of censorship resistance. These connections allow the transfer of both fungible (e.g Tokens) and non-fungible tokens (NFTs), generic message passing, cross-chain contract calls, cross-chain fee payments, and cross-ecosystem collateralization, all executed in a natively secured environment. @@ -30,13 +30,16 @@ Picasso expands upon the concept of restaking popularized by [Eigenlayer](https: We believe that all assets that have underlying utility, community, and liquidity, given long enough horizon, will have various level of economic value that can be used to enhance security guarantees for many use-cases (interoperability, oracles, sequencers and more) built upon the Proof of Stake consensus mechanism. -## Governance -Similar to the way that majority of Cosmos SDK chains operate, validators can vote using tokens they are delegated with. However, if a delegator votes themselves, their voting decision will override the validator’s vote if the decision differs. The parameters for the governance on Picasso are as follows: +## Staking PICA -| Parameter | Period/Number | -|----------------------------------------------------|----------------| -| Total Deposit | 2 million PICA | -| Quorum | 30% | -| Voting Period | 1 day | -| Threshold | 50% | -| No-with-veto | 33% | \ No newline at end of file +A portion of the bridging fees generated by each new IBC connection implemented via Picasso will be allocated to stakers of PICA. Currently, stakers receive rewards from the Polkadot-Cosmos and the Ethereum IBC implementation, with fees from Solana activity to be included upon launch. + +To handle fees collected in the form of the bridged token, a mechanism will be implemented to use these fees to buy back PICA from the market and distribute them to stakers as rewards. For instance, if ETH is bridged from Ethereum mainnet to Solana, 20% of the fees collected from this transfer will be used to buy back PICA and distribute it to PICA stakers. This process will be standardized for all tokens transferred across the bridge. + +PICA is essential for securing Picasso. To participate in governance activities, PICA must be staked on the network. Governance decisions on Picasso will include determining AVS and Operator onboarding, as well as adding new liquid staked assets to the restaking layer. + +The Generalized Restaking Layer will ensure the security of launches and activities of various Actively Validated Services (AVS), boosting revenue generation for PICA stakers. Specifically, 20% of the revenue will be allocated to PICA stakers. The initial AVS to be launched will be the AVS for Solana IBC. + +:::tip +Follow [this guide](https://docs.composable.finance/user-guides/pica-staking) for staking PICA on Picasso to take part in governance and earn rewards through various protocol revenue streams. +::: diff --git a/docs/docs/governance-&-token/governance.md b/docs/docs/governance-&-token/governance.md index ccd7f85cdaf..0865a9aa411 100644 --- a/docs/docs/governance-&-token/governance.md +++ b/docs/docs/governance-&-token/governance.md @@ -1,199 +1,10 @@ -# Picasso Kusama OpenGov - -Governance mechanisms for Picasso are intended to ensure the growth and adaptation of the ecosystem in alignment with the wants and needs of the Picasso community. Therefore, all token holders are able to participate, with their votes being weighted by stake. Moreover, any alteration to Picasso must be approved by a referendum decided by PICA token holders. - -[Picasso’s Polkassembly](https://picasso.polkassembly.io/opengov) will serve as a governance forum where open discussion about the future of Picasso can occur. Here, proposals can be refined based on community input. - -The OpenGov structure for Picasso was implemented in two phases. Picasso has passed the first phase with phase 2 live in production. - -**Phase 1:** Implement OpenGov with governance handled by two collectives: The Picasso Council and the Technical Committee. The purpose of this phase was to maintain the speed and efficiency demonstrated by the recent launches and connections on Picasso. - -**Phase 2:** Now, the second phase of Picasso OpenGov is live, a new era of decentralisation, allowing PICA holders to actively participate in governance and a new structure of collectives. - -Picasso’s OpenGov structure and design is an adapted version of Polkadot OpenGov. - -## Core Tenets - -Core principles guiding participation in the Picasso OpenGov process are as follows: - -- Supporting engagement of token holders who are influenced by and in turn would like to influence Picasso governance, even when their opinions and desires differ from that of the Composable team -- Prioritising the greater good of Picasso and its community over any individual interests -- Upholding transparency and openness with the public -- Acting morally and with a mind for consequences of action or inaction -- Standing firmly against any malicious language, behaviour, and actions - -## On-Chain Governance - -Picasso’s hard governance involves on-chain mechanisms where the majority of tokens on Picasso determine key decisions. These decisions are made via token holders voting on proposed referenda. - -### OpenGov Committees - -The **Technical Committee** is a group of 6 core developers that are able to whitelist proposals. Its purpose is to provide technical review of urgent security issues and upgrades. There must always be 1/3 approval from the committee to whitelist proposals. - -The **Treasury Committee** is an on-chain entity made up of 11 senior team members and supporters. Members of the Treasury committee consist of: - -- Henry Love, Executive Director of Composable Foundation -- 0xBrainJar, Composable Founder & Research Director -- Blas Rodriguez Irizar, Composable Co-Founder & CTO -- Joe DeTommasso, Composable Head of Governance & Strategy -- Miguel Santefé, Composable Co-Founder & Head of Design -- Jafar Azam, Composable Devrel -- Jacob Gadikian, Notional Ventures Founder & CEO -- Jesse Abramowitz, Entropy Lead Software and Protocol Engineer -- Will Pankiewicz, Parity Master of Validators -- Tamara Frankel, D1 Ventures Founding Partner -- James Wo, Digital Finance Group (DFG) Founder & Chairman - -The Treasury Committee also control Picasso’s multi-sig wallets holding the allocation for Liquidity Programs and Ecosystem incentives. Treasury proposals can be submitted by anyone but spending can only be approved by this council; the funds from any of these wallets will only be transferred upon the approval of on-chain governance. For more details, refer to the PICA token transparency commitment statement. - -The **Relayer Committee** consists of accounts running the Hyperspace relayer. - -## Definitions -Definitions and components for OpenGov on Picasso are detailed below: - -#### Origins -An origin is an authorization-based dispatch source for an operation. This determines the Track that a referendum is posted in. - -#### Pre-Image Deposit -This is the amount of tokens that a proposer must bond to submit a pre-image. It is a base deposit per network plus a fee per byte of the proposed pre-image. - -#### Pre-Image Hash -This is the hash of the proposal to be enacted. The first step to make a proposal is to submit a pre-image; the hash is its identifier. The proposer of the pre-image can be different than the user that proposes that pre-image as a formal proposal - -#### Proposals -Proposals are an action or item (defined by the pre-image hash) proposed by a token holder and open for consideration/discussion by token holders. - -#### Referendum -A referendum is a stake-based voting model. Each referendum is associated with an individual proposal for modifying Picasso in some way. This could include changes to code, parameters, or the governance of Picasso. - -## Tracks -This is a specific pipeline delineating the life cycle of a proposal. Tracks in Picasso OpenGov are Root, Whitelist Caller, General Admin, Referendum Canceller, and Referendum Killer: - -| Track | Description | Example | -|-----------------------|-------------------|--------------------------| -| Root | Highest Privileges | Runtime Upgrades | -| Whitelist Caller | Fast-track proposals | Accelerated proposal | -| General Admin | On-chain changes | Apollo and Collator onboarding, Release committee, LSD | -| Referendum Canceller | Cancelling proposal | Incorrect referendum | -| Referendum Killer | Cancelling proposals & slashing deposits | Malicious referendum | - - -### Voting -Token holders can approve or reject proposals. - -A vote’s weight is defined by the following: - -1. The number of tokens a user commits to a vote -2. The lock period of the vote; in Picasso OpenGov, users can voluntarily lock tokens to increase their voting power, with longer lock periods associated with a conviction multiplier on vote weight: - -| Lock Period After Enactment | Conviction Multiplier | Lock Time | -|-----------------------|-------------------|--------------------------| -| 0 | 0.1x | None | -| 1 | 1x | 28 days | -| 2 | 2x | 56 days | -| 4 | 3x | 112 days | -| 8 | 4x | 224 days | -| 16 | 5x | 448 days | -| 32 | 6x | 896 days | - - -#### Vote Delegation -Voters can delegate voting power (including conviction multiplier) to other token holders (“delegates”). This feature exists to allow tokens to be delegated to those who may be more knowledgeable about the Picasso network and thus able to make more informed decisions on specific referenda. - -#### Multirole Delegation -Voting power can be delegated based on tracks, e.g. token holders can specify different delegates for each track. - -#### Approval -This is the minimum number of votes for passing a referendum, as a percentage of total conviction-weighted votes needed to approve the referendum. - -#### Support -This is the minimum number of votes for passing a referendum (NOT taking into consideration conviction-weighted votes) needed to approve the referendum. - -#### Lead-In Period -This is the initial period of discussion and voting on a proposal. During this period, proposals are undecided until they pass the criteria for a Track, which include: - -- The prepare period, or the minimum time a referendum needs to wait before it can progress to the next phase after submission -- Capacity, or the limit for a number of referenda on a given track that can be decided at once -- Decision deposit, or the minimum deposit amount needed for a referendum to progress to the decision phase after the lead-in period ends; this deposit is larger than the submission deposit in order to limit spam proposals/referenda - -Details on the lead-in period (specifically, the prepare period) for each track are found in the OpenGov Parameters section of this documentation. - -#### Decision Period -During this period, token holders continue to vote on the referendum. If a referendum does not pass by the end of the period, it will be rejected, and the Decision Deposit will be refunded. -Details on the decision period for each track are found in the OpenGov Parameters section of this documentation. - -#### Confirm Period -This is a period of time within the decision period where the referendum needs to have maintained enough Approval and Support to be approved and move to the enactment period. - -Details on the confirm period for each track are found in the OpenGov Parameters section of this documentation. - -#### Enactment Period -This is a specified time, defined at the time the proposal was created, that an approved referendum waits before it can be dispatched. -There is a minimum amount of time for each Track. Details on the enactment period for each track are found in the OpenGov Parameters section of this documentation. -## OpenGov Parameters -Governance parameters (for each referenda track) are as follows: - -| Track | Track ID | Concurrent Proposals | Decision Deposit | -| -------- | -------- | --- | -------- | -| Root | 0 | 5 | 5,000,000 PICA | -| Whitelist Caller | 1 | 25 | 500,000 PICA | -| General Admin | 2 | 10 | 1,000,000 PICA | -| Referendum Canceller | 3 | 10 | 1,000,000 PICA | -| Referendum Killer | 4 | 25 | 1,000,000 PICA | - -## Period Parameters by Track - -| Track |Prepare Period | Decision Period | Confirm Period | Min. enactments | -| --- | --- | -------- | -------- | -------- | -| Root | 1 day 2 Hours (600 Blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day | -| Whitelist Caller | 10 mins (50 Blocks) | 10 Days (72000 Blocks) | 30 mins (150 Blocks) | 10 mins | -| General Admin | 1 hour (300 blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day | -| Referendum Canceller | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins | -| Referendum Killer | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins | - -## Support and Approval Parameters by Track - -| Track | Approval Curve | Parameters | Support Curve | Parameters | -| --- | --- | -------- | -------- | -------- | -| Root | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Linear | Day 0: 50% Day 10: 0.5% | -| Whitelist Caller | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 2% Hour 1: 1% Day 14: 0% | -| General Admin | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 50% Day 5: 10% Day 10: 0% | -| Referendum Canceller | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 10% Day 1: 1% Day 10: 0% | -| Referendum Killer | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 10% Day 1: 1% Day 10: 0% | - -## Approval Curves -With X % of support, Referenda can pass after Y duration (time periods in the table) since the beginning of referenda depending on whethere the approval rate is above the approval curve. - -![whitelist-curve](../governance-&-token/whitelist-track.png) -*Approval curve for the Whitelist Track* - -![root-curve](../governance-&-token/root-track.png -*Approval curve for the Root Track* - -## Proposal Roadmap - -1. A proposal author should submit their idea to Picasso’s Polkassembly governance forum, where they should be open to community feedback for at least five days before moving forward -2. Taking into account feedback, the proposal author can submit their proposal on-chain - - The proposer must first submit the preimage (if you need assistance with creating the preimage or would like secondary approval, reach out to our team on Discord) - - Note: your preimage deposit will be returned once via unnoting after the proposal is submitted - - The proposer then can submit the Referendum, and place the decision deposit (which covers the on-chain storage cost of the proposal) -3. Thus veins the lead-in period, where the community can begin voting -4. The proposal will then move to the decision period when the following are met: - - The referenda waits the duration of the prepare period (ensuring enough time for discussion) - - There is capacity in the chosen track - - A decision deposit has been submitted and meets the minimum requirements of the track -5. During the decision period, voting continues and the referendum has a set amount of days to reach approval. - - If the Referendum is rejected, the decision deposit will be returned -6. If the Referendum is approved, it enters the confirm period where it must remain approved for the duration of this period. - - If the referendum fails to meet these requirements at any time, it moves back to the decide period; if it again meets these requirements, it moves back to the confirm period and the decide period is delayed until the end of the confirm period -7. If the referendum receives enough approval and support throughout the confirm period, it will be approved and move to the enactment period -8. Once the enactment period elapses, the referendum will be executed - -## Proposal Cancellations -If a proposal in the voting stage is found to have an issue, it may be necessary to prevent its approval. This could be due to malicious activity or technical issues that void the proposal. - -Cancellations must be voted on by the network. Cancellation proposals are expedited, as they must be decided before the enactment of the proposal they seek to cancel. However, the same process as standard referenda applies. - -Moreover, a cancellation Origin called the Emergency Canceller exists for use against any referendum with an unanticipated issue. The Emergency Canceller Origin and the Root Origin can cancel referenda. Regardless of the Origin, if a proposal is cancelled, it is rejected and the decision deposit is refunded. - -The Kill Origin called Emergency Killer exists for use against malicious referenda. The Emergency Killer Origin and the Root Origin have the ability to kill referenda. The difference between killing and cancelling a referenda is that in the case of a kill, not only is the proposal cancelled, but also the Decision Deposit is slashed, meaning the deposit amount is burned regardless of the Origin. +# Governance +Similar to the way that majority of Cosmos SDK chains operate, validators can vote using tokens they are delegated with. However, if a delegator votes themselves, their voting decision will override the validator’s vote if the decision differs. The parameters for the governance on Picasso are as follows: + +| Parameter | Period/Number | +|----------------------------------------------------|----------------| +| Total Deposit | 2 million PICA | +| Quorum | 30% | +| Voting Period | 1 day | +| Threshold | 50% | +| No-with-veto | 33% | \ No newline at end of file diff --git a/docs/docs/governance-&-token/opengov.md b/docs/docs/governance-&-token/opengov.md new file mode 100644 index 00000000000..86a4b411370 --- /dev/null +++ b/docs/docs/governance-&-token/opengov.md @@ -0,0 +1,199 @@ +# Picasso Kusama OpenGov + +Governance mechanisms for Picasso Kusama are intended to ensure the growth and adaptation of the ecosystem in alignment with the wants and needs of the Picasso Kusama community. Therefore, all token holders are able to participate, with their votes being weighted by stake. Moreover, any alteration to Picasso Kusama must be approved by a referendum decided by PICA token holders. + +[Picasso’s Polkassembly](https://picasso.polkassembly.io/opengov) will serve as a governance forum where open discussion about the future of Picasso Kusama can occur. Here, proposals can be refined based on community input. + +The OpenGov structure for Picasso Kusama was implemented in two phases. Picasso Kusama has passed the first phase with phase 2 live in production. + +**Phase 1:** Implement OpenGov with governance handled by two collectives: The Picasso Kusama Council and the Technical Committee. The purpose of this phase was to maintain the speed and efficiency demonstrated by the recent launches and connections on Picasso Kusama. + +**Phase 2:** Now, the second phase of Picasso Kusama OpenGov is live, a new era of decentralisation, allowing PICA holders to actively participate in governance and a new structure of collectives. + +Picasso’s OpenGov structure and design is an adapted version of Polkadot OpenGov. + +## Core Tenets + +Core principles guiding participation in the Picasso Kusama OpenGov process are as follows: + +- Supporting engagement of token holders who are influenced by and in turn would like to influence Picasso Kusama governance, even when their opinions and desires differ from that of the Composable team +- Prioritising the greater good of Picasso Kusama and its community over any individual interests +- Upholding transparency and openness with the public +- Acting morally and with a mind for consequences of action or inaction +- Standing firmly against any malicious language, behaviour, and actions + +## On-Chain Governance + +Picasso’s hard governance involves on-chain mechanisms where the majority of tokens on Picasso Kusama determine key decisions. These decisions are made via token holders voting on proposed referenda. + +### OpenGov Committees + +The **Technical Committee** is a group of 6 core developers that are able to whitelist proposals. Its purpose is to provide technical review of urgent security issues and upgrades. There must always be 1/3 approval from the committee to whitelist proposals. + +The **Treasury Committee** is an on-chain entity made up of 11 senior team members and supporters. Members of the Treasury committee consist of: + +- Henry Love, Executive Director of Composable Foundation +- 0xBrainJar, Composable Founder & Research Director +- Blas Rodriguez Irizar, Composable Co-Founder & CTO +- Joe DeTommasso, Composable Head of Governance & Strategy +- Miguel Santefé, Composable Co-Founder & Head of Design +- Jafar Azam, Composable Devrel +- Jacob Gadikian, Notional Ventures Founder & CEO +- Jesse Abramowitz, Entropy Lead Software and Protocol Engineer +- Will Pankiewicz, Parity Master of Validators +- Tamara Frankel, D1 Ventures Founding Partner +- James Wo, Digital Finance Group (DFG) Founder & Chairman + +The Treasury Committee also control Picasso’s multi-sig wallets holding the allocation for Liquidity Programs and Ecosystem incentives. Treasury proposals can be submitted by anyone but spending can only be approved by this council; the funds from any of these wallets will only be transferred upon the approval of on-chain governance. For more details, refer to the PICA token transparency commitment statement. + +The **Relayer Committee** consists of accounts running the Hyperspace relayer. + +## Definitions +Definitions and components for OpenGov on Picasso Kusama are detailed below: + +#### Origins +An origin is an authorization-based dispatch source for an operation. This determines the Track that a referendum is posted in. + +#### Pre-Image Deposit +This is the amount of tokens that a proposer must bond to submit a pre-image. It is a base deposit per network plus a fee per byte of the proposed pre-image. + +#### Pre-Image Hash +This is the hash of the proposal to be enacted. The first step to make a proposal is to submit a pre-image; the hash is its identifier. The proposer of the pre-image can be different than the user that proposes that pre-image as a formal proposal + +#### Proposals +Proposals are an action or item (defined by the pre-image hash) proposed by a token holder and open for consideration/discussion by token holders. + +#### Referendum +A referendum is a stake-based voting model. Each referendum is associated with an individual proposal for modifying Picasso Kusama in some way. This could include changes to code, parameters, or the governance of Picasso Kusama. + +## Tracks +This is a specific pipeline delineating the life cycle of a proposal. Tracks in Picasso Kusama OpenGov are Root, Whitelist Caller, General Admin, Referendum Canceller, and Referendum Killer: + +| Track | Description | Example | +|-----------------------|-------------------|--------------------------| +| Root | Highest Privileges | Runtime Upgrades | +| Whitelist Caller | Fast-track proposals | Accelerated proposal | +| General Admin | On-chain changes | Apollo and Collator onboarding, Release committee, LSD | +| Referendum Canceller | Cancelling proposal | Incorrect referendum | +| Referendum Killer | Cancelling proposals & slashing deposits | Malicious referendum | + + +### Voting +Token holders can approve or reject proposals. + +A vote’s weight is defined by the following: + +1. The number of tokens a user commits to a vote +2. The lock period of the vote; in Picasso Kusama OpenGov, users can voluntarily lock tokens to increase their voting power, with longer lock periods associated with a conviction multiplier on vote weight: + +| Lock Period After Enactment | Conviction Multiplier | Lock Time | +|-----------------------|-------------------|--------------------------| +| 0 | 0.1x | None | +| 1 | 1x | 28 days | +| 2 | 2x | 56 days | +| 4 | 3x | 112 days | +| 8 | 4x | 224 days | +| 16 | 5x | 448 days | +| 32 | 6x | 896 days | + + +#### Vote Delegation +Voters can delegate voting power (including conviction multiplier) to other token holders (“delegates”). This feature exists to allow tokens to be delegated to those who may be more knowledgeable about Picasso Kusama and thus able to make more informed decisions on specific referenda. + +#### Multirole Delegation +Voting power can be delegated based on tracks, e.g. token holders can specify different delegates for each track. + +#### Approval +This is the minimum number of votes for passing a referendum, as a percentage of total conviction-weighted votes needed to approve the referendum. + +#### Support +This is the minimum number of votes for passing a referendum (NOT taking into consideration conviction-weighted votes) needed to approve the referendum. + +#### Lead-In Period +This is the initial period of discussion and voting on a proposal. During this period, proposals are undecided until they pass the criteria for a Track, which include: + +- The prepare period, or the minimum time a referendum needs to wait before it can progress to the next phase after submission +- Capacity, or the limit for a number of referenda on a given track that can be decided at once +- Decision deposit, or the minimum deposit amount needed for a referendum to progress to the decision phase after the lead-in period ends; this deposit is larger than the submission deposit in order to limit spam proposals/referenda + +Details on the lead-in period (specifically, the prepare period) for each track are found in the OpenGov Parameters section of this documentation. + +#### Decision Period +During this period, token holders continue to vote on the referendum. If a referendum does not pass by the end of the period, it will be rejected, and the Decision Deposit will be refunded. +Details on the decision period for each track are found in the OpenGov Parameters section of this documentation. + +#### Confirm Period +This is a period of time within the decision period where the referendum needs to have maintained enough Approval and Support to be approved and move to the enactment period. + +Details on the confirm period for each track are found in the OpenGov Parameters section of this documentation. + +#### Enactment Period +This is a specified time, defined at the time the proposal was created, that an approved referendum waits before it can be dispatched. +There is a minimum amount of time for each Track. Details on the enactment period for each track are found in the OpenGov Parameters section of this documentation. +## OpenGov Parameters +Governance parameters (for each referenda track) are as follows: + +| Track | Track ID | Concurrent Proposals | Decision Deposit | +| -------- | -------- | --- | -------- | +| Root | 0 | 5 | 5,000,000 PICA | +| Whitelist Caller | 1 | 25 | 500,000 PICA | +| General Admin | 2 | 10 | 1,000,000 PICA | +| Referendum Canceller | 3 | 10 | 1,000,000 PICA | +| Referendum Killer | 4 | 25 | 1,000,000 PICA | + +## Period Parameters by Track + +| Track |Prepare Period | Decision Period | Confirm Period | Min. enactments | +| --- | --- | -------- | -------- | -------- | +| Root | 1 day 2 Hours (600 Blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day | +| Whitelist Caller | 10 mins (50 Blocks) | 10 Days (72000 Blocks) | 30 mins (150 Blocks) | 10 mins | +| General Admin | 1 hour (300 blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day | +| Referendum Canceller | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins | +| Referendum Killer | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins | + +## Support and Approval Parameters by Track + +| Track | Approval Curve | Parameters | Support Curve | Parameters | +| --- | --- | -------- | -------- | -------- | +| Root | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Linear | Day 0: 50% Day 10: 0.5% | +| Whitelist Caller | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 2% Hour 1: 1% Day 14: 0% | +| General Admin | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 50% Day 5: 10% Day 10: 0% | +| Referendum Canceller | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 10% Day 1: 1% Day 10: 0% | +| Referendum Killer | Reciprocal | Day 0: 100% Day 2: 80% Day 10: 50% | Reciprocal | Day 0: 10% Day 1: 1% Day 10: 0% | + +## Approval Curves +With X % of support, Referenda can pass after Y duration (time periods in the table) since the beginning of referenda depending on whethere the approval rate is above the approval curve. + +![whitelist-curve](../governance-&-token/whitelist-track.png) +*Approval curve for the Whitelist Track* + +![root-curve](../governance-&-token/root-track.png +*Approval curve for the Root Track* + +## Proposal Roadmap + +1. A proposal author should submit their idea to Picasso’s Polkassembly governance forum, where they should be open to community feedback for at least five days before moving forward +2. Taking into account feedback, the proposal author can submit their proposal on-chain + - The proposer must first submit the preimage (if you need assistance with creating the preimage or would like secondary approval, reach out to our team on Discord) + - Note: your preimage deposit will be returned once via unnoting after the proposal is submitted + - The proposer then can submit the Referendum, and place the decision deposit (which covers the on-chain storage cost of the proposal) +3. Thus veins the lead-in period, where the community can begin voting +4. The proposal will then move to the decision period when the following are met: + - The referenda waits the duration of the prepare period (ensuring enough time for discussion) + - There is capacity in the chosen track + - A decision deposit has been submitted and meets the minimum requirements of the track +5. During the decision period, voting continues and the referendum has a set amount of days to reach approval. + - If the Referendum is rejected, the decision deposit will be returned +6. If the Referendum is approved, it enters the confirm period where it must remain approved for the duration of this period. + - If the referendum fails to meet these requirements at any time, it moves back to the decide period; if it again meets these requirements, it moves back to the confirm period and the decide period is delayed until the end of the confirm period +7. If the referendum receives enough approval and support throughout the confirm period, it will be approved and move to the enactment period +8. Once the enactment period elapses, the referendum will be executed + +## Proposal Cancellations +If a proposal in the voting stage is found to have an issue, it may be necessary to prevent its approval. This could be due to malicious activity or technical issues that void the proposal. + +Cancellations must be voted on by the network. Cancellation proposals are expedited, as they must be decided before the enactment of the proposal they seek to cancel. However, the same process as standard referenda applies. + +Moreover, a cancellation Origin called the Emergency Canceller exists for use against any referendum with an unanticipated issue. The Emergency Canceller Origin and the Root Origin can cancel referenda. Regardless of the Origin, if a proposal is cancelled, it is rejected and the decision deposit is refunded. + +The Kill Origin called Emergency Killer exists for use against malicious referenda. The Emergency Killer Origin and the Root Origin have the ability to kill referenda. The difference between killing and cancelling a referenda is that in the case of a kill, not only is the proposal cancelled, but also the Decision Deposit is slashed, meaning the deposit amount is burned regardless of the Origin. diff --git a/docs/docs/governance-&-token/use-cases.md b/docs/docs/governance-&-token/use-cases.md index 0ebc1dcedde..bb429980ccb 100644 --- a/docs/docs/governance-&-token/use-cases.md +++ b/docs/docs/governance-&-token/use-cases.md @@ -8,6 +8,12 @@ A concerted effort has been made to ensure that the PICA token holds as much uti ## What is $PICA used for? + +## Governance + +In pursuit of a trustless and interoperable vision, PICA plays a crucial role, as [governance on Picasso](../picasso/governance.md) is operating OpenGov phase 2. + +Additionally, as PICA serves as the native token of Composable Cosmos, it is essential for governance on the [Composable Cosmos](../composable-cosmos.md) chain as well. ### Validator staking PICA is used to secure Picasso. This is the first instance of a token being utilized for validation within both the Kusama and Cosmos ecosystems and highlights the critical role PICA plays within cross-ecosystem communication. @@ -19,22 +25,15 @@ With the introduction of Solana and Ethereum IBC connections in Q1 of 2024, 20% #### AVS Payment Distribution The Generalized Restaking Layer will secure the launches and activity of various Actively Validated Services (AVS) enhancing revenue generation for PICA stakers. A portion of the revenue, specifically 20%, will be directed towards PICA stakers. The initial AVS to be launched will be the Guest blockchain on Solana, which facilitates the Solana IBC connection. -#### Polkadot Liquid Staking -Composable launched Liquid Staked DOT (LSDOT) on [trustless.zone](https://app.trustless.zone/stake/), a liquid staked derivative for Polkadot's native token. Revenue from this activity will flow to PICA, providing yield emissions from liquid staking, but only while stakings are locked. The value accrual for liquid staking is a 1% fee + 75% of 10% of the yield generated. :::tip -Follow [this guide](https://docs.composable.finance/user-guides/composable-cosmos-staking) to stake PICA on Composable Cosmos and earn rewards through various protocol revenue streams. +Follow [this guide](https://docs.composable.finance/user-guides/pica-staking) for staking PICA on Picasso to take part in governance and earn rewards through various protocol revenue streams. ::: -### Oracle staking​ -Apollo is a permissionless, MEV-resistant oracle solution. Anyone can run an oracle node on Picasso by providing stake in PICA. - -### Collator staking​ -25% of fees on Picasso are distributed to collators, with the remaining 75% going directly to the community-governed treasury. Collators on Picasso are required to put down a stake to produce blocks on [Picasso](../picasso-parachain-overview.md), as with most proof of stake networks. - -