diff --git a/docs/02_products/01_trading/01_pools/01_omnipool/03_omnipool_design.md b/docs/02_products/01_trading/01_pools/01_omnipool.md similarity index 99% rename from docs/02_products/01_trading/01_pools/01_omnipool/03_omnipool_design.md rename to docs/02_products/01_trading/01_pools/01_omnipool.md index 56e32c9b..867ef24b 100644 --- a/docs/02_products/01_trading/01_pools/01_omnipool/03_omnipool_design.md +++ b/docs/02_products/01_trading/01_pools/01_omnipool.md @@ -1,6 +1,5 @@ --- -id: omnipool_design -title: Design +title: Omnipool --- import useBaseUrl from '@docusaurus/useBaseUrl'; diff --git a/docs/02_products/01_trading/01_pools/01_omnipool/01_omnipool.md b/docs/02_products/01_trading/01_pools/01_omnipool/01_omnipool.md deleted file mode 100644 index 6f8e1f70..00000000 --- a/docs/02_products/01_trading/01_pools/01_omnipool/01_omnipool.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Overview ---- - -Hydration is a next-gen DeFi protocol which is designed to **bring an ocean of liquidity to Polkadot**. Our tool for the job the **Hydration Omnipool** - an innovative Automated Market Maker (AMM) which **unlocks unparalleled efficiencies** by **combining all assets in a single trading pool**. - -By putting an **end to liquidity fragmentation**, the Hydration Omnipool makes trading efficient like no other AMM. Thanks to **lower slippage and less hops**, traders can enjoy capital efficiency gains (which scale further with TVL) as compared to a typical situation where liquidity is fragmented across different trading pools ([learn more](/omnipool_trading)). - -The design of the Hydration Omnipool empowers **single-sided liquidity provisioning** - anyone can provide liquidity only for the asset they want, and the Omnipool will take care of the rest ([learn more](/omnipool_lp)). In the early phases of bootstrapping growth, providing liquidity for selected assets will be incentivized by **Hydrated Farms** - additional rewards on top rewards from trading fees which grow over time ([learn more](/omnipool_hydrated_farms)). - -Single-sided LPing is an especially powerful concept for **treasuries of DAOs and other projects** who can supply their asset to the Omnipool - **trustlessly via XCM**, and gain **instant exposure to an ocean of assets**. Without hidden fees for market makers, **while building up (diversified) POL from trading fees** ([learn more](/omnipool_treasuries)). - -The Hydration Omnipool enjoys **state of the art security**: The underlying code has underwent **multiple audits**, and there is a **generous bug bounty program** incentivizing the **responsible disclosure of vulnerabilities**. Besides that, a combination of cutting-edge mechanisms such as liquidity caps, protocol fees and circuit breakers work together to keep your liquidity safe ([learn more](/omnipool_security)). - -Building upon **2+ years of R&D**, Hydration has found ways to address another pain point of AMMs - **impermanent loss (IL)**. Thanks to a **combination of non-inflationary measures**, liquidity providers will **experience less IL** when providing their liquidity to the Omnipool ([learn more](/omnipool_impermanent_loss)). \ No newline at end of file diff --git a/docs/02_products/01_trading/01_pools/01_omnipool/_category_.json b/docs/02_products/01_trading/01_pools/01_omnipool/_category_.json deleted file mode 100644 index b923ba62..00000000 --- a/docs/02_products/01_trading/01_pools/01_omnipool/_category_.json +++ /dev/null @@ -1,14 +0,0 @@ -{ - "label": "Omnipool", - "collapsible": true, - "collapsed": true, - "className": "red", - "link": { - "slug": "products/trading/pools/omnipool", - "type": "generated-index", - "title": "Omnipool" - }, - "customProps": { - "description": "" - } - } diff --git a/docs/02_products/01_trading/01_pools/02_isolated_pools.md b/docs/02_products/01_trading/01_pools/02_isolated_pools.md index a18361e9..9f360714 100644 --- a/docs/02_products/01_trading/01_pools/02_isolated_pools.md +++ b/docs/02_products/01_trading/01_pools/02_isolated_pools.md @@ -2,7 +2,7 @@ title: Isolated Pools (XYK) --- -In addition to [the Omnipool](./01_omnipool/01_omnipool.md), Hydration offers Isolated Pools, which are **separate pools that contain specific collections of assets**. Each Isolated Pool has its own unique risk management configurations, such as liquidity caps, fee structures, and asset composition. +In addition to [the Omnipool](./01_omnipool), Hydration offers Isolated Pools, which are **separate pools that contain specific collections of assets**. Each Isolated Pool has its own unique risk management configurations, such as liquidity caps, fee structures, and asset composition. This design differs from the Omnipool, where all assets are combined into a single pool with uniform risk management settings. diff --git a/docs/03_guides/06_opengov.md b/docs/03_guides/06_opengov.md new file mode 100644 index 00000000..b3b44329 --- /dev/null +++ b/docs/03_guides/06_opengov.md @@ -0,0 +1,89 @@ +--- +title: Participate in OpenGov +--- + +import useBaseUrl from '@docusaurus/useBaseUrl'; + +## **The Referendum Process** + +Before proceeding with making a referendum, identify the right track and origin for it. For instance, if the referendum is for requesting funds from treasury, select the treasury track with appropriate spend limits. Read [this post](/community/opengov) to learn more about Origins and Tracks. + +Below is the ideal process to follow: + +1. Create a discussion post about your proposal on Subsquare. This post allows the community to deliberate and recommend improvements. +2. Create a referenda on Subsquare. + +That said, you are free to create a referenda without first creating a discussion post. + +--- + +## **How to Create a Discussion Post** + +1. Go to **Subsquare > Discussions > New Post**. You can do so following this link: [https://](https://hydradx.subsquare.io/post/create)[hydration.subsquare.io/post/create](https://hydration.subsquare.io/post/create) +2. Fill in the **title, label,** and **description** of your proposal. + +
+ subsquare_UI_new_discussion_post +
+ +3. Click **‘Create’** and sign the transaction. + +Having created a discussion post for your proposal, you should share the link to the post on community channels and your socials. The goal is to get feedback from the community and also give you an opportunity to address any concerns raised. + +--- + +## **How to Create a Referendum** + +It is advisable to create a discussion around a proposal before making a referendum. This increases your chances of getting your referendum passed as you will get a chance a to listen to and act on community feedback and concerns. + +1. Go to **Subsquare > Referenda > New Proposal** https://hydration.subsquare.io/referenda + + If you are familiar with creating preimages, then go ahead and choose any of the two main options (New preimage, I already have preimage). + +
+subsquare_UI_new_referendum +
+ +2. If you do not know how to use preimages, then select one of the **Quick Start** options that best fits your proposal. Below are the options: + 1. **Treasury spend local** - for proposals that want to request HDX. + 2. **Treasury USDx spend** - for proposals that seek to request USDC/T. + 3. **Remark** - for proposals that wish to propose changes to the protocol/ecosystem. most ideal for the ‘Wish for Change’ track. +3. In the following dialog box, enter all relevant details. It is important to specify the correct track for your proposal. Once done, click **‘Create Preimage’** and sign the transaction. This will create your proposal/referendum. But note that until you pay the Decision Deposit, this referendum is, in a sense, inactive since any votes won’t count. At this stage, there are two things you need to do. +4. **Add contextual information**. You can do this by editing the referendum to add the information. Or you can link to the discussion post you created before. +6. **Pay Decision Deposit**. Click the Decision Deposit button on the ’Status’ dialog box of your referendum page. Enter the required HDX and sign the transaction. + +At this point, your referendum is now fully created and available for voting. + +--- + +## **How to Vote on Referendum** + +1. Go to the referendum page on **[Subsquare](https://hydration.subsquare.io/referenda)**. +2. Click the ‘**Vote**’ button. This will bring up a dialog box. +3. Choose your vote from 4 options + 1. **Aye** + 2. **Nay** + 3. **Split** - for when you wish to vote Aye and Nay. + 4. **Abstain** - for when you feel unqualified to vote on a proposal but want your tokens to count towards the Approval and Support parameters that determine whether or not a proposal passes. For more details on what this means, read this post. +4. Enter the **HDX** value of your vote. +5. Enter your vote’s **conviction multiplier**. The higher the conviction, the longer your HDX is locked and the more power your votes have. To learn more about conviction multipliers, read [this post](/community/opengov). +6. Click ‘**Confirm**’ and sign the transaction. + +You have successfully voted. + +--- + +## **How to Cancel or Kill a Referendum** + +To learn more about cancelling and killing a referendum, read [this post](/community/opengov). + +1. Go to the [Polkadot-JS UI](https://polkadot.js.org/apps/). +2. Ensure you are on the **Hydration** network. If you are, you will see the Hydration logo at the top left corner of the page. If you see a different logo (for instance, Polkadot), then click that logo and it will show a drop down menu. Scroll down to Hydration, select a server, and then scroll up to click ’Switch’. +3. Navigate to **Governance > Referenda**. +4. Click on the **"Add Preimage"** button. +5. In the **’Send from Account’** dialog box, choose the account you want to use. +6. In the **‘Propose’** section, select **‘Referenda’** from the drop down menu. +7. Beside the ‘Propose’ dialog box, specify the action you wish to take. + 1. If you wish to Cancel the referenda (stop the referenda without slashing the decision deposit bonded by the proposer), then select **‘cancel(index)’** in the drop down menu. + 2. If you wish to Kill the referenda (stop the referenda without slashing the decision deposit bonded by the proposer), then select **‘kill(index)’** in the drop down menu. +8. Enter the index number of referenda you wish to cancel. i.e. If you wish to cancel referendum 256, you will enter ‘256’ in the index dialog box. \ No newline at end of file diff --git a/docs/03_guides/06_identity.md b/docs/03_guides/07_identity.md similarity index 100% rename from docs/03_guides/06_identity.md rename to docs/03_guides/07_identity.md diff --git a/docs/04_community/03_opengov.md b/docs/04_community/03_opengov.md new file mode 100644 index 00000000..c2fa394f --- /dev/null +++ b/docs/04_community/03_opengov.md @@ -0,0 +1,302 @@ +--- +title: OpenGov (Democracy) +--- + +import useBaseUrl from '@docusaurus/useBaseUrl'; + +## Introduction + +On Hydration, all decisions which affect the protocol are adopted through a governance process that puts token holders at the centre of decision making. + +--- + +## **Components of OpenGov** + +This section covers all the relevant elements of OpenGov and what they mean. + +### **Participants** + +These are the groups of decision makers and their roles in the governance process. + +#### **1. Public** + +This group is inclusive of all HDX token holders. They can propose and vote on referenda. + +#### **2. Technical Committee** + +This is a group of experienced engineers who are appointed by OpenGov referenda on the GeneralAdmin track (read [Origins and Tracks](https://www.notion.so/Understanding-OpenGov-30557548d5bc4a7eae58c6a0a737bcef?pvs=21) section to understand what this means). Their main task is to safeguard the technical stability of the protocol. + +The Technical Committee has the power to whitelist referenda, which are then placed on the Whitelisted Caller track. This is a quicker track with lower thresholds that can dispatch Root origin referenda that can alter the runtime. This enables the TC to swiftly fix any problems that may arise. + +In addition to whitelisting referenda, the TC has another key function related to the security of the [Omnipool](https://docs.hydration.net/): targeted function pausing. This allows the TC to temporarily pause certain or all actions relating to specific assets. Thus, in the case of an emergency or detection of suspicious behaviour, the TC has the power to make any asset non-tradable. + +--- + +## **Referenda** + +In OpenGov, all referenda are public. Anyone can start a referendum at any time and as often as they wish. + +Key components of referenda in OpenGov include: + +1. **Decision Deposit**: A necessary deposit that must be provided for a referendum to enter its Decision Period. The amount depends on the track’s privilege level. +2. **Referenda Timeline**: The lifecycle of a referendum involves several stages, including the Lead-in Period, Decision Period, Confirmation Period, and Enactment Period. Each stage has specific requirements and durations based on the track. +3. **Origins and Tracks**: Origins refer to specific levels of privilege or authority for referenda, determining the Track a proposal follows. Tracks are pathways through which a referendum progresses, with each track having different parameters and thresholds. +4. **Approval and Support**: To be approved, a referendum must meet the criteria for approval and support during the Confirmation Period. Approval measures the percentage of 'yes' votes compared to the total votes, while Support measures the overall turnout of voters in favor or neutral. +5. **Conviction Voting**: A mechanism that allows token holders to increase their voting power by locking up their tokens for a specified period. The number of votes is calculated by multiplying tokens by the conviction multiplier. +6. **Cancelling & Killing Referenda**: Mechanisms to reject referenda before the voting period ends. The Referendum Canceller cancels ongoing referenda without slashing deposits, while the Referendum Killer instantly kills referenda and slashes deposits. +7. **Delegations**: The ability for voters to delegate their voting power to another voter. OpenGov introduces multirole delegation, allowing different delegates for different types of referenda. + +These components work together to ensure a robust and decentralized decision-making process within the Hydration protocol. + +--- + +### **Decision Deposit** + +In OpenGov, someone must provide the Decision Deposit for a referendum to enter its Decision Period (see Origins and Tracks for more details). The number of tokens required for the Decision Deposit depends on the track’s privilege level. The higher the privilege, the higher the deposit. For example, malicious referenda posted on the Small Tipper track inflict low economic damage to the network. In contrast, malicious referenda on the Root track can inflict more significant harm, such as changing the entire network's runtime. + +--- + +### **Referenda Timeline** + +Understanding the lifecycle of a referendum is crucial to grasping how decisions are made in OpenGov. When a referendum is created, the community can vote on it right away. However, it can't be finalized or enacted immediately. Instead, the referendum stays in a **Lead-in Period** until it meets three criteria: + +1. **Minimum Time Requirement**: The referendum must stay in the lead-in period for a set amount of time. This prevents quick decisions and allows everyone enough time to vote and participate, mitigating the risk of "decision sniping" (where an attacker might try to pass a proposal immediately without giving others time to vote). +2. **Decision Capacity**: Each origin (or level of authority) has a limit on how many referenda can be decided at once. For example, the highest authority, called Root, can only handle one referendum at a time. +3. **Decision Deposit**: A deposit must be submitted for the referendum to be reviewed and decided on. This deposit, which is more significant than the initial creation deposit, helps prevent spam and ensures only serious proposals move forward. If the deposit isn't submitted, the proposal will timeout. + +While in the Lead-in period, proposals are undecided. Once the three criteria are met, the referendum moves to the **Decision Period**, where votes are counted. + +Voting continues in this period until it meets the approval and support criteria for at least the **Confirmation Period** before it is approved. If it doesn't, the proposal is automatically rejected but can be resubmitted anytime. + +Once approved, a referendum enters the **Enactment Period**, after which the proposed changes are executed. + +The lengths of the lead-in, decision, confirmation, and enactment periods vary depending on the track. For example, the Root track has longer periods and can only handle one proposal at a time. In contrast, other tracks, like Small Tipper, can handle many proposals simultaneously. + +When a track's capacity is full, additional proposals in the lead-in period will queue until there is space to move into the decision period. + +--- + +### **Conviction Voting** + +Hydration utilizes an idea called voluntary locking that allows token holders to increase their voting power by declaring how long they are willing to lock up their tokens; hence, the number of votes for each token holder will be calculated by the following formula: + +votes = tokens * conviction_multiplier + +The conviction multiplier increases the vote multiplier by one every time the number of lock periods double. + +| Lock Periods | Vote Multiplier | Length in Days | +| --- | --- | --- | +| 0 | 0.1 | 0 | +| 1 | 1 | 7 | +| 2 | 2 | 14 | +| 4 | 3 | 28 | +| 8 | 4 | 56 | +| 16 | 5 | 112 | +| 32 | 6 | 224 | + +Votes are always "counted" at the same time (at the end of the voting period), no matter how long the tokens are locked. + +See below an example that shows how voluntary locking works. + +- Peter: Votes No with 10 DOT for a 32-week lock period => 10 x 6 = 60 Votes +- Logan: Votes Yes with 20 DOT for one week lock period => 20 x 1 = 20 Votes +- Kevin: Votes Yes with 15 DOT for a 2-week lock period => 15 x 2 = 30 Votes + +Even though both Logan and Kevin vote with more DOT than Peter, the lock period for both of them is less than Peter’s, leading to their voting power counting as less. + +--- + +### **Origins and Tracks** + +An **Origin** refers to a specific level of privilege or authority for referenda. Each Origin has its own tracks, which are the pipelines for proposals. Origins differ in their parameter requirements for referenda to pass, with more permissions resulting in higher requirements. + +For example, a runtime upgrade on the Root Origin has more significant implications than the approval of a treasury tip. Therefore, different parameter requirements are needed for these actions. + +Each Origin has distinct thresholds for decision deposits, support and approval requirements, and minimum enactment periods. Here are the key parameters: + +- **Maximum Deciding or Capacity**: the limit for the number of referenda that can be decided at once (i.e., the number of tracks within each origin). +- **Decision Deposit:** the amount of funds that must be placed on deposit for a referendum to enter the Decision Period (note that more requirements must be met to enter the Decision Period). +- **Preparation Period:** the minimum amount of voting time needed before entering the Decision Period (given capacity and deposit are met). +- **Decision Period:** the time interval during which a proposal's outcome can be decided. +- **Confirmation Period:** the minimum amount of time the approval and support criteria must hold before the proposal is approved and moved to the enactment period. The confirmation period should start before the end of the decision period. +- **Voting Period:** the total time allowed for voting, including preparation, decision, and confirmation periods. +- **Minimum Enactment Period:** the minimum amount of waiting time before the approved changes are applied. +- **Approval Curve:** a curve that shows the minimum percentage of 'aye' votes needed over time for a proposal to pass, ensuring strong voter support. +- **Support Curve:** a curve that shows the minimum overall support needed from all voters (including abstentions) over time, ensuring broad support among potential voters. + +For a quick overview of Hydration OpenGov tracks and their parameter values, see the table below. + +| OpenGov track | Description | Max Deciding | Decision Deposit | Prepare Period | Decision Period | Confirm Period | Min Enactment Period | Approval Curve | Support Curve | +|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------| --- |------------------|----------------|-----------------|----------------|----------------------| --- |-------------------------------| +| Root | Any action on the chain (e.g. upgrade the chain). Has the highest level of privilege and requires a high degree of approval and support. | 1 | 5,000,000 HDX | 10 Minutes | 7 Days | 1 Day | 4 Hours | Reciprocal | Linear Decreasing | +| Whitelisted Caller | For referenda whitelisted by the Technical Committee, typically used in emergencies. Shorter decision period and require less support to pass. | 10 | 50,000 HDX | 10 Minutes | 3 Days | 4 Hours | 10 Minutes | Reciprocal | Reciprocal Whitelisted Caller | +| Referendum Canceller | For referenda that seek to cancel other referenda without slashing the Decision Deposit. | 10 | 500,000 HDX | 1 Hour | 3 Days | 1 Hour | 10 Minutes | Linear Decreasing | Reciprocal | +| Referendum Killer | For referenda that seek to cancel other referenda and slash the Decision Deposit. | 10 | 2,500,000 HDX | 1 Hour | 3 Days | 3 Hours | 10 Minutes | Linear Decreasing | Reciprocal | +| General Admin | For general Protocol management, e.g. registrar or permissioned HRMP channel operations. | 10 | 500,000 HDX | 1 Hour | 7 Days | 3 Hours | 10 Minutes | Reciprocal | Reciprocal | +| Omnipool | For referenda aimed at changing parameters of the Omnipool. | 10 | 500,000 HDX | 1 Hour | 7 Days | 3 Hours | 10 Minutes | Linear Decreasing | Reciprocal | +| Treasurer | For referenda that seek to spend up to 50,000,000 HDX. | 10 | 1,250,000 HDX | 1 Hour | 7 Days | 12 Hours | 10 Minutes | Reciprocal | Linear Decreasing | +| Small Spender | For referenda that seek to spend up to 2,222,222 HDX. | 10 | 100,000 HDX | 1 Hour | 7 Days | 3 Hours | 10 Minutes | Linear Decreasing | Reciprocal | +| Small Tipper | For referenda that seek to spend up to 50,000 HDX. | 10 | 10,000 HDX | 1 Hour | 7 Days | 3 Hours | 10 Minutes | Linear Decreasing | Reciprocal | + +***Reciprocal** - Initially, a high level of approval is required for the referenda to enter the Confirmation Period. As time goes on, the level of approval needed decreases more slowly. + +****Linear Decreasing** - Initially, a high level of approval is required for referenda to enter their Confirmation Period. However, the level of approval needed decreases at a steady, predictable rate over time. + +--- + +### **Approval and Support** + +When a referendum exits the Lead-in Period and enters the Voting Period, it must meet two criteria for the duration of the Confirmation Period to be approved: **Approval** and **Support**. + +**Approval** - this measures the percentage of 'yes' (aye) votes compared to the total of 'yes' (aye) and 'no' (nay) votes, but with a twist: each vote can have different weights, known as convictions. + +- **Conviction-Weighted Votes**: Conviction multiplies the power of a vote. For example, if someone votes with 4x conviction, their vote counts four times more. What is gained in voting power is paid for with extended token locks. The higher your conviction, the longer your tokens will be locked. +- **Approval Calculation**: Approval is calculated as the share of conviction-weighted 'aye' votes against the total conviction-weighted 'aye' and 'nay' votes. + +**Support -** this measures the overall turnout of voters who are in favor or neutral (abstain), compared to the total possible votes in the system. + +- **Total Active Issuance**: This includes all possible votes. +- **Support Calculation**: Support is the total number of 'aye' and 'abstain' votes (without considering conviction) compared to the total active issuance. + +**Example 1: Calculating Approval & Support** + +Imagine the total active issuance is 100 DOT: + +- **Account A** votes "Aye" with 10 DOT and 4x conviction. +- **Account B** votes "Nay" with 5 DOT and 2x conviction. +- **Account C** votes "Abstain" with 20 DOT (no conviction for abstain votes). + +In this scenario, only 35 DOT from the total active issuance participated in voting. + +**Approval** + +1. Multiply votes by their conviction: + - Aye' = 10 DOT * 4 = 40 + - Nay' = 5 DOT * 2 = 10 +2. Total weighted votes = 40 (Aye') + 10 (Nay') = 50 +3. Approval = (Aye' / Total weighted votes) * 100 = (40 / 50) * 100 = 80% + +**Support** + +1. Add 'aye' and 'abstain' votes: + - Aye + Abstain = 10 + 20 = 30 +2. Support = (Total 'aye' + Abstain) / Total active issuance * 100 = (30 / 100) * 100 = 30% + +**Note**: Nay votes are not counted towards Support. Support measures voters who turned out either in favor or who consciously abstained. + +**Example 2: Understanding Approval & Support Curves** + +
+ opengov_approval_support_curve +
+ + +The figure above shows the following: + +- Even if the approval threshold is reached (i.e., % of current approval is greater than the approval curve), the proposal only enters the confirmation period once the support threshold is also reached (i.e., % current support is greater than the underlying support curve). +- If the referendum meets the approval and support thresholds for the duration of the confirmation period, the proposal will be approved and will be scheduled for enactment. Each track has a default minimum Enactment Period, and the approved referendum needs to wait till the end of it to be executed. Powerful Tracks like Root enforce a larger Enactment Period to ensure the network has ample time to prepare for any changes the proposal may bring. The referendum proposers can also set the enactment period higher than its default value. +- A referendum may exit the confirmation period when the thresholds are no longer met due to new *Nay* votes or a change of existing *Aye* or *Abstain* votes to *Nay* . Each time it exits, the confirmation period clock is reset. For example, suppose the confirmation period is 20 minutes, and a referendum enters it just for 5 min before exiting. The next time it enters, it must be confirmed for 20 minutes (not 15 minutes). +- It is possible that a referendum meets the approval and support thresholds almost at the end of the decision period. In this case, even though the decision period elapses, the referendum can pass if it stays confirming for the duration of the track-specific confirmation period. It is rejected immediately if it exits the confirmation period after the decision period elapses. +- The approval curve starts at 100% and gradually decreases to 50%, but never below 50%. Assuming all the active token supply has voted on a proposal, the conviction vote-weighted support should always be above 50% to pass. + +### **Approval & Support Curves for OpenGov Tracks** + +Different Origins have varying Confirmation Periods and requirements for Approval and Support. Referenda using less privileged origins may have lower support requirements compared to those using highly privileged origins like Root. Below are the approval and support curves for the different Origins of Hydration OpenGov. + +
+ root_approval_support_curve +
+ +**Root** - For referenda that seeks to change the protocol’s runtime + +
+ whitelisted_caller_approval_support_curve +
+ +**Whitelisted Caller** - For referenda submitted by the Technical Committee + +
+ referendum_canceller_approval_support_curve +
+ +**Referendum Canceller** - For referenda that seek to cancel other referenda without slashing the Decision Deposit + +
+ referendum_killer_approval_support_curve +
+ +**Referendum Killer** - For referenda that seek to cancel other referenda and slash the Decision Deposit + +
+ general_admin_approval_support_curve +
+ +**General Admin** - For referenda that seeks to manage the registrar and permissioned HRMP channel operations + +
+ omnipool_approval_support_curve +
+ +**Omnipool** - For referenda aimed at changing parameters of the Omnipool + +
+ treasurer_approval_support_curve +
+ +**Treasurer** - For referenda that seeks to spend up to $500,000 + +
+ spender_approval_support_curve +
+ +**Spender** - For referenda that seeks to spend up to $5,000 + +
+ tipper_approval_support_curve +
+ +**Tipper** - For referenda that seeks to spend up to $500 + +--- + +### **Cancelling & Killing Referenda** + +In OpenGov, referenda can be rejected in two ways before the voting period ends: by submitting a referendum in the Referendum Canceller and Referendum Killer tracks. + +**Referendum Canceller** aims to cancel an already ongoing referendum. When this origin cancels a referendum, the Submission and Decision Deposit are refunded to their originators. An example of when a referendum might be considered to be canceled is if the originator has made some errors in creating the preimage and did not necessarily do anything malicious. Cancellation has a lower Decision Period, and Approval and Support criteria are much easier to meet over time than most other Origins. This is because the cancellation of a referendum usually comes with a sense of urgency. + +**Referendum Killer** aims to instantly kill an ongoing referendum, slashing submission and decision deposit (the account(s) that posted these deposits will lose those funds). This origin can be engaged if, for example, a malicious actor submits a referendum on the Root Track to set the code of the chains' runtime to stop block production. + +The Decision Deposit for the Referendum Killer track itself is high to prevent malicious actors from attempting to slash deposits of good referenda. A subsequent Referendum Killer can kill an existing Referendum Killer. + +--- + +## **Delegations** + +In OpenGov, delegations build on the vote delegation feature from Governance v1, allowing voters to delegate their voting power to another voter. OpenGov introduces a feature called **Multirole Delegation**, where voters can choose different delegates for different types of referenda in the system. Delegation can be done per track, and accounts can select different delegates (or no delegation) for each track. + +For example, suppose a token holder does not have the technical background to consider the merits and vote on the referenda submitted to the Root track. In that case, they can delegate their voting power just for the Root track to a trusted expert who (according to them) acts in the best interest of the protocol. In this way, token holders do not need to be up-to-date with governance matters and can still make their votes count through delegates. + +### **Purpose of Delegations** + +- Ensure enough support for proposals to be enacted while keeping the system censorship-free. +- Help voters who may not have the technical knowledge or time to judge all referenda. +- Allow voters to participate hands-free by delegating their voting power to trusted entities. + +### **Key Points about Delegations** + +1. **Delegate with conviction locks -** When you undelegate your votes (take back your voting power), any conviction locks (periods during which your tokens are locked) will start immediately, whether or not your delegate used your votes for any referenda. This means your tokens will be locked for the conviction period even if they weren't used for voting. + + If you delegate votes to different delegates with different convictions, there will be various unlocking periods based on the conviction multipliers. + +2. **Undelegate without conviction -** If you delegate without conviction and then undelegate, you can unlock your tokens immediately. +3. **Undelegate with conviction -** If you delegate with a conviction (e.g., 1x or 2x) and then undelegate and re-delegate with a different conviction, multiple conviction locks are created. The highest conviction lock will determine when your tokens can be unlocked. + +### **Important Details** + +- Before delegating a specific track, you must remove any vote on that track. +- Delegating voting power does not give the delegate control over your account's funds. The delegate can vote with your power but cannot transfer balances, choose validators, or execute any other actions besides voting on the defined tracks. +- Delegated votes do not give action points for staking rewards on Hydration. To understand what this means, read about [HDX staking](https://docs.hydration.net/staking). + +## **How to Use OpenGov** +For tutorials (how-to guides) on how to use OpenGov, read this [page](/guides/opengov). \ No newline at end of file diff --git a/docs/04_community/03_referenda.md b/docs/04_community/04_referenda.md similarity index 96% rename from docs/04_community/03_referenda.md rename to docs/04_community/04_referenda.md index e42a0756..edebe0cd 100644 --- a/docs/04_community/03_referenda.md +++ b/docs/04_community/04_referenda.md @@ -1,9 +1,14 @@ --- -title: Participate in Referenda +title: Referenda (old) --- import useBaseUrl from '@docusaurus/useBaseUrl'; +:::warning +This page relates to the old governance system (Gov v1) which has been replaced by OpenGov. +Please check the [OpenGov docs](/community/opengov) instead. +::: + This post provides a step-by-step guide on how to participate in referenda - voting and proposing. There are two alternative tools which you can use for this purpose - [Subsquare](#sub) or [Polkadot/apps](#polkajs). Before you decide to participate, we strongly encourage you to read through the [knowledge article](../governance/democracy_referenda) in the Learn / Democracy section. There you will find some important details on the mechanics behind referenda. diff --git a/docs/04_community/04_tip_request.md b/docs/04_community/05_tip_request.md similarity index 95% rename from docs/04_community/04_tip_request.md rename to docs/04_community/05_tip_request.md index e68d9bef..cad05332 100644 --- a/docs/04_community/04_tip_request.md +++ b/docs/04_community/05_tip_request.md @@ -4,6 +4,11 @@ title: Request a Treasury Tip import useBaseUrl from '@docusaurus/useBaseUrl'; +:::warning +This page relates to the old governance system (Gov v1) which has been replaced by OpenGov. +Please check the [OpenGov docs](/community/opengov) instead. +::: + Community members can request HDX tips from the Hydration Treasury as a reward for their contributions to the Protocol. This guide walks you through the process of tip requests. You can find more information about the different types of activities that get rewarded in [this post](../community/spending_fw). The process of requesting a Treasury tip consists of two steps. As a first step, contributors need to [publish their tip request](#01-publish-tip-request) in Subsquare with a description of the contribution. As a second step, the Treasury tip request must be [submitted on-chain](#02-submit-on-chain) using Polkadot/apps. diff --git a/docs/04_community/05_spending_fw.md b/docs/04_community/06_spending_fw.md similarity index 100% rename from docs/04_community/05_spending_fw.md rename to docs/04_community/06_spending_fw.md diff --git a/docs/04_community/06_claim.md b/docs/04_community/07_claim.md similarity index 100% rename from docs/04_community/06_claim.md rename to docs/04_community/07_claim.md diff --git a/docs/04_community/07_archive_hydradx_crowdloan.md b/docs/04_community/08_archive_hydradx_crowdloan.md similarity index 100% rename from docs/04_community/07_archive_hydradx_crowdloan.md rename to docs/04_community/08_archive_hydradx_crowdloan.md diff --git a/docs/02_products/01_trading/01_pools/01_omnipool/02_omnipool_trading.md b/docs_archive/02_omnipool_trading.md similarity index 100% rename from docs/02_products/01_trading/01_pools/01_omnipool/02_omnipool_trading.md rename to docs_archive/02_omnipool_trading.md diff --git a/sidebars.js b/sidebars.js index c1716de7..e9735995 100644 --- a/sidebars.js +++ b/sidebars.js @@ -1,8 +1,8 @@ export default { - myAutogeneratedSidebar: [ - { - type: 'autogenerated', - dirName: '.', // '.' means the current docs folder - }, - ], + myAutogeneratedSidebar: [ + { + type: 'autogenerated', + dirName: '.', // '.' means the current docs folder + }, + ], }; diff --git a/static/img/community/opengov/general_admin_curve.jpg b/static/img/community/opengov/general_admin_curve.jpg new file mode 100644 index 00000000..e90c1bc3 Binary files /dev/null and b/static/img/community/opengov/general_admin_curve.jpg differ diff --git a/static/img/community/opengov/omnipool_curve.jpg b/static/img/community/opengov/omnipool_curve.jpg new file mode 100644 index 00000000..d9daa8e5 Binary files /dev/null and b/static/img/community/opengov/omnipool_curve.jpg differ diff --git a/static/img/community/opengov/opengov_as.jpg b/static/img/community/opengov/opengov_as.jpg new file mode 100644 index 00000000..10f5a882 Binary files /dev/null and b/static/img/community/opengov/opengov_as.jpg differ diff --git a/static/img/community/opengov/ref_canceller_curve.jpg b/static/img/community/opengov/ref_canceller_curve.jpg new file mode 100644 index 00000000..ce4cb72b Binary files /dev/null and b/static/img/community/opengov/ref_canceller_curve.jpg differ diff --git a/static/img/community/opengov/ref_killer_curve.jpg b/static/img/community/opengov/ref_killer_curve.jpg new file mode 100644 index 00000000..481d6240 Binary files /dev/null and b/static/img/community/opengov/ref_killer_curve.jpg differ diff --git a/static/img/community/opengov/root_curve.jpg b/static/img/community/opengov/root_curve.jpg new file mode 100644 index 00000000..1779b03d Binary files /dev/null and b/static/img/community/opengov/root_curve.jpg differ diff --git a/static/img/community/opengov/spender_curve.jpg b/static/img/community/opengov/spender_curve.jpg new file mode 100644 index 00000000..760f814a Binary files /dev/null and b/static/img/community/opengov/spender_curve.jpg differ diff --git a/static/img/community/opengov/tipper_curve.jpg b/static/img/community/opengov/tipper_curve.jpg new file mode 100644 index 00000000..4eb360de Binary files /dev/null and b/static/img/community/opengov/tipper_curve.jpg differ diff --git a/static/img/community/opengov/treasurer_curve.jpg b/static/img/community/opengov/treasurer_curve.jpg new file mode 100644 index 00000000..eca6ffe6 Binary files /dev/null and b/static/img/community/opengov/treasurer_curve.jpg differ diff --git a/static/img/community/opengov/whitelisted_caller_curve.jpg b/static/img/community/opengov/whitelisted_caller_curve.jpg new file mode 100644 index 00000000..a6c65bb0 Binary files /dev/null and b/static/img/community/opengov/whitelisted_caller_curve.jpg differ diff --git a/static/img/guides/opengov/new_discussion_post.jpg b/static/img/guides/opengov/new_discussion_post.jpg new file mode 100644 index 00000000..9c593a7a Binary files /dev/null and b/static/img/guides/opengov/new_discussion_post.jpg differ diff --git a/static/img/guides/opengov/new_referendum.jpg b/static/img/guides/opengov/new_referendum.jpg new file mode 100644 index 00000000..544c4f72 Binary files /dev/null and b/static/img/guides/opengov/new_referendum.jpg differ