diff --git a/404.html b/404.html index 5f603b3d..84a2fb5c 100644 --- a/404.html +++ b/404.html @@ -4,13 +4,13 @@ Page Not Found | HydraDX Docs - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/archive_hydradx_crowdloan/index.html b/archive_hydradx_crowdloan/index.html index 37c67f69..4eba0bf2 100644 --- a/archive_hydradx_crowdloan/index.html +++ b/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX Crowdloan | HydraDX Docs - +
Skip to main content

HydraDX Crowdloan

danger

This page has been archived, meaning that the information it contains may be outdated or no longer applicable.

The HydraDX crowdloan for the Polkadot parachain auctions is now live! You can support HydraDX by participating in our crowdloan campaign and pledging some amount of DOT tokens which will be locked up for the duration of the parachain slot.

In return, you will be granted HDX rewards which cover your opportunity costs. Once the parachain slot has expired, you will receive your DOT tokens back in full. The same applies to the scenario that HydraDX does not manage to win a parachain slot within the crowdloan campaign deadline stated hereunder.

Crowdloan Details

  • Visit: https://loan.hydradx.io/
  • Crowdloan start: 28 December 2021
  • Bidding on slots: #6 - #11
  • Onboarding of winning parachains: 11 March 2022
  • End of leased parachain slots: 12 January 2024
  • Crowdloan cap: 8,000,000 DOT
  • Rewards: between 280 and 12.5 HDX per contributed DOT
  • Rewards cap: max. 1,000,000,000 HDX (10% of total supply)
  • Vesting period: HDX rewards are distributed linearly. The distribution will start after HydraDX has been onboarded as a Polkadot parachain and the transition from Snakenet (our testnet) has been completed.
  • Crowdloan campaign deadline: 12 March 2022

HDX Rewards

All participants in the HydraDX crowdloan will receive HDX in exchange for their contributions. The amount of the rewards depends on our rank in the parachain auction race at the time of your contribution, as well as the total amount of DOT which have been contributed by others.

Contributions made before HydraDX is leading the race by 15% will receive the highest amount of rewards - between 280 and 125 HDX per contributed DOT.

After we have secured a comfortable lead, the rewards will start dropping linearly. They will be at their lowest level once HydraDX has a lead of 25% or more. Contributions made during the time that we are leading by more than 25% will receive between 28 and 12.5 HDX per contributed DOT.

The rewards system is designed to offset the opportunity costs of locking your DOT for the duration of the parachain lease, as opposed to staking it. Contributions made before we have gained a 15% lead will get their full opportunity costs reimbursed. The price of HDX used for the calculation is $ 0.026. This number is based on the closing HDX LBP price of $ 0.08 (February 2021), after taking into account the upcoming tripling of all balances which were built up during our testnet.

- + \ No newline at end of file diff --git a/assets/js/d631f7a2.5f003177.js b/assets/js/d631f7a2.629c48ae.js similarity index 71% rename from assets/js/d631f7a2.5f003177.js rename to assets/js/d631f7a2.629c48ae.js index 2d017059..ea3ecff3 100644 --- a/assets/js/d631f7a2.5f003177.js +++ b/assets/js/d631f7a2.629c48ae.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=n)&&Object.keys(d.O).every((function(e){return d.O[e](t[o])}))?t.splice(o--,1):(a=!1,n0&&e[i-1][2]>n;i--)e[i]=e[i-1];e[i]=[t,f,n]},d.n=function(e){var c=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(c,{a:c}),c},t=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var n=Object.create(null);d.r(n);var r={};c=c||[null,t({}),t([]),t(t)];for(var a=2&f&&e;"object"==typeof a&&!~c.indexOf(a);a=t(a))Object.getOwnPropertyNames(a).forEach((function(c){r[c]=function(){return e[c]}}));return r.default=function(){return e},d.d(n,r),n},d.d=function(e,c){for(var t in c)d.o(c,t)&&!d.o(e,t)&&Object.defineProperty(e,t,{enumerable:!0,get:c[t]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(c,t){return d.f[t](e,c),c}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",868:"df3e0357",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1366:"6b8317b5",2209:"3e2cea56",2250:"07178ad8",2332:"9fd70990",2666:"df696b68",2989:"7921dc2a",3258:"b99fcc0c",3350:"33cc27dd",4020:"669853c7",4101:"1d2d6146",4621:"05550a0c",5058:"bb071bc7",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5553:"80a7be49",5888:"2cad9136",6021:"cf68faa2",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7080:"4d54d076",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8323:"70254ef3",8462:"dab19d87",8653:"b81d6f32",8696:"a53b80d1",8741:"4ccf5e49",8801:"c8fd52f7",8895:"311e3e95",9219:"144c5974",9366:"c116d048",9514:"1be78505",9650:"497f4115",9671:"0e384e19",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"ff75d206",548:"e14157b2",574:"c99a337a",868:"854c7f6a",942:"5f003177",994:"53706c1c",1019:"05b39c12",1366:"2663e908",2209:"4ee5ad22",2250:"7fa664d8",2332:"c1c74f3c",2666:"52ff62e3",2989:"16e0c251",3258:"8aa2272f",3350:"592ee251",4020:"a4ce9eb2",4101:"b7d4969b",4621:"3799cfee",4972:"79f8b409",5058:"1b42c5ad",5183:"68e37a78",5355:"1a340719",5445:"5ea46efb",5488:"e92137be",5536:"75418680",5553:"b97c2d37",5888:"5900fe8b",6021:"05b4704a",6295:"bd462ac5",6428:"fd1dd37b",6714:"d1c44573",6880:"43006994",7080:"afc58c40",7615:"5f50a96b",7918:"bff4c59e",7939:"67f08b81",8323:"dc081fa1",8462:"25ece056",8653:"da253862",8696:"edc1eb48",8741:"7b4e3cdd",8801:"ba17e635",8895:"f6a1fef6",9219:"2b0ee72d",9366:"1fcc4e76",9514:"4cb072e6",9650:"92d4c46c",9671:"38752cb7",9726:"a3319393"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,c){return Object.prototype.hasOwnProperty.call(e,c)},f={},n="hydra-dx-docs:",d.l=function(e,c,t,r){if(f[e])f[e].push(c);else{var a,o;if(void 0!==t)for(var u=document.getElementsByTagName("script"),i=0;i=n)&&Object.keys(d.O).every((function(e){return d.O[e](t[o])}))?t.splice(o--,1):(a=!1,n0&&e[i-1][2]>n;i--)e[i]=e[i-1];e[i]=[t,f,n]},d.n=function(e){var c=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(c,{a:c}),c},t=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,f){if(1&f&&(e=this(e)),8&f)return e;if("object"==typeof e&&e){if(4&f&&e.__esModule)return e;if(16&f&&"function"==typeof e.then)return e}var n=Object.create(null);d.r(n);var r={};c=c||[null,t({}),t([]),t(t)];for(var a=2&f&&e;"object"==typeof a&&!~c.indexOf(a);a=t(a))Object.getOwnPropertyNames(a).forEach((function(c){r[c]=function(){return e[c]}}));return r.default=function(){return e},d.d(n,r),n},d.d=function(e,c){for(var t in c)d.o(c,t)&&!d.o(e,t)&&Object.defineProperty(e,t,{enumerable:!0,get:c[t]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(c,t){return d.f[t](e,c),c}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",868:"df3e0357",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1366:"6b8317b5",2209:"3e2cea56",2250:"07178ad8",2332:"9fd70990",2666:"df696b68",2989:"7921dc2a",3258:"b99fcc0c",3350:"33cc27dd",4020:"669853c7",4101:"1d2d6146",4621:"05550a0c",5058:"bb071bc7",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5553:"80a7be49",5888:"2cad9136",6021:"cf68faa2",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7080:"4d54d076",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8323:"70254ef3",8462:"dab19d87",8653:"b81d6f32",8696:"a53b80d1",8741:"4ccf5e49",8801:"c8fd52f7",8895:"311e3e95",9219:"144c5974",9366:"c116d048",9514:"1be78505",9650:"497f4115",9671:"0e384e19",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"ff75d206",548:"e14157b2",574:"c99a337a",868:"854c7f6a",942:"629c48ae",994:"53706c1c",1019:"05b39c12",1366:"2663e908",2209:"4ee5ad22",2250:"7fa664d8",2332:"c1c74f3c",2666:"52ff62e3",2989:"16e0c251",3258:"8aa2272f",3350:"592ee251",4020:"a4ce9eb2",4101:"b7d4969b",4621:"3799cfee",4972:"79f8b409",5058:"1b42c5ad",5183:"68e37a78",5355:"1a340719",5445:"5ea46efb",5488:"e92137be",5536:"75418680",5553:"b97c2d37",5888:"5900fe8b",6021:"05b4704a",6295:"bd462ac5",6428:"fd1dd37b",6714:"d1c44573",6880:"43006994",7080:"afc58c40",7615:"5f50a96b",7918:"bff4c59e",7939:"67f08b81",8323:"dc081fa1",8462:"25ece056",8653:"da253862",8696:"edc1eb48",8741:"7b4e3cdd",8801:"ba17e635",8895:"f6a1fef6",9219:"2b0ee72d",9366:"1fcc4e76",9514:"4cb072e6",9650:"92d4c46c",9671:"38752cb7",9726:"a3319393"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,c){return Object.prototype.hasOwnProperty.call(e,c)},f={},n="hydra-dx-docs:",d.l=function(e,c,t,r){if(f[e])f[e].push(c);else{var a,o;if(void 0!==t)for(var u=document.getElementsByTagName("script"),i=0;i Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/build_dev_chain/index.html b/build_dev_chain/index.html index b8091558..c03d2999 100644 --- a/build_dev_chain/index.html +++ b/build_dev_chain/index.html @@ -4,14 +4,14 @@ Set up a Development Chain | HydraDX Docs - +

Set up a Development Chain

This section runs you through the process of setting up a local HydraDX chain instance for development.

01 Install dependencies

To prepare a local HydraDX chain instance for development, your machine needs to cover all dependencies for running a Substrate chain. You will need to install a Rust developer environment and make sure that it is configured properly for compiling Substrate runtime code to the WebAssembly (Wasm) target.

You can install and configure all dependencies manually following the Substrate guide, or you could let this script do all the work for you:

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Build

Build the Wasm and native execution environments:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Build the binary
$ cd HydraDX-node/
$ cargo build --release

You should be able to find the build under ./target/release/hydra-dx.

03 Run

Before running your build you can purge any existing development chains on your machine (you will need to do this often in the development process):

$ ./target/release/hydra-dx purge-chain --dev

Run your build using one of the following commands:

$ ./target/release/hydra-dx --dev

# Run with detailed logging
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Connect to your local chain instance

You can connect to your HydraDX development node using Polkadot/apps and changing network to Development. You can also use this link:
https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/claim/index.html b/claim/index.html index ae781a1d..424648d8 100644 --- a/claim/index.html +++ b/claim/index.html @@ -4,13 +4,13 @@ Claim your HDX | HydraDX Docs - +

Claim your HDX

You can claim your HDX with the xHDX tokens (ERC-20) that you have obtained in the period when our Balancer LBP was live.

Prerequisites

There are two prerequisites for claiming your HDX. In the first place, you need to install the Polkadot.js browser extension which will be used to create your HDX wallet. In the second place, you need access to your xHDX tokens which should be stored in a wallet supporting the signing of messages relating to ERC-20 tokens (e.g. Metamask).

If your xHDX tokens are stored in Coinbase Wallet or Trust Wallet, you will need to use one of the following workarounds for claiming your HDX, as these wallets do not support the signing of messages:

  • Metamask: You can use the Metamask browser extension and import your wallet using the recovery seed phrase.
  • MEW (MyEtherWallet): You can also use MEW by either importing your recovery seed phrase (Mnemonic Phrase) or by using the WalletLink connection option. Both options can be accessed from the MEW wallet access page. If you are using Coinbase Wallet, you can use WalletLink which you can find the Settings of Coinbase Wallet.

Claim process

After making sure that you have fulfilled the prerequisites described above, you can navigate to the HydraDX Claim app and proceed with the claim process.

During the claim process, you will use your xHDX tokens (ERC-20) to claim your share of HDX tokens.

00 Authorize

The HydraDX Claim app will request authorization from the Polkadot.js browser extension.

danger

Make sure that you are not the victim of a phishing attack and pay attention to the authorization popup: The application should be identifying itself as CLAIM.HYDRADX.IO and the request should be coming from https://claim.hydradx.io.

authorize

After authorizing, you will be prompted to update the metadata for the Polkadot.js browser extension. This will allow Polkadot.js to create HydraDX-specific addresses which are required to complete the claim process.

authorize

01 Select your ETH address

In the first step of the claim process, you will be asked to select the account holding your xHDX tokens. This can be done by either connecting to your wallet holding the ERC-20 tokens (e.g. Metamask), or by entering your ETH address manually in the input box (in that case you will need to sign the message manually later).

After entering your ETH address, you should see the balance of HDX tokens you can claim, including the refund of the gas fees that you have spent for obtaining your xHDX on Balancer.

note

You are not eligible for a gas refund if you have obtained your xHDX at some other place than the official Balancer pool (such as Uniswap), or if you have moved your tokens out of the original buying wallet.

authorize

02 Create and select an HDX address

In the second step, you will be asked to select your HDX address.

To create a new HDX address, open the Polkadot.js browser extension and click on the + sign to create a new account. In the first step of account creation, you will see the 12-word mnemonic phrase which can be used to recover your account. After saving your seed phrase in a secure place, click on Next step. Here, you should change the Network by selecting the option HydraDX Snakenet. Enter a name and password for your account, and finish the account creation.

authorize
danger

Make sure that you back up your recovery seed phrase by storing it in a safe place and never share it with anybody. Using the seed phrase is the only way you can recover your account and if you lose or leak it, your funds might be compromised. Please note that you need to secure your access to this wallet until the mainnet starts, as all HDX balances are currently locked. If you lose access to your HDX wallet you will also lose your HDX.

After creating your HDX account, you should be able to select it in the HydraDX Claim app. After doing so, the app should provide you with an overview of the ETH and HDX addresses used for the claim process. Click on next to proceed to signing the message.

authorize

03 Sign

In the third step of the claim process using the HydraDX Claim app, you will be provided with the option to sign the message for using your xHDX tokens to claim HDX.

note

Please note that in this step you will see the public key of your HDX address, and not the address in its human readable form as it was displayed in the previous step and in your Polkadot.js browser extension (for more details refer to the ss58 docs). If you have followed all steps as described above, there is nothing to worry about and it is safe to proceed with signing the message. We will also verify that the HDX account you are using to sign the claim transaction at the final step corresponds with the account which is receiving the claimed HDX.

Depending on the choice you have made in the first step, you have two options to sign the message for using the xHDX tokens in the claim process:

  • If you are using Metamask, after clicking the Sign button you will be prompted by Metamask to sign the message. Follow the instructions in Metamask.

  • If you have entered your ETH address manually, you will need to sign the message through the external wallet that holds the private keys of your xHDX tokens. Once you have signed the message, copy the signature (starting with 0x) to the respective field in the HydraDX Claim app.

authorize

04 Claim

After signing the message with the wallet holding your xHDX tokens, the Polkadot.js extension should open and you will be asked to sign the transaction for claiming the HDX to your account. Enter your HDX account password, and click Sign the transaction.

authorize

You have now completed the claim process, thereby officially becoming an HDX owner!

You can check your balance using Polkadot/apps connected to the HydraDX network: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/cn/404.html b/cn/404.html index 1b7333ef..d89b9149 100644 --- a/cn/404.html +++ b/cn/404.html @@ -4,13 +4,13 @@ 哎呀!网页找不到了...... | HydraDX Docs - +

哎呀!网页找不到了......

我们找不到您想要的东西!

请联系将您引导至此的 URL 所有者,并告知其链接已损坏。

- + \ No newline at end of file diff --git a/cn/archive_hydradx_crowdloan/index.html b/cn/archive_hydradx_crowdloan/index.html index 799983c7..f68fdada 100644 --- a/cn/archive_hydradx_crowdloan/index.html +++ b/cn/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX 众贷 | HydraDX Docs - +

HydraDX 众贷

danger

此页面已存档,意味着它包含的信息可能已过时或不再适用。

Polkadot 平行链拍卖的 HydraDX 众贷现已上线!您可以通过参与我们的众贷活动并贡献锁定一定数量的 DOT 令牌来支持 HydraDX,这些令牌将在平行链插槽期间被锁定。

作为回报,您将获得 HDX 奖励,用于支付您的机会成本。 一旦平行链插槽过期,您将收到全额返还的 DOT 令牌。 这同样适用于 HydraDX 未能在下文所述众贷活动截止日期内赢得平行链插槽的情况。

众贷详情

  • 访问: https://loan.hydradx.io/
  • 众贷开始: 2021 年 12 月 28 日
  • 插槽竞标: #6 - #11
  • 获胜平行链后的接入: 2022 年 3 月 11 日
  • 租赁平行链插槽结束: 2024 年 1 月 12 日
  • 众贷上限: 8,000,000 DOT
  • 奖励: 每个贡献的 DOT 奖励 280 到 12.5 HDX
  • 奖励上限: 不超过 1,000,000,000 HDX (总供应量的 10%)
  • 归属期: HDX 奖励 线性分配。分发,将在 HydraDX 作为 Polkadot 平行链接入,并完成从 Snakenet(我们的测试网)迁移后开始。
  • 众贷活动截止日期: 2022 年 3 月 12 日

HDX 奖励

HydraDX 众贷所有参与者,都将 获得 HDX,以奖励他们的贡献。 奖励的多少,取决于您贡献时我们 在平行链拍卖竞赛中的排名,以及其他人贡献的 DOT 总量

HydraDX 领先 15% 之前 做出的贡献,将获得最高金额的奖励 - 每个贡献的 DOT 将获得 280 到 125 HDX

在我们获得舒适的领先优势后,奖励将开始 线性下降。 一旦 HydraDX 领先 25% 或更多,它们将处于最低水平。 在我们领先超过 25% 的时间内做出的贡献,每个贡献的 DOT 将获得 28 到 12.5 HDX。

奖励系统,旨在抵消在平行链租赁期间锁定您的 DOT 的 机会成本,而不是抵押它。 在我们获得 15% 的领先优势之前做出的贡献,将获得 全部机会成本的补偿。 用于计算的 HDX 价格为 0.026 美元。 该数字源于 HDX LBP 收盘价 0.08 美元(2021 年 2 月),同时考虑测试网期间实施的所有余额增至三倍这一因素。

- + \ No newline at end of file diff --git a/cn/assets/js/d631f7a2.d057361d.js b/cn/assets/js/d631f7a2.8cc21f25.js similarity index 70% rename from cn/assets/js/d631f7a2.d057361d.js rename to cn/assets/js/d631f7a2.8cc21f25.js index 070f30d3..fbcf75a9 100644 --- a/cn/assets/js/d631f7a2.d057361d.js +++ b/cn/assets/js/d631f7a2.8cc21f25.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=r)&&Object.keys(a.O).every((function(e){return a.O[e](f[o])}))?f.splice(o--,1):(d=!1,r0&&e[u-1][2]>r;u--)e[u]=e[u-1];e[u]=[f,n,r]},a.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return a.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},a.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);a.r(r);var c={};t=t||[null,f({}),f([]),f(f)];for(var d=2&n&&e;"object"==typeof d&&!~t.indexOf(d);d=f(d))Object.getOwnPropertyNames(d).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},a.d(r,c),r},a.d=function(e,t){for(var f in t)a.o(t,f)&&!a.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},a.f={},a.e=function(e){return Promise.all(Object.keys(a.f).reduce((function(t,f){return a.f[f](e,t),t}),[]))},a.u=function(e){return"assets/js/"+({4:"93e09bc6",17:"0f5b2c31",34:"69cc0604",53:"935f2afb",130:"4727d998",170:"a2bdce7f",555:"bd09a06c",574:"9deda591",868:"df3e0357",890:"97e46bc0",942:"d631f7a2",1128:"78f1e280",1241:"99d2fb8d",1612:"ff018aef",1672:"659c6af6",1834:"4eb111ee",1925:"4b800410",2332:"9fd70990",2755:"7d4d5edb",3075:"44005d35",3191:"3f560d8f",3598:"d38882c4",3600:"e37e2d01",4102:"6cec9ae9",4176:"7a2cf6e2",4177:"3369f823",4348:"576d8994",4418:"615ab048",4632:"c8f6f312",5355:"7c015a33",5488:"3c1194d0",5501:"ad746ab3",5554:"c5b2c5f5",5722:"5bcdc0d2",6368:"0ad71b7d",6969:"fee8eb78",7685:"2a532691",7846:"98acac85",7861:"f8214058",7918:"17896441",8102:"acd1db02",8164:"707312f4",8189:"c383f006",8741:"4ccf5e49",9493:"9f8fc863",9514:"1be78505",9628:"4f7aa6bb",9704:"bb9f71e5",9995:"1294b904"}[e]||e)+"."+{4:"39881315",17:"308ae345",34:"5d1a04f1",53:"bb1cec17",130:"d930f78c",170:"54a371e8",555:"6099afc0",574:"ad3254d2",868:"8f8760c3",890:"0f0616d0",942:"d057361d",1128:"7a2bf388",1241:"60053527",1612:"9f5a5150",1672:"363f053e",1834:"8fd5e35e",1925:"4d2494b7",2332:"c2d5e52c",2755:"1af0dcbd",3075:"d0782112",3191:"10a4a432",3598:"548964a6",3600:"e795f82e",4102:"175a9d5f",4176:"3b23cd39",4177:"e5d3211e",4348:"cafba404",4418:"51054974",4632:"8ff3a5e1",4972:"79f8b409",5355:"29e756a1",5488:"18099505",5501:"059bf7e9",5554:"1e3a76d9",5722:"c706bf07",6368:"8f664f53",6969:"684313be",7685:"978c976d",7846:"2d9dc682",7861:"eca1f3ba",7918:"bff4c59e",8102:"872ca3f9",8164:"a133edb0",8189:"48c6f96c",8741:"4bb884da",9493:"107bec22",9514:"4cb072e6",9628:"ce199967",9704:"a567f1b6",9995:"b940a244"}[e]+".js"},a.miniCssF=function(e){},a.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),a.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",a.l=function(e,t,f,c){if(n[e])n[e].push(t);else{var d,o;if(void 0!==f)for(var b=document.getElementsByTagName("script"),u=0;u=r)&&Object.keys(a.O).every((function(e){return a.O[e](f[o])}))?f.splice(o--,1):(d=!1,r0&&e[u-1][2]>r;u--)e[u]=e[u-1];e[u]=[f,n,r]},a.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return a.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},a.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);a.r(r);var c={};t=t||[null,f({}),f([]),f(f)];for(var d=2&n&&e;"object"==typeof d&&!~t.indexOf(d);d=f(d))Object.getOwnPropertyNames(d).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},a.d(r,c),r},a.d=function(e,t){for(var f in t)a.o(t,f)&&!a.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},a.f={},a.e=function(e){return Promise.all(Object.keys(a.f).reduce((function(t,f){return a.f[f](e,t),t}),[]))},a.u=function(e){return"assets/js/"+({4:"93e09bc6",17:"0f5b2c31",34:"69cc0604",53:"935f2afb",130:"4727d998",170:"a2bdce7f",555:"bd09a06c",574:"9deda591",868:"df3e0357",890:"97e46bc0",942:"d631f7a2",1128:"78f1e280",1241:"99d2fb8d",1612:"ff018aef",1672:"659c6af6",1834:"4eb111ee",1925:"4b800410",2332:"9fd70990",2755:"7d4d5edb",3075:"44005d35",3191:"3f560d8f",3598:"d38882c4",3600:"e37e2d01",4102:"6cec9ae9",4176:"7a2cf6e2",4177:"3369f823",4348:"576d8994",4418:"615ab048",4632:"c8f6f312",5355:"7c015a33",5488:"3c1194d0",5501:"ad746ab3",5554:"c5b2c5f5",5722:"5bcdc0d2",6368:"0ad71b7d",6969:"fee8eb78",7685:"2a532691",7846:"98acac85",7861:"f8214058",7918:"17896441",8102:"acd1db02",8164:"707312f4",8189:"c383f006",8741:"4ccf5e49",9493:"9f8fc863",9514:"1be78505",9628:"4f7aa6bb",9704:"bb9f71e5",9995:"1294b904"}[e]||e)+"."+{4:"39881315",17:"308ae345",34:"5d1a04f1",53:"bb1cec17",130:"d930f78c",170:"54a371e8",555:"6099afc0",574:"ad3254d2",868:"8f8760c3",890:"0f0616d0",942:"8cc21f25",1128:"7a2bf388",1241:"60053527",1612:"9f5a5150",1672:"363f053e",1834:"8fd5e35e",1925:"4d2494b7",2332:"c2d5e52c",2755:"1af0dcbd",3075:"d0782112",3191:"10a4a432",3598:"548964a6",3600:"e795f82e",4102:"175a9d5f",4176:"3b23cd39",4177:"e5d3211e",4348:"cafba404",4418:"51054974",4632:"8ff3a5e1",4972:"79f8b409",5355:"29e756a1",5488:"18099505",5501:"059bf7e9",5554:"1e3a76d9",5722:"c706bf07",6368:"8f664f53",6969:"684313be",7685:"978c976d",7846:"2d9dc682",7861:"eca1f3ba",7918:"bff4c59e",8102:"872ca3f9",8164:"a133edb0",8189:"48c6f96c",8741:"4bb884da",9493:"107bec22",9514:"4cb072e6",9628:"ce199967",9704:"a567f1b6",9995:"b940a244"}[e]+".js"},a.miniCssF=function(e){},a.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),a.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",a.l=function(e,t,f,c){if(n[e])n[e].push(t);else{var d,o;if(void 0!==f)for(var b=document.getElementsByTagName("script"),u=0;u Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/cn/build_dev_chain/index.html b/cn/build_dev_chain/index.html index a5b687bb..451abdfd 100644 --- a/cn/build_dev_chain/index.html +++ b/cn/build_dev_chain/index.html @@ -4,14 +4,14 @@ Set up a Development Chain | HydraDX Docs - +

Set up a Development Chain

This section runs you through the process of setting up a local HydraDX chain instance for development.

01 Install dependencies

To prepare a local HydraDX chain instance for development, your machine needs to cover all dependencies for running a Substrate chain. You will need to install a Rust developer environment and make sure that it is configured properly for compiling Substrate runtime code to the WebAssembly (Wasm) target.

You can install and configure all dependencies manually following the Substrate guide, or you could let this script do all the work for you:

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Build

Build the Wasm and native execution environments:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Build the binary
$ cd HydraDX-node/
$ cargo build --release

You should be able to find the build under ./target/release/hydra-dx.

03 Run

Before running your build you can purge any existing development chains on your machine (you will need to do this often in the development process):

$ ./target/release/hydra-dx purge-chain --dev

Run your build using one of the following commands:

$ ./target/release/hydra-dx --dev

# Run with detailed logging
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Connect to your local chain instance

You can connect to your HydraDX development node using Polkadot/apps and changing network to Development. You can also use this link:
https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/cn/claim/index.html b/cn/claim/index.html index 2b79346f..fa797c9d 100644 --- a/cn/claim/index.html +++ b/cn/claim/index.html @@ -4,14 +4,14 @@ 申领您的 HDX | HydraDX Docs - +

申领您的 HDX

您可以使用 Balancer LBP 期间获得的 xHDX 令牌(ERC-20)申领您的 HDX。

前提条件

申领 HDX,有两个前提条件。首先,您需在浏览器上安装 Polkadot.js 扩展程序,它将用于创建 HDX 钱包。其次,您需要访问您的 xHDX 令牌,该令牌应该存储在支持 ERC-20 令牌消息签署的钱包中(如 Metamask)。

如果您的 xHDX 令牌存储在 Coinbase 钱包或 Trust 钱包中,则需使用以下其中一个方法申领 HDX,因它们不支持消息签署:

  • Metamask:您可以使用 Metamask 浏览器扩展程序,并使用恢复种子短语(助记词 )导入钱包。
  • MEW (MyEtherWallet):您可以通过导入恢复种子短语(助记词 ) 或使用 WalletLink 连接这两个选项来使用 MEW 。这两个选项都可从 MEW 钱包页面 访问。如果您使用的是 Coinbase 钱包,则可以使用 WalletLink,在那里可以找到 Coinbase 的设置。

申领过程

满足上述前提条件后,您可以导航到 HydraDX 申领程序,启动申领过程。

在申领过程中,您将使用 xHDX 令牌(ERC-20)申领属于您的 HDX 令牌份额。

00 授权

HydraDX 申领程序,需要 Polkadot.js 扩展程序的授权。

danger

请确保您不是钓鱼攻击的受害者,注意授权弹出:申领程序应自我标识为 CLAIM.HYDRADX.IO,且请求来自于 https://claim.hydradx.io

authorize

授权后,会提示您更新 Polkadot.js 扩展程序的元数据。这将允许 Polkadot.js 创建一个申领过程所需的 HydraDX 特定地址。

authorize

01 选择 ETH 地址

在这一步,系统将要求选择持有您 xHDX 令牌的帐户。可通过连接到支持 ERC-20 令牌(如 Metamask)的钱包,或在输入框手动输入 ETH 地址完成(在此情况下,稍后需手动签署消息)。

确认 ETH 地址后,您应该能看到可申领的 HDX 令牌余额,包括您在 Balancer 上获得 xHDX 所花费的 Gas 退款

note

如果您在 Balancer 官方池以外的其它地方(如 Uniswap)获得了 xHDX,或已将 xHDX 令牌从原始购买钱包中移出,则无资格获得 Gas 退款。

authorize

02 创建并选择 HDX 地址

这一步,将要求您选择 HDX 地址。

要创建新的 HDX 地址,请打开 Polkadot.js 扩展程序,单击 + 号创建一个新帐户。在帐户创建的第一步,您会看到由 12 个英语单词组成、用于恢复帐户的助记词。将助记词保存在安全的地方后,点击 Next step(下一步)。在这里,选择 HydraDX 来切换 NETWORK (网络)。输入您的帐户名称和密码,完成帐户创建。

authorize
danger

确保通过安全的方式保存备份您的助记词,并且永远不要分享给任何人。助记词,是恢复账户的唯一方法,丢失或泄漏它可能会造成加密资产的损失。请注意,当前所有的 HDX 令牌均被锁定,主网启动前,您需要确保拥有对钱包的访问权限。如无法访问 HDX 钱包,那您也就丢失了所拥有的 HDX 。

创建 HDX 帐户后,您应能在 HydraDX 申领程序中选择它。之后,该应用程序应为您提供用于申领过程的 ETH 和 HDX 地址概况。单击 Next(下一步)继续对消息进行签署。

authorize

03 签署

在这一步,您将可以选择用 xHDX 令牌申领 HDX 的消息进行签署。

note

请注意,在此步骤中,您将看到 HDX 地址的 公钥 ,而不是上一步和 Polkadot.js 扩展程序中显示的该地址的可读格式形式的地址(更多详细信息,请参阅 ss58 文档 )。如果您已严格按照上述步骤进行操作,则无需担心,可以安全地对消息进行签署。我们还将验证,您最后一步用于签署申领交易的 HDX 帐户,与接收所申领 HDX 的帐户是否相对应。

根据您第一步的选择,有两个方法可对消息进行签署,以在申领过程中使用 xHDX 令牌:

  • 如果您用的是 Metamask , 则在单击 Sign(签署)按钮后,将由 Metamask 提示您对信息进行签署。请按 Metamask 中的说明进行操作。

  • 如果您手动输入了 ETH 地址,则需通过外部钱包签署消息,该外部钱包保留了您 xHDX 令牌的私钥。签署消息后,将签署哈希(以 0x 开头)复制粘贴到 HydraDX 申领程序的相应对话框中。

authorize

04 申领

使用持有 xHDX 令牌的钱包签署消息后,Polkadot.js 扩展程序应自动打开,并将要求签署交易,以将 HDX 申领到您的帐户中。输入您的 HDX 帐户密码,然后点击 Sign the transaction(签署交易)。

authorize

此时您已完成申领过程,从而正式成为 HDX 的所有者。

您可以使用连接到 HydraDX 网络检查令牌数额: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/cn/collator_setup/index.html b/cn/collator_setup/index.html index 5c96f8fa..29b298b4 100644 --- a/cn/collator_setup/index.html +++ b/cn/collator_setup/index.html @@ -4,14 +4,14 @@ 搭建整理器节点 | HydraDX Docs - +

搭建整理器节点

这是一个启动并运行 HydraDX 整理器的分步操作指南。在本指南中,我们使用 Ubuntu 20.04 LTS。

所需要的技术条件

运行 HydraDX 整理器节点至少需要满足以下技术要求:

  • 操作系统:Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (或同等单核性能)
  • 内存: 64GB RAM
  • 存储:容量至少为 200GB 的 NVMe SSD(数据占用空间会随着时间增长)
note

这些是经团队验证过的最低技术要求。想要确保您的机器有足够的资源来运行节点?请运行 基本性能测试 以找出答案。

创建技术 hydra 用户并将其添加到 Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

下载并配置 hydradx 二进制文件

选择一个 12.x 版本,我们使用我们资产存储库中的 v12.1.0

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

命令您的整理器运行

最好是使用 systemctl 将您的整理器作为 service。 为此,在 /etc/systemd/system/hydradx-collator.service 中创建一个名为 hydradx-collator.service 的文件。

sudo vim /etc/systemd/system/hydradx-collator.service

然后粘贴以下内容:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

在开始您的节点之前,让我们创建基本路径文件夹并赋予它必要的权限和所有权:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
caution

使用 df -h 命令确保您为 base-path 留有足够的空间。

请注意,这 --prometheus-external 是可选的,但我们强烈建议您使用它,以便您能够导出 prometheus 指标并通过 Grafana 监控节点的健康状况。有关监控的更多详细信息,请访问 此链接

如果您需要同时监控 parachainrelaychain 指标,--prometheus-external 则应在这两个部分中设置选项。您还需要为中继链部分设置一个单独的端口,如下所示:--prometheus-port YOUR_CUSTOM_PORT_NUMBER

根据您的设置,您可能还想覆盖某些参数,如 websocket、rpc 或您的节点 p2p 端口。有关可用选项的更多信息,请使用 hydradx --help

保存文件后,运行以下命令启动节点:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

您的节点现在应该已启动并正在运行。确保您的 hydra 用户具有访问您 base-path 和密钥文件的必要权限。 如果您需要对正在运行的服务进行故障排除,可以使用带有拖尾选项的 journalctl 命令:-f

journalctl -fu hydradx-collator

生成您的密钥

为了让您的节点生成密钥,请运行以下命令:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

完成后,您将看到似于以下内容的输出:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

设置您的密钥

要将生成的会话密钥与您的控制器帐户相关联,请导航到 Polkadot 平行链 HydraDX 上的 Polkadot/apps 中的以下菜单项:Developer > Extrinsics

填写字段:

  • using selected account(使用所选帐户):选择您的控制器帐户;
  • submit the following extrinsic(提交以下外部内容):选择 session 左侧和setKeys 右侧;
  • keys(密钥):输入您刚刚生成的会话密钥;
  • proof(证明): 0;

下一步是什么

确保您的节点已完全同步。一旦完成,请在专用的 Discord 频道中告诉我们(仅当您已被预选为整理器时)。

- + \ No newline at end of file diff --git a/cn/contributing/index.html b/cn/contributing/index.html index d94b9c29..e39b1088 100644 --- a/cn/contributing/index.html +++ b/cn/contributing/index.html @@ -4,13 +4,13 @@ 撰写规范 | HydraDX Docs - +

撰写规范

您可以使用 GitHub 风格的 Markdown 语法 编写内容。

Markdown 语法

在设计基于 markdown 的 Docusaurus 网站时,用作示例页面。

标题

H1 - 创建最佳文档

H2 - 创建最佳文档

H3 - 创建最佳文档

H4 - 创建最佳文档

H5 - 创建最佳文档
H6 - 创建最佳文档

重点

强调:又称斜体,可在文字前后添加 单星号下划线

重点突出:又称黑体,可在文字前后添加 双星号下划线

组合强调:可在文字前后同时添加 双星号和下划线

删除线:在文字前后添加两个波浪号 这是啥东东?


目录

  1. 首个目录项
  2. 另一目录项
    • 无序号子目录
  3. 实际数字并不重要,只是一个数字
    1. 有序号子目录
  4. 再一个目录项
  • 无序子目录可以使用星号
  • 或减号
  • 或加号

内嵌型链接

标题内嵌型链接

参考型链接

用数字定义的参考型链接

或留空并使用链接文本本身

URL和尖括号中的URL,将自动变为链接。 http://www.example.com/http://www.example.com/ ,有时是 example.com(举例,不在 GitHub 上)。

一些文本表明参考链接可以在以后使用。


图片

这是我们的标志(悬停以查看标题文本):

内嵌型: alt text

参考型: alt text

通过提供文件路径,可以使用任何文件夹中的图像。路径应指向 markdown 文件。

![img]{useBaseUrl('/static/img/logo.svg')}


代码

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

表格

冒号(:),可用于列的对齐,示例如下:

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

每个标题单元格,至少须有 3 个破折号(-)。 外框线(|)是可选的,您不需要把原始 Markdown 排列得很漂亮(会自动排列整齐)。 您也可以使用内嵌 Markdown 。

MarkdownLessPretty
Stillrendersnicely
123

块引用

电子邮件中的块引用非常有用,可以模拟回复文本。该行是同一引用的一部分。

引用断开

这一行很长,当它换行时仍会被正确引用。 哦,boy,让我们继续,确保它够长,以满足所有人的实际需要。哦,您也可以将 Markdown 放入 块引用中。


内嵌 HTML

定义清单
是人们有时会用到的东西。
Markdown 在 HTML 中
*不* 是 **很** 好用。使用 HTML 标记

换行

这是我们要开始的第一行。

本行与上面一行之间,有两个换行符,因此它将成为一个单独段落

本行也是一个单独段落,但是......这一行只用一个换行符隔开,所以它是同一段落 中的单独一行。


告诫

注:请保持题头:note、tip、important、caution 和 warning 为原始英文状态,内容可根据您的需要撰写。

note

This is a note

tip

This is a tip

info

This is important

caution

This is a caution

danger

This is a warning

- + \ No newline at end of file diff --git a/cn/create_account/index.html b/cn/create_account/index.html index 60af1b19..42b26207 100644 --- a/cn/create_account/index.html +++ b/cn/create_account/index.html @@ -4,14 +4,14 @@ 创建 HDX 新账户 | HydraDX Docs - +

创建 HDX 新账户

创建 HDX 新帐户的过程包括三个简单的步骤。

01 安装 Polkadot.js

为了创建和管理您的 HDX 钱包,您需要安装 Polkadot.js 浏览器扩展程序

02 升级 metadata(元数据)

安装 Polkadot.js 浏览器扩展程序后,您应确保它已更新为最新的链元数据。 为此,可访问以下链接并在出现提示时更新元数据: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/settings/metadata

03 创建您的 HDX 账户

要创建 HDX 新地址,请打开 Polkadot.js 浏览器扩展程序并单击 + > Create new account(创建新账户)。

您将看到一个 12 个短语的助记词,可用于恢复您的帐户。 确保在安全的位置备份您的种子短语。 点击 Next step (下一步)并填写以下信息:

  • Network(网络): 请选择 HydraDX
  • Descriptive name of the account(账户的描述性名称)
  • Password(账户密码)

单击 Add the account with the generated seed(使用生成的种子添加账户)后,将创建您的帐户。

create-account
danger

确保通过将其存储在安全位置来备份您的恢复种子短语。 永远不要与任何人分享您的种子短语。 种子短语可用于访问您的帐户。 如果丢失或泄露,您可能还会丢失帐户中存储的所有 HDX。 请注意,在主网启动之前,所有 HDX 余额都会被锁定,因此您需要确保在此之前保持持有令牌的帐户安全。

- + \ No newline at end of file diff --git a/cn/democracy_council/index.html b/cn/democracy_council/index.html index 2d9b758b..6d14bb09 100644 --- a/cn/democracy_council/index.html +++ b/cn/democracy_council/index.html @@ -4,13 +4,13 @@ HydraDX 议会 | HydraDX Docs - +

HydraDX 议会

HydraDX 议会是一个链上实体,在协议的治理中起着关键作用。 本文提供有关议会 组成、议会 主要任务选举议会成员 等三方面信息。

有关如何参与议会选举的分步指导,请参阅 本指南

组成

HydraDX 议会目前由 13 名成员 组成。

创始团队和投资者(4 名创始人 + 2 名投资者)将获得 6 个席位中的少数席位。

剩下的 7 个席位由更广泛的 HDX 持有者社区选举产生。

任务和职责

HydraDX 议会的任务涵盖广泛的日常治理活动。 首先,议会控制财政部并批准或拒绝财政部的提案。

HydraDX 议会也在公投机制中发挥作用。 议会可以发起全民投票,前提是至少有 60% 的成员支持(绝对多数)并且没有成员行使否决权。 在否决的情况下,可以在冷却期过后重新提交提案。 否决成员不能两次否决同一提案。

此外,任何提议的公投都可以在获得议会 2/3 绝对多数票的情况下取消。 这可以用作阻止可能在代码中引入错误的恶意提议或更改的最后手段。

最后,HydraDX 议会负责选举技术委员会。

选举

HDX 令牌的任何持有者都可以 申请 作为 HydraDX 议会的 7 个非常任组的一个候选人。

议会选举每 7 天举行一次,届时将在接下来的 7 天内填补 7 个非常任议会席位。 民主模块使用相同的 Phragmen 算法。

所有社区成员都可以通过选择锁定他们一定数量的 HDX 令牌在议会选举中 投票 。 锁定的令牌不可转让,将在后续选举中使用(直至取消)。 选民可以也应该按照优先顺序选择一名以上的候选人。 然后,选举算法将所有选票分配给获得最高社区支持的候选人,以确定可获得的议会席位的最优分配。

- + \ No newline at end of file diff --git a/cn/democracy_intro/index.html b/cn/democracy_intro/index.html index 8b43b547..37d06e49 100644 --- a/cn/democracy_intro/index.html +++ b/cn/democracy_intro/index.html @@ -4,13 +4,13 @@ 简介 | HydraDX Docs - +

简介

HydraDX 正在将其治理完全去中心化。所有影响项目发展的决定都是在一个由 Substrate 民主模块支持的民主程序之后通过的。在利益相关者之间建立共识的核心机制是 公投

本节文章包含了一系列知识,可以让您更好地了解 HydraDX 治理背后的机制。您将找到更多关于 公投如何运作 的信息,以及关于治理参与者的两个中心组: HydraDX 议会技术委员会

如果您正在寻找有关如何参与 HydraDX 治理的实用指南,请参阅 参与公投参与议会选举 的分步指南。

民主参数

下面列表包含了影响 HydraDX 治理机制的最重要参数。请注意,这些可能会随着时间的推移而改变。

  • 发起公投的最低 HDX 存款: 10 000 HDX
  • 公投制定周期: 6 天
  • 公投投票期: 3 天
  • 紧急公投投票时间: 3 小时
  • 公投被否决后的冷静期:7 天
  • 最大待决公投提案数: 100
- + \ No newline at end of file diff --git a/cn/democracy_referenda/index.html b/cn/democracy_referenda/index.html index 0c08a8fb..40b4f315 100644 --- a/cn/democracy_referenda/index.html +++ b/cn/democracy_referenda/index.html @@ -4,13 +4,13 @@ 公投 | HydraDX Docs - +

公投

公投允许利益相关者将提案提交给更广泛的社区进行加权、基于权益的投票。公投的对象是一些影响项目发展的建议行动,例如,财政部支出,甚至运行代码的更改。

一般来说,一次只进行一次公投。其他未决的公投提案被放入队列中。公开提交的提案和议会提案有不同的队列。每 3 天,公投机制会选出支持率最高的提案,在两个队列之间交替。在公投通过并被接受后,有一个所谓的 3 天“颁布延迟”期,在此期间,决定生效。这些规则不适用于技术委员会处理重大协议问题并需要快速追踪的紧急提案。

发起公投

有多种方式可以发起公投,下面将进行更详细的描述。公投的发起方式对适用的投票模式具有决定性意义。

公投

HDX 令牌的任何持有者都可以通过存入所需最低数量的 HDX 令牌并在链上 提出公投提案 。其他社区成员可以通过锁定等量的令牌来 支持(拥护)公投提案 。在每一个投票周期的开始,支持(总存入令牌)最高的公投提案,可以被社区优先投票。

适用于公投的投票模式是 正向投票率偏差

note

所有用于提案或拥护投票的 HDX 令牌在公投进入投票周期之前都被锁定。 重要的是要记住,并不能保证任何给定的提案都能得到足够的支持进入投票阶段,这意味着您的资金可能会无限期地被锁定。

议会公投

HydraDX 议会有权提出公投以进行社区投票。如果一致通过,公投适用的投票模式为 负向投票率偏差。如果公投是以议会简单多数票提出的,那么社区接受提案的投票方式为 简单多数

技术委员会的紧急提案

技术委员会可以提交处理(关键)错误修复或快速采用经过实战检验的功能的紧急提案。紧急提案无需排队,直接进入投票环节。社区可以在任何常规提案进入投票环节的同时,对紧急提案进行投票。此外,紧急提案的投票时间较短,以确保它们能够快速追踪。

取消公投

一旦提议进行全民公决,在进入投票环节之前不能撤销。对于那些被认为对协议有害的提案(例如:代码更改引入了 bug),这条规则不适用。在这种有限的情况下,公投提案可以由 HydraDX 议会 (60% 的绝对多数)或 技术委员会 (一致)取消。所有支持该提案的支持者锁定的令牌都将被烧毁。

在公投中投票

HydraDX 公投有 3 天的启动期。在每个新周期开始时,支持次数最多的提案将从等待队列中取出,并进入一轮投票。每一轮投票的持续时间为 3 天。在此期间,社区成员可以使用加权、基于权益的机制对公投进行投票。它们通过在给定时限内锁定一定数量的 HDX 令牌来做到这一点。

note

锁定的 HDX 令牌在选定的锁定期内无法转移。但是,它们仍然可以用于质押和投票。

投票权重

有两个因素决定了公投中每张选票的权重。第一个因素是选民锁定以支持投票的 HDX 令牌数量。第二个因素是所谓的信念系数,它反映了选民愿意锁定令牌的持续时间。

投票权重=令牌*信念系数

投票锁定期与颁布后延迟解锁的时间相同。如果选 1 个锁定期,意味着投票结束后令牌将被锁定 6 天 。选民可通过减少或增加令牌的锁定期,影响投票权重。当然,若使用 0 个锁定期进行投票,投票权重仅为很小的一部分(信念系数为 0.1)。另一方面,锁定期每增加一倍,信念系数将增加 1。如下表所示,锁定期最长达 192 天,信念系数也将会提高至 6。

锁定期信念系数
00.1
61
122
243
484
965
1926
一个例子:

Alice 以 5000 HDX 和 0 个锁定期进行投票。
Bob 用 100 个 HDX 和 192 个锁定期投票。

Alice 权重: 500
Bob 权重: 600

投票模式

民主模块的另一个重要方面,是不同的投票模式。批准或否决公投所需的票数门槛,可能因公投启动方式和投票的投票率而有所差异。投票率是根据在公投中用于投票的 HDX 令牌总量计算的(不包括信念系数)。投票率是否低,取决于投票率与投票者(即有资格投票的 HDX 令牌总量)之间的关系。

正向投票率偏差

这是社区提出公投时默认的投票模式。在投票率较低的情况下,需要获得合格的绝对多数票 yes 才能批准公投。随着投票率的增加,阈值会朝着简单多数的方向降低。

负向投票率偏差

这种投票方式,适用于议会一致提出的公投。此类提案需要获得合格的绝对 no 多数票才能在投票率低的情况下被否决。随着投票率的增加,拒绝公投的门槛降低到简单多数。

简单多数

由议会以多数同意(即非一致同意)发起的公投,可以由社区以简单多数票(50% + 1)接受。

- + \ No newline at end of file diff --git a/cn/democracy_technical_committee/index.html b/cn/democracy_technical_committee/index.html index 750683bc..0a0288a7 100644 --- a/cn/democracy_technical_committee/index.html +++ b/cn/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ 技术委员会 | HydraDX Docs - +

技术委员会

技术委员会由 HydraDX 议会直接任命的、一群经验丰富的核心开发人员组成。其主要任务是维护 HydraDX 协议的技术稳定性。

技术委员会有权 制定紧急公投 ,该公投可与任何其他有效公投同时进行快速跟踪和投票。这使委员会能够迅速采取行动并交付关键(代码)更改。

技术委员会的另一个重要权力,是有能力 取消 被认为对协议有害的 公投提案 。取消公投提案,技术委员会必须一致同意。

- + \ No newline at end of file diff --git a/cn/dev_intro/index.html b/cn/dev_intro/index.html index 68168f96..af16c997 100644 --- a/cn/dev_intro/index.html +++ b/cn/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/cn/great-unlock/index.html b/cn/great-unlock/index.html index 7f25ae4c..832d5fd6 100644 --- a/cn/great-unlock/index.html +++ b/cn/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/cn/howto_bonds_lbp/bonds1.jpg b/cn/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/cn/howto_bonds_lbp/bonds1.jpg and b/cn/howto_bonds_lbp/bonds1.jpg differ diff --git a/cn/howto_bonds_lbp/bonds2.jpg b/cn/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/cn/howto_bonds_lbp/bonds2.jpg and b/cn/howto_bonds_lbp/bonds2.jpg differ diff --git a/cn/howto_bonds_lbp/index.html b/cn/howto_bonds_lbp/index.html index 48bd5b41..02b1cab1 100644 --- a/cn/howto_bonds_lbp/index.html +++ b/cn/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

caution

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
note

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/cn/howto_bridge/index.html b/cn/howto_bridge/index.html index e1f2a082..dc08d082 100644 --- a/cn/howto_bridge/index.html +++ b/cn/howto_bridge/index.html @@ -4,14 +4,14 @@ 桥接资产 | HydraDX Docs - +

桥接资产

在此页面上,您将找到有关使用 Acala 通过 Wormhole(虫洞)实现从以太坊生态系统桥接令牌的分步指南。

Wormhole 的 Portal Bridge(传送桥)允许您在不同链之间桥接令牌。Wormhole 不是直接交换或转换资产,而是将您的源资产锁定在智能合约中,并在目标链上铸造新的 Wormhole 包装资产。然后,您可以在交易所将 Wormhole 包装的资产,交换成目标链上的其他资产。

必备条件

  • Polkadot 钱包(Talisman 或 Polkadot.js 应用程序);
  • 一个以太坊钱包(Metamask);
  • 按照 Acala 绑定指南 将以太坊钱包和您的 Acala 钱包地址绑定。完成这个动作需要少量的 ACA(< 1 ACA)。
caution

请确保您的钱包中有足够的令牌(ETH 和 ACA)来支付费用。请记住,发送和兑换令牌以及绑定您的钱包地址将收取费用。

桥接资产 ETH -> Acala

01 导航到虫洞令牌桥

https://www.portalbridge.com/#/transfer

metadata

02 选择网络并连接您的账户

  • 重新定向到 Token Bridge 页面后,选择您要桥接的链 (1)。在我们的例子中,Ethereum(以太坊) 为源链,Acala 为目标链;
  • 点击 Connect 连接到您桥接的 Metamask 帐户 (2)

03 选择要桥接的资产

  • 连接 Metamask 后,选择您想要桥接的令牌资产 (3) 。如果在下拉列表中没有找到令牌,您可以粘贴令牌合约地址(可以通过 Etherscan 确认);
  • 输入您想要桥接的令牌数量 (4) ;
  • 单击 Next (5)。这时 Metamask 将出现提示,请求将网络从以太坊切换到 Acala。
caution

请注意,目前唯一能够从以太坊桥接到 Acala 的资产是:

  • DAI: 0x6B175474E89094C44Da98b954EedeAC495271d0F(始终仔细检查合约地址)
metadata

04 选择 Gas 支付方式

  • 在网络切换到 Acala 之后,选择 Gas 的支付方式 (6) 。请注意,免费桥接的最小值(在 Acala 一侧)为 ≥10 $DAI;
  • 单击 Next (7) 继续。这时将出现 Metamask 提示,请求将网络从 Acala 切换回以太坊。
metadata

05 桥接令牌

  • 在网络切换回以太坊后,单击 Approve (8) 继续。Metamask 钱包将提示,第一笔令牌转移交易需要批准;
  • 执行此操作后,单击 Transfer (8) (将出现在 Approve 位置)。Metamask 钱包将提示,第二笔交易需要执行以桥接转账。
metadata

Wormhole 处理交易后,单击 Redeem (9)(兑换)。此操作,会让您在 Acala 链上收到令牌。

metadata

至此,您已完成了第一步!

桥接资产 Acala - > ETH

将桥接资产转回 Acala 后使用(跨链转账),可将它们桥接回以太坊生态系统,如下所示:

01 导航到 Wormhole 令牌桥页面

https://www.portalbridge.com/#/transfer

metadata

02 选择网络并连接您的账户

  • 重新定向到 Token Bridge(令牌桥)页面后,选择您要桥接的链 (1) 。此时,Acala 为源链,Ethereum 为目标链
  • 点击 Connect 连接到您桥接的 Metamask 帐户 (2)

03 选择要桥接的资产

  • 连接 Metamask 后,选择您想要桥接的令牌资产 (3)。如果在下拉列表中没有找到令牌,您可以粘贴令牌合约地址(可以通过 Acala Blockscout 确认);
caution

请注意,目前唯一能够从以太坊桥接到 Acala 的资产是:

  • DAI: 0x6B175474E89094C44Da98b954EedeAC495271d0F(始终仔细检查合约地址)
  • 输入您想要桥接的令牌数量 (4)
  • 单击 Next (5)。这时将出现 Metamask 提示,请求将网络从 Acala 切换到 Ethereum。
metadata

04 选择 Gas 支付方式

  • 在网络切换到以太坊后,选择 Gas 的支付方式 (6) 。请注意,手动支付是从 Acala 到 Ethereum 的唯一选择;
  • 单击 Next (7)。这时将出现 Metamask 提示,请求将网络从 Ethereum 切换回 Acala。
metadata

05 桥接令牌

  • 在网络切换回 Acala 后,单击 Approve (8) 继续。Metamask 钱包将会提示您,第一笔交易需要批准以转移令牌;
  • 执行此操作后,单击 Transfer (8)(将出现在 Approve 的位置)。Metamask 钱包将会提示您,第二笔交易需要执行以桥接转账。
metadata

Wormhole 交易处理后,单击 Redeem (9)(兑换)。此操作,会让您在以太坊链上收到令牌。

metadata

恭喜您,您已全部完成!

- + \ No newline at end of file diff --git a/cn/howto_dca/index.html b/cn/howto_dca/index.html index 694acf71..9336c3c4 100644 --- a/cn/howto_dca/index.html +++ b/cn/howto_dca/index.html @@ -4,13 +4,13 @@ 下达 DCA 订单 | HydraDX Docs - +

下达 DCA 订单

在此页面,您将找到 在 HydraDX Omnipool(万能池)中设置 DCA 订单 的分步指南。

正式开始前,请先访问我们的 DCA 产品页面,熟悉 HydraDX 实施的成本平均策略。

步骤 1:导航到 HydraDX DCA 页面

https://app.hydradx.io/dca

步骤 2:连接您的账户

点击 Connect Account(连接账户)(上图中的 1),连接您的钱包至 HydraDX。

步骤 3:设置 DCA 订单

  • 选择您将用于支付交易费用的资产;输入每笔 DCA 交易的订单金额,以及总订单规模 (2)
  • 选择每次 DCA 交易的时间间隔 (3)
  • 选择您希望从交易中获得的资产 (4)
  • 对于想以特定区块间隔下达订单的高级用户,可以点击 Advanced Settings(高级设置)(5) 切换开关来设置;
  • 如果您想调整滑点首选项,可通过单击 设置图标 (6) 来实现;
  • 要完成 DCA 订单,请点击 Schedule DCA trades(实施 DCA 交易)(7),并使用您的钱包应用程序签署交易。

步骤 4:查看您的 DCA 订单

  • 提交后,您的 DCA 订单将出现在 DCA Orders(DCA 订单)下;
  • 要查看详情,请点击 下拉箭头 (8);
  • 您可以通过点击 Terminate(终止)(9),取消剩余金额的 DCA 订单。
- + \ No newline at end of file diff --git a/cn/howto_hydrated_farms/index.html b/cn/howto_hydrated_farms/index.html index de24e284..15523f01 100644 --- a/cn/howto_hydrated_farms/index.html +++ b/cn/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ 加入九头蛇农场 | HydraDX Docs - +

加入九头蛇农场

通过九头蛇农场,除了获得交易费用奖励外,还可通过为选定资产提供流动性获得额外的奖励激励。要了解更多信息,请访问 产品专页

00 导航至流动性页面

https://app.hydradx.io/liquidity

01 提供流动性

资产激励,可通过 Farm rewards(农场奖励)来确定,它显示了该农场的所有可用奖励。

metadata

要加入农场,您须首先提供流动性,具体请参考 分步操作指南

02 加入农场

一旦为激励资产提供了流动性,您就可以加入其农场。

metadata

为此,请点击您提供流动性头寸旁边的 Join farms(加入农场)并用您的钱包签署交易。

九头蛇农耕快乐!

- + \ No newline at end of file diff --git a/cn/howto_lp/index.html b/cn/howto_lp/index.html index 0dbd0513..8baa6088 100644 --- a/cn/howto_lp/index.html +++ b/cn/howto_lp/index.html @@ -4,13 +4,13 @@ 提供流动性 | HydraDX Docs - +

提供流动性

在这一页中,您将在 HydraDX Omnipool(万能池)中找到一个 提供流动性的分步指南。成为流动性提供者,可以让您从池交易中 获得奖励

在决定成为流动性提供者之前,我们鼓励您访问我们的 产品页面,从而 了解熟悉 HydraDX Omnipool 的独特特性。

00 转移令牌

如果您想使用非原生资产(例如 DOT 或 DAI)执行交易,您首先需要把这些资产转移到 HydraDX 链。这一步不适用 HDX。

有两种不同的机制来转移非原生资产:

  • 跨链转账 - 使用此工具,可从其他 Polkadot 平行链或从 Polkadot 自身转移资产。分步指南在 这里
  • 以太坊桥 - 用于连接以太坊生态系统中的资产。分步指南文档在 这里

这些解决方案,也可用于 HydraDX 网络之外的令牌传输。

01 导航至 Omnipool 流动性页面

https://app.hydradx.io/#/liquidity

metadata

02 连接您的账户

点击 Connect Wallet(连接钱包)(上图中的 1 ) 连接到您常用的 Polkadot 钱包。然后,选择您的账户。

03 管理您的流动性

添加流动性

为给定资产添加流动性,点击该资产旁边的 Add Liquidity(添加流动性)(3).

metadata

填写您想提供的流动性数量,点击 Add Liquidity(添加流动性),使用您的钱包签署交易。

移除流动性

metadata

要移除流动性,请切换到相关资产 (1) 旁边的下拉菜单,并在希望退出的位置上,单击 Remove Liquidity (移除流动性)。

metadata

切换或输入您希望提取的流动性数量 (3),点击 Remove Liquidity (移除流动性)并使用您的钱包签署交易。

- + \ No newline at end of file diff --git a/cn/howto_stake/index.html b/cn/howto_stake/index.html index 462cd3d7..f0452411 100644 --- a/cn/howto_stake/index.html +++ b/cn/howto_stake/index.html @@ -4,13 +4,13 @@ 质押 HDX | HydraDX Docs - +

质押 HDX

质押,允许用户质押其 HDX 代币,并赚取随时间推移而分配的奖励。 本页面包含了如何质押 HDX 的分步指南,在开始之前,建议您熟悉 HDX 质押的基础知识

如果您还没有 HDX,可以在我们的 交易页面 上,通过与 Omnipool(万能池) 支持的一系列资产进行交换,来获得一些 HDX。

步骤 0: 导航至 HydraDX 质押页面

https://app.hydradx.io/staking

单击 Connect Account(连接账户),将您的钱包连接到 HydraDX。

步骤 1: 质押您的 HDX

  • 选择并填入您想要质押的 HDX 令牌数量 (3)
  • 点击 Stake(质押)(4) 使用您的钱包应用程序确认并签署交易。
metadata

步骤 2: 保持您的 HDX 质押

  • 您获得奖励的金额,取决于您质押的 HDX,相对整个质押池的大小。
  • 随着时间的推移,分配给您的大部分奖励,将会被解锁。 解锁率由奖励联合曲线决定。
  • 了解更多信息,请查阅 质押产品文档

步骤 3: 提升您的奖励

  • 收集行动积分,以增加奖励并加快奖励解锁的速度。
  • 您可以通过 公投投票 来收集行动积分。 您用于投票的质押 HDX 越多,信念乘数越高,您获得的行动积分就越多。
  • 更多信息可在 质押产品文档 中了解。

步骤 4: 领取您的奖励

  • 查看质押统计数据,观察并规划您自己的质押策略 (5)
  • 想要结束质押,可点击 Claim(领取),领取您解锁的奖励 (8)
metadata
caution

一旦决定领取解锁的质押奖励,您都会失去其余所有还处于锁定状态的奖励,它们将会被重新分配给所有其他质押者。 此外,您过去的行动积分,也将被重置。

例如,如果质押者在获得 75% 的奖励时领取奖励,则剩余的 25% 将被没收。 然后,质押者必须等待相同的时间,才能领取后续批次奖励的 75%。

- + \ No newline at end of file diff --git a/cn/howto_trade/index.html b/cn/howto_trade/index.html index bfa1682a..f4211fc9 100644 --- a/cn/howto_trade/index.html +++ b/cn/howto_trade/index.html @@ -4,13 +4,13 @@ 使用 Omnipool 进行交易 | HydraDX Docs - +

使用 Omnipool 进行交易

本页提供了 分步指南,将 帮您使用 HydraDX Omnipool(万能池)执行您的第一次交易

HydraDX Omniool 是可释放无与伦比的效率的新一代 AMM,您可以在我们的 产品文档 中找到更多信息。

metadata

00 转移令牌

如果您想使用非原生资产(例如 DOT 或 DAI)执行交易,您首先需要将这些资产转移到 HydraDX 链上。此步骤不适用于 HDX。

有两种不同的机制来转移非原生资产:

  • 跨链传输 - 使用此工具,可从其他 Polkadot 平行链或从 Polkadot 自身转移资产。分步指南在 这里
  • 以太坊桥 - 用于连接以太坊生态系统中的资产。分步指南在 这里

这些解决方案,也可用于 HydraDX 网络之外的令牌传输。

01 进入 Omnipool

https://app.hydradx.io/#/trade

02 连接您的账户

点击 Connect Wallet(连接钱包)(上图中的 1 ) 连接到您的首选钱包。然后,选择您的账户。

03 执行交易

HydraDX 的交易界面,可让您直观地执行交易:

  • 选择您打算交易的一对令牌 (2)
  • 输入交易的令牌 (3):您可输入您想要支付的令牌数量(如 5000 DAI),您也可以输入想要接收令牌的数量(如 1000 HDX);
  • 如果您想调整滑点偏好,可点击 设置按钮 (4) 完成;
  • 要完成交易,点击 Swap(互换) (5) 并使用您的钱包签署交易。

保持流动性,而不是干涸!

- + \ No newline at end of file diff --git a/cn/howto_wallet_parity_signer/index.html b/cn/howto_wallet_parity_signer/index.html index 5ee5a140..370e12ff 100644 --- a/cn/howto_wallet_parity_signer/index.html +++ b/cn/howto_wallet_parity_signer/index.html @@ -4,13 +4,13 @@ 使用 Parity Signer | HydraDX Docs - +

使用 Parity Signer

Parity Signer(奇偶校验签名器)是一个移动应用程序,它可以把您的 IOS 或 Android 设备变成 Polkadot、Kusama 和任何其他基于 Substrate 链的专用硬件钱包。它可以让您保持私钥离线,同时仍能使用二维码以一种物理隔离的方式方便地签署交易。

设置 Parity Signer

在您开始之前:请确保安全

开始清理

在安装 Parity Signer 之前,请确保您的手机纯净,如已使用过,请进行出厂设置,且不要安装除 Parity Signer 之外的任何其他应用程序。

不要插入 SIM 卡

如果可能的话,不要打开 WiFi 或者使用安全的 WiFi 连接,最好不要连接其他设备并使用信誉良好的 VPN 提供商来连接、更新设备并安装 Parity signer 应用程序。

使用强密码

为了获得更强的安全性,请为设备和使用设备创建的帐户设置长密码。

设置新账户

不要使用旧的谷歌 ID 或 Apple ID,创建一个专门用于下载更新以及 Parity Signer 的新 ID。对于 Android 设备,最好不要使用 WiFi 或谷歌帐户。我们建议使用一些操作系统加密您的数据,如 Lineage O.S,如果需要电子邮件,请创建一个新邮箱。或者,您也可以在 IOS 上创建新的 Apple ID 和电子邮件。

勿用生物识别

避免使用指纹扫描、面部识别系统或短数字码,因为它们很容易被利用。请改用强密码。

禁用所有信号接收功能

使用飞行模式,并确保手动禁用所有类似的功能。如果您使用的是 IOS 设备,请将其关闭,以及在 WiFi 设置中请求自动加入网络和热点的功能。包括:

  • 定位服务
  • WiFi(如果需要升级或设置,请在更新后立即禁用)
  • 蓝牙

退出所有账户

退出 APP 商店,iCloud 和您加入的任何其他帐户。

更新您的设备

如果您使用 WiFi 更新设备,请记得更新后立即禁用 WiFi,并且仅在安全的环境中使用,最好是通过安全加密的 VPN 通道。更新完成后,忘记 WiFi 网络,以确保您不会自动重新加入。

安装 Parity Signer

从官方应用商店为您的设备(IOS / Android)安装 Parity Signer。确保您正在下载的应用程序,是由 Parity Technologies 发布的。

创建一个新账户

按以下步骤创建新账户。

01 添加种子短语

打开 Parity Signer 应用程序,选择 New seed

metadata

02 备份您的恢复短语

应用程序将显示您的种子短语。把它写下来,放在安全的地方。

metadata

完成这些之后,您就可以开始了!您可以在 Parity Signer 中使用您的手机密码或身份验证方法(指纹/面部识别)。

danger

请确保安全!

任何拥有您种子短语的人,都可以访问您的资金,并且对于窃取您种子短语的人没有追索权。

为保护您的种子短语,可参考以下建议:

  • 不要把您的种子短语做成数字文件保存在任何设备上。
  • 总是选择用纸和笔记录您的种子短语。
  • 把您的种子短语放在安全的地方。
  • 不要向任何人提供您的种子短语,包括客服。

连接到 Polkadot.js/apps

任何时候,您都可以在 polkadot.js 浏览器扩展程序中添加您的 Parity Signer 帐户,以方便您在 polkadot.js 应用程序账户页面 查看余额及签署事务。

在 Polkadot.js 应用程序上

要添加您的帐户,请打开 polkadot.js 浏览器扩展程序,单击 + 并选择 Attach external QR-signer account

metadata

在 Parity Signer 上

  • 打开底部菜单的 Keys 选项卡;
  • 从链旁边的下拉菜单中选择您将使用的网络;
  • 选择您需要的帐户或子帐户;
  • 您会看到一个二维码,您需要用您的设备摄像头扫描。

添加 HydraDX 链

要使用 Parity Signer,首先需要向 Parity Signer 添加新链。如果您只想对 Polkadot 或 Kusama 使用 Parity,可跳过此步,继续更新元数据。要添加一条新链,您需扫描带有该链基本信息的二维码。

01 获取链规格

桌面导航至 https://nova-wallet.github.io/metadata-portal/ ,选择 HydraDX 作为所需的链。然后,点击 Chain Specs

metadata

02 添加规格

在您的 Parity Signer 上,点击 Scanner(扫描器),扫描二维码并点击 Add new chain(添加新链)。

使用 Parity Signer

danger

一定要确保您扫描的二维码,是由可信的验证人签署的。

签署交易

为便于使用,我们建议将其添加到 polkadot.js 扩展中。直到更多的链可以直接使用 Parity Signer,这将是桌面应用程序使用它的最佳方式。

当使用 Parity Signer 签署交易时,polkadot.js 应用程序将显示二维码。

metadata

使用 Parity Signer 扫描二维码,然后点击 Unlock key and sign (解锁键并签署)。

metadata

您的 Parity Signer 现在将显示一个二维码。要完成交易的签署,切换回 polkadot.js 应用程序,然后点击 Scan signature via camera (通过摄像头扫描签署)。

更新元数据

要使用 Parity Signer,您需用最新元数据解码 Parity Signer 中的事务。您可以通过扫描包含此数据的多重部分二维码,来获取元数据,允许 Parity Signer 解码实际交易,并在您签署前正确显示它。这一步,类似于更新分类帐应用程序。

01 获取元数据

桌面导航至 https://nova-wallet.github.io/metadata-portal/ 并选择所需的链。之后,点击 Metadata(元数据)。

metadata

02 更新

在您的 Parity Signer 上,点击 Scanner(扫描器),扫描二维码更新元数据。

- + \ No newline at end of file diff --git a/cn/howto_xcm/index.html b/cn/howto_xcm/index.html index d32da8ac..56ff27c6 100644 --- a/cn/howto_xcm/index.html +++ b/cn/howto_xcm/index.html @@ -4,13 +4,13 @@ 跨链转账 | HydraDX Docs - +

跨链转账

在本页上,您将找到 操作跨链转账的分步指南

跨链转账,允许您将非本地资产从其他 Polkadot 平行链或 Polkadot 本身,转账到 HydraDX 链。

目前,HydraDX 支持以下令牌进行跨链转账:

  • DOT
  • DAI(通过 Acala 虫洞桥)
  • HDX

00 前提条件

在继续之前,请确保您在目标链上有足够数量的令牌来支付费用(ACA 或 DOT)。

01 导航至跨链转账

https://app.hydradx.io/#/cross-chain

metadata

02 连接您的账户

点击 Connect Wallet(连接钱包),连接到您常用的 Polkadot 钱包。之后,选择您的帐户。

03 跨链转账

  • 选择源链和目标链;
  • 选择您打算转账的资产并输入金额;
  • 输入目的地址。它应该会自动填充您的链上地址,您也可以改为另一个地址;
  • 点击 Transfer(转账),用您的钱包签署交易。
- + \ No newline at end of file diff --git a/cn/identity/index.html b/cn/identity/index.html index 8d1fbcf7..02fc3e0a 100644 --- a/cn/identity/index.html +++ b/cn/identity/index.html @@ -4,7 +4,7 @@ 设置您的身份 | HydraDX Docs - + @@ -13,7 +13,7 @@ https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

在帐户页面,找到持有您 HDX 令牌的帐户。然后,点击帐号旁边的三个点(在右侧),并选择 Set on-chain identity (设置链上身份)。

authorize

您将看到一个名为 register identity(注册身份)的弹窗。在这里,您可以输入以下信息:

  • legal name(法定名称);
  • email(邮件);
  • web(网络);
  • twitter(推特);
  • riot name(roit 姓名)(如果使用 Matrix 信息)。
note

所有这些信息都是可选的,您可以有选择地提供。但是,如果您正在运行整理器节点,建议您设置电子邮件,以便在您的节点遇到问题时,方便和您联系。

在弹出窗口的最后一个字段,你可以看到需存入的 HDX 数量,作为存储您身份信息的保证金。以后,一旦决定清除身份信息,您会收回这笔保证金。

authorize

填写完信息后,单击 Set Identity(设置身份),并使用 Polkadot.js 浏览器扩展程序对交易进行签名。一旦确认了交易,您的身份就设置好了。

02 提交身份证明

在您设置好身份后,您可以将它提交给网络注册商进行认证。要做到这一点,请打开 Polkadot/apps 并导航到 Developer(开发者)> Extrinsics(交易)。或者,直接点击这个链接: https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

在上一步选择相应 HydraDX 帐户后,您需要填写以下信息:

  • submit the following extrinsic(提交下面的外部信息): 左边选 identity(身份);中间选 requestJudgement(reg_index, max_fee)(请求判定)。
  • regindex(注册商 ID): 在这里需要输入您选择的注册商 ID 进行验证。 HydraDX 有两个注册商:Simon Kraus - HydraSik(ID: 0)、Jimmy Tudeski - stakenode (ID: 1
  • maxFee(最大费用):在这里需要输入您愿意用 HDX 支付给注册商的最高费用。费用只有低于您支付最高费用的注册商,才有资格为您认证。

若要提交认证请求,请单击 Submit Transaction(提交交易)并签署交易。

authorize

请注意,身份认证可能需要一些时间。要查看您的请求状态,导航到 My accounts(我的账户)并将鼠标停在显示您身份的部分,您将看到一个显示当前状态的弹出框。

03 认证结果

在处理您的认证请求后,注册商将提交以下其中一项判断,该判断将在您的身份状态中显示:

  • Unknown - 默认值,尚未开始;
  • Reasonable - 提供的资料看起来合理,但还没进行深入检查;
  • KnownGood - 信息正确;
  • OutOfDate - 信息过去是正确的,现在已过时;
  • LowQuality - 信息不准确,但可通过修改进行更正;
  • Erroneous - 提供信息错误,可能存在恶意意图。
- + \ No newline at end of file diff --git a/cn/index.html b/cn/index.html index f6248745..d47e5149 100644 --- a/cn/index.html +++ b/cn/index.html @@ -4,13 +4,13 @@ 遇见 Omnipool | HydraDX Docs - +

遇见 Omnipool

HydraDX 是 旨在为 Polkadot 带来流动性海洋 的下一代 DeFi 协议。我们的工作工具,是 HydraDX Omnipool(万能池)- 一种创新的自动做市商(AMM)模型,通过 将所有资产合并在一个交易池中释放无与伦比的资金效率

通过 终结流动性的碎片化,HydraDX Omnipool 让交易变得更加高效,这是其他 AMM 无法比拟的。得益于 更低滑点和更少的跃点,与流动性分散在不同交易池中的典型情况相比,交易者可享受到更高的资本效益(随着 TVL 进一步增加)(了解更多)。

HydraDX Omnipool 的设计,支持 单边流动性提供 - 任何人都可只为他们喜欢的资产提供流动性,而其余部分将由 Omnipool 负责提供(了解更多)。在引导成长的早期阶段,为选定资产提供流动性,将获到 九头蛇农场 激励 - 随着时间推移,会从交易费用中获得更多奖励(了解更多)。

单边提供流动性,对于 DAO 和其他项目的财政 来说,是一个特别有诱惑的概念,他们可通过 XCM 无需信任地向 Omnipool 提供资产,并立即融入到资产海洋中。 他们还可以 通过交易费用建立多样化的 POL,且没有做市商的隐藏费用(了解更多)。

HydraDX Omnipool 具有 最先进的安全性:底层代码已经过 多次审计,且有一个 慷慨的漏洞赏金计划,鼓励 负责任地披露漏洞。除此之外,流动性上限、协议费用和熔断机制等尖端机制的组合运用,可以共同确保您提供流动性的安全(了解更多)。

经过 两年多研发,HydraDX 找到了解决 AMM 另一个痛点 - 无常损失(IL) 的方法。由于 结合了非通胀措施,流动性提供者在向 Omnipool 提供流动性时,将会经受 更少的 IL了解更多)。

保持流动性,而不是干涸。

- + \ No newline at end of file diff --git a/cn/lbp/index.html b/cn/lbp/index.html index c992b09d..aca8a1a7 100644 --- a/cn/lbp/index.html +++ b/cn/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

danger

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/cn/learn_amm/index.html b/cn/learn_amm/index.html index 2917d214..673e85f5 100644 --- a/cn/learn_amm/index.html +++ b/cn/learn_amm/index.html @@ -4,13 +4,13 @@ 什么是 AMM | HydraDX Docs - +

什么是 AMM

本文介绍了自动做市商(AMM)及其一些基本概念,例如 滑点流动性供应无常损失

这些介绍性信息,将帮助您更好了解 HydraDX Omnipool(万能池)背后的机制,您可在我们的 产品文档 中找到相关描述。

AMM 简介

为了解释自动做市商(AMM)及其工作原理,我们可以将其与中心化订单薄进行对比。

订单薄

订单簿提供了一种由中心化交易所(CEX)部署的机制,用以促进两种资产间的交易。 用户可在交易所管理的电子清单中下买入或卖出订单。 这个所谓订单簿中的订单,是按价格水平组织的,并随需求变化和订单匹配逐步填写。

在中心化背景下,订单簿的局限性显而易见。

中央机构“保存”着订单簿,并推动订单匹配进程,这就产生了对中央机构的依赖。 中央机构控制着交易,需要得到参与者的信任。 在交易量大、波动大的时候,中央机构可以决定暂停交易并停止其履行做市的职能。 此外,如果项目方想添加新的可交易资产,须在得到中央机构许可并提前支付费用后,才可让其资产上市交易。

AMM

自动做市商(AMM),是 DeFi 行业对订单簿的革新。AMM 提供了一种去中心化、无需许可的令牌交易方式,更无需屈服于中央机构的控制。

AMM 由持有基础可交易资产可用流动性的流动性池组成。 这种流动性是由用户(所谓“流动性提供者”)提供的,他们这样做的动机是,有可能从池中交易产生的费用中获得奖励。

在 AMM 的情况下,任何用户都可以在给定的交易池中执行买入或卖出订单。 交易价格,由确定性算法当场确定。该算法,将交易资产的流动性,与依赖于特定 AMM 实现的其他因素之间的关系,作为输入变量。

滑点

执行交易时,用户可能会遇到 AMM 的常见副作用,即 滑点:交易预期价格与交易实际执行价格间的差额。

滑点,由交易池中可用的流动性高低决定。 如果为资产提供的流动性较低,则在处理大订单交易时的滑点百分比就会更高。

提供流动性

由于 AMM 的去中心化属性,任何人都可以通过存入一定价值的令牌,来换取代表其流动性的仓位,从而成为流动性池的流动性提供者(LP)。

流动性提供者提供这种流动性的报酬,来源于其所提供流动性的资产经历的交易活动。

无常损失(IL)

无常损失(IL)是流动性提供者面临的一种风险,它体现了在 AMM 中持有令牌与在钱包中持有令牌之间的价值差异。

流动性池,由多个令牌(通常是两个)汇集而成。 当池内令牌价格(与存入时价格)出现差异时,IL 就会发生。 差异越大,流动性提供者的负回报风险就越大。

这种风险被称为“无常”,因为只有当流动性从池中撤出时,损失才会产生。 如果池中令牌的相对价格恢复到(令牌存入时)的原始状态,损失将被最小化或消除。 在流动性撤出的那一刻,损失将成为 永久性的,从而造成收益减少。

因此,流动性提供者需要权衡这两种行为的收益差异:将令牌用于提供流动性赚取费用和奖励,还是简单地放在钱包中。然后,做出自己的选择。

- + \ No newline at end of file diff --git a/cn/node_monitoring/index.html b/cn/node_monitoring/index.html index 42e75bfd..2b0c485f 100644 --- a/cn/node_monitoring/index.html +++ b/cn/node_monitoring/index.html @@ -4,7 +4,7 @@ 节点监控 | HydraDX Docs - + @@ -28,7 +28,7 @@ 设置 http://localhost:9090/,然后单击 Save and Test

导入仪表盘

请单击主导航中的 Plus 按钮,然后选择 import

我们将使用 HydraDX Dashboard(仪表盘) 进行加载,您只需输入id 14158 并点击 Load 按钮即可加载它:

您在这里不需要太多配置,只需确保将 Prometheus 用作数据源即可。 您现在可以完成导入:

现在,您应该立即看到仪表盘。
如果某些面板是空的,请确保您在面板上方的选择是这样的:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/cn/omnipool_dca/index.html b/cn/omnipool_dca/index.html index e49c7064..a6915380 100644 --- a/cn/omnipool_dca/index.html +++ b/cn/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA 交易 | HydraDX Docs - +

DCA 交易

HydraDX DCA拆分交易 (简易 DCA) ,是两个用户友好型功能,允许交易者在 Omnipool 中进行交易时,以无需许可和非托管的方式,实施美元成本平均(DCA)策略。

按照 DCA 策略,订单不是一次下达,而是分成较小的交易后定期执行。通过这样做,交易员可以保护自己免受价格波动的影响,并获得平均价格。此外,将大订单分成较小的块,滑点会减少。

HydraDX DCA 有两种实现方式 - 完整功能 DCA拆分交易(简易 DCA),您可在主交易页面上找到它们。 往下,您可以了解这些功能的更多有关信息。

如果您正在寻找分步指南,请查看 下达 DCA 订单指南

HydraDX DCA

HydraDX DCA 提供了直观的 UI,用户可以在 Omnipool 中微调 DCA 订单。

在设置订单时,用户可以指定他们想花费的资产 A 数量,以获得资产 B,以及交易频率 - 以小时(近似值)或区块(更精细)为单位。

下达订单后,HydraDX DCA 托盘,确定会按照指定的时间间隔安排交易,直到预设数量的资产 A 被花完。支持下达多个并列执行的 DCA 订单。

用户可在 UI 上跟踪订单状态。未平仓的订单,可随时终止剩余的金额。

拆分交易 (简易 DCA)

拆分交易 是在交易页面上更加直接简单地实现 DCA。它为用户提供了“一键”解决方案,用于拆分较大的订单,以保护自己免受滑点影响。

激活后,拆分交易会将订单分割成更小的块,直到交易规模小到可以实现 <0.1% 的滑点(这仅是估计 - 未来确切的交易滑点,永远无法预测)。

用户可以随时终止执行中的拆分交易订单,就像常规的 DCA 订单一样。

- + \ No newline at end of file diff --git a/cn/omnipool_design/index.html b/cn/omnipool_design/index.html index 0b9bf25c..cb45d6e5 100644 --- a/cn/omnipool_design/index.html +++ b/cn/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool 设计 | HydraDX Docs - + @@ -23,7 +23,7 @@ s-225.272,467,-225.272,467s-235,486,-235,486c-2.7,4.7,-9,7,-19,7 c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

单一资产 LP 仅对 TKN/LRNA 价格敏感,对 Omnipool 中其他令牌的价格不敏感(间接通过 LRNA 除外)。

- + \ No newline at end of file diff --git a/cn/omnipool_hydrated_farms/index.html b/cn/omnipool_hydrated_farms/index.html index 54d104c2..057d8e49 100644 --- a/cn/omnipool_hydrated_farms/index.html +++ b/cn/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ 九头蛇农场 | HydraDX Docs - +

九头蛇农场

九头蛇农场是一种有时间限制的激励计划,除了交易费奖励外,还为特定资产提供流动性,提供了额外奖励。

与传统流动性挖矿项目不同,九头蛇农场有几个独特的功能:使用 农场 NFT 代表农场位置,支持 奖励叠加 ,并且基于 忠诚度系数 的奖励,会随时间推移而增长。

在本页,您可以找到更多关于九头蛇农场的细节。如果想参与,请访问我们的 九头蛇农场分步指南

农场 NFT

当用户向 Omnipool(万能池)提供流动性并加入一个九头蛇农场时,HydraDX 协议将为其生成一个特有的 NFT。该 NFT 代表了用户在农场中的位置,并存储了某些详细信息,如:进入的时间。这使得协议能够提供可持续的激励,且奖励会随着时间推移而增长。

农场 NFT 所有者,控制着农场中的头寸,以及 Omnipool 的基础流动性。 未来,协议的利益相关方,可能会决定开放农场 NFT 市场,或将其用作抵押品。

note

由于农场 NFT 的独特属性,多次加入特定农场,将产生多个 NFT。

奖励叠加

九头蛇农场支持提供多种资产奖励的可能性。换句话说,奖励是可以叠加的。

任何团队都可以联系 HydraDX 的利益相关者,请求创建一个由自己 TKN 激励的九头蛇农场。 按照此例,HydraDX 通过治理还可以决定,提供 HDX 作为该农场的激励措施。 因此,九头蛇的农场主们,将同时获得 HDX 和 TKN 奖励。

忠诚度系数

为了鼓励更可持续的流动性供应,九头蛇农场引入了忠诚度系数 - 随着流动性持续留在农场,奖励会随时间推移而增长。您可在农场详情页面,查看具体的奖励分配曲线。

一旦用户决定离开农场,他们的忠诚度系数就会重置。如果重新加入,忠诚度系数将从基础级别重新开始。

- + \ No newline at end of file diff --git a/cn/omnipool_impermanent_loss/index.html b/cn/omnipool_impermanent_loss/index.html index b66a1a1f..5b504a4d 100644 --- a/cn/omnipool_impermanent_loss/index.html +++ b/cn/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ 减少无常损失 | HydraDX Docs - + - + \ No newline at end of file diff --git a/cn/omnipool_lp/index.html b/cn/omnipool_lp/index.html index a789fab0..d234dfec 100644 --- a/cn/omnipool_lp/index.html +++ b/cn/omnipool_lp/index.html @@ -4,13 +4,13 @@ 单边提供流动性 | HydraDX Docs - +

单边提供流动性

HydraDX Omnipool(万能池)的尖端设计提供了单边流动性供应的可能性:任何人都可以只为他们想要的资产提供流动性,而且数量不限(不超过 Omnipool 设定的资产 TVL 上限)。 这根除了标准 XYK AMM 的一个主要痛点:流动性提供者(LP)必须存入一对等价值的资产。

HydraDX Omnipool 的流动性是集中的,这意味着通过提供资产,您可以获得在 Omnipool 中所有其他资产面前即时曝光的机会。请忘掉流动性碎片化和将流动性分散到多个交易池的需求吧!

枢纽令牌 LRNA

我们的枢纽令牌 Lerna(LRNA)让提供单边流动性成为可能。 每次增加流动性时,Omnipool 都会铸造相应数量的 LRNA 以保持池的平衡。同理,LRNA 销毁,将被用于反映任何流动性的去除。 这些机制确保了在 Omnipool 中添加或移除资产时,LRNA 的价值不会出现明显波动。

login

理解枢纽令牌概念的另一种方法是,将 Omnipool 中的每项资产,想象成为一个合成的 50/50 流动性资产对池。唯一的区别,是该资产对的“第二条腿”,始终是 LRNA,即 TKN:LRNA。

这种设计允许协议以 LRNA 为代理,以抽象的方式反映 Omnipool 中锁定的价值,包括交易活动和价格波动。

- + \ No newline at end of file diff --git a/cn/omnipool_security/index.html b/cn/omnipool_security/index.html index ae894389..81b0339a 100644 --- a/cn/omnipool_security/index.html +++ b/cn/omnipool_security/index.html @@ -4,13 +4,13 @@ 最先进的安全性 | HydraDX Docs - +

最先进的安全性

HydraDX 协议采用多层安全策略,该策略专为确保您的资金安全量身定制。HydraDX Omnipool(万能池)背后的概念,以及它们在 Rust 中的运行时实现,都经过了 严格的审计。我们防御策略的第二层,是慷慨的漏洞赏金计划,奖励负责任的漏洞披露。 最后,还有一系列措施共同来 保护您的流动性(抵御有毒资产或黑客攻击等不幸事件)。

审计

对 HydraDX Omnipool 的 Rust 实现安全审计,是由 Runtime Verification 执行的。 Runtime Verification 是知名的行业领导者,客户包括 NASA、Ethereum 和 Polkadot。安全审计的范围包括 HydraDX Omnipool pallet 源代码,及其 数学逻辑资产注册表,以及作为(Substrate)依赖项包含的第三方库。 审计结果于 2022 年 9 月公布,您可以在 此处 查阅完整报告。

2022 年 3 月,Omnipool 的经济/数学审计由 BlockScience 完成。 BlockScience 是一家领先的 web3 原生公司,致力于为 Graph Protocol 和 Protocol Labs(Filecoin)等分析复杂系统。本次审计的范围是概述 AMM 规范,特别关注支撑 Omnipool 的数学和经济概念,以及这些机制对流动性供应和交易活动的影响。 您可以在 此处 查阅完整报告,包括我们事后整改的附录。

漏洞赏金计划

HydraDX 正在与区块链安全领域的另一行业领导者 Immunefi 合作, 建立一个全面的激励系统,奖励负责任的漏洞和潜在漏洞披露行为。

基于 Immunefi 漏洞严重程度分级系统 V2.2,根据漏洞的影响进行奖励分配。这是一个简化的 5 级量表,网站/apps、智能合约和区块链/分布式账本技术具有单独的量表,重点关注所报告漏洞的影响。

我们正处在设置漏洞赏金计划的最后阶段,很快就会有更多信息。

Omnipool 流动性保护机制

我们花了一年多的时间研究和设计机制,这些机制将在以下不幸情况下(并非不可能)被激活:参与者试图通过滥用有害资产(类似 LUNA 的情况)或一些恶意利用,来耗尽 Omnipool 的流动性。 我们提出了一系列措施并进行整合,建立了行业领先的安全标准。

其中一项措施,是 TVL 上限(又名 Omnipool 权重),它定义了为特定资产提供流动性相对于池中其他所有资产的最大比例。 TVL 上限,将依据 HydraDX 民主决策流程对每项资产进行设置。 与新项目令牌相比,为 DOT 或 DAI 等已上市资产设置更高的上限,是合理的。 这将限制潜在的流动性攻击可能会造成的损害。

另一种防御机制,是 目标函数暂停。通过这一机制,HydraDX 技术委员会可暂停调用我们 pallet 特定函数的交易,以便我们能够做出快速反应(如暂停提款)从而保护 Omnipool 的流动性。

以上这些,只是我们已经实施的一些机制。 作为未来迭代的一部分,我们正在研究和开发其他的机制,例如可靠的预言机、动态费用(在累积 POL 的同时,降低砸盘的经济效益)、自动交易节流和其它熔断机制的使用。

- + \ No newline at end of file diff --git a/cn/omnipool_trading/index.html b/cn/omnipool_trading/index.html index bb9089a7..6ce40124 100644 --- a/cn/omnipool_trading/index.html +++ b/cn/omnipool_trading/index.html @@ -4,13 +4,13 @@ 高效交易 | HydraDX Docs - +

高效交易

传统 DeFi 系统的特点是流动性分散化,即:流动性分散在多个交易池中。这个系统跃点较多,流动性较浅,导致价格影响变大滑点升高、经济效率低下。HydraDX Omnipool(万能池)通过将所有流动性合并到一个交易池中,实现了其它 AMM 无法比拟的高效率交易。

传统 AMM:流动性碎片化

先驱 XYK AMM 的出现,标志着 DeFi 领域一个关键时刻的到来,因为它让去中心化和无需许可交易成为了可能。 简单的 XYK 池,对 DeFi 初期的广泛采用,起到了促进作用。但时值今日,我们不得不面临这样一个局面: XYK 模型低下的经济效率,已经阻碍了 DeFi 应用的进一步发展。

Omnipool

XYK 模型的缺陷之一,是交易池只能由成对的资产构成。 流动性碎片化,导致更大的价格影响和更高的跃点和滑点。 上面截图 ETH-AAVE 的交易路线,为我们提供了一个生动的例子:

  • 85% 的交易,将 ETH 直接交换成 AAVE(产生 0.3% 的费用);
  • 余下的 15% 交易,则要先将 ETH 交换成 UNI,然后再将 UNI 交换为 AAVE(在两个交易池里分别产生了 0.3% 的交易费用)。

HydraDX Omnipool:统一流动性

得益于 Omnipool 的尖端设计,流动性才真正发挥出它应有的作用。 通过 LRNA 连接所有流动性,Omnipool 的任一资产,可直接访问池中所有资产统一形成的全部流动性,且与链上执行无缝衔接,交换在一次交易中完成,无需在彼此独立的交易池中间进行任何跳转。

此外,根据内在研究,随着 Omnipool 令牌数量和锁定价值(TVL)的不断增加,对于滑点的减少将呈指数级改善。

login

举个例子(如上图),假设资产 TKN 分布在 4 个不同的流动池中,4 池流动性水平各不相同。 交易者如果想用(少量的)DAI 交换 TKN,他们可选择拥有 100 万美元流动性的 TKN-DAI 池。 但如果交易规模加大,如 10 万美元以上,大部分的交易,可能要先通过 DAI-ETH 池,然后是传统 XYK 环境的 TKN-ETH 池来完成。

然而,对于 HydraDX Omnipool,同样的 500 万美元 TKN 资产(1000 万美元 TVL 的 50%)和 300 万美元 DAI,将会集中到一个池子里。 如果交易者在 Omnipool 中执行以上相同的交易,他们将享受由 500 万美元 TKN 和 300 万美元 DAI 所形成的全部流动性效益,并在一次交换中完成交易,整体上的价格影响将大大降低。

- + \ No newline at end of file diff --git a/cn/omnipool_treasuries/index.html b/cn/omnipool_treasuries/index.html index 8e4eb70c..f45baec3 100644 --- a/cn/omnipool_treasuries/index.html +++ b/cn/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ 让您的财政苏醒(B2B) | HydraDX Docs - +

让您的财政苏醒(B2B)

HydraDX Omnipool(万能池)对任何项目或 DAO 的财政,都有明确的价值主张。 忘掉中心化做市商和流动性挖矿的通膨奖励吧!Omnipool 可以用更经济高效的方式,为您的令牌创建市场 - 无需信任,没有隐藏成本,同时通过交易费用建立您的 POL。

得益于其尖端的设计,HydraDX Omnipool 支持 单边提供流动性。 与其浪费地分配流动性挖矿奖励来激励其他用户提供流动性,项目和 DAO 可以将部分资金存入 Omnipool,并获得 在流动性海洋中所有其他资产面前 的即时曝光机会:多样化和深度(HydraDX 有 2000 万美元 POL 正在逐步部署)。

HydraDX Omnipool 的流动性提供,是 真正地无需许可 的。利用 Polkadot 独特的 跨链通信(XCM) 功能,Omnipool 使您能够始终控制自己的资金:您既可以提供流动性,也可以在不依赖第三方的情况下进行资金管理。

为 HydraDX Omnipool 提供流动性,不仅具有成本效益,而且还 有利可图。与其让您的令牌闲置在财政中,不如让它们发挥作用。 您将会 从交易费中获得奖励,还可随时间推移 建立 POL。很快,我们会推出 TWAMM/DCA 功能,将允许您 把累积的 POL 分散 到其他资产中(例如,美元稳定币或 DOT,您可用它来竞标下一个平行链插槽)。

最后,HydraDX Omnipool 享有最先进的安全性。 除了严格的审计和慷慨的漏洞赏金计划外,我们还制定了一系列措施,共同确保您的流动性安全。 点击 这里 了解更多。

- + \ No newline at end of file diff --git a/cn/participate_in_council_elections/index.html b/cn/participate_in_council_elections/index.html index 84e6eed8..9e60ba65 100644 --- a/cn/participate_in_council_elections/index.html +++ b/cn/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ 参与议会选举 | HydraDX Docs - +

参与议会选举

本文提供了关于如何参与议会选举的分步指导: 为议会成员投票和成为议会候选人。

如果您对选举如何进行感兴趣,请阅读 此文章

caution

HydraDX民主选举将在 2021 年 9 月 15 号 后上线,请勿在此日期前尝试任何显示的操作。

使用 Polkadot/apps

在议会成员选举中投票

您将在 Governance(治理)> Council(议会)页面 中看到现有议员及候选者。

要为议会成员投票,请单击 Vote(投票)。

输入您愿意锁定以支持候选人的令牌数量。

之后,通过将候选人从左侧列表移到右侧列表,按偏好顺序选择您的候选人。 记住选择多个候选人 - 这将有助于算法选择最佳候选人分配给议会。

要投票,请单击 Vote(投票)并签署交易。

note

锁定的令牌不可转账,但仍可用于质押和公投投票。直到你手动解锁令牌之前,您的令牌将被锁定并用于下次的选举。

申请成为议会候选人

您可以通过导航到 Polkadot/apps 中的 Governance(治理)> Council(议会) 来提交您的议会成员申请。

单击 Submit candidacy(提交候选资格),这将触发一个弹出窗口。

选择正在运行的议会成员账户,点击 Submit(提交)并签署交易。

- + \ No newline at end of file diff --git a/cn/participate_in_referenda/index.html b/cn/participate_in_referenda/index.html index 8f2ba8e7..cb588bc6 100644 --- a/cn/participate_in_referenda/index.html +++ b/cn/participate_in_referenda/index.html @@ -4,13 +4,13 @@ 参加公投 | HydraDX Docs - +

参加公投

这篇文章提供了关于如何参与公投的分步指南:投票和提案。为此,您可以选择使用两种工具:Commonwealth.imPolkadot/apps

在您决定参与之前,我们强烈建议您通读“学习/民主”部分中的 知识文章 。在那里你会找到一些关于公投背后机制的重要细节。

caution

HydraDX 民主模块将于 2021 年 9 月 15 日 或之后推出。请不要在该日期之前尝试任何显示的操作。

使用 Commonwealth.im

在公投中投票

您可以通过导航到 HydraDX Commonwealth 页面上的 公投选项卡 来查看所有可供投票的公投。

要对正在进行的公投进行投票,您需要单击它。之后,您将看到一个显示所有相关详细信息的页面。

Cast Your Vote (投您的票)部分,填写以下信息:

  • Amount to vote (投票数量)- 这是您愿意锁定以支持公投的 HDX 令牌数量
  • Conviction multiplier (信念系数)- 这是共同决定您 投票权重 的系数。

之后,通过单击 Vote yes(投票是)或 Vote no(投票否)并签署交易进行投票。

提出公投提案

要提出公投,请访问 HydraDX Commonwealth 页面,然后单击顶部菜单中的 New Thread(新帖子)> New democracy proposal(民主新提案)。

在上面显示的字段中填写信息。最重要的参数是:

  • Module(模块)
  • Function(功能)
  • 您提议调用的函数指定的任何附加信息
  • Deposit(存款)- 您愿意为支持该提案而存入的 HDX 令牌数量

在上面的例子中,Module(模块)是 余额,而 Function(功能)是 设置余额,用于修改一个给定帐户的自由和储备余额。

要提交提案,请单击 Send transaction(发送交易)并使用您的钱包签名。

在链上提交提案并签署交易后,您的提案应出现在 提议公投列表 中。

caution

每个投票期间,获得最高支持(附议 )的公投提案进入投票轮次。随着公投数量的增加,无法保证您的提案将获得足够的支持以进入投票。无法撤回公投提案,这意味着您的资金可能会被长期锁定。

恶意公投提案受到惩罚。HydraDX 议会和技术委员会有权取消任何恶意提出的公投。结果是存入的令牌将被烧毁。

使用 Polkadot/apps

在公投中投票

您可以通过导航到 Polkadot/apps 中的 Governance(治理)> Democracy(民主) 来查看所有公开投票的公投。

要在公投中投票,请单击旁边的 Vote(投票)按钮。

在弹出窗口中,填写以下信息:

  • Vote value(投票值) - 这是您愿意锁定以支持公投的 HDX 令牌数量
  • Conviction multiplier(信念系数) - 这是共同决定您 投票权重 的系数

之后,通过单击 Vote Nay(否) 或 Vote Aye(是)来投票并签署交易。

提出公投

通过 Polkadot/apps 提出公投包括两个步骤:提交原像,以及在链上提交提案。

01 提交原像

要提交原像,请访问 Polkadot/apps 并导航至 Governance(治理) > Democracy(民主)

单击 Submit preimage(提交原像)后,您应该会看到以下弹出窗口:

在上面显示的字段中填写信息。最重要的参数是:

  • 发送提案的帐户
  • 提案范围
  • 提案操作

在上面的例子中,提案范围是 余额 ,操作是将令牌从一个帐户 强制转移 到另一个帐户。

在提交原像并签署交易之前,请确保复制原像哈希以在下一步使用它。

02 提交提案

要提交公投提案,请访问 Polkadot/apps 中的 Governance(治理)> Democracy(民主)

单击 Submit proposal(提交提案)后,您应该会看到以下弹出窗口:

输入上一步中的原像哈希值,以及您愿意为提案存入的令牌数量。最低为 10,000 HDX。

在链上提交提案并签署交易后,您的提案应出现在提议的公投列表中。

caution

每个投票期间,获得最高支持(附议 )的公投提案进入投票轮次。随着公投数量的增加,无法保证您的提案将获得足够的支持以进入投票。无法撤回公投提案,这意味着您的资金可能会被长期锁定。

恶意公投提案受到惩罚。HydraDX 议会和技术委员会有权取消任何恶意提出的公投。结果是存入的令牌将被烧毁。

- + \ No newline at end of file diff --git a/cn/performance_benchmark/index.html b/cn/performance_benchmark/index.html index 5a2a2bec..4fdc0c22 100644 --- a/cn/performance_benchmark/index.html +++ b/cn/performance_benchmark/index.html @@ -4,13 +4,13 @@ 基本性能测试 | HydraDX Docs - +

基本性能测试

您可以通过运行测试程序来确定自己的计算机是否符合 基本性能要求 。 请运行一下代码:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Prepare for running the benchmark
## Install Rust following https://rustup.rs
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

## Configure Rust
$ ./scripts/init.sh
$ rustup default nightly

## Install additional libraries
$ apt install python3-pip
$ apt install clang

# Run the benchmark
$ ./scripts/check_performance.sh

在测试程序运行完毕后,您可以看到与以下类似的输出结果:

         Pallet          |   Time comparison (µs)    |  diff* (µs)   |   diff* (%)    |            |   Rerun
amm | 773.00 vs 680.00 | 93.00 | 12.03 | OK |
exchange | 804.00 vs 720.00 | 84.00 | 10.44 | OK |
transaction_multi_payment| 218.00 vs 198.00 | 20.00 | 9.17 | OK |

Notes:
- in the diff fields you can see the difference between the reference benchmark time and the benchmark time of your machine
- if diff is positive for all three pallets, your machine covers the minimum requirements for running a HydraDX node
- if diff deviates by -10% or more for some of the pallets, your machine might not be suitable to run a node

您可以在 diff* (%) 列中看到您的计算机绩效参数与启动节点所需最低要求之间的差异。 如果此列的三个数值均为正数,则表示您的计算机可以正常运行 HydraDX 验证节点。 三个数值,如果任何一个数值低于 -10% ,则不建议使用该机运行 HydraDX 节点。

如果您想讨论基本性能测试结果,请加入我们的 Discord ,社区很乐意提供您!

(如发现翻译错误,请电报联系 @PDMCnode)

- + \ No newline at end of file diff --git a/cn/polkadotjs_apps_local/index.html b/cn/polkadotjs_apps_local/index.html index da888ce5..8e7a40ea 100644 --- a/cn/polkadotjs_apps_local/index.html +++ b/cn/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ 连接到本地节点 | HydraDX Docs - +

连接到本地节点

您可以使用 Polkadot/apps 连接到 HydraDX 本地节点。为此,需要访问用于 RPC Websocket 连接的 9944 端口。

danger

如果您是运行验证节点的验证人,我们强烈建议您将 9944 端口列入黑名单,以禁止第三方进行远程连接。第三方可能会滥用此端口,从而降低您的节点性能,并可能导致严厉惩罚或资金的非自愿损失。仅当您的验证节点处于本地网络时,才可使用 9944 端口连接。

使用 Polkadot/apps 连接本地节点

请打开 Polkadot/apps ,单击左上角来更改网络去访问您的节点:

打开菜单后,单击 DEVELOPMENT (开发),然后选择 Local Node (本地节点):

如有必要,请调整IP后,单击 Switch(转换)以切换到您的本地节点:

至此,您应该已连接到您的本地节点,并能够进行交互。

- + \ No newline at end of file diff --git a/cn/polkadotjs_apps_public/index.html b/cn/polkadotjs_apps_public/index.html index 8a393500..aa5f0b62 100644 --- a/cn/polkadotjs_apps_public/index.html +++ b/cn/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ 连接到公共节点 | HydraDX Docs - +

连接到公共节点

HydraDX 和我们的合作伙伴运营着两个公共 RPC 节点。使用这些节点,您可以与 Snakenet(蛇网) 进行交互。您可以通过单击以下链接,直接使用 Polkadot/apps 连接到公共节点:

手动连接到一个 RPC 节点

手动访问公共 RPC 节点,请打开 Polkadot/apps ,然后单击左上角来更改网络:

单击 LIVE NETWORKS(现行网络),然后选择 HydraDX

选择其中一个 RPC 节点,单击 Switch(转换):

至此,您应该已经连接到选定的公共 RPC 节点。

- + \ No newline at end of file diff --git a/cn/spending_fw/index.html b/cn/spending_fw/index.html index 1c280be3..0ab5fe2e 100644 --- a/cn/spending_fw/index.html +++ b/cn/spending_fw/index.html @@ -4,13 +4,13 @@ 为 HydraDX 做贡献 | HydraDX Docs - +

奖励为 HydraDX 做出的贡献

HydraDX 欢迎大家参与社区共建。每个人都可以通过做贡献,获得 HydraDX 财政奖励。

本文列出了社区贡献奖励支付的总体框架。该框架已获 HydraDX 社区 投票 批准,授权 HydraDX 议会在规定限额内对下述类别贡献兑付奖励。

首先请注意,本文提到的所有赏金及小费支付,均由 HydraDX 议会全权酌情决定。如果不确定您的努力是否有资格获得赏金,请提前联系。

您可在 HydraDX Discord 的 #bounties 中提问。

1. 漏洞赏金

HydraDX 在 Immunefi 上运行漏洞赏金计划(Bug Bounty)。错误和漏洞,按严重程度分成三到四类,这决定了赏金的上限:

区块链:

  • 关键:$50,000 ~ $1,000,000;
  • 高:$5,000 ~ $50,000;
  • 中:$5,000;
  • 低:$1,000.

网站和 APP

  • 关键:$5,000 ~ $50,000;
  • 高:$5,000;
  • 中:$1,000.
note
  • 为了获得赏金,必须根据认可的纰漏程序以及 HydraDX Immunefi 页面发布的相关指南上报漏洞;
  • 区块链关键漏洞赏金上限,为潜在经济损失的 10%;
  • 奖励赏金的实际数额,由议会根据情况决定;
  • 赏金由财政的 HDX 以交易所 7d MA 美元的价格支付(一旦 Oracles 可用,CEX 或 DEX - 如有疑问,请在 #bounties 中与 HydraDX 议会讨论)。

2. 开发赏金

HydraDX 开发团队,将启动一个带有开发奖励的仪表板,以尽量分散协议的技术工作。仪表板将显示最新的赏金,以及赏金描述、技术规格和数额。

目前的框架,授权 HydraDX 议会提出高达 $100,000 的开发赏金,这些赏金将由财政按 交易所 7d MA 美元价 以 HDX 形式支付。超过该数额的赏金,仍需要通过社区治理批准。

3. 社区管理

为社区管理做出努力,可从 HydraDX 财政按每小时 20 美元的标准(使用交易所 7d MA 美元价格)获得奖励。

新进社区经理,需事先得到团队批准。

以下是对这一角色的期望:

  • 担任 Telegram 和 Discord 的 MOD(管理员);
  • 成为项目大使;
  • 社交活跃;
  • 与其他社区经理一起,参加双周电话会议;
  • 协调完成翻译任务;
  • 最好已是 Hydra 社区的活跃成员。

4. 翻译

翻译工作,可从 HydraDX 财政按每小时 20 美元的标准获得 HDX 奖励(使用交易所 7d MA 美元价格)。目前,HydraDX 欢迎以下语言的翻译(可通过公投扩充列表):

  • 中文普通话;
  • 西班牙语;
  • 俄语;
  • 斯洛伐克语。

新进译员,需事先得到社区经理或 HydraDX 议会的批准。

5. 其它社区贡献

您想做出上述类别之外的贡献吗?请随时与我们联系,HydraDX 议会已准备好考虑您的个案。

该框架授权 HydraDX 议会,提供价值高达 100,000 美元的奖金(使用交易所 7d MA 美元价格)。

以下是一些可以获得奖励的贡献示例:

  • 创建良好的教育内容,例如指南、解释性博客或视频。内容创建者,在制作前和制作中,应与社区经理和 HydraDX 议会保持联系,确保提供内容的质量
  • 提供去中心化的基础设施;
  • 推进对协议或社区有贡献的整合;
  • MEME(!!)、表情符号、商品和贴纸。
- + \ No newline at end of file diff --git a/cn/staking/index.html b/cn/staking/index.html index 85de0a1c..7b3c1dd2 100644 --- a/cn/staking/index.html +++ b/cn/staking/index.html @@ -4,13 +4,13 @@ 质押 | HydraDX Docs - +

质押

HydraDX 有一个长期的 HDX 质押计划,用于 激励对协议有利的活动。 在这个页面上,您将找到 HDX 质押计划背后机制 的有关信息。 您也可以查看我们的 质押分步指南

质押基础知识

HDX 持有者,可以 质押其 HDX 并获得奖励,这些奖励奖随着时间推移变为 可领取。 质押奖励将从一个专用的池分配,该池由 不同的协议收入流 汇聚而成。 最初,池子的主要收入来源,是 HydraDX 协议的 HDX 在 Omnipool(万能池)中提供流动性产生的 LP 费用。 此外,HydraDX 社区已经批准一项提案,对质押计划实施的第一年,进行 APR 支持,即:由 HydraDX 财政提供 约 2200 万 HDX 的额外补贴,每天一次逐步分配到质押奖励池中。

进入质押池的奖励,会是在任何的特定时刻,直接分配给所有质押者。 用户有权获得的金额,与他们在质押池中质押量的相对大小成正比。 然而,奖励不会自动出现在质押者的账户上 —— 相反,质押者需要手动领取它们。

领取奖励时,HDX 质押的所有参与者,都应该了解 忠诚度和游戏化 这两个要素在其中所起的作用。 一旦奖励被分配,无法立即全额领取 —— 即使您这样做了,也只会领取分配总奖励的一小部分,其余的将返还给其他所有利益相关者。

用户若想要领取尽可能多的奖励,应该保持其 HDX 质押,直到经过足够的时间才领取(奖励按照联合曲线“归属”)。 等待时间是动态的,这取决于用户的具体动作。 仅 被动质押 的用户,需要 等待大约 2 年才能领取 95% 的奖励。 相比之下,收集最大数量行动积分(更多内容见下文)的 主动质押者,可在短短 2 个多月内,就能领取 95% 的奖励。 这仅仅是粗略的估计,实际的时间表,根据用户的具体操作和公投数量,会有所不同。

提高您的奖励

质押者可以通过 收集行动积分提高奖励 来加快领取奖励的速度。 行动积分,可以通过执行协议鼓励的某些行动来获取。 最初,收集行动积分的唯一方法,是 通过使用质押的 HDX 参与 HydraDX 治理,对社区发起的公投进行投票

login

有两个因素,决定了质押者获得行动积分的数量: 投票规模(相对于质押 HDX 总规模)和 信念乘数。 投票的信念乘数越高,权重就越大。 请记住,使用信念乘数进行投票,会 对令牌进行临时锁定。 希望获得最高奖励提升的质押者,可使用 6 倍信念乘数进行投票,从而将其 HDX 锁定 192 天(从使用此信念系数的最后一次投票开始算起)。 只是提醒一下,此锁定与质押无关 —— 相反,它是 Polkadot 生态系统治理的标准功能(更多信息请查阅 我们的相关文档) 。

信念乘数锁定天数
0.1x0天
1x6天
2x12天
3x24天
4x48天
5x96天
6x192天

领取您的奖励

当 HDX 保持质押时,用户会随着时间的推移积累奖励。 这些奖励可根据联合曲线领取,该曲线受行动积分的提升影响(见上文)。

在任何特定的时刻,质押者都可以领取 其可领取的奖励。 然而,一旦这样做了,他们就会 失去剩余不可领取的奖励。 这些奖励将 自动转回质押奖励池,并被重新分配给所有其他的质押者。 此外,领取行为会 重置用户以往的行积分点,用户将被送回联合曲线的起点,以领取未来获得的质押奖励。

这种机制,创造了一个有趣的 游戏化动态:通过 在利益相关池中停留更长时间,用户不仅 可以解锁分配奖励的大部分 ,还有机会获得 来自其他提前领取或退出的利益相关者丰厚的部分奖励回报

祝您质押快乐!

- + \ No newline at end of file diff --git a/cn/testnet_howto/index.html b/cn/testnet_howto/index.html index 91e3056c..ffeedb9d 100644 --- a/cn/testnet_howto/index.html +++ b/cn/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/cn/tip_request/index.html b/cn/tip_request/index.html index 2a4d2cee..8d73354d 100644 --- a/cn/tip_request/index.html +++ b/cn/tip_request/index.html @@ -4,13 +4,13 @@ 申请财政小费 | HydraDX Docs - +

申请财政小费

作为社区成员对协议贡献的奖励,他们可向 HydraDX 财政申请 HDX 小费。本指南将指导您如何申请小费。您可以在 这篇文章 中找到更多获得奖励的各种活动信息。

申请财政小费的流程,包括两个步骤:第一步,贡献者需要在 Subsquare 中 发布小费申请,并附上贡献描述;第二步,财政小费申请必须使用 Polkadot/apps 链上提交

01 在 Subsquare 发布

为确保透明度,所有财政小费申请必须在 HydraDX Subsquare 页面 上以讨论帖子的形式公布。

note

打开帖子之前,请确保 Subsquare 链接到您的 HDX 钱包。点击 Sign-Up(注册)(首次使用)或 Login(登录)(二次使用),并选择 with Web3 address(Web3 地址)选项。在弹出窗口中选择您的 HDX 地址后,您将被要求使用钱包签署消息。

登录后,您需要为小费申请创建一个新讨论帖。您可以点击以下链接:https://hydradx.subsquare.io/post/create

您可以使用帖子标题来表明主旨(小费申请)和贡献主题。在帖子正文中,请提供以下信息:

  • 贡献期间;
  • 贡献摘要;
  • 申请小费金额(HDX);
  • 贡献耗时(h);
  • 如果可能,请提供更详细的信息,例如:与 HydraDX 贡献相关的链接和 PR 链接(若是技术贡献)。

发布帖子之前,请确保选择 Treasury(财政)标签,以表明讨论性质。

作为参考,您可以查看这个 小费申请示例

login

点击 Create(创建)发布您的讨论帖子。此时,它应该立即在 讨论列表 中可见。

02 链上提交

发布财政小费申请后,您需在链上提交。出于这个目的,您的钱包需要持有少量 HDX 来支付交易费用。如果您目前没有任何 HDX,则不需要执行此步骤 - 其他人会帮您完成小费申请的链上提交。

财政小费申请,可通过以下链接在 Polkadot/app 上完成链上提交:https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/treasury/tips

要提交新的小费请求,请点击 Propose tip(提出小费)并提供以下信息:

  • submit with account(随账户提交)- 选择签署交易、小费申请提交链上的帐户。这个账户需要持有少量 HDX 作为交易费用。
  • beneficiary(受益者)- 选择或输入接收财政小费的帐户地址。此帐户必须与打开 Subsquare 帖子的帐户相对应。
  • tip reason(小费原因)- 提供一个 Subsquare 帖子的 URL。
login

要提交小费请求,请点击 Propose tip(提出小费)并签署交易。

确认交易后,您应该能在 Overview (概览)页面上看到小费申请。

login
- + \ No newline at end of file diff --git a/cn/tokenomics/index.html b/cn/tokenomics/index.html index c3e55e4a..a55ef80f 100644 --- a/cn/tokenomics/index.html +++ b/cn/tokenomics/index.html @@ -4,13 +4,13 @@ HDX 令牌经济学 | HydraDX Docs - +

HDX 令牌经济学

供应分布

说明:

HDX 供应总量 6,500,000,000,分布及占比如下:

  • LBP 参与者:1,983,002,235HDX(30.51%)
  • 团队:810,000,000HDX(12.46%)
  • 种子轮:540,000,000HDX(8.31%)
  • 战略轮:150,000,000HDX(2.31%)
  • BSX 众贷:120,714,086HDX(1.86%)
  • 财政:354,484,118HDX(5.45%)
  • HDX 众贷:494,588,589HDX(7.61%)
  • 整理器奖励:251,548,200HDX(3.87%)
  • 成长(LM 奖励、赏金等):1,795,662,772HDX(27.63%)

供应归属

- + \ No newline at end of file diff --git a/collator_setup/index.html b/collator_setup/index.html index 01c44860..5e5917a8 100644 --- a/collator_setup/index.html +++ b/collator_setup/index.html @@ -4,13 +4,13 @@ Set up a Collator Node | HydraDX Docs - +

Set up a Collator Node

This is a step-by-step how-to so you can get your HydraDX collator up and running. In this guide, we use Ubuntu 20.04 LTS.

Required technical specifications

The following technical specifications are required as a minimum for running a HydraDX collator node:

  • OS: Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (or equivalent single core performance)
  • Memory: 64GB RAM
  • Storage: NVMe SSD with a capacity of at least 200GB (the data footprint will grow over time)
note

These are the minimum technical requirements which have been verified by the team. Want to make sure that your machine has sufficient resources to run a node? Run a performance benchmark to find out.

Create a technical hydra user and add it to Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

Download and configure the hydradx binary

Pick a 12.x release, we are using v12.1.0 from our assets repository:

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

Command to run your collator

Best is to run your collator as a service using systemctl. To do so, create a file, namely hydradx-collator.service under /etc/systemd/system/hydradx-collator.service:

sudo vim /etc/systemd/system/hydradx-collator.service

Then paste the following:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

Before starting your node, let's create the base-path folder and give it the necessary permissions and ownership:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
caution

Make sure you have enough volume for your base-path by using df -h command.

Note that --prometheus-external is optional, but we highly recommend it so you can be able to export prometheus metrics and monitor your node's health through Grafana. For more details about monitoring, please visit this link.

If you need to monitor both the parachain and relaychain metrics, --prometheus-externaloption should be setup in both parts. You also need to set a separate port for the relaychain part as follows: --prometheus-port YOUR_CUSTOM_PORT_NUMBER

Depending on your setup, you might also want to override certain parameters like the websocket, rpc or your node p2p port. Please use hydradx --help for more information about the available options.

After saving your file, run the following commands to start your node:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

Your node should now be up and running. Make sure your hydra user has the necessary permissions to access your base-path and key file.

If you need to troubleshoot your running service, you can use the journalctl command with the -f option for tailing:

journalctl -fu hydradx-collator

Generate your session key

In order to generate keys for your node, run the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

Once done, you will have an output similar to:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

Set your session key

To associate the generated session keys with your Controller account, navigate to the following menu item in the Polkadot/apps on the Polkadot parachain HydraDX: Developer > Extrinsics.

Fill in the fields:

  • using selected account: select your Controller account;
  • submit the following extrinsic: select session on the left side and setKeys on the right;
  • keys: enter your session key you just generated;
  • proof: 0;

What's next?

Make sure that your node is fully synced. Once this is done, let us know in the dedicated Discord channel (only if you have been preselected as a collator).

- + \ No newline at end of file diff --git a/contributing/index.html b/contributing/index.html index a8a42697..4bf7a232 100644 --- a/contributing/index.html +++ b/contributing/index.html @@ -4,13 +4,13 @@ Writing Docs | HydraDX Docs - +

Writing Docs

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation
H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.


Lists

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
  4. And another item.
  • Unordered list can use asterisks
  • Or minuses
  • Or pluses

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example).

Some text to show that the reference links can follow later.


Images

Here's our logo (hover to see the title text):

Inline-style: alt text

Reference-style: alt text

Images from any folder can be used by providing path to file. Path should be relative to markdown file.

![img]{useBaseUrl('/static/img/logo.svg')}


Code

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

MarkdownLessPretty
Stillrendersnicely
123

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.


Inline HTML

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.


Admonitions

note

This is a note

tip

This is a tip

info

This is important

caution

This is a caution

danger

This is a warning

- + \ No newline at end of file diff --git a/create_account/index.html b/create_account/index.html index b86d81a0..4712f9ea 100644 --- a/create_account/index.html +++ b/create_account/index.html @@ -4,13 +4,13 @@ Create a new HDX Account | HydraDX Docs - +

Create a new HDX Account

The process of creating a new HDX Account consists of three simple steps.

01 Install Polkadot.js

In order to create and manage your HDX wallet, you need to install the Polkadot.js browser extension.

02 Upgrade metadata

After installing the Polkadot.js browser extension, you should make sure that it has been updated with the latest chain metadata. For this purpose, you can visit the following link and update your metadata, if prompted:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/settings/metadata

03 Create your HDX Account

To create a new HDX address, open the Polkadot.js browser extension and click on + > Create new account.

You will be displayed a 12-word mnemonic phrase which can be used to recover your account. Make sure that you backup your seed phrase in a secure location. Click on Next step and fill in the following information:

  • Network: Please select HydraDX Snakenet
  • Descriptive name of the account
  • Password

Your account will be created after clicking Add the account with the generated seed.

create-account
danger

Make sure to backup your recovery seed phrase by storing it in a secure location. Never share your seed phrase with anybody. The seed phrase can be used to gain access to your account. If you lose it or leak it, you might also lose all the HDX stored in your account. Please note that all HDX balances are locked until mainnet starts, so you need to make sure that you keep the account holding your tokens secure until then.

- + \ No newline at end of file diff --git a/de/404.html b/de/404.html index 04ecf1d7..1e411f62 100644 --- a/de/404.html +++ b/de/404.html @@ -4,13 +4,13 @@ Seite nicht gefunden | HydraDX Docs - +

Seite nicht gefunden

Wir konnten nicht finden, wonach Sie gesucht haben.

Bitte kontaktieren Sie den Besitzer der Seite, die Sie mit der ursprünglichen URL verlinkt hat, und teilen Sie ihm mit, dass der Link nicht mehr funktioniert.

- + \ No newline at end of file diff --git a/de/archive_hydradx_crowdloan/index.html b/de/archive_hydradx_crowdloan/index.html index 65bfad0d..97f6468f 100644 --- a/de/archive_hydradx_crowdloan/index.html +++ b/de/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX Crowdloan | HydraDX Docs - +

HydraDX Crowdloan

danger

This page has been archived, meaning that the information it contains may be outdated or no longer applicable.

The HydraDX crowdloan for the Polkadot parachain auctions is now live! You can support HydraDX by participating in our crowdloan campaign and pledging some amount of DOT tokens which will be locked up for the duration of the parachain slot.

In return, you will be granted HDX rewards which cover your opportunity costs. Once the parachain slot has expired, you will receive your DOT tokens back in full. The same applies to the scenario that HydraDX does not manage to win a parachain slot within the crowdloan campaign deadline stated hereunder.

Crowdloan Details

  • Visit: https://loan.hydradx.io/
  • Crowdloan start: 28 December 2021
  • Bidding on slots: #6 - #11
  • Onboarding of winning parachains: 11 March 2022
  • End of leased parachain slots: 12 January 2024
  • Crowdloan cap: 8,000,000 DOT
  • Rewards: between 280 and 12.5 HDX per contributed DOT
  • Rewards cap: max. 1,000,000,000 HDX (10% of total supply)
  • Vesting period: HDX rewards are distributed linearly. The distribution will start after HydraDX has been onboarded as a Polkadot parachain and the transition from Snakenet (our testnet) has been completed.
  • Crowdloan campaign deadline: 12 March 2022

HDX Rewards

All participants in the HydraDX crowdloan will receive HDX in exchange for their contributions. The amount of the rewards depends on our rank in the parachain auction race at the time of your contribution, as well as the total amount of DOT which have been contributed by others.

Contributions made before HydraDX is leading the race by 15% will receive the highest amount of rewards - between 280 and 125 HDX per contributed DOT.

After we have secured a comfortable lead, the rewards will start dropping linearly. They will be at their lowest level once HydraDX has a lead of 25% or more. Contributions made during the time that we are leading by more than 25% will receive between 28 and 12.5 HDX per contributed DOT.

The rewards system is designed to offset the opportunity costs of locking your DOT for the duration of the parachain lease, as opposed to staking it. Contributions made before we have gained a 15% lead will get their full opportunity costs reimbursed. The price of HDX used for the calculation is $ 0.026. This number is based on the closing HDX LBP price of $ 0.08 (February 2021), after taking into account the upcoming tripling of all balances which were built up during our testnet.

- + \ No newline at end of file diff --git a/de/assets/js/d631f7a2.499b2778.js b/de/assets/js/d631f7a2.99bae425.js similarity index 70% rename from de/assets/js/d631f7a2.499b2778.js rename to de/assets/js/d631f7a2.99bae425.js index 9f5c2468..f29e7f5d 100644 --- a/de/assets/js/d631f7a2.499b2778.js +++ b/de/assets/js/d631f7a2.99bae425.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=r)&&Object.keys(d.O).every((function(e){return d.O[e](c[o])}))?c.splice(o--,1):(f=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[c,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},c=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var a={};t=t||[null,c({}),c([]),c(c)];for(var f=2&n&&e;"object"==typeof f&&!~t.indexOf(f);f=c(f))Object.getOwnPropertyNames(f).forEach((function(t){a[t]=function(){return e[t]}}));return a.default=function(){return e},d.d(r,a),r},d.d=function(e,t){for(var c in t)d.o(t,c)&&!d.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:t[c]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,c){return d.f[c](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",754:"6e1b281d",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1280:"5bfc32c8",1717:"0ca40dc2",1899:"9d138630",1961:"d544b026",2250:"07178ad8",2255:"39e4c5dd",2332:"9fd70990",2989:"7921dc2a",4020:"669853c7",4085:"c0c5209d",4101:"1d2d6146",4214:"948a3151",4517:"7ab05892",4633:"6eb8a42e",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5888:"2cad9136",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",6922:"23ab7581",7033:"0a9786c2",7476:"7c1ee906",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8232:"42a52747",8323:"70254ef3",8462:"dab19d87",8696:"a53b80d1",8741:"4ccf5e49",8819:"7fc1aeb9",9219:"144c5974",9366:"c116d048",9397:"16a98310",9514:"1be78505",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"fd1dbe55",548:"2ed16348",574:"23773abf",754:"918d6ff6",942:"499b2778",994:"9eb73dfd",1019:"8d5cf2e5",1280:"5be8c5ea",1717:"df35d42c",1899:"b56b9ea7",1961:"adb0208a",2250:"dcc93d17",2255:"ebe19120",2332:"deed9950",2989:"6bc54d8d",4020:"8f5e2fe9",4085:"f51047e4",4101:"6ddd2a65",4214:"00b2a57d",4517:"64b9e13d",4633:"fe99896f",4972:"79f8b409",5183:"ecd6d151",5355:"2ecc0d08",5445:"538ec41f",5488:"b8a11bf7",5536:"e203ad45",5888:"3be0c1cd",6295:"6fb16261",6428:"f2af83b2",6714:"582b3613",6880:"129d422d",6922:"b75d34b4",7033:"1430243c",7476:"89533496",7615:"f0f7f647",7918:"bff4c59e",7939:"ee37a1af",8232:"07d4ed41",8323:"9e082c5d",8462:"aee47dbe",8696:"000b7e41",8741:"68269c6a",8819:"6ddc8fd5",9219:"1ed8a31f",9366:"1197ea5d",9397:"f2074bb9",9514:"4cb072e6",9726:"5ab88791"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,c,a){if(n[e])n[e].push(t);else{var f,o;if(void 0!==c)for(var u=document.getElementsByTagName("script"),i=0;i=r)&&Object.keys(d.O).every((function(e){return d.O[e](c[o])}))?c.splice(o--,1):(f=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[c,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},c=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var a={};t=t||[null,c({}),c([]),c(c)];for(var f=2&n&&e;"object"==typeof f&&!~t.indexOf(f);f=c(f))Object.getOwnPropertyNames(f).forEach((function(t){a[t]=function(){return e[t]}}));return a.default=function(){return e},d.d(r,a),r},d.d=function(e,t){for(var c in t)d.o(t,c)&&!d.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:t[c]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,c){return d.f[c](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",754:"6e1b281d",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1280:"5bfc32c8",1717:"0ca40dc2",1899:"9d138630",1961:"d544b026",2250:"07178ad8",2255:"39e4c5dd",2332:"9fd70990",2989:"7921dc2a",4020:"669853c7",4085:"c0c5209d",4101:"1d2d6146",4214:"948a3151",4517:"7ab05892",4633:"6eb8a42e",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5888:"2cad9136",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",6922:"23ab7581",7033:"0a9786c2",7476:"7c1ee906",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8232:"42a52747",8323:"70254ef3",8462:"dab19d87",8696:"a53b80d1",8741:"4ccf5e49",8819:"7fc1aeb9",9219:"144c5974",9366:"c116d048",9397:"16a98310",9514:"1be78505",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"fd1dbe55",548:"2ed16348",574:"23773abf",754:"918d6ff6",942:"99bae425",994:"9eb73dfd",1019:"8d5cf2e5",1280:"5be8c5ea",1717:"df35d42c",1899:"b56b9ea7",1961:"adb0208a",2250:"dcc93d17",2255:"ebe19120",2332:"deed9950",2989:"6bc54d8d",4020:"8f5e2fe9",4085:"f51047e4",4101:"6ddd2a65",4214:"00b2a57d",4517:"64b9e13d",4633:"fe99896f",4972:"79f8b409",5183:"ecd6d151",5355:"2ecc0d08",5445:"538ec41f",5488:"b8a11bf7",5536:"e203ad45",5888:"3be0c1cd",6295:"6fb16261",6428:"f2af83b2",6714:"582b3613",6880:"129d422d",6922:"b75d34b4",7033:"1430243c",7476:"89533496",7615:"f0f7f647",7918:"bff4c59e",7939:"ee37a1af",8232:"07d4ed41",8323:"9e082c5d",8462:"aee47dbe",8696:"000b7e41",8741:"68269c6a",8819:"6ddc8fd5",9219:"1ed8a31f",9366:"1197ea5d",9397:"f2074bb9",9514:"4cb072e6",9726:"5ab88791"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,c,a){if(n[e])n[e].push(t);else{var f,o;if(void 0!==c)for(var u=document.getElementsByTagName("script"),i=0;i Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/de/build_dev_chain/index.html b/de/build_dev_chain/index.html index 75700b7f..6cdcb57e 100644 --- a/de/build_dev_chain/index.html +++ b/de/build_dev_chain/index.html @@ -4,14 +4,14 @@ Einrichten einer Dev-Chain | HydraDX Docs - +

Einrichten einer Dev-Chain

Dieser Abschnitt führt Sie durch den Prozess des Einrichtens einer lokalen HydraDX-Chain für die Entwicklung.

note

Möchten Sie eine Validator Node einrichten? Bitte lesen Sie unseren collator setup guide.

01 Abhängigkeiten installieren

Um eine lokale HydraDX-Chain für die Entwicklung vorzubereiten, muss Ihr Computer alle Abhängigkeiten für die Ausführung einer Substrat-Chain abdecken. Sie müssen eine Rust-Entwicklerumgebung installieren und sicherstellen, dass sie ordnungsgemäß für das Kompilieren des Substrate-Laufzeitcodes auf das WebAssembly (Wasm) konfiguriert ist.

Sie können alle Abhängigkeiten manuell installieren und konfigurieren, lesen Sie dazu bitte den Substrate guide, oder Sie können dieses Skript die ganze Arbeit für Sie erledigen lassen:

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Build

Erstellen Sie die Wasm- und native Ausführungsumgebungen:

# Rufen Sie die Quelle der neuesten stabilen Version ab
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Erstellen Sie die Binärdatei
$ cd HydraDX-node/
$ cargo build --release

Sie können die Binärdatei hier finden: ./target/release/hydra-dx.

03 Ausführen

Bevor Sie Ihr Build ausführen, können Sie alle vorhandenen Dev-Chains auf Ihrem Computer löschen (dies müssen Sie im Entwicklungsprozess häufig tun):

$ ./target/release/hydra-dx purge-chain --dev

Führen Sie Ihr Build mit einem der folgenden Befehle aus:

$ ./target/release/hydra-dx --dev

# Führen Sie mit detaillierter Protokollierung aus
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Mit der lokalen Chain verbinden

Sie können mit Polkadot/apps eine Verbindung zu Ihrer HydraDX Dev-Node herstellen indem Sie das Netzwerk in "Development" ändern. Sie können auch diesen Link verwenden: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/de/claim/index.html b/de/claim/index.html index 234a24e1..fe13ce6c 100644 --- a/de/claim/index.html +++ b/de/claim/index.html @@ -4,7 +4,7 @@ HDX beanspruchen | HydraDX Docs - + @@ -18,7 +18,7 @@ Klicken Sie auf next um fortzufahren und die Nachricht zu signieren.

authorize

03 Signieren

Im dritten Schritt müssen Sie die Nachricht signieren um Ihre Account-Inhaberschaft zu bestätigen und den Claiming-Prozess abzuschließen.

note

Aufgrund der Eigenschaften des ss58 Adressformats welche die Polkadot Chain benutzt um Adressen in einer für Menschen lesbaren Darstellung anzuzeigen, werden die Adresse die Sie signieren und der Adresse die Sie in der Polkadot.js Erweiterung sehen werden, nicht übereinstimmen. Was Sie in der Mitteilungsbox sehen ist Ihr öffentlicher Schlüssel zu Ihrer Adresse, während Sie in der Erweiterung eine für Menschen lesbare Repräsentation Ihrer Adresse sehen werden. Dies ist vollständig sicher da wir die Adresse die Sie signieren, mit der Adresse des von Ihnen zur Beanspruchung verwendeten Accounts abgleichen. Dadurch ist es nicht möglich HDX von einer anderen Adresse zu beanspruchen außer von der die Sie im vorangegangen Schritt verwendet haben.

Abhängig von der von Ihnen verwendeten Möglichkeit die Sie in Schritt Eins ausgewählt haben werden Ihnen hier nun eine von Zwei möglichen Optionen angezeigt.

  • Wenn Sie Ihr Metamask verbunden haben, werden Sie aufgefordert eine Nachricht zu signieren wenn Sie auf den Sign-Button klicken. Folgen Sie den Anweisungen in Metamask um die Nachricht zu signieren.
  • Wenn Sie Ihre Ethereum Adresse manuell eingegeben haben müssen Sie die Nachricht mit Ihrem externen Wallet signieren, das Sie zum Kauf der Token verwendet haben. Sobald sie Ihre Nachricht signiert haben, fügen Sie die Signatur (beginnt mit "0x") in das dafür vorgesehene Feld ein.
authorize

04 Beanspruchen

Sobald die Nachricht signiert ist, müssen Sie eine Transaktion senden und Sie mit ihrer Polkadot.js Erweiterung signieren. Wenn Sie dies abgeschlossen haben sind Sie nun offizieller HDX Besitzer. Sie können Ihren HDX Kontostand überprüfen unter Polkadot.js, falls es nicht bereits in der Erweiterung angezeigt werden sollte.

authorize

Sie habenn den Claim-Prozess erfolgreich abgeschlossen und sind nun offiziell ein HDX-Halter!

Sie können Ihren Kontostand mit Hilfe von Polkadot/apps überprüfen wenn Sie sich mit dem HydraDX Netzwerk verbunden haben: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/de/collator_setup/index.html b/de/collator_setup/index.html index 68387c77..c62346f8 100644 --- a/de/collator_setup/index.html +++ b/de/collator_setup/index.html @@ -4,13 +4,13 @@ Set up a Collator Node | HydraDX Docs - +

Set up a Collator Node

This is a step-by-step how-to so you can get your HydraDX collator up and running. In this guide, we use Ubuntu 20.04 LTS.

Required technical specifications

The following technical specifications are required as a minimum for running a HydraDX collator node:

  • OS: Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (or equivalent single core performance)
  • Memory: 64GB RAM
  • Storage: NVMe SSD with a capacity of at least 200GB (the data footprint will grow over time)
note

These are the minimum technical requirements which have been verified by the team. Want to make sure that your machine has sufficient resources to run a node? Run a performance benchmark to find out.

Create a technical hydra user and add it to Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

Download and configure the hydradx binary

Pick a 12.x release, we are using v12.1.0 from our assets repository:

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

Command to run your collator

Best is to run your collator as a service using systemctl. To do so, create a file, namely hydradx-collator.service under /etc/systemd/system/hydradx-collator.service:

sudo vim /etc/systemd/system/hydradx-collator.service

Then paste the following:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

Before starting your node, let's create the base-path folder and give it the necessary permissions and ownership:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
caution

Make sure you have enough volume for your base-path by using df -h command.

Note that --prometheus-external is optional, but we highly recommend it so you can be able to export prometheus metrics and monitor your node's health through Grafana. For more details about monitoring, please visit this link.

If you need to monitor both the parachain and relaychain metrics, --prometheus-externaloption should be setup in both parts. You also need to set a separate port for the relaychain part as follows: --prometheus-port YOUR_CUSTOM_PORT_NUMBER

Depending on your setup, you might also want to override certain parameters like the websocket, rpc or your node p2p port. Please use hydradx --help for more information about the available options.

After saving your file, run the following commands to start your node:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

Your node should now be up and running. Make sure your hydra user has the necessary permissions to access your base-path and key file.

If you need to troubleshoot your running service, you can use the journalctl command with the -f option for tailing:

journalctl -fu hydradx-collator

Generate your session key

In order to generate keys for your node, run the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

Once done, you will have an output similar to:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

Set your session key

To associate the generated session keys with your Controller account, navigate to the following menu item in the Polkadot/apps on the Polkadot parachain HydraDX: Developer > Extrinsics.

Fill in the fields:

  • using selected account: select your Controller account;
  • submit the following extrinsic: select session on the left side and setKeys on the right;
  • keys: enter your session key you just generated;
  • proof: 0;

What's next?

Make sure that your node is fully synced. Once this is done, let us know in the dedicated Discord channel (only if you have been preselected as a collator).

- + \ No newline at end of file diff --git a/de/contributing/index.html b/de/contributing/index.html index 549324fd..2db6d3b0 100644 --- a/de/contributing/index.html +++ b/de/contributing/index.html @@ -4,13 +4,13 @@ Writing Docs | HydraDX Docs - +

Writing Docs

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation
H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.


Lists

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
  4. And another item.
  • Unordered list can use asterisks
  • Or minuses
  • Or pluses

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example).

Some text to show that the reference links can follow later.


Images

Here's our logo (hover to see the title text):

Inline-style: alt text

Reference-style: alt text

Images from any folder can be used by providing path to file. Path should be relative to markdown file.

![img]{useBaseUrl('/static/img/logo.svg')}


Code

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

MarkdownLessPretty
Stillrendersnicely
123

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.


Inline HTML

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.


Admonitions

note

This is a note

tip

This is a tip

info

This is important

caution

This is a caution

danger

This is a warning

- + \ No newline at end of file diff --git a/de/create_account/index.html b/de/create_account/index.html index a4600e16..39e3cc2c 100644 --- a/de/create_account/index.html +++ b/de/create_account/index.html @@ -4,13 +4,13 @@ Create a new HDX Account | HydraDX Docs - +

Create a new HDX Account

The process of creating a new HDX Account consists of three simple steps.

01 Install Polkadot.js

In order to create and manage your HDX wallet, you need to install the Polkadot.js browser extension.

02 Upgrade metadata

After installing the Polkadot.js browser extension, you should make sure that it has been updated with the latest chain metadata. For this purpose, you can visit the following link and update your metadata, if prompted:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/settings/metadata

03 Create your HDX Account

To create a new HDX address, open the Polkadot.js browser extension and click on + > Create new account.

You will be displayed a 12-word mnemonic phrase which can be used to recover your account. Make sure that you backup your seed phrase in a secure location. Click on Next step and fill in the following information:

  • Network: Please select HydraDX Snakenet
  • Descriptive name of the account
  • Password

Your account will be created after clicking Add the account with the generated seed.

create-account
danger

Make sure to backup your recovery seed phrase by storing it in a secure location. Never share your seed phrase with anybody. The seed phrase can be used to gain access to your account. If you lose it or leak it, you might also lose all the HDX stored in your account. Please note that all HDX balances are locked until mainnet starts, so you need to make sure that you keep the account holding your tokens secure until then.

- + \ No newline at end of file diff --git a/de/democracy_council/index.html b/de/democracy_council/index.html index d1abaaf8..ef845620 100644 --- a/de/democracy_council/index.html +++ b/de/democracy_council/index.html @@ -4,13 +4,13 @@ HydraDX-Rat | HydraDX Docs - +

HydraDX-Rat

Das HydraDX Council ist eine On-Chain-Einheit, die eine Schlüsselrolle bei der Governance des Protokolls spielt. Dieser Artikel informiert über die Zusammensetzung des Rates, seine Hauptaufgaben, und die Wahl der Ratsmitglieder.

Eine Schritt-für-Schritt-Anleitung zur Teilnahme an Ratswahlen finden Sie in diesem Leitfaden.

Komposition

Der HydraDX-Rat besteht derzeit aus 13 Mitgliedern.

Ein Minderheitsanteil von 6 Sitzen ist für das Gründerteam und die Investoren (4 Gründer + 2 Investoren) reserviert.

Die restlichen 7 Sitze werden von der breiteren Gemeinschaft der HDX-Inhaber gewählt.

Aufgaben und Verantwortlichkeiten

Die Aufgaben des HydraDX Council umfassen ein breites Spektrum an täglichen Governance-Aktivitäten. Zunächst kontrolliert der Rat das Finanzministerium und genehmigt oder lehnt Vorschläge des Finanzministeriums ab.

Der HydraDX-Rat spielt auch eine Rolle beim Referendum-Mechanismus. Der Rat kann eine Volksabstimmung einleiten, sofern mindestens 60 % der Mitglieder dies unterstützen (Supermehrheit) und kein Mitglied ein Vetorecht ausübt. Im Falle eines Vetos kann der Vorschlag nach Ablauf der Cool-Down-Periode erneut eingereicht werden. Das ablehnende Mitglied kann denselben Vorschlag nicht zweimal ablehnen.

Darüber hinaus kann jedes vorgeschlagene Referendum mit einer 2/3-Supermehrheit der Ratsstimmen annulliert werden. Dies kann als letztes Mittel verwendet werden, um böswillige Vorschläge oder Änderungen zu stoppen, die Fehler im Code verursachen könnten.

Schließlich ist der HydraDX-Rat für die Wahl des Technischen Komitees verantwortlich.

Wahlen

Jeder Inhaber von HDX-Token kann sich für eines der 7 nicht-permanenten Sets des HydraDX Council als Kandidat bewerben.

Die Ratswahlen finden alle 7 Tage statt, wobei ein Algorithmus die 7 nichtständigen Ratssitze für die Dauer der folgenden 7 Tage besetzt. Das Demokratiemodul verwendet denselben Phragmen-Algorithmus, der verwendet wird, um den aktiven Satz von Validatoren im Polkadot Netzwerk auszuwählen.

Alle Community-Mitglieder können bei den Ratswahlen abstimmen indem sie eine bestimmte Anzahl von HDX-Token ihrer Wahl sperren. Gesperrte Token können nicht übertragen werden und werden bei den Folgewahlen (bis auf Widerruf) verwendet. Die Wähler können und sollten mehr als einen Kandidaten in der Reihenfolge ihrer Präferenz auswählen. Der Wahlalgorithmus verteilt dann alle Stimmen, um die optimale Zuteilung der verfügbaren Ratssitze an die Kandidaten mit der höchsten Unterstützung durch die Gemeinschaft zu bestimmen.

- + \ No newline at end of file diff --git a/de/democracy_intro/index.html b/de/democracy_intro/index.html index 272cbb68..8781c980 100644 --- a/de/democracy_intro/index.html +++ b/de/democracy_intro/index.html @@ -4,13 +4,13 @@ Einführung | HydraDX Docs - +

Einführung

HydraDX ist dabei, seine Governance vollständig zu dezentralisieren. Alle Entscheidungen, die das Protokoll betreffen, werden nach einem demokratischen Verfahren gefasst, das durch das Modul Substrate Democracy unterstützt wird. Der zentrale Mechanismus zur Konsensbildung unter den Stakeholdern ist das Referendum.

Dieser Abschnitt enthält eine Reihe von Wissensartikeln, die Ihnen ein besseres Verständnis der Mechanismen hinter der Steuerung von HydraDX vermitteln sollen. Weitere Informationen finden Sie unter Funktionsweise von Volksabstimmungen, sowie zu den beiden zentralen Gruppen von Governance-Akteuren: HydraDX Council und Technischer Ausschuss.

Wenn Sie praktische Anleitungen zur Teilnahme an der Governance von HydraDX suchen, lesen Sie bitte die Schritt-für-Schritt-Anleitungen zu Teilnahme an Referenden und Teilnahme an Ratswahlen.

Demokratieparameter

Die folgende Liste enthält die wichtigsten Parameter, die den Governance-Mechanismus von HydraDX beeinflussen. Bitte beachten Sie, dass sich diese im Laufe der Zeit ändern können.

  • Mindesteinzahlung HDX für die Einleitung eines Referendums: 100.000 HDX
  • Abstimmungsfrist: 3 Tage
  • Abstimmungszeitraum für das Referendum: 3 Tage
  • Abstimmungsperiode für das Notfallreferendum: 3 Stunden
  • Cooloff-Periode nach Ablehnung eines Referendums: 7 Tage
  • Maximal ausstehende Referendumsvorschläge: 100
- + \ No newline at end of file diff --git a/de/democracy_referenda/index.html b/de/democracy_referenda/index.html index 31133f2b..c8b68c63 100644 --- a/de/democracy_referenda/index.html +++ b/de/democracy_referenda/index.html @@ -4,13 +4,13 @@ Referenda | HydraDX Docs - +

Referenda

Referenda ermöglicht es Interessenvertretern, einen Vorschlag einer gewichteten, beteiligungsbasierten Abstimmung durch die breitere Gemeinschaft zu unterbreiten. Gegenstand des Referendums ist ein Aktionsvorschlag, der das Protokoll betrifft – zum Beispiel eine Auszahlung durch das Finanzministerium oder sogar eine Änderung des Laufzeitcodes.

Grundsätzlich wird immer nur über ein Referendum abgestimmt. Andere anhängige Referendumsvorschläge werden in eine Warteschlange gestellt. Für öffentlich eingereichte Vorschläge und für Vorschläge des Rates gibt es separate Warteschlangen. Alle 3 Tage wählt der Referendumsmechanismus den besten Vorschlag mit der höchsten Unterstützung aus, abwechselnd zwischen den beiden Warteschlangen. Nach der Abstimmung und Annahme eines Referendums gibt es eine sogenannte Verzögerungsfrist von 3 Tagen, die verstreichen muss, bevor der Beschluss in Kraft tritt. Eine Ausnahme von diesen Regeln gilt für Dringlichkeitsvorschläge des Technischen Komitees, die sich mit größeren Protokollproblemen befassen und beschleunigt werden müssen.

Initiierung eines Referendums

Es gibt mehrere Möglichkeiten, ein Referendum einzuleiten, die im Folgenden genauer beschrieben werden. Die Art und Weise, wie das Referendum eingeleitet wurde, ist entscheidend für den anzuwendenden Abstimmungsmodus.

Volksabstimmung

Jeder Inhaber von HDX-Token kann ein Referendum vorschlagen indem er die erforderliche Mindestmenge an HDX-Token einzahlt und den Vorschlag in der Kette einreicht. Andere Community-Mitglieder können den (zweiten) Vorschlag unterstützen indem sie eine gleiche Anzahl von Token sperren. Zu Beginn jedes Abstimmungszyklus wird der Referendumsvorschlag mit der höchsten Anzahl an Seconding (Gesamtzahl der hinterlegten Token) von der Community zur Abstimmung gestellt.

Der Abstimmungsmodus, der für Volksabstimmungen gilt, ist Positive Turnout Bias.

note

Alle HDX-Token, die hinterlegt werden, um ein Referendum vorzuschlagen oder zu unterstützen, werden für den gesamten Zeitraum gesperrt, bis das Referendum in den Abstimmungszyklus eingetreten ist. Es ist wichtig, sich daran zu erinnern, dass es keine Garantie dafür gibt, dass ein bestimmter Vorschlag jemals genügend Unterstützung erhält, um in die Abstimmungsrunde einzutreten, was bedeutet, dass Ihre Gelder möglicherweise auf unbestimmte Zeit gesperrt bleiben.

Council Referendum

Der HydraDX-Rat hat die Befugnis, ein Referendum für eine Gemeinschaftsabstimmung vorzuschlagen. Wenn sie dies einstimmig tut, ist der anwendbare Abstimmungsmodus für das Referendum Negative Turnout Bias. Wenn das Referendum mit einfacher Mehrheit der Ratsstimmen vorgeschlagen wird, ist der Abstimmungsmodus für die Annahme der Vorschläge durch die Gemeinschaft einfache Mehrheit.

Dringlichkeitsvorschläge des Technischen Komitees

Das Technische Komitee kann Notfallvorschläge einreichen, die sich mit (kritischen) Fehlerkorrekturen oder der schnellen Übernahme kampferprobter Funktionen befassen. Notfallvorschläge überspringen die Warteschlange und treten direkt in die Abstimmungsrunde ein. Die Community kann parallel zu allen regulären Vorschlägen, die in die Abstimmungsrunde eingegangen sind, über Dringlichkeitsvorschläge abstimmen. Darüber hinaus haben Dringlichkeitsvorschläge eine kürzere Abstimmungsfrist, um sicherzustellen, dass sie beschleunigt werden können.

Absage eines Referendums

Ein einmal vorgeschlagenes Referendum kann erst nach Eintritt in die Abstimmungsrunde widerrufen werden. Eine Ausnahme von dieser Regel gilt für Vorschläge, die als protokollschädlich erachtet werden (z. B. Codeänderungen, die einen Fehler einführen). In diesem begrenzten Fall kann der Referendumsvorschlag vom HydraDX Council (mit 60 % Supermehrheit) oder dem Technical Committee (einstimmig) annulliert werden.Alle Token, die von Unterstützern gesperrt wurden, die den Vorschlag unterstützen, werden verbrannt.

Abstimmung in einem Referendum

HydraDX-Referenden haben einen Startzeitraum von 3 Tagen. Zu Beginn jeder neuen Periode wird der Vorschlag mit der höchsten Anzahl von Entsendungen aus der Warteschlange genommen und in eine Abstimmungsrunde gestellt. Jede Abstimmungsrunde hat eine Dauer von 3 Tagen. Während dieser Zeit können die Mitglieder der Gemeinschaft über ein gewichtetes, stakebasiertes Verfahren über das Referendum abstimmen. Sie tun dies, indem sie eine bestimmte Anzahl von HDX-Token für einen bestimmten Zeitraum sperren.

note

Gesperrte HDX-Token können für die Dauer des gewählten Sperrzeitraums nicht übertragen werden. Sie können jedoch weiterhin zum Abstecken und zur Abstimmung verwendet werden.

Stimmengewichtung

Es gibt zwei Faktoren, die das Gewicht jeder Stimme in einem Referendum bestimmen. Der erste Faktor ist die Menge an HDX-Token, die der Wähler zur Unterstützung der Abstimmung einsperrt. Der zweite Faktor ist der sogenannte Conviction Multiplier, der die Dauer widerspiegelt, für die der Wähler bereit ist, die Token zu sperren.

vote_weight = tokens * conviction_multiplier

Abstimmungssperrfristen haben die gleiche Dauer wie die Inkraftsetzungsverzögerung. Wenn Token für 1 Abstimmungsperiode gesperrt sind, bedeutet dies, dass sie nach Beendigung der Abstimmung noch 3 Tage gesperrt bleiben. Wähler können das Gewicht ihrer Stimmen beeinflussen, indem sie die Anzahl der Zeiträume, für die die Token gesperrt sind, verringern oder erhöhen. Es ist möglich, eine Stimme mit 0 Sperrperioden herauszubringen, ihr Gewicht wäre jedoch nur ein Bruchteil (Überzeugungsmultiplikator von 0,1x). Andererseits erhöht sich der Überzeugungsmultiplikator um 1 für jede Verdoppelung der Sperrperioden. Wie in der Tabelle unten gezeigt, würde das Sperren der Stimmen für maximal 32 Perioden den Verurteilungsmultiplikator auf das 6-fache erhöhen.

SperrzeitenÜberzeugungsmultiplikator
00.1
11
22
43
84
165
326
Beispiel:

Alice stimmt mit 5000 HDX und 0 Sperrzeiten.
Bob stimmt mit 100 HDX und 32 Sperrperioden ab.

Alice Gewicht: 500
Bob Gewicht: 600

Abstimmungsmodi

Ein weiterer wichtiger Aspekt des Demokratiemoduls sind die unterschiedlichen Wahlmodi. Die für die Annahme oder Ablehnung eines Referendums erforderliche Stimmenschwelle kann je nach Einleitung des Referendums und der Wahlbeteiligung variieren. Die Wahlbeteiligung wird anhand der Gesamtmenge der HDX-Token berechnet, die zur Abstimmung im Referendum verwendet wurden (ohne Überzeugungsmultiplikatoren). Ob die Wahlbeteiligung niedrig war oder nicht, wird durch das Verhältnis zwischen Wahlbeteiligung und Elaktorate (d. h. der Gesamtzahl der stimmberechtigten HDX-Token) bestimmt..

Positive Turnout Bias

Dies ist der Standard-Abstimmungsmodus, wenn von der Gemeinschaft ein Referendum vorgeschlagen wird. Bei geringerer Wahlbeteiligung ist eine qualifizierte Supermehrheit von Ja-Stimmen erforderlich, um das Referendum zu genehmigen. Mit steigender Wahlbeteiligung sinkt die Schwelle in Richtung einer einfachen Mehrheit.

Negative Turnout Bias

Dieser Abstimmungsmodus gilt für Referenden, die vom Rat einstimmig vorgeschlagen wurden. Solche Vorschläge erfordern eine qualifizierte Supermehrheit von "Nein"-Stimmen, um bei geringer Wahlbeteiligung abgelehnt zu werden. Mit steigender Wahlbeteiligung sinkt die Schwelle zur Ablehnung des Referendums in Richtung einer einfachen Mehrheit.

Einfache Mehrheit

Volksabstimmungen, die vom Rat mehrheitlich (also nicht einstimmig) initiiert wurden, können von der Gemeinde mit einfacher Stimmenmehrheit (50% + 1) angenommen werden.

- + \ No newline at end of file diff --git a/de/democracy_technical_committee/index.html b/de/democracy_technical_committee/index.html index 586ecc82..d4cb83b0 100644 --- a/de/democracy_technical_committee/index.html +++ b/de/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ Technischer Ausschuss | HydraDX Docs - +

Technischer Ausschuss

Das Technical Committee ist eine Gruppe erfahrener Kernentwickler, die direkt vom HydraDX Council ernannt wird. Seine Hauptaufgabe besteht darin, die technische Stabilität des Protokolls zu gewährleisten.

Das Technische Komitee hat das Recht, Notfallreferenden durchzuführen, die im Schnellverfahren durchgeführt und parallel zu allen anderen aktiven Referenden abgestimmt werden. Dies ermöglicht dem Ausschuss, schnell zu handeln und kritische (Code-)Änderungen vorzunehmen.

Eine weitere wichtige Befugnis des Technischen Komitees ist die Möglichkeit, Referendumsvorschläge, die als nachteilig für das Protokoll angesehen werden, zurückzuziehen. Um einen Referendumsvorschlag aufzuheben, muss der Ausschuss einstimmig zustimmen.

- + \ No newline at end of file diff --git a/de/dev_intro/index.html b/de/dev_intro/index.html index f7bea8f6..d03089ff 100644 --- a/de/dev_intro/index.html +++ b/de/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/de/great-unlock/index.html b/de/great-unlock/index.html index 29e68923..b36fc724 100644 --- a/de/great-unlock/index.html +++ b/de/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/de/howto_bonds_lbp/bonds1.jpg b/de/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/de/howto_bonds_lbp/bonds1.jpg and b/de/howto_bonds_lbp/bonds1.jpg differ diff --git a/de/howto_bonds_lbp/bonds2.jpg b/de/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/de/howto_bonds_lbp/bonds2.jpg and b/de/howto_bonds_lbp/bonds2.jpg differ diff --git a/de/howto_bonds_lbp/index.html b/de/howto_bonds_lbp/index.html index 72e20389..b140840d 100644 --- a/de/howto_bonds_lbp/index.html +++ b/de/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

caution

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
note

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/de/howto_bridge/index.html b/de/howto_bridge/index.html index ecf34065..77ea57b4 100644 --- a/de/howto_bridge/index.html +++ b/de/howto_bridge/index.html @@ -4,13 +4,13 @@ Bridge Assets | HydraDX Docs - +

Bridge Assets

On this page you will find a step-by-step guide on bridging tokens from the Ethereum ecosystem. Currently there are two methods to bridging to and from Ethereum (via Wormhole):

Wormhole’s Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain.

To/From Ethereum via Moonbeam

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Talisman or Metamask);
caution

Make sure to have enough tokens (ETH) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens.

01 Navigate to Carrier.so

https://www.carrier.so/

caution

Use with caution. All crypto applications can potentially carry risks related to smart contracts/pallets.

metadata

02 Add the Wallets from Source and Destination Network

  • Once you have navigated to Carrier.so, add the wallets needed to allow for bridging to and from the desired networks (1 in image above).
  • In the example above, Metamask was selected as the wallet for Ethereum and Talisman for HydraDX.
metadata

03 Select Networks and Wallets to Bridge

metadata
  • Once Metamask and Talisman are connected, select the network chains (2) and select the previously connected wallets (3).

04 Select Asset to Bridge

  • Select the token asset and amount of tokens you would like to bridge (4).

05 Bridge Tokens

  • Within Settings (5), you can select whether to Auto Relay the transaction. It is recommended that this is toggled on.
metadata
  • Click Confirm & Begin Transaction (6) to proceed. This will prompt your wallet to sign the transactions. Once confirmed, you are all done!

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

To/From Ethereum via Acala

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Metamask);
  • Bind your two wallets following Acala's guide. Completing this action will require a small amount of ACA.
caution

Make sure to have enough tokens (ETH and ACA) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens, and for binding your wallet addresses.

01 Navigate to Acala Bridge Page

https://apps.acala.network/bridge

Once you have been directed to Acala bridge page, follow the actions below:

metadata

Step 2: Connect to Your Account

  • Connect your account (1).
  • Select the chains you intend to bridge to and from (2), in this case, it will be Ethereum as the Origin Chain and HydraDX as the Destination Chain.
  • Connect to your Metamask account that you are bridging from (3).

Step 3: Bridge Tokens

  • Enter the amount of tokens and the token for bridging (4).
  • To commence the bridge, click Approve Tokens (5) and sign the transaction using your Metamask wallet app.
  • Once the tokens are approved for transfer, click Send Tokens (5). This starts the bridging process cross-chain.
  • Once the transaction has been processed by Wormhole, click Redeem & Route Tokens (5). This action results in you receiving the tokens on the destination chain.

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

- + \ No newline at end of file diff --git a/de/howto_dca/index.html b/de/howto_dca/index.html index ba95dd41..5c79dc2a 100644 --- a/de/howto_dca/index.html +++ b/de/howto_dca/index.html @@ -4,13 +4,13 @@ Place a DCA Order | HydraDX Docs - +

Place a DCA Order

On this page you will find a step-by-step guide for setting up a DCA order in the HydraDX Omnipool.

Before proceeding, we encourage you to visit our DCA product page in order to get yourself familiar with the HydraDX implementation of the dollar-cost averaging strategy.

Step 1: Navigate to HydraDX DCA Page

https://app.hydradx.io/dca

Step 2: Connect to Your Account

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 3: Set up DCA Order

  • Select the asset you will use to pay for the swap; Enter the order amount for each DCA trade, and the total order size (2);
  • Select the time interval for each DCA swap (3);
  • Select the asset you would like to receive from the swap (4);
  • For advanced users who would like to set up orders at specific block intervals, you can toggle the switch Advanced Settings (5) to set this up;
  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (6);
  • To complete the DCA order, click on Schedule DCA trades (7) and sign the transaction using your wallet app.

Step 4: View your DCA Order

  • After submitting it, your DCA order will appear under DCA Orders;
  • To see the details, click the Dropdown Arrow (8);
  • You can cancel your DCA order for the remaining amount by clicking on Terminate (9).
- + \ No newline at end of file diff --git a/de/howto_hydrated_farms/index.html b/de/howto_hydrated_farms/index.html index 1408cfa0..fdd7ddac 100644 --- a/de/howto_hydrated_farms/index.html +++ b/de/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ Join Hydrated Farms | HydraDX Docs - +

Join Hydrated Farms

With Hydrated Farms, providing liquidity to selected assets is incentivized by additional rewards on top of rewards from trading fees. To learn more, please visit the dedicated product page.

00 Navigate to Liquidity Page

https://app.hydradx.io/liquidity

01 Provide Liquidity

Incentivized assets can be identified by the Farm rewards section which displays all available rewards for a given farm.

metadata

To join a farm, you must first provide liquidity (step-by-step guide here).

02 Join Farm

Once you have provided liquidity for an incentivized asset, you can join its farm.

metadata

To do so, click on Join farms (located next to your liquidity position) and sign the transaction using your wallet app.

Happy hydrated farming!

- + \ No newline at end of file diff --git a/de/howto_lp/index.html b/de/howto_lp/index.html index 17876703..ffee7000 100644 --- a/de/howto_lp/index.html +++ b/de/howto_lp/index.html @@ -4,13 +4,13 @@ Provide Liquidity | HydraDX Docs - +

Provide Liquidity

On this page you will find a step-by-step guide for providing liquidity in the HydraDX Omnipool. Becoming a liquidity provider allows you to earn rewards from the fees generated by trades in the pool.

Before deciding to become a liquidity provider, we encourage you to visit our product page and to get yourself familiar with the unique features of the HydraDX Omnipool.

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Navigate to Omnipool Liquidity

https://app.hydradx.io/#/liquidity

metadata

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Managing Your Liquidity

Adding Liquidity

To add liquidity for a given asset, click the button Add liquidity which is located right next to that asset (3).

info

In the HydraDX Omnipool, each individual asset has a Total Value Locked (TVL) cap. This means that once the cap has been reached, users can no longer further add liquidity for that specific asset.

The individual caps for each asset will be reviewed from time to time by the team; any suggested revisions (either from team or the community) will be submitted as proposals via governance and voted on.

metadata

Fill in the amount of liquidity you wish to provide (1), click Add liquidity (2) and sign the transaction using your wallet.

Next, you can learn how to join Hydrated Farms and earn additional rewards on top of the rewards from trading fees.

Removing Liquidity

metadata

To remove liquidity, toggle the dropdown located right next to the relevant asset (1) and click Remove liquidity (2) on the position you wish to exit.

metadata

Toggle or enter the amount of liquidity you wish to withdraw (3), click on Remove liquidity (4) and sign the transaction using your wallet.

- + \ No newline at end of file diff --git a/de/howto_stake/index.html b/de/howto_stake/index.html index 9f1b74b2..ead57670 100644 --- a/de/howto_stake/index.html +++ b/de/howto_stake/index.html @@ -4,13 +4,13 @@ Stake HDX | HydraDX Docs - +

Stake HDX

Staking allows users to stake their HDX tokens and earn rewards which vest over time. This page contains a step-by-step guide on how to stake your HDX. Before proceeding, we recommend that you get familiar with the basics of HDX staking.

If you don't have any HDX, you can obtain some on our trade page by swapping against a range of assets supported by the Omnipool.

Step 0: Navigate to HydraDX Staking Page

https://app.hydradx.io/staking

Connect your wallet to HydraDX by clicking Connect Account.

Step 1: Stake Your HDX

  • Select the amount of HDX tokens you would like stake (3).
  • Click on Stake (4) to confirm and sign the transaction using your wallet app.
metadata

Step 2: Keep Your HDX Staked

  • The amount of rewards you receive is determined by the size of your staked HDX relative to the whole stake pool.
  • As time passes, you unlock a greater portion of your allocated rewards. The rate of unlocking is determined by a rewards bonding curve.
  • Learn more in the Staking product docs.

Step 3: Boost Your Rewards

  • Collect Action Points to boost your rewards and increase the pace at which you unlock rewards.
  • You can collect Action Points by voting on referenda. The more staked HDX you use for the vote and the higher the Conviction Multitplier - the more Action Points you receive.
  • Learn more in the Staking product docs.

Step 4: Claim Your Rewards

  • Review your Staking statistics to observe and plan your own staking strategy (5).
  • Once you are done staking, Claim your unlocked rewards (8).
metadata
caution

Every time you claim unlocked staking rewards, you forfeit any locked rewards which are redistributed to all other stakers. Furthermore, your past Action Points will be reset.

For instance, if a staker claims rewards when 75% of the rewards are available, the remaining 25% is forfeited. The staker must then wait for the same duration to claim 75% of the subsequent batch of rewards.

- + \ No newline at end of file diff --git a/de/howto_trade/index.html b/de/howto_trade/index.html index ceb748d0..374e037f 100644 --- a/de/howto_trade/index.html +++ b/de/howto_trade/index.html @@ -4,13 +4,13 @@ Trade in Omnipool | HydraDX Docs - +

Trade in Omnipool

This page provides a step-by-step guide which will help you execute your first trades using the HydraDX Omnipool.

The HydraDX Omnipool is a next-gen AMM which unlocks unparalleled efficiencies, you can find out more in our product documentation.

metadata

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Enter Omnipool

https://app.hydradx.io/#/trade

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Execute a Trade

The HydraDX Trade UI allows you to intuitively execute a trade:

  • Select the pair of tokens you intend to trade (2);
  • Enter the amount of tokens for the trade (3).
    You can enter the amount of tokens you would like to pay with (e.g. 5000 DAI), but you can also enter the amount of tokens you would like to receive (e.g. 1000 HDX);
  • If you would like to adjust your slippage preferences, you can do so in Settings (4);
  • To complete the trade with instant execution (pre-selected) (5), click on Swap (7) and sign the transaction using your wallet. Otherwise, follow the additional steps below.

04 Execute a Split Trade

If your trade is large enough so that price impact would be > 0.15%, the UI will allow you to select Split trade (6) - breaking your trade into multiple smaller trades executed over < 3 hours and therefore reducing your price impact.

  • Select the pair of tokens and amounts as in 03 Execute a Trade above;
  • Select Split trade (6);
  • To schedule your Split trade execution, click on Place trades (7) and sign the transaction using your wallet.

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/de/howto_wallet_parity_signer/index.html b/de/howto_wallet_parity_signer/index.html index edfd6119..468a8926 100644 --- a/de/howto_wallet_parity_signer/index.html +++ b/de/howto_wallet_parity_signer/index.html @@ -4,14 +4,14 @@ Use Parity Signer | HydraDX Docs - +

Use Parity Signer

Parity Signer is a mobile app which turns your iOS or Android device into a dedicated hardware wallet for Polkadot, Kusama, and any other Substrate-based chain. It allows you to keep your private keys offline while still being able to conveniently sign transactions in an air-gapped way using QR codes.

Set Up Parity Signer

Before You Start: Stay Safe

Start clean

Before installing Parity Signer, make sure that your phone is in a clean state. If it has been used, perform a factory reset and do not install any other apps besides Parity Signer.

Don’t Insert Sim

If possible, don’t turn on WiFi or use a secure WiFi connection, preferably with no other connected devices and a reputable VPN provider to connect, update the device, and install the Parity signer app.

Use Strong Passwords

For robust security, use long passwords for the device and the accounts you need to create to use it.

Setup New Account

Don’t use your old google ID or apple ID, create a new one specifically for this use which will be used only to download updates and parity signer. In case of Android device it’s better to not use WiFi or google account at all. We recommend using some sort of OS that encrypts your data like Lineage O.S. If an email is required, create a new one. Alternatively, you can create new apple id and email on iOS.

No Biometrics

Avoid fingerprint scanners, face ID, or shot numeric codes as they are exploitable. Use a strong password instead.

Disable All Signal-receiving Features

Use airplane mode and make sure to disable all of these features manually. If you are on an iOS device, turn it off and ask to auto-join networks and hotspots in the WiFi settings. Including:

  • Location services
  • WiFi (if required to upgrade or setup, disable right after the update)
  • Bluetooth

Logout From All Accounts

Log out from App stores, iCloud, and any other accounts you’ve joined.

Updating Your Device

If you are using WiFi to update your device, remember to disable it right after the update and use it only in a secure environment, preferably through a secure and encrypted VPN channel. After the update is complete, forget the WiFi network to make sure you don't automatically rejoin.

Install Parity Signer

Install Parity Signer from the official app store for your device (iOS / Android).
Make sure that the application you are downloading has been published by Parity Technologies.

Create a New Account

To create a new account, follow the steps below.

01 Add Seed

Open the Parity Signer app and select New seed.

metadata

02 Back Up your Recovery Phrase

The app will display your recover phrase. Write it down and store it in a safe place.

metadata

After completing this, you are all set to go! You can use your phone passcode or authentication method (fingerprint / face id) in Parity Signer.

danger

Stay safe!

Anyone with your seed phrase can access your funds, and there is no recourse for someone stealing your seed phrase.

To protect your seed phrase, consider the following tips:

  • Never store your seed phrase as a digital file on any device.
  • Always write down your seed phrase with a pen and paper.
  • Store the paper with your seed phrase on it somewhere safe.
  • Never give your seed phrase to anybody, including support staff.

Connect to Polkadot.js/apps

Optionally, you can add your Parity Signer account into the Polkadot.js browser extension which will allow you to view your balances on the Polkadot.js/apps accounts page and to sign transactions more easily.

On Polkadot.js/apps

To add your account, open the Polkadot.js browser extension, click on + and select Attach external QR-signer account.

metadata

On Parity Signer

  • Open Keys tab in the bottom menu;
  • Select the network you will be using from the dropdown menu next to chain;
  • Select your desired account or sub-account;
  • You will see a QR code which you need to scan with your device camera.

Add HydraDX Chain

To use Parity Signer, you first need to add a new chain to Parity Signer. If you want to use Parity only for Polkadot or Kusama, you can skip this step and proceed with updating metadata. To add a new chain, you need to scan a QR code with base information about the chain.

01 Get Chain Specs

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select HydraDX as the desired chain. After that, click on Chain Specs.

metadata

02 Add Specs

On your Parity Signer, click Scanner, scan the QR code and click Add new chain.

Use Parity Signer

danger

Always make sure you are scanning a QR code signed by a trusted verifier.

Sign a Transaction

To sign a transaction from your parity signer, we recommended adding it to polkadot.js extension for ease of use. Until more chains can work with Parity Signer directly, it will be the most convenient way to use it inside applications on your desktop.

When signing a transaction using your Parity Signer, Polkadot.js/apps will display a QR code.

metadata

Scan the QR code using Parity Signer and click on Unlock key and sign.

metadata

Your Parity Signer will now display a QR code. To complete signing the transaction, switch back to Polkadot.js/apps and click on Scan signature via camera.

Update Metadata

To use the Parity Signer, you require the latest metadata for decoding transactions in the Parity Signer. You can acquire the metadata by scanning a multi-part QR code containing this data, allowing the Parity Signer to decode the actual transaction and display it correctly before you sign. This step is similar to updating your ledger application.

01 Get Metadata

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select the desired chain. After that, click on Metadata.

metadata

02 Update

On your Parity Signer, click Scanner, and update the Metadata by scanning the QR code

- + \ No newline at end of file diff --git a/de/howto_xcm/index.html b/de/howto_xcm/index.html index fabaada3..d3d0ddbe 100644 --- a/de/howto_xcm/index.html +++ b/de/howto_xcm/index.html @@ -4,13 +4,13 @@ Cross-chain Transfer | HydraDX Docs - +

Cross-chain Transfer

On this page you will find a step-by-step guide for performing cross-chain transfers.

Cross-chain transfers allow you to transport non-native assets to the HydraDX chain from other Polkadot parachains, or from Polkadot itself.

Currently, the following tokens are supported by HydraDX for cross-chain transfers:

  • DOT
  • DAI (from Acala, bridged via Wormhole)
  • ETH (from Acala, bridged via Wormhole)
  • HDX

00 Prerequisites

Before you continue, please make sure you have sufficient amount of tokens on the destination chain for fees (ACA or DOT).

01 Navigate to Cross-chain Transfers

https://app.hydradx.io/#/cross-chain

metadata

02 Connect Your Account

Click on Connect wallet and connect to your preferred Polkadot wallet. After that, select your account.

03 Cross-chain Transfer

  • Select the source chain and the destination chain;
  • Select the asset you intend to transfer and enter the amount;
  • Enter the destination address. It should automatically populate with your address on that chain, but you can also change it to another address;
  • Click Transfer and sign the transaction using your wallet.
- + \ No newline at end of file diff --git a/de/identity/index.html b/de/identity/index.html index 7672aaa6..307e0d0e 100644 --- a/de/identity/index.html +++ b/de/identity/index.html @@ -4,13 +4,13 @@ Identität festlegen | HydraDX Docs - +

Identität festlegen

Kontoinhaber haben die Möglichkeit, ihre eigene Identität festzulegen, indem sie bestimmte Informationen bereitstellen und in der Blockchain speichern. Außerdem können die Identitätsinformationen optional zur Überprüfung an die HydraDX-Registratoren übermittelt werden. Durch das Festlegen und Überprüfen ihrer Identität tragen Validatoren und Nominatoren dazu bei, das Vertrauen in das Netzwerk zu stärken.

note

Wenn Sie als HydraDX-Validator teilnehmen, empfehlen wir Ihnen dringend, sowohl Ihre Identität festzulegen als auch den Überprüfungsprozess durchzuführen. Verifizierte Validatoren erscheinen vertrauenswürdiger und ziehen mehr Nominierungen an, wodurch sich ihre Chancen erhöhen, in die Gruppe der aktiven Validatoren aufgenommen zu werden.

01 Identität festlegen

Um Ihre Identität festzulegen, öffnen Sie Polkadot/apps (verbunden mit HydraDX Snakenet network) und navigieren Sie zu My accounts. Man kann auch diesem Link folgen:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

Suchen Sie auf der Kontoseite das Konto, auf dem sich Ihre gebundenen HDX-Token befinden. Klicken Sie auf die drei Punkte neben dem Konto (auf der rechten Seite) und wählen Sie Set on-chain identity.

authorize

Sie sehen ein Popup mit dem Namen register identity. Hier können Sie folgende Informationen eingeben:

  • Offizieller Name
  • E-Mail
  • Webadresse
  • Twitter
  • Riotname (falls Sie Matrix verwenden)
note

Sämtliche Angaben sind optional. Sie können nach Belieben entscheiden welche Angaben Sie hinterlegen möchten. Wenn Sie jedoch eine Validator Node betreiben möchten wir Sie darum bitten Ihre E-Mail-Adresse anzugeben. Dies ermöglicht es uns Sie zu kontaktieren, falls wir Probleme an Ihrer Node feststellen.

Im letzten Feld des Popups sehen Sie die Menge von HDX, die Sie hinterlegen müssen, um Ihre Identitätsinformationen zu speichern. Sie erhalten diese Kaution zurück, sobald Sie sich entschließen, Ihre Identität zu einem späteren Zeitpunkt zu löschen.

authorize

Klicken Sie nach dem Ausfüllen der Informationen auf Set Identity und signieren Sie die Transaktion mit der Browsererweiterung Polkadot.js. Sobald die Transaktion bestätigt würde, wird Ihre Identität festgelegt.

02 Senden Sie Ihre Identität zur Überprüfung

Nachdem Sie Ihre Identität festgelegt haben, kann man sie zur Überprüfung an die Netzwerkregister senden. Öffnen Sie dazu Polkadot / apps und navigieren Sie zu Developer > Extrinsics. Man kann auch diesem Link folgen:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

Nachdem Sie im letzten Schritt das entsprechende HydraDX-Konto ausgewählt haben, müssen Sie die folgenden Informationen eingeben:

  • extrinsic: identity
  • action: requestJudgment
  • reg_index: Hier müssen Sie die ID des Registers eingeben, den Sie für die Überprüfung ausgewählt haben.
    HydraDX hat 2 Registratoren: Simon Kraus - HydraSik (ID: 0) and Jimmy Tudeski - stakenode (ID: 1).
  • max_fee: Hier müssen Sie die maximale Gebühr in HDX eingeben, die Sie zur Überprüfung an den Registrator zahlen möchten. Nur Registratoren mit einer Gebühr unter Ihrer max_fee können die Überprüfung durchführen.

Um Ihre Bestätigungsanfrage einzureichen, klicken Sie auf Submit Transaction und signieren Sie die Transaktion.

authorize

Bitte beachten Sie, dass der Vorgang der Identitätsprüfung einige Zeit in Anspruch nehmen kann. Um den Status Ihrer Anfrage anzuzeigen, navigieren Sie zu My accounts und bewegen Sie den Mauszeiger über den Abschnitt, in dem Ihre Identität angezeigt wird. Es wird ein Popup mit dem aktuellen Status angezeigt.

03 Ergebnis des Überprüfungsverfahrens

Nach der Bearbeitung Ihrer Bestätigungsanfrage wird der Registrator einen der folgenden Status festlegen, die in Ihrem Identitätsstatus sichtbar werden:

  • Unknown - Standardwert, es wurde noch kein Urteil gefällt.
  • Reasonable - Die bereitgestellte Informationen erscheinen angemessen, es wurden jedoch keine eingehenden Überprüfungen durchgeführt.
  • KnownGood - Die Informationen sind korrekt.
  • OutOfDate - Die Informationen waren in der Vergangenheit korrekt, sind aber jetzt veraltet.
  • LowQuality - Die Informationen sind ungenau, können jedoch durch Aktualisierung behoben werden.
  • Erroneous - Die angegebenen Informationen sind falsch und weist möglicherweise auf eine böswillige Absicht hin.
- + \ No newline at end of file diff --git a/de/index.html b/de/index.html index ec42ef45..72f47d8a 100644 --- a/de/index.html +++ b/de/index.html @@ -4,7 +4,7 @@ Erste Schritte | HydraDX Docs - + @@ -18,7 +18,7 @@ In diesem Omnipool können verschiedene Assets gegeneinander gewertet werden indem der native HDX-Token als Referenzwert herangezogen wird. Mit dem Omnipool bricht HydraDX die traditionellen Konzepte des Handels in paarweisen isolierten Pools auf. Des Weiteren sind wir sehr glücklich ein Teil des Polkadot Ökosystems zu sein und sehen einer Zukunft entgegen, in der wir der meistgennutzte Liquiditäts-Anbieter für alle Substrate-basierten Assets sind.

- + \ No newline at end of file diff --git a/de/lbp/index.html b/de/lbp/index.html index 3dcbbb79..d0949795 100644 --- a/de/lbp/index.html +++ b/de/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

danger

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/de/learn_amm/index.html b/de/learn_amm/index.html index d39c4424..b6ab39e8 100644 --- a/de/learn_amm/index.html +++ b/de/learn_amm/index.html @@ -4,13 +4,13 @@ What are AMMs? | HydraDX Docs - +

What are AMMs?

This article provides an introduction to Automated Market Makers (AMMs) together with some of their underpinning concepts such as slippage, liquidity provisioning and impermanent loss.

This introductory information will help you understand better the mechanics behind the HydraDX Omnipool which you can find described in our product documentation.

A Short Intro into AMMs

To explain Automated Market Makers (AMMs) and how they work, we can contrast them to their centralized counterpart: Order books.

Order Books

Order books provide a mechanism which is deployed by centralized exchanges to facilitate trading between two assets. Users can place a Buy or Sell order in an electronic list managed by the exchange. The orders in this so-called Order Book are organized by price level and progressively filled as demand shifts and orders are being matched. The limitations of order books become apparent against the background of their centralized nature.

The need for an intermediary to “keep” the order book and to facilitate the process of order matching creates a dependency on a central authority. This central authority has control over the trading and needs to be trusted by the participants. In times of substantial volume traffic and volatility, the central authority can decide to halt trading and stop performing its market-making function. Furthermore, the process of adding new tradable assets is permissioned and projects may need to pay in advance to get their assets listed.

AMMs

Automated Market Makers (AMMs) is the answer by the DeFi industry to order books. AMMs provide a decentralized, permissionless way of trading tokens without the need to subdue oneself to a central authority of control.

AMMs consist of liquidity pools that hold the available liquidity of the underlying tradable assets. This liquidity is provided by users (the so-called “liquidity providers”) who are incentivized to do so by the prospect of earning rewards from the fees generated by trades in the pool.

In the case of AMMs, any user can execute a Buy or Sell order on top of a given trading pool. The price of the trade is determined on the spot by a deterministic algorithm which takes as input the relationship between the liquidity of the traded assets, together with other factors which depend on the particular AMM implementation.

Slippage

When a trade is executed, users may experience a common side-effect of AMMs known as slippage. This is the difference between the expected price of a trade and the price when the trade is actually executed.

Slippage is determined by the amount of liquidity available within the trading pool. If there is a low amount of liquidity provided for the asset, then the slippage percentage when transacting with big orders will be higher.

Providing Liquidity

Thanks to the decentralized nature of an AMM, anyone can become a liquidity provider (LP) for a liquidity pool by depositing some amount of value in return for a token representing their liquidity position.

LPs are rewarded with fees for providing this liquidity based on the trading activity experienced by the asset for which they have provided liquidity.

Impermanent Loss (IL)

Impermanent loss (IL) is a risk faced by liquidity providers which embodies the difference in value between holding tokens in an AMM as opposed to holding them in your wallet.

Liquidity pools consist of multiple tokens (usually two) which are pooled together. IL occurs when the tokens inside the pool diverge in price. The greater the divergence, the greater the risk of negative returns for the pool's LPs.

The risk is referred to as "impermanent" because the loss is only realized when liquidity is withdrawn from the pool. If the relative prices of tokens in the pool return to their original state (when the tokens were deposited), the loss is minimized or eliminated. The loss will become permanent at the moment when the liquidity is withdrawn, leading to reduced earnings.

As such, LPs need to weigh the fees and rewards earned from LPing versus simply holding their tokens in their wallets.

- + \ No newline at end of file diff --git a/de/node_monitoring/index.html b/de/node_monitoring/index.html index d7e3496c..f8ba3e8f 100644 --- a/de/node_monitoring/index.html +++ b/de/node_monitoring/index.html @@ -4,7 +4,7 @@ Node Monitoring | HydraDX Docs - + @@ -34,7 +34,7 @@ Stellen Sie http://localhost:9090/ ein und klicken Save and Test.

Das Dashboard importieren

Bitte klicken Sie den Plus-Button im Hauptmenü und wählen import.

Sie können das HydraDX Dashboard nutzen und um es zu laden geben Sie einfach die ID 14158 ein und klicken auf Load.

Hier müssen Sie nicht viel einstellen, vergewissern Sie sich lediglich, dass Prometheus als Datasource eingestellt ist. Sie können den Importvorgang nun abschließen.

Sie sollten das Dashboard sofort mit ihren Daten sehen. Falls einzelne Panele leer sind, vergewissern Sie sich bitte, dass die Auswahlfelder ganz oben folgende Werte enthalten:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/de/omnipool_dca/index.html b/de/omnipool_dca/index.html index d35f215f..88d33ea7 100644 --- a/de/omnipool_dca/index.html +++ b/de/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA Trading | HydraDX Docs - +

DCA Trading

HydraDX DCA and Split Trade (easy DCA) are two user-friendly features which allow traders to implement the dollar-cost-averaging (DCA) strategy when trading in the Omnipool - in a permissionless and non-custodial way.

Following the DCA strategy, orders are not placed at once but instead split into smaller trades which are executed at regular intervals of time. By doing so, traders may protect themselves against price volatility and achieve an average price. Additionally, splitting a large order in smaller chunks will result in less slippage.

HydraDX has two DCA implementations - the full DCA feature, and Split Trade (easy DCA) which can be found on the main trading page. Further down, you can learn more about these features.

If you are looking for step-by-step guidance, check out the how-to place a DCA order guide.

HydraDX DCA

HydraDX DCA provides an intuitive UI which enables users to fine-tune their DCA orders in the Omnipool.

When setting up their order, users specify the amount of Asset A they would like to spend in order to obtain Asset B, as well as the frequency of the trades - in hours (approximation) or number of blocks (more granularity).

After placing the order, the HydraDX DCA pallet makes sure that trades are scheduled at the specified intervals until the predetermined amount of Asset A has been spent. Placing multiple DCA orders which are executed in parallel is supported.

Users can track the status of their orders on the UI. Open orders can at any time be terminated for the remaining amount.

Split Trade (easy DCA)

Split Trade is a more simple implementation of DCA directly into the main trade page. It provides users with a one-click solution for splitting larger orders in order to protect themselves from slippage.

When activated, Split Trade will split the order in smaller chunks until the size of the trades is small enough to achieve <0.1% slippage (estimate only - the exact slippage for future trades can never be predicted in advance).

Open Split Trade orders can be terminated by the user at any time, just like any regular DCA order.

- + \ No newline at end of file diff --git a/de/omnipool_design/index.html b/de/omnipool_design/index.html index c8508558..f74a2ed3 100644 --- a/de/omnipool_design/index.html +++ b/de/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool Design | HydraDX Docs - + @@ -46,7 +46,7 @@ c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).

- + \ No newline at end of file diff --git a/de/omnipool_hydrated_farms/index.html b/de/omnipool_hydrated_farms/index.html index a6468a53..5c2592c5 100644 --- a/de/omnipool_hydrated_farms/index.html +++ b/de/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ Hydrated Farms | HydraDX Docs - +

Hydrated Farms

Hydrated Farms are time-limited incentives programs which offer additional rewards for providing liquidity for selected assets, on top of the rewards from trading fees.

Departing from traditional liquidity mining programs, Hydrated Farms offer several distinctive features: they use Farm NFTs to represent the farm position, they support rewards stacking, and their rewards grow over time thanks to a loyalty multiplier.

On this page you will find further details on the features of Hydrated Farms. If you would like to participate, please visit our step-by-step guide on Hydrated Farms.

Farm NFTs

Whenever a user provides liquidity to the Omnipool and joins a Hydrated Farm, the HydraDX Protocol will mint an NFT which is owned by the user. This NFT represents the user position in the farm and stores certain details such as time of entry. This enables the Protocol to provide sustainable incentives with rewards which grow over time.

The owner of the farm NFT controls the position in the farm as well the underlying liquidity in the Omnipool. In the future, Protocol stakeholders may decide to open up a marketplace for Farm NFTs or enable their usage as collateral.

note

Due to the unique properties of the Farm NFTs, joining a given farm multiple times will yield several NFTs.

Rewards Stacking

Hydrated Farms support the possibility to offer rewards in more than one asset. In other words, rewards are stackable.

Any team can reach out to the HydraDX stakeholders with the request to create a Hydrated Farm incentivized by their own TKN. Following this example, the HydraDX governance can decide to also provide HDX as incentives to that farm. As a result, hydrated farmers would receive both HDX and TKN rewards.

Loyalty Multiplier

To encourage more sustainable liquidity provisioning, Hydrated Farms feature a loyalty multiplier - rewards grow over time as liquidity remains in the farm. You can view the exact curve for distributing rewards on the farm detail page.

Once users decide to leave a farm, their loyalty multiplier is reset and they will begin from the base level again if they decide to rejoin.

- + \ No newline at end of file diff --git a/de/omnipool_impermanent_loss/index.html b/de/omnipool_impermanent_loss/index.html index 8a398d60..209a7817 100644 --- a/de/omnipool_impermanent_loss/index.html +++ b/de/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ Less Impermanent Loss | HydraDX Docs - + - + \ No newline at end of file diff --git a/de/omnipool_lp/index.html b/de/omnipool_lp/index.html index c6dfd8ed..c06f8f81 100644 --- a/de/omnipool_lp/index.html +++ b/de/omnipool_lp/index.html @@ -4,13 +4,13 @@ Single-Sided LPing | HydraDX Docs - +

Single-Sided LPing

The cutting-edge design of the HydraDX Omnipool unlocks the possibility of single-sided liquidity provisioning: Anyone can provide liquidity only for the asset they want, and as much as they want (up to the respective TVL cap for the asset). This resolves one of the main drawbacks of standard XYK AMMs which require that liquidity providers (LPs) deposit a pair of assets in equivalent value.

Liquidity in the HydraDX Omnipool is concentrated, meaning that by providing your asset you gain instant exposure to all other assets in the Omnipool. Forget about liquidity fragmentation and the need to spread your liquidity across several trading pools.

The Hub Token LRNA

Single-sided liquidity provisioning is made possible by our hub token called Lerna (LRNA). Every time liquidity is added, the Omnipool will mint a corresponding amount of LRNA to keep the pool in balance. Accordingly, LRNA will be burnt to reflect any removal of liquidity. These mechanisms ensure that the value of LRNA does not significantly fluctuate when assets are added or removed from the Omnipool.

login

Another way to understand the hub token concept is to imagine every single asset within the Omnipool as a synthetic 50/50 liquidity pool, with the only difference being that the 2nd leg of the pair is always LRNA i.e. TKN:LRNA.

This design allows the Protocol to use LRNA as a proxy which reflects the value locked in the Omnipool, including trading activity and price fluctuations, in an abstract manner.

- + \ No newline at end of file diff --git a/de/omnipool_security/index.html b/de/omnipool_security/index.html index 8112b94f..395dae3e 100644 --- a/de/omnipool_security/index.html +++ b/de/omnipool_security/index.html @@ -4,13 +4,13 @@ State of the Art Security | HydraDX Docs - +

State of the Art Security

The HydraDX Protocol pursues a multi-layered security strategy. On this page you will find a description of the various measures which work together to keep your funds safe.

The most basic layer of the HydraDX security strategy consists carefully conducted research and development, as well as rigorous peer review processes. On top of that, HydraDX strives to have all mission-critical code undergo rigorous audits. The next layer of the security strategy is a generous bug bounty program which makes it worthwhile to find and disclose vulnerabilities (as opposed to exploiting them).

Finally, the protocol has implemented a combination of state-of-the-art measures which are designed to protect your liquidity against unfortunate events such as toxic assets or (economic) exploits.

Audits

The HydraDX protocol conducts audits of all mission-critical code and publishes the audit reports on a regular basis.

The security audit of the Rust implementation of the HydraDX Omnipool was performed by Runtime Verification - an established industry leader with clients such as NASA, Ethereum and Polkadot. The scope of the security audit includes the source code of HydraDX Omnipool pallet,its mathematical logic and asset registry, as well as 3rd party libraries which have been included as a (Substrate) dependency. The results of the audit were published in September 2022, you can consult the full report here.

In March 2022, the economic/math audit of the Omnipool was completed by BlockScience - a leading web3 native firm dedicated to analyzing complex systems for the likes of Graph Protocol and Protocol Labs (Filecoin). The scope of this audit was to provide an overview of the AMM specification with a special attention to the mathematical and economic concepts underpinning the Omnipool, together with the implications of those mechanisms for liquidity provisioning and trading activity. You can consult the full report here, including the addendum by HydraDX with post-factum changes.

Bug Bounty Program

HydraDX has set up a generous bug bounty program which provides strong incentives for the detection and responsible disclosure of bugs and other vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Mechanisms for Protecting Omnipool Liquidity

The HydraDX protocol is continuously researching and implementing mechanisms that keep the Omnipool liquidity safe. These mechanisms are activated in the unfortunate (but not impossible) scenario that an actor tries to drain liquidity from the Omnipool by abusing a toxic asset situation (LUNA-like scenario) or some malicious exploit.

TVL Caps

All assets are subject to a specific TVL cap defining the maximum proportion of liquidity which any given asset can represent in the Omnipool. Riskier assets will have lower caps compared to less risky (high mcap or stable) assets. This allows the HydraDX protocol to significantly limit the damage which may potentially be caused from toxic asset flows: Using a hyper-inflationary asset, attackers cannot drain more liquidity than its TVL cap.

Oracles

On-chain oracles provide average price information for a specified Omnipool asset during a given timeframe (e.g. 10 blocks). Oracles are an essential monitoring tool that allow the HydraDX protocol to detect irregularities and potential price manipulation attacks - and to act accordingly.

Dynamic Withdrawal Fees

To protect the Omnipool liquidity, all withdrawals of liquidity positions are subject to a fee. The withdrawal fee is dynamic, ranging between 0.01% and 1% of the total amount. The exact fee amount is determined at the time of withdrawal based on the asset in question.

The withdrawal fee covers the spread between the current spot price of the asset and the its average price over the previous 10 blocks (fetched from the HydraDX oracles). A large discrepancy between spot and average price indicates a potential price manipulation attack, and a higher withdrawal fee is applied to eliminate the economic incentives for carrying out such an attack.

In the scenario that extreme volatility leads to the spread between the spot price and average oracle price of an asset being greater than 1%, liquidity addition or withdrawal for that asset will be temporarily paused. These operations will again resume once this threshold is respected.

In-block Trade Limits

To protect the Omnipool against economic exploits, there is a limit in place that no more than 50% of an asset's liquidity can be traded in a single block - trades that are greater than this amount should be spread across multiple blocks.

Targeted Function Pausing

If some suspicious behaviour is detected on-chain, Targeted Function Pausing allows the HydraDX Technical Committee to take swift action and temporarily pause certain or all actions relating to specific assets. This action of last resort can help mitigate the damage and allow for further investigation.

- + \ No newline at end of file diff --git a/de/omnipool_trading/index.html b/de/omnipool_trading/index.html index d1cd369e..44675a1b 100644 --- a/de/omnipool_trading/index.html +++ b/de/omnipool_trading/index.html @@ -4,13 +4,13 @@ Efficient Trading | HydraDX Docs - +

Efficient Trading

The traditional DeFi landscape is characterised by fragmented liquidity which is dispersed across several trading pools. This leads to economic inefficiencies: More hops and shallower liquidity create higher price impact and slippage. By combining all liquidity in a single trading pool, the HydraDX Omnipool enables efficient trading like no other AMM.

Traditional AMMs: Liquidity Fragmentation

The pioneer XYK AMM model marked a pivotal moment for DeFi which made decentralized and permissionless trading possible. The simplicity of XYK pools boosted the initial adoption of DeFi, however today we stand at a point where the resulting economic inefficiencies hinder the continued adoption.

Omnipool

One of the flaws of the XYK model is that trading pools are constrained to pairs of assets. Fragmented liquidity results in a higher price impact due to more hops and slippage. The route of the ETH-AAVE trade in the screenshot above provides a practical example:

  • 85% direct from ETH to AAVE (incurring 0.3% fee);
  • 15% ETH traded for UNI first then the UNI is swapped for AAVE (incurring two 0.3% swap fees).

HydraDX Omnipool: Unified Liquidity

Thanks to the cutting-edge design, liquidity in the Omnipool truly acts as one. By having all the liquidity connected through LRNA, the assets within the Omnipool have direct access to the entirety of liquidity for any other asset that is also deposited into the Omnipool. This allows for a seamless on-chain execution and enables swaps to be completed in a single transaction with no hopping required between various isolated trading pools.

Furthermore, based on internal research, the increase in the number of tokens and total value locked (TVL) within the Omnipool lead to exponential improvements in slippage reduction.

login

To illustrate with an example, imagine the TKN asset is distributed across 4 different liquidity pools with varying levels of liquidity. In the scenario that a trader wants to trade DAI for TKN, they would only have access to the direct liquidity of the $1M TKN-DAI pool. If their trade size is substantial (e.g. $100K+), the majority of the trade will likely be routed through a DAI-ETH pool followed by the TKN-ETH pool in the traditional XYK landscape.

However, with the Omnipool, that same $5mm (50% of the total $10mm TVL) of the TKN asset and $3mm of DAI would be concentrated in one pool. As such, if a trader proceeds to make the same trade in the HydraDX Omnipool, they will get the entire benefit of the $5mm of TKN and $3mm of DAI liquidity in their direct swap, materially reducing the overall price impact.

- + \ No newline at end of file diff --git a/de/omnipool_treasuries/index.html b/de/omnipool_treasuries/index.html index f9a5149f..458577be 100644 --- a/de/omnipool_treasuries/index.html +++ b/de/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ Hydrate Your Treasury (B2B) | HydraDX Docs - +

Hydrate Your Treasury (B2B)

The HydraDX Omnipool has an outspoken value proposition for the treasury of any project or DAO. Forget about centralized market makers and inflationary rewards for liquidity mining; the Omnipool can facilitate the creation of a market for your token in a cost-efficient manner - trustless, without hidden costs and while building up your POL from trading fees.

Thanks to its cutting-edge design, the HydraDX Omnipool supports single-sided LPing. Instead of wastefully allocating liquidity mining rewards to incentivize other users to provide liquidity, projects and DAOs can deposit a part of their treasury to the Omnipool and receive instant exposure to all other assets in an ocean of liquidity: Diversified and deep (HydraDX has $20M+ worth of POL which is gradually being deployed).

LPing in the HydraDX Omnipool is truly trustless. Leveraging Polkadot’s unique capability of cross-chain communication (XCM), the Omnipool empowers you to always remain in control of your funds: You can both provide your liquidity and manage it without relying on third parties.

Providing liquidity to the HydraDX Omnipool is not only cost-efficient - it is also profitable. Instead of having your tokens sit idle in your treasury, you can put them to work. You will earn rewards from trading fees, allowing you to build up POL over time. Soon, our upcoming TWAMM/DCA feature will allow you diversify the accumulated POL in other assets (e.g. dollar cost averaged stablecoins or DOT which you can use to bid on your next parachain slot).

Finally, the HydraDX Omnipool enjoys state of the art security. Besides rigorous audits and a generous bug bounty program, we have set up a combination of measures which work together to keep your liquidity safe. Learn more here.

- + \ No newline at end of file diff --git a/de/participate_in_council_elections/index.html b/de/participate_in_council_elections/index.html index 597e075d..7b035a54 100644 --- a/de/participate_in_council_elections/index.html +++ b/de/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ Teilnahme an Ratswahlen | HydraDX Docs - +

Teilnahme an Ratswahlen

Dieser Artikel enthält eine Schritt-für-Schritt-Anleitung zur Teilnahme an Ratswahlen - für die Wahl von Ratsmitgliedern und für die Aufnahme als Ratskandidat.

Wenn Sie daran interessiert sind, wie der Wahlmechanismus funktioniert, lesen Sie bitte diesen Beitrag.

caution

Das HydraDX-Demokratiemodul wird am oder nach dem 15. September 2021 eingeführt. Bitte versuchen Sie vor diesem Datum keine der angezeigten Aktionen.

Verwundung von Polkadot/apps

Abstimmung bei den Wahlen zu den Ratsmitgliedern

Die aktuellen Ratsmitglieder sowie die Zweitplatzierten sind auf der Seite Governance > Council page in Polkadot/apps zu sehen.

Um Ihre Stimme für die Ratsmitglieder herauszubringen, klicken Sie auf Vote.

Geben Sie die Anzahl der Token ein, die Sie zur Unterstützung Ihrer Kandidaten sperren möchten.

Wählen Sie anschließend Ihre Kandidaten in der Reihenfolge ihrer Präferenz aus, indem Sie sie von der linken Liste in die rechte Liste verschieben. Denken Sie daran, mehrere Kandidaten auszuwählen - dies hilft dem Algorithmus, die optimale Verteilung der Kandidaten an den Rat auszuwählen.

Um Ihre Stimme herauszubringen, klicken Sie auf Vote und unterschreiben Sie die Transaktion.

note

Gesperrte Token können nicht übertragen werden, sie können jedoch weiterhin zum Abstecken und zur Abstimmung in Volksabstimmungen verwendet werden. Ihre Token bleiben erhalten und werden für nachfolgende Wahlen verwendet, bis Sie sich entschieden haben, sie freizuschalten.

Bewerben Sie sich als Ratskandidat

Sie können Ihren Antrag auf Mitgliedschaft im Rat einreichen, indem Sie zu Governance > Council in Polkadot/apps navigieren.

Klicken Sie auf Submit candidacy, um ein Popup-Fenster auszulösen.

Wählen Sie das Konto aus, das für die Mitgliedschaft im Council läuft, klicken Sie auf Submit und unterschreiben Sie die Transaktion.

- + \ No newline at end of file diff --git a/de/participate_in_referenda/index.html b/de/participate_in_referenda/index.html index 82a7b50c..73b10ca0 100644 --- a/de/participate_in_referenda/index.html +++ b/de/participate_in_referenda/index.html @@ -4,7 +4,7 @@ Teilnahme an Referenda | HydraDX Docs - + @@ -13,7 +13,7 @@ (/democracy_referenda#referenda-votes-weighing) mitbestimmt.

Bringen Sie anschließend Ihre Stimme mit einem Klick auf Vote Nay (No) or Vote Aye (Yes) * heraus und unterschreiben Sie die Transaktion.

Referendum vorschlagen

Der Vorschlag eines Referendums über Polkadot/Apps besteht aus zwei Schritten – dem Einreichen eines Vorabbilds und dem Einreichen des Vorschlags in der Kette.

01 Vorabbild senden

Um das Preimage einzureichen, besuchen Sie Polkadot/Apps und navigieren Sie zu Governance > Democracy.

Nachdem Sie auf Submit preimage geklickt haben, sollten Sie das folgende Popup sehen:

Füllen Sie die Informationen in den oben angezeigten Feldern aus. Die wichtigsten Parameter sind:

  • Konto, von dem das Angebot gesendet wird
  • Angebotsbereich
  • Vorgeschlagene Maßnahmen

Im obigen Beispiel lautet der Angebotsbereich balances und die Aktion forceTransfer von Token von einem Konto auf ein anderes.

Bevor Sie das Preimage einreichen und die Transaktion unterzeichnen, kopieren Sie bitte den Preimage-Hash. Sie benötigen es für den nächsten Schritt.

02 Vorschlag einreichen

Um den Referendumsvorschlag einzureichen, besuchen Sie Governance > Democracy in Polkadot/apps.

Nachdem Sie auf Submit proposal geklickt haben, sollten Sie das folgende Popup sehen:

Geben Sie den Preimage-Hash aus dem vorherigen Schritt und die Anzahl der Token ein, die Sie für das Angebot hinterlegen möchten. Das Minimum ist 100.000 HDX.

Nachdem Sie den Vorschlag in der Kette eingereicht und die Transaktion unterzeichnet haben, sollte Ihr Vorschlag in der Liste der vorgeschlagenen Referenden erscheinen.

caution

In jeder Abstimmungsperiode geht der Referendumsvorschlag mit der höchsten Unterstützung (Seconding) in die Abstimmungsrunde. Da die Zahl der Referenden zunimmt, gibt es keine Garantie dafür, dass Ihr Vorschlag jemals genügend Abordnungen erhält, um an der Abstimmung teilzunehmen. Es gibt keine Möglichkeit, einen Referendumsvorschlag zurückzuziehen, was bedeutet, dass Ihre Gelder möglicherweise für einen längeren Zeitraum gesperrt bleiben.

Böswillige Referendumsvorschläge werden bestraft. Der HydraDX-Rat und das Technische Komitee haben das Recht, ein bösgläubiges Referendum abzubrechen. Infolgedessen werden die hinterlegten Token verbrannt.

- + \ No newline at end of file diff --git a/de/performance_benchmark/index.html b/de/performance_benchmark/index.html index 5d08e1ab..9bc61760 100644 --- a/de/performance_benchmark/index.html +++ b/de/performance_benchmark/index.html @@ -4,7 +4,7 @@ Leistungs-Benchmark | HydraDX Docs - + @@ -13,7 +13,7 @@ Nutzen Sie hierfür Folgenden Befehl:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Prepare for running the benchmark
## Install Rust following https://rustup.rs
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

## Configure Rust
$ ./scripts/init.sh
$ rustup default nightly

## Install additional libraries
$ apt install python3-pip
$ apt install clang

# Run the benchmark
$ ./scripts/check_performance.sh

Nachdem Ihr Benchmark ausgeführt wurde sollte ihre Ausgabe ähnlich zu folgedem sein:

         Pallet          |   Time comparison (µs)    |  diff* (µs)   |   diff* (%)    |            |   Rerun
amm | 773.00 vs 680.00 | 93.00 | 12.03 | OK |
exchange | 804.00 vs 720.00 | 84.00 | 10.44 | OK |
transaction_multi_payment| 218.00 vs 198.00 | 20.00 | 9.17 | OK |

Notes:
- in the diff fields you can see the difference between the reference benchmark time and the benchmark time of your machine
- if diff is positive for all three pallets, your machine covers the minimum requirements for running a HydraDX node
- if diff deviates by -10% or more for some of the pallets, your machine might not be suitable to run a node

Sie können die Unterschiede in der Leistungsfähigkeit zwischen Ihrem Server und den Mindestanforderungen in der diff* (%)-Spalte sehen. Wenn alle drei Werte positiv sind sollte Ihr Server in der Lage sein eine HydraDX Validator Node zu betreiben. Wenn einer der Werte niedriger als -10 % ist empfehlen wir Ihnen vom Betreiben eines Validators auf diesem Server abzusehen.

Sie können gerne unserem Discord Channel beitreten wenn sie Ihre Benchmark Ergebnisse diskutieren wollen oder Hilfe brauchen. Unsere Community hilft Ihnen gerne!

- + \ No newline at end of file diff --git a/de/polkadotjs_apps_local/index.html b/de/polkadotjs_apps_local/index.html index 1980ebfd..94012ccb 100644 --- a/de/polkadotjs_apps_local/index.html +++ b/de/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ Mit einer lokalen Node verbinden | HydraDX Docs - +

Mit einer lokalen Node verbinden

Sie können Polkadot/apps verwenden um sich mit ihrem Lokalen HydraDX Node zu verbinden. Dafür ist es nötig Zugang zum Port 9944zu haben, welcher für RPC Websocket verbindungen verwendet wird.

danger

Wenn Sie den Node als Validator verwenden, empfehlen wir den Port 9944auf die Blacklist für Remote Zugriffe zu setzen. Dieser Port könnte sonst von Dritten dafür verwendet werden die Performance Ihres Nodes einzuschränken, was wiederum in Slashing oder unbeabsichtigen Verlust von Krypto führen könnte. Sie sollten den Port 9944 nur dann zum Verbinden zu Ihrem Node verwenden wenn dieser in Ihrem Lokalen Netzwerk ist.

Über Polkadot/apps mit einer lokalen Node verbinden

Um auf Ihren Node zuzugreifen öffnen SiePolkadot/apps und klicken Sie in die obere linke Ecke um das Netzwerk zu wechseln.

Nachdem das Menü sich öffnet klicken sie auf Development und wählen sie Local node.

Passen Sie die IP wenn nötig an und klicken Sie auf Switch um zu Ihrer lokalen Node zu wechseln.

Jetzt sollten Sie mit Ihrer lokalen Node verbunden sein und können nun darauf zugreifen.

- + \ No newline at end of file diff --git a/de/polkadotjs_apps_public/index.html b/de/polkadotjs_apps_public/index.html index c6f20c9d..650261c4 100644 --- a/de/polkadotjs_apps_public/index.html +++ b/de/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ Mit einer öffentlichen Node verbinden | HydraDX Docs - +

Mit einer öffentlichen Node verbinden

Es gibt zwei Öffentliche RPC Nodes die von HydraDX und unseren Partnern unterhalten werden. Diese können von Ihnen verwendet werden um mit dem Snakenet zu interagieren. Sie können sich direkt mit einem der öffentlichen Nodes verbinden indem Sie auf die unten angeführten Links klicken:

Manuell mit einer RPC Node verbinden

Um einen öffentlichen RPC Node manuell zuzugreifen, öffnen Sie die Polkadot/apps und klicken Sie in die obere linke Ecke um das Netzwerk zu wechseln.

Klicken sie auf LIVE NETWORKS und wählen Sie HydraDX.

Wählen Sie einen der Nodes aus und klicken sie auf Switch.

Nun sollten sie mit dem von Ihnen ausgewählten öffentlichen Node verbunden sein.

- + \ No newline at end of file diff --git a/de/spending_fw/index.html b/de/spending_fw/index.html index 1643bc63..9ec13c27 100644 --- a/de/spending_fw/index.html +++ b/de/spending_fw/index.html @@ -4,13 +4,13 @@ Contribute to HydraDX | HydraDX Docs - +

Rewarding Contributions to HydraDX

HydraDX welcomes various contributions which are in the interest of the Protocol. Such activities are incentivized with the help of rewards from the HydraDX Treasury.

The present document sets out the general framework for rewarding community contributions. This framework has been approved by the community of HydraDX in a general vote. The spending framework empowers payouts in the mentioned categories by the HydraDX Council, within the defined limits.

Please note in advance that the payout of all bounties and tips mentioned in this document is subject to the full discretion of the HydraDX Council. If you are in doubt whether your effort entitles you to a bounty, please reach out in advance.

You can ask questions in #bounties on the HydraDX Discord.

1. Bug Bounties

HydraDX runs a Bug Bounty program on Immunefi. Bugs and vulnerabilities are classified into three to four categories of severity which determine the maximum size of the bounty:

Blockchain:

  • Critical: $50,000 to $1,000,000;
  • High: $5,000 to $50,000;
  • Medium: $5,000;
  • Low: $1,000.

Websites & Apps:

  • Critical: $5,000 to $50,000;
  • High: $5,000;
  • Medium: $1,000.

Notes:

  • In order to be granted a bounty, bug reports must be made in accordance with the procedure for responsible disclosure and any other guideline posted on the HydraDX Immunefi page;
  • Bounties for critical Blockchain vulnerabilities are capped at 10% of the potential economic damage;
  • The actual size of the rewarded bounties is at the discretion of the Council;
  • Bounties are paid by the treasury in HDX using the 7d MA USD price from an exchange (CEX or DEX once Oracles are available - if in doubt, please discuss with the HydraDX Council in #bounties).

2. Development Bounties

The HydraDX development team will be launching a dashboard with development bounties in an effort to decentralize technical work on the protocol. The dashboard will present the latest bounties together with a description, technical specification and size of the bounty.

The present framework authorizes the HydraDX Council to propose development bounties of up to $100,000 which will be paid by the Treasury in HDX using the 7d MA USD price from an exchange. Bounties exceeding this amount still need to undergo the governance process.

3. Community Management

Efforts spent on Community Management can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange).

New community managers are subject to prior approval by the team.

Here are some of the expectations attached to these roles:

  • Moderate on both Telegram and Discord;
  • Be an ambassador for the project;
  • Show activity on socials;
  • Participate in bi-weekly calls with other community managers;
  • Coordinate translations
  • Ideally already an active member of the Hydra community.

4. Translations

Work on translations can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange). Currently, HydraDX welcomes translations in the following languages (this list can be extended via a referendum):

  • Mandarin
  • Spanish
  • Russian
  • Slovak

New translators are subject to prior approval by the Community Managers and/or HydraDX Council.

5. Other Community Contributions

Are you looking to contribute with an effort which does not fall into one of the categories above? Please feel free to reach out, the HydraDX Council is prepared to consider your case. This spending framework authorizes the HydraDX Council to provide tips up to the value of $100,000 (using the 7d MA USD price from an exchange).

Here are some examples of contributions that could be rewarded:

  • Creating good educational content such as guides, explanative blogs or videos [content creator should liaise with Community Managers & HydraDX Council ahead of and during production process to ensure information is of the highest quality];
  • Provisioning Decentralized infrastructure;
  • Advancing integrations which contribute to the Protocol or the community;
  • Memes (!!), emojis, merch and stickers.
- + \ No newline at end of file diff --git a/de/staking/index.html b/de/staking/index.html index ccf02058..7f04b2a4 100644 --- a/de/staking/index.html +++ b/de/staking/index.html @@ -4,13 +4,13 @@ Staking | HydraDX Docs - +

Staking

HydraDX has a long-running HDX staking program which incentivizes user activity in areas that are beneficial to the Protocol. On this page you will find important information regarding the mechanics behind the HDX Staking program. You can also check out our step-by-step guide on staking.

Staking Basics

HDX holders can stake their HDX and receive rewards which become claimable as time passes. Staking rewards are distributed from a dedicated pot that is gradually filled up by different Protocol revenue streams. Initially, the main revenue stream are the LP fees which the HydraDX Protocol accrues from its HDX LP position in the Omnipool. Furthermore, the HydraDX community has approved a proposal to support the APR during the first year of the staking program with an additional subsidy of ~22M HDX from the HydraDX Treasury which is gradually distributed to the staking rewards pot once per day.

Rewards which enter the staking pot are always distributed directly to all stakers at any given moment. The amount that users are entitled to is proportional to the relative size of their stake in the stake pool. However, stakers do not automatically receive the rewards on their account - instead, they need to claim them.

When it comes to claiming rewards, all participants in HDX staking should be aware of the elements of loyalty and gamification. Once rewards are awarded, they cannot be instantly claimed for the full amount - doing so would yield just a fraction of the total rewards, with the remainder being returned the pot for redistribution to all stakers.

Users who want to claim as many rewards as possible should keep their HDX staked without claiming until sufficient time has passed (rewards are “vested” following a bonding curve). The length of the waiting period is dynamic and depends on the user (in)actions. A user who just stakes passively would need to wait ~2 years to claim 95% of their rewards. In contrast, active stakers who collect the maximum amount of action points (more on that below) could claim 95% of their rewards in just over 2 months. These are rough estimates - the actual timelines may vary in accordance with user actions and overall count of referenda.

Boosting Your Rewards

Stakers can increase the pace at which they can claim their rewards by collecting action points and boosting their rewards. Action points can be acquired by performing certain actions that are incentivized by the Protocol. Initially, the only way to collect action points is to participate in the governance of HydraDX by voting on community referenda using the staked HDX.

login

There are 2 factors which determine the amount of action points that stakers will receive: The size of the vote (relative to the total size of their staked HDX), and the conviction multiplier. The higher the conviction multiplier of the vote, the greater its weight. Keep in mind that voting with a conviction multiplier places a temporary lock on the tokens. Stakers looking to achieve the highest rewards boost would be voting with 6x conviction multiplier, thereby locking their HDX for 192 days (counted from the last vote using such conviction). Just a reminder that this lock is not related to staking as such - instead, it is a standard feature of governance in the Polkadot ecosystem (more info in our docs).

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d

Claiming Your Rewards

As they keep their HDX staked, users accumulate rewards over time. These rewards become claimable subject to a bonding curve which is influenced by the boosts from action points (see above).

At any given time, stakers can claim (a portion of) their claimable rewards. By doing so, however, they forfeit the remainder of their non-claimable rewards. These rewards are automatically transferred back to the staking rewards pot which redistributes them to all other stakers. Furthermore, claiming resets the past action points of the user, sending users back to the beginning of the bonding curve for future rewards from staking.

This mechanism creates an interesting gamification dynamic: By remaining longer in the pool of stakers, users not only unlock a greater part of their allocated rewards - they also have the chance to receive a juicy portion of rewards from other stakers who claim or exit early.

Happy staking!

- + \ No newline at end of file diff --git a/de/testnet_howto/index.html b/de/testnet_howto/index.html index ef838d23..73839760 100644 --- a/de/testnet_howto/index.html +++ b/de/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/de/tip_request/index.html b/de/tip_request/index.html index 7531af4c..cf2d3dcb 100644 --- a/de/tip_request/index.html +++ b/de/tip_request/index.html @@ -4,13 +4,13 @@ Die Anfrage vom Finanzministerium | HydraDX Docs - +

Die Anfrage vom Finanzministerium

Mit der Einführung des HydraDX New Deal-Incentive-Programms können Community-Mitglieder HDX-Tipps vom Finanzministerium als Belohnung für ihre Beiträge anfordern. Dieser Leitfaden führt Sie durch den Prozess der Trinkgeldanfragen. Weitere Informationen zu den verschiedenen Arten von Aktivitäten, die belohnt werden, finden Sie in diesem Beitrag.

Das Anfordern eines Treasury-Tipps besteht aus zwei Schritten. Im ersten Schritt müssen Beitragende ihre Tipp-Anfrage in Commonwealth.im mit einer Beschreibung des Beitrags veröffentlichen. Als zweiter Schritt muss die Treasury-Tipp-Anfrage mithilfe von Polkadot/Apps on-chain eingereicht werden.

01 Veröffentlichung der Trinkgeldanfrage in Commonwealth.im

Um die Transparenz zu gewährleisten, müssen alle Treasury-Tipp-Anfragen in einem Thread auf der [HydraDX Commonwealth-Seite] (https://commonwealth.im/hydradx) veröffentlicht werden. Bevor Sie einen Thread öffnen, müssen Sie Ihre HydraDX-Brieftasche mit Commonwealth.im verknüpfen: Klick Log in (obere rechte Ecke) und wähl Connect with wallet > polkadot-js.

login

Nachdem Sie im Popup Ihre HDX-Adresse ausgewählt haben, werden Sie aufgefordert, die Nachricht mit Ihrem Wallet zu signieren und einen Anzeigenamen für dieses Wallet festzulegen.

Nachdem Sie sich eingeloggt haben, müssen Sie einen neuen Thread für Ihre Trinkgeldanfrage erstellen. Navigieren Sie zum oberen rechten Teil der Seite und klicken Sie auf New thread > New thread. Sie können auch direkt diesen Link verwenden: https://commonwealth.im/hydradx/new/thread.

Sie können den Titel des Threads verwenden, um das Thema (Tippanfrage) und das Thema des Beitrags anzugeben. Geben Sie im Hauptteil des Threads bitte die folgenden Informationen an:

  • Zeitraum, in dem der Beitrag geleistet wurde
  • Eine kurze Zusammenfassung des Beitrags
  • Die Höhe des angeforderten Trinkgelds (in HDX)
  • Zeitaufwand für den Beitrag (in Stunden)
  • Bei Bedarf eine genauere Beschreibung einschließlich der Relevanz des Beitrags zu HydraDX
  • Geben Sie ggf. weitere Informationen an, z. B. die Relevanz des Beitrags zu HydraDX und einen Link zur PR (bei technischen Beiträgen)

Als Referenz können Sie einen Blick auf [diese Beispiel-Tipp-Anfrage] (https://commonwealth.im/hydradx/proposal/discussion/1165-tip-request-add-documentation-for-staking) werfen.

Nachdem Sie die Informationen ausgefüllt haben, posten Sie den Thread und er sollte in der allgemeinen Liste verfügbar sein.

note

Nominatoren und Validatoren, die ihr HDX überschuldet haben und „steckengeblieben“ sind, können ein Treasury-Tipp von 1 HDX anfordern, das es ihnen ermöglicht, einige ihrer Token aufzulösen. Wenn dies auf Ihren Fall zutrifft, erstellen Sie bitte einen Commonwealth-Thread nach diesem Beispiel.

02 Senden der Tippanforderung On-Chain

Nachdem Sie Ihre Treasury-Tipp-Anfrage veröffentlicht haben, müssen Sie sie in der Kette einreichen. Zu diesem Zweck muss Ihr Wallet eine kleine Menge HDX enthalten, um die Transaktionsgebühren zu decken. Wenn Sie derzeit kein HDX besitzen, müssen Sie diesen Schritt nicht ausführen – jemand anderes wird Ihre Trinkgeldanforderung für Sie in der Kette einreichen.

Treasury-Tipp-Anfragen können mit Polkadot / Apps über den folgenden Link in der Kette eingereicht werden: https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/treasury/tips.

Um eine neue Trinkgeldanfrage zu stellen, klicken Sie auf Propose tip und geben Sie die folgenden Informationen ein:

  • submit with account - wählen Sie das Konto aus, das die Transaktion zum Senden der Trinkgeldanforderung in der Kette unterschreibt. Dieses Konto muss eine kleine Menge HDX für Transaktionskosten halten.
  • beneficiary - wählen oder geben Sie die Adresse des Kontos ein, das den Treasury-Tipp erhält. Dieses Konto muss dem Konto entsprechen, das den Commonwealth-Thread eröffnet hat.
  • tip reason - geben Sie eine URL zum Commonwealth-Thread an.
login

Um die Trinkgeldanfrage zu senden, klicken Sie auf Propose tip und unterschreiben Sie die Transaktion.

Sobald die Transaktion bestätigt ist, sollten Sie die Trinkgeldanfrage auf der Übersichtsseite sehen.

login
- + \ No newline at end of file diff --git a/de/tokenomics/index.html b/de/tokenomics/index.html index 5847f47c..5679d0e5 100644 --- a/de/tokenomics/index.html +++ b/de/tokenomics/index.html @@ -4,13 +4,13 @@ HDX Tokenomics | HydraDX Docs - +

HDX Tokenomics

Purpose

The HDX token is a governance token that allows staked token holders to decide the future of the protocol. Our mission with the HydraDX DAO is to distribute all decision-making to create a trustless liquidity protocol built around community-growth and self-sustainability.

To have a vote in the HydraDX DAO, and to contribute to the determination of any of the topics raised by community members, one must hold the HDX governance token. For more specifically on the governance process, please read our Democracy documentation.

HDX will initially be used for the following:

  • Setting the base network swap fee (the user may change this to any asset)
  • Voting on protocol upgrades
  • Voting on topics raised by community members (inclusive of allocation of Protocol-Owned Liquidity)

HDX Token Allocation

Upon the launch of the HydraDX DAO, the defined maximum supply of HDX tokens was 10 billion HDX. However through the governance-approved supply reduction, this defined maximum supply was reduced to 6.5 billion HDX tokens.

The allocation of these tokens is currently as follows:

  • LBP Participants - 30.5% (~1.983B)
  • Founders and team - 12.5% (810M)
  • Investors - 10.6% (690M)
  • HDX Crowdloan - 7.6% (~494.6M)
  • BSX Crowdloan - 1.9% (~120.7M)
  • DAO treasury - 5.5% (~354.5M)
  • Collators - 3.9% (~251.5M)
  • Growth - 27.6% (~1.796B)

HDX Emission Schedule

As of Sept 2023, ~2.6 billion of HDX tokens are in circulation.

There is currently no concrete emission/release schedule for HDX tokens residing in the Treasury and Growth allocations. HydraDX intends to distribute the supply of HDX in the treasury and growth funds to help fund ecosystem development where opportunities may arise. All of these distributions will be discussed transparently to the community beforehand and voted on by the HydraDX DAO.

Token distributions range from a variety of developmental purposes and growth initiatives, (eg. HDX bonds, liquidity provider rewards, integrations/partnerships with other projects, etc).

- + \ No newline at end of file diff --git a/democracy_council/index.html b/democracy_council/index.html index 15987663..44e7d42b 100644 --- a/democracy_council/index.html +++ b/democracy_council/index.html @@ -4,13 +4,13 @@ HydraDX Council | HydraDX Docs - +

HydraDX Council

The HydraDX Council is an on-chain entity which plays a key role in the governance of the protocol. This article provides information on the composition of the Council, its main tasks, and the election of Council members.

For step-by-step guidance on how to participate in Council elections, please refer to this guide.

Composition

The HydraDX Council currently consists of 13 members.

A minority share of 6 seats is reserved for the founding team and the investors (4 founders + 2 investors).

The remaining 7 seats are elected by the wider community of HDX holders.

Tasks and Responsibilities

The tasks of the HydraDX Council cover a wide range of day-to-day governance activities. To begin with, the Council controls the Treasury and approves or rejects Treasury proposals.

The HydraDX Council also plays a role in the referendum mechanism. The Council can initiate a referendum, provided that at least 60% of the members support this (super-majority) and no member exercises a veto. In the case of a veto, the proposal can be resubmitted after the cool-down period has lapsed. The vetoing member cannot veto the same proposal twice.

Furthermore, any proposed referendum can be cancelled with a 2/3 super-majority of the Council votes. This can be used as a last-resort measure to stop malicious proposals or changes which could introduce bugs in the code.

Finally, the HydraDX Council is responsible for electing the Technical Committee.

Elections

Any holder of HDX tokens can apply for one of the 7 non-permanent sets of the HydraDX Council as a candidate.

The Council elections take place every 7 days, at which point an algorithm fills the 7 non-permanent Council seats for the duration of the following 7 days. The democracy module uses the same Phragmen algorithm which is used to elect the active set of validators on the Polkadot Relay Chain.

All community members can vote in the Council elections by locking a certain amount of HDX tokens of their choice. Locked tokens are not available for transfer and will be used in the follow-up elections (until cancelled). Voters can and should select more than one candidate in order of preference. The election algorithm then distributes all votes to determine the optimal allocation of the available Council seats to the candidates with the highest community backing.

- + \ No newline at end of file diff --git a/democracy_intro/index.html b/democracy_intro/index.html index e55b460d..15713f4c 100644 --- a/democracy_intro/index.html +++ b/democracy_intro/index.html @@ -4,13 +4,13 @@ Introduction | HydraDX Docs - +

Introduction

HydraDX is in the process of fully decentralizing its governance. All decisions which affect the protocol are adopted following a democratic process which is supported by the Substrate democracy module. The central mechanism for establishing consensus among the stakeholders is the referendum.

This section contains a series of knowledge articles which should provide you with a better understanding of the mechanisms behind the governance of HydraDX. You will find more information on how referenda work, as well as on the two central groups of governance actors: the HydraDX Council and the Technical Committee.

If you are looking for practical guidance on how to participate in the governance of HydraDX, please refer to the step-by-step guides on participating in referenda and participating in Council elections.

Democracy parameters

The list below contains the most important parameters which influence the governance mechanism on HydraDX. Please note that these may change over time.

  • Minimum HDX deposit for initiating a referendum: 10 000 HDX
  • Referendum enactment period: 6 days
  • Referendum voting period: 3 days
  • Emergency referendum voting period: 3 hours
  • Cooloff period after a referendum has been rejected: 7 days
  • Maximum pending referendum proposals: 100
- + \ No newline at end of file diff --git a/democracy_referenda/index.html b/democracy_referenda/index.html index be416fe5..95d40dc6 100644 --- a/democracy_referenda/index.html +++ b/democracy_referenda/index.html @@ -4,13 +4,13 @@ Referenda | HydraDX Docs - +

Referenda

Referenda allow stakeholders to put a proposal to a weighted, stake-based vote by the wider community. The object of the referendum is some suggested action which affects the protocol - for example, a Treasury payout, or even a change in the runtime code.

Generally speaking, only one referendum is brought to a vote at a time. Other pending referendum proposals are put in a queue. There are separate queues for publicly submitted proposals and for Council proposals. Every 3 days, the referendum mechanism picks the top proposal with the highest amount of support, alternating between the two queues. After a referendum has been voted upon and accepted, there is a so-called enactment delay period of 3 days which needs to pass before the decision is put into effect. An exception to these rules applies for emergency proposals by the Technical Committee which deal with major protocol problems and need to be fast-tracked.

Initiating a Referendum

There are multiple ways to initiate a referendum which are described in greater detail below. The way the referendum was initiated is decisive for the applicable voting mode.

Public Referendum

Any holder of HDX tokens can propose a referendum by depositing the minimum required amount of HDX tokens and submitting the proposal on-chain. Other community members can support (second) the proposal for a referendum by locking up an equal amount of tokens. At the beginning of every voting cycle, the referendum proposal with the highest amount of seconding (total deposited tokens) is advanced to a vote by the community.

The voting mode which applies to public referenda is Positive Turnout Bias.

note

All HDX tokens which are deposited to propose or second a referendum are locked up for the whole period until the referendum has entered the voting cycle. It is important to remember that there is no guarantee that any given proposal will ever receive sufficient backing to move into the voting round, meaning that your funds might remain locked for an indefinite period.

Council Referendum

The HydraDX Council has the powers to propose a referendum for a community vote. If it does so unanimously, the applicable voting mode for the referendum is Negative Turnout Bias. If the referendum is proposed with a simple majority of the Council votes, then the voting mode for accepting the proposals by the community is Simple Majority.

Emergency Proposals by the Technical Committee

The Technical Committee can submit emergency proposals which deal with (critical) bug fixes or the quick adoption of battle-tested functionality. Emergency proposals skip the waiting queue and enter the voting round directly. The community can vote on emergency proposals in parallel to any regular proposal which has entered the voting round. Furthermore, emergency proposals have a shorter voting period to ensure that they can be fast-tracked.

Canceling a Referendum

Once a referendum has been proposed, it cannot be revoked until it has entered the voting round. An exception to this rule is made for proposals which are deemed detrimental to the protocol (e.g. code changes introducing a bug). In this limited case, the referendum proposal can be cancelled by the HydraDX Council (with a 60% super-majority) or the Technical Committee (unanimously). All tokens wich were locked by supporters seconding the proposal are burned.

Voting in a Referendum

HydraDX referenda have a launch period of 3 days. At the beginning of every new period, the proposal with the highest amount of seconding is taken from the waiting queue and put into a voting round. Every voting round has a duration of 3 days. During this period, community members can vote on the referendum using a weighted, stake-base mechanism. They do so by locking up a certain amount of HDX tokens for a given timeframe.

note

Locked HDX tokens cannot be transferred for the duration of the chosen lock period. However, they can still be used for voting.

Votes Weighing

There are two factors which determine the weight of each vote in a referendum. The first factor is the amount of HDX tokens which the voter locks up in support of the vote. The second factor is the so-called conviction multiplier which reflects the duration for which the voter is willing to lock up the tokens.

vote_weight = tokens * conviction_multiplier

The table below contains an overview of the various Conviction Multipliers and the amount of days the tokens will be locked up for. It is possible to bring out a vote without locking your HDX, however its weight would be only a fraction (conviction multiplier of 0.1x). As shown in the table below, locking the tokens for the maximum of 192d would raise the conviction multiplier to 6x.

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d
An example:

Alice votes with 5000 HDX and 0.1x Conviction Multiplier.
Bob votes with 100 HDX and 6x Conviction Multiplier.

Weight Alice: 500
Weight Bob: 600

Token lock Alice: 0 days
Token lock Bob: 192 days

Voting Modes

Another important aspect of the democracy module are the different voting modes which apply. The threshold of votes needed for approving or rejecting a referendum can vary depending on how the referendum was initiated and on the turnout of the vote. The turnout is calculated based on the total amount of HDX tokens which were used to vote in the referendum (conviction multipliers excluded). Whether the turnout was low or not is determined by the relationship between the turnout and the elactorate (i.e. the total amount of HDX tokens eligible to vote).

Positive Turnout Bias

This is the default voting mode when a referendum is proposed by the Community. At lower turnouts, a qualified super-majority of yes votes is required in order to approve the referendum. As the turnout grows, the threshold decreases towards a simple majority.

Negative Turnout Bias

This voting mode applies to referenda which have been proposed by the Council unanimously. Such proposals require a qualified super-majority of no votes to be rejected at low turnouts. As the turnout grows, the threshold for rejecting the referendum decreases towards a simple majority.

Simple Majority

Referenda which were initiated by the Council with majority agreement (i.e. not unanimously) can be accepted by the community with a simple majority of the votes (50% + 1).

- + \ No newline at end of file diff --git a/democracy_technical_committee/index.html b/democracy_technical_committee/index.html index 99c3c551..b813a730 100644 --- a/democracy_technical_committee/index.html +++ b/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ Technical Committee | HydraDX Docs - +

Technical Committee

The Technical Committee is a group of experienced core developers which is appointed directly by the HydraDX Council. Its main task is to safeguard the technical stability of the protocol.

The Technical Committee has the right to produce emergency referenda which are fast-tracked and voted in parallel with any other active referenda. This allows the Committee to act quickly and deliver critical (code) changes.

Another important power of the Technical Committee is the ability to cancel referendum proposals which are deemed to be detrimental to the protocol. In order to cancel a referendum proposal, the Committee must agree unanimously.

- + \ No newline at end of file diff --git a/dev_intro/index.html b/dev_intro/index.html index f7da4dd9..b19616aa 100644 --- a/dev_intro/index.html +++ b/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/es/404.html b/es/404.html index 78a818fd..076dd8a8 100644 --- a/es/404.html +++ b/es/404.html @@ -4,13 +4,13 @@ Página no encontrada | HydraDX Docs - +

Página no encontrada

No pudimos encontrar lo que buscabas.

Comuníquese con el propietario del sitio que lo vinculó a la URL original y hágale saber que su vínculo no funciona.

- + \ No newline at end of file diff --git a/es/archive_hydradx_crowdloan/index.html b/es/archive_hydradx_crowdloan/index.html index a20fde51..e15645c0 100644 --- a/es/archive_hydradx_crowdloan/index.html +++ b/es/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX Crowdloan | HydraDX Docs - +

HydraDX Crowdloan

danger

This page has been archived, meaning that the information it contains may be outdated or no longer applicable.

The HydraDX crowdloan for the Polkadot parachain auctions is now live! You can support HydraDX by participating in our crowdloan campaign and pledging some amount of DOT tokens which will be locked up for the duration of the parachain slot.

In return, you will be granted HDX rewards which cover your opportunity costs. Once the parachain slot has expired, you will receive your DOT tokens back in full. The same applies to the scenario that HydraDX does not manage to win a parachain slot within the crowdloan campaign deadline stated hereunder.

Crowdloan Details

  • Visit: https://loan.hydradx.io/
  • Crowdloan start: 28 December 2021
  • Bidding on slots: #6 - #11
  • Onboarding of winning parachains: 11 March 2022
  • End of leased parachain slots: 12 January 2024
  • Crowdloan cap: 8,000,000 DOT
  • Rewards: between 280 and 12.5 HDX per contributed DOT
  • Rewards cap: max. 1,000,000,000 HDX (10% of total supply)
  • Vesting period: HDX rewards are distributed linearly. The distribution will start after HydraDX has been onboarded as a Polkadot parachain and the transition from Snakenet (our testnet) has been completed.
  • Crowdloan campaign deadline: 12 March 2022

HDX Rewards

All participants in the HydraDX crowdloan will receive HDX in exchange for their contributions. The amount of the rewards depends on our rank in the parachain auction race at the time of your contribution, as well as the total amount of DOT which have been contributed by others.

Contributions made before HydraDX is leading the race by 15% will receive the highest amount of rewards - between 280 and 125 HDX per contributed DOT.

After we have secured a comfortable lead, the rewards will start dropping linearly. They will be at their lowest level once HydraDX has a lead of 25% or more. Contributions made during the time that we are leading by more than 25% will receive between 28 and 12.5 HDX per contributed DOT.

The rewards system is designed to offset the opportunity costs of locking your DOT for the duration of the parachain lease, as opposed to staking it. Contributions made before we have gained a 15% lead will get their full opportunity costs reimbursed. The price of HDX used for the calculation is $ 0.026. This number is based on the closing HDX LBP price of $ 0.08 (February 2021), after taking into account the upcoming tripling of all balances which were built up during our testnet.

- + \ No newline at end of file diff --git a/es/assets/js/d631f7a2.0aa925f6.js b/es/assets/js/d631f7a2.0d0a2f2e.js similarity index 70% rename from es/assets/js/d631f7a2.0aa925f6.js rename to es/assets/js/d631f7a2.0d0a2f2e.js index d08b651e..79eba783 100644 --- a/es/assets/js/d631f7a2.0aa925f6.js +++ b/es/assets/js/d631f7a2.0d0a2f2e.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=r)&&Object.keys(d.O).every((function(e){return d.O[e](f[o])}))?f.splice(o--,1):(a=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[f,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var c={};t=t||[null,f({}),f([]),f(f)];for(var a=2&n&&e;"object"==typeof a&&!~t.indexOf(a);a=f(a))Object.getOwnPropertyNames(a).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},d.d(r,c),r},d.d=function(e,t){for(var f in t)d.o(t,f)&&!d.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,f){return d.f[f](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",775:"6df84e08",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",2085:"1fd75fb9",2091:"7f52a4ed",2250:"07178ad8",2332:"9fd70990",2989:"7921dc2a",3847:"a13a2e64",4020:"669853c7",4101:"1d2d6146",4315:"0a03b4a5",4685:"359fb69f",5127:"e48ff9e9",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5888:"2cad9136",6047:"b66768d7",6131:"679fd3c6",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8323:"70254ef3",8462:"dab19d87",8499:"4a7f69ff",8696:"a53b80d1",8741:"4ccf5e49",8975:"ceb1145d",9219:"144c5974",9305:"c52f9895",9361:"b5d04332",9366:"c116d048",9430:"89732296",9514:"1be78505",9726:"18ff1f2d",9824:"6f9a81bf",9841:"a0c649f9"}[e]||e)+"."+{17:"308ae345",53:"3eb39c64",548:"1a95c330",574:"6b577cce",775:"b4a55f68",942:"0aa925f6",994:"fbfb776e",1019:"bd0d2028",2085:"bcb4349a",2091:"10bb220b",2250:"38153c9a",2332:"90abbdf1",2989:"bc87b238",3847:"1d8cfb11",4020:"cea91086",4101:"506c143d",4315:"47369a4d",4685:"64c202a5",4972:"79f8b409",5127:"d3571d9f",5183:"084bbd4e",5355:"4d82b523",5445:"2745e38d",5488:"4ecd00bc",5536:"4bb6e965",5888:"4180e556",6047:"2367b708",6131:"3d01f616",6295:"ab94f60e",6428:"759746a8",6714:"6ae3137d",6880:"7d5768ab",7615:"6c7ef706",7918:"bff4c59e",7939:"4a04ced5",8323:"8c3829b8",8462:"e6394343",8499:"e146566b",8696:"9aa2b756",8741:"ff60cdec",8975:"c16cdcb2",9219:"65692f24",9305:"ba3360f2",9361:"8fe7b3ab",9366:"e6dfcc7f",9430:"d1204c43",9514:"4cb072e6",9726:"6c607e00",9824:"36cba715",9841:"c19f3533"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,f,c){if(n[e])n[e].push(t);else{var a,o;if(void 0!==f)for(var u=document.getElementsByTagName("script"),i=0;i=r)&&Object.keys(d.O).every((function(e){return d.O[e](f[o])}))?f.splice(o--,1):(a=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[f,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var c={};t=t||[null,f({}),f([]),f(f)];for(var a=2&n&&e;"object"==typeof a&&!~t.indexOf(a);a=f(a))Object.getOwnPropertyNames(a).forEach((function(t){c[t]=function(){return e[t]}}));return c.default=function(){return e},d.d(r,c),r},d.d=function(e,t){for(var f in t)d.o(t,f)&&!d.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,f){return d.f[f](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",548:"0b7119cc",574:"9deda591",775:"6df84e08",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",2085:"1fd75fb9",2091:"7f52a4ed",2250:"07178ad8",2332:"9fd70990",2989:"7921dc2a",3847:"a13a2e64",4020:"669853c7",4101:"1d2d6146",4315:"0a03b4a5",4685:"359fb69f",5127:"e48ff9e9",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5888:"2cad9136",6047:"b66768d7",6131:"679fd3c6",6295:"d2692880",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7615:"4756a152",7918:"17896441",7939:"dfd1ff83",8323:"70254ef3",8462:"dab19d87",8499:"4a7f69ff",8696:"a53b80d1",8741:"4ccf5e49",8975:"ceb1145d",9219:"144c5974",9305:"c52f9895",9361:"b5d04332",9366:"c116d048",9430:"89732296",9514:"1be78505",9726:"18ff1f2d",9824:"6f9a81bf",9841:"a0c649f9"}[e]||e)+"."+{17:"308ae345",53:"3eb39c64",548:"1a95c330",574:"6b577cce",775:"b4a55f68",942:"0d0a2f2e",994:"fbfb776e",1019:"bd0d2028",2085:"bcb4349a",2091:"10bb220b",2250:"38153c9a",2332:"90abbdf1",2989:"bc87b238",3847:"1d8cfb11",4020:"cea91086",4101:"506c143d",4315:"47369a4d",4685:"64c202a5",4972:"79f8b409",5127:"d3571d9f",5183:"084bbd4e",5355:"4d82b523",5445:"2745e38d",5488:"4ecd00bc",5536:"4bb6e965",5888:"4180e556",6047:"2367b708",6131:"3d01f616",6295:"ab94f60e",6428:"759746a8",6714:"6ae3137d",6880:"7d5768ab",7615:"6c7ef706",7918:"bff4c59e",7939:"4a04ced5",8323:"8c3829b8",8462:"e6394343",8499:"e146566b",8696:"9aa2b756",8741:"ff60cdec",8975:"c16cdcb2",9219:"65692f24",9305:"ba3360f2",9361:"8fe7b3ab",9366:"e6dfcc7f",9430:"d1204c43",9514:"4cb072e6",9726:"6c607e00",9824:"36cba715",9841:"c19f3533"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,f,c){if(n[e])n[e].push(t);else{var a,o;if(void 0!==f)for(var u=document.getElementsByTagName("script"),i=0;i Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/es/build_dev_chain/index.html b/es/build_dev_chain/index.html index d5654976..e5fce6be 100644 --- a/es/build_dev_chain/index.html +++ b/es/build_dev_chain/index.html @@ -4,14 +4,14 @@ Configura una Cadena para desarrolladores. | HydraDX Docs - +

Configura una Cadena para desarrolladores.

Esta sección le muestra el proceso de configuración de una instancia de cadena HydraDX local para el desarrollo.

01 Instalar dependencias

Para preparar una instancia local de HydraDX Chain para el desarrollo, su máquina debe cubrir todas las dependencias para ejecutar una cadena de substrate. Deberá instalar un entorno de desarrollador de Rust y asegurarse de que esté configurado correctamente para compilar el Substrate runtime code para el destino WebAssembly (Wasm).

Puede instalar y configurar todas las dependencias manualmente siguiendo la Substrate guide, o puede dejar que este script haga todo el trabajo por usted.

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Crea

Cree los entornos de ejecución nativos y de Wasm:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Build the binary
$ cd HydraDX-node/
$ cargo build --release

Debería poder encontrar la compilación bajo ./target/release/hydra-dx.

03 Ejecuta

Antes de ejecutar su compilación, puede purgar cualquier cadena de desarrollo existente en su máquina (deberá hacer esto a menudo en el proceso de desarrollo):

$ ./target/release/hydra-dx purge-chain --dev

Ejecute su compilación usando uno de los siguientes comandos:

$ ./target/release/hydra-dx --dev

# Run with detailed logging
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Conéctese a su instancia de cadena local

Puede conectarse a su nodo de desarrollo HydraDX usando Polkadot / apps y cambiando la red a Desarrollo. También puede utilizar este enlace: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/es/claim/index.html b/es/claim/index.html index d68455ce..98e1df42 100644 --- a/es/claim/index.html +++ b/es/claim/index.html @@ -4,13 +4,13 @@ Reclamar tus HDX | HydraDX Docs - +

Reclamar tus HDX

Tu puedes reclamar tus HDX con los xHDX tokens (ERC-20) que obtuvo durante nuestro Balancer LBP mientras etsuvo activo.

Pre-requisitos

Hay dos requisitos previos para reclamar su HDX. En primer lugar, debe instalar la extensión del navegador Polkadot.js que se utilizará para crear su billetera HDX. En segundo lugar, necesita acceso a sus tokens xHDX, que deben almacenarse en una billetera que admita la firma de mensajes relacionados con tokens ERC-20 (por ejemplo, Metamask).

Si sus tokens xHDX están almacenados en Coinbase Wallet o Trust Wallet, deberá utilizar una de las siguientes soluciones para reclamar su HDX, ya que estas carteras no admiten la firma de mensajes:

  • Metamask: puede usar la extensión del navegador Metamask e importar su billetera usando la frase inicial de recuperación.
  • MEW (MyEtherWallet): también puede usar MEW importando su frase inicial de recuperación ( Frase mnemónica ) o usando la opción de conexión WalletLink. Se puede acceder a ambas opciones desde la página de acceso a la billetera MEW. Si está utilizando Coinbase Wallet, puede usar WalletLink, que puede encontrar la Configuración de Coinbase Wallet.

Proceso de Reclamo

Después de asegurarse de que ha cumplido con los requisitos previos descritos anteriormente, puede navegar a la aplicación HydraDX Claim y continuar con el proceso de reclamación.

Durante el proceso de reclamo, usará sus tokens xHDX (ERC-20) para reclamar su parte de tokens HDX.

00 Autorización

La aplicación HydraDX Claim solicitará la autorización de la extensión del navegador Polkadot.js.

danger

Asegúrese de no ser víctima de un ataque de phishing y preste atención a la ventana emergente de autorización: la aplicación debe identificarse como CLAIM.HYDRADX.IO y la solicitud debe provenir de https://reclamo .hidradx.io.

authorize

Después de autorizar, se le pedirá que actualice los metadatos para la extensión del navegador Polkadot.js. Esto permitirá que Polkadot.js cree direcciones específicas de HydraDX que se requieren para completar el proceso de reclamo.

authorize

01 Selecciona tu dirección ETH

En el primer paso del proceso de reclamo, se le pedirá que seleccione la cuenta que contiene sus tokens xHDX. Esto se puede hacer conectándose a su billetera con los tokens ERC-20 (por ejemplo, Metamask) o ingresando su dirección ETH manualmente en el cuadro de entrada (en ese caso, deberá firmar el mensaje manualmente más tarde).

Después de ingresar su dirección ETH, debería ver el saldo de tokens HDX que puede reclamar, incluido el reembolso de las tarifas del gas que ha gastado para obtener su xHDX en Balancer.

note

No es elegible para un reembolso de gasolina si ha obtenido su xHDX en algún otro lugar que no sea el grupo oficial de Balancer (como Uniswap), o si ha sacado sus tokens de la billetera de compra original.

authorize

02 Crea y Selecciona una dirección HDX

En el segundo paso, se le pedirá que seleccione su dirección HDX.

Para crear una nueva dirección HDX, abra la extensión del navegador Polkadot.js y haga clic en el signo + para crear una nueva cuenta. En el primer paso de la creación de la cuenta, verá la frase mnemotécnica de 12 trabajos que se puede utilizar para recuperar su cuenta. Después de guardar su frase inicial en un lugar seguro, haga clic en Siguiente paso. Aquí, debe cambiar la Red seleccionando la opción HydraDX Snakenet. Ingrese un nombre y contraseña para su cuenta y finalice la creación de la cuenta.

authorize
danger

Asegúrese de hacer una copia de seguridad de su frase inicial de recuperación guardándola en un lugar seguro y nunca la comparta con nadie. Usar la frase inicial es la única forma en que puede recuperar su cuenta y, si la pierde o filtra, sus fondos podrían verse comprometidos. Tenga en cuenta que debe proteger su acceso a esta billetera hasta que se inicie la red principal, ya que todos los saldos de HDX están actualmente bloqueados. Si pierde el acceso a su billetera HDX, también perderá su HDX.

Después de crear su cuenta HDX, debería poder seleccionarla en la aplicación HydraDX Claim. Después de hacerlo, la aplicación debería proporcionarle una descripción general de las direcciones ETH y HDX utilizadas para el proceso de reclamo. Haga clic en siguiente para continuar con la firma del mensaje.

authorize

03 Firma

En el tercer paso del proceso de reclamo utilizando la aplicación HydraDX Claim, se le proporcionará la opción de firmar el mensaje para usar sus tokens xHDX para reclamar HDX.

note

Tenga en cuenta que en este paso verá la clave pública de su dirección HDX, y no la dirección en su forma legible por humanos como se mostró en el paso anterior y en la extensión de su navegador Polkadot.js (para más detalles consulte los ss58 docs). Si ha seguido todos los pasos descritos anteriormente, no hay nada de qué preocuparse y es seguro continuar con la firma del mensaje. También verificaremos que la cuenta HDX que está utilizando para firmar la transacción de reclamo en el paso final corresponda con la cuenta que recibe el HDX reclamado.

Dependiendo de la elección que haya hecho en el primer paso, tiene dos opciones para firmar el mensaje para usar los tokens xHDX en el proceso de reclamo:

  • Si está utilizando Metamask, después de hacer clic en el botón Firmar, Metamask le pedirá que firme el mensaje. Siga las instrucciones en Metamask.

  • Si ingresó su dirección ETH manualmente, deberá firmar el mensaje a través de la billetera externa que contiene las claves privadas de sus tokens xHDX. Una vez que haya firmado el mensaje, copie la firma (comenzando con 0x) en el campo respectivo en la aplicación HydraDX Claim.

authorize

04 Reclamo

Después de firmar el mensaje con la billetera que contiene sus tokens xHDX, la extensión Polkadot.js debería abrirse y se le pedirá que firme la transacción para reclamar el HDX a su cuenta. Ingrese la contraseña de su cuenta HDX y haga clic en Firmar la transacción.

¡Ya ha completado el proceso de reclamación, convirtiéndose así oficialmente en propietario de HDX!

Puede consultar su saldo utilizando Polkadot/apps conectado a HydraDX Red: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/es/collator_setup/index.html b/es/collator_setup/index.html index 5b2d4268..52fde4f1 100644 --- a/es/collator_setup/index.html +++ b/es/collator_setup/index.html @@ -4,13 +4,13 @@ Set up a Collator Node | HydraDX Docs - +

Set up a Collator Node

This is a step-by-step how-to so you can get your HydraDX collator up and running. In this guide, we use Ubuntu 20.04 LTS.

Required technical specifications

The following technical specifications are required as a minimum for running a HydraDX collator node:

  • OS: Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (or equivalent single core performance)
  • Memory: 64GB RAM
  • Storage: NVMe SSD with a capacity of at least 200GB (the data footprint will grow over time)
note

These are the minimum technical requirements which have been verified by the team. Want to make sure that your machine has sufficient resources to run a node? Run a performance benchmark to find out.

Create a technical hydra user and add it to Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

Download and configure the hydradx binary

Pick a 12.x release, we are using v12.1.0 from our assets repository:

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

Command to run your collator

Best is to run your collator as a service using systemctl. To do so, create a file, namely hydradx-collator.service under /etc/systemd/system/hydradx-collator.service:

sudo vim /etc/systemd/system/hydradx-collator.service

Then paste the following:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

Before starting your node, let's create the base-path folder and give it the necessary permissions and ownership:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
caution

Make sure you have enough volume for your base-path by using df -h command.

Note that --prometheus-external is optional, but we highly recommend it so you can be able to export prometheus metrics and monitor your node's health through Grafana. For more details about monitoring, please visit this link.

If you need to monitor both the parachain and relaychain metrics, --prometheus-externaloption should be setup in both parts. You also need to set a separate port for the relaychain part as follows: --prometheus-port YOUR_CUSTOM_PORT_NUMBER

Depending on your setup, you might also want to override certain parameters like the websocket, rpc or your node p2p port. Please use hydradx --help for more information about the available options.

After saving your file, run the following commands to start your node:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

Your node should now be up and running. Make sure your hydra user has the necessary permissions to access your base-path and key file.

If you need to troubleshoot your running service, you can use the journalctl command with the -f option for tailing:

journalctl -fu hydradx-collator

Generate your session key

In order to generate keys for your node, run the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

Once done, you will have an output similar to:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

Set your session key

To associate the generated session keys with your Controller account, navigate to the following menu item in the Polkadot/apps on the Polkadot parachain HydraDX: Developer > Extrinsics.

Fill in the fields:

  • using selected account: select your Controller account;
  • submit the following extrinsic: select session on the left side and setKeys on the right;
  • keys: enter your session key you just generated;
  • proof: 0;

What's next?

Make sure that your node is fully synced. Once this is done, let us know in the dedicated Discord channel (only if you have been preselected as a collator).

- + \ No newline at end of file diff --git a/es/contributing/index.html b/es/contributing/index.html index 5ea115e2..fdc9e749 100644 --- a/es/contributing/index.html +++ b/es/contributing/index.html @@ -4,13 +4,13 @@ Writing Docs | HydraDX Docs - +

Writing Docs

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation
H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.


Lists

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
  4. And another item.
  • Unordered list can use asterisks
  • Or minuses
  • Or pluses

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example).

Some text to show that the reference links can follow later.


Images

Here's our logo (hover to see the title text):

Inline-style: alt text

Reference-style: alt text

Images from any folder can be used by providing path to file. Path should be relative to markdown file.

![img]{useBaseUrl('/static/img/logo.svg')}


Code

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

MarkdownLessPretty
Stillrendersnicely
123

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.


Inline HTML

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.


Admonitions

note

This is a note

tip

This is a tip

info

This is important

caution

This is a caution

danger

This is a warning

- + \ No newline at end of file diff --git a/es/create_account/index.html b/es/create_account/index.html index b67753c9..ef1c5b26 100644 --- a/es/create_account/index.html +++ b/es/create_account/index.html @@ -4,13 +4,13 @@ Create a new HDX Account | HydraDX Docs - +

Create a new HDX Account

The process of creating a new HDX Account consists of three simple steps.

01 Install Polkadot.js

In order to create and manage your HDX wallet, you need to install the Polkadot.js browser extension.

02 Upgrade metadata

After installing the Polkadot.js browser extension, you should make sure that it has been updated with the latest chain metadata. For this purpose, you can visit the following link and update your metadata, if prompted:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/settings/metadata

03 Create your HDX Account

To create a new HDX address, open the Polkadot.js browser extension and click on + > Create new account.

You will be displayed a 12-word mnemonic phrase which can be used to recover your account. Make sure that you backup your seed phrase in a secure location. Click on Next step and fill in the following information:

  • Network: Please select HydraDX Snakenet
  • Descriptive name of the account
  • Password

Your account will be created after clicking Add the account with the generated seed.

create-account
danger

Make sure to backup your recovery seed phrase by storing it in a secure location. Never share your seed phrase with anybody. The seed phrase can be used to gain access to your account. If you lose it or leak it, you might also lose all the HDX stored in your account. Please note that all HDX balances are locked until mainnet starts, so you need to make sure that you keep the account holding your tokens secure until then.

- + \ No newline at end of file diff --git a/es/democracy_council/index.html b/es/democracy_council/index.html index 06751052..3475140f 100644 --- a/es/democracy_council/index.html +++ b/es/democracy_council/index.html @@ -4,13 +4,13 @@ Consejo de HydraDX | HydraDX Docs - +

Consejo de HydraDX

El Consejo HydraDX es una entidad on-chain que desempeña un papel clave en la gobernanza del protocolo. Este artículo proporciona información sobre la composición del Consejo, sus tareas principales y la elección de los miembros del Consejo

Para obtener orientación paso a paso sobre cómo participar en las elecciones del Consejo, consulte esta guía.

Composición

El Consejo HydraDX consta actualmente de 13 miembros.

Se reserva una participación minoritaria de 6 asientos para el equipo fundador y los inversores (4 fundadores + 2 inversores).

Los 7 asientos restantes son elegidos por la comunidad más amplia de titulares de HDX

Tareas y responsabilidades

Las tareas del Consejo HydraDX cubren una amplia gama de actividades de gobernanza diarias. Para empezar, el Consejo controla el Tesoro y aprueba o rechaza las propuestas de la Tesorería.

El Consejo HydraDX también juega un papel en el mecanismo de referéndum. El Consejo puede iniciar un referéndum, siempre que al menos el 60% de los miembros lo apoyen (supermayoría) y ningún miembro ejerza un veto. En caso de veto, la propuesta puede volver a presentarse una vez transcurrido el período Cool-down. El miembro vetador no puede vetar la misma propuesta dos veces.

Además, cualquier referéndum propuesto puede cancelarse con una supermayoría de 2/3 de los votos del Consejo. Esto se puede utilizar como medida de último recurso para detener propuestas o cambios maliciosos que podrían introducir errores en el código.

Finalmente, el Consejo de HydraDX es responsable de elegir al Comité Técnico.

Elecciones

Cualquier titular de tokens HDX puede aplicar para uno de los 7 asientos no permanentes del Consejo HydraDX como candidato.

Las elecciones del Consejo se llevan a cabo cada 7 días, momento en el que un algoritmo llena los 7 puestos no permanentes del Consejo durante los 7 días siguientes. El módulo de democracia utiliza el mismo algoritmo Phragmen que se utiliza para elegir el conjunto activo de validadores in Polkadot.

Todos los miembros de la comunidad pueden votar en las elecciones del Consejo bloqueando una cierta cantidad de tokens HDX de su elección. Los tokens bloqueados no están disponibles para su transferencia y se utilizarán en las elecciones de seguimiento (hasta que se cancelen). Los votantes pueden y deben seleccionar más de un candidato en orden de preferencia. Luego, el algoritmo de elección distribuye todos los votos para determinar la asignación óptima de los puestos disponibles en el Consejo a los candidatos con el mayor respaldo de la comunidad.

- + \ No newline at end of file diff --git a/es/democracy_intro/index.html b/es/democracy_intro/index.html index 491e31b8..9e649e06 100644 --- a/es/democracy_intro/index.html +++ b/es/democracy_intro/index.html @@ -4,13 +4,13 @@ Introducción | HydraDX Docs - +

Introducción

HydraDX está en proceso de descentralizar completamente su gobernanza. Todas las decisiones que afectan al protocolo se adoptan siguiendo un proceso democrático que está respaldado por el módulo de democracia de Substrate. El mecanismo central para establecer un consenso entre las partes interesadas es el referéndum.

Esta sección contiene una serie de artículos que deberían proporcionarle una mejor comprensión de los mecanismos detrás de la gobernanza de HydraDX. Encontrará más información sobre cómo funcionan los referendos, así como sobre los dos grupos centrales de actores de la gobernanza: el Consejo HydraDX y el Comité Técnico.

Si está buscando una guía práctica sobre cómo participar en la gobernanza de HydraDX, consulte las guías paso a paso sobre [participando en los referendos](/participate_in_referenda y participar en las elecciones del Consejo.

Parámetros de democracia

La siguiente lista contiene los parámetros más importantes que influyen en el mecanismo de gobernanza de HydraDX. Tenga en cuenta que estos pueden cambiar con el tiempo.

  • Depósito mínimo de HDX para iniciar un referéndum: 100,000 HDX
  • Período de promulgación del referéndum: 3 días
  • Periodo de votación del referéndum: 3 días
  • Período de votación de referéndum de emergencia: 3 horas
  • Período Cooloff después del rechazo de un referéndum: 7 días
  • Máximo de propuestas de referéndum pendientes: 100
- + \ No newline at end of file diff --git a/es/democracy_referenda/index.html b/es/democracy_referenda/index.html index 5d87fa70..b301bc3d 100644 --- a/es/democracy_referenda/index.html +++ b/es/democracy_referenda/index.html @@ -4,13 +4,13 @@ Referéndum | HydraDX Docs - +

Referéndum

Los referéndums permiten a las partes interesadas someter una propuesta a una votación ponderada y basada en stake por parte de la comunidad en general. El objeto del referéndum es alguna acción sugerida que afecte al protocolo, por ejemplo, un pago de la Tesorería o incluso un cambio en el código runtime

En términos generales, solo se somete a votación un referéndum a la vez. Otras propuestas de referéndum pendientes se ponen en cola. Hay colas separadas para las propuestas presentadas públicamente y para las propuestas del Consejo. Cada 3 días, el mecanismo de referéndum elige la primera propuesta con la mayor cantidad de apoyo, alternando entre las dos colas. Una vez que se ha votado y aceptado un referéndum, hay un período de promulgación de 3 días que debe transcurrir antes de que la decisión entre en vigor. Se aplica una excepción a estas reglas para las propuestas de emergencia del Comité Técnico que se ocupan de los principales problemas de protocolo y deben acelerarse.

Iniciando un referéndum

Hay varias formas de iniciar un referéndum que se describen con mayor detalle a continuación. La forma en que se inició el referéndum es decisiva para el modo de votación aplicable.

Referéndum Público

Cualquier titular de tokens HDX puede proponer un referéndum) depositando la cantidad mínima requerida de tokens HDX y enviando la propuesta on-chain. Otros miembros de la comunidad pueden apoyar (secundar) la propuesta para un referéndum bloqueando una cantidad igual de tokens. Al comienzo de cada ciclo de votación, la propuesta de referéndum con la mayor cantidad de secundaciones (total de tokens depositados) se avanza a votación por parte de la comunidad.

El modo de votación que se aplica a los referendos públicos es Sesgo de participación positiva

note

Todos los tokens HDX que se depositan para proponer o apoyar un referéndum se bloquean durante todo el período hasta que el referéndum haya entrado en el ciclo de votación. Es importante recordar que no hay garantía de que una propuesta determinada reciba el respaldo suficiente para pasar a la ronda de votación, lo que significa que sus fondos pueden permanecer bloqueados por un período indefinido.

Referéndum del Consejo

El Consejo de HydraDX tiene el poder para proponer un referéndum para que la comunidad lo vote.Si lo hace por unanimidad, el modo de votación aplicable para el referéndum es Sesgo de participación negativa. Si el referéndum se propone con una mayoría simple de los votos del Consejo, entonces el modo de votación para aceptar las propuestas de la comunidad es Mayoría simple.

Propuestas de emergencia del Comité Técnico

El Comité Técnico puede enviar propuestas de emergencia que se ocupen de la corrección de errores (críticos) o la rápida adopción de funciones probadas en batalla. Las propuestas de emergencia se saltan la cola de espera y entran directamente en la ronda de votación. La comunidad puede votar sobre propuestas de emergencia en paralelo a cualquier propuesta regular que haya entrado en la ronda de votación. Además, las propuestas de emergencia tienen un período de votación más corto para garantizar que puedan acelerarse.

Cancelar un referéndum

Una vez que se ha propuesto un referéndum, no se puede revocar hasta que no haya entrado en la ronda de votación. Se hace una excepción a esta regla para las propuestas que se consideran perjudiciales para el protocolo (por ejemplo, cambios de código que introducen un error). En este caso limitado, la propuesta de referéndum puede ser cancelada por el Consejo de HydraDX (con una supermayoría del 60%) o el Comité Técnico (por unanimidad). Todos los tokens que fueron bloqueados por los partidarios que secundaban la propuesta se queman.

Votación de un Referendum

Los referendos de HydraDX tienen un período de lanzamiento de 3 días. Al comienzo de cada nuevo período, la propuesta con la mayor cantidad de apoyo se toma de la cola de espera y se coloca en una ronda de votación. Cada ronda de votación tiene una duración de 3 días. Durante este período, los miembros de la comunidad pueden votar en el referéndum utilizando un mecanismo ponderado de base de intereses. Lo hacen bloqueando una cierta cantidad de tokens HDX durante un período de tiempo determinado.

note

Los tokens HDX bloqueados no se pueden transferir durante el período de bloqueo elegido. Sin embargo, todavía se pueden usar para votar.

Ponderación de votos

Hay dos factores que determinan el peso de cada voto en un referéndum. El primer factor es la cantidad de tokens HDX que el votante bloquea en apoyo del voto. El segundo factor es el llamado multiplicador de convicciones que refleja la duración durante la cual el votante está dispuesto a bloquear los tokens.

vote_weight = tokens * conviction_multiplier

Los períodos de bloqueo de votos tienen la misma duración que el periodo de promulgación. Si los tokens están bloqueados durante 1 período de votación, esto significa que permanecerán bloqueados durante 3 días después de que finalice la votación. Los votantes pueden influir en el peso de sus votos disminuyendo o aumentando la cantidad de períodos durante los cuales los tokens están bloqueados. Es posible generar un voto con 0 períodos de bloqueo, sin embargo, su peso sería solo una fracción (multiplicador de convicción de 0.1x). Por otro lado, el multiplicador de convicciones aumenta en 1 por cada duplicación de los períodos de bloqueo. Como se muestra en la tabla a continuación, bloquear los votos por un máximo de 32 períodos elevaría el multiplicador de convicciones a 6x.

Períodos de bloqueoMultiplicador de convicciones
00.1
11
22
43
84
165
326
Un ejemplo:

Alice vota con 5000 HDX y 0 períodos de bloqueo.
Bob vota con 100 HDX y 32 períodos de bloqueo.

Peso de Alice: 500
Peso de Bob: 600

Modos de votación

Otro aspecto importante del módulo de democracia son los diferentes modos de votación que se aplican. El umbral de votos necesarios para aprobar o rechazar un referéndum puede variar dependiendo de cómo se inició el referéndum y de la participación de la votación. La participación se calcula en función de la cantidad total de tokens HDX que se utilizaron para votar en el referéndum (se excluyen los multiplicadores de convicciones). Si la participación fue baja o no está determinada por la relación entre la participación y el elactorado (es decir, la cantidad total de tokens HDX elegibles para votar).

Sesgo de participación positiva

Este es el modo de votación predeterminado cuando la Comunidad propone un referéndum. En participaciones más bajas, se requiere una supermayoría calificada de votos a favor para aprobar el referéndum. A medida que aumenta la participación, el umbral disminuye hacia una mayoría simple.

Sesgo de participación negativa

Este modo de votación se aplica a los referendos propuestos por el Consejo por unanimidad. Tales propuestas requieren una supermayoría calificada de votos "no" para ser rechazadas con baja participación. A medida que crece la participación, el umbral para rechazar el referéndum disminuye hacia una mayoría simple.

Mayoría simple

Los referémdus iniciados por el Consejo con un acuerdo mayoritario (es decir, no unánimemente) pueden ser aceptados por la comunidad con una mayoría simple de los votos (50% + 1).

- + \ No newline at end of file diff --git a/es/democracy_technical_committee/index.html b/es/democracy_technical_committee/index.html index cc9a4fa8..b40098d1 100644 --- a/es/democracy_technical_committee/index.html +++ b/es/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ Comité técnico | HydraDX Docs - +

Comité técnico

El Comité Técnico es un grupo de desarrolladores centrales experimentados que es designado directamente por el Consejo de HydraDX. Su tarea principal es salvaguardar la estabilidad técnica del protocolo.

El Comité Técnico tiene derecho a producir referendum de emergencia que se aceleran y se votan en paralelo con cualquier otro referendum activo. Esto permite que el Comité actúe rápidamente y realice cambios críticos (de código).

Otro poder importante del Comité Técnico es la capacidad de cancelar propuestas de referéndum que se consideren perjudiciales para el protocolo. Para cancelar una propuesta de referéndum, el Comité debe estar de acuerdo por unanimidad.

- + \ No newline at end of file diff --git a/es/dev_intro/index.html b/es/dev_intro/index.html index 723719fe..e66c9547 100644 --- a/es/dev_intro/index.html +++ b/es/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/es/great-unlock/index.html b/es/great-unlock/index.html index 20573517..ee8cd707 100644 --- a/es/great-unlock/index.html +++ b/es/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/es/howto_bonds_lbp/bonds1.jpg b/es/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/es/howto_bonds_lbp/bonds1.jpg and b/es/howto_bonds_lbp/bonds1.jpg differ diff --git a/es/howto_bonds_lbp/bonds2.jpg b/es/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/es/howto_bonds_lbp/bonds2.jpg and b/es/howto_bonds_lbp/bonds2.jpg differ diff --git a/es/howto_bonds_lbp/index.html b/es/howto_bonds_lbp/index.html index 3a893086..3b9d9b65 100644 --- a/es/howto_bonds_lbp/index.html +++ b/es/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

caution

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
note

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/es/howto_bridge/index.html b/es/howto_bridge/index.html index 78669981..c037d7d2 100644 --- a/es/howto_bridge/index.html +++ b/es/howto_bridge/index.html @@ -4,13 +4,13 @@ Bridge Assets | HydraDX Docs - +

Bridge Assets

On this page you will find a step-by-step guide on bridging tokens from the Ethereum ecosystem. Currently there are two methods to bridging to and from Ethereum (via Wormhole):

Wormhole’s Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain.

To/From Ethereum via Moonbeam

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Talisman or Metamask);
caution

Make sure to have enough tokens (ETH) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens.

01 Navigate to Carrier.so

https://www.carrier.so/

caution

Use with caution. All crypto applications can potentially carry risks related to smart contracts/pallets.

metadata

02 Add the Wallets from Source and Destination Network

  • Once you have navigated to Carrier.so, add the wallets needed to allow for bridging to and from the desired networks (1 in image above).
  • In the example above, Metamask was selected as the wallet for Ethereum and Talisman for HydraDX.
metadata

03 Select Networks and Wallets to Bridge

metadata
  • Once Metamask and Talisman are connected, select the network chains (2) and select the previously connected wallets (3).

04 Select Asset to Bridge

  • Select the token asset and amount of tokens you would like to bridge (4).

05 Bridge Tokens

  • Within Settings (5), you can select whether to Auto Relay the transaction. It is recommended that this is toggled on.
metadata
  • Click Confirm & Begin Transaction (6) to proceed. This will prompt your wallet to sign the transactions. Once confirmed, you are all done!

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

To/From Ethereum via Acala

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Metamask);
  • Bind your two wallets following Acala's guide. Completing this action will require a small amount of ACA.
caution

Make sure to have enough tokens (ETH and ACA) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens, and for binding your wallet addresses.

01 Navigate to Acala Bridge Page

https://apps.acala.network/bridge

Once you have been directed to Acala bridge page, follow the actions below:

metadata

Step 2: Connect to Your Account

  • Connect your account (1).
  • Select the chains you intend to bridge to and from (2), in this case, it will be Ethereum as the Origin Chain and HydraDX as the Destination Chain.
  • Connect to your Metamask account that you are bridging from (3).

Step 3: Bridge Tokens

  • Enter the amount of tokens and the token for bridging (4).
  • To commence the bridge, click Approve Tokens (5) and sign the transaction using your Metamask wallet app.
  • Once the tokens are approved for transfer, click Send Tokens (5). This starts the bridging process cross-chain.
  • Once the transaction has been processed by Wormhole, click Redeem & Route Tokens (5). This action results in you receiving the tokens on the destination chain.

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

- + \ No newline at end of file diff --git a/es/howto_dca/index.html b/es/howto_dca/index.html index ed737121..605deb93 100644 --- a/es/howto_dca/index.html +++ b/es/howto_dca/index.html @@ -4,13 +4,13 @@ Place a DCA Order | HydraDX Docs - +

Place a DCA Order

On this page you will find a step-by-step guide for setting up a DCA order in the HydraDX Omnipool.

Before proceeding, we encourage you to visit our DCA product page in order to get yourself familiar with the HydraDX implementation of the dollar-cost averaging strategy.

Step 1: Navigate to HydraDX DCA Page

https://app.hydradx.io/dca

Step 2: Connect to Your Account

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 3: Set up DCA Order

  • Select the asset you will use to pay for the swap; Enter the order amount for each DCA trade, and the total order size (2);
  • Select the time interval for each DCA swap (3);
  • Select the asset you would like to receive from the swap (4);
  • For advanced users who would like to set up orders at specific block intervals, you can toggle the switch Advanced Settings (5) to set this up;
  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (6);
  • To complete the DCA order, click on Schedule DCA trades (7) and sign the transaction using your wallet app.

Step 4: View your DCA Order

  • After submitting it, your DCA order will appear under DCA Orders;
  • To see the details, click the Dropdown Arrow (8);
  • You can cancel your DCA order for the remaining amount by clicking on Terminate (9).
- + \ No newline at end of file diff --git a/es/howto_hydrated_farms/index.html b/es/howto_hydrated_farms/index.html index 2b389a09..64d8d4a5 100644 --- a/es/howto_hydrated_farms/index.html +++ b/es/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ Join Hydrated Farms | HydraDX Docs - +

Join Hydrated Farms

With Hydrated Farms, providing liquidity to selected assets is incentivized by additional rewards on top of rewards from trading fees. To learn more, please visit the dedicated product page.

00 Navigate to Liquidity Page

https://app.hydradx.io/liquidity

01 Provide Liquidity

Incentivized assets can be identified by the Farm rewards section which displays all available rewards for a given farm.

metadata

To join a farm, you must first provide liquidity (step-by-step guide here).

02 Join Farm

Once you have provided liquidity for an incentivized asset, you can join its farm.

metadata

To do so, click on Join farms (located next to your liquidity position) and sign the transaction using your wallet app.

Happy hydrated farming!

- + \ No newline at end of file diff --git a/es/howto_lp/index.html b/es/howto_lp/index.html index 9ef98ebc..e1bc6cc6 100644 --- a/es/howto_lp/index.html +++ b/es/howto_lp/index.html @@ -4,13 +4,13 @@ Provide Liquidity | HydraDX Docs - +

Provide Liquidity

On this page you will find a step-by-step guide for providing liquidity in the HydraDX Omnipool. Becoming a liquidity provider allows you to earn rewards from the fees generated by trades in the pool.

Before deciding to become a liquidity provider, we encourage you to visit our product page and to get yourself familiar with the unique features of the HydraDX Omnipool.

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Navigate to Omnipool Liquidity

https://app.hydradx.io/#/liquidity

metadata

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Managing Your Liquidity

Adding Liquidity

To add liquidity for a given asset, click the button Add liquidity which is located right next to that asset (3).

info

In the HydraDX Omnipool, each individual asset has a Total Value Locked (TVL) cap. This means that once the cap has been reached, users can no longer further add liquidity for that specific asset.

The individual caps for each asset will be reviewed from time to time by the team; any suggested revisions (either from team or the community) will be submitted as proposals via governance and voted on.

metadata

Fill in the amount of liquidity you wish to provide (1), click Add liquidity (2) and sign the transaction using your wallet.

Next, you can learn how to join Hydrated Farms and earn additional rewards on top of the rewards from trading fees.

Removing Liquidity

metadata

To remove liquidity, toggle the dropdown located right next to the relevant asset (1) and click Remove liquidity (2) on the position you wish to exit.

metadata

Toggle or enter the amount of liquidity you wish to withdraw (3), click on Remove liquidity (4) and sign the transaction using your wallet.

- + \ No newline at end of file diff --git a/es/howto_stake/index.html b/es/howto_stake/index.html index 4744021a..5393af2b 100644 --- a/es/howto_stake/index.html +++ b/es/howto_stake/index.html @@ -4,13 +4,13 @@ Stake HDX | HydraDX Docs - +

Stake HDX

Staking allows users to stake their HDX tokens and earn rewards which vest over time. This page contains a step-by-step guide on how to stake your HDX. Before proceeding, we recommend that you get familiar with the basics of HDX staking.

If you don't have any HDX, you can obtain some on our trade page by swapping against a range of assets supported by the Omnipool.

Step 0: Navigate to HydraDX Staking Page

https://app.hydradx.io/staking

Connect your wallet to HydraDX by clicking Connect Account.

Step 1: Stake Your HDX

  • Select the amount of HDX tokens you would like stake (3).
  • Click on Stake (4) to confirm and sign the transaction using your wallet app.
metadata

Step 2: Keep Your HDX Staked

  • The amount of rewards you receive is determined by the size of your staked HDX relative to the whole stake pool.
  • As time passes, you unlock a greater portion of your allocated rewards. The rate of unlocking is determined by a rewards bonding curve.
  • Learn more in the Staking product docs.

Step 3: Boost Your Rewards

  • Collect Action Points to boost your rewards and increase the pace at which you unlock rewards.
  • You can collect Action Points by voting on referenda. The more staked HDX you use for the vote and the higher the Conviction Multitplier - the more Action Points you receive.
  • Learn more in the Staking product docs.

Step 4: Claim Your Rewards

  • Review your Staking statistics to observe and plan your own staking strategy (5).
  • Once you are done staking, Claim your unlocked rewards (8).
metadata
caution

Every time you claim unlocked staking rewards, you forfeit any locked rewards which are redistributed to all other stakers. Furthermore, your past Action Points will be reset.

For instance, if a staker claims rewards when 75% of the rewards are available, the remaining 25% is forfeited. The staker must then wait for the same duration to claim 75% of the subsequent batch of rewards.

- + \ No newline at end of file diff --git a/es/howto_trade/index.html b/es/howto_trade/index.html index 024837db..cd14c494 100644 --- a/es/howto_trade/index.html +++ b/es/howto_trade/index.html @@ -4,13 +4,13 @@ Trade in Omnipool | HydraDX Docs - +

Trade in Omnipool

This page provides a step-by-step guide which will help you execute your first trades using the HydraDX Omnipool.

The HydraDX Omnipool is a next-gen AMM which unlocks unparalleled efficiencies, you can find out more in our product documentation.

metadata

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Enter Omnipool

https://app.hydradx.io/#/trade

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Execute a Trade

The HydraDX Trade UI allows you to intuitively execute a trade:

  • Select the pair of tokens you intend to trade (2);
  • Enter the amount of tokens for the trade (3).
    You can enter the amount of tokens you would like to pay with (e.g. 5000 DAI), but you can also enter the amount of tokens you would like to receive (e.g. 1000 HDX);
  • If you would like to adjust your slippage preferences, you can do so in Settings (4);
  • To complete the trade with instant execution (pre-selected) (5), click on Swap (7) and sign the transaction using your wallet. Otherwise, follow the additional steps below.

04 Execute a Split Trade

If your trade is large enough so that price impact would be > 0.15%, the UI will allow you to select Split trade (6) - breaking your trade into multiple smaller trades executed over < 3 hours and therefore reducing your price impact.

  • Select the pair of tokens and amounts as in 03 Execute a Trade above;
  • Select Split trade (6);
  • To schedule your Split trade execution, click on Place trades (7) and sign the transaction using your wallet.

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/es/howto_wallet_parity_signer/index.html b/es/howto_wallet_parity_signer/index.html index 40be454a..eeb85728 100644 --- a/es/howto_wallet_parity_signer/index.html +++ b/es/howto_wallet_parity_signer/index.html @@ -4,14 +4,14 @@ Use Parity Signer | HydraDX Docs - +

Use Parity Signer

Parity Signer is a mobile app which turns your iOS or Android device into a dedicated hardware wallet for Polkadot, Kusama, and any other Substrate-based chain. It allows you to keep your private keys offline while still being able to conveniently sign transactions in an air-gapped way using QR codes.

Set Up Parity Signer

Before You Start: Stay Safe

Start clean

Before installing Parity Signer, make sure that your phone is in a clean state. If it has been used, perform a factory reset and do not install any other apps besides Parity Signer.

Don’t Insert Sim

If possible, don’t turn on WiFi or use a secure WiFi connection, preferably with no other connected devices and a reputable VPN provider to connect, update the device, and install the Parity signer app.

Use Strong Passwords

For robust security, use long passwords for the device and the accounts you need to create to use it.

Setup New Account

Don’t use your old google ID or apple ID, create a new one specifically for this use which will be used only to download updates and parity signer. In case of Android device it’s better to not use WiFi or google account at all. We recommend using some sort of OS that encrypts your data like Lineage O.S. If an email is required, create a new one. Alternatively, you can create new apple id and email on iOS.

No Biometrics

Avoid fingerprint scanners, face ID, or shot numeric codes as they are exploitable. Use a strong password instead.

Disable All Signal-receiving Features

Use airplane mode and make sure to disable all of these features manually. If you are on an iOS device, turn it off and ask to auto-join networks and hotspots in the WiFi settings. Including:

  • Location services
  • WiFi (if required to upgrade or setup, disable right after the update)
  • Bluetooth

Logout From All Accounts

Log out from App stores, iCloud, and any other accounts you’ve joined.

Updating Your Device

If you are using WiFi to update your device, remember to disable it right after the update and use it only in a secure environment, preferably through a secure and encrypted VPN channel. After the update is complete, forget the WiFi network to make sure you don't automatically rejoin.

Install Parity Signer

Install Parity Signer from the official app store for your device (iOS / Android).
Make sure that the application you are downloading has been published by Parity Technologies.

Create a New Account

To create a new account, follow the steps below.

01 Add Seed

Open the Parity Signer app and select New seed.

metadata

02 Back Up your Recovery Phrase

The app will display your recover phrase. Write it down and store it in a safe place.

metadata

After completing this, you are all set to go! You can use your phone passcode or authentication method (fingerprint / face id) in Parity Signer.

danger

Stay safe!

Anyone with your seed phrase can access your funds, and there is no recourse for someone stealing your seed phrase.

To protect your seed phrase, consider the following tips:

  • Never store your seed phrase as a digital file on any device.
  • Always write down your seed phrase with a pen and paper.
  • Store the paper with your seed phrase on it somewhere safe.
  • Never give your seed phrase to anybody, including support staff.

Connect to Polkadot.js/apps

Optionally, you can add your Parity Signer account into the Polkadot.js browser extension which will allow you to view your balances on the Polkadot.js/apps accounts page and to sign transactions more easily.

On Polkadot.js/apps

To add your account, open the Polkadot.js browser extension, click on + and select Attach external QR-signer account.

metadata

On Parity Signer

  • Open Keys tab in the bottom menu;
  • Select the network you will be using from the dropdown menu next to chain;
  • Select your desired account or sub-account;
  • You will see a QR code which you need to scan with your device camera.

Add HydraDX Chain

To use Parity Signer, you first need to add a new chain to Parity Signer. If you want to use Parity only for Polkadot or Kusama, you can skip this step and proceed with updating metadata. To add a new chain, you need to scan a QR code with base information about the chain.

01 Get Chain Specs

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select HydraDX as the desired chain. After that, click on Chain Specs.

metadata

02 Add Specs

On your Parity Signer, click Scanner, scan the QR code and click Add new chain.

Use Parity Signer

danger

Always make sure you are scanning a QR code signed by a trusted verifier.

Sign a Transaction

To sign a transaction from your parity signer, we recommended adding it to polkadot.js extension for ease of use. Until more chains can work with Parity Signer directly, it will be the most convenient way to use it inside applications on your desktop.

When signing a transaction using your Parity Signer, Polkadot.js/apps will display a QR code.

metadata

Scan the QR code using Parity Signer and click on Unlock key and sign.

metadata

Your Parity Signer will now display a QR code. To complete signing the transaction, switch back to Polkadot.js/apps and click on Scan signature via camera.

Update Metadata

To use the Parity Signer, you require the latest metadata for decoding transactions in the Parity Signer. You can acquire the metadata by scanning a multi-part QR code containing this data, allowing the Parity Signer to decode the actual transaction and display it correctly before you sign. This step is similar to updating your ledger application.

01 Get Metadata

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select the desired chain. After that, click on Metadata.

metadata

02 Update

On your Parity Signer, click Scanner, and update the Metadata by scanning the QR code

- + \ No newline at end of file diff --git a/es/howto_xcm/index.html b/es/howto_xcm/index.html index d7693555..34bffe44 100644 --- a/es/howto_xcm/index.html +++ b/es/howto_xcm/index.html @@ -4,13 +4,13 @@ Cross-chain Transfer | HydraDX Docs - +

Cross-chain Transfer

On this page you will find a step-by-step guide for performing cross-chain transfers.

Cross-chain transfers allow you to transport non-native assets to the HydraDX chain from other Polkadot parachains, or from Polkadot itself.

Currently, the following tokens are supported by HydraDX for cross-chain transfers:

  • DOT
  • DAI (from Acala, bridged via Wormhole)
  • ETH (from Acala, bridged via Wormhole)
  • HDX

00 Prerequisites

Before you continue, please make sure you have sufficient amount of tokens on the destination chain for fees (ACA or DOT).

01 Navigate to Cross-chain Transfers

https://app.hydradx.io/#/cross-chain

metadata

02 Connect Your Account

Click on Connect wallet and connect to your preferred Polkadot wallet. After that, select your account.

03 Cross-chain Transfer

  • Select the source chain and the destination chain;
  • Select the asset you intend to transfer and enter the amount;
  • Enter the destination address. It should automatically populate with your address on that chain, but you can also change it to another address;
  • Click Transfer and sign the transaction using your wallet.
- + \ No newline at end of file diff --git a/es/identity/index.html b/es/identity/index.html index b318d369..a7307ebc 100644 --- a/es/identity/index.html +++ b/es/identity/index.html @@ -4,14 +4,14 @@ Establecer tu Identidad | HydraDX Docs - +

Establecer tu Identidad

Los titulares de cuentas tienen la posibilidad de establecer su identidad proporcionando información específica y almacenándola en la cadena. Además de eso, la información de identidad se puede enviar opcionalmente a los registradores de HydraDX para su verificación. Al establecer y verificar su identidad, los validadores y nominadores ayudan a salvaguardar la confianza en la red.

note

Si participa como validador de HydraDX, le recomendamos encarecidamente que establezca su identidad y se someta al proceso de verificación. Los validadores verificados parecen más confiables y atraen más nominaciones, lo que aumenta sus posibilidades de ser incluidos en el conjunto de validadores activos.

01 Establece tu identidad

Para establecer su identidad, abra Polkadot / apps (conectado a la red HydraDX Snakenet ) y navegue hasta Cuentas . Alternativamente, puede seguir este enlace:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

En dicha sección de "Cuentas", ubique la cuenta que contiene sus tokens HDX vinculados. Después de eso, haga clic en los tres puntos junto a la cuenta (en el lado derecho) y seleccione Establecer identidad en cadena .

authorize

Verá una ventana emergente llamada identidad de registro . Aquí, puede ingresar la siguiente información:

  • Nombre legal
  • Correo electrónico
  • Direccion web
  • twitter
  • riot name (en caso de que esté utilizando mensajes de Matrix)
note

Toda esta información es opcional; no dude en proporcionar solo la información que desee. Sin embargo, si está ejecutando un nodo de validación, le recomendamos que establezca su correo electrónico. Esto nos permitiría comunicarnos con usted en caso de que encontremos problemas con su nodo.

En el último campo de la ventana emergente, puede ver la cantidad de HDX que necesita depositar para almacenar su información de identidad. Recibirá este depósito una vez que decida borrar su identidad en un momento posterior.

authorize

Después de completar la información, haga clic en Establecer identidad y firme la transacción con la extensión del navegador Polkadot.js. Una vez que se confirma la transacción, se establece su identidad.

02 Envie su identidad para verificación

Una vez que haya establecido su identidad, puede enviarla a los registradores de la red para su verificación. Para hacerlo, abra Polkadot / apps y vaya a Desarrollador > Extrinsics . Alternativamente, puede seguir este enlace:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

After selecting the relevant HydraDX account from the last step, you need to fill out the following information:

  • extrinsic: identity
  • action: requestJudgement
  • reg_index: aquí debe ingresar el ID del registrador que elija para realizar la verificación. HydraDX tiene 2 registradores: Simon Kraus - HydraSik (ID: 0 ) y Jimmy Tudeski - stakenode (ID: 1 ).
  • max_fee:aquí debe ingresar la tarifa máxima en HDX que está dispuesto a pagar al registrador por la verificación. Solo los registradores con una tarifa inferior a su max_fee serán elegibles para llevar a cabo la verificación.

Para enviar su solicitud de verificación, haga clic en Enviar transacción y firme la transacción.

authorize

Tenga en cuenta que el proceso de verificación de identidad puede tardar algún tiempo en completarse. Para ver el estado de su solicitud, vaya a Cuentas y coloque el cursor sobre la sección que muestra su identidad; verá una ventana emergente que muestra el estado actual.

03 Resultado del procedimiento de verificación

Después de procesar su solicitud de verificación, el registrador enviará uno de los siguientes juicios que se harán visibles en su estado de identidad:

  • Desconocido : valor predeterminado, aún no se ha emitido ningún juicio.
  • Razonable : la información proporcionada parece razonable, sin embargo, no se realizaron verificaciones en profundidad.
  • Conocido Bueno: la información es correcta.
  • OutOfDate : la información era correcta en el pasado, pero ahora está desactualizada.
  • Baja calidad : la información no es precisa, pero se puede corregir actualizándola.
  • Erróneo : la información proporcionada es incorrecta y puede indicar una intención maliciosa.
- + \ No newline at end of file diff --git a/es/index.html b/es/index.html index f0418449..be86ce24 100644 --- a/es/index.html +++ b/es/index.html @@ -4,13 +4,13 @@ Intro | HydraDX Docs - +

Intro

Bienvenido a los documentos oficiales de HydraDX! Aquí puede encontrar todo tipo de recursos útiles sobre el protocolo HydraDX. Nuestra intención es hacer de este un gran lugar para todos, cubriendo el espectro completo entre visitantes ocasionales, validadores, nominadores y desarrolladores que desean ayudar a construir HydraDX.

HydraDx esta impulsado por la comunidad, y un ejemplo de ello, son estos documentos. Nos complace ver que todas sus contribuciones, toman formas distintas, por ejemplo, podría escribir un nuevo articulo o traducir uno existente. Si desea contribuir, consulte nuestro, repoositorio de GitHub, asi como algunas pautas de contribución..

¿Qué es HydraDX?

HydraDX es un protocolo de liquidez de cadena cruzada basado en Substrate. Nuestra misión es permitir una liquidez sin fricciones para todos los criptoactivos mediante la creación del primer pool de liquidez de activos múltiples de su tipo: HydraDX Omnipool. En el Omnipool, varios activos se comparan entre sí mediante el uso de nuestro token nativo HDX como proxy para determinar su valor relativo. Con Omnipool, HydraDX rompe con la concepción tradicional según la cual los activos se negocian por pares utilizando pools aislados. Además de eso, estamos felices de ser parte del ecosistema Polkadot y esperamos convertirnos en el proveedor de liquidez de referencia para todos los activos construidos en Substrate.

- + \ No newline at end of file diff --git a/es/lbp/index.html b/es/lbp/index.html index ef16f3fa..27cf8750 100644 --- a/es/lbp/index.html +++ b/es/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

danger

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/es/learn_amm/index.html b/es/learn_amm/index.html index 398c18c7..b808ab2d 100644 --- a/es/learn_amm/index.html +++ b/es/learn_amm/index.html @@ -4,13 +4,13 @@ What are AMMs? | HydraDX Docs - +

What are AMMs?

This article provides an introduction to Automated Market Makers (AMMs) together with some of their underpinning concepts such as slippage, liquidity provisioning and impermanent loss.

This introductory information will help you understand better the mechanics behind the HydraDX Omnipool which you can find described in our product documentation.

A Short Intro into AMMs

To explain Automated Market Makers (AMMs) and how they work, we can contrast them to their centralized counterpart: Order books.

Order Books

Order books provide a mechanism which is deployed by centralized exchanges to facilitate trading between two assets. Users can place a Buy or Sell order in an electronic list managed by the exchange. The orders in this so-called Order Book are organized by price level and progressively filled as demand shifts and orders are being matched. The limitations of order books become apparent against the background of their centralized nature.

The need for an intermediary to “keep” the order book and to facilitate the process of order matching creates a dependency on a central authority. This central authority has control over the trading and needs to be trusted by the participants. In times of substantial volume traffic and volatility, the central authority can decide to halt trading and stop performing its market-making function. Furthermore, the process of adding new tradable assets is permissioned and projects may need to pay in advance to get their assets listed.

AMMs

Automated Market Makers (AMMs) is the answer by the DeFi industry to order books. AMMs provide a decentralized, permissionless way of trading tokens without the need to subdue oneself to a central authority of control.

AMMs consist of liquidity pools that hold the available liquidity of the underlying tradable assets. This liquidity is provided by users (the so-called “liquidity providers”) who are incentivized to do so by the prospect of earning rewards from the fees generated by trades in the pool.

In the case of AMMs, any user can execute a Buy or Sell order on top of a given trading pool. The price of the trade is determined on the spot by a deterministic algorithm which takes as input the relationship between the liquidity of the traded assets, together with other factors which depend on the particular AMM implementation.

Slippage

When a trade is executed, users may experience a common side-effect of AMMs known as slippage. This is the difference between the expected price of a trade and the price when the trade is actually executed.

Slippage is determined by the amount of liquidity available within the trading pool. If there is a low amount of liquidity provided for the asset, then the slippage percentage when transacting with big orders will be higher.

Providing Liquidity

Thanks to the decentralized nature of an AMM, anyone can become a liquidity provider (LP) for a liquidity pool by depositing some amount of value in return for a token representing their liquidity position.

LPs are rewarded with fees for providing this liquidity based on the trading activity experienced by the asset for which they have provided liquidity.

Impermanent Loss (IL)

Impermanent loss (IL) is a risk faced by liquidity providers which embodies the difference in value between holding tokens in an AMM as opposed to holding them in your wallet.

Liquidity pools consist of multiple tokens (usually two) which are pooled together. IL occurs when the tokens inside the pool diverge in price. The greater the divergence, the greater the risk of negative returns for the pool's LPs.

The risk is referred to as "impermanent" because the loss is only realized when liquidity is withdrawn from the pool. If the relative prices of tokens in the pool return to their original state (when the tokens were deposited), the loss is minimized or eliminated. The loss will become permanent at the moment when the liquidity is withdrawn, leading to reduced earnings.

As such, LPs need to weigh the fees and rewards earned from LPing versus simply holding their tokens in their wallets.

- + \ No newline at end of file diff --git a/es/node_monitoring/index.html b/es/node_monitoring/index.html index c4846674..052b5254 100644 --- a/es/node_monitoring/index.html +++ b/es/node_monitoring/index.html @@ -4,7 +4,7 @@ Monitoreo de nodo | HydraDX Docs - + @@ -34,7 +34,7 @@ Colocarhttp://localhost:9090/ y clic Save and Test.

Importando the Dashboard

Por favor presione el bonton Plusen la navegacion principal y selecciona import.

Nosotros usaremos el HydraDX Dashboard y para cargarlo, simplemente ingrese el id 14158 y presione el botón Load.

No necesita mucha configuración aquí, solo asegúrese de que Prometheus se use como fuente de datos. Ahora puede finalizar la importación.

Ahora debería ver su panel de control de inmediato. Si algunos paneles están vacíos, asegúrese de que su selección sobre los paneles sea así:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/es/omnipool_dca/index.html b/es/omnipool_dca/index.html index c6d6146f..6c22d4d6 100644 --- a/es/omnipool_dca/index.html +++ b/es/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA Trading | HydraDX Docs - +

DCA Trading

HydraDX DCA and Split Trade (easy DCA) are two user-friendly features which allow traders to implement the dollar-cost-averaging (DCA) strategy when trading in the Omnipool - in a permissionless and non-custodial way.

Following the DCA strategy, orders are not placed at once but instead split into smaller trades which are executed at regular intervals of time. By doing so, traders may protect themselves against price volatility and achieve an average price. Additionally, splitting a large order in smaller chunks will result in less slippage.

HydraDX has two DCA implementations - the full DCA feature, and Split Trade (easy DCA) which can be found on the main trading page. Further down, you can learn more about these features.

If you are looking for step-by-step guidance, check out the how-to place a DCA order guide.

HydraDX DCA

HydraDX DCA provides an intuitive UI which enables users to fine-tune their DCA orders in the Omnipool.

When setting up their order, users specify the amount of Asset A they would like to spend in order to obtain Asset B, as well as the frequency of the trades - in hours (approximation) or number of blocks (more granularity).

After placing the order, the HydraDX DCA pallet makes sure that trades are scheduled at the specified intervals until the predetermined amount of Asset A has been spent. Placing multiple DCA orders which are executed in parallel is supported.

Users can track the status of their orders on the UI. Open orders can at any time be terminated for the remaining amount.

Split Trade (easy DCA)

Split Trade is a more simple implementation of DCA directly into the main trade page. It provides users with a one-click solution for splitting larger orders in order to protect themselves from slippage.

When activated, Split Trade will split the order in smaller chunks until the size of the trades is small enough to achieve <0.1% slippage (estimate only - the exact slippage for future trades can never be predicted in advance).

Open Split Trade orders can be terminated by the user at any time, just like any regular DCA order.

- + \ No newline at end of file diff --git a/es/omnipool_design/index.html b/es/omnipool_design/index.html index a5f6b200..793eeead 100644 --- a/es/omnipool_design/index.html +++ b/es/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool Design | HydraDX Docs - + @@ -46,7 +46,7 @@ c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).

- + \ No newline at end of file diff --git a/es/omnipool_hydrated_farms/index.html b/es/omnipool_hydrated_farms/index.html index 238878f4..e85e5f0b 100644 --- a/es/omnipool_hydrated_farms/index.html +++ b/es/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ Hydrated Farms | HydraDX Docs - +

Hydrated Farms

Hydrated Farms are time-limited incentives programs which offer additional rewards for providing liquidity for selected assets, on top of the rewards from trading fees.

Departing from traditional liquidity mining programs, Hydrated Farms offer several distinctive features: they use Farm NFTs to represent the farm position, they support rewards stacking, and their rewards grow over time thanks to a loyalty multiplier.

On this page you will find further details on the features of Hydrated Farms. If you would like to participate, please visit our step-by-step guide on Hydrated Farms.

Farm NFTs

Whenever a user provides liquidity to the Omnipool and joins a Hydrated Farm, the HydraDX Protocol will mint an NFT which is owned by the user. This NFT represents the user position in the farm and stores certain details such as time of entry. This enables the Protocol to provide sustainable incentives with rewards which grow over time.

The owner of the farm NFT controls the position in the farm as well the underlying liquidity in the Omnipool. In the future, Protocol stakeholders may decide to open up a marketplace for Farm NFTs or enable their usage as collateral.

note

Due to the unique properties of the Farm NFTs, joining a given farm multiple times will yield several NFTs.

Rewards Stacking

Hydrated Farms support the possibility to offer rewards in more than one asset. In other words, rewards are stackable.

Any team can reach out to the HydraDX stakeholders with the request to create a Hydrated Farm incentivized by their own TKN. Following this example, the HydraDX governance can decide to also provide HDX as incentives to that farm. As a result, hydrated farmers would receive both HDX and TKN rewards.

Loyalty Multiplier

To encourage more sustainable liquidity provisioning, Hydrated Farms feature a loyalty multiplier - rewards grow over time as liquidity remains in the farm. You can view the exact curve for distributing rewards on the farm detail page.

Once users decide to leave a farm, their loyalty multiplier is reset and they will begin from the base level again if they decide to rejoin.

- + \ No newline at end of file diff --git a/es/omnipool_impermanent_loss/index.html b/es/omnipool_impermanent_loss/index.html index f37b0b3c..e58fb32e 100644 --- a/es/omnipool_impermanent_loss/index.html +++ b/es/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ Less Impermanent Loss | HydraDX Docs - + - + \ No newline at end of file diff --git a/es/omnipool_lp/index.html b/es/omnipool_lp/index.html index eb89264a..a21f9ba2 100644 --- a/es/omnipool_lp/index.html +++ b/es/omnipool_lp/index.html @@ -4,13 +4,13 @@ Single-Sided LPing | HydraDX Docs - +

Single-Sided LPing

The cutting-edge design of the HydraDX Omnipool unlocks the possibility of single-sided liquidity provisioning: Anyone can provide liquidity only for the asset they want, and as much as they want (up to the respective TVL cap for the asset). This resolves one of the main drawbacks of standard XYK AMMs which require that liquidity providers (LPs) deposit a pair of assets in equivalent value.

Liquidity in the HydraDX Omnipool is concentrated, meaning that by providing your asset you gain instant exposure to all other assets in the Omnipool. Forget about liquidity fragmentation and the need to spread your liquidity across several trading pools.

The Hub Token LRNA

Single-sided liquidity provisioning is made possible by our hub token called Lerna (LRNA). Every time liquidity is added, the Omnipool will mint a corresponding amount of LRNA to keep the pool in balance. Accordingly, LRNA will be burnt to reflect any removal of liquidity. These mechanisms ensure that the value of LRNA does not significantly fluctuate when assets are added or removed from the Omnipool.

login

Another way to understand the hub token concept is to imagine every single asset within the Omnipool as a synthetic 50/50 liquidity pool, with the only difference being that the 2nd leg of the pair is always LRNA i.e. TKN:LRNA.

This design allows the Protocol to use LRNA as a proxy which reflects the value locked in the Omnipool, including trading activity and price fluctuations, in an abstract manner.

- + \ No newline at end of file diff --git a/es/omnipool_security/index.html b/es/omnipool_security/index.html index 96b4dd45..ec0b097a 100644 --- a/es/omnipool_security/index.html +++ b/es/omnipool_security/index.html @@ -4,13 +4,13 @@ State of the Art Security | HydraDX Docs - +

State of the Art Security

The HydraDX Protocol pursues a multi-layered security strategy. On this page you will find a description of the various measures which work together to keep your funds safe.

The most basic layer of the HydraDX security strategy consists carefully conducted research and development, as well as rigorous peer review processes. On top of that, HydraDX strives to have all mission-critical code undergo rigorous audits. The next layer of the security strategy is a generous bug bounty program which makes it worthwhile to find and disclose vulnerabilities (as opposed to exploiting them).

Finally, the protocol has implemented a combination of state-of-the-art measures which are designed to protect your liquidity against unfortunate events such as toxic assets or (economic) exploits.

Audits

The HydraDX protocol conducts audits of all mission-critical code and publishes the audit reports on a regular basis.

The security audit of the Rust implementation of the HydraDX Omnipool was performed by Runtime Verification - an established industry leader with clients such as NASA, Ethereum and Polkadot. The scope of the security audit includes the source code of HydraDX Omnipool pallet,its mathematical logic and asset registry, as well as 3rd party libraries which have been included as a (Substrate) dependency. The results of the audit were published in September 2022, you can consult the full report here.

In March 2022, the economic/math audit of the Omnipool was completed by BlockScience - a leading web3 native firm dedicated to analyzing complex systems for the likes of Graph Protocol and Protocol Labs (Filecoin). The scope of this audit was to provide an overview of the AMM specification with a special attention to the mathematical and economic concepts underpinning the Omnipool, together with the implications of those mechanisms for liquidity provisioning and trading activity. You can consult the full report here, including the addendum by HydraDX with post-factum changes.

Bug Bounty Program

HydraDX has set up a generous bug bounty program which provides strong incentives for the detection and responsible disclosure of bugs and other vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Mechanisms for Protecting Omnipool Liquidity

The HydraDX protocol is continuously researching and implementing mechanisms that keep the Omnipool liquidity safe. These mechanisms are activated in the unfortunate (but not impossible) scenario that an actor tries to drain liquidity from the Omnipool by abusing a toxic asset situation (LUNA-like scenario) or some malicious exploit.

TVL Caps

All assets are subject to a specific TVL cap defining the maximum proportion of liquidity which any given asset can represent in the Omnipool. Riskier assets will have lower caps compared to less risky (high mcap or stable) assets. This allows the HydraDX protocol to significantly limit the damage which may potentially be caused from toxic asset flows: Using a hyper-inflationary asset, attackers cannot drain more liquidity than its TVL cap.

Oracles

On-chain oracles provide average price information for a specified Omnipool asset during a given timeframe (e.g. 10 blocks). Oracles are an essential monitoring tool that allow the HydraDX protocol to detect irregularities and potential price manipulation attacks - and to act accordingly.

Dynamic Withdrawal Fees

To protect the Omnipool liquidity, all withdrawals of liquidity positions are subject to a fee. The withdrawal fee is dynamic, ranging between 0.01% and 1% of the total amount. The exact fee amount is determined at the time of withdrawal based on the asset in question.

The withdrawal fee covers the spread between the current spot price of the asset and the its average price over the previous 10 blocks (fetched from the HydraDX oracles). A large discrepancy between spot and average price indicates a potential price manipulation attack, and a higher withdrawal fee is applied to eliminate the economic incentives for carrying out such an attack.

In the scenario that extreme volatility leads to the spread between the spot price and average oracle price of an asset being greater than 1%, liquidity addition or withdrawal for that asset will be temporarily paused. These operations will again resume once this threshold is respected.

In-block Trade Limits

To protect the Omnipool against economic exploits, there is a limit in place that no more than 50% of an asset's liquidity can be traded in a single block - trades that are greater than this amount should be spread across multiple blocks.

Targeted Function Pausing

If some suspicious behaviour is detected on-chain, Targeted Function Pausing allows the HydraDX Technical Committee to take swift action and temporarily pause certain or all actions relating to specific assets. This action of last resort can help mitigate the damage and allow for further investigation.

- + \ No newline at end of file diff --git a/es/omnipool_trading/index.html b/es/omnipool_trading/index.html index 6ac358a8..c8113498 100644 --- a/es/omnipool_trading/index.html +++ b/es/omnipool_trading/index.html @@ -4,13 +4,13 @@ Efficient Trading | HydraDX Docs - +

Efficient Trading

The traditional DeFi landscape is characterised by fragmented liquidity which is dispersed across several trading pools. This leads to economic inefficiencies: More hops and shallower liquidity create higher price impact and slippage. By combining all liquidity in a single trading pool, the HydraDX Omnipool enables efficient trading like no other AMM.

Traditional AMMs: Liquidity Fragmentation

The pioneer XYK AMM model marked a pivotal moment for DeFi which made decentralized and permissionless trading possible. The simplicity of XYK pools boosted the initial adoption of DeFi, however today we stand at a point where the resulting economic inefficiencies hinder the continued adoption.

Omnipool

One of the flaws of the XYK model is that trading pools are constrained to pairs of assets. Fragmented liquidity results in a higher price impact due to more hops and slippage. The route of the ETH-AAVE trade in the screenshot above provides a practical example:

  • 85% direct from ETH to AAVE (incurring 0.3% fee);
  • 15% ETH traded for UNI first then the UNI is swapped for AAVE (incurring two 0.3% swap fees).

HydraDX Omnipool: Unified Liquidity

Thanks to the cutting-edge design, liquidity in the Omnipool truly acts as one. By having all the liquidity connected through LRNA, the assets within the Omnipool have direct access to the entirety of liquidity for any other asset that is also deposited into the Omnipool. This allows for a seamless on-chain execution and enables swaps to be completed in a single transaction with no hopping required between various isolated trading pools.

Furthermore, based on internal research, the increase in the number of tokens and total value locked (TVL) within the Omnipool lead to exponential improvements in slippage reduction.

login

To illustrate with an example, imagine the TKN asset is distributed across 4 different liquidity pools with varying levels of liquidity. In the scenario that a trader wants to trade DAI for TKN, they would only have access to the direct liquidity of the $1M TKN-DAI pool. If their trade size is substantial (e.g. $100K+), the majority of the trade will likely be routed through a DAI-ETH pool followed by the TKN-ETH pool in the traditional XYK landscape.

However, with the Omnipool, that same $5mm (50% of the total $10mm TVL) of the TKN asset and $3mm of DAI would be concentrated in one pool. As such, if a trader proceeds to make the same trade in the HydraDX Omnipool, they will get the entire benefit of the $5mm of TKN and $3mm of DAI liquidity in their direct swap, materially reducing the overall price impact.

- + \ No newline at end of file diff --git a/es/omnipool_treasuries/index.html b/es/omnipool_treasuries/index.html index 2880e219..0e042251 100644 --- a/es/omnipool_treasuries/index.html +++ b/es/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ Hydrate Your Treasury (B2B) | HydraDX Docs - +

Hydrate Your Treasury (B2B)

The HydraDX Omnipool has an outspoken value proposition for the treasury of any project or DAO. Forget about centralized market makers and inflationary rewards for liquidity mining; the Omnipool can facilitate the creation of a market for your token in a cost-efficient manner - trustless, without hidden costs and while building up your POL from trading fees.

Thanks to its cutting-edge design, the HydraDX Omnipool supports single-sided LPing. Instead of wastefully allocating liquidity mining rewards to incentivize other users to provide liquidity, projects and DAOs can deposit a part of their treasury to the Omnipool and receive instant exposure to all other assets in an ocean of liquidity: Diversified and deep (HydraDX has $20M+ worth of POL which is gradually being deployed).

LPing in the HydraDX Omnipool is truly trustless. Leveraging Polkadot’s unique capability of cross-chain communication (XCM), the Omnipool empowers you to always remain in control of your funds: You can both provide your liquidity and manage it without relying on third parties.

Providing liquidity to the HydraDX Omnipool is not only cost-efficient - it is also profitable. Instead of having your tokens sit idle in your treasury, you can put them to work. You will earn rewards from trading fees, allowing you to build up POL over time. Soon, our upcoming TWAMM/DCA feature will allow you diversify the accumulated POL in other assets (e.g. dollar cost averaged stablecoins or DOT which you can use to bid on your next parachain slot).

Finally, the HydraDX Omnipool enjoys state of the art security. Besides rigorous audits and a generous bug bounty program, we have set up a combination of measures which work together to keep your liquidity safe. Learn more here.

- + \ No newline at end of file diff --git a/es/participate_in_council_elections/index.html b/es/participate_in_council_elections/index.html index 61518609..098887d2 100644 --- a/es/participate_in_council_elections/index.html +++ b/es/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ Participar en las elecciones del consejo | HydraDX Docs - +

Participar en las elecciones del consejo

Este artículo proporciona una guía paso a paso sobre cómo participar en las elecciones del Consejo: votar por los miembros del Consejo y convertirse en candidato al Consejo.

Si está interesado en cómo funciona el mecanismo de elección, consulte esta publicación.

caution

El módulo de democracia HydraDX se lanzará a partir del 15 de septiembre de 2021. No intente ninguna de las acciones mostradas antes de esa fecha.

Usando Polkadot/apps

Votar en las elecciones de miembros del Consejo

Puede ver a los miembros actuales del Consejo, así como a los runners-up en la página Governance> Consejo en Polkadot/apps

Para mostrar su voto por los miembros del Consejo, haga clic en Voto.

Ingrese la cantidad de tokens que está dispuesto a bloquear para apoyar a sus candidatos.

Después de eso, seleccione sus candidatos en orden de preferencia moviéndolos de la lista de la izquierda a la derecha. Recuerde seleccionar varios candidatos: esto ayudará al algoritmo a seleccionar la distribución óptima de candidatos al Consejo.

Para mostrar su voto, haga clic en Voto y firme la transacción.

note

Los tokens bloqueados no se pueden transferir, sin embargo, aún se pueden usar para votar en referendos. Tus tokens seguirán siendo afortunados y se usarán para elecciones posteriores hasta que decidas desbloquearlos.

Aplicar a candidato del Consejo

Puede enviar su solicitud para ser miembro del Consejo navegando a Governance> Consejo en Polkadot/apps.

Click en Presentar a la candidatura que activará una ventana emergente.

Seleccione la cuenta que se está ejecutando para ser miembro del Consejo, haga clic en Enviar y firme la transacción.

- + \ No newline at end of file diff --git a/es/participate_in_referenda/index.html b/es/participate_in_referenda/index.html index 2006e573..df10a00e 100644 --- a/es/participate_in_referenda/index.html +++ b/es/participate_in_referenda/index.html @@ -4,13 +4,13 @@ Participar en Referéndums | HydraDX Docs - +

Participar en Referéndums

Esta publicación proporciona una guía paso a paso sobre cómo participar en referéndums: votar y proponer. Hay dos herramientas alternativas que puede utilizar para este propósito: Commonwealth.im o Polkadot/apps.

Antes de que decida participar, le recomendamos encarecidamente que lea este artículo en la sección Aprender / Democracia. Allí encontrará algunos detalles importantes sobre la mecánica de los referendos.

caution

El módulo de democracia HydraDX se lanzará a partir del 15 de septiembre de 2021. No intente ninguna de las acciones mostradas antes de esa fecha.

Usando Commonwealth.im

Votar en un referéndum

Puede ver todos los referendos que están abiertos para votación navegando a la Referenda tab en la página HydraDX Commonwealth.

Para votar en un referéndum activo, debe hacer clic en él. Después de eso, verá una página que muestra todos los detalles relevantes..

En la sección Cast Your Vote, complete la siguiente información:

  • Cantidad para votar: esta es la cantidad de tokens HDX que está dispuesto a bloquear en apoyo del referéndum.
  • Multiplicador de convicciones: este es el multiplicador que co-determina el peso de su voto

Después de eso, saque su voto haciendo clic en Vote yes o Vote no y firme la transacción.

Proponer un referéndum

Para proponer un referéndum, visite la página de HydraDX Commonwealth y haga clic en el menú superior en New Thread > New democracy proposal.

Complete la información en los campos que se muestra arriba. Los parámetros más importantes son:

  • Module
  • Function
  • Cualquier información adicional según lo especificado por la función a la que está proponiendo que se realice
  • Depósito: la cantidad de tokens HDX que está dispuesto a depositar para respaldar la propuesta.

En el ejemplo anterior, el módulo de propuesta es balances y la función es setBalance, que modifica los saldos libres y de reserva de una cuenta determinada.

Para enviar la propuesta, haga clic en Send transaction y firme con su billetera.

Después de enviar la propuesta on-chain y firmar la transacción, su propuesta debe aparecer en la list of proposed referenda.

caution

En cada período de votación, la propuesta de referéndum con el mayor respaldo (secundando) ingresa a la ronda de votación. A medida que aumenta la cantidad de referendos, no hay garantía de que su propuesta obtenga el apoyo suficiente para entrar en votación. No hay opción para retirar una propuesta de referéndum, lo que significa que sus fondos pueden permanecer bloqueados por un período de tiempo más largo.

Las propuestas de referéndum maliciosas son castigadas. El Consejo de HydraDX y el Comité Técnico tienen derecho a cancelar cualquier referéndum propuesto de mala fe. Como resultado, los tokens depositados se quemarán.

Usando Polkadot/apps

Votar en un referéndum

Puede ver todos los referendos que están abiertos para votación navegando a Governance> Democracia en Polkadot/apps.

Para votar en un referéndum, haga clic en el botón Votar al lado

En la ventana emergente, complete la siguiente información:

  • Valor de voto: esta es la cantidad de tokens HDX que está dispuesto a bloquear en apoyo del referéndum.
  • Multiplicador de convicciones: este es el multiplicador que co-determina el peso de su voto.

Después de eso, saque su voto haciendo clic en Vote Nay (No) o Vote Aye (Sí) y firme la transacción.

Proponer un referéndum

Proponer un referéndum a través de Polkadot/apps consta de dos pasos: enviar una preimagen y enviar la propuesta on-chain.

01 Enviar preimagen

Para enviar la preimagen, visite Polkadot/apps y navegue hasta Governance > Democracia.

Después de hacer clic en Enviar preimagen, debería ver la siguiente ventana emergente:

Complete la información en los campos que se muestran arriba. Los parámetros más importantes son:

  • Enviar desde la cuenta
  • Área donde dice Proponer
  • Acción propuesta

En el ejemplo anterior, el área de propuesta es balances y la acción es forceTransfer de tokens de una cuenta a otra.

Antes de enviar la preimagen y firmar la transacción, asegúrese de copiar el hash de la preimagen. Lo necesitará para el siguiente paso.

02 Subir propuesta

Para presentar la propuesta de referéndum, visite Governance > Democracia en Polkadot/apps.

Después de hacer clic en Subir propuesta, debería ver la siguiente ventana emergente:

Ingrese el hash de la preimagen del paso anterior y la cantidad de tokens que está dispuesto a depositar para la propuesta. El mínimo es 100.000 HDX.

Después de enviar la propuesta on-chain y firmar la transacción, su propuesta debería aparecer en la lista de referendos propuestos.

caution

En cada período de votación, la propuesta de referéndum con el mayor respaldo (secundando) ingresa a la ronda de votación. A medida que aumenta la cantidad de referendos, no hay garantía de que su propuesta obtenga el apoyo suficiente para entrar en votación. No hay opción para retirar una propuesta de referéndum, lo que significa que sus fondos pueden permanecer bloqueados por un período de tiempo más largo.

Las propuestas de referéndum maliciosas son castigadas. El Consejo de HydraDX y el Comité Técnico tienen derecho a cancelar cualquier referéndum propuesto de mala fe. Como resultado, los tokens depositados se quemarán.

- + \ No newline at end of file diff --git a/es/performance_benchmark/index.html b/es/performance_benchmark/index.html index e1e68505..e2030cba 100644 --- a/es/performance_benchmark/index.html +++ b/es/performance_benchmark/index.html @@ -4,13 +4,13 @@ Benchmark de desempeño | HydraDX Docs - +

Benchmark de desempeño

Puede asegurarse de que su máquina cumpla con las especificaciones técnicas requeridas ejecutando una evaluación comparativa de rendimiento. Para hacerlo, siga los pasos a continuación:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Prepare for running the benchmark
## Install Rust following https://rustup.rs
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

## Configure Rust
$ ./scripts/init.sh
$ rustup default nightly

## Install additional libraries
$ apt install python3-pip
$ apt install clang

# Run the benchmark
$ ./scripts/check_performance.sh

Después de que se ejecute benchmark, debería ver un resultado similar al siguiente:

         Pallet          |   Time comparison (µs)    |  diff* (µs)   |   diff* (%)    |            |   Rerun
amm | 773.00 vs 680.00 | 93.00 | 12.03 | OK |
exchange | 804.00 vs 720.00 | 84.00 | 10.44 | OK |
transaction_multi_payment| 218.00 vs 198.00 | 20.00 | 9.17 | OK |

Notes:
- in the diff fields you can see the difference between the reference benchmark time and the benchmark time of your machine
- if diff is positive for all three pallets, your machine covers the minimum requirements for running a HydraDX node
- if diff deviates by -10% or more for some of the pallets, your machine might not be suitable to run a node

Puede ver la diferencia en el rendimiento entre su máquina y la configuración mínima requerida en la columna diff* (%). Si los tres valores de esta columna son positivos, su máquina debería ser adecuada para ejecutar un nodo validador HydraDX. Si alguno de los valores está por debajo de -10%, no recomendamos ejecutar un nodo HydraDX.

Únase a nosotros en Discord si desea discutir sus resultados de referencia, nuestra comunidad siempre estará feliz de ayudar.

- + \ No newline at end of file diff --git a/es/polkadotjs_apps_local/index.html b/es/polkadotjs_apps_local/index.html index 1872f20b..1f77b485 100644 --- a/es/polkadotjs_apps_local/index.html +++ b/es/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ Conectarse a un nodo local | HydraDX Docs - +

Conectarse a un nodo local

Puede usar Polkadot/apps para conectarse a su nodo HydraDX local. Para este propósito, necesita tener acceso al puerto 9944 que se usa para conexiones de websocket RPC.

danger

Si está ejecutando el nodo como un validador, le recomendamos encarecidamente que ponga en la lista negra el puerto 9944 para conexiones remotas. Este puerto podría ser abusado por terceros para degradar el rendimiento de su nodo, lo que puede resultar en cortes y pérdidas involuntarias de fondos. Debe usar el puerto 9944 para conectarse a su nodo validador solo cuando el nodo está en su red local.

Accediendo a su nodo local usando Polkadot/apps

Para acceder a tu nodo usa Polkadot/apps y haga clic en en la esquina superior izquierda para cambiar la red.

Luego de abrir el menu, haga clic en desarrollo y selecciona Nodo local.

Ajuste la IP si es necesario y haga clic en Switch para cambiar a su nodo local.

Ahora debería estar conectado a su nodo local y poder interactuar con él.

- + \ No newline at end of file diff --git a/es/polkadotjs_apps_public/index.html b/es/polkadotjs_apps_public/index.html index e0297902..a43ef7e2 100644 --- a/es/polkadotjs_apps_public/index.html +++ b/es/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ Conectarse a un nodo público | HydraDX Docs - +

Conectarse a un nodo público

Hay dos nodos RPC públicos que son mantenidos por HydraDX y nuestros socios. Puede utilizar estos nodos para interactuar con Snakenet. Puede conectarse directamente a un nodo público con Polkadot/apps haciendo clic en los enlaces a continuación:

Conectarse manualmente a un nodo RPC

Para acceder a un nodo RPC público manualmente, abra Polkadot/apps y haga clic en en la esquina superior izquierda para cambiar la red.

Clic en REDES EN FUNCIONAMIENTO y selecciona HydraDX.

Seleccione uno de los nodos y haga clic en Switch.

Ahora debería estar conectado al nodo RPC público seleccionado.

- + \ No newline at end of file diff --git a/es/spending_fw/index.html b/es/spending_fw/index.html index cd6ce915..9cf6685d 100644 --- a/es/spending_fw/index.html +++ b/es/spending_fw/index.html @@ -4,13 +4,13 @@ Contribute to HydraDX | HydraDX Docs - +

Rewarding Contributions to HydraDX

HydraDX welcomes various contributions which are in the interest of the Protocol. Such activities are incentivized with the help of rewards from the HydraDX Treasury.

The present document sets out the general framework for rewarding community contributions. This framework has been approved by the community of HydraDX in a general vote. The spending framework empowers payouts in the mentioned categories by the HydraDX Council, within the defined limits.

Please note in advance that the payout of all bounties and tips mentioned in this document is subject to the full discretion of the HydraDX Council. If you are in doubt whether your effort entitles you to a bounty, please reach out in advance.

You can ask questions in #bounties on the HydraDX Discord.

1. Bug Bounties

HydraDX runs a Bug Bounty program on Immunefi. Bugs and vulnerabilities are classified into three to four categories of severity which determine the maximum size of the bounty:

Blockchain:

  • Critical: $50,000 to $1,000,000;
  • High: $5,000 to $50,000;
  • Medium: $5,000;
  • Low: $1,000.

Websites & Apps:

  • Critical: $5,000 to $50,000;
  • High: $5,000;
  • Medium: $1,000.

Notes:

  • In order to be granted a bounty, bug reports must be made in accordance with the procedure for responsible disclosure and any other guideline posted on the HydraDX Immunefi page;
  • Bounties for critical Blockchain vulnerabilities are capped at 10% of the potential economic damage;
  • The actual size of the rewarded bounties is at the discretion of the Council;
  • Bounties are paid by the treasury in HDX using the 7d MA USD price from an exchange (CEX or DEX once Oracles are available - if in doubt, please discuss with the HydraDX Council in #bounties).

2. Development Bounties

The HydraDX development team will be launching a dashboard with development bounties in an effort to decentralize technical work on the protocol. The dashboard will present the latest bounties together with a description, technical specification and size of the bounty.

The present framework authorizes the HydraDX Council to propose development bounties of up to $100,000 which will be paid by the Treasury in HDX using the 7d MA USD price from an exchange. Bounties exceeding this amount still need to undergo the governance process.

3. Community Management

Efforts spent on Community Management can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange).

New community managers are subject to prior approval by the team.

Here are some of the expectations attached to these roles:

  • Moderate on both Telegram and Discord;
  • Be an ambassador for the project;
  • Show activity on socials;
  • Participate in bi-weekly calls with other community managers;
  • Coordinate translations
  • Ideally already an active member of the Hydra community.

4. Translations

Work on translations can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange). Currently, HydraDX welcomes translations in the following languages (this list can be extended via a referendum):

  • Mandarin
  • Spanish
  • Russian
  • Slovak

New translators are subject to prior approval by the Community Managers and/or HydraDX Council.

5. Other Community Contributions

Are you looking to contribute with an effort which does not fall into one of the categories above? Please feel free to reach out, the HydraDX Council is prepared to consider your case. This spending framework authorizes the HydraDX Council to provide tips up to the value of $100,000 (using the 7d MA USD price from an exchange).

Here are some examples of contributions that could be rewarded:

  • Creating good educational content such as guides, explanative blogs or videos [content creator should liaise with Community Managers & HydraDX Council ahead of and during production process to ensure information is of the highest quality];
  • Provisioning Decentralized infrastructure;
  • Advancing integrations which contribute to the Protocol or the community;
  • Memes (!!), emojis, merch and stickers.
- + \ No newline at end of file diff --git a/es/staking/index.html b/es/staking/index.html index 699c244c..20624ae8 100644 --- a/es/staking/index.html +++ b/es/staking/index.html @@ -4,13 +4,13 @@ Staking | HydraDX Docs - +

Staking

HydraDX has a long-running HDX staking program which incentivizes user activity in areas that are beneficial to the Protocol. On this page you will find important information regarding the mechanics behind the HDX Staking program. You can also check out our step-by-step guide on staking.

Staking Basics

HDX holders can stake their HDX and receive rewards which become claimable as time passes. Staking rewards are distributed from a dedicated pot that is gradually filled up by different Protocol revenue streams. Initially, the main revenue stream are the LP fees which the HydraDX Protocol accrues from its HDX LP position in the Omnipool. Furthermore, the HydraDX community has approved a proposal to support the APR during the first year of the staking program with an additional subsidy of ~22M HDX from the HydraDX Treasury which is gradually distributed to the staking rewards pot once per day.

Rewards which enter the staking pot are always distributed directly to all stakers at any given moment. The amount that users are entitled to is proportional to the relative size of their stake in the stake pool. However, stakers do not automatically receive the rewards on their account - instead, they need to claim them.

When it comes to claiming rewards, all participants in HDX staking should be aware of the elements of loyalty and gamification. Once rewards are awarded, they cannot be instantly claimed for the full amount - doing so would yield just a fraction of the total rewards, with the remainder being returned the pot for redistribution to all stakers.

Users who want to claim as many rewards as possible should keep their HDX staked without claiming until sufficient time has passed (rewards are “vested” following a bonding curve). The length of the waiting period is dynamic and depends on the user (in)actions. A user who just stakes passively would need to wait ~2 years to claim 95% of their rewards. In contrast, active stakers who collect the maximum amount of action points (more on that below) could claim 95% of their rewards in just over 2 months. These are rough estimates - the actual timelines may vary in accordance with user actions and overall count of referenda.

Boosting Your Rewards

Stakers can increase the pace at which they can claim their rewards by collecting action points and boosting their rewards. Action points can be acquired by performing certain actions that are incentivized by the Protocol. Initially, the only way to collect action points is to participate in the governance of HydraDX by voting on community referenda using the staked HDX.

login

There are 2 factors which determine the amount of action points that stakers will receive: The size of the vote (relative to the total size of their staked HDX), and the conviction multiplier. The higher the conviction multiplier of the vote, the greater its weight. Keep in mind that voting with a conviction multiplier places a temporary lock on the tokens. Stakers looking to achieve the highest rewards boost would be voting with 6x conviction multiplier, thereby locking their HDX for 192 days (counted from the last vote using such conviction). Just a reminder that this lock is not related to staking as such - instead, it is a standard feature of governance in the Polkadot ecosystem (more info in our docs).

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d

Claiming Your Rewards

As they keep their HDX staked, users accumulate rewards over time. These rewards become claimable subject to a bonding curve which is influenced by the boosts from action points (see above).

At any given time, stakers can claim (a portion of) their claimable rewards. By doing so, however, they forfeit the remainder of their non-claimable rewards. These rewards are automatically transferred back to the staking rewards pot which redistributes them to all other stakers. Furthermore, claiming resets the past action points of the user, sending users back to the beginning of the bonding curve for future rewards from staking.

This mechanism creates an interesting gamification dynamic: By remaining longer in the pool of stakers, users not only unlock a greater part of their allocated rewards - they also have the chance to receive a juicy portion of rewards from other stakers who claim or exit early.

Happy staking!

- + \ No newline at end of file diff --git a/es/testnet_howto/index.html b/es/testnet_howto/index.html index fcaedb6e..c8127f41 100644 --- a/es/testnet_howto/index.html +++ b/es/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/es/tip_request/index.html b/es/tip_request/index.html index 4edc98e6..5481ccd0 100644 --- a/es/tip_request/index.html +++ b/es/tip_request/index.html @@ -4,13 +4,13 @@ Soliciar tips de la Tesorería | HydraDX Docs - +

Soliciar tips de la Tesorería

Con el lanzamiento del Programa de incentivos HydraDX New Deal , los miembros de la comunidad pueden solicitar tips a la Tesorería como recompensa por sus contribuciones. Con esta guía, podra tener un paso a paso, del proceso de solicitud de tips. Puede encontrar más información sobre los diferentes tipos de actividades que se recompensan en este post.

El proceso para solicitar tips a la Tesorería consta de dos pasos. En el primer paso, los contribuyentes deben publicar su solicitud de tips en Commonwealth.im con una descripción de la contribución. Como segundo paso, la solicitud de tips a la Tesorería debe enviarse on-chain utilizando Polkadot/apps.

01 Publica la solicitud del tips en Commonwealth.im

Para salvaguardar la transparencia, todas las solicitudes de tips a la Tesorería deben publicarse en un hilo en la pagina de HydraDX Commonwealth. Before opening a thread, you need to link your HydraDX wallet to Commonwealth.im: Click Log in (top right corner) and select Connect with wallet > polkadot-js.Antes de abrir un hilo, debe vincular su billetera HydraDX a Commonwealth.im: haga clic en Log in (esquina superior derecha) y seleccione Continue with wallet > polkadot-js

login

Después de seleccionar su dirección HDX en la ventana emergente, se le pedirá que firme el mensaje con su billetera y que configure un nombre para mostrar con esta billetera.

Una vez que haya iniciado sesión, debe crear un nuevo hilo para su solicitud del tip. Navegue a la parte superior derecha de la página y haga clic en on New thread > New thread. También puede utilizar este link directamente: https://commonwealth.im/hydradx/new/thread .

Puede utilizar el título del hilo para indicar el tema (tip request) y el tema de la contribución. En el cuerpo del hilo, proporcione la siguiente información en ingles por favor:

  • Periodo en el que se realizó la contribución
  • Un breve resumen de la contribución
  • El monto del tip solicitado (en HDX)
  • Tiempo dedicado a la contribución (en horas)
  • Si es apropiado, proporcione información más detallada así como la relevancia de la contribución a HydraDX, y a su vez el link al PR(en caso de ser una contribución técnica)

Como referencia, puede echar un vistazo a esta solicitud como ejemplo.

Después de completar la información, publique el hilo y debería estar disponible en la lista general.

note

Los nominadores y validadores que hicieron bond de todo su HDX y se "atascaron" pueden solicitar un tip de la Tesorería con valor de 1 HDX que les permitirá hacer unbond de algunos de sus tokens. Si esto se aplica a su caso, cree un hilo de Commonwealth siguiendo este ejemplo.

02 Envía la solicitud del Tip On-Chain

Después de publicar su solicitud de Tips de la Tesorería, debe enviarla de modo on-chain. Para este propósito, su billetera debe contener una pequeña cantidad de HDX para cubrir el fees de la transacción. Si actualmente no tiene ningún HDX, no es necesario que ejecute este paso; alguien más enviará su solicitud del tip on-chain por usted.

Las solicitudes de los tips de la Tesorería se pueden enviar on-chain con Polkadot/apps usando el siguiente link: https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/treasury/tips.

Para enviar una nueva solicitud de propina, haga clic en Proponer gratificación y proporcione la siguiente información:

  • enviar con la cuenta - seleccione la cuenta que firmará la transacción para enviar la solicitud del tip on-chain. Esta cuenta debe tener una pequeña cantidad de HDX para los fees.
  • beneficiario - seleccione o ingrese la dirección de la cuenta que recibirá el tip de la Tesorería. Esta cuenta debe corresponder a la cuenta que abrió el hilo de Commonwealth.
  • razón de la propina - proporcione el URL al hilo correspondiente a su Tip de Commonwealth.
login

Para enviar la solicitud del tip, haga clic en Proponer gratificación y firme la transacción.

Una vez que se confirma la transacción, debería ver la solicitud de propina en la página de descripción general.

login
- + \ No newline at end of file diff --git a/es/tokenomics/index.html b/es/tokenomics/index.html index 9f3d2079..b45408d0 100644 --- a/es/tokenomics/index.html +++ b/es/tokenomics/index.html @@ -4,13 +4,13 @@ HDX Tokenomics | HydraDX Docs - +

HDX Tokenomics

Purpose

The HDX token is a governance token that allows staked token holders to decide the future of the protocol. Our mission with the HydraDX DAO is to distribute all decision-making to create a trustless liquidity protocol built around community-growth and self-sustainability.

To have a vote in the HydraDX DAO, and to contribute to the determination of any of the topics raised by community members, one must hold the HDX governance token. For more specifically on the governance process, please read our Democracy documentation.

HDX will initially be used for the following:

  • Setting the base network swap fee (the user may change this to any asset)
  • Voting on protocol upgrades
  • Voting on topics raised by community members (inclusive of allocation of Protocol-Owned Liquidity)

HDX Token Allocation

Upon the launch of the HydraDX DAO, the defined maximum supply of HDX tokens was 10 billion HDX. However through the governance-approved supply reduction, this defined maximum supply was reduced to 6.5 billion HDX tokens.

The allocation of these tokens is currently as follows:

  • LBP Participants - 30.5% (~1.983B)
  • Founders and team - 12.5% (810M)
  • Investors - 10.6% (690M)
  • HDX Crowdloan - 7.6% (~494.6M)
  • BSX Crowdloan - 1.9% (~120.7M)
  • DAO treasury - 5.5% (~354.5M)
  • Collators - 3.9% (~251.5M)
  • Growth - 27.6% (~1.796B)

HDX Emission Schedule

As of Sept 2023, ~2.6 billion of HDX tokens are in circulation.

There is currently no concrete emission/release schedule for HDX tokens residing in the Treasury and Growth allocations. HydraDX intends to distribute the supply of HDX in the treasury and growth funds to help fund ecosystem development where opportunities may arise. All of these distributions will be discussed transparently to the community beforehand and voted on by the HydraDX DAO.

Token distributions range from a variety of developmental purposes and growth initiatives, (eg. HDX bonds, liquidity provider rewards, integrations/partnerships with other projects, etc).

- + \ No newline at end of file diff --git a/fr/404.html b/fr/404.html index 9b5ebe04..7f2c9463 100644 --- a/fr/404.html +++ b/fr/404.html @@ -4,13 +4,13 @@ Page introuvable | HydraDX Docs - +

Page introuvable

Nous n'avons pas trouvé ce que vous recherchez.

Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.

- + \ No newline at end of file diff --git a/fr/archive_hydradx_crowdloan/index.html b/fr/archive_hydradx_crowdloan/index.html index ae51e96a..e821a87f 100644 --- a/fr/archive_hydradx_crowdloan/index.html +++ b/fr/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX Crowdloan | HydraDX Docs - +

HydraDX Crowdloan

danger

This page has been archived, meaning that the information it contains may be outdated or no longer applicable.

The HydraDX crowdloan for the Polkadot parachain auctions is now live! You can support HydraDX by participating in our crowdloan campaign and pledging some amount of DOT tokens which will be locked up for the duration of the parachain slot.

In return, you will be granted HDX rewards which cover your opportunity costs. Once the parachain slot has expired, you will receive your DOT tokens back in full. The same applies to the scenario that HydraDX does not manage to win a parachain slot within the crowdloan campaign deadline stated hereunder.

Crowdloan Details

  • Visit: https://loan.hydradx.io/
  • Crowdloan start: 28 December 2021
  • Bidding on slots: #6 - #11
  • Onboarding of winning parachains: 11 March 2022
  • End of leased parachain slots: 12 January 2024
  • Crowdloan cap: 8,000,000 DOT
  • Rewards: between 280 and 12.5 HDX per contributed DOT
  • Rewards cap: max. 1,000,000,000 HDX (10% of total supply)
  • Vesting period: HDX rewards are distributed linearly. The distribution will start after HydraDX has been onboarded as a Polkadot parachain and the transition from Snakenet (our testnet) has been completed.
  • Crowdloan campaign deadline: 12 March 2022

HDX Rewards

All participants in the HydraDX crowdloan will receive HDX in exchange for their contributions. The amount of the rewards depends on our rank in the parachain auction race at the time of your contribution, as well as the total amount of DOT which have been contributed by others.

Contributions made before HydraDX is leading the race by 15% will receive the highest amount of rewards - between 280 and 125 HDX per contributed DOT.

After we have secured a comfortable lead, the rewards will start dropping linearly. They will be at their lowest level once HydraDX has a lead of 25% or more. Contributions made during the time that we are leading by more than 25% will receive between 28 and 12.5 HDX per contributed DOT.

The rewards system is designed to offset the opportunity costs of locking your DOT for the duration of the parachain lease, as opposed to staking it. Contributions made before we have gained a 15% lead will get their full opportunity costs reimbursed. The price of HDX used for the calculation is $ 0.026. This number is based on the closing HDX LBP price of $ 0.08 (February 2021), after taking into account the upcoming tripling of all balances which were built up during our testnet.

- + \ No newline at end of file diff --git a/fr/assets/js/d631f7a2.7f68e0f8.js b/fr/assets/js/d631f7a2.a737484b.js similarity index 70% rename from fr/assets/js/d631f7a2.7f68e0f8.js rename to fr/assets/js/d631f7a2.a737484b.js index b5381e75..61f7a809 100644 --- a/fr/assets/js/d631f7a2.7f68e0f8.js +++ b/fr/assets/js/d631f7a2.a737484b.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=n)&&Object.keys(o.O).every((function(e){return o.O[e](f[d])}))?f.splice(d--,1):(a=!1,n0&&e[i-1][2]>n;i--)e[i]=e[i-1];e[i]=[f,c,n]},o.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return o.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},o.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var n=Object.create(null);o.r(n);var r={};t=t||[null,f({}),f([]),f(f)];for(var a=2&c&&e;"object"==typeof a&&!~t.indexOf(a);a=f(a))Object.getOwnPropertyNames(a).forEach((function(t){r[t]=function(){return e[t]}}));return r.default=function(){return e},o.d(n,r),n},o.d=function(e,t){for(var f in t)o.o(t,f)&&!o.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},o.f={},o.e=function(e){return Promise.all(Object.keys(o.f).reduce((function(t,f){return o.f[f](e,t),t}),[]))},o.u=function(e){return"assets/js/"+({17:"0f5b2c31",31:"182ebef2",53:"935f2afb",548:"0b7119cc",574:"9deda591",791:"51f33e43",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1032:"7273c7bc",1467:"57a1d77e",1750:"8046228a",2250:"07178ad8",2332:"9fd70990",2730:"415223f0",2989:"7921dc2a",3452:"2c5c0c79",4020:"669853c7",4101:"1d2d6146",4609:"d06f888d",5130:"6202444b",5137:"05b760bf",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5510:"843686d8",5536:"5ae84af0",5888:"2cad9136",6295:"d2692880",6358:"cafe75eb",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7405:"847459cf",7615:"4756a152",7915:"d57ef520",7918:"17896441",7939:"dfd1ff83",8278:"8ff7c77a",8323:"70254ef3",8462:"dab19d87",8696:"a53b80d1",8741:"4ccf5e49",9096:"082eb71c",9219:"144c5974",9366:"c116d048",9514:"1be78505",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",31:"161da9d8",53:"8fdd79b8",548:"58339e54",574:"6fa6010e",791:"088834ca",942:"7f68e0f8",994:"576e620c",1019:"c1723447",1032:"abd26c43",1467:"6237f645",1750:"adbec9c1",2250:"df6b5854",2332:"0c64b022",2730:"ea0bbbff",2989:"e3b8209f",3452:"8d68b315",4020:"f6022812",4101:"1370076c",4609:"3fbdef19",4972:"79f8b409",5130:"af965268",5137:"d205a255",5183:"54194338",5355:"4031948e",5445:"828820a5",5488:"0ad59258",5510:"c6baeed3",5536:"f47f477a",5888:"a471ddfd",6295:"4f9ad0e4",6358:"63ee711e",6428:"9697d2d6",6714:"7cd76856",6880:"74feb9b6",7405:"89c64399",7615:"7cbb4ca4",7915:"1e669e8a",7918:"bff4c59e",7939:"b0a5fa5e",8278:"e57cf36e",8323:"8f3c92d3",8462:"d6955f84",8696:"43ada01e",8741:"b87f0bea",9096:"ee994b62",9219:"bd8e2789",9366:"d7dd043f",9514:"4cb072e6",9726:"75400fb1"}[e]+".js"},o.miniCssF=function(e){},o.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),o.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},c={},n="hydra-dx-docs:",o.l=function(e,t,f,r){if(c[e])c[e].push(t);else{var a,d;if(void 0!==f)for(var u=document.getElementsByTagName("script"),i=0;i=n)&&Object.keys(o.O).every((function(e){return o.O[e](f[d])}))?f.splice(d--,1):(a=!1,n0&&e[i-1][2]>n;i--)e[i]=e[i-1];e[i]=[f,c,n]},o.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return o.d(t,{a:t}),t},f=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},o.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var n=Object.create(null);o.r(n);var r={};t=t||[null,f({}),f([]),f(f)];for(var a=2&c&&e;"object"==typeof a&&!~t.indexOf(a);a=f(a))Object.getOwnPropertyNames(a).forEach((function(t){r[t]=function(){return e[t]}}));return r.default=function(){return e},o.d(n,r),n},o.d=function(e,t){for(var f in t)o.o(t,f)&&!o.o(e,f)&&Object.defineProperty(e,f,{enumerable:!0,get:t[f]})},o.f={},o.e=function(e){return Promise.all(Object.keys(o.f).reduce((function(t,f){return o.f[f](e,t),t}),[]))},o.u=function(e){return"assets/js/"+({17:"0f5b2c31",31:"182ebef2",53:"935f2afb",548:"0b7119cc",574:"9deda591",791:"51f33e43",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1032:"7273c7bc",1467:"57a1d77e",1750:"8046228a",2250:"07178ad8",2332:"9fd70990",2730:"415223f0",2989:"7921dc2a",3452:"2c5c0c79",4020:"669853c7",4101:"1d2d6146",4609:"d06f888d",5130:"6202444b",5137:"05b760bf",5183:"ff2c1298",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5510:"843686d8",5536:"5ae84af0",5888:"2cad9136",6295:"d2692880",6358:"cafe75eb",6428:"8cc7a8b7",6714:"b29c726d",6880:"8ab1c036",7405:"847459cf",7615:"4756a152",7915:"d57ef520",7918:"17896441",7939:"dfd1ff83",8278:"8ff7c77a",8323:"70254ef3",8462:"dab19d87",8696:"a53b80d1",8741:"4ccf5e49",9096:"082eb71c",9219:"144c5974",9366:"c116d048",9514:"1be78505",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",31:"161da9d8",53:"8fdd79b8",548:"58339e54",574:"6fa6010e",791:"088834ca",942:"a737484b",994:"576e620c",1019:"c1723447",1032:"abd26c43",1467:"6237f645",1750:"adbec9c1",2250:"df6b5854",2332:"0c64b022",2730:"ea0bbbff",2989:"e3b8209f",3452:"8d68b315",4020:"f6022812",4101:"1370076c",4609:"3fbdef19",4972:"79f8b409",5130:"af965268",5137:"d205a255",5183:"54194338",5355:"4031948e",5445:"828820a5",5488:"0ad59258",5510:"c6baeed3",5536:"f47f477a",5888:"a471ddfd",6295:"4f9ad0e4",6358:"63ee711e",6428:"9697d2d6",6714:"7cd76856",6880:"74feb9b6",7405:"89c64399",7615:"7cbb4ca4",7915:"1e669e8a",7918:"bff4c59e",7939:"b0a5fa5e",8278:"e57cf36e",8323:"8f3c92d3",8462:"d6955f84",8696:"43ada01e",8741:"b87f0bea",9096:"ee994b62",9219:"bd8e2789",9366:"d7dd043f",9514:"4cb072e6",9726:"75400fb1"}[e]+".js"},o.miniCssF=function(e){},o.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),o.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},c={},n="hydra-dx-docs:",o.l=function(e,t,f,r){if(c[e])c[e].push(t);else{var a,d;if(void 0!==f)for(var u=document.getElementsByTagName("script"),i=0;i Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/fr/build_dev_chain/index.html b/fr/build_dev_chain/index.html index b9ce2836..856f9be4 100644 --- a/fr/build_dev_chain/index.html +++ b/fr/build_dev_chain/index.html @@ -4,14 +4,14 @@ Configurer une chaîne de développement | HydraDX Docs - +

Configurer une chaîne de développement

Cette section vous guide tout au long du processus de configuration de votre instance locale HydraDX à des fins de développement.

01 installer les dépendances

Pour préparer une instance locale HydraDX pour le développement, votre machine doit avoir toutes les dépendances pour faire fonctionner une chaîne Substrate. Vous devrez installer un environnement de développement Rust et vous assurer qu'il est configuré convenablement pour compiler du code d'exécution Substrate pour une finalité en WebAssembly (Wasm).

Vous pouvez installer et configurer toutes les dépendances manuellement en suivant le guide de Substrate, ou vous pouvez utiliser le script suivant :

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Construire (build)

Construire le Wasm et les environnements d'exécution natifs:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Build the binary
$ cd HydraDX-node/
$ cargo build --release

Vous trouverez le build (la construction) dans le dossier suivant ./target/release/hydra-dx.

03 exécuter

Avant d'exécuter votre build vous pouvez purger n'importe quel chaîne de développement existante sur votre machine (vous devrez faire ça souvent dans le processus de développement):

$ ./target/release/hydra-dx purge-chain --dev

Exécuter votre build en utilisant une des commandes suivantes:

$ ./target/release/hydra-dx --dev

# Run with detailed logging
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Connectez vous à voitre instance de chaîne locale

Vous pouvez vous connecter à votre node de développement HydraDX en utilisant Polkadot/apps et en changeant le réseau en Développement. Vous pouvez aussi utilisez ce lien: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/fr/claim/index.html b/fr/claim/index.html index 6c68a522..aff30b60 100644 --- a/fr/claim/index.html +++ b/fr/claim/index.html @@ -4,14 +4,14 @@ Récupérer vos HDX | HydraDX Docs - +

Récupérer vos HDX

Vous pouvez récupérer vos HDX avec les tokens xHDX (ERC-20) que vous avez obtenus pendant la période où notre Balancer LBP était opérationnel.

Prérequis

Il y a deux conditions préalables pour récupérer vos HDX. En premier lieu, vous devez installer l'extension de navigateur Polkadot.js qui sera utilisée pour créer votre portefeuille HDX. En second lieu, vous devez accéder à vos xHDX qui devraient être stockés dans un portefeuille supportant la signature de messages relatifs aux tokens ERC-20 (par exemple : Metamask).

Si vos tokens xHDX sont stockés dans un portefeuille Coinbase ou un portefeuille Trust, vous devrez utiliser une des solutions alternatives suivantes pour récupérer vos HDX, puisque ces portefeuilles ne supportent pas la signature de messages:

  • Metamask: vous pouvez utiliser l'extension de navigateur Metamask et importer votre portefeuille en utilisant la "seed phrase" de récupération.
  • MEW (MyEtherWallet): vous pouvez aussi utiliser MEW soit en important votre "seed phrase" de récupération (Phrase Mnémontechnique) ou en utilisant l'option de connexion WalletLink. Les deux options sont accessibles depuis MEW wallet access page. Si vous utilisez un portefeuille Coinbase, vous pouvez utiliser WalletLink que vous pouvez trouver dans les paramètres du portefeuille Coinbase.

procédure de réclamation

Après vous être assuré que vous satisfaites les prérequis décris ci-dessus, vous pouvez vous rendre sur application de réclamation HydraDX et effectuer le procédé de récupération.

Pendant la procédure de récupération, vous allez utiliser vos tokens xHDX (ERC-20) pour récupérer votre part de tokens HDX.

00 Autoriser

L'application de réclamation HydraDX va requérir une autorisation de l'extension de navigateur Polkadot.js.

danger

assurez vous que vous n'êtes pas victime d'une attaque d'hameçonnage, et soyez attentif au pop-up d'autorisation: L'application devrait s'identifier elle-même comme CLAIM.HYDRADX.IO et la requête devrait venir de https://claim.hydradx.io.

authorize

Après autorisation, vous serez invité à mettre à jour les métadonnées pour l'extension de navigateur Polkadot.js. Cela permettra à Polkadot.js de créer des adresses spécifiques à HydraDX qui seront nécessaires pour terminer la procédure de récupération.

authorize

01 Sélectionnez votre adresse ETH

Dans la première étape de la procédure de récupération, on vous demandera de choisir votre compte contenant vos tokens xHDX. Ca peut être fait soit en connectant votre portefeuille contenant les tokens ERC-20 (par exemple : Metamask), soit en entrant manuellement votre adresse ETH dans la zone de saisie (auquel cas vous devrez signer le message manuellement plus tard).

Après avoir entré votre adresse ETH, vous devriez voir le solde de tokens HDX que vous pouvez réclamer, dont le remboursement des frais de gaz que vous avez dépensé pour obtenir vos xHDX sur le Balancer.

remarque

Vous n'êtes pas éligible pour un remboursement de gaz si vous avez obtenu vos xHDX à un autre endroit que sur le Balancer pool officiel (par exemple sur Uniswap), ou si vous avez déplacé vos tokens en dehors de votre portefeuille utilisé au moment de l'achat.

authorize

02 créez et sélectionnez une adresse HDX

Dans la seconde étape, on vous demandera de choisir votre adresse HDX.

Pour créer une nouvelle adresse HDX, ouvre l'extension de navigateur Polkadot.js et cliquez sur le signe "+" pour créer un nouveau compte. Dans la première étape de création de compte, vous verrez la phrase mnémotechnique de 12 mots qui pourra être utilisée pour récupérer votre compte. Après avoir enregistré votre "seed phrase" dans un endroit sûr, cliquez sur Next step. Ici, vous devriez changer le Network en choisissant l'option HydraDX Snakenet. Saisissez un nom et un mot de passe pour votre compte, et finissez la création de compte.

authorize
danger

Assurez vous de conserver votre "seed phrase" de récupération en la stockant dans un endroit sûr et ne la partagez avec personne. Utilisez cette "seed phrase" est le seul moyen pour vous de recouvrer votre compte et si vous la perdez ou la faites fuiter, vos fonds pourraient être compromis. Veuillez noter que vous avez besoin de protéger l'accès à ce portefeuille jusqu'à ce que le mainnet commence, puisque tous les soldes HDX sont actuellement verrouillés. Si vous perdez l'accès à votre portefeuille HDX, vous perdrez en même temps vos HDX.

Après avoir créé votre compte HDX, vous devriez être capable de le séléctionner dans l'application de récupération HydraDX. Après l'avoir fait, l'application devrait vous fournir un aperçu des adresses ETH et HDX utilisées pour la procédure de récupération. Cliquez sur suivant pour procéder à la signature du message.

authorize

03 Signer

Dans la troisième étape du processus de récupération en utilisant l'application de récupération HydraDX, vous aurez l'option de signer le message en utilisant vos tokens xHDX pour réclamer vos HDX.

remarque

Veuillez noter que dans cette étape vous verrez la public key (clé publique) de votre adresse HDX, et non pas l'adresse dans sa forme humainement lisible comme elle était présentée dans les étapes précédentes dans votre extension de navigateur Polkadot.js (pour plus de détails référez vous à ss58 docs). Si vous avez suivi toutes les étapes comme décrites ci-dessus, Il n'y a pas d'inquiétude à avoir et il est sûr de continuer avec la signature du message. Nous allons aussi vérifier que le compte HDX que vous utilisez pour signer la transaction de récupération à l'étape finale correspond au compte qui reçoit les HDX réclamés.

Selon le choix que vous avez fait à la première étape, vous avez deux options de signature de message pour utiliser les tokens xHDX dans le processus de récupération:

  • Si vous utilisez Metamask, après avoir cliqué sur le bouton sign (signez) vous serez invité par Metamask à signer le message. Suivez les instructions dans Metamask.

  • Si vous avez entré votre adresse ETH manuellement, vous devrez signer le message via le portefeuille externe qui contient la clé privée de vos tokens xHDX. Une fois que vous avez signé le message, copiez la signature (qui commence par "0x") dans le champ respectif sur l'application de récupération HydraDX.

authorize

04 Récupération

Après avoir signé le message avec le portefeuille contenant vos tokens xHDX, l'extension Polkadot.js devrait s'ouvrir et il vous sera demandé de signer la transaction pour récupérer les HDX sur votre compte. Entrez votre mode de passe de votre compte HDX, et clickez sur Sign the transaction (signez la transaction).

authorize

Vous avez terminé la procédure de récupération, faisant ainsi de vous un propriétaire de HDX.

Vous pouvez visualiser votre solde en utilisant Polkadot/apps connecté au réseau HydraDX: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/fr/collator_setup/index.html b/fr/collator_setup/index.html index b741f61a..7cf23106 100644 --- a/fr/collator_setup/index.html +++ b/fr/collator_setup/index.html @@ -4,13 +4,13 @@ Set up a Collator Node | HydraDX Docs - +

Set up a Collator Node

This is a step-by-step how-to so you can get your HydraDX collator up and running. In this guide, we use Ubuntu 20.04 LTS.

Required technical specifications

The following technical specifications are required as a minimum for running a HydraDX collator node:

  • OS: Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (or equivalent single core performance)
  • Memory: 64GB RAM
  • Storage: NVMe SSD with a capacity of at least 200GB (the data footprint will grow over time)
remarque

These are the minimum technical requirements which have been verified by the team. Want to make sure that your machine has sufficient resources to run a node? Run a performance benchmark to find out.

Create a technical hydra user and add it to Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

Download and configure the hydradx binary

Pick a 12.x release, we are using v12.1.0 from our assets repository:

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

Command to run your collator

Best is to run your collator as a service using systemctl. To do so, create a file, namely hydradx-collator.service under /etc/systemd/system/hydradx-collator.service:

sudo vim /etc/systemd/system/hydradx-collator.service

Then paste the following:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

Before starting your node, let's create the base-path folder and give it the necessary permissions and ownership:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
attention

Make sure you have enough volume for your base-path by using df -h command.

Note that --prometheus-external is optional, but we highly recommend it so you can be able to export prometheus metrics and monitor your node's health through Grafana. For more details about monitoring, please visit this link.

If you need to monitor both the parachain and relaychain metrics, --prometheus-externaloption should be setup in both parts. You also need to set a separate port for the relaychain part as follows: --prometheus-port YOUR_CUSTOM_PORT_NUMBER

Depending on your setup, you might also want to override certain parameters like the websocket, rpc or your node p2p port. Please use hydradx --help for more information about the available options.

After saving your file, run the following commands to start your node:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

Your node should now be up and running. Make sure your hydra user has the necessary permissions to access your base-path and key file.

If you need to troubleshoot your running service, you can use the journalctl command with the -f option for tailing:

journalctl -fu hydradx-collator

Generate your session key

In order to generate keys for your node, run the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

Once done, you will have an output similar to:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

Set your session key

To associate the generated session keys with your Controller account, navigate to the following menu item in the Polkadot/apps on the Polkadot parachain HydraDX: Developer > Extrinsics.

Fill in the fields:

  • using selected account: select your Controller account;
  • submit the following extrinsic: select session on the left side and setKeys on the right;
  • keys: enter your session key you just generated;
  • proof: 0;

What's next?

Make sure that your node is fully synced. Once this is done, let us know in the dedicated Discord channel (only if you have been preselected as a collator).

- + \ No newline at end of file diff --git a/fr/contributing/index.html b/fr/contributing/index.html index 4c57d437..494a9630 100644 --- a/fr/contributing/index.html +++ b/fr/contributing/index.html @@ -4,13 +4,13 @@ Writing Docs | HydraDX Docs - +

Writing Docs

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation
H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.


Lists

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
  4. And another item.
  • Unordered list can use asterisks
  • Or minuses
  • Or pluses

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example).

Some text to show that the reference links can follow later.


Images

Here's our logo (hover to see the title text):

Inline-style: alt text

Reference-style: alt text

Images from any folder can be used by providing path to file. Path should be relative to markdown file.

![img]{useBaseUrl('/static/img/logo.svg')}


Code

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

MarkdownLessPretty
Stillrendersnicely
123

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.


Inline HTML

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.


Admonitions

remarque

This is a note

astuce

This is a tip

info

This is important

attention

This is a caution

danger

This is a warning

- + \ No newline at end of file diff --git a/fr/create_account/index.html b/fr/create_account/index.html index a4fac68a..93486c9f 100644 --- a/fr/create_account/index.html +++ b/fr/create_account/index.html @@ -4,13 +4,13 @@ Create a new HDX Account | HydraDX Docs - +

Create a new HDX Account

The process of creating a new HDX Account consists of three simple steps.

01 Install Polkadot.js

In order to create and manage your HDX wallet, you need to install the Polkadot.js browser extension.

02 Upgrade metadata

After installing the Polkadot.js browser extension, you should make sure that it has been updated with the latest chain metadata. For this purpose, you can visit the following link and update your metadata, if prompted:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/settings/metadata

03 Create your HDX Account

To create a new HDX address, open the Polkadot.js browser extension and click on + > Create new account.

You will be displayed a 12-word mnemonic phrase which can be used to recover your account. Make sure that you backup your seed phrase in a secure location. Click on Next step and fill in the following information:

  • Network: Please select HydraDX Snakenet
  • Descriptive name of the account
  • Password

Your account will be created after clicking Add the account with the generated seed.

create-account
danger

Make sure to backup your recovery seed phrase by storing it in a secure location. Never share your seed phrase with anybody. The seed phrase can be used to gain access to your account. If you lose it or leak it, you might also lose all the HDX stored in your account. Please note that all HDX balances are locked until mainnet starts, so you need to make sure that you keep the account holding your tokens secure until then.

- + \ No newline at end of file diff --git a/fr/democracy_council/index.html b/fr/democracy_council/index.html index 6e72a4b7..9728bc87 100644 --- a/fr/democracy_council/index.html +++ b/fr/democracy_council/index.html @@ -4,13 +4,13 @@ HydraDX Council | HydraDX Docs - +

HydraDX Council

Le conseil HydraDX est une entité sur-chaîne qui joue un rôle majeur dans la gouvernance du protocole. Cet article fournit les informations sur la composition du Conseil, ses tâches principales, et l'élection des membres du Conseil.

Pour un guide étape par étape sur comment participer aux élections du Conseil, veuillez vous référer à ce guide.

Composition

Le conseil HydraDX est composé actuellement de 13 membres.

Une part minoritaire de 6 sièges est réservée pour l'équipe fondatrice et les investisseurs (4 fondateurs + 2 investisseurs).

Les 7 sièges restans sont élus par une communauté plus large de détenteurs de HDX.

Tâches et responsabilités

Les tâches du Conseil HydraDX couvrent un large éventail d'activités de gouvernance. Pour commencer, le Conseil contrôle la trésorerie et approuve ou rejette les propositions de trésorerie.

Le conseil HydraDX joue aussi un rôle dans le mécanisme de référendum. Le Conseil peut initier un référendum, à condition qu'au moins 60% des membres le soutienne (super-majorité) et qu'aucun membre n'exerce un veto. Dans le cas d'un veto, la proposition peut être resoumise après que la période de repos soit passée. Le membre du veto ne peut pas utiliser son veto pour la même proposition deux fois.

De plus, chaque référendum proposé peut être annulé avec un super-majorité de 2/3 des votes du conseil. Cela peut être utilisé comme dernier recours pour stopper des propositions mal intentionnées ou des changements qui pourraient introduire des bugs dans le code.

Enfin, le Conseil HydraDX est responsable de l'élection du Comité Technique.

Élections

Chaque détenteur de token HDX peut se présenter pour l'un des 7 siège non permanent du Conseil HydraDX en tant que candidat.

Les élections du conseil prennent place tous les 7 jours, après quoi un algorithme remplit les 7 sièges non-permanents pour la durée des 7 jours suivants. Le module de démocratie utilise le même algorithme Phragmen qui est utilisé pour élire le set de validateurs actifs.

Tous les membres de la communauté peuvent voter aux élections du Conseil en verrouillant un certain montant de leur choix de tokens HDX. Les tokens verrouillés ne sont pas disponibles pour transfert et seront utilisés dans les élections suivantes (jusqu'à annulation). Les votants peuvent et devront sélectionner plus d'une candidature dans leur ordre de préférence. L'algorithme d'élection distribue ensuite tous les votes pour déterminer l'allocation optimale des sièges du Conseil disponibles aux candidats avec les plus grands soutiens de la communauté.

- + \ No newline at end of file diff --git a/fr/democracy_intro/index.html b/fr/democracy_intro/index.html index b81a7415..e471037d 100644 --- a/fr/democracy_intro/index.html +++ b/fr/democracy_intro/index.html @@ -4,13 +4,13 @@ Introduction | HydraDX Docs - +

Introduction

HydraDX est en train de décentraliser complètement sa gouvernance. Toutes les décisions qui affectent le protocole sont adopté selon un processus démocratique qui est supporté par le module de démocratie Substrate. Le mécanisme central pour établir le consensus parmi les parties prenantes est le référendum.

Cette section contient une série d'articles informatifs qui devraient vous fournir une meilleure compréhension des mécanismes derrière la gouvernance de HydraDX. Vous trouverez plus d'informations sur comment fonctionnent les référendums, ainsi que sur les deux groupes centraux d'acteurs de la gouvernance: le Conseil HydraDX et le Comité Technique.

Si vous êtes à la recherche de conseils pratiques sur comment participer à la gouvernance de HydraDX, veuillez vous référer aux guides pas à pas sur participer aux référendums et participer aux élections du conseil.

Paramètres de démocratie

La liste ci-dessous contient les paramètres les plus importants qui influencent la mécanique de gouvernance sur HydraDX. veuillez noter qu'ils peuvent être amener à changer dans le futur.

  • Dépôt minimum de HDX pour commencer un référendum: 100 000 HDX
  • Période d'adoption du référendum: 3 jours
  • Période de vote du référendum: 3 jours
  • Période de vote du référendum d'urgence: 3 heures
  • Période de repos après qu'un référendum a été rejeté: 7 jours
  • Maximum de propositions de référendum en attente: 100
- + \ No newline at end of file diff --git a/fr/democracy_referenda/index.html b/fr/democracy_referenda/index.html index 8404fd07..91bef3f4 100644 --- a/fr/democracy_referenda/index.html +++ b/fr/democracy_referenda/index.html @@ -4,13 +4,13 @@ Référendums | HydraDX Docs - +

Référendums

Les référendums permettent aux parties prenantes de soumettre une proposition à un vote pondéré, basé sur la délégation, par la communauté au sens large. L'objet du référendum est une action suggérée qui affecte le protocole - par exemple, un paiement de trésorerie, ou même un changement dans le code runtime.

De manière générale, seul un référendum est amené à être voté à la fois. Les autres propositions de référendums en suspens sont mis dans une file d'attente. Il y a des files séparées pour des propositions soumises publiquement et pour des des propositions de Conseil. Tous les 3 jours, le mécanisme de référendums choisit la meilleure proposition avec le plus haut montant de soutient, en alternant entre les deux files d'attente. Après qu'un référendum a été voté et accepté, il y a une période de délai d'adoption de 3 jours qui devront s'écouler avant que la décision ne soit effective. Une exception à ces règles s'applique pour les propositions d'urgence par le Comité Technique qui gèrent les problèmes majeurs de protocole et ont besoin d'être accélérées.

Lancer un Référendum

Il y a plusieurs façons de lancer un référendum qui sont décrites plus en détail ci-dessous. La façon dont un référendum est initié est décisive pour le mode de vote applicable.

Référendum Public

N'importe quel détenteur de tokens HDX peut proposer un référendum en déposant le montant minimum requis de tokens HDX et en soumettant la proposition sur-chaîne. D'autres membres de la communauté peuvent soutenir (appuyer) la proposition pour un référendum en verrouillant un montant égal de tokens. Au début de chaque cycle de vote, la proposition de référendum avec le plus important montant d'appui (tokens totaux déposés) est avancé pour un vote par la communauté.

Le mode de vote qui s'applique aux référendums publics est Biais de Participation Positif.

remarque

Tous les tokens HDX qui sont déposés pour proposer ou appuyer un référendum sont verouillés jusqu'à ce que le référendum soit entré dans un cycle de vote. Il est important de se rappeler qu'il n'y a pas de garantie qu'une proposition donnée va recevoir assez de soutient pour entrer dans un tour de scrutin, ce qui veut dire que vos fonds pourraient rester verrouillés pendant une période indéfinie.

Référendum du Conseil

Le Conseil HydraDX a les pouvoirs de proposer un référendum pour un vote à la communauté. Si cela se fait anonymement, le mode de vote applicable pour le référendum est le Biais de Participation Négatif. Si le référendum est proposé avec une majorité simple des votes du Conseil, alors le mode de vote pour accepter les propositions par la communauté est la Simple Majorité.

Propositons d'Urgence par le Comité Technique

Le comité technique peut soumettre des propositions d'urgence qui gère les corrections de bugs (critiques) ou l'adoption rapide de fonctionalité éprouvée. Les propositions d'urgence sautent la file d'attente et entre directement dans la phase de scrutin. La communauté peut voter les propositions d'urgence en parallèle avec n'importe quelle autre proposition qui a intégré le tour de scrutin. De plus, les propositions d'urgence ont une période de vote plus courtes afin de s'assurer qu'elles sont accélérées.

Annuler un Référendum

Une fois qu'un référendum a été proposé, il ne peut pas être révoqué avant d'entrer le tour de scrutin. Une exception à cette règle est faite pour les propositions qui sont jugées préjudiciables au protocole (ex: des changement de code qui introduisent un bug). Dans ce cas précis, la proposition de référendum peut être annulée par le conseil HydraDX (avec une super majorité de 60%) ou le Comité Technique (à l'unanimité). Tous les tokens qui étaient verrouillés par les soutiens appuyant la proposition sont détruits.

Voter dans un référendum

Les référendums HydraDX ont une période de lancement de 3 jours. Au début de chaque période, la proposition avec le plus au montant d'appuis est prise depuis la file d'attente et soumise au tour de scrutin. Chaque tour de scrutin a une durée de 3 jours. Pendant cette période, les membres de la communauté peuvent voter au référendum en utilisant un mécanisme pondéré, basé sur la délégation. Ils le font en verrouillant un certain montant de tokens HDX pour une période de temps donnée.

remarque

Les tokens HDX verrouillés ne peuvent pas être transférés pendant la durée de la période de verrouillage choisie. Cependant, ils peuvent toujours être utilisés pour la délégation et le vote.

Pesée des Votes

Il y a deux facteurs qui déterminent le poids de chaque vote dans un référendum. Le premier facteur est le montant de tokens HDX que le votant verrouille en soutient au vote. Le second facteur est le soi-disant conviction multiplier (multiplicateur de conviction) qui reflète la durée pendant laquelle le votant est prêt à verrouiller ses tokens.

poids_du_vote = tokens * multiplicateur_de_conviction

Les périodes de verrouillage de vote ont la même durée que les délais d'adoption. Si les tokens sont verrouillés pour 1 période de vote, cela signifie qu'ils vont rester verrouillés pour 3 jours après que le vote soit terminé. Les votants peuvent influencer le poids de leur vote en diminuant ou en augmentant le montant de périodes pendant lesquelles les tokens seront verrouillés. Il est possible de participer à un vote avec une période de verrouillage de 0 jour, cependant son poids serait seulement une fraction de ce qu'il serait autrement (multiplicateur de conviction de 0,1). D'un autre côté, le multiplicateur de conviction augmente de 1 pour chaque doublement des périodes de verrouillages. Comme montré dans le tableau ci-dessous, verrouiller les votes pour un maximum de 32 période augmenterait le multiplicateur de conviction à 6.

Périodes de verrouillagesMultiplicateur de conviction
00.1
11
22
43
84
165
326
Un exemple:

Alice vote avec 5000 HDX et 0 période de verrouillage.
Bob vote avec 100 HDX et une 32 périodes de verrouillage.

Poids du vote d'Alice: 500
Poids du vote de Bob: 600

Modes de Scrutins

Un autre aspect important du module de démocratie sont les différents modes de scrutin qui s'appliquent. Le seuil de votes requis pour approuver ou rejeter un référendum peut varier selon comment le référendum a été lancer et selon la participation au vote. La participation est calculée en se basant sur le montant total de HDX qui étaient utilisés pour voter le référendum (multiplicateurs de conviction exclus). Que la participation soit basse ou non est déterminé par la relation entre la participation et l'électorat (Le nombre total de HDX éligible au vote).

Biais de Participation Positif

C'est le mode de scrutin par défaut quand un référendum est proposé par la communauté. Avec des participations basses, une super majorité qualifié de yes/oui est requise afin d'approuver le référendum. Au fur et à mesure que la participation augmente, le seuil diminue jusqu'à une simple majorité.

Biais de Participation Négatif

Ce mode de scrutin s'applique aux référendums qui ont été proposés par le Conseil à l'unanimité. De telles propositions exigent une super majorité qualifiée de vote no/non pour être rejetées avec des participations basses. Au fur et à mesure que la participation augmente, le seuil pour rejeter le référendum diminue à une simple majorité.

Simple Majorité

Les référendums qui ont été lancés par le Conseil avec un accord majoritaire (non anonymement) peuvent être acceptés par la communauté avec une simple majorité des votes (50% + 1).

- + \ No newline at end of file diff --git a/fr/democracy_technical_committee/index.html b/fr/democracy_technical_committee/index.html index 1219b4f7..2132730a 100644 --- a/fr/democracy_technical_committee/index.html +++ b/fr/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ Comité Technique | HydraDX Docs - +

Comité Technique

Le comité technique est un groupe de développeurs expérimentés phares qui sont nommés directement par le Conseil HydraDX. Sa tâche principale est de sauvegarder la stabilité technique du protocole.

Le Comité Technique a le droit de produire des référendums d'urgence qui sont accélérés et votés en parallèle avec tout autre référendum actif. Cela permet au Comité d'agir rapidement et de délivrer des changements (de codes) critiques.

Un autre pouvoir important du Comité Technique est la capacité à annuler des propositions de référendum qui sont jugées nocives pour le protocole. De façon à annuler une proposition de référendum, le Comité doit unanimement tomber d'accord.

- + \ No newline at end of file diff --git a/fr/dev_intro/index.html b/fr/dev_intro/index.html index 3b202547..3725f367 100644 --- a/fr/dev_intro/index.html +++ b/fr/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/fr/great-unlock/index.html b/fr/great-unlock/index.html index c5ff4650..04851b27 100644 --- a/fr/great-unlock/index.html +++ b/fr/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/fr/howto_bonds_lbp/bonds1.jpg b/fr/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/fr/howto_bonds_lbp/bonds1.jpg and b/fr/howto_bonds_lbp/bonds1.jpg differ diff --git a/fr/howto_bonds_lbp/bonds2.jpg b/fr/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/fr/howto_bonds_lbp/bonds2.jpg and b/fr/howto_bonds_lbp/bonds2.jpg differ diff --git a/fr/howto_bonds_lbp/index.html b/fr/howto_bonds_lbp/index.html index fd73195f..d46f8898 100644 --- a/fr/howto_bonds_lbp/index.html +++ b/fr/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

attention

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
remarque

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/fr/howto_bridge/index.html b/fr/howto_bridge/index.html index 773e5619..7d9b787d 100644 --- a/fr/howto_bridge/index.html +++ b/fr/howto_bridge/index.html @@ -4,13 +4,13 @@ Bridge Assets | HydraDX Docs - +

Bridge Assets

On this page you will find a step-by-step guide on bridging tokens from the Ethereum ecosystem. Currently there are two methods to bridging to and from Ethereum (via Wormhole):

Wormhole’s Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain.

To/From Ethereum via Moonbeam

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Talisman or Metamask);
attention

Make sure to have enough tokens (ETH) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens.

01 Navigate to Carrier.so

https://www.carrier.so/

attention

Use with caution. All crypto applications can potentially carry risks related to smart contracts/pallets.

metadata

02 Add the Wallets from Source and Destination Network

  • Once you have navigated to Carrier.so, add the wallets needed to allow for bridging to and from the desired networks (1 in image above).
  • In the example above, Metamask was selected as the wallet for Ethereum and Talisman for HydraDX.
metadata

03 Select Networks and Wallets to Bridge

metadata
  • Once Metamask and Talisman are connected, select the network chains (2) and select the previously connected wallets (3).

04 Select Asset to Bridge

  • Select the token asset and amount of tokens you would like to bridge (4).

05 Bridge Tokens

  • Within Settings (5), you can select whether to Auto Relay the transaction. It is recommended that this is toggled on.
metadata
  • Click Confirm & Begin Transaction (6) to proceed. This will prompt your wallet to sign the transactions. Once confirmed, you are all done!

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

To/From Ethereum via Acala

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Metamask);
  • Bind your two wallets following Acala's guide. Completing this action will require a small amount of ACA.
attention

Make sure to have enough tokens (ETH and ACA) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens, and for binding your wallet addresses.

01 Navigate to Acala Bridge Page

https://apps.acala.network/bridge

Once you have been directed to Acala bridge page, follow the actions below:

metadata

Step 2: Connect to Your Account

  • Connect your account (1).
  • Select the chains you intend to bridge to and from (2), in this case, it will be Ethereum as the Origin Chain and HydraDX as the Destination Chain.
  • Connect to your Metamask account that you are bridging from (3).

Step 3: Bridge Tokens

  • Enter the amount of tokens and the token for bridging (4).
  • To commence the bridge, click Approve Tokens (5) and sign the transaction using your Metamask wallet app.
  • Once the tokens are approved for transfer, click Send Tokens (5). This starts the bridging process cross-chain.
  • Once the transaction has been processed by Wormhole, click Redeem & Route Tokens (5). This action results in you receiving the tokens on the destination chain.

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

- + \ No newline at end of file diff --git a/fr/howto_dca/index.html b/fr/howto_dca/index.html index 82e9d61a..1cfc607c 100644 --- a/fr/howto_dca/index.html +++ b/fr/howto_dca/index.html @@ -4,13 +4,13 @@ Place a DCA Order | HydraDX Docs - +

Place a DCA Order

On this page you will find a step-by-step guide for setting up a DCA order in the HydraDX Omnipool.

Before proceeding, we encourage you to visit our DCA product page in order to get yourself familiar with the HydraDX implementation of the dollar-cost averaging strategy.

Step 1: Navigate to HydraDX DCA Page

https://app.hydradx.io/dca

Step 2: Connect to Your Account

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 3: Set up DCA Order

  • Select the asset you will use to pay for the swap; Enter the order amount for each DCA trade, and the total order size (2);
  • Select the time interval for each DCA swap (3);
  • Select the asset you would like to receive from the swap (4);
  • For advanced users who would like to set up orders at specific block intervals, you can toggle the switch Advanced Settings (5) to set this up;
  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (6);
  • To complete the DCA order, click on Schedule DCA trades (7) and sign the transaction using your wallet app.

Step 4: View your DCA Order

  • After submitting it, your DCA order will appear under DCA Orders;
  • To see the details, click the Dropdown Arrow (8);
  • You can cancel your DCA order for the remaining amount by clicking on Terminate (9).
- + \ No newline at end of file diff --git a/fr/howto_hydrated_farms/index.html b/fr/howto_hydrated_farms/index.html index fa09d1e5..732666c6 100644 --- a/fr/howto_hydrated_farms/index.html +++ b/fr/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ Join Hydrated Farms | HydraDX Docs - +

Join Hydrated Farms

With Hydrated Farms, providing liquidity to selected assets is incentivized by additional rewards on top of rewards from trading fees. To learn more, please visit the dedicated product page.

00 Navigate to Liquidity Page

https://app.hydradx.io/liquidity

01 Provide Liquidity

Incentivized assets can be identified by the Farm rewards section which displays all available rewards for a given farm.

metadata

To join a farm, you must first provide liquidity (step-by-step guide here).

02 Join Farm

Once you have provided liquidity for an incentivized asset, you can join its farm.

metadata

To do so, click on Join farms (located next to your liquidity position) and sign the transaction using your wallet app.

Happy hydrated farming!

- + \ No newline at end of file diff --git a/fr/howto_lp/index.html b/fr/howto_lp/index.html index 636894ed..1111a456 100644 --- a/fr/howto_lp/index.html +++ b/fr/howto_lp/index.html @@ -4,13 +4,13 @@ Provide Liquidity | HydraDX Docs - +

Provide Liquidity

On this page you will find a step-by-step guide for providing liquidity in the HydraDX Omnipool. Becoming a liquidity provider allows you to earn rewards from the fees generated by trades in the pool.

Before deciding to become a liquidity provider, we encourage you to visit our product page and to get yourself familiar with the unique features of the HydraDX Omnipool.

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Navigate to Omnipool Liquidity

https://app.hydradx.io/#/liquidity

metadata

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Managing Your Liquidity

Adding Liquidity

To add liquidity for a given asset, click the button Add liquidity which is located right next to that asset (3).

info

In the HydraDX Omnipool, each individual asset has a Total Value Locked (TVL) cap. This means that once the cap has been reached, users can no longer further add liquidity for that specific asset.

The individual caps for each asset will be reviewed from time to time by the team; any suggested revisions (either from team or the community) will be submitted as proposals via governance and voted on.

metadata

Fill in the amount of liquidity you wish to provide (1), click Add liquidity (2) and sign the transaction using your wallet.

Next, you can learn how to join Hydrated Farms and earn additional rewards on top of the rewards from trading fees.

Removing Liquidity

metadata

To remove liquidity, toggle the dropdown located right next to the relevant asset (1) and click Remove liquidity (2) on the position you wish to exit.

metadata

Toggle or enter the amount of liquidity you wish to withdraw (3), click on Remove liquidity (4) and sign the transaction using your wallet.

- + \ No newline at end of file diff --git a/fr/howto_stake/index.html b/fr/howto_stake/index.html index d83591cf..d6f23e0a 100644 --- a/fr/howto_stake/index.html +++ b/fr/howto_stake/index.html @@ -4,13 +4,13 @@ Stake HDX | HydraDX Docs - +

Stake HDX

Staking allows users to stake their HDX tokens and earn rewards which vest over time. This page contains a step-by-step guide on how to stake your HDX. Before proceeding, we recommend that you get familiar with the basics of HDX staking.

If you don't have any HDX, you can obtain some on our trade page by swapping against a range of assets supported by the Omnipool.

Step 0: Navigate to HydraDX Staking Page

https://app.hydradx.io/staking

Connect your wallet to HydraDX by clicking Connect Account.

Step 1: Stake Your HDX

  • Select the amount of HDX tokens you would like stake (3).
  • Click on Stake (4) to confirm and sign the transaction using your wallet app.
metadata

Step 2: Keep Your HDX Staked

  • The amount of rewards you receive is determined by the size of your staked HDX relative to the whole stake pool.
  • As time passes, you unlock a greater portion of your allocated rewards. The rate of unlocking is determined by a rewards bonding curve.
  • Learn more in the Staking product docs.

Step 3: Boost Your Rewards

  • Collect Action Points to boost your rewards and increase the pace at which you unlock rewards.
  • You can collect Action Points by voting on referenda. The more staked HDX you use for the vote and the higher the Conviction Multitplier - the more Action Points you receive.
  • Learn more in the Staking product docs.

Step 4: Claim Your Rewards

  • Review your Staking statistics to observe and plan your own staking strategy (5).
  • Once you are done staking, Claim your unlocked rewards (8).
metadata
attention

Every time you claim unlocked staking rewards, you forfeit any locked rewards which are redistributed to all other stakers. Furthermore, your past Action Points will be reset.

For instance, if a staker claims rewards when 75% of the rewards are available, the remaining 25% is forfeited. The staker must then wait for the same duration to claim 75% of the subsequent batch of rewards.

- + \ No newline at end of file diff --git a/fr/howto_trade/index.html b/fr/howto_trade/index.html index 66244984..8be83c87 100644 --- a/fr/howto_trade/index.html +++ b/fr/howto_trade/index.html @@ -4,13 +4,13 @@ Trade in Omnipool | HydraDX Docs - +

Trade in Omnipool

This page provides a step-by-step guide which will help you execute your first trades using the HydraDX Omnipool.

The HydraDX Omnipool is a next-gen AMM which unlocks unparalleled efficiencies, you can find out more in our product documentation.

metadata

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Enter Omnipool

https://app.hydradx.io/#/trade

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Execute a Trade

The HydraDX Trade UI allows you to intuitively execute a trade:

  • Select the pair of tokens you intend to trade (2);
  • Enter the amount of tokens for the trade (3).
    You can enter the amount of tokens you would like to pay with (e.g. 5000 DAI), but you can also enter the amount of tokens you would like to receive (e.g. 1000 HDX);
  • If you would like to adjust your slippage preferences, you can do so in Settings (4);
  • To complete the trade with instant execution (pre-selected) (5), click on Swap (7) and sign the transaction using your wallet. Otherwise, follow the additional steps below.

04 Execute a Split Trade

If your trade is large enough so that price impact would be > 0.15%, the UI will allow you to select Split trade (6) - breaking your trade into multiple smaller trades executed over < 3 hours and therefore reducing your price impact.

  • Select the pair of tokens and amounts as in 03 Execute a Trade above;
  • Select Split trade (6);
  • To schedule your Split trade execution, click on Place trades (7) and sign the transaction using your wallet.

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/fr/howto_wallet_parity_signer/index.html b/fr/howto_wallet_parity_signer/index.html index 76aed2aa..c254d386 100644 --- a/fr/howto_wallet_parity_signer/index.html +++ b/fr/howto_wallet_parity_signer/index.html @@ -4,14 +4,14 @@ Use Parity Signer | HydraDX Docs - +

Use Parity Signer

Parity Signer is a mobile app which turns your iOS or Android device into a dedicated hardware wallet for Polkadot, Kusama, and any other Substrate-based chain. It allows you to keep your private keys offline while still being able to conveniently sign transactions in an air-gapped way using QR codes.

Set Up Parity Signer

Before You Start: Stay Safe

Start clean

Before installing Parity Signer, make sure that your phone is in a clean state. If it has been used, perform a factory reset and do not install any other apps besides Parity Signer.

Don’t Insert Sim

If possible, don’t turn on WiFi or use a secure WiFi connection, preferably with no other connected devices and a reputable VPN provider to connect, update the device, and install the Parity signer app.

Use Strong Passwords

For robust security, use long passwords for the device and the accounts you need to create to use it.

Setup New Account

Don’t use your old google ID or apple ID, create a new one specifically for this use which will be used only to download updates and parity signer. In case of Android device it’s better to not use WiFi or google account at all. We recommend using some sort of OS that encrypts your data like Lineage O.S. If an email is required, create a new one. Alternatively, you can create new apple id and email on iOS.

No Biometrics

Avoid fingerprint scanners, face ID, or shot numeric codes as they are exploitable. Use a strong password instead.

Disable All Signal-receiving Features

Use airplane mode and make sure to disable all of these features manually. If you are on an iOS device, turn it off and ask to auto-join networks and hotspots in the WiFi settings. Including:

  • Location services
  • WiFi (if required to upgrade or setup, disable right after the update)
  • Bluetooth

Logout From All Accounts

Log out from App stores, iCloud, and any other accounts you’ve joined.

Updating Your Device

If you are using WiFi to update your device, remember to disable it right after the update and use it only in a secure environment, preferably through a secure and encrypted VPN channel. After the update is complete, forget the WiFi network to make sure you don't automatically rejoin.

Install Parity Signer

Install Parity Signer from the official app store for your device (iOS / Android).
Make sure that the application you are downloading has been published by Parity Technologies.

Create a New Account

To create a new account, follow the steps below.

01 Add Seed

Open the Parity Signer app and select New seed.

metadata

02 Back Up your Recovery Phrase

The app will display your recover phrase. Write it down and store it in a safe place.

metadata

After completing this, you are all set to go! You can use your phone passcode or authentication method (fingerprint / face id) in Parity Signer.

danger

Stay safe!

Anyone with your seed phrase can access your funds, and there is no recourse for someone stealing your seed phrase.

To protect your seed phrase, consider the following tips:

  • Never store your seed phrase as a digital file on any device.
  • Always write down your seed phrase with a pen and paper.
  • Store the paper with your seed phrase on it somewhere safe.
  • Never give your seed phrase to anybody, including support staff.

Connect to Polkadot.js/apps

Optionally, you can add your Parity Signer account into the Polkadot.js browser extension which will allow you to view your balances on the Polkadot.js/apps accounts page and to sign transactions more easily.

On Polkadot.js/apps

To add your account, open the Polkadot.js browser extension, click on + and select Attach external QR-signer account.

metadata

On Parity Signer

  • Open Keys tab in the bottom menu;
  • Select the network you will be using from the dropdown menu next to chain;
  • Select your desired account or sub-account;
  • You will see a QR code which you need to scan with your device camera.

Add HydraDX Chain

To use Parity Signer, you first need to add a new chain to Parity Signer. If you want to use Parity only for Polkadot or Kusama, you can skip this step and proceed with updating metadata. To add a new chain, you need to scan a QR code with base information about the chain.

01 Get Chain Specs

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select HydraDX as the desired chain. After that, click on Chain Specs.

metadata

02 Add Specs

On your Parity Signer, click Scanner, scan the QR code and click Add new chain.

Use Parity Signer

danger

Always make sure you are scanning a QR code signed by a trusted verifier.

Sign a Transaction

To sign a transaction from your parity signer, we recommended adding it to polkadot.js extension for ease of use. Until more chains can work with Parity Signer directly, it will be the most convenient way to use it inside applications on your desktop.

When signing a transaction using your Parity Signer, Polkadot.js/apps will display a QR code.

metadata

Scan the QR code using Parity Signer and click on Unlock key and sign.

metadata

Your Parity Signer will now display a QR code. To complete signing the transaction, switch back to Polkadot.js/apps and click on Scan signature via camera.

Update Metadata

To use the Parity Signer, you require the latest metadata for decoding transactions in the Parity Signer. You can acquire the metadata by scanning a multi-part QR code containing this data, allowing the Parity Signer to decode the actual transaction and display it correctly before you sign. This step is similar to updating your ledger application.

01 Get Metadata

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select the desired chain. After that, click on Metadata.

metadata

02 Update

On your Parity Signer, click Scanner, and update the Metadata by scanning the QR code

- + \ No newline at end of file diff --git a/fr/howto_xcm/index.html b/fr/howto_xcm/index.html index 815209b8..4003fa7f 100644 --- a/fr/howto_xcm/index.html +++ b/fr/howto_xcm/index.html @@ -4,13 +4,13 @@ Cross-chain Transfer | HydraDX Docs - +

Cross-chain Transfer

On this page you will find a step-by-step guide for performing cross-chain transfers.

Cross-chain transfers allow you to transport non-native assets to the HydraDX chain from other Polkadot parachains, or from Polkadot itself.

Currently, the following tokens are supported by HydraDX for cross-chain transfers:

  • DOT
  • DAI (from Acala, bridged via Wormhole)
  • ETH (from Acala, bridged via Wormhole)
  • HDX

00 Prerequisites

Before you continue, please make sure you have sufficient amount of tokens on the destination chain for fees (ACA or DOT).

01 Navigate to Cross-chain Transfers

https://app.hydradx.io/#/cross-chain

metadata

02 Connect Your Account

Click on Connect wallet and connect to your preferred Polkadot wallet. After that, select your account.

03 Cross-chain Transfer

  • Select the source chain and the destination chain;
  • Select the asset you intend to transfer and enter the amount;
  • Enter the destination address. It should automatically populate with your address on that chain, but you can also change it to another address;
  • Click Transfer and sign the transaction using your wallet.
- + \ No newline at end of file diff --git a/fr/identity/index.html b/fr/identity/index.html index c4d5ebae..574b67b5 100644 --- a/fr/identity/index.html +++ b/fr/identity/index.html @@ -4,13 +4,13 @@ définir votre identité | HydraDX Docs - +

définir votre identité

Les titulaires de compte ont la possibilité de définir leur identité en fournissant des informations spécifiques et en les stockant on-chain (sur la chaîne). Par ailleurs, l'information de l'identité peut optionnellement être soumise aux gérants de registres pour vérification. En définissant et en vérifiant leur identité, les validateurs et les nominateurs aident à maintenir la confiance du réseau.

remarque

Si vous participez en tant que validateur HydradDX nous recommandons fortement de vérifier votre identité et fassiez les étapes de vérification. Les validateurs vérifiés paraissent plus fiables et attirent plus de nominations, et augmente ainsi leurs chances d'être inclus dans l'ensemble des validateurs actifs.

01 Définir votre identité

Pour définir votre identité, ouvrez Polkadot/apps (connecté au réseau HydraDX Snakenet ) et naviguez jusqu'à Mes comptes. Sinon, vous pouvez suivre ce lien:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

Sur la page des comptes, repérez le compte qui contient vos tokens HDX engagés. Après ça, cliquez sur les trois points à côté du compte (sur la droite) et sélectionnez Définir l'identité sur la chaîne de bloc.

authorize

Vous verrez une nouvelle fenêtre appelée enregistrer votre identité. Ici, vous pouvez entrer les informations suivantes:

  • nom légal
  • email
  • adresse web (web)
  • twitter
  • nom matrix (riot name en anglais) (au cas où vous utilisez la messagerie Matrix)
remarque

Toutes ces informations sont facultatives - renseignez seulement les informations que vous souhaitez. Si vous gérez un node de validation, nous vous encourageons à renseigner votre email, cela nous permettra de vous contacter en cas de soucis avec votre node de validation

Dans le dernier champ de la fenêtre, vous pouvez voir le montant de HDX que vous devez déposer pour garder les informations relatives à votre identité. Vous récupérerez la caution si vous déciderez de supprimer votre identité.

authorize

Après avoir rempli les informations, cliquez sur Définir l'identité et signer la transaction en utilisant l'extension de navigateur Polkadot.js. Une fois que la transaction est confirmée, votre identité est définie.

02 Soumettre votre identité pour vérification

Après avoir défini votre identité, vous pouvez la soumettre aux gérants de registres pour vérification. Ouvrez Polkadot/apps et naviguez jusqu'à Développeur > Extrinsics. Ou cliquez sur le lien suivant:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

Après avoir sélectionné le compte HydraDX approprié (de l'étape précédente), vous devez remplir les informations suivantes:

  • extrinsic: identity
  • action: requestJudgment
  • reg_index: Ici vous devez entrez l'ID du gérant de registre que vous choisissez pour procéder à la vérification. HydraDX a deux gérants de registres: Simon Kraus - HydraSik (ID: 0) et Jimmy Tudeski - stakenode (ID: 1).
  • max_fee: Ici vous devez entrer le montant de frais maximum en HDX que vous êtes prêt à payer au registraire pour la vérification. Seuls les registraires avec des frais inférieurs à votre max_fee vont être éligible pour effectuer la vérification.

Pour soumettre la requête de vérification, cliquez sur Soumettre la transaction (Submit Transaction en anglais) et signez la transaction.

authorize

Veuillez noter que le processus de vérification d'identité peut prendre du temps. Pour voir le statut de votre requête, naviguez jusque Mes comptes et passez le curseur sur la section montrant votre identité - vous verrez une fenêtre popup montrant le statut actuel.

03 Résultat de la procédure de vérification

Après avoir effectué votre requête de vérification, le registraire va soumettre un des jugements suivants qui va devenir visible dans votre statut d'identité:

  • Unknown - valeur par défaut, aucun jugement n'a encore été émis.
  • Reasonable - les informations fournies paraissent raisonnables, cependant, aucune vérification en profondeur n'a été effectuée.
  • KnownGood - l'information est correcte.
  • OutOfDate - l'information était correcte avant, mais est n'est plus à jour.
  • LowQuality - l'information est imprécise mais peut être corrigée en la mettant à jour.
  • Erroneous - l'information fournie est fausse et pourrait indiquer une intention malveillante.
- + \ No newline at end of file diff --git a/fr/index.html b/fr/index.html index 5e2d8868..0ca76115 100644 --- a/fr/index.html +++ b/fr/index.html @@ -4,14 +4,14 @@ Commencer | HydraDX Docs - +

Commencer

Bienvenue sur les documentations officielles HydraDX ! Ici vous pouvez trouver toutes les ressources utiles sur le protocole HydraDX. Notre intention est d'en faire un endroit incontournable pour tous, couvrant le spectre complet, des visiteurs occasionnels, en passant pas les validateurs, les nominateurs, jusqu'aux développeurs qui veulent aider à construire HydraDX.

HydraDX est conduit par sa communauté, ainsi que les sont ces documentations. Nous sommes heureux de voir vos contributions, qui peuvent prendre plusieurs formes - par exemple, vous pourriez écrire un nouvel article ou en traduire un existant. Regardez notre dépôt GitHub ainsi que certaines lignes directrices de contribution.

Qu'est-ce que HydraDX?

HydraDX est un protocole de liquidité inter-chaînes construit sur la technologie Substrate. Notre mission est de permettre les liquidités fluides ("frictionless" en anglais) pour tous les actifs crypto en construisant la première réserve de liquidité (liquidity pool) multi-actifs de son genre - L'Omnipool HydraDX (ou Omniréserve). Dans l'Omnipool, différents actifs sont évalués les uns par rapport aux autres en utilisant nos token HDX natifs comme un intermédiaire pour déterminer leur valeur relative. Avec l'Omnipool, HydraDX rompt avec la conception traditionnelle selon laquelle les actifs sont négociés par paires en utilisant des réserves (pools) isolées. En outre, nous sommes heureux de faire partie de l'écosystème Polkadot et nous espérons devenir le fournisseur de liquidités principal pour tous les actifs construits sur Substrate.

- + \ No newline at end of file diff --git a/fr/lbp/index.html b/fr/lbp/index.html index 04fbc3ff..7b8cce93 100644 --- a/fr/lbp/index.html +++ b/fr/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

danger

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/fr/learn_amm/index.html b/fr/learn_amm/index.html index 0a95e4a2..54c67eec 100644 --- a/fr/learn_amm/index.html +++ b/fr/learn_amm/index.html @@ -4,13 +4,13 @@ What are AMMs? | HydraDX Docs - +

What are AMMs?

This article provides an introduction to Automated Market Makers (AMMs) together with some of their underpinning concepts such as slippage, liquidity provisioning and impermanent loss.

This introductory information will help you understand better the mechanics behind the HydraDX Omnipool which you can find described in our product documentation.

A Short Intro into AMMs

To explain Automated Market Makers (AMMs) and how they work, we can contrast them to their centralized counterpart: Order books.

Order Books

Order books provide a mechanism which is deployed by centralized exchanges to facilitate trading between two assets. Users can place a Buy or Sell order in an electronic list managed by the exchange. The orders in this so-called Order Book are organized by price level and progressively filled as demand shifts and orders are being matched. The limitations of order books become apparent against the background of their centralized nature.

The need for an intermediary to “keep” the order book and to facilitate the process of order matching creates a dependency on a central authority. This central authority has control over the trading and needs to be trusted by the participants. In times of substantial volume traffic and volatility, the central authority can decide to halt trading and stop performing its market-making function. Furthermore, the process of adding new tradable assets is permissioned and projects may need to pay in advance to get their assets listed.

AMMs

Automated Market Makers (AMMs) is the answer by the DeFi industry to order books. AMMs provide a decentralized, permissionless way of trading tokens without the need to subdue oneself to a central authority of control.

AMMs consist of liquidity pools that hold the available liquidity of the underlying tradable assets. This liquidity is provided by users (the so-called “liquidity providers”) who are incentivized to do so by the prospect of earning rewards from the fees generated by trades in the pool.

In the case of AMMs, any user can execute a Buy or Sell order on top of a given trading pool. The price of the trade is determined on the spot by a deterministic algorithm which takes as input the relationship between the liquidity of the traded assets, together with other factors which depend on the particular AMM implementation.

Slippage

When a trade is executed, users may experience a common side-effect of AMMs known as slippage. This is the difference between the expected price of a trade and the price when the trade is actually executed.

Slippage is determined by the amount of liquidity available within the trading pool. If there is a low amount of liquidity provided for the asset, then the slippage percentage when transacting with big orders will be higher.

Providing Liquidity

Thanks to the decentralized nature of an AMM, anyone can become a liquidity provider (LP) for a liquidity pool by depositing some amount of value in return for a token representing their liquidity position.

LPs are rewarded with fees for providing this liquidity based on the trading activity experienced by the asset for which they have provided liquidity.

Impermanent Loss (IL)

Impermanent loss (IL) is a risk faced by liquidity providers which embodies the difference in value between holding tokens in an AMM as opposed to holding them in your wallet.

Liquidity pools consist of multiple tokens (usually two) which are pooled together. IL occurs when the tokens inside the pool diverge in price. The greater the divergence, the greater the risk of negative returns for the pool's LPs.

The risk is referred to as "impermanent" because the loss is only realized when liquidity is withdrawn from the pool. If the relative prices of tokens in the pool return to their original state (when the tokens were deposited), the loss is minimized or eliminated. The loss will become permanent at the moment when the liquidity is withdrawn, leading to reduced earnings.

As such, LPs need to weigh the fees and rewards earned from LPing versus simply holding their tokens in their wallets.

- + \ No newline at end of file diff --git a/fr/node_monitoring/index.html b/fr/node_monitoring/index.html index 3a3af5fc..2658d793 100644 --- a/fr/node_monitoring/index.html +++ b/fr/node_monitoring/index.html @@ -4,7 +4,7 @@ Supervision de node | HydraDX Docs - + @@ -34,7 +34,7 @@ Entrez http://localhost:9090/ et cliquez Save and Test.

Importer le tableau de bord

Veuillez cliquer sur le bouton Plus dans le menu principal de navigation et sélectionnez import.

Nous allons utiliser le Tableau de bord HydraDX pour le charger vous entrez l'id 14158 et cliquez sur le bouton Load.

Il n'y a pas besoin de beaucoup de configuration ici, assurez vous juste que Prometheus est utilisé comme source de donnée. Vous pouvez maintenant terminer l'importation.

Vous devriez maintenant voir votre tableau de bord directement. Si certains panneaux sont vides, assurez vous que la sélection au dessus des panneaux est comme suit:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/fr/omnipool_dca/index.html b/fr/omnipool_dca/index.html index ac9ea304..e36d9ae9 100644 --- a/fr/omnipool_dca/index.html +++ b/fr/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA Trading | HydraDX Docs - +

DCA Trading

HydraDX DCA and Split Trade (easy DCA) are two user-friendly features which allow traders to implement the dollar-cost-averaging (DCA) strategy when trading in the Omnipool - in a permissionless and non-custodial way.

Following the DCA strategy, orders are not placed at once but instead split into smaller trades which are executed at regular intervals of time. By doing so, traders may protect themselves against price volatility and achieve an average price. Additionally, splitting a large order in smaller chunks will result in less slippage.

HydraDX has two DCA implementations - the full DCA feature, and Split Trade (easy DCA) which can be found on the main trading page. Further down, you can learn more about these features.

If you are looking for step-by-step guidance, check out the how-to place a DCA order guide.

HydraDX DCA

HydraDX DCA provides an intuitive UI which enables users to fine-tune their DCA orders in the Omnipool.

When setting up their order, users specify the amount of Asset A they would like to spend in order to obtain Asset B, as well as the frequency of the trades - in hours (approximation) or number of blocks (more granularity).

After placing the order, the HydraDX DCA pallet makes sure that trades are scheduled at the specified intervals until the predetermined amount of Asset A has been spent. Placing multiple DCA orders which are executed in parallel is supported.

Users can track the status of their orders on the UI. Open orders can at any time be terminated for the remaining amount.

Split Trade (easy DCA)

Split Trade is a more simple implementation of DCA directly into the main trade page. It provides users with a one-click solution for splitting larger orders in order to protect themselves from slippage.

When activated, Split Trade will split the order in smaller chunks until the size of the trades is small enough to achieve <0.1% slippage (estimate only - the exact slippage for future trades can never be predicted in advance).

Open Split Trade orders can be terminated by the user at any time, just like any regular DCA order.

- + \ No newline at end of file diff --git a/fr/omnipool_design/index.html b/fr/omnipool_design/index.html index aebed792..84db3a30 100644 --- a/fr/omnipool_design/index.html +++ b/fr/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool Design | HydraDX Docs - + @@ -46,7 +46,7 @@ c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).

- + \ No newline at end of file diff --git a/fr/omnipool_hydrated_farms/index.html b/fr/omnipool_hydrated_farms/index.html index 08c9a2b7..b33bc9ca 100644 --- a/fr/omnipool_hydrated_farms/index.html +++ b/fr/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ Hydrated Farms | HydraDX Docs - +

Hydrated Farms

Hydrated Farms are time-limited incentives programs which offer additional rewards for providing liquidity for selected assets, on top of the rewards from trading fees.

Departing from traditional liquidity mining programs, Hydrated Farms offer several distinctive features: they use Farm NFTs to represent the farm position, they support rewards stacking, and their rewards grow over time thanks to a loyalty multiplier.

On this page you will find further details on the features of Hydrated Farms. If you would like to participate, please visit our step-by-step guide on Hydrated Farms.

Farm NFTs

Whenever a user provides liquidity to the Omnipool and joins a Hydrated Farm, the HydraDX Protocol will mint an NFT which is owned by the user. This NFT represents the user position in the farm and stores certain details such as time of entry. This enables the Protocol to provide sustainable incentives with rewards which grow over time.

The owner of the farm NFT controls the position in the farm as well the underlying liquidity in the Omnipool. In the future, Protocol stakeholders may decide to open up a marketplace for Farm NFTs or enable their usage as collateral.

remarque

Due to the unique properties of the Farm NFTs, joining a given farm multiple times will yield several NFTs.

Rewards Stacking

Hydrated Farms support the possibility to offer rewards in more than one asset. In other words, rewards are stackable.

Any team can reach out to the HydraDX stakeholders with the request to create a Hydrated Farm incentivized by their own TKN. Following this example, the HydraDX governance can decide to also provide HDX as incentives to that farm. As a result, hydrated farmers would receive both HDX and TKN rewards.

Loyalty Multiplier

To encourage more sustainable liquidity provisioning, Hydrated Farms feature a loyalty multiplier - rewards grow over time as liquidity remains in the farm. You can view the exact curve for distributing rewards on the farm detail page.

Once users decide to leave a farm, their loyalty multiplier is reset and they will begin from the base level again if they decide to rejoin.

- + \ No newline at end of file diff --git a/fr/omnipool_impermanent_loss/index.html b/fr/omnipool_impermanent_loss/index.html index 65de6003..3a49a080 100644 --- a/fr/omnipool_impermanent_loss/index.html +++ b/fr/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ Less Impermanent Loss | HydraDX Docs - + - + \ No newline at end of file diff --git a/fr/omnipool_lp/index.html b/fr/omnipool_lp/index.html index 8a08cbd9..0a61d6a1 100644 --- a/fr/omnipool_lp/index.html +++ b/fr/omnipool_lp/index.html @@ -4,13 +4,13 @@ Single-Sided LPing | HydraDX Docs - +

Single-Sided LPing

The cutting-edge design of the HydraDX Omnipool unlocks the possibility of single-sided liquidity provisioning: Anyone can provide liquidity only for the asset they want, and as much as they want (up to the respective TVL cap for the asset). This resolves one of the main drawbacks of standard XYK AMMs which require that liquidity providers (LPs) deposit a pair of assets in equivalent value.

Liquidity in the HydraDX Omnipool is concentrated, meaning that by providing your asset you gain instant exposure to all other assets in the Omnipool. Forget about liquidity fragmentation and the need to spread your liquidity across several trading pools.

The Hub Token LRNA

Single-sided liquidity provisioning is made possible by our hub token called Lerna (LRNA). Every time liquidity is added, the Omnipool will mint a corresponding amount of LRNA to keep the pool in balance. Accordingly, LRNA will be burnt to reflect any removal of liquidity. These mechanisms ensure that the value of LRNA does not significantly fluctuate when assets are added or removed from the Omnipool.

login

Another way to understand the hub token concept is to imagine every single asset within the Omnipool as a synthetic 50/50 liquidity pool, with the only difference being that the 2nd leg of the pair is always LRNA i.e. TKN:LRNA.

This design allows the Protocol to use LRNA as a proxy which reflects the value locked in the Omnipool, including trading activity and price fluctuations, in an abstract manner.

- + \ No newline at end of file diff --git a/fr/omnipool_security/index.html b/fr/omnipool_security/index.html index 5b44dcf6..eb4011c3 100644 --- a/fr/omnipool_security/index.html +++ b/fr/omnipool_security/index.html @@ -4,13 +4,13 @@ State of the Art Security | HydraDX Docs - +

State of the Art Security

The HydraDX Protocol pursues a multi-layered security strategy. On this page you will find a description of the various measures which work together to keep your funds safe.

The most basic layer of the HydraDX security strategy consists carefully conducted research and development, as well as rigorous peer review processes. On top of that, HydraDX strives to have all mission-critical code undergo rigorous audits. The next layer of the security strategy is a generous bug bounty program which makes it worthwhile to find and disclose vulnerabilities (as opposed to exploiting them).

Finally, the protocol has implemented a combination of state-of-the-art measures which are designed to protect your liquidity against unfortunate events such as toxic assets or (economic) exploits.

Audits

The HydraDX protocol conducts audits of all mission-critical code and publishes the audit reports on a regular basis.

The security audit of the Rust implementation of the HydraDX Omnipool was performed by Runtime Verification - an established industry leader with clients such as NASA, Ethereum and Polkadot. The scope of the security audit includes the source code of HydraDX Omnipool pallet,its mathematical logic and asset registry, as well as 3rd party libraries which have been included as a (Substrate) dependency. The results of the audit were published in September 2022, you can consult the full report here.

In March 2022, the economic/math audit of the Omnipool was completed by BlockScience - a leading web3 native firm dedicated to analyzing complex systems for the likes of Graph Protocol and Protocol Labs (Filecoin). The scope of this audit was to provide an overview of the AMM specification with a special attention to the mathematical and economic concepts underpinning the Omnipool, together with the implications of those mechanisms for liquidity provisioning and trading activity. You can consult the full report here, including the addendum by HydraDX with post-factum changes.

Bug Bounty Program

HydraDX has set up a generous bug bounty program which provides strong incentives for the detection and responsible disclosure of bugs and other vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Mechanisms for Protecting Omnipool Liquidity

The HydraDX protocol is continuously researching and implementing mechanisms that keep the Omnipool liquidity safe. These mechanisms are activated in the unfortunate (but not impossible) scenario that an actor tries to drain liquidity from the Omnipool by abusing a toxic asset situation (LUNA-like scenario) or some malicious exploit.

TVL Caps

All assets are subject to a specific TVL cap defining the maximum proportion of liquidity which any given asset can represent in the Omnipool. Riskier assets will have lower caps compared to less risky (high mcap or stable) assets. This allows the HydraDX protocol to significantly limit the damage which may potentially be caused from toxic asset flows: Using a hyper-inflationary asset, attackers cannot drain more liquidity than its TVL cap.

Oracles

On-chain oracles provide average price information for a specified Omnipool asset during a given timeframe (e.g. 10 blocks). Oracles are an essential monitoring tool that allow the HydraDX protocol to detect irregularities and potential price manipulation attacks - and to act accordingly.

Dynamic Withdrawal Fees

To protect the Omnipool liquidity, all withdrawals of liquidity positions are subject to a fee. The withdrawal fee is dynamic, ranging between 0.01% and 1% of the total amount. The exact fee amount is determined at the time of withdrawal based on the asset in question.

The withdrawal fee covers the spread between the current spot price of the asset and the its average price over the previous 10 blocks (fetched from the HydraDX oracles). A large discrepancy between spot and average price indicates a potential price manipulation attack, and a higher withdrawal fee is applied to eliminate the economic incentives for carrying out such an attack.

In the scenario that extreme volatility leads to the spread between the spot price and average oracle price of an asset being greater than 1%, liquidity addition or withdrawal for that asset will be temporarily paused. These operations will again resume once this threshold is respected.

In-block Trade Limits

To protect the Omnipool against economic exploits, there is a limit in place that no more than 50% of an asset's liquidity can be traded in a single block - trades that are greater than this amount should be spread across multiple blocks.

Targeted Function Pausing

If some suspicious behaviour is detected on-chain, Targeted Function Pausing allows the HydraDX Technical Committee to take swift action and temporarily pause certain or all actions relating to specific assets. This action of last resort can help mitigate the damage and allow for further investigation.

- + \ No newline at end of file diff --git a/fr/omnipool_trading/index.html b/fr/omnipool_trading/index.html index d0a1a139..f17245e7 100644 --- a/fr/omnipool_trading/index.html +++ b/fr/omnipool_trading/index.html @@ -4,13 +4,13 @@ Efficient Trading | HydraDX Docs - +

Efficient Trading

The traditional DeFi landscape is characterised by fragmented liquidity which is dispersed across several trading pools. This leads to economic inefficiencies: More hops and shallower liquidity create higher price impact and slippage. By combining all liquidity in a single trading pool, the HydraDX Omnipool enables efficient trading like no other AMM.

Traditional AMMs: Liquidity Fragmentation

The pioneer XYK AMM model marked a pivotal moment for DeFi which made decentralized and permissionless trading possible. The simplicity of XYK pools boosted the initial adoption of DeFi, however today we stand at a point where the resulting economic inefficiencies hinder the continued adoption.

Omnipool

One of the flaws of the XYK model is that trading pools are constrained to pairs of assets. Fragmented liquidity results in a higher price impact due to more hops and slippage. The route of the ETH-AAVE trade in the screenshot above provides a practical example:

  • 85% direct from ETH to AAVE (incurring 0.3% fee);
  • 15% ETH traded for UNI first then the UNI is swapped for AAVE (incurring two 0.3% swap fees).

HydraDX Omnipool: Unified Liquidity

Thanks to the cutting-edge design, liquidity in the Omnipool truly acts as one. By having all the liquidity connected through LRNA, the assets within the Omnipool have direct access to the entirety of liquidity for any other asset that is also deposited into the Omnipool. This allows for a seamless on-chain execution and enables swaps to be completed in a single transaction with no hopping required between various isolated trading pools.

Furthermore, based on internal research, the increase in the number of tokens and total value locked (TVL) within the Omnipool lead to exponential improvements in slippage reduction.

login

To illustrate with an example, imagine the TKN asset is distributed across 4 different liquidity pools with varying levels of liquidity. In the scenario that a trader wants to trade DAI for TKN, they would only have access to the direct liquidity of the $1M TKN-DAI pool. If their trade size is substantial (e.g. $100K+), the majority of the trade will likely be routed through a DAI-ETH pool followed by the TKN-ETH pool in the traditional XYK landscape.

However, with the Omnipool, that same $5mm (50% of the total $10mm TVL) of the TKN asset and $3mm of DAI would be concentrated in one pool. As such, if a trader proceeds to make the same trade in the HydraDX Omnipool, they will get the entire benefit of the $5mm of TKN and $3mm of DAI liquidity in their direct swap, materially reducing the overall price impact.

- + \ No newline at end of file diff --git a/fr/omnipool_treasuries/index.html b/fr/omnipool_treasuries/index.html index ba6d0eea..51591187 100644 --- a/fr/omnipool_treasuries/index.html +++ b/fr/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ Hydrate Your Treasury (B2B) | HydraDX Docs - +

Hydrate Your Treasury (B2B)

The HydraDX Omnipool has an outspoken value proposition for the treasury of any project or DAO. Forget about centralized market makers and inflationary rewards for liquidity mining; the Omnipool can facilitate the creation of a market for your token in a cost-efficient manner - trustless, without hidden costs and while building up your POL from trading fees.

Thanks to its cutting-edge design, the HydraDX Omnipool supports single-sided LPing. Instead of wastefully allocating liquidity mining rewards to incentivize other users to provide liquidity, projects and DAOs can deposit a part of their treasury to the Omnipool and receive instant exposure to all other assets in an ocean of liquidity: Diversified and deep (HydraDX has $20M+ worth of POL which is gradually being deployed).

LPing in the HydraDX Omnipool is truly trustless. Leveraging Polkadot’s unique capability of cross-chain communication (XCM), the Omnipool empowers you to always remain in control of your funds: You can both provide your liquidity and manage it without relying on third parties.

Providing liquidity to the HydraDX Omnipool is not only cost-efficient - it is also profitable. Instead of having your tokens sit idle in your treasury, you can put them to work. You will earn rewards from trading fees, allowing you to build up POL over time. Soon, our upcoming TWAMM/DCA feature will allow you diversify the accumulated POL in other assets (e.g. dollar cost averaged stablecoins or DOT which you can use to bid on your next parachain slot).

Finally, the HydraDX Omnipool enjoys state of the art security. Besides rigorous audits and a generous bug bounty program, we have set up a combination of measures which work together to keep your liquidity safe. Learn more here.

- + \ No newline at end of file diff --git a/fr/participate_in_council_elections/index.html b/fr/participate_in_council_elections/index.html index a8a8db79..7024b3ec 100644 --- a/fr/participate_in_council_elections/index.html +++ b/fr/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ Participer aux Elections du Conseil | HydraDX Docs - +

Participer aux Elections du Conseil

Cet article fournit des directions pas à pas sur comment participer aux élections du Conseil - comment voter pour les membres du conseil et devenir un candidat au Conseil. Il y a deux outils que vous pouvez utiliser à ces fins - Commonwealth.im ou Polkadot/apps.

Si vous vous intéressez au fonctionnement des élections, veuillez vous référer à cet article.

attention

Le module de démocratie HydraDX sera lancé le, ou après le, 15 septembre 2021. Veuillez ne pas tenter les actions montrées avant cette date.

Utilisation de Commonwealth.im

Voter aux élections des membres du Conseil

Vous pouvez voir les membres du Conseil actuels ainsi que les finalistes dans L'onglet conseillers sur la page Commonwealth de HydraDX.

Pour voter pour les membres du Conseil, Cliquez sur Vote.

Entrez le montant de tokens que vous êtes prêt à verrouiller en soutient à vos candidats.

Après ça, choisissez vos candidats préférés en cliquant sur leurs noms. Rappelez vous de choisir plusieurs candidats - Cela aidera l'algorithme à choisir la distribution optimale de candidats pour le Conseil.

Pour voter, cliquez sur Submit vote et signez la transaction.

remarque

Les tokens verrouillés ne peuvent pas être transférés, cependant ils peuvent être utilisés pour voter aux référendums. Vos tokens vont rester verrouillés et utilisés pour les élections suivantes jusqu'à ce que vous décidiez de les déverrouiller.

Postuler comme candidat au Conseil

Vous pouvez soumettre votre candidature d'adhésion au Conseil en naviguant jusqu'à l'onglet Conseillers sur la page Commonwealth de HydraDX.

Cliquez sur Run for council (se présenter au Conseil) ce qui vous emmènera à un page montrant le dépôt minimum pour l'adhésion.

Pour soumettre votre candidature, cliquez sur Sign and send transaction (Signer et envoyer la transaction) et signer en utilisant votre portefeuille.

Utilisation de Polkadot/apps

Voter aux élection de membres du Conseil

Vous pouvez voir les membres du Conseil actuels ainsi que les finalistes sur Gouvernance > Conseil page dans Polkadot/apps.

Pour voter pour les membres du Conseil, cliquez sur Voter.

Entrez le montant de tokens que vous êtes prêt à verrouiller en soutient à vos candidats.

Après ça, choisissez vos candidats dans l'ordre de préférence en les déplaçant de la liste de gauche à la liste de droite. Rappelez vous d'en choisir plusieurs - cela aidera l'algorithme à choisir la distribution optimale de candidats pour le Conseil.

Pour voter, cliquez sur Voter et signer la transaction.

remarque

Les tokens verrouillés ne peuvent pas être transférés, cependant ils peuvent être utilisés pour voter aux référendums. Vos tokens vont rester verrouillés et utilisés pour les élections suivantes jusqu'à ce que vous décidiez de les déverrouiller.

Postuler comme candidat au Conseil

Vous pouvez soumettre votre candidature d'adhésion au Conseil en naviguant jusqu'à Gouvernance > Conseil dans Polkadot/apps.

Cliquez sur Soumettre la candidature va faire apparaître une fenêtre contextuelle.

Sélectionnez le compte que vous voulez voir participer à l'adhésion au Conseil, cliquez sur Soumettre, et signez la transaction.

- + \ No newline at end of file diff --git a/fr/participate_in_referenda/index.html b/fr/participate_in_referenda/index.html index 0c9f6645..d0c0688e 100644 --- a/fr/participate_in_referenda/index.html +++ b/fr/participate_in_referenda/index.html @@ -4,13 +4,13 @@ Participer aux Référendums | HydraDX Docs - +

Participer aux Référendums

Ce post fournit un guide détaillé sur comment participer aux référendums - voter et proposer. Il y a deux outils que vous pouvez utiliser à ces fins - Commonwealth.im ou Polkadot/apps.

Avant de vous décider à participer, nous vous encourageons fortement à lire l'article informatif dans la section Apprendre / Démocratie. Là, vous trouverez des détails importants sur les mécanismes derrière les référendums.

attention

Le module de démocratie HydraDX sera lancé le, ou après le, 15 septembre 2021. Veuillez ne pas tenter les actions montrées avant cette date.

Utiliser Commonwealth.im

Voter dans un Référendum

Vous pouvez voir tous les référendums qui sont ouverts au vote en naviguant sur l'onglet Référendums sur la page Commonwealth de HydraDX.

Pour voter sur un référendum actif, vous devez cliquer dessus. Après quoi, vous verrez une page montrant tous les détails pertinents.

Dans la section Cast Your Vote (Voter), remplissez les information suivantes:

  • Le montant du vote - c'est le montant de tokens HDX que vous êtes prêt à verrouiller pour soutenir le référendum.
  • Le multiplicateur de conviction (Conviction multiplier) - c'est le multiplicateur qui co-détermine le poids de votre vote.

Après ça, votez en cliquant sur Vote yes/oui ou Vote no/non et signez la transaction.

Proposer un Référendum

Pour proposer un référendum, visitez la page Commonwealth HydraDX et cliquez sur le menu du dessus sur New Thread > New democracy proposal.

Remplissez les information des champs montrés ci-dessus. Les paramètres les plus importants sont:

  • Module
  • Function
  • Toute information supplémentaire comme spécifié par la fonction que proposer à être appelée
  • Deposit - le montant de tokens HDX que vous êtes prêt à déposer en soutient à la proposition

Dans l'exemple ci-dessus, le module de proposition est balances, et la fonction est SetBalance qui modifie l'équilibre de solde libre et réservé d'un compte donnée.

Pour soumettre la proposition, cliquez sur Send transaction et signer en utilisant votre portefeuille (wallet).

Après avoir soumis la proposition sur-chaîne et avoir signé la transaction, la proposition devrait apparaître dans la liste des référendums proposés.

attention

À chaque période de vote, la proposition de référendum avec le soutient le plus important (seconding / appui) entre dans le tour de scrutin. À mesure que le nombre de référendums augmente, il n'y a aucune garantie que votre proposition atteigne jamais un appui suffisant pour entrer dans le scrutin. Il n'y a pas d'option pour retirer une proposition de référendum, ce qui veut dire que vos fonds peuvent rester verrouillés pour une période de temps plus longue.

Les propositions de référendum malveillantes sont sanctionnées. Le Conseil HydraDX et le Comité Technique ont le droit d'annuler tout référendum qui a été proposé de mauvaise foi. Par conséquent, les tokens déposés seront détruits.

Utiliser Polkadot/apps

Voter dans un Référendum

Vous pouvez voir tous les référendums qui sont ouverts au vote en naviguant sur Gouvernance > Démocratie dans Polkadot/apps.

Pour voter dans un référendum, cliquez sur le bouton Vote à son côté.

Dans la fenêtre contextuelle, remplissez les informations suivantes:

  • Vote value - c'est le montant de tokens HDX que vous êtes prêts à verrouiller en soutient au référendum
  • Conviction multiplier - c'est le multiplicateur qui co-détermine le poids de votre vote.

Après ça, apportez votre vote en cliquant sur Vote Nay (Non) or Vote Aye (Oui) et signez la transaction.

Proposer un Référendum

Proposer un référendum via Polkadot/apps consiste en deux étapes - soumettre une pré-image, et soumettre une proposition sur-chaîne.

01 Soumettre une pré-image

Pour soumettre une pré-image, visitez Polkadot/apps et naviguez jusqu'à Gouvernance > Démocratie.

Après avoir cliqué sur Soumette la pré-image, vous devriez voir la fenêtre contextuelle suivante:

Remplissez les informations des champs montrés ci-dessus. Les paramètres les plus importants sont:

  • Le compte depuis lequel la proposition est envoyée.
  • La zone de proposition
  • L'action de la proposition

Dans l'exemple ci-dessus, la zone de proposition est balances, et l'action est forceTransfer des tokens d'un compte vers un autre.

Avant de soumettre la pré-image et de signer la transaction, veuillez vous assurer de copier le "preimage hash" (hachage de la pré-image). vous en aurez besoin pour l'étape suivante.

02 Soumettre la proposition

Pour soumettre la proposition de référendum, visitez Gouvernance > Démocratie dans Polkadot/apps.

Après avoir cliqué sur Soumettre la proposition, vous devriez voir la fenêtre contextuelle suivante:

Entrez le hachage (hash) de la pré-image de l'étape précédente, et le montant de tokens que vous êtes prêt à déposer pour la proposition. Le minimum est de 100 000 HDX.

Après avoir soumis la proposition sur-chaîne, et avoir signé la transaction, votre proposition devrait apparaître dans la liste des référendums proposés.

attention

À chaque période de vote, la proposition de référendum avec le soutient le plus important (seconding / appui) entre dans le tour de scrutin. À mesure que le nombre de référendums augmente, il n'y a aucune garantie que votre proposition atteigne jamais un appui suffisant pour entrer dans le scrutin. Il n'y a pas d'option pour retirer une proposition de référendum, ce qui veut dire que vos fonds peuvent rester verrouillés pour une période de temps plus longue.

Les propositions de référendum malveillantes sont sanctionnées. Le Conseil HydraDX et le Comité Technique ont le droit d'annuler tout référendum qui a été proposé de mauvaise foi. Par conséquent, les tokens déposés seront détruits.

- + \ No newline at end of file diff --git a/fr/performance_benchmark/index.html b/fr/performance_benchmark/index.html index cb8c83e4..4732ebb5 100644 --- a/fr/performance_benchmark/index.html +++ b/fr/performance_benchmark/index.html @@ -4,13 +4,13 @@ Benchmark de performance | HydraDX Docs - +

Benchmark de performance

Vous pouvez vous assurer que votre machine correspond aux spécifications techniques requises en exécutant un benchmark de performance. Pour ce faire, suivez les étapes ci-dessous:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Prepare for running the benchmark
## Install Rust following https://rustup.rs
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

## Configure Rust
$ ./scripts/init.sh
$ rustup default nightly

## Install additional libraries
$ apt install python3-pip
$ apt install clang

# Run the benchmark
$ ./scripts/check_performance.sh

Après que le benchmark s'exécute, vous devriez voir une sortie similaire à ce qui suit:

         Pallet          |   Time comparison (µs)    |  diff* (µs)   |   diff* (%)    |            |   Rerun
amm | 773.00 vs 680.00 | 93.00 | 12.03 | OK |
exchange | 804.00 vs 720.00 | 84.00 | 10.44 | OK |
transaction_multi_payment| 218.00 vs 198.00 | 20.00 | 9.17 | OK |

Notes:
- dans les champs "diff" vous pouvez voir la différence entre le temps benchmark de référence et le temps benchmark de votre machine
- Si diff est positif pour les trois données, votre machine répond aux exigences minimums pour faire fonctionner un node HydraDX
- Si diff dévie de -10% ou plus pour certaines données, votre machine pourrait ne pas convenir pour faire fonctionner un node

Vous pouvez voir la différence de performance entre votre machine et la configuration minimale requise dans la colonne diff* (%). Si les trois valeurs dans cette colonne sont positives, votre machine devrait convenir pour faire fonctionner un node validateur HydraDX. Si une des valeurs est en dessous de -10 %, il est déconseillé de faire fonctionner un node HydraDX.

Rejoignez nous sur Discord si vous voulez discuter des résultats du benchmark, notre communauté vous aidera volontiers.

- + \ No newline at end of file diff --git a/fr/polkadotjs_apps_local/index.html b/fr/polkadotjs_apps_local/index.html index e21f232c..3104ba29 100644 --- a/fr/polkadotjs_apps_local/index.html +++ b/fr/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ Se connecter à un node local | HydraDX Docs - +

Se connecter à un node local

Vous pouvez utiliser Polkadot/apps pour vous connecter à votre node HydraDX local. Pour ce faire, vous devez avoir accès au port 9944 qui est utilisé connexions websockets RPC.

attention

Si vous faites fonctionner un node en tant que validateur, nous recommandons fortement que vous blacklistiez le port 9944 pour des connexions à distance (hors LAN). Ce port pourrait être exploité par des personnes tierces pour altérer la performance de votre node, ce qui peut résulter par un slashing et une perte involontaire de fonds. Vous devriez utiliser le port 9944 pour vous connecter à votre node validateur seulement quand le node est dans votre réseau local.

Accéder à votre node local en utilisant Polkadot/apps

Pour accéder à votre node, ouvrez Polkadot/apps et cliquez dans le coin supérieur gauche pour changer de réseau.

Après avoir ouvert le menu, cliquez sur Development et choisissez Local node.

ou dans l'interface en français:

Développement et choisissez Nœud local(propre Nœud)

Régler l'IP si nécessaire et cliquez sur Switch pour passer à votre node local.

Maintenant vous devriez être connecté à votre node local et être capable d'interagir avec.

- + \ No newline at end of file diff --git a/fr/polkadotjs_apps_public/index.html b/fr/polkadotjs_apps_public/index.html index e73f40aa..0dfa6955 100644 --- a/fr/polkadotjs_apps_public/index.html +++ b/fr/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ Se connecter à un node publique | HydraDX Docs - +

Se connecter à un node publique

Il y a deux nodes publiques RPC qui sont maintenus par HydraDX et nos partenaires. Vous pouvez utilisez ces nodes pour interagir avec Snakenet. Vous pouvez vous connecter directement à un node publique avec Polkadot/apps en cliquant sur les liens ci-dessous:

Se connecter manuellement à un node RPC

Pour accéder à un node RPC publique manuellement, ouvrez Polkadot/apps et cliquez dans le coin supérieur gauche pour changer le réseau.

Cliquez sur LIVE NETWORKS (ou Réseau live dans l'interface en français) et choisissez HydraDX.

Choisissez un des nodes et cliquez Switch (ou Appliquer dans l'interface en français).

Maintenant vous devriez être connecté au node PRC publique selectionné.

- + \ No newline at end of file diff --git a/fr/spending_fw/index.html b/fr/spending_fw/index.html index f5079204..0447ab1d 100644 --- a/fr/spending_fw/index.html +++ b/fr/spending_fw/index.html @@ -4,13 +4,13 @@ Contribute to HydraDX | HydraDX Docs - +

Rewarding Contributions to HydraDX

HydraDX welcomes various contributions which are in the interest of the Protocol. Such activities are incentivized with the help of rewards from the HydraDX Treasury.

The present document sets out the general framework for rewarding community contributions. This framework has been approved by the community of HydraDX in a general vote. The spending framework empowers payouts in the mentioned categories by the HydraDX Council, within the defined limits.

Please note in advance that the payout of all bounties and tips mentioned in this document is subject to the full discretion of the HydraDX Council. If you are in doubt whether your effort entitles you to a bounty, please reach out in advance.

You can ask questions in #bounties on the HydraDX Discord.

1. Bug Bounties

HydraDX runs a Bug Bounty program on Immunefi. Bugs and vulnerabilities are classified into three to four categories of severity which determine the maximum size of the bounty:

Blockchain:

  • Critical: $50,000 to $1,000,000;
  • High: $5,000 to $50,000;
  • Medium: $5,000;
  • Low: $1,000.

Websites & Apps:

  • Critical: $5,000 to $50,000;
  • High: $5,000;
  • Medium: $1,000.

Notes:

  • In order to be granted a bounty, bug reports must be made in accordance with the procedure for responsible disclosure and any other guideline posted on the HydraDX Immunefi page;
  • Bounties for critical Blockchain vulnerabilities are capped at 10% of the potential economic damage;
  • The actual size of the rewarded bounties is at the discretion of the Council;
  • Bounties are paid by the treasury in HDX using the 7d MA USD price from an exchange (CEX or DEX once Oracles are available - if in doubt, please discuss with the HydraDX Council in #bounties).

2. Development Bounties

The HydraDX development team will be launching a dashboard with development bounties in an effort to decentralize technical work on the protocol. The dashboard will present the latest bounties together with a description, technical specification and size of the bounty.

The present framework authorizes the HydraDX Council to propose development bounties of up to $100,000 which will be paid by the Treasury in HDX using the 7d MA USD price from an exchange. Bounties exceeding this amount still need to undergo the governance process.

3. Community Management

Efforts spent on Community Management can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange).

New community managers are subject to prior approval by the team.

Here are some of the expectations attached to these roles:

  • Moderate on both Telegram and Discord;
  • Be an ambassador for the project;
  • Show activity on socials;
  • Participate in bi-weekly calls with other community managers;
  • Coordinate translations
  • Ideally already an active member of the Hydra community.

4. Translations

Work on translations can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange). Currently, HydraDX welcomes translations in the following languages (this list can be extended via a referendum):

  • Mandarin
  • Spanish
  • Russian
  • Slovak

New translators are subject to prior approval by the Community Managers and/or HydraDX Council.

5. Other Community Contributions

Are you looking to contribute with an effort which does not fall into one of the categories above? Please feel free to reach out, the HydraDX Council is prepared to consider your case. This spending framework authorizes the HydraDX Council to provide tips up to the value of $100,000 (using the 7d MA USD price from an exchange).

Here are some examples of contributions that could be rewarded:

  • Creating good educational content such as guides, explanative blogs or videos [content creator should liaise with Community Managers & HydraDX Council ahead of and during production process to ensure information is of the highest quality];
  • Provisioning Decentralized infrastructure;
  • Advancing integrations which contribute to the Protocol or the community;
  • Memes (!!), emojis, merch and stickers.
- + \ No newline at end of file diff --git a/fr/staking/index.html b/fr/staking/index.html index 06e18a1f..9aed0a09 100644 --- a/fr/staking/index.html +++ b/fr/staking/index.html @@ -4,13 +4,13 @@ Staking | HydraDX Docs - +

Staking

HydraDX has a long-running HDX staking program which incentivizes user activity in areas that are beneficial to the Protocol. On this page you will find important information regarding the mechanics behind the HDX Staking program. You can also check out our step-by-step guide on staking.

Staking Basics

HDX holders can stake their HDX and receive rewards which become claimable as time passes. Staking rewards are distributed from a dedicated pot that is gradually filled up by different Protocol revenue streams. Initially, the main revenue stream are the LP fees which the HydraDX Protocol accrues from its HDX LP position in the Omnipool. Furthermore, the HydraDX community has approved a proposal to support the APR during the first year of the staking program with an additional subsidy of ~22M HDX from the HydraDX Treasury which is gradually distributed to the staking rewards pot once per day.

Rewards which enter the staking pot are always distributed directly to all stakers at any given moment. The amount that users are entitled to is proportional to the relative size of their stake in the stake pool. However, stakers do not automatically receive the rewards on their account - instead, they need to claim them.

When it comes to claiming rewards, all participants in HDX staking should be aware of the elements of loyalty and gamification. Once rewards are awarded, they cannot be instantly claimed for the full amount - doing so would yield just a fraction of the total rewards, with the remainder being returned the pot for redistribution to all stakers.

Users who want to claim as many rewards as possible should keep their HDX staked without claiming until sufficient time has passed (rewards are “vested” following a bonding curve). The length of the waiting period is dynamic and depends on the user (in)actions. A user who just stakes passively would need to wait ~2 years to claim 95% of their rewards. In contrast, active stakers who collect the maximum amount of action points (more on that below) could claim 95% of their rewards in just over 2 months. These are rough estimates - the actual timelines may vary in accordance with user actions and overall count of referenda.

Boosting Your Rewards

Stakers can increase the pace at which they can claim their rewards by collecting action points and boosting their rewards. Action points can be acquired by performing certain actions that are incentivized by the Protocol. Initially, the only way to collect action points is to participate in the governance of HydraDX by voting on community referenda using the staked HDX.

login

There are 2 factors which determine the amount of action points that stakers will receive: The size of the vote (relative to the total size of their staked HDX), and the conviction multiplier. The higher the conviction multiplier of the vote, the greater its weight. Keep in mind that voting with a conviction multiplier places a temporary lock on the tokens. Stakers looking to achieve the highest rewards boost would be voting with 6x conviction multiplier, thereby locking their HDX for 192 days (counted from the last vote using such conviction). Just a reminder that this lock is not related to staking as such - instead, it is a standard feature of governance in the Polkadot ecosystem (more info in our docs).

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d

Claiming Your Rewards

As they keep their HDX staked, users accumulate rewards over time. These rewards become claimable subject to a bonding curve which is influenced by the boosts from action points (see above).

At any given time, stakers can claim (a portion of) their claimable rewards. By doing so, however, they forfeit the remainder of their non-claimable rewards. These rewards are automatically transferred back to the staking rewards pot which redistributes them to all other stakers. Furthermore, claiming resets the past action points of the user, sending users back to the beginning of the bonding curve for future rewards from staking.

This mechanism creates an interesting gamification dynamic: By remaining longer in the pool of stakers, users not only unlock a greater part of their allocated rewards - they also have the chance to receive a juicy portion of rewards from other stakers who claim or exit early.

Happy staking!

- + \ No newline at end of file diff --git a/fr/testnet_howto/index.html b/fr/testnet_howto/index.html index 691db962..ae58b15f 100644 --- a/fr/testnet_howto/index.html +++ b/fr/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/fr/tip_request/index.html b/fr/tip_request/index.html index 6790a643..0cf407c1 100644 --- a/fr/tip_request/index.html +++ b/fr/tip_request/index.html @@ -4,7 +4,7 @@ Réclamer une récompense de trésorerie | HydraDX Docs - + @@ -12,7 +12,7 @@

Réclamer une récompense de trésorerie

Avec le lancement du Programme récompensé de Nouvel Accord HydraDX, les membres de la communauté peuvent réclamer des récompenses HDX de la trésorerie en tant que récompense pour leurs contributions. Ce guide va vous guider tout au long du procédé de réclamation de récompense. Vous pouvez trouver plus d'informations sur les différents types d'activités qui sont récompensées dans ce post.

Le processus pour réclamer une récompense de trésorie se compose de deux étapes. Dans un premier temps, les contributeurs doivent publier leur requête de récompense sur Commonwealth.im avec une description de la contribution. dans un second temps, la récompense de trésorerie doit être soumit sur la chaîne (on-chain) en utilisant Polkadot/apps.

01 Publier la requête de pourboire dans Commonwealth.im

Par soucis de transparence, toutes les réclamations de récompense doivent être publiées dans un fil (thread) sur la Page HydraDX Commonwealth. Avant d'ouvrir un thread, vous devez lier votre portefeuille HydraDX à Commonwealth.im: Cliquez sur Log in (en haut à droite) et sélectionnez Connect with wallet > polkadot-js.

login

Après avoir choisi votre adresse HDX dans le popup, on vous demandera de signer le message en utilisant votre portefeuille et de configurer un nom d'affichage pour ce portefeuille.

Une fois connecté, vous devez créer un nouveau thread pour votre requête de récompense. Naviguez jusqu'à la partie en haut à droite de la page et cliquez sur New thread > New thread. Vous pouvez aussi directement utiliser ce lien: https://commonwealth.im/hydradx/new/thread.

Vous pouvez utiliser le titre de ce thread pour indiquer le sujet (tip request) et la nature de la contribution. Dans le corps du thread, veuillez fournir les informations suivantes:

  • La période pendant laquelle la contribution a été effectuée
  • Un bref résumé de la contribution
  • Le montant de la récompense réclamée (en HDX)
  • Le temps passé pour la contribution (en heures)
  • Si besoin est, un descriptif plus détaillé incluant la pertinence de la contribution à HydraDX
    • Si c'est approprié, fournissez des informations plus détaillées comme la pertinence de la contribution à HydraDX et un lien vers le PR (dans le cas d'une contribution technique).

Pour référence, vous pouvez regarder cet exemple de requête de pourboire.

Après avoir rempli les informations, postez ce thread et il devrait devenir disponible dans la liste générale.

remarque

Les nominateurs et les validateurs qui ont alloués tout leurs HDXs et qui se retrouvent "coincés" peuvent réclamer une récompense de trésorerie de 1 HDX qui leur permettra de délier certains de leurs tokens. Si cela s'applique à votre cas, veuillez créer un thread Commonwealth en suivant cet exemple.

02 Soumettre la réclamation de pouboire sur la chaîne (On-Chain)

Après avoir publié votre réclamation de récompense de trésorerie, vous devez la soumettre sur chaîne (on-chain). À cet effet, votre portefeuille doit contenir un petit montant de HDX pour couvrir les frais de transaction. Si vous n'avez pas de HDX actuellement, vous n'avez pas besoin d'effectuer cette étape - quelqu'un d'autre va soumettre votre requête de récompense sur chaîne pour vous.

Les réclamations de récompense de trésorerie peuvent être soumises sur chaîne avec Polkadot/apps en utilisant le lien suivant: https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/treasury/tips.

pour soumettre une nouvelle requête de récompense, cliquez sur Proposez une récompense

  • soumettre avec le compte ou submit with account (en anglais) - choisissez le compte qui va signer la transaction pour soumettre la requête de récompense sur chaîne. Ce compte doit contenir un petit montant de HDX pour les coûts de transaction.
  • bénéficiaire ou beneficiary (en anglais) - choisissez ou entrez l'adresse du compte qui recevra la récompense de trésorerie. Ce compte doit correspondre au compte qui a ouvert le thread Commonwealth.
  • raison de la récompense ou tip reason (en anglais) - fournissez l'URL du thread Commonwealth.
login

Pour soumettre la requête de récompense, cliquez sur Proposez une récompense ou Propose tip (en anglais) et signez la transaction.

Une fois la transaction confirmée, vous devriez pouvoir voir votre réclamation de récompense sur la page overview.

login
- + \ No newline at end of file diff --git a/fr/tokenomics/index.html b/fr/tokenomics/index.html index 6db1b843..84ba22d2 100644 --- a/fr/tokenomics/index.html +++ b/fr/tokenomics/index.html @@ -4,13 +4,13 @@ HDX Tokenomics | HydraDX Docs - +

HDX Tokenomics

Purpose

The HDX token is a governance token that allows staked token holders to decide the future of the protocol. Our mission with the HydraDX DAO is to distribute all decision-making to create a trustless liquidity protocol built around community-growth and self-sustainability.

To have a vote in the HydraDX DAO, and to contribute to the determination of any of the topics raised by community members, one must hold the HDX governance token. For more specifically on the governance process, please read our Democracy documentation.

HDX will initially be used for the following:

  • Setting the base network swap fee (the user may change this to any asset)
  • Voting on protocol upgrades
  • Voting on topics raised by community members (inclusive of allocation of Protocol-Owned Liquidity)

HDX Token Allocation

Upon the launch of the HydraDX DAO, the defined maximum supply of HDX tokens was 10 billion HDX. However through the governance-approved supply reduction, this defined maximum supply was reduced to 6.5 billion HDX tokens.

The allocation of these tokens is currently as follows:

  • LBP Participants - 30.5% (~1.983B)
  • Founders and team - 12.5% (810M)
  • Investors - 10.6% (690M)
  • HDX Crowdloan - 7.6% (~494.6M)
  • BSX Crowdloan - 1.9% (~120.7M)
  • DAO treasury - 5.5% (~354.5M)
  • Collators - 3.9% (~251.5M)
  • Growth - 27.6% (~1.796B)

HDX Emission Schedule

As of Sept 2023, ~2.6 billion of HDX tokens are in circulation.

There is currently no concrete emission/release schedule for HDX tokens residing in the Treasury and Growth allocations. HydraDX intends to distribute the supply of HDX in the treasury and growth funds to help fund ecosystem development where opportunities may arise. All of these distributions will be discussed transparently to the community beforehand and voted on by the HydraDX DAO.

Token distributions range from a variety of developmental purposes and growth initiatives, (eg. HDX bonds, liquidity provider rewards, integrations/partnerships with other projects, etc).

- + \ No newline at end of file diff --git a/great-unlock/index.html b/great-unlock/index.html index 7c0a0a55..c34e917b 100644 --- a/great-unlock/index.html +++ b/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/howto_bonds_lbp/bonds1.jpg b/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/howto_bonds_lbp/bonds1.jpg and b/howto_bonds_lbp/bonds1.jpg differ diff --git a/howto_bonds_lbp/bonds2.jpg b/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/howto_bonds_lbp/bonds2.jpg and b/howto_bonds_lbp/bonds2.jpg differ diff --git a/howto_bonds_lbp/index.html b/howto_bonds_lbp/index.html index 52e2814d..75538111 100644 --- a/howto_bonds_lbp/index.html +++ b/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

caution

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
note

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/howto_bridge/index.html b/howto_bridge/index.html index 9fe6fc02..15783465 100644 --- a/howto_bridge/index.html +++ b/howto_bridge/index.html @@ -4,13 +4,13 @@ Bridge Assets | HydraDX Docs - +

Bridge Assets

On this page you will find a step-by-step guide on bridging tokens from the Ethereum ecosystem. Currently there are two methods to bridging to and from Ethereum (via Wormhole):

Wormhole’s Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain.

To/From Ethereum via Moonbeam

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Talisman or Metamask);
caution

Make sure to have enough tokens (ETH) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens.

01 Navigate to Carrier.so

https://www.carrier.so/

caution

Use with caution. All crypto applications can potentially carry risks related to smart contracts/pallets.

metadata

02 Add the Wallets from Source and Destination Network

  • Once you have navigated to Carrier.so, add the wallets needed to allow for bridging to and from the desired networks (1 in image above).
  • In the example above, Metamask was selected as the wallet for Ethereum and Talisman for HydraDX.
metadata

03 Select Networks and Wallets to Bridge

metadata
  • Once Metamask and Talisman are connected, select the network chains (2) and select the previously connected wallets (3).

04 Select Asset to Bridge

  • Select the token asset and amount of tokens you would like to bridge (4).

05 Bridge Tokens

  • Within Settings (5), you can select whether to Auto Relay the transaction. It is recommended that this is toggled on.
metadata
  • Click Confirm & Begin Transaction (6) to proceed. This will prompt your wallet to sign the transactions. Once confirmed, you are all done!

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

To/From Ethereum via Acala

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Metamask);
  • Bind your two wallets following Acala's guide. Completing this action will require a small amount of ACA.
caution

Make sure to have enough tokens (ETH and ACA) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens, and for binding your wallet addresses.

01 Navigate to Acala Bridge Page

https://apps.acala.network/bridge

Once you have been directed to Acala bridge page, follow the actions below:

metadata

Step 2: Connect to Your Account

  • Connect your account (1).
  • Select the chains you intend to bridge to and from (2), in this case, it will be Ethereum as the Origin Chain and HydraDX as the Destination Chain.
  • Connect to your Metamask account that you are bridging from (3).

Step 3: Bridge Tokens

  • Enter the amount of tokens and the token for bridging (4).
  • To commence the bridge, click Approve Tokens (5) and sign the transaction using your Metamask wallet app.
  • Once the tokens are approved for transfer, click Send Tokens (5). This starts the bridging process cross-chain.
  • Once the transaction has been processed by Wormhole, click Redeem & Route Tokens (5). This action results in you receiving the tokens on the destination chain.

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

- + \ No newline at end of file diff --git a/howto_dca/index.html b/howto_dca/index.html index d1badd43..f4c3b94c 100644 --- a/howto_dca/index.html +++ b/howto_dca/index.html @@ -4,13 +4,13 @@ Place a DCA Order | HydraDX Docs - +

Place a DCA Order

On this page you will find a step-by-step guide for setting up a DCA order in the HydraDX Omnipool.

Before proceeding, we encourage you to visit our DCA product page in order to get yourself familiar with the HydraDX implementation of the dollar-cost averaging strategy.

Step 1: Navigate to HydraDX DCA Page

https://app.hydradx.io/dca

Step 2: Connect to Your Account

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 3: Set up DCA Order

  • Select the asset you will use to pay for the swap; Enter the order amount for each DCA trade, and the total order size (2);
  • Select the time interval for each DCA swap (3);
  • Select the asset you would like to receive from the swap (4);
  • For advanced users who would like to set up orders at specific block intervals, you can toggle the switch Advanced Settings (5) to set this up;
  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (6);
  • To complete the DCA order, click on Schedule DCA trades (7) and sign the transaction using your wallet app.

Step 4: View your DCA Order

  • After submitting it, your DCA order will appear under DCA Orders;
  • To see the details, click the Dropdown Arrow (8);
  • You can cancel your DCA order for the remaining amount by clicking on Terminate (9).
- + \ No newline at end of file diff --git a/howto_hydrated_farms/index.html b/howto_hydrated_farms/index.html index 2e894d08..c44fed35 100644 --- a/howto_hydrated_farms/index.html +++ b/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ Join Hydrated Farms | HydraDX Docs - +

Join Hydrated Farms

With Hydrated Farms, providing liquidity to selected assets is incentivized by additional rewards on top of rewards from trading fees. To learn more, please visit the dedicated product page.

00 Navigate to Liquidity Page

https://app.hydradx.io/liquidity

01 Provide Liquidity

Incentivized assets can be identified by the Farm rewards section which displays all available rewards for a given farm.

metadata

To join a farm, you must first provide liquidity (step-by-step guide here).

02 Join Farm

Once you have provided liquidity for an incentivized asset, you can join its farm.

metadata

To do so, click on Join farms (located next to your liquidity position) and sign the transaction using your wallet app.

Happy hydrated farming!

- + \ No newline at end of file diff --git a/howto_lp/index.html b/howto_lp/index.html index 4409c7b7..7317ea5a 100644 --- a/howto_lp/index.html +++ b/howto_lp/index.html @@ -4,13 +4,13 @@ Provide Liquidity | HydraDX Docs - +

Provide Liquidity

On this page you will find a step-by-step guide for providing liquidity in the HydraDX Omnipool. Becoming a liquidity provider allows you to earn rewards from the fees generated by trades in the pool.

Before deciding to become a liquidity provider, we encourage you to visit our product page and to get yourself familiar with the unique features of the HydraDX Omnipool.

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Navigate to Omnipool Liquidity

https://app.hydradx.io/#/liquidity

metadata

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Managing Your Liquidity

Adding Liquidity

To add liquidity for a given asset, click the button Add liquidity which is located right next to that asset (3).

info

In the HydraDX Omnipool, each individual asset has a Total Value Locked (TVL) cap. This means that once the cap has been reached, users can no longer further add liquidity for that specific asset.

The individual caps for each asset will be reviewed from time to time by the team; any suggested revisions (either from team or the community) will be submitted as proposals via governance and voted on.

metadata

Fill in the amount of liquidity you wish to provide (1), click Add liquidity (2) and sign the transaction using your wallet.

Next, you can learn how to join Hydrated Farms and earn additional rewards on top of the rewards from trading fees.

Removing Liquidity

metadata

To remove liquidity, toggle the dropdown located right next to the relevant asset (1) and click Remove liquidity (2) on the position you wish to exit.

metadata

Toggle or enter the amount of liquidity you wish to withdraw (3), click on Remove liquidity (4) and sign the transaction using your wallet.

- + \ No newline at end of file diff --git a/howto_stake/index.html b/howto_stake/index.html index 15d4b170..46ca89da 100644 --- a/howto_stake/index.html +++ b/howto_stake/index.html @@ -4,13 +4,13 @@ Stake HDX | HydraDX Docs - +

Stake HDX

Staking allows users to stake their HDX tokens and earn rewards which vest over time. This page contains a step-by-step guide on how to stake your HDX. Before proceeding, we recommend that you get familiar with the basics of HDX staking.

If you don't have any HDX, you can obtain some on our trade page by swapping against a range of assets supported by the Omnipool.

Step 0: Navigate to HydraDX Staking Page

https://app.hydradx.io/staking

Connect your wallet to HydraDX by clicking Connect Account.

Step 1: Stake Your HDX

  • Select the amount of HDX tokens you would like stake (3).
  • Click on Stake (4) to confirm and sign the transaction using your wallet app.
metadata

Step 2: Keep Your HDX Staked

  • The amount of rewards you receive is determined by the size of your staked HDX relative to the whole stake pool.
  • As time passes, you unlock a greater portion of your allocated rewards. The rate of unlocking is determined by a rewards bonding curve.
  • Learn more in the Staking product docs.

Step 3: Boost Your Rewards

  • Collect Action Points to boost your rewards and increase the pace at which you unlock rewards.
  • You can collect Action Points by voting on referenda. The more staked HDX you use for the vote and the higher the Conviction Multitplier - the more Action Points you receive.
  • Learn more in the Staking product docs.

Step 4: Claim Your Rewards

  • Review your Staking statistics to observe and plan your own staking strategy (5).
  • Once you are done staking, Claim your unlocked rewards (8).
metadata
caution

Every time you claim unlocked staking rewards, you forfeit any locked rewards which are redistributed to all other stakers. Furthermore, your past Action Points will be reset.

For instance, if a staker claims rewards when 75% of the rewards are available, the remaining 25% is forfeited. The staker must then wait for the same duration to claim 75% of the subsequent batch of rewards.

- + \ No newline at end of file diff --git a/howto_trade/index.html b/howto_trade/index.html index ace47a92..bf5c7351 100644 --- a/howto_trade/index.html +++ b/howto_trade/index.html @@ -4,13 +4,13 @@ Trade in Omnipool | HydraDX Docs - +

Trade in Omnipool

This page provides a step-by-step guide which will help you execute your first trades using the HydraDX Omnipool.

The HydraDX Omnipool is a next-gen AMM which unlocks unparalleled efficiencies, you can find out more in our product documentation.

metadata

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Enter Omnipool

https://app.hydradx.io/#/trade

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Execute a Trade

The HydraDX Trade UI allows you to intuitively execute a trade:

  • Select the pair of tokens you intend to trade (2);
  • Enter the amount of tokens for the trade (3).
    You can enter the amount of tokens you would like to pay with (e.g. 5000 DAI), but you can also enter the amount of tokens you would like to receive (e.g. 1000 HDX);
  • If you would like to adjust your slippage preferences, you can do so in Settings (4);
  • To complete the trade with instant execution (pre-selected) (5), click on Swap (7) and sign the transaction using your wallet. Otherwise, follow the additional steps below.

04 Execute a Split Trade

If your trade is large enough so that price impact would be > 0.15%, the UI will allow you to select Split trade (6) - breaking your trade into multiple smaller trades executed over < 3 hours and therefore reducing your price impact.

  • Select the pair of tokens and amounts as in 03 Execute a Trade above;
  • Select Split trade (6);
  • To schedule your Split trade execution, click on Place trades (7) and sign the transaction using your wallet.

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/howto_wallet_parity_signer/index.html b/howto_wallet_parity_signer/index.html index 05039bb4..0ab73263 100644 --- a/howto_wallet_parity_signer/index.html +++ b/howto_wallet_parity_signer/index.html @@ -4,14 +4,14 @@ Use Parity Signer | HydraDX Docs - +

Use Parity Signer

Parity Signer is a mobile app which turns your iOS or Android device into a dedicated hardware wallet for Polkadot, Kusama, and any other Substrate-based chain. It allows you to keep your private keys offline while still being able to conveniently sign transactions in an air-gapped way using QR codes.

Set Up Parity Signer

Before You Start: Stay Safe

Start clean

Before installing Parity Signer, make sure that your phone is in a clean state. If it has been used, perform a factory reset and do not install any other apps besides Parity Signer.

Don’t Insert Sim

If possible, don’t turn on WiFi or use a secure WiFi connection, preferably with no other connected devices and a reputable VPN provider to connect, update the device, and install the Parity signer app.

Use Strong Passwords

For robust security, use long passwords for the device and the accounts you need to create to use it.

Setup New Account

Don’t use your old google ID or apple ID, create a new one specifically for this use which will be used only to download updates and parity signer. In case of Android device it’s better to not use WiFi or google account at all. We recommend using some sort of OS that encrypts your data like Lineage O.S. If an email is required, create a new one. Alternatively, you can create new apple id and email on iOS.

No Biometrics

Avoid fingerprint scanners, face ID, or shot numeric codes as they are exploitable. Use a strong password instead.

Disable All Signal-receiving Features

Use airplane mode and make sure to disable all of these features manually. If you are on an iOS device, turn it off and ask to auto-join networks and hotspots in the WiFi settings. Including:

  • Location services
  • WiFi (if required to upgrade or setup, disable right after the update)
  • Bluetooth

Logout From All Accounts

Log out from App stores, iCloud, and any other accounts you’ve joined.

Updating Your Device

If you are using WiFi to update your device, remember to disable it right after the update and use it only in a secure environment, preferably through a secure and encrypted VPN channel. After the update is complete, forget the WiFi network to make sure you don't automatically rejoin.

Install Parity Signer

Install Parity Signer from the official app store for your device (iOS / Android).
Make sure that the application you are downloading has been published by Parity Technologies.

Create a New Account

To create a new account, follow the steps below.

01 Add Seed

Open the Parity Signer app and select New seed.

metadata

02 Back Up your Recovery Phrase

The app will display your recover phrase. Write it down and store it in a safe place.

metadata

After completing this, you are all set to go! You can use your phone passcode or authentication method (fingerprint / face id) in Parity Signer.

danger

Stay safe!

Anyone with your seed phrase can access your funds, and there is no recourse for someone stealing your seed phrase.

To protect your seed phrase, consider the following tips:

  • Never store your seed phrase as a digital file on any device.
  • Always write down your seed phrase with a pen and paper.
  • Store the paper with your seed phrase on it somewhere safe.
  • Never give your seed phrase to anybody, including support staff.

Connect to Polkadot.js/apps

Optionally, you can add your Parity Signer account into the Polkadot.js browser extension which will allow you to view your balances on the Polkadot.js/apps accounts page and to sign transactions more easily.

On Polkadot.js/apps

To add your account, open the Polkadot.js browser extension, click on + and select Attach external QR-signer account.

metadata

On Parity Signer

  • Open Keys tab in the bottom menu;
  • Select the network you will be using from the dropdown menu next to chain;
  • Select your desired account or sub-account;
  • You will see a QR code which you need to scan with your device camera.

Add HydraDX Chain

To use Parity Signer, you first need to add a new chain to Parity Signer. If you want to use Parity only for Polkadot or Kusama, you can skip this step and proceed with updating metadata. To add a new chain, you need to scan a QR code with base information about the chain.

01 Get Chain Specs

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select HydraDX as the desired chain. After that, click on Chain Specs.

metadata

02 Add Specs

On your Parity Signer, click Scanner, scan the QR code and click Add new chain.

Use Parity Signer

danger

Always make sure you are scanning a QR code signed by a trusted verifier.

Sign a Transaction

To sign a transaction from your parity signer, we recommended adding it to polkadot.js extension for ease of use. Until more chains can work with Parity Signer directly, it will be the most convenient way to use it inside applications on your desktop.

When signing a transaction using your Parity Signer, Polkadot.js/apps will display a QR code.

metadata

Scan the QR code using Parity Signer and click on Unlock key and sign.

metadata

Your Parity Signer will now display a QR code. To complete signing the transaction, switch back to Polkadot.js/apps and click on Scan signature via camera.

Update Metadata

To use the Parity Signer, you require the latest metadata for decoding transactions in the Parity Signer. You can acquire the metadata by scanning a multi-part QR code containing this data, allowing the Parity Signer to decode the actual transaction and display it correctly before you sign. This step is similar to updating your ledger application.

01 Get Metadata

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select the desired chain. After that, click on Metadata.

metadata

02 Update

On your Parity Signer, click Scanner, and update the Metadata by scanning the QR code

- + \ No newline at end of file diff --git a/howto_xcm/index.html b/howto_xcm/index.html index 8a302246..576042db 100644 --- a/howto_xcm/index.html +++ b/howto_xcm/index.html @@ -4,13 +4,13 @@ Cross-chain Transfer | HydraDX Docs - +

Cross-chain Transfer

On this page you will find a step-by-step guide for performing cross-chain transfers.

Cross-chain transfers allow you to transport non-native assets to the HydraDX chain from other Polkadot parachains, or from Polkadot itself.

Currently, the following tokens are supported by HydraDX for cross-chain transfers:

  • DOT
  • DAI (from Acala, bridged via Wormhole)
  • ETH (from Acala, bridged via Wormhole)
  • HDX

00 Prerequisites

Before you continue, please make sure you have sufficient amount of tokens on the destination chain for fees (ACA or DOT).

01 Navigate to Cross-chain Transfers

https://app.hydradx.io/#/cross-chain

metadata

02 Connect Your Account

Click on Connect wallet and connect to your preferred Polkadot wallet. After that, select your account.

03 Cross-chain Transfer

  • Select the source chain and the destination chain;
  • Select the asset you intend to transfer and enter the amount;
  • Enter the destination address. It should automatically populate with your address on that chain, but you can also change it to another address;
  • Click Transfer and sign the transaction using your wallet.
- + \ No newline at end of file diff --git a/identity/index.html b/identity/index.html index ef51be62..ea61dab2 100644 --- a/identity/index.html +++ b/identity/index.html @@ -4,13 +4,13 @@ Set your Identity | HydraDX Docs - +

Set your Identity

Account holders have the possibility to set their identity by prodiving specific information and storing it on-chain. Besides that, the identity information can optionally be submitted to the HydraDX registrars for verification. By setting and verifying their identity, validators and nominators help safeguard the trust in the network.

note

If you are participating as a HydraDX validator we highly recommend that you both set your identity and undergo the verification process. Verified validators appear more trustworthy and attract more nominations, thereby increasing their chances to be included in the set of active validators.

01 Set identity

To set your identity, open Polkadot/apps (connected to HydraDX Snakenet network) and navigate to My accounts. Alternatively, you can follow this link:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

On the accounts page, locate the account holding your bonded HDX tokens. After that, click on the three dots next to the account (on the right side) and select Set on-chain identity.

authorize

You will see a popup called register identity. Here, you can enter the following information:

  • legal name
  • email
  • web address
  • twitter
  • riot name (in case you are using Matrix messaging)
note

All this information is optional - feel free to only provide the details you choose. However, if you are running a validator node, we encourage you to set your email. This would allow us to contact you in case we encounter issues with your node.

In the last field of the popup, you can see the amount of HDX you need to deposit to store your identity information. You will receive this deposit back once you decide to clear your identity at a later point.

authorize

After filling out the information, click on Set Identity and sign the transaction using the Polkadot.js browser extension. Once the transaction is confirmed, your identity is set.

02 Submit your identity for verification

After you have set your identity, you can submit it to the network registrars for verification. To do so, open Polkadot/apps and navigate to Developer > Extrinsics. Alternatively, you can follow this link:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

After selecting the relevant HydraDX account from the last step, you need to fill out the following information:

  • extrinsic: identity
  • action: requestJudgement
  • reg_index: here you need to enter the ID of the registrar that you choose to carry out the verification.
    HydraDX has 2 registrars: Simon Kraus - HydraSik (ID: 0) and Jimmy Tudeski - stakenode (ID: 1).
  • max_fee: here you need to enter the maximum fee in HDX that you are willing to pay to the registrar for the verification. Only registrars with a fee below your max_fee will be eligible to carry out the verification.

To submit your verification request, click on Submit Transaction and sign the transaction.

authorize

Please note that the process of identity verification may take some time to complete. To see the status of your request, navigate to My accounts and hover the section displaying your identity - you will see a popup showing the current status.

03 Outcome of the verification procedure

After processing your verification request, the registrar will submit one of the following judgements which will become visible in your identity status:

  • Unknown - default value, no judgement has been made yet.
  • Reasonable - the provided information appears reasonable, however no in-depth checks were made.
  • KnownGood - the information is correct.
  • OutOfDate - the information was correct in the past but it is now out of date.
  • LowQuality - the information is unprecise but it can be fixed by updating it.
  • Erroneous - the provided information is wrong and might indicate a malicious intent.
- + \ No newline at end of file diff --git a/index.html b/index.html index ed7abf5d..f93b49ee 100644 --- a/index.html +++ b/index.html @@ -4,13 +4,13 @@ Meet Omnipool | HydraDX Docs - +

Meet Omnipool

HydraDX is a next-gen DeFi protocol which is designed to bring an ocean of liquidity to Polkadot. Our tool for the job the HydraDX 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 HydraDX 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).

The design of the HydraDX 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). 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).

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).

The HydraDX 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).

Building upon 2+ years of R&D, HydraDX 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).

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/lbp/index.html b/lbp/index.html index 6921e0cd..10067ed7 100644 --- a/lbp/index.html +++ b/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

danger

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/learn_amm/index.html b/learn_amm/index.html index a221e8cb..34454364 100644 --- a/learn_amm/index.html +++ b/learn_amm/index.html @@ -4,13 +4,13 @@ What are AMMs? | HydraDX Docs - +

What are AMMs?

This article provides an introduction to Automated Market Makers (AMMs) together with some of their underpinning concepts such as slippage, liquidity provisioning and impermanent loss.

This introductory information will help you understand better the mechanics behind the HydraDX Omnipool which you can find described in our product documentation.

A Short Intro into AMMs

To explain Automated Market Makers (AMMs) and how they work, we can contrast them to their centralized counterpart: Order books.

Order Books

Order books provide a mechanism which is deployed by centralized exchanges to facilitate trading between two assets. Users can place a Buy or Sell order in an electronic list managed by the exchange. The orders in this so-called Order Book are organized by price level and progressively filled as demand shifts and orders are being matched. The limitations of order books become apparent against the background of their centralized nature.

The need for an intermediary to “keep” the order book and to facilitate the process of order matching creates a dependency on a central authority. This central authority has control over the trading and needs to be trusted by the participants. In times of substantial volume traffic and volatility, the central authority can decide to halt trading and stop performing its market-making function. Furthermore, the process of adding new tradable assets is permissioned and projects may need to pay in advance to get their assets listed.

AMMs

Automated Market Makers (AMMs) is the answer by the DeFi industry to order books. AMMs provide a decentralized, permissionless way of trading tokens without the need to subdue oneself to a central authority of control.

AMMs consist of liquidity pools that hold the available liquidity of the underlying tradable assets. This liquidity is provided by users (the so-called “liquidity providers”) who are incentivized to do so by the prospect of earning rewards from the fees generated by trades in the pool.

In the case of AMMs, any user can execute a Buy or Sell order on top of a given trading pool. The price of the trade is determined on the spot by a deterministic algorithm which takes as input the relationship between the liquidity of the traded assets, together with other factors which depend on the particular AMM implementation.

Slippage

When a trade is executed, users may experience a common side-effect of AMMs known as slippage. This is the difference between the expected price of a trade and the price when the trade is actually executed.

Slippage is determined by the amount of liquidity available within the trading pool. If there is a low amount of liquidity provided for the asset, then the slippage percentage when transacting with big orders will be higher.

Providing Liquidity

Thanks to the decentralized nature of an AMM, anyone can become a liquidity provider (LP) for a liquidity pool by depositing some amount of value in return for a token representing their liquidity position.

LPs are rewarded with fees for providing this liquidity based on the trading activity experienced by the asset for which they have provided liquidity.

Impermanent Loss (IL)

Impermanent loss (IL) is a risk faced by liquidity providers which embodies the difference in value between holding tokens in an AMM as opposed to holding them in your wallet.

Liquidity pools consist of multiple tokens (usually two) which are pooled together. IL occurs when the tokens inside the pool diverge in price. The greater the divergence, the greater the risk of negative returns for the pool's LPs.

The risk is referred to as "impermanent" because the loss is only realized when liquidity is withdrawn from the pool. If the relative prices of tokens in the pool return to their original state (when the tokens were deposited), the loss is minimized or eliminated. The loss will become permanent at the moment when the liquidity is withdrawn, leading to reduced earnings.

As such, LPs need to weigh the fees and rewards earned from LPing versus simply holding their tokens in their wallets.

- + \ No newline at end of file diff --git a/node_monitoring/index.html b/node_monitoring/index.html index e098c25e..fe42c9c8 100644 --- a/node_monitoring/index.html +++ b/node_monitoring/index.html @@ -4,7 +4,7 @@ Node Monitoring | HydraDX Docs - + @@ -34,7 +34,7 @@ Set http://localhost:9090/ and click Save and Test.

Importing the Dashboard

Please click the Plus-button in the main navigation and select import.

We will use the HydraDX Dashboard layout, so simply input the id 14158 and hit the Load-button.

You don't need much configuration here, just make sure Prometheus is used as the datasource.
You can now finish the import.

You should now see your dashboard right away.
If some panels are empty please ensure your selection above the panels is like this:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/omnipool_dca/index.html b/omnipool_dca/index.html index d2033dcf..a09ce5ae 100644 --- a/omnipool_dca/index.html +++ b/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA Trading | HydraDX Docs - +

DCA Trading

HydraDX DCA and Split Trade (easy DCA) are two user-friendly features which allow traders to implement the dollar-cost-averaging (DCA) strategy when trading in the Omnipool - in a permissionless and non-custodial way.

Following the DCA strategy, orders are not placed at once but instead split into smaller trades which are executed at regular intervals of time. By doing so, traders may protect themselves against price volatility and achieve an average price. Additionally, splitting a large order in smaller chunks will result in less slippage.

HydraDX has two DCA implementations - the full DCA feature, and Split Trade (easy DCA) which can be found on the main trading page. Further down, you can learn more about these features.

If you are looking for step-by-step guidance, check out the how-to place a DCA order guide.

HydraDX DCA

HydraDX DCA provides an intuitive UI which enables users to fine-tune their DCA orders in the Omnipool.

When setting up their order, users specify the amount of Asset A they would like to spend in order to obtain Asset B, as well as the frequency of the trades - in hours (approximation) or number of blocks (more granularity).

After placing the order, the HydraDX DCA pallet makes sure that trades are scheduled at the specified intervals until the predetermined amount of Asset A has been spent. Placing multiple DCA orders which are executed in parallel is supported.

Users can track the status of their orders on the UI. Open orders can at any time be terminated for the remaining amount.

Split Trade (easy DCA)

Split Trade is a more simple implementation of DCA directly into the main trade page. It provides users with a one-click solution for splitting larger orders in order to protect themselves from slippage.

When activated, Split Trade will split the order in smaller chunks until the size of the trades is small enough to achieve <0.1% slippage (estimate only - the exact slippage for future trades can never be predicted in advance).

Open Split Trade orders can be terminated by the user at any time, just like any regular DCA order.

- + \ No newline at end of file diff --git a/omnipool_design/index.html b/omnipool_design/index.html index 3e91414d..7a55b708 100644 --- a/omnipool_design/index.html +++ b/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool Design | HydraDX Docs - + @@ -46,7 +46,7 @@ c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).

- + \ No newline at end of file diff --git a/omnipool_hydrated_farms/index.html b/omnipool_hydrated_farms/index.html index 0dd7b244..cbc932a8 100644 --- a/omnipool_hydrated_farms/index.html +++ b/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ Hydrated Farms | HydraDX Docs - +

Hydrated Farms

Hydrated Farms are time-limited incentives programs which offer additional rewards for providing liquidity for selected assets, on top of the rewards from trading fees.

Departing from traditional liquidity mining programs, Hydrated Farms offer several distinctive features: they use Farm NFTs to represent the farm position, they support rewards stacking, and their rewards grow over time thanks to a loyalty multiplier.

On this page you will find further details on the features of Hydrated Farms. If you would like to participate, please visit our step-by-step guide on Hydrated Farms.

Farm NFTs

Whenever a user provides liquidity to the Omnipool and joins a Hydrated Farm, the HydraDX Protocol will mint an NFT which is owned by the user. This NFT represents the user position in the farm and stores certain details such as time of entry. This enables the Protocol to provide sustainable incentives with rewards which grow over time.

The owner of the farm NFT controls the position in the farm as well the underlying liquidity in the Omnipool. In the future, Protocol stakeholders may decide to open up a marketplace for Farm NFTs or enable their usage as collateral.

note

Due to the unique properties of the Farm NFTs, joining a given farm multiple times will yield several NFTs.

Rewards Stacking

Hydrated Farms support the possibility to offer rewards in more than one asset. In other words, rewards are stackable.

Any team can reach out to the HydraDX stakeholders with the request to create a Hydrated Farm incentivized by their own TKN. Following this example, the HydraDX governance can decide to also provide HDX as incentives to that farm. As a result, hydrated farmers would receive both HDX and TKN rewards.

Loyalty Multiplier

To encourage more sustainable liquidity provisioning, Hydrated Farms feature a loyalty multiplier - rewards grow over time as liquidity remains in the farm. You can view the exact curve for distributing rewards on the farm detail page.

Once users decide to leave a farm, their loyalty multiplier is reset and they will begin from the base level again if they decide to rejoin.

- + \ No newline at end of file diff --git a/omnipool_impermanent_loss/index.html b/omnipool_impermanent_loss/index.html index c0ce3d33..e502aedf 100644 --- a/omnipool_impermanent_loss/index.html +++ b/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ Less Impermanent Loss | HydraDX Docs - + - + \ No newline at end of file diff --git a/omnipool_lp/index.html b/omnipool_lp/index.html index 11ed2b14..41670218 100644 --- a/omnipool_lp/index.html +++ b/omnipool_lp/index.html @@ -4,13 +4,13 @@ Single-Sided LPing | HydraDX Docs - +

Single-Sided LPing

The cutting-edge design of the HydraDX Omnipool unlocks the possibility of single-sided liquidity provisioning: Anyone can provide liquidity only for the asset they want, and as much as they want (up to the respective TVL cap for the asset). This resolves one of the main drawbacks of standard XYK AMMs which require that liquidity providers (LPs) deposit a pair of assets in equivalent value.

Liquidity in the HydraDX Omnipool is concentrated, meaning that by providing your asset you gain instant exposure to all other assets in the Omnipool. Forget about liquidity fragmentation and the need to spread your liquidity across several trading pools.

The Hub Token LRNA

Single-sided liquidity provisioning is made possible by our hub token called Lerna (LRNA). Every time liquidity is added, the Omnipool will mint a corresponding amount of LRNA to keep the pool in balance. Accordingly, LRNA will be burnt to reflect any removal of liquidity. These mechanisms ensure that the value of LRNA does not significantly fluctuate when assets are added or removed from the Omnipool.

login

Another way to understand the hub token concept is to imagine every single asset within the Omnipool as a synthetic 50/50 liquidity pool, with the only difference being that the 2nd leg of the pair is always LRNA i.e. TKN:LRNA.

This design allows the Protocol to use LRNA as a proxy which reflects the value locked in the Omnipool, including trading activity and price fluctuations, in an abstract manner.

- + \ No newline at end of file diff --git a/omnipool_security/index.html b/omnipool_security/index.html index ff8251bc..cf6f8f24 100644 --- a/omnipool_security/index.html +++ b/omnipool_security/index.html @@ -4,13 +4,13 @@ State of the Art Security | HydraDX Docs - +

State of the Art Security

The HydraDX Protocol pursues a multi-layered security strategy. On this page you will find a description of the various measures which work together to keep your funds safe.

The most basic layer of the HydraDX security strategy consists carefully conducted research and development, as well as rigorous peer review processes. On top of that, HydraDX strives to have all mission-critical code undergo rigorous audits. The next layer of the security strategy is a generous bug bounty program which makes it worthwhile to find and disclose vulnerabilities (as opposed to exploiting them).

Finally, the protocol has implemented a combination of state-of-the-art measures which are designed to protect your liquidity against unfortunate events such as toxic assets or (economic) exploits.

Audits

The HydraDX protocol conducts audits of all mission-critical code and publishes the audit reports on a regular basis.

The security audit of the Rust implementation of the HydraDX Omnipool was performed by Runtime Verification - an established industry leader with clients such as NASA, Ethereum and Polkadot. The scope of the security audit includes the source code of HydraDX Omnipool pallet,its mathematical logic and asset registry, as well as 3rd party libraries which have been included as a (Substrate) dependency. The results of the audit were published in September 2022, you can consult the full report here.

In March 2022, the economic/math audit of the Omnipool was completed by BlockScience - a leading web3 native firm dedicated to analyzing complex systems for the likes of Graph Protocol and Protocol Labs (Filecoin). The scope of this audit was to provide an overview of the AMM specification with a special attention to the mathematical and economic concepts underpinning the Omnipool, together with the implications of those mechanisms for liquidity provisioning and trading activity. You can consult the full report here, including the addendum by HydraDX with post-factum changes.

Bug Bounty Program

HydraDX has set up a generous bug bounty program which provides strong incentives for the detection and responsible disclosure of bugs and other vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Mechanisms for Protecting Omnipool Liquidity

The HydraDX protocol is continuously researching and implementing mechanisms that keep the Omnipool liquidity safe. These mechanisms are activated in the unfortunate (but not impossible) scenario that an actor tries to drain liquidity from the Omnipool by abusing a toxic asset situation (LUNA-like scenario) or some malicious exploit.

TVL Caps

All assets are subject to a specific TVL cap defining the maximum proportion of liquidity which any given asset can represent in the Omnipool. Riskier assets will have lower caps compared to less risky (high mcap or stable) assets. This allows the HydraDX protocol to significantly limit the damage which may potentially be caused from toxic asset flows: Using a hyper-inflationary asset, attackers cannot drain more liquidity than its TVL cap.

Oracles

On-chain oracles provide average price information for a specified Omnipool asset during a given timeframe (e.g. 10 blocks). Oracles are an essential monitoring tool that allow the HydraDX protocol to detect irregularities and potential price manipulation attacks - and to act accordingly.

Dynamic Withdrawal Fees

To protect the Omnipool liquidity, all withdrawals of liquidity positions are subject to a fee. The withdrawal fee is dynamic, ranging between 0.01% and 1% of the total amount. The exact fee amount is determined at the time of withdrawal based on the asset in question.

The withdrawal fee covers the spread between the current spot price of the asset and the its average price over the previous 10 blocks (fetched from the HydraDX oracles). A large discrepancy between spot and average price indicates a potential price manipulation attack, and a higher withdrawal fee is applied to eliminate the economic incentives for carrying out such an attack.

In the scenario that extreme volatility leads to the spread between the spot price and average oracle price of an asset being greater than 1%, liquidity addition or withdrawal for that asset will be temporarily paused. These operations will again resume once this threshold is respected.

In-block Trade Limits

To protect the Omnipool against economic exploits, there is a limit in place that no more than 50% of an asset's liquidity can be traded in a single block - trades that are greater than this amount should be spread across multiple blocks.

Targeted Function Pausing

If some suspicious behaviour is detected on-chain, Targeted Function Pausing allows the HydraDX Technical Committee to take swift action and temporarily pause certain or all actions relating to specific assets. This action of last resort can help mitigate the damage and allow for further investigation.

- + \ No newline at end of file diff --git a/omnipool_trading/index.html b/omnipool_trading/index.html index a64d2fdc..0276750d 100644 --- a/omnipool_trading/index.html +++ b/omnipool_trading/index.html @@ -4,13 +4,13 @@ Efficient Trading | HydraDX Docs - +

Efficient Trading

The traditional DeFi landscape is characterised by fragmented liquidity which is dispersed across several trading pools. This leads to economic inefficiencies: More hops and shallower liquidity create higher price impact and slippage. By combining all liquidity in a single trading pool, the HydraDX Omnipool enables efficient trading like no other AMM.

Traditional AMMs: Liquidity Fragmentation

The pioneer XYK AMM model marked a pivotal moment for DeFi which made decentralized and permissionless trading possible. The simplicity of XYK pools boosted the initial adoption of DeFi, however today we stand at a point where the resulting economic inefficiencies hinder the continued adoption.

Omnipool

One of the flaws of the XYK model is that trading pools are constrained to pairs of assets. Fragmented liquidity results in a higher price impact due to more hops and slippage. The route of the ETH-AAVE trade in the screenshot above provides a practical example:

  • 85% direct from ETH to AAVE (incurring 0.3% fee);
  • 15% ETH traded for UNI first then the UNI is swapped for AAVE (incurring two 0.3% swap fees).

HydraDX Omnipool: Unified Liquidity

Thanks to the cutting-edge design, liquidity in the Omnipool truly acts as one. By having all the liquidity connected through LRNA, the assets within the Omnipool have direct access to the entirety of liquidity for any other asset that is also deposited into the Omnipool. This allows for a seamless on-chain execution and enables swaps to be completed in a single transaction with no hopping required between various isolated trading pools.

Furthermore, based on internal research, the increase in the number of tokens and total value locked (TVL) within the Omnipool lead to exponential improvements in slippage reduction.

login

To illustrate with an example, imagine the TKN asset is distributed across 4 different liquidity pools with varying levels of liquidity. In the scenario that a trader wants to trade DAI for TKN, they would only have access to the direct liquidity of the $1M TKN-DAI pool. If their trade size is substantial (e.g. $100K+), the majority of the trade will likely be routed through a DAI-ETH pool followed by the TKN-ETH pool in the traditional XYK landscape.

However, with the Omnipool, that same $5mm (50% of the total $10mm TVL) of the TKN asset and $3mm of DAI would be concentrated in one pool. As such, if a trader proceeds to make the same trade in the HydraDX Omnipool, they will get the entire benefit of the $5mm of TKN and $3mm of DAI liquidity in their direct swap, materially reducing the overall price impact.

- + \ No newline at end of file diff --git a/omnipool_treasuries/index.html b/omnipool_treasuries/index.html index 418243a5..0833b1c7 100644 --- a/omnipool_treasuries/index.html +++ b/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ Hydrate Your Treasury (B2B) | HydraDX Docs - +

Hydrate Your Treasury (B2B)

The HydraDX Omnipool has an outspoken value proposition for the treasury of any project or DAO. Forget about centralized market makers and inflationary rewards for liquidity mining; the Omnipool can facilitate the creation of a market for your token in a cost-efficient manner - trustless, without hidden costs and while building up your POL from trading fees.

Thanks to its cutting-edge design, the HydraDX Omnipool supports single-sided LPing. Instead of wastefully allocating liquidity mining rewards to incentivize other users to provide liquidity, projects and DAOs can deposit a part of their treasury to the Omnipool and receive instant exposure to all other assets in an ocean of liquidity: Diversified and deep (HydraDX has $20M+ worth of POL which is gradually being deployed).

LPing in the HydraDX Omnipool is truly trustless. Leveraging Polkadot’s unique capability of cross-chain communication (XCM), the Omnipool empowers you to always remain in control of your funds: You can both provide your liquidity and manage it without relying on third parties.

Providing liquidity to the HydraDX Omnipool is not only cost-efficient - it is also profitable. Instead of having your tokens sit idle in your treasury, you can put them to work. You will earn rewards from trading fees, allowing you to build up POL over time. Soon, our upcoming TWAMM/DCA feature will allow you diversify the accumulated POL in other assets (e.g. dollar cost averaged stablecoins or DOT which you can use to bid on your next parachain slot).

Finally, the HydraDX Omnipool enjoys state of the art security. Besides rigorous audits and a generous bug bounty program, we have set up a combination of measures which work together to keep your liquidity safe. Learn more here.

- + \ No newline at end of file diff --git a/participate_in_council_elections/index.html b/participate_in_council_elections/index.html index 0d50e81d..617e505e 100644 --- a/participate_in_council_elections/index.html +++ b/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ Participate in Council Elections | HydraDX Docs - +

Participate in Council Elections

This article provides step-by-step guidance on how to participate in Council elections - voting for Council members and becoming a Council candidate.

If you are interested in how the election mechanism works, please refer to this post.

Using Polkadot/apps

Vote in Council member elections

You can see the current Council members as well as the runners-up on the Governance > Council page in Polkadot/apps.

To bring out your vote for Council members, click on Vote.

Enter the amount of tokens you are willing to lock in support of your candidates.

After that, select your candidates in order of preference by moving them from the left list to the right one. Remeber to select multiple candidates - this will help the algorithm select the optimal distribution of candidates to the Council.

To bring out your vote, click on Vote and sign the transaction.

note

Locked tokens cannot be transferred, however they can still be used for voting in referenda. Your tokens will remain locked and used for subsequent elections until you have decided to unlock them.

Apply as a Council candidate

You can submit your application for Council membership by navigating to Governance > Council in Polkadot/apps.

Click on Submit candidacy which will trigger a popup.

Select the account which is running for Council membership, click on Submit, and sign the transaction.

- + \ No newline at end of file diff --git a/participate_in_referenda/index.html b/participate_in_referenda/index.html index 8a78a741..9c63ee85 100644 --- a/participate_in_referenda/index.html +++ b/participate_in_referenda/index.html @@ -4,13 +4,13 @@ Participate in Referenda | HydraDX Docs - +

Participate in Referenda

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 or Polkadot/apps.

Before you decide to participate, we strongly encourage you to read through the knowledge article in the Learn / Democracy section. There you will find some important details on the mechanics behind referenda.

Using Subsquare

Vote in a Referendum

To see all active and past referenda, navigate to the Referenda tab on Subsquare.

For first time and previous users, click on Login (top right corner) and connect your wallet.

Click on an active referendum to see its details, the voting turnout, as well as the voting module.

To cast your vote, click on Vote and provide the following information:

  • Vote with account - select the voting account.
  • Value - this is the amount of HDX tokens you are willing to lock in support of the referendum.
  • Vote lock - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Nay (No) or Aye (Yes) and sign the transaction.

In the section Cast Your Vote, fill in the following information:

  • Amount to vote - this is the amount of HDX tokens you are willing to lock in support of the referendum
  • Conviction multiplier - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Vote yes or Vote no and sign the transaction.

Using Polkadot/apps

Vote in a Referendum

You can see all referenda which are open for voting by navigating to Governance > Democracy in Polkadot/apps.

To vote in a referendum, click on the Vote button next to it.

In the popup, fill in the following information:

  • Vote value - this is the amount of HDX tokens you are willing to lock in support of the referendum
  • Conviction multiplier - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Vote Nay (No) or Vote Aye (Yes) and sign the transaction.

Propose a Referendum

Proposing a referendum via Polkadot/apps consists of two steps - submitting a preimage, and submitting the proposal on-chain.

01 Submit preimage

To submit the preimage, visit Polkadot/apps and navigate to Governance > Democracy.

After clicking on Submit preimage, you should see the following popup:

Fill in the information in the fields show above. The most important parameters are:

  • Account from which the proposal is sent
  • Proposal area
  • Proposed action

In the example above, the proposal area is balances, and the action is forceTransfer of tokens from one account to another.

Before submitting the preimage and signing the transaction, please make sure to copy the preimage hash. You will need it for the next step.

02 Submit proposal

To submit the referendum proposal, visit Governance > Democracy in Polkadot/apps.

After clicking on Submit proposal, you should see the following popup:

Enter the preimage hash from the previous step, and the amount of tokens you are willing to deposit for the proposal. The minimum is 100,000 HDX.

After submitting the proposal on-chain and signing the transaction, your proposal should appear in the list of proposed referenda.

caution

Every voting period, the referendum proposal with the highest backing (seconding) enters the voting round. As the amount of referenda grows, there is no guarantee that your proposal will ever gain sufficient seconding to enter voting. There is no option to withdraw a referendum proposal, meaning that your funds might remain locked for a longer period of time.

Malicious referendum proposals are punished. The HydraDX Council and the Technical Committee have the right to cancel any referendum which was proposed in bad faith. As a result, the deposited tokens will be burnt.

- + \ No newline at end of file diff --git a/performance_benchmark/index.html b/performance_benchmark/index.html index 44913eb0..852fa49a 100644 --- a/performance_benchmark/index.html +++ b/performance_benchmark/index.html @@ -4,13 +4,13 @@ Performance Benchmark | HydraDX Docs - +

Performance Benchmark

You can make sure that your machine satisfies the required technical specifications by running a performance benchmark. To do so, follow the steps below:

# Fetch source of the latest stable release
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Prepare for running the benchmark
## Install Rust following https://rustup.rs
$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

## Configure Rust
$ ./scripts/init.sh
$ rustup default nightly

## Install additional libraries
$ apt install python3-pip
$ apt install clang

# Run the benchmark
$ ./scripts/check_performance.sh

After the benchmark executes you should see an output similar to the following:

         Pallet          |   Time comparison (µs)    |  diff* (µs)   |   diff* (%)    |            |   Rerun
amm | 773.00 vs 680.00 | 93.00 | 12.03 | OK |
exchange | 804.00 vs 720.00 | 84.00 | 10.44 | OK |
transaction_multi_payment| 218.00 vs 198.00 | 20.00 | 9.17 | OK |

Notes:
- in the diff fields you can see the difference between the reference benchmark time and the benchmark time of your machine
- if diff is positive for all three pallets, your machine covers the minimum requirements for running a HydraDX node
- if diff deviates by -10% or more for some of the pallets, your machine might not be suitable to run a node

You can see the difference in the performance between your machine and the minimum required setup in the column diff* (%). If all three values in this column are positive, your machine should be suitable to run a HydraDX validator node. If any of the values is below -10 %, we do not recommend running a HydraDX node.

Join us at Discord if you would like to discuss your benchmark results, our community is always happy to help.

- + \ No newline at end of file diff --git a/polkadotjs_apps_local/index.html b/polkadotjs_apps_local/index.html index dd641652..3d3b00ea 100644 --- a/polkadotjs_apps_local/index.html +++ b/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ Connect to a Local Node | HydraDX Docs - +

Connect to a Local Node

You can use the Polkadot/apps to connect to your local HydraDX node. For this purpose, you need to have access to port 9944 which is used for RPC websocket connections.

danger

If you are running the node as a validator, we highly recommend that you blacklist port 9944 for remote connections. This port could be abused by third parties to degrade the performance of your node, which may result in slashing and involuntary loss of funds. You should use port 9944 to connect to your validator node only when the node is in your local network.

Accessing your local node using Polkadot/apps

To access your node, open Polkadot/apps and click in the upper left corner to change the network.

After opening the menu, click on Development and select Local node.

Adjust the IP if necessary and click on Switch to switch to your local node.

Now you should be connected to your local node and be able to interact with it.

- + \ No newline at end of file diff --git a/polkadotjs_apps_public/index.html b/polkadotjs_apps_public/index.html index 4519bd74..95ab1c61 100644 --- a/polkadotjs_apps_public/index.html +++ b/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ Connect to a Public Node | HydraDX Docs - +

Connect to a Public Node

There are two public RPC nodes which are maintained by HydraDX and our partners. You can use these nodes for interacting with Snakenet. You can directly connect to a public node with Polkadot/apps by clicking on the link below:

Connect manually to an RPC node

To access a public RPC node manually, open the Polkadot/apps and click in the upper left corner to change the network.

Click on LIVE NETWORKS and select HydraDX.

Select one of the nodes and click Switch.

Now you should be connected to the selected public RPC node.

- + \ No newline at end of file diff --git a/ru/404.html b/ru/404.html index b0510c55..db48a1e0 100644 --- a/ru/404.html +++ b/ru/404.html @@ -4,13 +4,13 @@ Страница не найдена | HydraDX Docs - +

Страница не найдена

К сожалению, мы не смогли найти запрашиваемую вами страницу.

Пожалуйста, обратитесь к владельцу сайта, с которого вы перешли на эту ссылку, чтобы сообщить ему ссылка не работает.

- + \ No newline at end of file diff --git a/ru/archive_hydradx_crowdloan/index.html b/ru/archive_hydradx_crowdloan/index.html index 05b9bbf9..697cb8c2 100644 --- a/ru/archive_hydradx_crowdloan/index.html +++ b/ru/archive_hydradx_crowdloan/index.html @@ -4,13 +4,13 @@ HydraDX Crowdloan | HydraDX Docs - +

HydraDX Crowdloan

осторожно

This page has been archived, meaning that the information it contains may be outdated or no longer applicable.

The HydraDX crowdloan for the Polkadot parachain auctions is now live! You can support HydraDX by participating in our crowdloan campaign and pledging some amount of DOT tokens which will be locked up for the duration of the parachain slot.

In return, you will be granted HDX rewards which cover your opportunity costs. Once the parachain slot has expired, you will receive your DOT tokens back in full. The same applies to the scenario that HydraDX does not manage to win a parachain slot within the crowdloan campaign deadline stated hereunder.

Crowdloan Details

  • Visit: https://loan.hydradx.io/
  • Crowdloan start: 28 December 2021
  • Bidding on slots: #6 - #11
  • Onboarding of winning parachains: 11 March 2022
  • End of leased parachain slots: 12 January 2024
  • Crowdloan cap: 8,000,000 DOT
  • Rewards: between 280 and 12.5 HDX per contributed DOT
  • Rewards cap: max. 1,000,000,000 HDX (10% of total supply)
  • Vesting period: HDX rewards are distributed linearly. The distribution will start after HydraDX has been onboarded as a Polkadot parachain and the transition from Snakenet (our testnet) has been completed.
  • Crowdloan campaign deadline: 12 March 2022

HDX Rewards

All participants in the HydraDX crowdloan will receive HDX in exchange for their contributions. The amount of the rewards depends on our rank in the parachain auction race at the time of your contribution, as well as the total amount of DOT which have been contributed by others.

Contributions made before HydraDX is leading the race by 15% will receive the highest amount of rewards - between 280 and 125 HDX per contributed DOT.

After we have secured a comfortable lead, the rewards will start dropping linearly. They will be at their lowest level once HydraDX has a lead of 25% or more. Contributions made during the time that we are leading by more than 25% will receive between 28 and 12.5 HDX per contributed DOT.

The rewards system is designed to offset the opportunity costs of locking your DOT for the duration of the parachain lease, as opposed to staking it. Contributions made before we have gained a 15% lead will get their full opportunity costs reimbursed. The price of HDX used for the calculation is $ 0.026. This number is based on the closing HDX LBP price of $ 0.08 (February 2021), after taking into account the upcoming tripling of all balances which were built up during our testnet.

- + \ No newline at end of file diff --git a/ru/assets/js/d631f7a2.c720b25a.js b/ru/assets/js/d631f7a2.00c55808.js similarity index 70% rename from ru/assets/js/d631f7a2.c720b25a.js rename to ru/assets/js/d631f7a2.00c55808.js index 484b96d6..f29a9efe 100644 --- a/ru/assets/js/d631f7a2.c720b25a.js +++ b/ru/assets/js/d631f7a2.00c55808.js @@ -1 +1 @@ -"use strict";(self.webpackChunkhydra_dx_docs=self.webpackChunkhydra_dx_docs||[]).push([[942],{3905:function(e,t,n){n.d(t,{Zo:function(){return l},kt:function(){return m}});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var d=r.createContext({}),c=function(e){var t=r.useContext(d),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},l=function(e){var t=c(e.components);return r.createElement(d.Provider,{value:t},e.children)},p="mdxType",u={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},f=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,d=e.parentName,l=s(e,["components","mdxType","originalType","parentName"]),p=c(n),f=a,m=p["".concat(d,".").concat(f)]||p[f]||u[f]||o;return n?r.createElement(m,i(i({ref:t},l),{},{components:n})):r.createElement(m,i({ref:t},l))}));function m(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=f;var s={};for(var d in t)hasOwnProperty.call(t,d)&&(s[d]=t[d]);s.originalType=e,s[p]="string"==typeof e?e:a,i[1]=s;for(var c=2;c=r)&&Object.keys(d.O).every((function(e){return d.O[e](c[o])}))?c.splice(o--,1):(a=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[c,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},c=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var f={};t=t||[null,c({}),c([]),c(c)];for(var a=2&n&&e;"object"==typeof a&&!~t.indexOf(a);a=c(a))Object.getOwnPropertyNames(a).forEach((function(t){f[t]=function(){return e[t]}}));return f.default=function(){return e},d.d(r,f),r},d.d=function(e,t){for(var c in t)d.o(t,c)&&!d.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:t[c]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,c){return d.f[c](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",306:"62b94dd6",548:"0b7119cc",574:"9deda591",741:"ba655ed0",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1518:"66ffdd67",1800:"b8aca70d",2250:"07178ad8",2332:"9fd70990",2989:"7921dc2a",3258:"b99fcc0c",4020:"669853c7",4101:"1d2d6146",4621:"05550a0c",5058:"bb071bc7",5183:"ff2c1298",5349:"5d8f0860",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5553:"80a7be49",5888:"2cad9136",6295:"d2692880",6428:"8cc7a8b7",6630:"bccd5aec",6714:"b29c726d",6880:"8ab1c036",7615:"4756a152",7687:"e65d0e32",7918:"17896441",7939:"dfd1ff83",8056:"c218de4c",8323:"70254ef3",8462:"dab19d87",8653:"b81d6f32",8696:"a53b80d1",8741:"4ccf5e49",8781:"d4dad5f6",9219:"144c5974",9366:"c116d048",9502:"d62e8a9b",9514:"1be78505",9650:"497f4115",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"733f63c9",306:"bc7f0ff1",548:"250be516",574:"dc355494",741:"10a11346",942:"c720b25a",994:"3617fed4",1019:"9c4c1126",1518:"d78a1628",1800:"fc82945b",2250:"fa9bc1b3",2332:"3c8ebb9c",2989:"77cb53d4",3258:"2dd288c9",4020:"a2bc44e2",4101:"9b376595",4621:"a243d228",4972:"79f8b409",5058:"2bfe8d14",5183:"88e4ba34",5349:"8a0124fa",5355:"261b2187",5445:"f041fef6",5488:"715843a0",5536:"626405e7",5553:"4ba2b3c2",5888:"aa081633",6295:"f1add0ca",6428:"1f14d2a4",6630:"c61d64fd",6714:"abe234a2",6880:"d6899f9d",7615:"b4893709",7687:"e8b7a12a",7918:"bff4c59e",7939:"0c59c730",8056:"db011a2f",8323:"70b67a91",8462:"c31eec35",8653:"f9703ec7",8696:"f70cede6",8741:"fbdef1a1",8781:"770f4bac",9219:"dd4d386e",9366:"e7c9f1ee",9502:"df362274",9514:"4cb072e6",9650:"05984ade",9726:"9b330fb9"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,c,f){if(n[e])n[e].push(t);else{var a,o;if(void 0!==c)for(var u=document.getElementsByTagName("script"),i=0;i=r)&&Object.keys(d.O).every((function(e){return d.O[e](c[o])}))?c.splice(o--,1):(a=!1,r0&&e[i-1][2]>r;i--)e[i]=e[i-1];e[i]=[c,n,r]},d.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return d.d(t,{a:t}),t},c=Object.getPrototypeOf?function(e){return Object.getPrototypeOf(e)}:function(e){return e.__proto__},d.t=function(e,n){if(1&n&&(e=this(e)),8&n)return e;if("object"==typeof e&&e){if(4&n&&e.__esModule)return e;if(16&n&&"function"==typeof e.then)return e}var r=Object.create(null);d.r(r);var f={};t=t||[null,c({}),c([]),c(c)];for(var a=2&n&&e;"object"==typeof a&&!~t.indexOf(a);a=c(a))Object.getOwnPropertyNames(a).forEach((function(t){f[t]=function(){return e[t]}}));return f.default=function(){return e},d.d(r,f),r},d.d=function(e,t){for(var c in t)d.o(t,c)&&!d.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:t[c]})},d.f={},d.e=function(e){return Promise.all(Object.keys(d.f).reduce((function(t,c){return d.f[c](e,t),t}),[]))},d.u=function(e){return"assets/js/"+({17:"0f5b2c31",53:"935f2afb",306:"62b94dd6",548:"0b7119cc",574:"9deda591",741:"ba655ed0",942:"d631f7a2",994:"5c6fed25",1019:"437311ef",1518:"66ffdd67",1800:"b8aca70d",2250:"07178ad8",2332:"9fd70990",2989:"7921dc2a",3258:"b99fcc0c",4020:"669853c7",4101:"1d2d6146",4621:"05550a0c",5058:"bb071bc7",5183:"ff2c1298",5349:"5d8f0860",5355:"7c015a33",5445:"30ccafc3",5488:"3c1194d0",5536:"5ae84af0",5553:"80a7be49",5888:"2cad9136",6295:"d2692880",6428:"8cc7a8b7",6630:"bccd5aec",6714:"b29c726d",6880:"8ab1c036",7615:"4756a152",7687:"e65d0e32",7918:"17896441",7939:"dfd1ff83",8056:"c218de4c",8323:"70254ef3",8462:"dab19d87",8653:"b81d6f32",8696:"a53b80d1",8741:"4ccf5e49",8781:"d4dad5f6",9219:"144c5974",9366:"c116d048",9502:"d62e8a9b",9514:"1be78505",9650:"497f4115",9726:"18ff1f2d"}[e]||e)+"."+{17:"308ae345",53:"733f63c9",306:"bc7f0ff1",548:"250be516",574:"dc355494",741:"10a11346",942:"00c55808",994:"3617fed4",1019:"9c4c1126",1518:"d78a1628",1800:"fc82945b",2250:"fa9bc1b3",2332:"3c8ebb9c",2989:"77cb53d4",3258:"2dd288c9",4020:"a2bc44e2",4101:"9b376595",4621:"a243d228",4972:"79f8b409",5058:"2bfe8d14",5183:"88e4ba34",5349:"8a0124fa",5355:"261b2187",5445:"f041fef6",5488:"715843a0",5536:"626405e7",5553:"4ba2b3c2",5888:"aa081633",6295:"f1add0ca",6428:"1f14d2a4",6630:"c61d64fd",6714:"abe234a2",6880:"d6899f9d",7615:"b4893709",7687:"e8b7a12a",7918:"bff4c59e",7939:"0c59c730",8056:"db011a2f",8323:"70b67a91",8462:"c31eec35",8653:"f9703ec7",8696:"f70cede6",8741:"fbdef1a1",8781:"770f4bac",9219:"dd4d386e",9366:"e7c9f1ee",9502:"df362274",9514:"4cb072e6",9650:"05984ade",9726:"9b330fb9"}[e]+".js"},d.miniCssF=function(e){},d.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),d.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n={},r="hydra-dx-docs:",d.l=function(e,t,c,f){if(n[e])n[e].push(t);else{var a,o;if(void 0!==c)for(var u=document.getElementsByTagName("script"),i=0;i Bonds | HydraDX Docs - +
-

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info on the origins of bonds, as well as the process of a bonds campaign.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

- +

Bonds

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

All HDX bonds have a maturity date, which marks the moment when the bond can be swapped against the underlying asset (HDX). The HydraDX Protocol can decide the manner in which bonds are sold: For example, it can host a dynamically priced LBP event, or simply place an OTC order against a fixed price. Once acquired, bonds are transferrable and tradeable on the secondary market (e.g. OTC), also before they have reached maturity.

On this page you will find more info about bonds, including the process of a bonds campaign. For step-by-step guidance on how to participate in a bonds LBP, please visit this guide.

History of Bonds

The concept of bonds was first pioneered by OlympusDAO in 2021 as a tool which would help grow its POL. In the case of OlympusDAO, the Protocol was heavily relying on unsustainable yields as an incentivisation strategy for attracting liquidity - a strategy which ultimately resulted in an inefficient use of funds outside of bull markets.

The Process of a Bonds Campaign

The first step of a Bonds campaign is the issuance of the bonds by the Protocol. Any member of the HydraDX Community can initiate a governance discussion and a referendum to issue a given amount of bonds with a predefined maturity date, in order to obtain a given asset as POL.

Once bonds are issued, the HydraDX Governance must decide on the method of trade. One option is to host a dedicated LBP event, which limited in time and allows for dynamic pricing thanks to the interplay between time-based weights shifting and demand (more info in our LBP docs). Another option is for the Protocol to place an OTC order against a predefined price per bond.

metadata

After a Bonds Campaign

All bonds have a maturity date. Once matured, the bonds can be swapped against the underlying asset (HDX) in a 1:1 ratio. In the meantime, the bonds are transferrable which means that they can be traded between users (e.g. by placing an OTC order).

+ \ No newline at end of file diff --git a/ru/build_dev_chain/index.html b/ru/build_dev_chain/index.html index dfe5f5ea..c6755755 100644 --- a/ru/build_dev_chain/index.html +++ b/ru/build_dev_chain/index.html @@ -4,14 +4,14 @@ Создание цепочки разработки | HydraDX Docs - +

Создание цепочки разработки

В этом разделе вы познакомитесь с процессом настройки локального экземпляра цепочки HydraDX для разработки.

01 Установить зависимостей

Чтобы подготовить локальный экземпляр цепочки HydraDX для разработки, ваш сервер должен покрыть все зависимости для запуска цепочки субстратов. Вам нужно будет установить среду разработчика Rust и убедиться, что она правильно настроена для компиляции кода среды выполнения Substrate для цели WebAssembly (Wasm).

Вы можете установить и настроить все зависимости вручную, следуя Руководству по субстратам, или вы можете позволить этому скрипту сделать всю работу за вас:

$ curl https://getsubstrate.io -sSf | bash -s -- --fast
$ source ~/.cargo/env

02 Сборка

Соберите Wasm и родную среду выполнения:

# Получить исходный код последней стабильной версии
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable

# Сборка бинарных файлов
$ cd HydraDX-node/
$ cargo build --release

Вы должны найти результат сборки в ./target/release/hydra-dx.

03 Запуск

Перед запуском сборки вы можете очистить все существующие цепочки разработки на вашем компьютере (вам нужно будет часто делать это в процессе разработки):

$ ./target/release/hydra-dx purge-chain --dev

Запустите вашу сборку, используя одну из следующих команд:

$ ./target/release/hydra-dx --dev

# Запуск с подробным ведением журнала
$ RUST_LOG=debug RUST_BACKTRACE=1 ./target/release/hydra-dx -lruntime=debug --dev

04 Подключитесь к экземпляру локальной сети

Вы можете подключиться к своей ноде разработки HydraDX, используя Polkadot/apps и изменив сеть на Development. Вы также можете использовать эту ссылку: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/explorer

connect to node
- + \ No newline at end of file diff --git a/ru/claim/index.html b/ru/claim/index.html index 621f4e2e..52dc2ccd 100644 --- a/ru/claim/index.html +++ b/ru/claim/index.html @@ -4,13 +4,13 @@ Получение ваших HDX | HydraDX Docs - +

Получение ваших HDX

Вы можете запросить свои токены HDX с помощью токенов xHDX (ERC-20), которые вы получили во время аукциона на Balancer LBP

Предварительные требования

Есть два предварительных условия для подачи заявки на HDX. Во-первых, вам необходимо установить расширение для браузера, которое будет использоваться для создания вашего кошелька HDX. Во-вторых, вам нужен доступ к вашим токенам xHDX, которые должны храниться в кошельке, поддерживающем подпись сообщений, относящихся к токенам ERC-20 (например, Metamask).

Если ваши токены xHDX хранятся в кошельке Coinbase или Trust Wallet, вам нужно будет использовать один из следующих обходных путей для получения своих токенов HDX, поскольку эти кошельки не поддерживают подписание сообщений:

  • Metamask: вы можете использовать расширение для браузера Metamask и импортировать свой кошелек, используя seed-фразу восстановления.
  • MEW (MyEtherWallet): вы также можете использовать MEW, импортировав seed-фразу восстановления (Мнемоническую Фразу) или используя параметр подключения WalletLink. Оба варианта доступны на странице доступа к кошельку MEW. Если вы используете кошелек Coinbase, вы можете использовать WalletLink, который вы можете найти в настройках кошелька Coinbase.

Процесс запроса токенов

Убедившись, что вы выполнили предварительные условия, описанные выше, вы можете перейти в приложение HydraDX Claim и продолжить процесс запроса.

Во время процесса заявки вы будете использовать свои токены xHDX (ERC-20), чтобы потребовать свою долю токенов HDX.

00 Авторизация

Приложение HydraDX Claim запросит авторизацию у расширения браузера Polkadot.js.

осторожно

Убедитесь, что вы не являетесь жертвой фишинг-атаки, и обратите внимание на всплывающее окно авторизации: приложение должно идентифицировать себя как CLAIM.HYDRADX.IO, а запрос должен исходить с https://claim.hydradx.io

authorize

После авторизации вам будет предложено обновить метаданные для расширения polkadot.js. Это означает, что polkadot.js сможет создавать специальные адреса HydraDX, которые необходимы для завершения процесса запроса токенов в пользовательском интерфейсе.

authorize

01 Выбор вашего адреса ETH

На первом этапе процесса запроса вам будет предложено выбрать учетную запись, в которой хранятся ваши токены xHDX. Это можно сделать, подключившись к вашему кошельку с токенами ERC-20 (например, Metamask), или введя свой адрес ETH вручную в поле ввода (в этом случае вам нужно будет подписать сообщение вручную позже).

После ввода адреса ETH вы должны увидеть остаток токенов HDX, которые вы можете запросить, включая возмещение платы за газ, потраченной на получение xHDX на балансировщике.

примечание

Вы не имеете права на возврат газа, если вы получили свой xHDX в другом месте, кроме официального пула балансировщика (например, Uniswap), или если вы переместили свои токены из исходного кошелька для покупки.

authorize

02 Создание и выбор адреса HDX

На втором этапе вам будет предложено выбрать ваш адрес HDX.

Чтобы создать новый адрес HDX, откройте расширение браузера Polkadot.js и щелкните значок +, чтобы создать новую учетную запись. На первом этапе создания учетной записи вы увидите мнемоническую фразу из 12 слов, которую можно использовать для восстановления вашей учетной записи. После сохранения исходной фразы в надежном месте нажмите «Следующий шаг». Здесь вы должны изменить Network, выбрав опцию HydraDX Snakenet. Введите имя и пароль для своей учетной записи и завершите создание учетной записи.

authorize
осторожно

Никогда никому не передавайте свою seed-фразу. Сделайте резервную копию и храните в надежном месте. Это единственный способ восстановить свою учетную запись, и в случае ее потери или утечки ваши средства будут скомпрометированы. Обратите внимание, что вам нужно хранить этот кошелек до запуска основной сети, поскольку балансы будут заблокированы, и если вы потеряете доступ к кошельку, вы также потеряете свой HDX. Пожалуйста, сохраните это в безопасности.

После создания учетной записи HDX вы сможете выбрать ее в приложении HydraDX Claim. После этого приложение должно предоставить вам обзор адресов ETH и HDX, используемых для процесса заявки. Нажмите «Далее», чтобы подписать сообщение.

authorize

03 Подписание

На третьем этапе процесса запроса с использованием приложения HydraDX Claim вам будет предоставлена возможность подписать сообщение об использовании ваших токенов xHDX для запроса HDX.

примечание

Обратите внимание, что на этом этапе вы увидите публичный ключ вашего адреса HDX, а не адрес в его удобочитаемой форме, как он был отображен на предыдущем шаге и в расширении браузера Polkadot.js (подробнее см. ss58 docs). Если вы выполнили все шаги, описанные выше, беспокоиться не о чем, и можно безопасно приступить к подписанию сообщения. Мы также проверим, что учетная запись HDX, которую вы используете для подписания транзакции запроса токенов на последнем этапе, соответствует учетной записи, которая получает запрашиваемые HDX.

В зависимости от варианта, который вы выбрали на первом шаге, здесь вам будет представлен один из двух вариантов.

  • Если вы используете Metamask, после нажатия кнопки Sign Metamask предложит вам подписать сообщение. Следуйте инструкциям в Metamask.

  • Если вы ввели свой адрес ETH вручную, вам нужно будет подписать сообщение через внешний кошелек, в котором хранятся закрытые ключи ваших токенов xHDX. После того, как вы подписали сообщение, скопируйте подпись (начиная с 0x) в соответствующее поле в приложении HydraDX Claim.

authorize

04 Запрос токенов

После подписания сообщения кошельком с вашими токенами xHDX должно открыться расширение Polkadot.js, и вам будет предложено подписать транзакцию для запроса токенов HDX на вашу учетную запись. Введите пароль своей учетной записи HDX и нажмите Sign the transaction.

authorize

Вы завершили процесс подачи заявки и официально стали владельцем HDX!

Вы можете проверить свой баланс с помощью Polkadot/apps, подключившись к сети HydraDX: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/accounts

- + \ No newline at end of file diff --git a/ru/collator_setup/index.html b/ru/collator_setup/index.html index f52460c5..fb40ba4e 100644 --- a/ru/collator_setup/index.html +++ b/ru/collator_setup/index.html @@ -4,13 +4,13 @@ Set up a Collator Node | HydraDX Docs - +

Set up a Collator Node

This is a step-by-step how-to so you can get your HydraDX collator up and running. In this guide, we use Ubuntu 20.04 LTS.

Required technical specifications

The following technical specifications are required as a minimum for running a HydraDX collator node:

  • OS: Ubuntu 20.04
  • CPU: Intel Core i7-7700K @ 4.5Ghz (or equivalent single core performance)
  • Memory: 64GB RAM
  • Storage: NVMe SSD with a capacity of at least 200GB (the data footprint will grow over time)
примечание

These are the minimum technical requirements which have been verified by the team. Want to make sure that your machine has sufficient resources to run a node? Run a performance benchmark to find out.

Create a technical hydra user and add it to Sudoers

sudo adduser hydra
sudo usermod -aG sudo hydra
su - hydra

Download and configure the hydradx binary

Pick a 12.x release, we are using v12.1.0 from our assets repository:

wget https://github.com/galacticcouncil/HydraDX-node/releases/download/v12.1.0/hydradx
sudo mv hydradx /usr/local/bin
sudo chmod +x /usr/local/bin/hydradx
sudo chown hydra:hydra /usr/local/bin/hydradx

Command to run your collator

Best is to run your collator as a service using systemctl. To do so, create a file, namely hydradx-collator.service under /etc/systemd/system/hydradx-collator.service:

sudo vim /etc/systemd/system/hydradx-collator.service

Then paste the following:

[Unit]
Description=hydradx validator
[Service]
Type=exec
User=hydra
ExecStart=/usr/local/bin/hydradx \
--name YOUR_COLLATOR_NAME \
--prometheus-external \
--base-path /var/lib/hydradx \
--collator \
-- \
--execution wasm \
--telemetry-url "wss://telemetry.hydradx.io:9000/submit/ 0" \
--base-path /var/lib/hydradx

Restart=always
RestartSec=120
[Install]
WantedBy=multi-user.target

Before starting your node, let's create the base-path folder and give it the necessary permissions and ownership:

mkdir /var/lib/hydradx
chown hydra:hydra /var/lib/hydradx
предупреждение

Make sure you have enough volume for your base-path by using df -h command.

Note that --prometheus-external is optional, but we highly recommend it so you can be able to export prometheus metrics and monitor your node's health through Grafana. For more details about monitoring, please visit this link.

If you need to monitor both the parachain and relaychain metrics, --prometheus-externaloption should be setup in both parts. You also need to set a separate port for the relaychain part as follows: --prometheus-port YOUR_CUSTOM_PORT_NUMBER

Depending on your setup, you might also want to override certain parameters like the websocket, rpc or your node p2p port. Please use hydradx --help for more information about the available options.

After saving your file, run the following commands to start your node:

sudo systemctl enable hydradx-collator
sudo systemctl start hydradx-collator.service

Your node should now be up and running. Make sure your hydra user has the necessary permissions to access your base-path and key file.

If you need to troubleshoot your running service, you can use the journalctl command with the -f option for tailing:

journalctl -fu hydradx-collator

Generate your session key

In order to generate keys for your node, run the following command:

curl -H "Content-Type: application/json" -d '{"id":1, "jsonrpc":"2.0", "method": "author_rotateKeys", "params":[]}' http://localhost:9933

Once done, you will have an output similar to:

{"jsonrpc":"2.0","result":"0x9257c7a88f94f858a6f477743b4180f0c9a0630a1cea85c3f47dc6ca78e503767089bebe02b18765232ecd67b35a7fb18fc3027613840f27aca5a5cc300775391cf298af0f0e0342d0d0d873b1ec703009c6816a471c64b5394267c6fc583c31884ac83d9fed55d5379bbe1579601872ccc577ad044dd449848da1f830dd3e45","id":1}

Set your session key

To associate the generated session keys with your Controller account, navigate to the following menu item in the Polkadot/apps on the Polkadot parachain HydraDX: Developer > Extrinsics.

Fill in the fields:

  • using selected account: select your Controller account;
  • submit the following extrinsic: select session on the left side and setKeys on the right;
  • keys: enter your session key you just generated;
  • proof: 0;

What's next?

Make sure that your node is fully synced. Once this is done, let us know in the dedicated Discord channel (only if you have been preselected as a collator).

- + \ No newline at end of file diff --git a/ru/contributing/index.html b/ru/contributing/index.html index fd1c533b..74eabfa7 100644 --- a/ru/contributing/index.html +++ b/ru/contributing/index.html @@ -4,13 +4,13 @@ Writing Docs | HydraDX Docs - +

Writing Docs

You can write content using GitHub-flavored Markdown syntax.

Markdown Syntax

To serve as an example page when styling markdown based Docusaurus sites.

Headers

H1 - Create the best documentation

H2 - Create the best documentation

H3 - Create the best documentation

H4 - Create the best documentation

H5 - Create the best documentation
H6 - Create the best documentation

Emphasis

Emphasis, aka italics, with asterisks or underscores.

Strong emphasis, aka bold, with asterisks or underscores.

Combined emphasis with asterisks and underscores.

Strikethrough uses two tildes. Scratch this.


Lists

  1. First ordered list item
  2. Another item
    • Unordered sub-list.
  3. Actual numbers don't matter, just that it's a number
    1. Ordered sub-list
  4. And another item.
  • Unordered list can use asterisks
  • Or minuses
  • Or pluses

I'm an inline-style link

I'm an inline-style link with title

I'm a reference-style link

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com/ or http://www.example.com/ and sometimes example.com (but not on GitHub, for example).

Some text to show that the reference links can follow later.


Images

Here's our logo (hover to see the title text):

Inline-style: alt text

Reference-style: alt text

Images from any folder can be used by providing path to file. Path should be relative to markdown file.

![img]{useBaseUrl('/static/img/logo.svg')}


Code

var s = 'JavaScript syntax highlighting';
alert(s);
s = "Python syntax highlighting"
print(s)
No language indicated, so no syntax highlighting.
But let's throw in a <b>tag</b>.
function highlightMe() {
console.log('This line can be highlighted!');
}

Tables

Colons can be used to align columns.

TablesAreCool
col 3 isright-aligned$1600
col 2 iscentered$12
zebra stripesare neat$1

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.

MarkdownLessPretty
Stillrendersnicely
123

Blockquotes

Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.

Quote break.

This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can put Markdown into a blockquote.


Inline HTML

Definition list
Is something people use sometimes.
Markdown in HTML
Does *not* work **very** well. Use HTML tags.

Line Breaks

Here's a line for us to start with.

This line is separated from the one above by two newlines, so it will be a separate paragraph.

This line is also a separate paragraph, but... This line is only separated by a single newline, so it's a separate line in the same paragraph.


Admonitions

примечание

This is a note

подсказка

This is a tip

к сведению

This is important

предупреждение

This is a caution

осторожно

This is a warning

- + \ No newline at end of file diff --git a/ru/create_account/index.html b/ru/create_account/index.html index edb51584..a22c49f6 100644 --- a/ru/create_account/index.html +++ b/ru/create_account/index.html @@ -4,13 +4,13 @@ Create a new HDX Account | HydraDX Docs - +

Create a new HDX Account

The process of creating a new HDX Account consists of three simple steps.

01 Install Polkadot.js

In order to create and manage your HDX wallet, you need to install the Polkadot.js browser extension.

02 Upgrade metadata

After installing the Polkadot.js browser extension, you should make sure that it has been updated with the latest chain metadata. For this purpose, you can visit the following link and update your metadata, if prompted:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/settings/metadata

03 Create your HDX Account

To create a new HDX address, open the Polkadot.js browser extension and click on + > Create new account.

You will be displayed a 12-word mnemonic phrase which can be used to recover your account. Make sure that you backup your seed phrase in a secure location. Click on Next step and fill in the following information:

  • Network: Please select HydraDX Snakenet
  • Descriptive name of the account
  • Password

Your account will be created after clicking Add the account with the generated seed.

create-account
осторожно

Make sure to backup your recovery seed phrase by storing it in a secure location. Never share your seed phrase with anybody. The seed phrase can be used to gain access to your account. If you lose it or leak it, you might also lose all the HDX stored in your account. Please note that all HDX balances are locked until mainnet starts, so you need to make sure that you keep the account holding your tokens secure until then.

- + \ No newline at end of file diff --git a/ru/democracy_council/index.html b/ru/democracy_council/index.html index 2e242bf6..f55b1845 100644 --- a/ru/democracy_council/index.html +++ b/ru/democracy_council/index.html @@ -4,13 +4,13 @@ HydraDX Council | HydraDX Docs - +

HydraDX Council

The HydraDX Council is an on-chain entity which plays a key role in the governance of the protocol. This article provides information on the composition of the Council, its main tasks, and the election of Council members.

For step-by-step guidance on how to participate in Council elections, please refer to this guide.

Composition

The HydraDX Council currently consists of 13 members.

A minority share of 6 seats is reserved for the founding team and the investors (4 founders + 2 investors).

The remaining 7 seats are elected by the wider community of HDX holders.

Tasks and Responsibilities

The tasks of the HydraDX Council cover a wide range of day-to-day governance activities. To begin with, the Council controls the Treasury and approves or rejects Treasury proposals.

The HydraDX Council also plays a role in the referendum mechanism. The Council can initiate a referendum, provided that at least 60% of the members support this (super-majority) and no member exercises a veto. In the case of a veto, the proposal can be resubmitted after the cool-down period has lapsed. The vetoing member cannot veto the same proposal twice.

Furthermore, any proposed referendum can be cancelled with a 2/3 super-majority of the Council votes. This can be used as a last-resort measure to stop malicious proposals or changes which could introduce bugs in the code.

Finally, the HydraDX Council is responsible for electing the Technical Committee.

Elections

Any holder of HDX tokens can apply for one of the 7 non-permanent sets of the HydraDX Council as a candidate.

The Council elections take place every 7 days, at which point an algorithm fills the 7 non-permanent Council seats for the duration of the following 7 days. The democracy module uses the same Phragmen algorithm which is used to elect the active set of validators on the Polkadot Relay Chain.

All community members can vote in the Council elections by locking a certain amount of HDX tokens of their choice. Locked tokens are not available for transfer and will be used in the follow-up elections (until cancelled). Voters can and should select more than one candidate in order of preference. The election algorithm then distributes all votes to determine the optimal allocation of the available Council seats to the candidates with the highest community backing.

- + \ No newline at end of file diff --git a/ru/democracy_intro/index.html b/ru/democracy_intro/index.html index 3faaffa2..f02224c7 100644 --- a/ru/democracy_intro/index.html +++ b/ru/democracy_intro/index.html @@ -4,13 +4,13 @@ Introduction | HydraDX Docs - +

Introduction

HydraDX is in the process of fully decentralizing its governance. All decisions which affect the protocol are adopted following a democratic process which is supported by the Substrate democracy module. The central mechanism for establishing consensus among the stakeholders is the referendum.

This section contains a series of knowledge articles which should provide you with a better understanding of the mechanisms behind the governance of HydraDX. You will find more information on how referenda work, as well as on the two central groups of governance actors: the HydraDX Council and the Technical Committee.

If you are looking for practical guidance on how to participate in the governance of HydraDX, please refer to the step-by-step guides on participating in referenda and participating in Council elections.

Democracy parameters

The list below contains the most important parameters which influence the governance mechanism on HydraDX. Please note that these may change over time.

  • Minimum HDX deposit for initiating a referendum: 10 000 HDX
  • Referendum enactment period: 6 days
  • Referendum voting period: 3 days
  • Emergency referendum voting period: 3 hours
  • Cooloff period after a referendum has been rejected: 7 days
  • Maximum pending referendum proposals: 100
- + \ No newline at end of file diff --git a/ru/democracy_referenda/index.html b/ru/democracy_referenda/index.html index a24b114a..93aa897e 100644 --- a/ru/democracy_referenda/index.html +++ b/ru/democracy_referenda/index.html @@ -4,13 +4,13 @@ Referenda | HydraDX Docs - +

Referenda

Referenda allow stakeholders to put a proposal to a weighted, stake-based vote by the wider community. The object of the referendum is some suggested action which affects the protocol - for example, a Treasury payout, or even a change in the runtime code.

Generally speaking, only one referendum is brought to a vote at a time. Other pending referendum proposals are put in a queue. There are separate queues for publicly submitted proposals and for Council proposals. Every 3 days, the referendum mechanism picks the top proposal with the highest amount of support, alternating between the two queues. After a referendum has been voted upon and accepted, there is a so-called enactment delay period of 3 days which needs to pass before the decision is put into effect. An exception to these rules applies for emergency proposals by the Technical Committee which deal with major protocol problems and need to be fast-tracked.

Initiating a Referendum

There are multiple ways to initiate a referendum which are described in greater detail below. The way the referendum was initiated is decisive for the applicable voting mode.

Public Referendum

Any holder of HDX tokens can propose a referendum by depositing the minimum required amount of HDX tokens and submitting the proposal on-chain. Other community members can support (second) the proposal for a referendum by locking up an equal amount of tokens. At the beginning of every voting cycle, the referendum proposal with the highest amount of seconding (total deposited tokens) is advanced to a vote by the community.

The voting mode which applies to public referenda is Positive Turnout Bias.

примечание

All HDX tokens which are deposited to propose or second a referendum are locked up for the whole period until the referendum has entered the voting cycle. It is important to remember that there is no guarantee that any given proposal will ever receive sufficient backing to move into the voting round, meaning that your funds might remain locked for an indefinite period.

Council Referendum

The HydraDX Council has the powers to propose a referendum for a community vote. If it does so unanimously, the applicable voting mode for the referendum is Negative Turnout Bias. If the referendum is proposed with a simple majority of the Council votes, then the voting mode for accepting the proposals by the community is Simple Majority.

Emergency Proposals by the Technical Committee

The Technical Committee can submit emergency proposals which deal with (critical) bug fixes or the quick adoption of battle-tested functionality. Emergency proposals skip the waiting queue and enter the voting round directly. The community can vote on emergency proposals in parallel to any regular proposal which has entered the voting round. Furthermore, emergency proposals have a shorter voting period to ensure that they can be fast-tracked.

Canceling a Referendum

Once a referendum has been proposed, it cannot be revoked until it has entered the voting round. An exception to this rule is made for proposals which are deemed detrimental to the protocol (e.g. code changes introducing a bug). In this limited case, the referendum proposal can be cancelled by the HydraDX Council (with a 60% super-majority) or the Technical Committee (unanimously). All tokens wich were locked by supporters seconding the proposal are burned.

Voting in a Referendum

HydraDX referenda have a launch period of 3 days. At the beginning of every new period, the proposal with the highest amount of seconding is taken from the waiting queue and put into a voting round. Every voting round has a duration of 3 days. During this period, community members can vote on the referendum using a weighted, stake-base mechanism. They do so by locking up a certain amount of HDX tokens for a given timeframe.

примечание

Locked HDX tokens cannot be transferred for the duration of the chosen lock period. However, they can still be used for voting.

Votes Weighing

There are two factors which determine the weight of each vote in a referendum. The first factor is the amount of HDX tokens which the voter locks up in support of the vote. The second factor is the so-called conviction multiplier which reflects the duration for which the voter is willing to lock up the tokens.

vote_weight = tokens * conviction_multiplier

The table below contains an overview of the various Conviction Multipliers and the amount of days the tokens will be locked up for. It is possible to bring out a vote without locking your HDX, however its weight would be only a fraction (conviction multiplier of 0.1x). As shown in the table below, locking the tokens for the maximum of 192d would raise the conviction multiplier to 6x.

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d
An example:

Alice votes with 5000 HDX and 0.1x Conviction Multiplier.
Bob votes with 100 HDX and 6x Conviction Multiplier.

Weight Alice: 500
Weight Bob: 600

Token lock Alice: 0 days
Token lock Bob: 192 days

Voting Modes

Another important aspect of the democracy module are the different voting modes which apply. The threshold of votes needed for approving or rejecting a referendum can vary depending on how the referendum was initiated and on the turnout of the vote. The turnout is calculated based on the total amount of HDX tokens which were used to vote in the referendum (conviction multipliers excluded). Whether the turnout was low or not is determined by the relationship between the turnout and the elactorate (i.e. the total amount of HDX tokens eligible to vote).

Positive Turnout Bias

This is the default voting mode when a referendum is proposed by the Community. At lower turnouts, a qualified super-majority of yes votes is required in order to approve the referendum. As the turnout grows, the threshold decreases towards a simple majority.

Negative Turnout Bias

This voting mode applies to referenda which have been proposed by the Council unanimously. Such proposals require a qualified super-majority of no votes to be rejected at low turnouts. As the turnout grows, the threshold for rejecting the referendum decreases towards a simple majority.

Simple Majority

Referenda which were initiated by the Council with majority agreement (i.e. not unanimously) can be accepted by the community with a simple majority of the votes (50% + 1).

- + \ No newline at end of file diff --git a/ru/democracy_technical_committee/index.html b/ru/democracy_technical_committee/index.html index dcc1bd37..9abbd293 100644 --- a/ru/democracy_technical_committee/index.html +++ b/ru/democracy_technical_committee/index.html @@ -4,13 +4,13 @@ Technical Committee | HydraDX Docs - +

Technical Committee

The Technical Committee is a group of experienced core developers which is appointed directly by the HydraDX Council. Its main task is to safeguard the technical stability of the protocol.

The Technical Committee has the right to produce emergency referenda which are fast-tracked and voted in parallel with any other active referenda. This allows the Committee to act quickly and deliver critical (code) changes.

Another important power of the Technical Committee is the ability to cancel referendum proposals which are deemed to be detrimental to the protocol. In order to cancel a referendum proposal, the Committee must agree unanimously.

- + \ No newline at end of file diff --git a/ru/dev_intro/index.html b/ru/dev_intro/index.html index 7d4e6b35..61de5c93 100644 --- a/ru/dev_intro/index.html +++ b/ru/dev_intro/index.html @@ -4,14 +4,14 @@ Intro to Development | HydraDX Docs - +

Intro to Development

The purpose of the Build section of the HydraDX documentation is to share technical knowledge with the community and to empower individual contributions. HydraDX is a community-driven project which invests heavily in incentivizing community involvement, and we especially appreciate technical contributions!

All technical contributions which are aligned with the goals of HydraDX are eligible for generous rewards which are paid out as Treasury tips in HDX. You can find more information about our reward scheme under the following links:

How to Start

HydraDX is powered by Substrate which is a cutting-edge blockchain framework built on Rust. Knowledge of Rust is therefore an important prerequisite for chain development. If you want to learn Rust, a good place to start is the "Rust Book".

A further requirement is basic knowledge of the Substrate framework. If you want to get up to speed quickly, we highly recommend you to subscribe to the Acala Runtime Developer Academy.

How to Continue

Check out the docs under Build. Ask questions on Discord. Fork us. Open a PR with your contribution.

https://github.com/galacticcouncil/HydraDX-node
https://github.com/galacticcouncil/Basilisk-node

- + \ No newline at end of file diff --git a/ru/great-unlock/index.html b/ru/great-unlock/index.html index ea36e0bc..222481d7 100644 --- a/ru/great-unlock/index.html +++ b/ru/great-unlock/index.html @@ -4,13 +4,13 @@ The Great Unlock | HydraDX Docs - +

The Great Unlock

On October 24th, ~113M DOT which was locked in the first batch of Polkadot crowdloans will be returned to its owners. Amounting to a whopping ~10% of the circulating supply, this event has not been spared of FUD. With some expecting a dump, while others not ruling out a pump - in reality, we will have to wait and see what the invisible hand of the markets is cooking.

Regardless of how the DOT price develops on Tuesday and the weeks that follow, the HydraDX Protocol retains a strong conviction in the Polkadot ecosystem. This is our home, we are here to stay, and we are more bullish than ever on Polkadot.

To celebrate the Great Unlock, the HydraDX Protocol is preparing to accumulate more DOT into its Protocol-owned liquidity (POL), on top of the 400k+ (v)DOT it already hodls. For this purpose, the Protocol is considering a Bonds campaign (subject to a governance vote) conducted via an LBP event. Besides accumulating more DOT, the Great Unlock will allow us to test two new features that recently hit mainnet.

lbp

If approved, the HydraDX Protocol will issue 50,000,000 HDX bonds (HDXb) with a 1-year maturity. Once the maturity date has been reached, these bonds are 1:1 redeemable against HDX. Also before the bonds have matured, HDXb remain transferable and tradeable on the secondary market (e.g. OTC). You can learn more about bonds in our docs.

The method of distribution for this first Bonds campaign will be a 24-hour DOT/HDXb LBP event - a real throwback for the OG Hydrators out there. The LBP will kick off on 24.10.2023 - follow our socials for the exact start time. At the start, the HDXb price will be set 22% higher than the HDX spot price. Over time, the shifting weights mechanism of the LBP will exert downward pressure on the price. The falling price will be counteracted by any buy orders obtaining HDXb from the pool. For the precise configuration of the LBP event please check the democracy vote.

Before participating, we encourage everyone to get familiar with the mechanics of an LBP in our docs.

Stay hydrated.

- + \ No newline at end of file diff --git a/ru/howto_bonds_lbp/bonds1.jpg b/ru/howto_bonds_lbp/bonds1.jpg index b6d0fe60..b1576af8 100644 Binary files a/ru/howto_bonds_lbp/bonds1.jpg and b/ru/howto_bonds_lbp/bonds1.jpg differ diff --git a/ru/howto_bonds_lbp/bonds2.jpg b/ru/howto_bonds_lbp/bonds2.jpg index 1f42eaaa..576d7582 100644 Binary files a/ru/howto_bonds_lbp/bonds2.jpg and b/ru/howto_bonds_lbp/bonds2.jpg differ diff --git a/ru/howto_bonds_lbp/index.html b/ru/howto_bonds_lbp/index.html index 65dcd00e..292ff295 100644 --- a/ru/howto_bonds_lbp/index.html +++ b/ru/howto_bonds_lbp/index.html @@ -4,13 +4,13 @@ Acquire Bonds (LBP) | HydraDX Docs - +

Acquire Bonds (LBP)

The HydraDX Protocol uses Bonds as part of its strategy to grow and diversify its Protocol-owned liquidity (POL). For this purpose, the HydraDX Governance can at any time decide to issue a given amount of bonds which will be traded against assets that the HydraDX Treasury wishes to accumulate.

This page contains a step-by-step guide on how to acquire Bonds via LBP on HydraDX. Before proceeding, we recommend that you get familiar with Bonds: https://docs.hydradx.io/bonds.

metadata

Step 0: Navigate to HydraDX Bonds Page

https://app.hydradx.io/trade/bonds

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 1: Pick the Bond you want to support

  • You will be able to see all current active Bond campaigns (2) as well as past campaigns (3).
  • Click on Trade to enter into the dedicated Bonds campaign which you want to contribute to.
metadata

Step 2: Participate in the Bonds LBP

предупреждение

Before participating in a Liquidity Bootstrapping Pool (LBP), you should first get familiar with how an LBP works.

Find more info in our docs.

The HydraDX Bonds LBP UI allows you to intuitively execute the swap:

  • Select the token you intend to use and enter the amount (4).
  • A price graph tracking the LBP price history and price trajectory (without any new trades) is provided for users to reference.
примечание

If the user conducts the swap with any asset other than the targeted asset (USDT in the example above), the protocol will automatically swap that asset into the target asset, meaning that the user will experience additional swap fees and price impact.

Note that if the user were to sell back the Bond at any time during the LBP auction, there will also be an additional return fee incurred.

  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (5).
  • To complete the trade, click on Swap (7) and sign the transaction using your wallet app.
  • Once you have completed the swap, the acquired bonds will show up under My Bonds (8).
- + \ No newline at end of file diff --git a/ru/howto_bridge/index.html b/ru/howto_bridge/index.html index 7d136210..dff25c0f 100644 --- a/ru/howto_bridge/index.html +++ b/ru/howto_bridge/index.html @@ -4,13 +4,13 @@ Bridge Assets | HydraDX Docs - +

Bridge Assets

On this page you will find a step-by-step guide on bridging tokens from the Ethereum ecosystem. Currently there are two methods to bridging to and from Ethereum (via Wormhole):

Wormhole’s Portal Bridge allows you to bridge tokens across different chains. Instead of swapping or converting assets directly, Wormhole locks your source assets in a smart contract and mints new Wormhole-wrapped assets on the target chain. You can then swap Wormhole-wrapped assets on an exchange for other assets on the target chain.

To/From Ethereum via Moonbeam

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Talisman or Metamask);
предупреждение

Make sure to have enough tokens (ETH) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens.

01 Navigate to Carrier.so

https://www.carrier.so/

предупреждение

Use with caution. All crypto applications can potentially carry risks related to smart contracts/pallets.

metadata

02 Add the Wallets from Source and Destination Network

  • Once you have navigated to Carrier.so, add the wallets needed to allow for bridging to and from the desired networks (1 in image above).
  • In the example above, Metamask was selected as the wallet for Ethereum and Talisman for HydraDX.
metadata

03 Select Networks and Wallets to Bridge

metadata
  • Once Metamask and Talisman are connected, select the network chains (2) and select the previously connected wallets (3).

04 Select Asset to Bridge

  • Select the token asset and amount of tokens you would like to bridge (4).

05 Bridge Tokens

  • Within Settings (5), you can select whether to Auto Relay the transaction. It is recommended that this is toggled on.
metadata
  • Click Confirm & Begin Transaction (6) to proceed. This will prompt your wallet to sign the transactions. Once confirmed, you are all done!

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

To/From Ethereum via Acala

Prerequisites

  • A Polkadot wallet (Talisman or Polkadot.js/apps);
  • An Ethereum wallet (Metamask);
  • Bind your two wallets following Acala's guide. Completing this action will require a small amount of ACA.
предупреждение

Make sure to have enough tokens (ETH and ACA) in your wallets to pay for fees. Remember that fees will be charged for sending and redeeming tokens, and for binding your wallet addresses.

01 Navigate to Acala Bridge Page

https://apps.acala.network/bridge

Once you have been directed to Acala bridge page, follow the actions below:

metadata

Step 2: Connect to Your Account

  • Connect your account (1).
  • Select the chains you intend to bridge to and from (2), in this case, it will be Ethereum as the Origin Chain and HydraDX as the Destination Chain.
  • Connect to your Metamask account that you are bridging from (3).

Step 3: Bridge Tokens

  • Enter the amount of tokens and the token for bridging (4).
  • To commence the bridge, click Approve Tokens (5) and sign the transaction using your Metamask wallet app.
  • Once the tokens are approved for transfer, click Send Tokens (5). This starts the bridging process cross-chain.
  • Once the transaction has been processed by Wormhole, click Redeem & Route Tokens (5). This action results in you receiving the tokens on the destination chain.

In the example above, bridging from Ethereum to HydraDX, your assets will automatically appear in your wallet on HydraDX network. If you are bridging out of HydraDX to Ethereum, your assets should appear in your Metamask wallet afterwards.

- + \ No newline at end of file diff --git a/ru/howto_dca/index.html b/ru/howto_dca/index.html index ffaebd5a..c8b3a61b 100644 --- a/ru/howto_dca/index.html +++ b/ru/howto_dca/index.html @@ -4,13 +4,13 @@ Place a DCA Order | HydraDX Docs - +

Place a DCA Order

On this page you will find a step-by-step guide for setting up a DCA order in the HydraDX Omnipool.

Before proceeding, we encourage you to visit our DCA product page in order to get yourself familiar with the HydraDX implementation of the dollar-cost averaging strategy.

Step 1: Navigate to HydraDX DCA Page

https://app.hydradx.io/dca

Step 2: Connect to Your Account

Connect your wallet to HydraDX by clicking Connect Account (1 in image above).

Step 3: Set up DCA Order

  • Select the asset you will use to pay for the swap; Enter the order amount for each DCA trade, and the total order size (2);
  • Select the time interval for each DCA swap (3);
  • Select the asset you would like to receive from the swap (4);
  • For advanced users who would like to set up orders at specific block intervals, you can toggle the switch Advanced Settings (5) to set this up;
  • If you would like to adjust your slippage preferences, you can do so by clicking on the Settings Icon (6);
  • To complete the DCA order, click on Schedule DCA trades (7) and sign the transaction using your wallet app.

Step 4: View your DCA Order

  • After submitting it, your DCA order will appear under DCA Orders;
  • To see the details, click the Dropdown Arrow (8);
  • You can cancel your DCA order for the remaining amount by clicking on Terminate (9).
- + \ No newline at end of file diff --git a/ru/howto_hydrated_farms/index.html b/ru/howto_hydrated_farms/index.html index a68739cc..1da679a6 100644 --- a/ru/howto_hydrated_farms/index.html +++ b/ru/howto_hydrated_farms/index.html @@ -4,13 +4,13 @@ Join Hydrated Farms | HydraDX Docs - +

Join Hydrated Farms

With Hydrated Farms, providing liquidity to selected assets is incentivized by additional rewards on top of rewards from trading fees. To learn more, please visit the dedicated product page.

00 Navigate to Liquidity Page

https://app.hydradx.io/liquidity

01 Provide Liquidity

Incentivized assets can be identified by the Farm rewards section which displays all available rewards for a given farm.

metadata

To join a farm, you must first provide liquidity (step-by-step guide here).

02 Join Farm

Once you have provided liquidity for an incentivized asset, you can join its farm.

metadata

To do so, click on Join farms (located next to your liquidity position) and sign the transaction using your wallet app.

Happy hydrated farming!

- + \ No newline at end of file diff --git a/ru/howto_lp/index.html b/ru/howto_lp/index.html index 22b7a585..683e8e50 100644 --- a/ru/howto_lp/index.html +++ b/ru/howto_lp/index.html @@ -4,13 +4,13 @@ Provide Liquidity | HydraDX Docs - +

Provide Liquidity

On this page you will find a step-by-step guide for providing liquidity in the HydraDX Omnipool. Becoming a liquidity provider allows you to earn rewards from the fees generated by trades in the pool.

Before deciding to become a liquidity provider, we encourage you to visit our product page and to get yourself familiar with the unique features of the HydraDX Omnipool.

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Navigate to Omnipool Liquidity

https://app.hydradx.io/#/liquidity

metadata

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Managing Your Liquidity

Adding Liquidity

To add liquidity for a given asset, click the button Add liquidity which is located right next to that asset (3).

к сведению

In the HydraDX Omnipool, each individual asset has a Total Value Locked (TVL) cap. This means that once the cap has been reached, users can no longer further add liquidity for that specific asset.

The individual caps for each asset will be reviewed from time to time by the team; any suggested revisions (either from team or the community) will be submitted as proposals via governance and voted on.

metadata

Fill in the amount of liquidity you wish to provide (1), click Add liquidity (2) and sign the transaction using your wallet.

Next, you can learn how to join Hydrated Farms and earn additional rewards on top of the rewards from trading fees.

Removing Liquidity

metadata

To remove liquidity, toggle the dropdown located right next to the relevant asset (1) and click Remove liquidity (2) on the position you wish to exit.

metadata

Toggle or enter the amount of liquidity you wish to withdraw (3), click on Remove liquidity (4) and sign the transaction using your wallet.

- + \ No newline at end of file diff --git a/ru/howto_stake/index.html b/ru/howto_stake/index.html index 38bf96fd..49573373 100644 --- a/ru/howto_stake/index.html +++ b/ru/howto_stake/index.html @@ -4,13 +4,13 @@ Stake HDX | HydraDX Docs - +

Stake HDX

Staking allows users to stake their HDX tokens and earn rewards which vest over time. This page contains a step-by-step guide on how to stake your HDX. Before proceeding, we recommend that you get familiar with the basics of HDX staking.

If you don't have any HDX, you can obtain some on our trade page by swapping against a range of assets supported by the Omnipool.

Step 0: Navigate to HydraDX Staking Page

https://app.hydradx.io/staking

Connect your wallet to HydraDX by clicking Connect Account.

Step 1: Stake Your HDX

  • Select the amount of HDX tokens you would like stake (3).
  • Click on Stake (4) to confirm and sign the transaction using your wallet app.
metadata

Step 2: Keep Your HDX Staked

  • The amount of rewards you receive is determined by the size of your staked HDX relative to the whole stake pool.
  • As time passes, you unlock a greater portion of your allocated rewards. The rate of unlocking is determined by a rewards bonding curve.
  • Learn more in the Staking product docs.

Step 3: Boost Your Rewards

  • Collect Action Points to boost your rewards and increase the pace at which you unlock rewards.
  • You can collect Action Points by voting on referenda. The more staked HDX you use for the vote and the higher the Conviction Multitplier - the more Action Points you receive.
  • Learn more in the Staking product docs.

Step 4: Claim Your Rewards

  • Review your Staking statistics to observe and plan your own staking strategy (5).
  • Once you are done staking, Claim your unlocked rewards (8).
metadata
предупреждение

Every time you claim unlocked staking rewards, you forfeit any locked rewards which are redistributed to all other stakers. Furthermore, your past Action Points will be reset.

For instance, if a staker claims rewards when 75% of the rewards are available, the remaining 25% is forfeited. The staker must then wait for the same duration to claim 75% of the subsequent batch of rewards.

- + \ No newline at end of file diff --git a/ru/howto_trade/index.html b/ru/howto_trade/index.html index 1e341999..1a77bfc4 100644 --- a/ru/howto_trade/index.html +++ b/ru/howto_trade/index.html @@ -4,13 +4,13 @@ Trade in Omnipool | HydraDX Docs - +

Trade in Omnipool

This page provides a step-by-step guide which will help you execute your first trades using the HydraDX Omnipool.

The HydraDX Omnipool is a next-gen AMM which unlocks unparalleled efficiencies, you can find out more in our product documentation.

metadata

00 Transport tokens

If you would like to execute a trade using a non-native asset (e.g. DOT or DAI), you first need to get these assets to the HydraDX chain. This step does not apply to HDX.

There are two different mechanisms to transport non-native assets:

  • Cross-chain transfer - use this tool to transfer assets from other Polkadot parachains, or from Polkadot itself. Step-by-step documentation here;
  • Ethereum bridge - for bridging assets from the Ethereum ecosystem. Step-by-step documentation here.

These solutions can also be used to transport tokens outside of the HydraDX network.

01 Enter Omnipool

https://app.hydradx.io/#/trade

02 Connect Your Account

Click on Connect wallet (1 in image above) and connect to your preferred Polkadot wallet. After that, select your account.

03 Execute a Trade

The HydraDX Trade UI allows you to intuitively execute a trade:

  • Select the pair of tokens you intend to trade (2);
  • Enter the amount of tokens for the trade (3).
    You can enter the amount of tokens you would like to pay with (e.g. 5000 DAI), but you can also enter the amount of tokens you would like to receive (e.g. 1000 HDX);
  • If you would like to adjust your slippage preferences, you can do so in Settings (4);
  • To complete the trade with instant execution (pre-selected) (5), click on Swap (7) and sign the transaction using your wallet. Otherwise, follow the additional steps below.

04 Execute a Split Trade

If your trade is large enough so that price impact would be > 0.15%, the UI will allow you to select Split trade (6) - breaking your trade into multiple smaller trades executed over < 3 hours and therefore reducing your price impact.

  • Select the pair of tokens and amounts as in 03 Execute a Trade above;
  • Select Split trade (6);
  • To schedule your Split trade execution, click on Place trades (7) and sign the transaction using your wallet.

Stay hydrated, not liquidated.

- + \ No newline at end of file diff --git a/ru/howto_wallet_parity_signer/index.html b/ru/howto_wallet_parity_signer/index.html index 2c90bb9b..e81eab3d 100644 --- a/ru/howto_wallet_parity_signer/index.html +++ b/ru/howto_wallet_parity_signer/index.html @@ -4,14 +4,14 @@ Use Parity Signer | HydraDX Docs - +

Use Parity Signer

Parity Signer is a mobile app which turns your iOS or Android device into a dedicated hardware wallet for Polkadot, Kusama, and any other Substrate-based chain. It allows you to keep your private keys offline while still being able to conveniently sign transactions in an air-gapped way using QR codes.

Set Up Parity Signer

Before You Start: Stay Safe

Start clean

Before installing Parity Signer, make sure that your phone is in a clean state. If it has been used, perform a factory reset and do not install any other apps besides Parity Signer.

Don’t Insert Sim

If possible, don’t turn on WiFi or use a secure WiFi connection, preferably with no other connected devices and a reputable VPN provider to connect, update the device, and install the Parity signer app.

Use Strong Passwords

For robust security, use long passwords for the device and the accounts you need to create to use it.

Setup New Account

Don’t use your old google ID or apple ID, create a new one specifically for this use which will be used only to download updates and parity signer. In case of Android device it’s better to not use WiFi or google account at all. We recommend using some sort of OS that encrypts your data like Lineage O.S. If an email is required, create a new one. Alternatively, you can create new apple id and email on iOS.

No Biometrics

Avoid fingerprint scanners, face ID, or shot numeric codes as they are exploitable. Use a strong password instead.

Disable All Signal-receiving Features

Use airplane mode and make sure to disable all of these features manually. If you are on an iOS device, turn it off and ask to auto-join networks and hotspots in the WiFi settings. Including:

  • Location services
  • WiFi (if required to upgrade or setup, disable right after the update)
  • Bluetooth

Logout From All Accounts

Log out from App stores, iCloud, and any other accounts you’ve joined.

Updating Your Device

If you are using WiFi to update your device, remember to disable it right after the update and use it only in a secure environment, preferably through a secure and encrypted VPN channel. After the update is complete, forget the WiFi network to make sure you don't automatically rejoin.

Install Parity Signer

Install Parity Signer from the official app store for your device (iOS / Android).
Make sure that the application you are downloading has been published by Parity Technologies.

Create a New Account

To create a new account, follow the steps below.

01 Add Seed

Open the Parity Signer app and select New seed.

metadata

02 Back Up your Recovery Phrase

The app will display your recover phrase. Write it down and store it in a safe place.

metadata

After completing this, you are all set to go! You can use your phone passcode or authentication method (fingerprint / face id) in Parity Signer.

осторожно

Stay safe!

Anyone with your seed phrase can access your funds, and there is no recourse for someone stealing your seed phrase.

To protect your seed phrase, consider the following tips:

  • Never store your seed phrase as a digital file on any device.
  • Always write down your seed phrase with a pen and paper.
  • Store the paper with your seed phrase on it somewhere safe.
  • Never give your seed phrase to anybody, including support staff.

Connect to Polkadot.js/apps

Optionally, you can add your Parity Signer account into the Polkadot.js browser extension which will allow you to view your balances on the Polkadot.js/apps accounts page and to sign transactions more easily.

On Polkadot.js/apps

To add your account, open the Polkadot.js browser extension, click on + and select Attach external QR-signer account.

metadata

On Parity Signer

  • Open Keys tab in the bottom menu;
  • Select the network you will be using from the dropdown menu next to chain;
  • Select your desired account or sub-account;
  • You will see a QR code which you need to scan with your device camera.

Add HydraDX Chain

To use Parity Signer, you first need to add a new chain to Parity Signer. If you want to use Parity only for Polkadot or Kusama, you can skip this step and proceed with updating metadata. To add a new chain, you need to scan a QR code with base information about the chain.

01 Get Chain Specs

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select HydraDX as the desired chain. After that, click on Chain Specs.

metadata

02 Add Specs

On your Parity Signer, click Scanner, scan the QR code and click Add new chain.

Use Parity Signer

осторожно

Always make sure you are scanning a QR code signed by a trusted verifier.

Sign a Transaction

To sign a transaction from your parity signer, we recommended adding it to polkadot.js extension for ease of use. Until more chains can work with Parity Signer directly, it will be the most convenient way to use it inside applications on your desktop.

When signing a transaction using your Parity Signer, Polkadot.js/apps will display a QR code.

metadata

Scan the QR code using Parity Signer and click on Unlock key and sign.

metadata

Your Parity Signer will now display a QR code. To complete signing the transaction, switch back to Polkadot.js/apps and click on Scan signature via camera.

Update Metadata

To use the Parity Signer, you require the latest metadata for decoding transactions in the Parity Signer. You can acquire the metadata by scanning a multi-part QR code containing this data, allowing the Parity Signer to decode the actual transaction and display it correctly before you sign. This step is similar to updating your ledger application.

01 Get Metadata

On your Desktop, navigate to https://nova-wallet.github.io/metadata-portal/ and select the desired chain. After that, click on Metadata.

metadata

02 Update

On your Parity Signer, click Scanner, and update the Metadata by scanning the QR code

- + \ No newline at end of file diff --git a/ru/howto_xcm/index.html b/ru/howto_xcm/index.html index 7b2e80d9..af7f80c3 100644 --- a/ru/howto_xcm/index.html +++ b/ru/howto_xcm/index.html @@ -4,13 +4,13 @@ Cross-chain Transfer | HydraDX Docs - +

Cross-chain Transfer

On this page you will find a step-by-step guide for performing cross-chain transfers.

Cross-chain transfers allow you to transport non-native assets to the HydraDX chain from other Polkadot parachains, or from Polkadot itself.

Currently, the following tokens are supported by HydraDX for cross-chain transfers:

  • DOT
  • DAI (from Acala, bridged via Wormhole)
  • ETH (from Acala, bridged via Wormhole)
  • HDX

00 Prerequisites

Before you continue, please make sure you have sufficient amount of tokens on the destination chain for fees (ACA or DOT).

01 Navigate to Cross-chain Transfers

https://app.hydradx.io/#/cross-chain

metadata

02 Connect Your Account

Click on Connect wallet and connect to your preferred Polkadot wallet. After that, select your account.

03 Cross-chain Transfer

  • Select the source chain and the destination chain;
  • Select the asset you intend to transfer and enter the amount;
  • Enter the destination address. It should automatically populate with your address on that chain, but you can also change it to another address;
  • Click Transfer and sign the transaction using your wallet.
- + \ No newline at end of file diff --git a/ru/identity/index.html b/ru/identity/index.html index 7b4d9ec2..011463b2 100644 --- a/ru/identity/index.html +++ b/ru/identity/index.html @@ -4,14 +4,14 @@ Установите свою личность | HydraDX Docs - +

Установите свою личность

Владельцы счетов имеют возможность установить свою личность, предоставив определенную информацию и сохранив ее в сети. Кроме того, идентификационная информация может быть отправлена регистраторам HydraDX для проверки. Устанавливая и проверяя свою личность, валидаторы и номинаторы помогают повысить доверие к сети.

примечание

Если вы участвуете в качестве валидатора HydraDX, мы настоятельно рекомендуем вам указать свою личность и пройти процесс проверки. Проверенные валидаторы выглядят более надежными и привлекают больше номинаций, тем самым увеличивая шансы быть включенными в набор активных валидаторов.

01 Установка идентичности

Чтобы установить свою личность, откройте Polkadot/apps (подключенный к сети HydraDX Snakenet) и перейдите в Мои учетные записи. Как вариант, вы можете перейти по этой ссылке:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/accounts

На странице учетных записей найдите учетную запись, в которой хранятся ваши привязанные токены HDX. После этого нажмите на три точки рядом с учетной записью (справа) и выберите Установить идентификацию в сети.

authorize

Вы увидите всплывающее окно с названием зарегистрировать личность. Здесь вы можете ввести следующую информацию:

  • legal name
  • email
  • web address
  • twitter
  • riot name (если вы используете систему обмена сообщениями Matrix)
примечание

Вся эта информация является необязательной - не стесняйтесь предоставлять только те детали, которые вы выбираете. Однако, если вы используете узел валидатора, мы рекомендуем вам указать свой адрес электронной почты. Это позволит нам связаться с вами в случае возникновения проблем с вашим узлом.

В последнем поле всплывающего окна вы можете увидеть сумму HDX, которую вам нужно внести для хранения вашей идентификационной информации. Вы получите этот депозит обратно, как только решите очистить информацию о своей личности.

authorize

После заполнения информации нажмите Set Identity и подпишите транзакцию с помощью расширения браузера Polkadot.js. После подтверждения транзакции данные ваша личности установлены.

02 Отправьте вашу личность для проверки

После того, как вы установили свою личность, вы можете отправить ее регистраторам сети для проверки. Для этого откройте Polkadot/apps и перейдите в Developer>Extrinsics. Как вариант, вы можете перейти по этой ссылке:

https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/extrinsics

После выбора соответствующей учетной записи HydraDX на последнем шаге вам необходимо заполнить следующую информацию:

  • extrinsic: identity
  • action: requestJudgement
  • reg_index: здесь вам нужно ввести идентификатор регистратора, которого вы выбираете для проведения проверки. HydraDX has 2 registrars: Simon Kraus - HydraSik (ID: 0) and Jimmy Tudeski - stakenode (ID: 1).
  • max_fee: здесь вам нужно ввести максимальную плату в HDX, которую вы готовы заплатить регистратору за проверку. Только регистраторы с комиссией ниже вашего max_fee будут иметь право проводить проверку.

Чтобы отправить запрос на подтверждение, нажмите Отправить транзакцию (или Submit Transaction) и подпишите транзакцию.

authorize

Обратите внимание, что процесс подтверждения личности может занять некоторое время. Чтобы увидеть статус вашего запроса, перейдите в Мои учетные записи (или My accounts) и наведите указатель мыши на раздел, отображающий вашу личность - вы увидите всплывающее окно с текущим статусом.

03 Результаты проверки

После обработки вашего запроса на подтверждение регистратор представит одно из следующих решений, которые станут видны в вашем статусе личности:

  • Unknown - значение по умолчанию, суждение еще не вынесено.
  • Reasonable - предоставленная информация кажется разумной, однако никаких углубленных проверок не проводилось.
  • KnownGood - информация верна.
  • OutOfDate - информация была верной в прошлом, но теперь она устарела.
  • LowQuality - информация неточная, но ее можно исправить, обновив.
  • Erroneous - предоставленная информация неверна и может указывать на злой умысел.
- + \ No newline at end of file diff --git a/ru/index.html b/ru/index.html index 7f6631e4..7cf13999 100644 --- a/ru/index.html +++ b/ru/index.html @@ -4,13 +4,13 @@ Приступая к работе | HydraDX Docs - +

Приступая к работе

Добро пожаловать в официальную документацию HydraDX! Здесь вы можете найти всевозможные полезные ресурсы по протоколу HydraDX. Наше намерение состоит в том, чтобы сделать это прекрасным местом для всех, охватывая весь спектр случайных посетителей, валидаторов, номинантов и разработчиков, которые хотят помочь в создании HydraDX.

HydraDX управляется сообществом, как и эти Документы. Мы рады видеть ваш вклад, который может принимать различные формы - например, вы можете написать новую статью или перевести существующую. Ознакомьтесь с нашим репозиторием GitHub, а также с некоторыми правилами участия.

Что такое HydraDX?

HydraDX-это кросс-цепной протокол ликвидности, построенный на субстрате. Наша миссия состоит в том, чтобы обеспечить бесперебойную ликвидность для всех криптоассетов путем создания первого в своем роде пула ликвидности с несколькими активами-HydraDX Omnipool. В Omnipool различные активы оцениваются друг с другом с помощью нашего собственного токена HDX в качестве прокси-сервера для определения их относительной стоимости. Создав Omnipool, HydraDX нарушает традиционную концепцию, согласно которой активы торгуются парами с использованием изолированных пулов. Кроме того, мы рады быть частью экосистемы Polkadot и с нетерпением ждем возможности стать поставщиком ликвидности для всех активов, построенных на Substrate.

- + \ No newline at end of file diff --git a/ru/lbp/index.html b/ru/lbp/index.html index b14e3d3c..9fefbed0 100644 --- a/ru/lbp/index.html +++ b/ru/lbp/index.html @@ -4,13 +4,13 @@ Liquidity bootstrapping (LBP) | HydraDX Docs - +

Liquidity bootstrapping (LBP)

LBP (Liquidity Bootstrapping Pool) is a permissionless Automated Market Maker (AMM) built for the Polkadot ecosystem. Its aim is to empower young crypto projects by allowing them to bootstrap liquidity and navigate initial price discovery while performing a fair distribution of tokens to their communities. Another possible use of LBP is to conduct bond campaigns which allow the Protocol to acquire Protocol-owned liquidity (POL).

An LBP uses a mechanism of time-based weights shifting which exerts a continuous downward pressure on the price. This is being counteracted by any buy orders that change the amount of tokens in the pool and drive the price up.

осторожно

The information in this article is for illustrative purposes only. Every LBP is different and it is impossible to predict in advance how the price will develop.

The starting price of the LBP, its weights settings and the overall general interest in the project raising liquidity are all factors which will affect the price navigation during LBP.

Do your own research before aping!

Overview of General LBP Trajectory

At Start

An LBP event begins with a predefined starting price. Projects can decide to set an unrealistically high price and let the weights push it down, but this is not necessarily always the case. You should DYOR with regard to the starting price.

If the starting price is (many times higher) than the expected valuation, it may not be wise to buy at the very beginning of the LBP event.

During the LBP Event

Every LBP event is set to run for a specific amount of time (usually 3-5 days). Through the pre-programmed changing of the token weights in the pool, a downward price pressure will begin to be exerted during the course of the LBP event. This programmed decline will have its highest downward pressure at the beginning periods of the LBP. This is because when the token weight ratio changes from, say, 90-10 to 89-11, that is a 10% increase in supply of the latter asset vs if the weighting changes from 60-40 to 59-41, which is a 2.5% increase in supply.

As such, this programmed downward pressure allows participants to enter once price reaches what they deem a reasonable level. When participants begin to buy from the LBP, this will change the expected price trajectory because this will change the ratio between the two tokens. In addition, the size and timing of the buy order also affects how large the price impact will be. Placing a very large order will drive the price up (a lot), meaning that splitting orders into smaller chuncks may be a good idea.

Eventually, as the downward pressure decreases, the buy pressure from participants will overcome the further downward pressure (supply) programmed and prices will begin to rise. At this time, some participants may also sell back their acquired tokens to the LBP. This would also change the expected price trajectory of the LBP.

Model Scenario Examples (illustrative)

Let’s take a look at how the LBP price trajectory may change based on user actions. Please note that the examples and prices below are for illustrative purposes only.

Chart 1: If nobody buys

If nobody buys, the price will continually decline based on a similar curve displayed below:

lbp

Chart 2: If someone buys (with small bids)

In case of a small but consistent buy pressure just above the $0.01 mark, the curve would look something like this:

lbp

Chart 3: If someone buys (with a large bid)

If someone buys 1/4 of all tokens at the price of $0.005, and nobody else buys or sells, the curve would look like this:

lbp

Chart 4: If someone buys (with a large bid at the end)

In cases of large buy orders towards the end of the LBP event, the price may pump significantly. This is because at the end of the LBP, the downward pressure from the weights is very small while the effect of large buy orders is relatively bigger:

lbp

Real-world LBP Examples

The abstract model scenarios above should shed some light on the interaction between user orders and the shifting weights.

Now let's take a look at several real-world examples of an LBP:

Exhibit A

Price was initially sniped by bots/whales and pumped significantly over the initial price. This was eventually counteracted by the reweighting over time and demand picking up once a more reasonable price was reached.

lbp

Exhibit B

Initial price was not sniped and allowed to fall before the significant demand from buyers pushed up prices materially. Buyers still had a good window of opportunity to enter in on acceptable prices given the duration of the LBP.

lbp

Exhibit C: HydraDX LBP

Finally, you can take a look at our analysis of the HydraDX LBP back in February 2021 which helped HydraDX raise 22.9M DAI to become one of the most successful LBPs ever conducted.

lbp
- + \ No newline at end of file diff --git a/ru/learn_amm/index.html b/ru/learn_amm/index.html index b282435f..a3aec424 100644 --- a/ru/learn_amm/index.html +++ b/ru/learn_amm/index.html @@ -4,13 +4,13 @@ What are AMMs? | HydraDX Docs - +

What are AMMs?

This article provides an introduction to Automated Market Makers (AMMs) together with some of their underpinning concepts such as slippage, liquidity provisioning and impermanent loss.

This introductory information will help you understand better the mechanics behind the HydraDX Omnipool which you can find described in our product documentation.

A Short Intro into AMMs

To explain Automated Market Makers (AMMs) and how they work, we can contrast them to their centralized counterpart: Order books.

Order Books

Order books provide a mechanism which is deployed by centralized exchanges to facilitate trading between two assets. Users can place a Buy or Sell order in an electronic list managed by the exchange. The orders in this so-called Order Book are organized by price level and progressively filled as demand shifts and orders are being matched. The limitations of order books become apparent against the background of their centralized nature.

The need for an intermediary to “keep” the order book and to facilitate the process of order matching creates a dependency on a central authority. This central authority has control over the trading and needs to be trusted by the participants. In times of substantial volume traffic and volatility, the central authority can decide to halt trading and stop performing its market-making function. Furthermore, the process of adding new tradable assets is permissioned and projects may need to pay in advance to get their assets listed.

AMMs

Automated Market Makers (AMMs) is the answer by the DeFi industry to order books. AMMs provide a decentralized, permissionless way of trading tokens without the need to subdue oneself to a central authority of control.

AMMs consist of liquidity pools that hold the available liquidity of the underlying tradable assets. This liquidity is provided by users (the so-called “liquidity providers”) who are incentivized to do so by the prospect of earning rewards from the fees generated by trades in the pool.

In the case of AMMs, any user can execute a Buy or Sell order on top of a given trading pool. The price of the trade is determined on the spot by a deterministic algorithm which takes as input the relationship between the liquidity of the traded assets, together with other factors which depend on the particular AMM implementation.

Slippage

When a trade is executed, users may experience a common side-effect of AMMs known as slippage. This is the difference between the expected price of a trade and the price when the trade is actually executed.

Slippage is determined by the amount of liquidity available within the trading pool. If there is a low amount of liquidity provided for the asset, then the slippage percentage when transacting with big orders will be higher.

Providing Liquidity

Thanks to the decentralized nature of an AMM, anyone can become a liquidity provider (LP) for a liquidity pool by depositing some amount of value in return for a token representing their liquidity position.

LPs are rewarded with fees for providing this liquidity based on the trading activity experienced by the asset for which they have provided liquidity.

Impermanent Loss (IL)

Impermanent loss (IL) is a risk faced by liquidity providers which embodies the difference in value between holding tokens in an AMM as opposed to holding them in your wallet.

Liquidity pools consist of multiple tokens (usually two) which are pooled together. IL occurs when the tokens inside the pool diverge in price. The greater the divergence, the greater the risk of negative returns for the pool's LPs.

The risk is referred to as "impermanent" because the loss is only realized when liquidity is withdrawn from the pool. If the relative prices of tokens in the pool return to their original state (when the tokens were deposited), the loss is minimized or eliminated. The loss will become permanent at the moment when the liquidity is withdrawn, leading to reduced earnings.

As such, LPs need to weigh the fees and rewards earned from LPing versus simply holding their tokens in their wallets.

- + \ No newline at end of file diff --git a/ru/node_monitoring/index.html b/ru/node_monitoring/index.html index 388c2ee4..3681219d 100644 --- a/ru/node_monitoring/index.html +++ b/ru/node_monitoring/index.html @@ -4,7 +4,7 @@ Мониторинг Ноды | HydraDX Docs - + @@ -31,7 +31,7 @@ Установите http://localhost:9090/ и нажмите Save and Test.

Настройка источника данных

Нажмите кнопку Plus на главной панели навигации и выберите import.

Мы будем использовать панель управления HydraDX, и для ее загрузки вы просто вводите идентификатор 14158 и нажимаете кнопку Load.

Здесь вам не нужно много настраивать, просто убедитесь, что Prometheus используется в качестве источника данных. Теперь вы можете завершить импорт.

Теперь вы должны сразу увидеть свою панель управления. Если некоторые панели пусты, убедитесь, что ваш выбор над панелями выглядит следующим образом:

  • Chain Metrics: Substrate
  • Chain Instance: localhost:9615
  • Server Job: node_exporter
  • Server Host: localhost:9100
- + \ No newline at end of file diff --git a/ru/omnipool_dca/index.html b/ru/omnipool_dca/index.html index 2894c2d2..0df83444 100644 --- a/ru/omnipool_dca/index.html +++ b/ru/omnipool_dca/index.html @@ -4,13 +4,13 @@ DCA Trading | HydraDX Docs - +

DCA Trading

HydraDX DCA and Split Trade (easy DCA) are two user-friendly features which allow traders to implement the dollar-cost-averaging (DCA) strategy when trading in the Omnipool - in a permissionless and non-custodial way.

Following the DCA strategy, orders are not placed at once but instead split into smaller trades which are executed at regular intervals of time. By doing so, traders may protect themselves against price volatility and achieve an average price. Additionally, splitting a large order in smaller chunks will result in less slippage.

HydraDX has two DCA implementations - the full DCA feature, and Split Trade (easy DCA) which can be found on the main trading page. Further down, you can learn more about these features.

If you are looking for step-by-step guidance, check out the how-to place a DCA order guide.

HydraDX DCA

HydraDX DCA provides an intuitive UI which enables users to fine-tune their DCA orders in the Omnipool.

When setting up their order, users specify the amount of Asset A they would like to spend in order to obtain Asset B, as well as the frequency of the trades - in hours (approximation) or number of blocks (more granularity).

After placing the order, the HydraDX DCA pallet makes sure that trades are scheduled at the specified intervals until the predetermined amount of Asset A has been spent. Placing multiple DCA orders which are executed in parallel is supported.

Users can track the status of their orders on the UI. Open orders can at any time be terminated for the remaining amount.

Split Trade (easy DCA)

Split Trade is a more simple implementation of DCA directly into the main trade page. It provides users with a one-click solution for splitting larger orders in order to protect themselves from slippage.

When activated, Split Trade will split the order in smaller chunks until the size of the trades is small enough to achieve <0.1% slippage (estimate only - the exact slippage for future trades can never be predicted in advance).

Open Split Trade orders can be terminated by the user at any time, just like any regular DCA order.

- + \ No newline at end of file diff --git a/ru/omnipool_design/index.html b/ru/omnipool_design/index.html index 6ec758fa..c6bf36b7 100644 --- a/ru/omnipool_design/index.html +++ b/ru/omnipool_design/index.html @@ -4,7 +4,7 @@ Omnipool Design | HydraDX Docs - + @@ -46,7 +46,7 @@ c-6,0,-10,-1,-12,-3s-194,-422,-194,-422s-65,47,-65,47z M834 80h400000v40h-400000z">1

The single-asset LP has sensitivity only to the TKN/LRNA price, not to prices of other tokens in the Omnipool (except indirectly via LRNA).

- + \ No newline at end of file diff --git a/ru/omnipool_hydrated_farms/index.html b/ru/omnipool_hydrated_farms/index.html index 0be0b7a2..12cdaeba 100644 --- a/ru/omnipool_hydrated_farms/index.html +++ b/ru/omnipool_hydrated_farms/index.html @@ -4,13 +4,13 @@ Hydrated Farms | HydraDX Docs - +

Hydrated Farms

Hydrated Farms are time-limited incentives programs which offer additional rewards for providing liquidity for selected assets, on top of the rewards from trading fees.

Departing from traditional liquidity mining programs, Hydrated Farms offer several distinctive features: they use Farm NFTs to represent the farm position, they support rewards stacking, and their rewards grow over time thanks to a loyalty multiplier.

On this page you will find further details on the features of Hydrated Farms. If you would like to participate, please visit our step-by-step guide on Hydrated Farms.

Farm NFTs

Whenever a user provides liquidity to the Omnipool and joins a Hydrated Farm, the HydraDX Protocol will mint an NFT which is owned by the user. This NFT represents the user position in the farm and stores certain details such as time of entry. This enables the Protocol to provide sustainable incentives with rewards which grow over time.

The owner of the farm NFT controls the position in the farm as well the underlying liquidity in the Omnipool. In the future, Protocol stakeholders may decide to open up a marketplace for Farm NFTs or enable their usage as collateral.

примечание

Due to the unique properties of the Farm NFTs, joining a given farm multiple times will yield several NFTs.

Rewards Stacking

Hydrated Farms support the possibility to offer rewards in more than one asset. In other words, rewards are stackable.

Any team can reach out to the HydraDX stakeholders with the request to create a Hydrated Farm incentivized by their own TKN. Following this example, the HydraDX governance can decide to also provide HDX as incentives to that farm. As a result, hydrated farmers would receive both HDX and TKN rewards.

Loyalty Multiplier

To encourage more sustainable liquidity provisioning, Hydrated Farms feature a loyalty multiplier - rewards grow over time as liquidity remains in the farm. You can view the exact curve for distributing rewards on the farm detail page.

Once users decide to leave a farm, their loyalty multiplier is reset and they will begin from the base level again if they decide to rejoin.

- + \ No newline at end of file diff --git a/ru/omnipool_impermanent_loss/index.html b/ru/omnipool_impermanent_loss/index.html index 1a130bed..6f03ab24 100644 --- a/ru/omnipool_impermanent_loss/index.html +++ b/ru/omnipool_impermanent_loss/index.html @@ -4,13 +4,13 @@ Less Impermanent Loss | HydraDX Docs - + - + \ No newline at end of file diff --git a/ru/omnipool_lp/index.html b/ru/omnipool_lp/index.html index ef78d5c9..99b24c7f 100644 --- a/ru/omnipool_lp/index.html +++ b/ru/omnipool_lp/index.html @@ -4,13 +4,13 @@ Single-Sided LPing | HydraDX Docs - +

Single-Sided LPing

The cutting-edge design of the HydraDX Omnipool unlocks the possibility of single-sided liquidity provisioning: Anyone can provide liquidity only for the asset they want, and as much as they want (up to the respective TVL cap for the asset). This resolves one of the main drawbacks of standard XYK AMMs which require that liquidity providers (LPs) deposit a pair of assets in equivalent value.

Liquidity in the HydraDX Omnipool is concentrated, meaning that by providing your asset you gain instant exposure to all other assets in the Omnipool. Forget about liquidity fragmentation and the need to spread your liquidity across several trading pools.

The Hub Token LRNA

Single-sided liquidity provisioning is made possible by our hub token called Lerna (LRNA). Every time liquidity is added, the Omnipool will mint a corresponding amount of LRNA to keep the pool in balance. Accordingly, LRNA will be burnt to reflect any removal of liquidity. These mechanisms ensure that the value of LRNA does not significantly fluctuate when assets are added or removed from the Omnipool.

login

Another way to understand the hub token concept is to imagine every single asset within the Omnipool as a synthetic 50/50 liquidity pool, with the only difference being that the 2nd leg of the pair is always LRNA i.e. TKN:LRNA.

This design allows the Protocol to use LRNA as a proxy which reflects the value locked in the Omnipool, including trading activity and price fluctuations, in an abstract manner.

- + \ No newline at end of file diff --git a/ru/omnipool_security/index.html b/ru/omnipool_security/index.html index 51bf15fb..cd134cf5 100644 --- a/ru/omnipool_security/index.html +++ b/ru/omnipool_security/index.html @@ -4,13 +4,13 @@ State of the Art Security | HydraDX Docs - +

State of the Art Security

The HydraDX Protocol pursues a multi-layered security strategy. On this page you will find a description of the various measures which work together to keep your funds safe.

The most basic layer of the HydraDX security strategy consists carefully conducted research and development, as well as rigorous peer review processes. On top of that, HydraDX strives to have all mission-critical code undergo rigorous audits. The next layer of the security strategy is a generous bug bounty program which makes it worthwhile to find and disclose vulnerabilities (as opposed to exploiting them).

Finally, the protocol has implemented a combination of state-of-the-art measures which are designed to protect your liquidity against unfortunate events such as toxic assets or (economic) exploits.

Audits

The HydraDX protocol conducts audits of all mission-critical code and publishes the audit reports on a regular basis.

The security audit of the Rust implementation of the HydraDX Omnipool was performed by Runtime Verification - an established industry leader with clients such as NASA, Ethereum and Polkadot. The scope of the security audit includes the source code of HydraDX Omnipool pallet,its mathematical logic and asset registry, as well as 3rd party libraries which have been included as a (Substrate) dependency. The results of the audit were published in September 2022, you can consult the full report here.

In March 2022, the economic/math audit of the Omnipool was completed by BlockScience - a leading web3 native firm dedicated to analyzing complex systems for the likes of Graph Protocol and Protocol Labs (Filecoin). The scope of this audit was to provide an overview of the AMM specification with a special attention to the mathematical and economic concepts underpinning the Omnipool, together with the implications of those mechanisms for liquidity provisioning and trading activity. You can consult the full report here, including the addendum by HydraDX with post-factum changes.

Bug Bounty Program

HydraDX has set up a generous bug bounty program which provides strong incentives for the detection and responsible disclosure of bugs and other vulnerabilities.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Mechanisms for Protecting Omnipool Liquidity

The HydraDX protocol is continuously researching and implementing mechanisms that keep the Omnipool liquidity safe. These mechanisms are activated in the unfortunate (but not impossible) scenario that an actor tries to drain liquidity from the Omnipool by abusing a toxic asset situation (LUNA-like scenario) or some malicious exploit.

TVL Caps

All assets are subject to a specific TVL cap defining the maximum proportion of liquidity which any given asset can represent in the Omnipool. Riskier assets will have lower caps compared to less risky (high mcap or stable) assets. This allows the HydraDX protocol to significantly limit the damage which may potentially be caused from toxic asset flows: Using a hyper-inflationary asset, attackers cannot drain more liquidity than its TVL cap.

Oracles

On-chain oracles provide average price information for a specified Omnipool asset during a given timeframe (e.g. 10 blocks). Oracles are an essential monitoring tool that allow the HydraDX protocol to detect irregularities and potential price manipulation attacks - and to act accordingly.

Dynamic Withdrawal Fees

To protect the Omnipool liquidity, all withdrawals of liquidity positions are subject to a fee. The withdrawal fee is dynamic, ranging between 0.01% and 1% of the total amount. The exact fee amount is determined at the time of withdrawal based on the asset in question.

The withdrawal fee covers the spread between the current spot price of the asset and the its average price over the previous 10 blocks (fetched from the HydraDX oracles). A large discrepancy between spot and average price indicates a potential price manipulation attack, and a higher withdrawal fee is applied to eliminate the economic incentives for carrying out such an attack.

In the scenario that extreme volatility leads to the spread between the spot price and average oracle price of an asset being greater than 1%, liquidity addition or withdrawal for that asset will be temporarily paused. These operations will again resume once this threshold is respected.

In-block Trade Limits

To protect the Omnipool against economic exploits, there is a limit in place that no more than 50% of an asset's liquidity can be traded in a single block - trades that are greater than this amount should be spread across multiple blocks.

Targeted Function Pausing

If some suspicious behaviour is detected on-chain, Targeted Function Pausing allows the HydraDX Technical Committee to take swift action and temporarily pause certain or all actions relating to specific assets. This action of last resort can help mitigate the damage and allow for further investigation.

- + \ No newline at end of file diff --git a/ru/omnipool_trading/index.html b/ru/omnipool_trading/index.html index 348a5c1c..a59a23a0 100644 --- a/ru/omnipool_trading/index.html +++ b/ru/omnipool_trading/index.html @@ -4,13 +4,13 @@ Efficient Trading | HydraDX Docs - +

Efficient Trading

The traditional DeFi landscape is characterised by fragmented liquidity which is dispersed across several trading pools. This leads to economic inefficiencies: More hops and shallower liquidity create higher price impact and slippage. By combining all liquidity in a single trading pool, the HydraDX Omnipool enables efficient trading like no other AMM.

Traditional AMMs: Liquidity Fragmentation

The pioneer XYK AMM model marked a pivotal moment for DeFi which made decentralized and permissionless trading possible. The simplicity of XYK pools boosted the initial adoption of DeFi, however today we stand at a point where the resulting economic inefficiencies hinder the continued adoption.

Omnipool

One of the flaws of the XYK model is that trading pools are constrained to pairs of assets. Fragmented liquidity results in a higher price impact due to more hops and slippage. The route of the ETH-AAVE trade in the screenshot above provides a practical example:

  • 85% direct from ETH to AAVE (incurring 0.3% fee);
  • 15% ETH traded for UNI first then the UNI is swapped for AAVE (incurring two 0.3% swap fees).

HydraDX Omnipool: Unified Liquidity

Thanks to the cutting-edge design, liquidity in the Omnipool truly acts as one. By having all the liquidity connected through LRNA, the assets within the Omnipool have direct access to the entirety of liquidity for any other asset that is also deposited into the Omnipool. This allows for a seamless on-chain execution and enables swaps to be completed in a single transaction with no hopping required between various isolated trading pools.

Furthermore, based on internal research, the increase in the number of tokens and total value locked (TVL) within the Omnipool lead to exponential improvements in slippage reduction.

login

To illustrate with an example, imagine the TKN asset is distributed across 4 different liquidity pools with varying levels of liquidity. In the scenario that a trader wants to trade DAI for TKN, they would only have access to the direct liquidity of the $1M TKN-DAI pool. If their trade size is substantial (e.g. $100K+), the majority of the trade will likely be routed through a DAI-ETH pool followed by the TKN-ETH pool in the traditional XYK landscape.

However, with the Omnipool, that same $5mm (50% of the total $10mm TVL) of the TKN asset and $3mm of DAI would be concentrated in one pool. As such, if a trader proceeds to make the same trade in the HydraDX Omnipool, they will get the entire benefit of the $5mm of TKN and $3mm of DAI liquidity in their direct swap, materially reducing the overall price impact.

- + \ No newline at end of file diff --git a/ru/omnipool_treasuries/index.html b/ru/omnipool_treasuries/index.html index 5de55a6a..acc22e7f 100644 --- a/ru/omnipool_treasuries/index.html +++ b/ru/omnipool_treasuries/index.html @@ -4,13 +4,13 @@ Hydrate Your Treasury (B2B) | HydraDX Docs - +

Hydrate Your Treasury (B2B)

The HydraDX Omnipool has an outspoken value proposition for the treasury of any project or DAO. Forget about centralized market makers and inflationary rewards for liquidity mining; the Omnipool can facilitate the creation of a market for your token in a cost-efficient manner - trustless, without hidden costs and while building up your POL from trading fees.

Thanks to its cutting-edge design, the HydraDX Omnipool supports single-sided LPing. Instead of wastefully allocating liquidity mining rewards to incentivize other users to provide liquidity, projects and DAOs can deposit a part of their treasury to the Omnipool and receive instant exposure to all other assets in an ocean of liquidity: Diversified and deep (HydraDX has $20M+ worth of POL which is gradually being deployed).

LPing in the HydraDX Omnipool is truly trustless. Leveraging Polkadot’s unique capability of cross-chain communication (XCM), the Omnipool empowers you to always remain in control of your funds: You can both provide your liquidity and manage it without relying on third parties.

Providing liquidity to the HydraDX Omnipool is not only cost-efficient - it is also profitable. Instead of having your tokens sit idle in your treasury, you can put them to work. You will earn rewards from trading fees, allowing you to build up POL over time. Soon, our upcoming TWAMM/DCA feature will allow you diversify the accumulated POL in other assets (e.g. dollar cost averaged stablecoins or DOT which you can use to bid on your next parachain slot).

Finally, the HydraDX Omnipool enjoys state of the art security. Besides rigorous audits and a generous bug bounty program, we have set up a combination of measures which work together to keep your liquidity safe. Learn more here.

- + \ No newline at end of file diff --git a/ru/participate_in_council_elections/index.html b/ru/participate_in_council_elections/index.html index e911d1f4..8df42729 100644 --- a/ru/participate_in_council_elections/index.html +++ b/ru/participate_in_council_elections/index.html @@ -4,13 +4,13 @@ Participate in Council Elections | HydraDX Docs - +

Participate in Council Elections

This article provides step-by-step guidance on how to participate in Council elections - voting for Council members and becoming a Council candidate.

If you are interested in how the election mechanism works, please refer to this post.

Using Polkadot/apps

Vote in Council member elections

You can see the current Council members as well as the runners-up on the Governance > Council page in Polkadot/apps.

To bring out your vote for Council members, click on Vote.

Enter the amount of tokens you are willing to lock in support of your candidates.

After that, select your candidates in order of preference by moving them from the left list to the right one. Remeber to select multiple candidates - this will help the algorithm select the optimal distribution of candidates to the Council.

To bring out your vote, click on Vote and sign the transaction.

примечание

Locked tokens cannot be transferred, however they can still be used for voting in referenda. Your tokens will remain locked and used for subsequent elections until you have decided to unlock them.

Apply as a Council candidate

You can submit your application for Council membership by navigating to Governance > Council in Polkadot/apps.

Click on Submit candidacy which will trigger a popup.

Select the account which is running for Council membership, click on Submit, and sign the transaction.

- + \ No newline at end of file diff --git a/ru/participate_in_referenda/index.html b/ru/participate_in_referenda/index.html index 338d9552..b6bb7b54 100644 --- a/ru/participate_in_referenda/index.html +++ b/ru/participate_in_referenda/index.html @@ -4,13 +4,13 @@ Participate in Referenda | HydraDX Docs - +

Participate in Referenda

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 or Polkadot/apps.

Before you decide to participate, we strongly encourage you to read through the knowledge article in the Learn / Democracy section. There you will find some important details on the mechanics behind referenda.

Using Subsquare

Vote in a Referendum

To see all active and past referenda, navigate to the Referenda tab on Subsquare.

For first time and previous users, click on Login (top right corner) and connect your wallet.

Click on an active referendum to see its details, the voting turnout, as well as the voting module.

To cast your vote, click on Vote and provide the following information:

  • Vote with account - select the voting account.
  • Value - this is the amount of HDX tokens you are willing to lock in support of the referendum.
  • Vote lock - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Nay (No) or Aye (Yes) and sign the transaction.

In the section Cast Your Vote, fill in the following information:

  • Amount to vote - this is the amount of HDX tokens you are willing to lock in support of the referendum
  • Conviction multiplier - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Vote yes or Vote no and sign the transaction.

Using Polkadot/apps

Vote in a Referendum

You can see all referenda which are open for voting by navigating to Governance > Democracy in Polkadot/apps.

To vote in a referendum, click on the Vote button next to it.

In the popup, fill in the following information:

  • Vote value - this is the amount of HDX tokens you are willing to lock in support of the referendum
  • Conviction multiplier - this is the multiplier which co-determines the weight of your vote.

After that, bring out your vote by clicking on Vote Nay (No) or Vote Aye (Yes) and sign the transaction.

Propose a Referendum

Proposing a referendum via Polkadot/apps consists of two steps - submitting a preimage, and submitting the proposal on-chain.

01 Submit preimage

To submit the preimage, visit Polkadot/apps and navigate to Governance > Democracy.

After clicking on Submit preimage, you should see the following popup:

Fill in the information in the fields show above. The most important parameters are:

  • Account from which the proposal is sent
  • Proposal area
  • Proposed action

In the example above, the proposal area is balances, and the action is forceTransfer of tokens from one account to another.

Before submitting the preimage and signing the transaction, please make sure to copy the preimage hash. You will need it for the next step.

02 Submit proposal

To submit the referendum proposal, visit Governance > Democracy in Polkadot/apps.

After clicking on Submit proposal, you should see the following popup:

Enter the preimage hash from the previous step, and the amount of tokens you are willing to deposit for the proposal. The minimum is 100,000 HDX.

After submitting the proposal on-chain and signing the transaction, your proposal should appear in the list of proposed referenda.

предупреждение

Every voting period, the referendum proposal with the highest backing (seconding) enters the voting round. As the amount of referenda grows, there is no guarantee that your proposal will ever gain sufficient seconding to enter voting. There is no option to withdraw a referendum proposal, meaning that your funds might remain locked for a longer period of time.

Malicious referendum proposals are punished. The HydraDX Council and the Technical Committee have the right to cancel any referendum which was proposed in bad faith. As a result, the deposited tokens will be burnt.

- + \ No newline at end of file diff --git a/ru/performance_benchmark/index.html b/ru/performance_benchmark/index.html index 55ba3d40..9000d92e 100644 --- a/ru/performance_benchmark/index.html +++ b/ru/performance_benchmark/index.html @@ -4,13 +4,13 @@ Тест производительности | HydraDX Docs - +

Тест производительности

Вы можете убедиться, что ваш сервер соответствует требуемым техническим характеристикам, выполнив тест производительности. Для этого выполните следующие действия:

# Получить исходный код последней стабильной версии
$ git clone https://github.com/galacticcouncil/HydraDX-node -b stable
$ cd HydraDX-node/

# Подготовьтесь к запуску теста
$ ./scripts/init.sh
$ rustup default nightly
$ apt install python3-pip
$ pip3 install bench-wizard

# Запустите тест
$ ./scripts/check_performance.sh

После выполнения теста вы должны увидеть результат, подобный следующему:

         Pallet          |   Time comparison (µs)    |     diff*     |            |   Rerun
amm | 1066.00 vs 1045.80 | 20 | OK |
exchange | 1105.00 vs 1049.10 | 55 | OK |
transaction_multi_payment| 289.00 vs 279.96 | 9 | OK |

Вы можете увидеть разницу в производительности вашего компьютера и минимально необходимой настройки в столбце diff* (%). Если все три значения в этом столбце положительны, ваша машина должна быть подходящей для запуска узла валидатора HydraDX. Если какое-либо из значений ниже -10 %, мы не рекомендуем запускать узел HydraDX.

Присоединяйтесь к нам в Discord, если вы хотите обсудить результаты своих тестов, наше сообщество всегда рады помочь.

- + \ No newline at end of file diff --git a/ru/polkadotjs_apps_local/index.html b/ru/polkadotjs_apps_local/index.html index 2c0e3269..ec9ef509 100644 --- a/ru/polkadotjs_apps_local/index.html +++ b/ru/polkadotjs_apps_local/index.html @@ -4,13 +4,13 @@ Подключение к локальному узлу HydraDX | HydraDX Docs - +

Подключение к локальному узлу HydraDX

Вы можете использовать Polkadot/apps для подключения к локальному узлу HydraDX. Для этого вам необходимо иметь доступ к порту 9944, который используется для подключений через веб-сокеты RPC.

осторожно

Если вы запускаете узел в качестве валидатора, мы настоятельно рекомендуем вам занести в черный список порт 9944 для удаленных подключений. Этот порт может быть использован третьими сторонами для снижения производительности вашего узла, что может привести к резкому сокращению и непроизвольной потере средств. Вы должны использовать порт 9944 для подключения к узлу валидатора только тогда, когда узел находится в вашей локальной сети.

Доступ к вашему локальному узлу с помощью Polkadot/apps

Чтобы получить доступ к своему узлу, откройте Polkadot/apps и щелкните в верхнем левом углу, чтобы изменить сеть.

После открытия меню нажмите Development и выберите Local node.

При необходимости измените IP-адрес и нажмите Switch, чтобы переключиться на локальный узел.

Теперь вы должны быть подключены к своему локальному узлу и иметь возможность взаимодействовать с ним.

- + \ No newline at end of file diff --git a/ru/polkadotjs_apps_public/index.html b/ru/polkadotjs_apps_public/index.html index b6532b24..1800b40d 100644 --- a/ru/polkadotjs_apps_public/index.html +++ b/ru/polkadotjs_apps_public/index.html @@ -4,13 +4,13 @@ Подключение к публичной ноде | HydraDX Docs - +

Подключение к публичной ноде

Есть два общедоступных узла RPC, которые обслуживаются HydraDX и нашими партнерами. Вы можете использовать эти узлы для взаимодействия со Snakenet. Вы можете напрямую подключиться к общедоступному узлу с помощью Polkadot/apps, нажав на ссылки ниже:

Подключиться к узлу RPC вручную

Чтобы получить доступ к общедоступному узлу RPC вручную, откройте Polkadot/apps и щелкните в верхнем левом углу, чтобы изменить сеть.

Щелкните по LIVE NETWORKS и выберите HydraDX.

Выберите один из узлов и нажмите Switch.

Теперь вы должны подключиться к выбранному общедоступному узлу RPC.

- + \ No newline at end of file diff --git a/ru/spending_fw/index.html b/ru/spending_fw/index.html index fcb5b622..0d20afb5 100644 --- a/ru/spending_fw/index.html +++ b/ru/spending_fw/index.html @@ -4,13 +4,13 @@ Contribute to HydraDX | HydraDX Docs - +

Rewarding Contributions to HydraDX

HydraDX welcomes various contributions which are in the interest of the Protocol. Such activities are incentivized with the help of rewards from the HydraDX Treasury.

The present document sets out the general framework for rewarding community contributions. This framework has been approved by the community of HydraDX in a general vote. The spending framework empowers payouts in the mentioned categories by the HydraDX Council, within the defined limits.

Please note in advance that the payout of all bounties and tips mentioned in this document is subject to the full discretion of the HydraDX Council. If you are in doubt whether your effort entitles you to a bounty, please reach out in advance.

You can ask questions in #bounties on the HydraDX Discord.

1. Bug Bounties

HydraDX runs a Bug Bounty program on Immunefi. Bugs and vulnerabilities are classified into three to four categories of severity which determine the maximum size of the bounty:

Blockchain:

  • Critical: $50,000 to $1,000,000;
  • High: $5,000 to $50,000;
  • Medium: $5,000;
  • Low: $1,000.

Websites & Apps:

  • Critical: $5,000 to $50,000;
  • High: $5,000;
  • Medium: $1,000.

Notes:

  • In order to be granted a bounty, bug reports must be made in accordance with the procedure for responsible disclosure and any other guideline posted on the HydraDX Immunefi page;
  • Bounties for critical Blockchain vulnerabilities are capped at 10% of the potential economic damage;
  • The actual size of the rewarded bounties is at the discretion of the Council;
  • Bounties are paid by the treasury in HDX using the 7d MA USD price from an exchange (CEX or DEX once Oracles are available - if in doubt, please discuss with the HydraDX Council in #bounties).

2. Development Bounties

The HydraDX development team will be launching a dashboard with development bounties in an effort to decentralize technical work on the protocol. The dashboard will present the latest bounties together with a description, technical specification and size of the bounty.

The present framework authorizes the HydraDX Council to propose development bounties of up to $100,000 which will be paid by the Treasury in HDX using the 7d MA USD price from an exchange. Bounties exceeding this amount still need to undergo the governance process.

3. Community Management

Efforts spent on Community Management can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange).

New community managers are subject to prior approval by the team.

Here are some of the expectations attached to these roles:

  • Moderate on both Telegram and Discord;
  • Be an ambassador for the project;
  • Show activity on socials;
  • Participate in bi-weekly calls with other community managers;
  • Coordinate translations
  • Ideally already an active member of the Hydra community.

4. Translations

Work on translations can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange). Currently, HydraDX welcomes translations in the following languages (this list can be extended via a referendum):

  • Mandarin
  • Spanish
  • Russian
  • Slovak

New translators are subject to prior approval by the Community Managers and/or HydraDX Council.

5. Other Community Contributions

Are you looking to contribute with an effort which does not fall into one of the categories above? Please feel free to reach out, the HydraDX Council is prepared to consider your case. This spending framework authorizes the HydraDX Council to provide tips up to the value of $100,000 (using the 7d MA USD price from an exchange).

Here are some examples of contributions that could be rewarded:

  • Creating good educational content such as guides, explanative blogs or videos [content creator should liaise with Community Managers & HydraDX Council ahead of and during production process to ensure information is of the highest quality];
  • Provisioning Decentralized infrastructure;
  • Advancing integrations which contribute to the Protocol or the community;
  • Memes (!!), emojis, merch and stickers.
- + \ No newline at end of file diff --git a/ru/staking/index.html b/ru/staking/index.html index d4c1bbfa..bd74cf24 100644 --- a/ru/staking/index.html +++ b/ru/staking/index.html @@ -4,13 +4,13 @@ Staking | HydraDX Docs - +

Staking

HydraDX has a long-running HDX staking program which incentivizes user activity in areas that are beneficial to the Protocol. On this page you will find important information regarding the mechanics behind the HDX Staking program. You can also check out our step-by-step guide on staking.

Staking Basics

HDX holders can stake their HDX and receive rewards which become claimable as time passes. Staking rewards are distributed from a dedicated pot that is gradually filled up by different Protocol revenue streams. Initially, the main revenue stream are the LP fees which the HydraDX Protocol accrues from its HDX LP position in the Omnipool. Furthermore, the HydraDX community has approved a proposal to support the APR during the first year of the staking program with an additional subsidy of ~22M HDX from the HydraDX Treasury which is gradually distributed to the staking rewards pot once per day.

Rewards which enter the staking pot are always distributed directly to all stakers at any given moment. The amount that users are entitled to is proportional to the relative size of their stake in the stake pool. However, stakers do not automatically receive the rewards on their account - instead, they need to claim them.

When it comes to claiming rewards, all participants in HDX staking should be aware of the elements of loyalty and gamification. Once rewards are awarded, they cannot be instantly claimed for the full amount - doing so would yield just a fraction of the total rewards, with the remainder being returned the pot for redistribution to all stakers.

Users who want to claim as many rewards as possible should keep their HDX staked without claiming until sufficient time has passed (rewards are “vested” following a bonding curve). The length of the waiting period is dynamic and depends on the user (in)actions. A user who just stakes passively would need to wait ~2 years to claim 95% of their rewards. In contrast, active stakers who collect the maximum amount of action points (more on that below) could claim 95% of their rewards in just over 2 months. These are rough estimates - the actual timelines may vary in accordance with user actions and overall count of referenda.

Boosting Your Rewards

Stakers can increase the pace at which they can claim their rewards by collecting action points and boosting their rewards. Action points can be acquired by performing certain actions that are incentivized by the Protocol. Initially, the only way to collect action points is to participate in the governance of HydraDX by voting on community referenda using the staked HDX.

login

There are 2 factors which determine the amount of action points that stakers will receive: The size of the vote (relative to the total size of their staked HDX), and the conviction multiplier. The higher the conviction multiplier of the vote, the greater its weight. Keep in mind that voting with a conviction multiplier places a temporary lock on the tokens. Stakers looking to achieve the highest rewards boost would be voting with 6x conviction multiplier, thereby locking their HDX for 192 days (counted from the last vote using such conviction). Just a reminder that this lock is not related to staking as such - instead, it is a standard feature of governance in the Polkadot ecosystem (more info in our docs).

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d

Claiming Your Rewards

As they keep their HDX staked, users accumulate rewards over time. These rewards become claimable subject to a bonding curve which is influenced by the boosts from action points (see above).

At any given time, stakers can claim (a portion of) their claimable rewards. By doing so, however, they forfeit the remainder of their non-claimable rewards. These rewards are automatically transferred back to the staking rewards pot which redistributes them to all other stakers. Furthermore, claiming resets the past action points of the user, sending users back to the beginning of the bonding curve for future rewards from staking.

This mechanism creates an interesting gamification dynamic: By remaining longer in the pool of stakers, users not only unlock a greater part of their allocated rewards - they also have the chance to receive a juicy portion of rewards from other stakers who claim or exit early.

Happy staking!

- + \ No newline at end of file diff --git a/ru/testnet_howto/index.html b/ru/testnet_howto/index.html index 5b314a95..b5574eef 100644 --- a/ru/testnet_howto/index.html +++ b/ru/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/ru/tip_request/index.html b/ru/tip_request/index.html index 7e0163aa..7138fe3e 100644 --- a/ru/tip_request/index.html +++ b/ru/tip_request/index.html @@ -4,13 +4,13 @@ Request a Treasury Tip | HydraDX Docs - +

Request a Treasury Tip

With the launch of the HydraDX New Deal incentives program, community members can request HDX tips from the Treasury as a reward for their contributions. 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.

The process of requesting a Treasury tip consists of two steps. In the first step, contributors need to publish their tip request in Commonwealth.im with a description of the contribution. As a second step, the Treasury tip request must be submitted on-chain using Polkadot/apps.

01 Publish the Tip Request in Commonwealth.im

To safeguard transparency, all Treasury tip requests must be published in a thread on the HydraDX Commonwealth page. Before opening a thread, you need to link your HydraDX wallet to Commonwealth.im: Click Log in (top right corner) and select Connect with wallet > polkadot-js.

login

After selecting your HDX address in the popup, you will be asked to sign the message using your wallet and to set a display name for this wallet.

Once logged in, you need to create a new thread for your tip request. Navigate to the top-right part of the page and click on New thread > New thread. You can also directly use this link: https://commonwealth.im/hydradx/new/thread.

You can use the title of the thread to indicate the subject (tip request) and the topic of the contribution. In the body of the thread, please provide the following information:

  • Period when the contribution was made
  • A brief summary of the contribution
  • The amount of the requested tip (in HDX)
  • Time spent on the contribution (in hours)
  • If needed, a more detailed description including the relevance of the contribution to HydraDX

For reference, you can take a look at this example tip request.

After filling out the information, post the thread and it should become available in the general list.

примечание

Nominators and validators who overbonded their HDX and got "stuck" can request a Treasury tip of 1 HDX which will allow them to unbond some of their tokens. If this applies to your case, please create a Commonwealth thread following this example.

02 Submit the Tip Request On-Chain

After publishing your Treasury tip request, you need to submit it on-chain. For this purpose, your wallet needs to hold a small amount of HDX to cover the transaction fees. If you currently do not hold any HDX, you do not need to execute this step - someone else will submit your tip request on-chain for you.

Treasury tip requests can be submitted on-chain with Polkadot/apps using the following link: https://polkadot.js.org/apps/?rpc=wss%253A%252F%252Frpc.hydradx.cloud#/treasury/tips.

To submit a new tip request, click on Propose tip and provide the following information:

  • submit with account - select the account which will sign the transaction for submitting the tip request on-chain. This account needs to hold a small amount of HDX for transaction costs.
  • beneficiary - select or enter the address of the account which will receive the Treasury tip. This account must correspond to the account which opened the Commonwealth thread.
  • tip reason - provide a URL to the Commonwealth thread.
login

To submit the tip request, click on Propose tip and sign the transaction.

Once the transaction is confirmed, you should see the tip request on the overview page.

login
- + \ No newline at end of file diff --git a/ru/tokenomics/index.html b/ru/tokenomics/index.html index 31232d10..20a10758 100644 --- a/ru/tokenomics/index.html +++ b/ru/tokenomics/index.html @@ -4,13 +4,13 @@ HDX Tokenomics | HydraDX Docs - +

HDX Tokenomics

Purpose

The HDX token is a governance token that allows staked token holders to decide the future of the protocol. Our mission with the HydraDX DAO is to distribute all decision-making to create a trustless liquidity protocol built around community-growth and self-sustainability.

To have a vote in the HydraDX DAO, and to contribute to the determination of any of the topics raised by community members, one must hold the HDX governance token. For more specifically on the governance process, please read our Democracy documentation.

HDX will initially be used for the following:

  • Setting the base network swap fee (the user may change this to any asset)
  • Voting on protocol upgrades
  • Voting on topics raised by community members (inclusive of allocation of Protocol-Owned Liquidity)

HDX Token Allocation

Upon the launch of the HydraDX DAO, the defined maximum supply of HDX tokens was 10 billion HDX. However through the governance-approved supply reduction, this defined maximum supply was reduced to 6.5 billion HDX tokens.

The allocation of these tokens is currently as follows:

  • LBP Participants - 30.5% (~1.983B)
  • Founders and team - 12.5% (810M)
  • Investors - 10.6% (690M)
  • HDX Crowdloan - 7.6% (~494.6M)
  • BSX Crowdloan - 1.9% (~120.7M)
  • DAO treasury - 5.5% (~354.5M)
  • Collators - 3.9% (~251.5M)
  • Growth - 27.6% (~1.796B)

HDX Emission Schedule

As of Sept 2023, ~2.6 billion of HDX tokens are in circulation.

There is currently no concrete emission/release schedule for HDX tokens residing in the Treasury and Growth allocations. HydraDX intends to distribute the supply of HDX in the treasury and growth funds to help fund ecosystem development where opportunities may arise. All of these distributions will be discussed transparently to the community beforehand and voted on by the HydraDX DAO.

Token distributions range from a variety of developmental purposes and growth initiatives, (eg. HDX bonds, liquidity provider rewards, integrations/partnerships with other projects, etc).

- + \ No newline at end of file diff --git a/spending_fw/index.html b/spending_fw/index.html index 11a04570..4cb23134 100644 --- a/spending_fw/index.html +++ b/spending_fw/index.html @@ -4,13 +4,13 @@ Contribute to HydraDX | HydraDX Docs - +

Rewarding Contributions to HydraDX

HydraDX welcomes various contributions which are in the interest of the Protocol. Such activities are incentivized with the help of rewards from the HydraDX Treasury.

The present document sets out the general framework for rewarding community contributions. This framework has been approved by the community of HydraDX in a general vote. The spending framework empowers payouts in the mentioned categories by the HydraDX Council, within the defined limits.

Please note in advance that the payout of all bounties and tips mentioned in this document is subject to the full discretion of the HydraDX Council. If you are in doubt whether your effort entitles you to a bounty, please reach out in advance.

You can ask questions in #bounties on the HydraDX Discord.

1. Bug Bounties

HydraDX runs a Bug Bounty program on Immunefi. Bugs and vulnerabilities are classified into three to four categories of severity which determine the maximum size of the bounty:

Blockchain:

  • Critical: $50,000 to $1,000,000;
  • High: $5,000 to $50,000;
  • Medium: $5,000;
  • Low: $1,000.

Websites & Apps:

  • Critical: $5,000 to $50,000;
  • High: $5,000;
  • Medium: $1,000.

Notes:

  • In order to be granted a bounty, bug reports must be made in accordance with the procedure for responsible disclosure and any other guideline posted on the HydraDX Immunefi page;
  • Bounties for critical Blockchain vulnerabilities are capped at 10% of the potential economic damage;
  • The actual size of the rewarded bounties is at the discretion of the Council;
  • Bounties are paid by the treasury in HDX using the 7d MA USD price from an exchange (CEX or DEX once Oracles are available - if in doubt, please discuss with the HydraDX Council in #bounties).

2. Development Bounties

The HydraDX development team will be launching a dashboard with development bounties in an effort to decentralize technical work on the protocol. The dashboard will present the latest bounties together with a description, technical specification and size of the bounty.

The present framework authorizes the HydraDX Council to propose development bounties of up to $100,000 which will be paid by the Treasury in HDX using the 7d MA USD price from an exchange. Bounties exceeding this amount still need to undergo the governance process.

3. Community Management

Efforts spent on Community Management can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange).

New community managers are subject to prior approval by the team.

Here are some of the expectations attached to these roles:

  • Moderate on both Telegram and Discord;
  • Be an ambassador for the project;
  • Show activity on socials;
  • Participate in bi-weekly calls with other community managers;
  • Coordinate translations
  • Ideally already an active member of the Hydra community.

4. Translations

Work on translations can be rewarded from the HydraDX treasury in HDX at a rate of $20 per hour (using the 7d MA USD price from an exchange). Currently, HydraDX welcomes translations in the following languages (this list can be extended via a referendum):

  • Mandarin
  • Spanish
  • Russian
  • Slovak

New translators are subject to prior approval by the Community Managers and/or HydraDX Council.

5. Other Community Contributions

Are you looking to contribute with an effort which does not fall into one of the categories above? Please feel free to reach out, the HydraDX Council is prepared to consider your case. This spending framework authorizes the HydraDX Council to provide tips up to the value of $100,000 (using the 7d MA USD price from an exchange).

Here are some examples of contributions that could be rewarded:

  • Creating good educational content such as guides, explanative blogs or videos [content creator should liaise with Community Managers & HydraDX Council ahead of and during production process to ensure information is of the highest quality];
  • Provisioning Decentralized infrastructure;
  • Advancing integrations which contribute to the Protocol or the community;
  • Memes (!!), emojis, merch and stickers.
- + \ No newline at end of file diff --git a/staking/index.html b/staking/index.html index 39ff8160..2fdda5e9 100644 --- a/staking/index.html +++ b/staking/index.html @@ -4,13 +4,13 @@ Staking | HydraDX Docs - +

Staking

HydraDX has a long-running HDX staking program which incentivizes user activity in areas that are beneficial to the Protocol. On this page you will find important information regarding the mechanics behind the HDX Staking program. You can also check out our step-by-step guide on staking.

Staking Basics

HDX holders can stake their HDX and receive rewards which become claimable as time passes. Staking rewards are distributed from a dedicated pot that is gradually filled up by different Protocol revenue streams. Initially, the main revenue stream are the LP fees which the HydraDX Protocol accrues from its HDX LP position in the Omnipool. Furthermore, the HydraDX community has approved a proposal to support the APR during the first year of the staking program with an additional subsidy of ~22M HDX from the HydraDX Treasury which is gradually distributed to the staking rewards pot once per day.

Rewards which enter the staking pot are always distributed directly to all stakers at any given moment. The amount that users are entitled to is proportional to the relative size of their stake in the stake pool. However, stakers do not automatically receive the rewards on their account - instead, they need to claim them.

When it comes to claiming rewards, all participants in HDX staking should be aware of the elements of loyalty and gamification. Once rewards are awarded, they cannot be instantly claimed for the full amount - doing so would yield just a fraction of the total rewards, with the remainder being returned the pot for redistribution to all stakers.

Users who want to claim as many rewards as possible should keep their HDX staked without claiming until sufficient time has passed (rewards are “vested” following a bonding curve). The length of the waiting period is dynamic and depends on the user (in)actions. A user who just stakes passively would need to wait ~2 years to claim 95% of their rewards. In contrast, active stakers who collect the maximum amount of action points (more on that below) could claim 95% of their rewards in just over 2 months. These are rough estimates - the actual timelines may vary in accordance with user actions and overall count of referenda.

Boosting Your Rewards

Stakers can increase the pace at which they can claim their rewards by collecting action points and boosting their rewards. Action points can be acquired by performing certain actions that are incentivized by the Protocol. Initially, the only way to collect action points is to participate in the governance of HydraDX by voting on community referenda using the staked HDX.

login

There are 2 factors which determine the amount of action points that stakers will receive: The size of the vote (relative to the total size of their staked HDX), and the conviction multiplier. The higher the conviction multiplier of the vote, the greater its weight. Keep in mind that voting with a conviction multiplier places a temporary lock on the tokens. Stakers looking to achieve the highest rewards boost would be voting with 6x conviction multiplier, thereby locking their HDX for 192 days (counted from the last vote using such conviction). Just a reminder that this lock is not related to staking as such - instead, it is a standard feature of governance in the Polkadot ecosystem (more info in our docs).

Conviction MultiplierDays Locked
0.1x0d
1x6d
2x12d
3x24d
4x48d
5x96d
6x192d

Claiming Your Rewards

As they keep their HDX staked, users accumulate rewards over time. These rewards become claimable subject to a bonding curve which is influenced by the boosts from action points (see above).

At any given time, stakers can claim (a portion of) their claimable rewards. By doing so, however, they forfeit the remainder of their non-claimable rewards. These rewards are automatically transferred back to the staking rewards pot which redistributes them to all other stakers. Furthermore, claiming resets the past action points of the user, sending users back to the beginning of the bonding curve for future rewards from staking.

This mechanism creates an interesting gamification dynamic: By remaining longer in the pool of stakers, users not only unlock a greater part of their allocated rewards - they also have the chance to receive a juicy portion of rewards from other stakers who claim or exit early.

Happy staking!

- + \ No newline at end of file diff --git a/testnet_howto/index.html b/testnet_howto/index.html index 5f9d97df..35efb29a 100644 --- a/testnet_howto/index.html +++ b/testnet_howto/index.html @@ -4,13 +4,13 @@ Design and Automation of our Tesnet Deployment at HydraDX | HydraDX Docs - +

Design and Automation of our Tesnet Deployment at HydraDX

In this article, we are going to show you how we designed and automated our pipeline to be able to deploy a new testnet (Parachain + Relaychain) within minutes using Kubernetes (EKS Fargate), AWS ACM, Route53, Terraform and Github Actions.

The choice of EKS with Fargate

Why EKS with Fargate?

Our Parachain and Relaychain images are based on two separate images, which need one or more containers to run for each. Kubernetes being the standard of container automation and scaling in the industry today, we naturally made this choice (Docker Swarm has some serious scaling issues that we might talk about in a separate article, if interest be.)

Now, since our infrastructure is partially based on AWS, we had the choice between having either EKS with EC2 instances running under the hood, or using Fargate. The difference between the two is that, with EC2, you have less flexibility as far as controlling the resources is concerned; if you have no idea about the number of pods you need to be running in the future, you most likely will have to overestimate the capacity (CPU / RAM power as well as the number) of your instances, which may result in useless capacity lost and higher bills. Another reason is that these EC2 instances need to be administrated, which needs time and resources.

For these reasons, we came to the conclusion that the usage of Fargate might be a better solution for dealing with our deployments and to be able to scale (either up or down) them correctly. In Fargate, you don't need to worry about instances or servers, all you have to do (in a nutshell) is to write your Kubernetes Manifests, apply those, and AWS will take care of the rest; i.e. provisioning the servers, planning the pods, etc.

To create a Kubernetes Instance in AWS, you can either use EKSCTL or Terraform. Nothing fancy here. Here is an example for creating a Fargate Cluster (from the documentation):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: fargate-cluster
region: ap-northeast-1

nodeGroups:
- name: ng-1
instanceType: m5.large
desiredCapacity: 1

fargateProfiles:
- name: fp-default
selectors:
# All workloads in the "default" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: default
# All workloads in the "kube-system" Kubernetes namespace will be
# scheduled onto Fargate:
- namespace: kube-system
- name: fp-dev
selectors:
# All workloads in the "dev" Kubernetes namespace matching the following
# label selectors will be scheduled onto Fargate:
- namespace: dev
labels:
env: dev
checks: passed

Once done, all we had to do is to create and apply our Kubernetes Objects.

Deployment of our Relaychain

Deployment Example:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: relaychain-alice-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: relaychain-alice
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: relaychain-alice
spec:
containers:
- image: YOUR-IMAGE-HERE
imagePullPolicy: Always
name: relaychain-alice
command: ["/polkadot/polkadot"]
args: ["--chain", "/polkadot/config.json", ..."]
ports:
- containerPort: 9944
- containerPort: 30333

In this manifest, we choose the name of our node, the ports to expose, the command and its argument (please check HydraDX docs) as well as the number of replicas. This parameter is important as we only want one replica per node, to avoid sync issues. Note that you can have as many nodes as necessary.

Service Example

We use the Service object in Kubernetes for at least two purposes here:

  1. First, so nodes can communicate with each other, please check this link for more info
  2. To be able to expose the service to the outside world, if necessary, using an ingress controller.

Nothing fancy, just yet another basic service:

apiVersion: v1
kind: Service
metadata:
namespace: YOUR_NAMESPACE
name: SVC_NAME
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: relaychain-alice

Please note that, if you wish to expose the service to the outside world, the selector parameter becomes crucial.

And voilà ! That's it. Now one last step is when we want to expose a Service (related to a given Deployment) to the outside world. For this, we use what we call an Ingress Object:

Ingress Example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
namespace: YOUR_NAMESPACE
name: INGRESS_OBJECT_NAME
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/group.name: wstgroup2
alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=4000
alb.ingress.kubernetes.io/auth-session-timeout: '86400'
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":443}, {"HTTPS":443}]'
alb.ingress.kubernetes.io/healthcheck-path: /
alb.ingress.kubernetes.io/healthcheck-port: '80'
alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=600
alb.ingress.kubernetes.io/certificate-arn: YOUR_ARN
labels:
app: relaychain
spec:
rules:
- host: relaychain.hydration.cloud
http:
paths:
- path: /ws/
backend:
serviceName: relaychain-bob-svc
servicePort: 80

This object, namely Ingress, is used so our service can be accessible from the outside world using the host address relaychain.hydration.cloud. For this, we use the ALB Controller Service of AWS More information here

Parameters of this Ingress are pretty much basic, and can be kept as is for more info, please check this link. The most important value to change, is the one of alb.ingress.kubernetes.io/certificate-arn, which is the identifier of the ACM Certificate you get when you create an entry in ACM for your host. More details later on in this article.

Deployment of our Parachain

Since the steps are pretty much the same, here are simply samples for each object we used to deploy our Parachain:

Deployment Example (collator):

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: YOUR_NAMESPACE
name: parachain-coll-01-deployment
spec:
selector:
matchLabels:
app.kubernetes.io/name: parachain-coll-01
replicas: 1
template:
metadata:
labels:
app.kubernetes.io/name: parachain-coll-01
spec:
containers:
- image: YOUR_IMAGE
imagePullPolicy: Always
name: parachain-coll-01
volumeMounts:
- mountPath: /tmp
name: persistent-storage
command: ["/basilisk/basilisk"]
args: ["--chain", "local", "--parachain-id", "", "--alice", "--base-path", "/basilisk/", "--node-key", "", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--", "--chain", "/tmp/rococo-local-raw.json", "--bootnodes", "/dns/coll-01-svc.YOUR_NAMESPACE.svc.cluster.local/tcp/30333/p2p/KEY", "--base-path", "/basilisk/", "--execution=wasm"]
ports:
- containerPort: 9944
- containerPort: 9933
- containerPort: 30333
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: efs-pv

Service Example:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: coll-01-svc
spec:
ports:
- port: 9944
name: websocket
targetPort: 9944
protocol: TCP
- port: 30333
name: custom-port
targetPort: 30333
protocol: TCP
- port: 9933
name: rpc-port
targetPort: 9933
type: NodePort
selector:
app.kubernetes.io/name: parachain-coll-01

Public RPC Service:

apiVersion: v1
kind: Service
metadata:
namespace: NAMESPACE
name: public-rpc-svc
spec:
ports:
- port: 80
name: websocket
targetPort: 9944
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: public-rpc

Ingress:

Ingress Manifest remains exactly the same.

What are the challenges we faced?

Apart from the choice that we had to make between EC2 and Fargate instances, we had an issue that wasn't that easy to be dealt with: namely, the volumes. During our deployment, we found out that we had to pass a configuration to our Basilisk Command, which could not be stored in a config-map, since the configuration was more than 4MB in size, whereas config-maps can only store up to 1MB. Now the problem is that, this is something pretty straight forward to do in Kubernetes (create a Volume, put a file or folder inside and use it from other pods) with EC2, the task isn't so simple with Fargate. In Fargate, Volumes were not supported until August 2020, and the feature is still not mature. So if you have to heavily use volumes in your Kubernetes Deployment, please take this into account. We could however solve this issue following this documentation, with AWS EFS. This link will save your ass if you have to use volumes with Fargate, trust me.

ACM and Route53

If you need to expose your node to the outside world, with a nice and secured URL, you can use AWS ACM. Basically, all you need to do is to create a certificate with the name of your URL, validate it (via DNS), and get the result ARN. Then add it as a value of the alb.ingress.kubernetes.io/certificate-arn parameter in your Ingress Manifest file, and voilà !

Terraform for Automated Deployment

Of course, the creation of your certificate can be done through Terraform, if you want to automate it in your CI (we didn't make this choice, but we will probably deploy it later). However, this .tf file might be of a great help to you:

provider "aws" {
region = "eu-west-1"
}

# DNS Zone Name: hydraction.cloud
variable "dns_zone" {
description = "Specific to your setup, pick a domain you have in route53"
default = "hydration.cloud"
}
# subdomain name
variable "domain_dns_name" {
description = "domainname"
default = "YOUR_SUBDOMAIN"
}


# On crée une datasource à partir du nom de la zone DNS
data "aws_route53_zone" "public" {
name = "${var.dns_zone}"
private_zone = false
}
resource "aws_acm_certificate" "myapp-cert" {
domain_name = "${var.domain_dns_name}.${data.aws_route53_zone.public.name}"
#subject_alternative_names = ["${var.alternate_dns_name}.${data.aws_route53_zone.public.name}"]
validation_method = "DNS"
lifecycle {
create_before_destroy = true
}
}
resource "aws_route53_record" "cert_validation" {
for_each = {
for dvo in aws_acm_certificate.myapp-cert.domain_validation_options : dvo.domain_name => {
name = dvo.resource_record_name
record = dvo.resource_record_value
type = dvo.resource_record_type
}
}
allow_overwrite = true
name = each.value.name
records = [each.value.record]
ttl = 60
type = each.value.type
zone_id = data.aws_route53_zone.public.id
}
# This tells terraform to cause the route53 validation to happen
resource "aws_acm_certificate_validation" "cert" {
certificate_arn = aws_acm_certificate.myapp-cert.arn
validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
}

output "acm-arn" {
value = aws_acm_certificate.myapp-cert.arn
}

The output value of this TF is the ARN to be used in your Ingress Manifest file.

Github Actions to wrap it all

Of course, you can just write your manifest files, and deploy your Kubernetes Objects using kubectl apply, but you might as well want to do it through a CI-CD. We use Github Actions, and it's pretty straightforward:

name: deploy app to k8s and expose
on:
push:
branches:
- main

jobs:
deploy-prod:
name: deploy
runs-on: ubuntu-latest
env:
ACTIONS_ALLOW_UNSECURE_COMMANDS: true
AWS_ACCESS_KEY_ID: ${{ secrets.K8S_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.K8S_AWS_SECRET_KEY_ID }}
AWS_REGION: ${{ secrets.AWS_REGION }}
NAMESPACE: validators_namespace
APPNAME1: validator1
APPNAME2: validator2
DOMAIN: hydration.cloud
SUBDOMAIN: validator1
IMAGENAME: YOUR_IMAGE
CERTIFICATE_ARN: _CERTIFICATEARN_

steps:
- name: checkout code
uses: actions/checkout@v2.1.0

- name: run-everything
run: |
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
export AWS_ACCESS_KEY_ID=${{ env.AWS_ACCESS_KEY_ID }}
export AWS_SECRET_ACCESS_KEY=${{ env.AWS_SECRET_ACCESS_KEY }}
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version
aws eks --region eu-west-1 update-kubeconfig --name CLUSTER_NAME
kubectl delete all --all -n ${{ env.NAMESPACE }}
eksctl create fargateprofile --cluster CLUSTER_NAME --region ${{ env.AWS_REGION }} --name ${{ env.NAMESPACE }} --namespace ${{ env.NAMESPACE }}
sed -i 's/_NAMESPACE_/${{ env.NAMESPACE }}/g' components.yaml
kubectl apply -f components.yaml

This workflow basically creates the fargate profile as well as depoys your manifest file containing all your Kubernetes Objects to your chosen Cluster. Of course, make sure you give the right access and secret keys :).

Good luck!

- + \ No newline at end of file diff --git a/tip_request/index.html b/tip_request/index.html index 3e9415a0..d7ea832e 100644 --- a/tip_request/index.html +++ b/tip_request/index.html @@ -4,13 +4,13 @@ Request a Treasury Tip | HydraDX Docs - +

Request a Treasury Tip

Community members can request HDX tips from the HydraDX 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.

The process of requesting a Treasury tip consists of two steps. As a first step, contributors need to publish their tip request in Subsquare with a description of the contribution. As a second step, the Treasury tip request must be submitted on-chain using Polkadot/apps.

01 Publish in Subsquare

To safeguard transparency, all Treasury tip requests must be published as a Discussion thread on the HydraDX Subsquare page.

note

Before opening a thread, make sure that Subsquare is linked to your HDX wallet. To do so, click on Sign-Up (first-time use) or Login (repeated use) and select the option with Web3 address. After selecting your HDX address in the popup, you will be asked to sign the message using your wallet.

Once logged in, you need to create a new Discussion thread for your tip request. You can do so following this link: https://hydradx.subsquare.io/post/create

You can use the title of the thread to indicate the subject (tip request) and the topic of the contribution. In the body of the thread, please provide the following information:

  • Period when the contribution was made
  • A brief summary of the contribution
  • The amount of the requested tip (in HDX)
  • Time spent on the contribution (in hours)
  • If appropriate, provide more detailed information such as the relevance of the contribution to HydraDX and a link to the PR (in the case of technical contributions)

Before posting the thread, please make sure that the tab Treasury is selected to indicate the nature of the Discussion.

For reference, you can take a look at this example tip request.

login

Click on Create to publish your Discussion thread. Immediately after that, it should become visible in the list of discussions.

02 Submit On-Chain

After publishing your Treasury tip request, you need to submit it on-chain. For this purpose, your wallet needs to hold a small amount of HDX to cover the transaction fees. If you currently do not hold any HDX, you do not need to execute this step - someone else will submit your tip request on-chain for you.

Treasury tip requests can be submitted on-chain with Polkadot/apps using the following link: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.hydradx.cloud#/treasury/tips

To submit a new tip request, click on Propose tip and provide the following information:

  • submit with account - select the account which will sign the transaction for submitting the tip request on-chain. This account needs to hold a small amount of HDX for transaction costs.
  • beneficiary - select or enter the address of the account which will receive the Treasury tip. This account must correspond with the account which opened the Subsquare thread.
  • tip reason - provide a URL to the Subsquare thread.
login

To submit the tip request, click on Propose tip and sign the transaction.

Once the transaction is confirmed, you should see the tip request on the overview page.

login
- + \ No newline at end of file diff --git a/tokenomics/index.html b/tokenomics/index.html index 52a3b85f..7bf03dfc 100644 --- a/tokenomics/index.html +++ b/tokenomics/index.html @@ -4,13 +4,13 @@ HDX Tokenomics | HydraDX Docs - +

HDX Tokenomics

Purpose

The HDX token is a governance token that allows staked token holders to decide the future of the protocol. Our mission with the HydraDX DAO is to distribute all decision-making to create a trustless liquidity protocol built around community-growth and self-sustainability.

To have a vote in the HydraDX DAO, and to contribute to the determination of any of the topics raised by community members, one must hold the HDX governance token. For more specifically on the governance process, please read our Democracy documentation.

HDX will initially be used for the following:

  • Setting the base network swap fee (the user may change this to any asset)
  • Voting on protocol upgrades
  • Voting on topics raised by community members (inclusive of allocation of Protocol-Owned Liquidity)

HDX Token Allocation

Upon the launch of the HydraDX DAO, the defined maximum supply of HDX tokens was 10 billion HDX. However through the governance-approved supply reduction, this defined maximum supply was reduced to 6.5 billion HDX tokens.

The allocation of these tokens is currently as follows:

  • LBP Participants - 30.5% (~1.983B)
  • Founders and team - 12.5% (810M)
  • Investors - 10.6% (690M)
  • HDX Crowdloan - 7.6% (~494.6M)
  • BSX Crowdloan - 1.9% (~120.7M)
  • DAO treasury - 5.5% (~354.5M)
  • Collators - 3.9% (~251.5M)
  • Growth - 27.6% (~1.796B)

HDX Emission Schedule

As of Sept 2023, ~2.6 billion of HDX tokens are in circulation.

There is currently no concrete emission/release schedule for HDX tokens residing in the Treasury and Growth allocations. HydraDX intends to distribute the supply of HDX in the treasury and growth funds to help fund ecosystem development where opportunities may arise. All of these distributions will be discussed transparently to the community beforehand and voted on by the HydraDX DAO.

Token distributions range from a variety of developmental purposes and growth initiatives, (eg. HDX bonds, liquidity provider rewards, integrations/partnerships with other projects, etc).

- + \ No newline at end of file