diff --git a/docs/.vuepress/public/assets/img/network/technical_stack.png b/docs/.vuepress/public/assets/img/network/technical_stack.png new file mode 100644 index 00000000000..2f3e0177a3f Binary files /dev/null and b/docs/.vuepress/public/assets/img/network/technical_stack.png differ diff --git a/docs/.vuepress/public/assets/img/network/token_economy.png b/docs/.vuepress/public/assets/img/network/token_economy.png new file mode 100644 index 00000000000..759fa5b497e Binary files /dev/null and b/docs/.vuepress/public/assets/img/network/token_economy.png differ diff --git a/docs/.vuepress/sidebar.ts b/docs/.vuepress/sidebar.ts index 4e5399e0b18..0079ff9d2ff 100644 --- a/docs/.vuepress/sidebar.ts +++ b/docs/.vuepress/sidebar.ts @@ -468,7 +468,7 @@ export const getSidebar = (locale: string) => ], }, { - text: "Node Operators", + text: "Node Operators / Indexers", link: `${locale}/subquery_network/node_operators/introduction.md`, collapsible: true, children: [ diff --git a/docs/quickstart/quickstart_multichain/snippets/multi-chain-cosmos-quickstart-reference.md b/docs/quickstart/quickstart_multichain/snippets/multi-chain-cosmos-quickstart-reference.md index 3337a957c82..7ff48aca9df 100644 --- a/docs/quickstart/quickstart_multichain/snippets/multi-chain-cosmos-quickstart-reference.md +++ b/docs/quickstart/quickstart_multichain/snippets/multi-chain-cosmos-quickstart-reference.md @@ -1,4 +1,4 @@ -If you are new to SubQuery, we recommend starting your learning journey with single-chain examples, such as the [Osmosis](../quickstart_chains/cosmos-osmosis.md). +If you are new to SubQuery, we recommend starting your learning journey with single-chain examples, such as the [Osmosis](../../quickstart_chains/cosmos-osmosis.md) example. ::: diff --git a/docs/subquery_network/architects/introduction.md b/docs/subquery_network/architects/introduction.md index 1062e02d1ca..225b1d2804e 100644 --- a/docs/subquery_network/architects/introduction.md +++ b/docs/subquery_network/architects/introduction.md @@ -2,7 +2,7 @@ ## What is an Architect? -An Architect is a SubQuery network participant who creates SubQuery projects for Indexers to index. +An Architect is a SubQuery network participant who creates SubQuery indexing projects for Indexers to index. ## Requirements to become an Architect @@ -17,8 +17,8 @@ Architects may be dApp developers, data analytics experts, or someone with a sol ## How Architects are rewarded? -Architects can sell their services for creating SubQuery projects. Here, Architects can determine what SubQuery projects the Consumer market demands and build projects specifically for these Consumers. Alternatively, Architects can also index their own projects, and thus also become an Indexer and gain rewards from serving query data to Consumers. +Architects can sell their services for creating SubQuery projects. Here, Architects can determine what SubQuery projects the Consumer market demands and build projects specifically for these Consumers. Commonly, Architects might also index their own projects, and thus also become an Indexer and gain rewards from serving valuable query data to Consumers. ## Next steps -You can already become an architect today, all you need to do is learn how to build a SubQuery project. View the quick start guide [here](../../quickstart/quickstart.md) to get started! +You can already become an architect today, all you need to do is learn how to build a SubQuery project. View the [quick start guide here](../../quickstart/quickstart.md) to get started! diff --git a/docs/subquery_network/consumers/faq.md b/docs/subquery_network/consumers/faq.md index 56646a18bf9..665112ea2b6 100644 --- a/docs/subquery_network/consumers/faq.md +++ b/docs/subquery_network/consumers/faq.md @@ -2,8 +2,8 @@ ## As a Consumer, can I select 1 Indexer or multiple Indexers? -Unless a Closed Service Agreement is being used, there will be one or more Indexers indexing a SubQuery project. Consumers have the choice when deciding which Indexer to read data from. Typically Consumers would select the most reliable and lowest latency Indexer. Consumers could also incorporate automatic failover and read data from another Indexer if the first one times out or is not responsive. +Depending on demand, there will often be multiple Indexers indexing an given SubQuery project and multiple RPC providers for each network. Consumers have the choice when deciding which Node Operator to make agreements with. Typically Consumers would select Node Operators from a combination of cost, reliability, and latency. Consumers could also incorporate automatic failover and read data from another Node Operator if the first one times out or is not responsive. -## What happens if a Data Indexer or an RPC Provider goes offline? +## What happens if a Node Operator goes offline? -Unless a Closed Service Agreement is being used, and if there is more than one Data Indexer/RPC provider serving your SubQuery project, it would simply be a matter of switching to another Indexer. The ideal scenario would be include strategies like alert monitoring to be notified of potential issues and intelligent routing and caching. +Unless a Closed Service Agreement is being used, and if there is more than one Data Indexer/RPC provider serving your SubQuery project, it would simply be a matter of switching to another Node Operator. The ideal scenario would be include strategies like alert monitoring to be notified of potential issues and intelligent routing and caching. diff --git a/docs/subquery_network/consumers/introduction.md b/docs/subquery_network/consumers/introduction.md index 47800d7c75d..c45c22b87b4 100644 --- a/docs/subquery_network/consumers/introduction.md +++ b/docs/subquery_network/consumers/introduction.md @@ -2,13 +2,13 @@ :::info -The SubQuery Kepler Network does not yet have the consumer role. Consumers will launch with the SubQuery Mainnet. +The SubQuery Kepler Network does not yet have the Consumer role. Consumers will launch with the SubQuery Mainnet. ::: ## What is a Consumer? -A Consumer is a participant in the SubQuery network and is either an individual or organisation that pays for processed and organised blockchain data from the SubQuery Network. Consumers effectively make requests to the SubQuery Network for specific data or the ability to submit transactions to RPC providers and pay an agreed amount of SQT in return. +A Consumer is a participant in the SubQuery Network and is either an individual or organisation that pays for processed and organised blockchain data and/or RPC queries from the SubQuery Network. Consumers effectively make requests to the SubQuery Network for specific data or the ability to submit transactions to RPC providers and pay an agreed amount of SQT in return. Consumers are typically dApp (decentralised application) developers, data analytic companies, blockchain networks, middleware developers, or even web aggregating companies that need access to blockchain data or performant RPCs to provide services to their end-users. @@ -20,12 +20,13 @@ There are no requirements as such to become a SubQuery Consumer. However, Consum As a Consumer, you can interact with performant RPCs or receive indexed data from the Network for your dApps. Other benefits include: -- Easy access to blockchain data. There is no need to learn about the intricacies of a blockchain. Just get access to the exact data you need to run your applications. -- Focus on developing your appplication, not on time consuming blockchain integration. +- Faster performance for your dApps. Since your dApps an get data from a decentralised network of Node Operators (RPCs or data indexers), the average latency will be lower and performance higher +- Higher reliability. Due to the decentralised nature of the network, your dApp can immediately fall back to an alternative when an RPC provider goes offline. +- Focus on developing your appplication, not on running blockchain infrastructure. - Cost effective. Combining the two points from above, consuming data from SubQuery results in a very cost effective way to power your applications. ## Costs to being a Consumer -The cost of submitting or querying data on the blockchain will be based on supply and demand and will be comparable to other similar centralised and decentralised services currently available. The advantage of an open and transparent network and ecosystem is that competition is encouraged to provide the best service to the Consumer. +The cost of making RPC calls or querying indexed data on the network will be based on supply and demand and ideally will be lower than other similar centralised and decentralised services currently available. The advantage of an open and transparent network and ecosystem is that competition is encouraged to provide the best service to the Consumer. -For flexibility, Consumers have 3 payment options to pay for blockchain data, you can read more about these, how they work, and the advantages/disadvantages on the [Payment Methods article](../design/payment-methods.md). +For flexibility, Consumers have multiple payment options to pay for blockchain data and RPC queries, you can read more about these, how they work, and the advantages/disadvantages on the [Payment Methods article](../design/payment-methods.md). diff --git a/docs/subquery_network/delegators/delegating.md b/docs/subquery_network/delegators/delegating.md index f6c487bef90..47b15fbcdd2 100644 --- a/docs/subquery_network/delegators/delegating.md +++ b/docs/subquery_network/delegators/delegating.md @@ -1,12 +1,18 @@ -# Delegating to an Indexer +# Delegating to a Node Operator + +:::info Kepler + +In Kepler, you can only delegate to Indexers. When mainnet launches we will rename this section to Node Operators + +::: ## How to delegate to an Indexer -After you have [selected what indexer to delegate to](./rewards.md#how-to-select-what-indexers-to-delegate-to), to delegate to an Indexer of your choice, navigate to `Delegator` -> `Indexers`(on the left sidebar). Then select `Delegate` in the last column next to your desired Indexer. +After you have [selected what indexer to delegate to](./rewards.md#how-to-select-what-node-operators-to-delegate-to), to delegate to an Indexer of your choice, navigate to `Delegator` -> `Indexers`(on the left sidebar). Then select `Delegate` in the last column next to your desired Indexer. ![Delegate Indexer List](/assets/img/network/delegate_indexers.png) -Select your source for the delegation (it can be your wallet, or from an existing delegation amoutn) and enter an amount. Click on `Delegate`. You will be asked to confirm your transaction with Metamask. Please wait for a while after confirming the transaction. +Select your source for the delegation (it can be your wallet, or from an existing delegation amount) and enter an amount. Click on `Delegate`. You will be asked to confirm your transaction with Metamask. Please wait for a while after confirming the transaction. ![Delegate to an Indexer part 2](/assets/img/network/delegate_action.png) diff --git a/docs/subquery_network/delegators/introduction.md b/docs/subquery_network/delegators/introduction.md index 54e19d7e4be..991025363a3 100644 --- a/docs/subquery_network/delegators/introduction.md +++ b/docs/subquery_network/delegators/introduction.md @@ -4,7 +4,7 @@ A Delegator is a non-technical network role in the SubQuery Network and is a great way to start participating in the SubQuery Network. This role enables Delegators to “delegate” their SQT to one or more Node Operator (RPC Providers or Data Indexers) and earn rewards (similar to staking). -Without Delegators, Node Operators would likely earn fewer rewards because they will have less SQT to allocate. Therefore, Node Operators compete to attract Delegators by offering a competitive share of an Node Operator's rewards. +Without Delegators, Node Operators would likely earn fewer rewards because they will have less SQT to stake. Therefore, Node Operators compete to attract Delegators by offering a competitive share of an Node Operator's rewards. ## Requirements to be a Delegator @@ -14,17 +14,15 @@ One of the best things about being a Delegator is that you don’t need any devo There are several benefits of becoming a Delegator: -- It's easy to get started and requires little technical knowledge, Delegators only need to acquire SQT tokens and then learn the process of delegating the tokens to their preferred Node Operator(s). -- Delegating contribute to the network and to Node Operators. In return, Delegators are rewarded with SQT. -- Delegators earn rewards by putting their SQT to work by delegating their SQT to Node Operators and earning a share of the reward pool. +- It's easy to get started and requires little technical knowledge, Delegators only need to acquire SQT tokens and then [learn the process of delegating the tokens to their preferred Node Operator(s)](./delegating.md). +- Delegating contribute to the network by putting their SQT to work by delegating their SQT to Node Operators. In return, Delegators are [rewarded with SQT](./rewards.md) (a share of the reward pool). - There is no minimum required delegation to be a Delegator. This means that anyone can join no matter how much SQT one has. ## Risks of being a Delegator Even though it is not considered a risky role, being a Delegator includes a few risks to be aware of. -1. Market volatility risk: The constant fluctuations in the market is a risk that affects not just SQT, but all tokens in the general cryptocurrency marketplace. Taking a long term approach can reduce this type of risk. -2. Constant adjustments of staking parameters by Node Operators and delegation fees can increase the risk to a Delegator. For example, a Delegator might miss a change in staking parameters resulting in a less than expected return. To reduce this risk, when Node Operators decrease their stake parameters, it will only take effect after the next full Era has been completed, giving time for delegators to assess and make any changes. -3. Node Operator poor performance: It is possible that Delegators can select Node Operators that perform poorly and therefore provide a substandard return on investment to Delegators. Delegators are therefore encouraged to do Node Operator due diligence on potential Node Operators. A Reputation Index is also available to help Delegators compare Node Operators to each other. +1. Constant adjustments of staking parameters by Node Operators and delegation fees can increase the risk to a Delegator. For example, a Delegator might miss a change in staking parameters resulting in a less than expected return. To reduce this risk, when Node Operators decrease their stake parameters, it will only take effect after the next full Era has been completed, giving time for delegators to assess and make any changes. +2. Node Operator poor performance: It is possible that Delegators can select Node Operators that perform poorly and therefore provide a substandard return on investment to Delegators. Delegators are therefore encouraged to do Node Operator due diligence on potential Node Operators. A Reputation Index is also available to help Delegators compare Node Operators to each other. Once a preferred Node Operator(s) is found, due diligence should be performed to check an Node Operator’s reputation and reliability. Assessments could be performed to evaluate if the Node Operator is active in the community, if the Node Operator helps other members, if it is possible to get in touch with the Node Operator, and if the Node Operator is up-to-date with protocol and project updates. The aforementioned Reputation Index can also serve as a primary selection indicator. diff --git a/docs/subquery_network/delegators/rewards.md b/docs/subquery_network/delegators/rewards.md index ca9bbc53d63..712a9efe8c0 100644 --- a/docs/subquery_network/delegators/rewards.md +++ b/docs/subquery_network/delegators/rewards.md @@ -6,9 +6,9 @@ To attract Delegators to support their work, Node Operators (Data Indexers or RP :::info Node Operator Commission Rate (NOCR) -_Node Operator's Commission Rate (ICR)_: This is a percentage share of the rewards received by Node Operators from serving requests to Consumers. After deducting the ICR from total rewards, the remaining rewards will be shared within the total delegation/staking pool proportionally to the individual delegated/staked value in the pool. +_Node Operator's Commission Rate (NOCR)_: This is a percentage share of the rewards received by Node Operators from serving requests to Consumers. After deducting the NOCR from total rewards, the remaining rewards will be shared within the total delegation/staking pool proportionally to the individual delegated/staked value in the pool. -Node Operators are free to set this rate to any value they desire. A higher NOCR indicates that Node Operators keep more of the rewards. A lower ICR indicates that the Node Operators share more of their rewards with their Delegators. +Node Operators are free to set this rate to any value they desire. A higher NOCR indicates that Node Operators keep more of the rewards. A lower NOCR indicates that the Node Operators share more of their rewards with their Delegators. ::: @@ -16,6 +16,8 @@ Delegators will only receive revenue for staking Eras that they were a part of f If an Node Operator wishes to increase the Node Operator Commission Rate that they offer to their Delegators, they must advertise this for an entire staking Era. The Node Operator will be able to decrease their Node Operator Commission Rate at any point to raise more delegated SQT for staking in the short term. Delegators can withdraw or undelegate their staked amount at any time, but they will forfeit any rewards earned within the staking Era (as they were not part of the delegation pool for the entire duration of the staking Era). +![Token economic flow](/assets/img/network/token_economy.png) + ## How to select what Node Operators to delegate to You need to assess a few things when deciding on what Node Operator to choose. @@ -32,9 +34,9 @@ For Data Indexers, we've made it easier for you to see other data about all Data Besides the period when Delegators can effectively earn money, a non-reward period also occurs. Delegators receive rewards for staking Eras that they were a part of for the entire duration. For example, if a Delegator joins a staking era halfway through, they will not earn any rewards for that particular era. -Delegators can change the Node Operator that their SQT is delegated to (called redelegating), this change will be queued to happen automatically at the end of the Era and no thawing period will occur. +Delegators can change the Node Operator that their SQT is delegated to (called redelegating), this change will be queued to happen automatically at the end of the Era and no lock period will occur. -If a Delegator decides to undelegate their SQT, a 28 day thawing period starts. The tokens cannot be used during this period, no fees can be accrued or any reward gained. +If a Delegator decides to undelegate their SQT, a 28 day lock period starts. The tokens cannot be used during this period, no fees can be accrued, and no rewards will be gained. ## Delegation Lifecycle diff --git a/docs/subquery_network/introduction.md b/docs/subquery_network/introduction.md index fefa151b83f..5d0db154b35 100644 --- a/docs/subquery_network/introduction.md +++ b/docs/subquery_network/introduction.md @@ -1,11 +1,17 @@ # Introduction -**The SubQuery Network is the future of web3 infrastructure** +**_Decentralisation without Compromise - the SubQuery Network is the future of web3 infrastructure_** -We’re building the most open, performant, reliable, and scalable data service for dApp developers. The SubQuery Network indexes and services data to the global community in an incentivised and verifiable way. After publishing your project to the SubQuery Network, anyone can index and host it - providing data to users around the world faster and reliably. +We not just simply indexing web3 data, we're pioneering a complete web3 infrastructure revolution. Web3 middleware services like indexers and RPC providers are pivotal in blockchain dApp development, but there is a hidden truth behind the mask of _“decentralisation”_ most of these middleware services wear. The reality is a significant reliance on centralised middleware components, which poses a substantial threat to the envisioned unstoppability of a web3 future. + +We need to decentralise these services, without compromise. We’ve already delivered breakthroughs in decentralised data indexing, but our next steps will focus on enhancing the performance of RPCs with the SubQuery Data Node, and then to bring RPCs to the masses, with SubQuery’s Sharded Data Nodes. These steps together, will help unlock the next level of performance increases in web3. + +We’re building the most open, performant, reliable, and scalable web3 infrastructure service for dApp developers. The SubQuery Network indexes and services data to the global community in an incentivised and verifiable way. The SubQuery Network is facilitating an open web3 data revolution by allowing you to completely decentralise your infrastructure stack. +![The vision for SubQuery Network to encompass key web3 infrastructure components in a completely decentralised manner](/assets/img/network/technical_stack.png) + There’s a role for everyone in the network, from highly technical developers to those that are not. The SubQuery network includes four main network participants. **Consumers** will ask the SubQuery Network for specific data for their dApps or tools, and pay an advertised amount of SQT for each request. Learn more about [Consumers](./consumers/introduction.md). @@ -16,9 +22,11 @@ There’s a role for everyone in the network, from highly technical developers t **Delegators** will participate in the Network by supporting their favourite Node Operators to earn rewards based on the work those Node Operators do. Learn more about [Delegators](./delegators/introduction.md). +![Token economic flow](/assets/img/network/token_economy.png) + ## SubQuery Kepler Network -SubQuery’s mission is to help developers create the decentralised products of the future. In order to realise this, we are focused on the release of the [decentralised SubQuery Network](https://subquery.network/network). The final phase before launching the SubQuery Network is deploying the Kepler Network. +SubQuery’s mission is to help developers create the decentralised products of the future. In order to realise this, we are focused on the release of the [decentralised SubQuery Network](https://subquery.network/network). The final phase before launching the SubQuery Network was deploying the Kepler Network. :::note @@ -26,9 +34,9 @@ SubQuery’s mission is to help developers create the decentralised products of ::: -### Why Are We Launching Kepler? +### Why Did We Launching Kepler? -You can think of Kepler as a pre-mainnet, a controlled phase that will help us bootstrap the mainnet with participants and activity. +You can think of Kepler as a pre-mainnet, a controlled phase that helped us bootstrap the mainnet with participants and activity. In order to launch our decentralised network (The SubQuery Network), there are several technical milestones that must be met. The first significant milestone was achieved in 2022, with three successful ‘seasons’ (or phases) of our Frontier testnet which stress-tested the network in a test environment. After taking these learnings, we elected to take a novel approach by allowing participants in our testnet to get started on real world projects now via Kepler rather than waiting for the launching of our token. diff --git a/docs/subquery_network/node_operators/introduction.md b/docs/subquery_network/node_operators/introduction.md index 516a4a07285..88f4d93b559 100644 --- a/docs/subquery_network/node_operators/introduction.md +++ b/docs/subquery_network/node_operators/introduction.md @@ -1,3 +1,11 @@ -## Node Operators +## Node Operators / Indexers -SubQuery has a commitment to expanding the SubQuery Network to decentralise both Data Indexers, as well as supercharging RPCs to address a much broader centralisation issue throughout Web3 infrastructure. The SubQuery network will see thousands of decentralised Indexers and RPC providers simplify the data layer for a myriad of applications and use cases. +:::info SubQuey Kepler Network + +The SubQuery Kepler network only has the concept of Data Indexers. RPC Providers will launch with the mainnet. + +::: + +SubQuery has a commitment to expanding the SubQuery Network to decentralise both Data Indexers, as well as supercharging RPCs to address a much broader centralisation issue throughout Web3 infrastructure. The SubQuery network will see thousands of decentralised Indexers and RPC providers (together called Node Operators) simplify the data layer for a myriad of applications and use cases. + +![The vision for SubQuery Network to encompass key web3 infrastructure components in a completely decentralised manner](/assets/img/network/technical_stack.png) diff --git a/docs/subquery_network/token/token.md b/docs/subquery_network/token/token.md index 6c2bdff6774..5c6f78084dc 100644 --- a/docs/subquery_network/token/token.md +++ b/docs/subquery_network/token/token.md @@ -8,6 +8,8 @@ The network is designed to provide value where Node Operators can index, aggrega There is no intention for SQT to be used as a medium of exchange for goods or services outside of the SubQuery Network. SQT does not in any way represent or confer upon its holders any right to, title of, interest or participation in, the ownership, shareholding and/or management of SubQuery whatsoever. SQT will not entitle holders to any promise of fees, dividends, revenue, profits, or investment returns. +![Token economic flow](/assets/img/network/token_economy.png) + ## KSQT kSQT is the name of the token that is used by participants who operate within the Kepler Network. This token mimics the properties of the eventual SubQuery Network token (SQT) in that tokens will be rewarded to Node Operators for performing tasks and Delegators can allocate their tokens to Node Operators to secure the network and receive rewards.