Add sections about reward distribution and Eras

docs/.vuepress/config.ts

@@ -216,6 +216,10 @@ export default defineUserConfig({
         include: {
           deep: true,
         },
+        // Enable Subscript
+        sub: true,
+        // Enable  Superscript
+        sup: true,
       },
 
       pwa: {

docs/.vuepress/sidebar.ts

@@ -516,7 +516,9 @@ export const getSidebar = (locale: string) =>
           collapsible: true,
           children: [
             `${locale}/subquery_network/design/design-philosophy.md`,
+            `${locale}/subquery_network/design/era.md`,
             `${locale}/subquery_network/design/payment-methods.md`,
+            `${locale}/subquery_network/design/reward-distribution.md`,
           ],
         },
         {

docs/subquery_network/delegators/introduction.md

@@ -22,7 +22,7 @@ There are several benefits of becoming a Delegator:
 
 Even though it is not considered a risky role, being a Delegator includes a few risks to be aware of.
 
-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.
+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](../design/era.md) 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.

docs/subquery_network/delegators/rewards.md

@@ -12,9 +12,9 @@ Node Operators are free to set this rate to any value they desire. A higher NOCR
 
 :::
 
-Delegators will only receive revenue for staking Eras that they were a part of for the entire period. For example, if they join a staking Era in the middle of the relevant period, then they will not earn any Query Fee revenue for that particular Era.
+Delegators will only receive revenue for staking [Eras](../design/era.md) that they were a part of for the entire period. For example, if they join a staking Era in the middle of the relevant period, then they will not earn any Query Fee revenue for that particular Era.
 
-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).
+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](../design/era.md). 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)
 
@@ -26,13 +26,13 @@ Node Operators set an Node Operator’s Commission Rate (NOCR) which is the perc
 
 For example, Node Operator A has set an NOCR of 80% and has received SQT from 8 Delegators. This means that the 8 Delegators plus the Node Operator itself, will be rewarded a share of the remaining 20% of what the Node Operator has earned. The share will be split proportionally between them based on the amount staked/delegated. Alternatively, if Node Operator A had an NOCR of 30%, then the 8 delegators and Node Operator would share proportionally rewards from the remaining 70% of rewards. In short, the lower the NOCR - the better it is for Delegators.
 
-Note that Delegators must have delegated their tokens for the entire Era to be eligible for these rewards (note [Non-reward period](#non-reward-period)).
+Note that Delegators must have delegated their tokens for the entire [Era](../design/era.md) to be eligible for these rewards (note [Non-reward period](#non-reward-period)).
 
 For Data Indexers, we've made it easier for you to see other data about all Data Indexers in our app. Navigate to `Delegator` > `Indexers` and view the [leaderboard](https://kepler.subquery.network/delegator/node_operators/indexers/top) which shows various scores and details that we think are important to you when deciding what Data Indexer to choose. The Data Indexers Score takes into account an Data Indexer’s uptime, slashing events, and other parameters.
 
 ## Non-reward period
 
-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.
+Besides the period when Delegators can effectively earn money, a non-reward period also occurs. Delegators receive rewards for staking [Eras](../design/era.md) 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 lock period will occur.
 

docs/subquery_network/design/design-philosophy.md

@@ -42,7 +42,7 @@ It additionally provides several advanced subscription based options for Consume
 
 ## Node Operator/Delegator Imbalance
 
-Among some competitors, it is observed that there is a serious imbalance between Node Operators and Delegators in terms of the ability to change delegation rates without warning. SubQuery has tried to equalise this imbalance by requiring that the Node Operator advertise an increase to the Node Operator Commission Rate for an entire staking Era. Delegators are also free to withdraw their delegated tokens at any point during the staking Era, but they will lose any rewards that they could have been eligible for during that Era.
+Among some competitors, it is observed that there is a serious imbalance between Node Operators and Delegators in terms of the ability to change delegation rates without warning. SubQuery has tried to equalise this imbalance by requiring that the Node Operator advertise an increase to the Node Operator Commission Rate for an entire staking [Era](./era.md). Delegators are also free to withdraw their delegated tokens at any point during the staking Era, but they will lose any rewards that they could have been eligible for during that Era.
 
 ## Incentives for Query Performance
 

docs/subquery_network/design/era.md

@@ -0,0 +1,10 @@
+# The Era
+
+The SubQuery Network is oriented around a single constant heartbeat or period - this is called the **Era**.
+
+Currently the Era is 7 days (earth time). The Era represents a period that many settings and actions within the SubQuery Network are orientated around including:
+
+- Network reward allocations are made at the end of an Era
+- The length of Plans are represented in a number of Era
+- Any re-staging or re-delegation actions will be queued up for the end of the Era
+- Changes to the Node Operator Commission Rate (NOCR) will be queued up for the end of the Era (or the subsequent Era in some cases)

docs/subquery_network/design/payment-methods.md

@@ -1,16 +1,12 @@
 # Payment Methods
 
-For flexibility, there are 3 payment options to pay for blockchain data. They are:
-
-- Pay-As-You-Go (PAYG).
-- Closed Service Agreement.
-- Open Service Agreement.
+Three different payment methods are planned for the SubQuery Network, this provides all participants with various flexible ways to transact SQT. Both Node Operators and Consumers will come together on the Plan Marketplace to advertise their pricing and supported payment methods.
 
 ## Flex Plans (Pay-As-You-Go / PAYG)
 
-This is the baseline payment method and a fallback for others. Each Node Operator will advertise their PAYG prices when registering their ability to serve requests for specific SubQuery projects.
+The first, and a standard amongst the web3 industry, is pay-as-you-go (we call it Flex Plans). This is the baseline payment method and a fallback for others. Each Node Operator will advertise their PAYG prices when registering their ability to serve requests for specific SubQuery projects or RPC endpoint.
 
-Consumers making requests will have to lock the tokens necessary to make that request in a state channel, and at the end of an Era, these tokens will be distributed to the Node Operators based on the Cobb-Douglas production function.
+Consumers making requests will have to lock the tokens necessary to make that request in a state channel, and at the end of an [Era](./era.md), these tokens will be distributed to the Node Operators based on the [Cobb-Douglas production function](./reward-distribution.md).
 
 ## Closed Plans and Agreements
 
@@ -24,10 +20,25 @@ Closed Plans can also be placed on existing SubQuery Projects to attract additio
 
 Open Market Service Agreements are similar to Closed Market Service Agreements, but allow multiple Node Operators to join and compete to provide data to the Consumer. An Open Market Service Agreement may start as a contract between 1 Consumer and 1 Node Operator, but more parties may join the contract resulting in _n_ Consumers and _n_ Node Operators.
 
-Each Open Market Service Agreement results in a new reward pool being created for that contract, and SQT is distributed amongst participating Node Operators by the Cobb-Douglas production function.
+Each Open Market Service Agreement results in a new reward pool being created for that contract, and SQT is distributed amongst participating Node Operators by the [Cobb-Douglas production function](./reward-distribution.md#cobb-douglas-production-function).
 
 Open Agreements provide favourable terms for both Node Operators and Consumers, but enable better performance and reliability for Consumers by attracting more Node Operators to compete and serve the same data. If Consumers are running large scale applications with users around the world, then Open Agreements are ideal.
 
+## Comparison of Payment Methods
+
+SubQuery is intended to function as a marketplace where both Consumers and Node Operators can meet to exchange data for SQT tokens. However, there are a lot of up-front costs that an Node Operators must incur before they are able to sell data from a new SubQuery Project or act as an RPC provider.
+
+Closed and Open Agreements are designed to give Node Operators confidence that there is a market for data from a particular SubQuery Project or network, and essentially signal to them which Indexer Projects or RPC endpoints should be indexed. Plans can also be placed on existing Indexer Projects or RPC endpoints to attract additional Node Operators to that Indexer Projects or RPC endpoints. This may be useful in situations where the existing monopolistic Node Operator may be charging an unreasonable amount for the data or there is a lack of competition to drive prices to equilibrium.
+
+When a Consumer exceeds the limitations of the Open or Closed Agreement that they have in place, then all subsequent requests that do not come under the Open or Closed Agreement’s terms may automatically occur under a Flex Plan. This can be used to prevent service interruptions after usage exceeds the prescribed daily limit.
+
+| Comparison                                 | Pay as you Go     | Open Agreement    | Closed Agreement |
+| ------------------------------------------ | ----------------- | ----------------- | ---------------- |
+| **Favours who?**                           | Both              | Indexers          | Consumers        |
+| **Reward Distribution**                    | Cobb-Douglas Pool | Cobb-Douglas Pool | Direct           |
+| **Number of Node Operators per agreement** | >=1               | >=1               | 1                |
+| **Number of Consumers per agreement**      | >=1               | >=1               | 1                |
+
 ## SubQuery’s Innovation in Payment Methods
 
 Today, we generally pay with subscription-based payments for the music we listen to, the TV shows we watch, and the applications that we use. In pioneering web3 service applications, we’ve instead adopted a pay-as-you-go model, where each atomic transaction has an exact cost in the network.

docs/subquery_network/design/reward-distribution.md

@@ -0,0 +1,29 @@
+# How Rewards are Distributed
+
+In order to earn rewards from query revenue as a Node Operator, Node Operators must stake SQT against a particular SubQuery Project or RPC endpoint that they are providing the service to. The Cobb-Douglas production function will be used to determine the rewards distributed to each Node Operator.
+
+There may be multiple reward pools simultaneously active for a given Node Operator. The Node Operator's job is to allocate their staked and delegated SQT amongst these pools (in terms of a percentage of their total SQT). There will be a reward pool for each data indexer project or RPC endpoint that the Node Operator accepts [Flex Plans](./payment-methods.md#flex-plans-pay-as-you-go--payg), and a reward pool for each Market Agreement that the Node Operator is a party of. For a [Closed Agreement](./payment-methods.md#closed-plans-and-agreements), the Cobb-Douglas production is not used to allocate rewards to Node Operators.
+
+![Reward Pools](/assets/img/network/reward_pools.png)
+
+## Cobb-Douglas Production Function
+
+![Cobb Douglas production Function](/assets/img/network/cobb_douglas.png)
+
+The query fee revenue that Node Operator (**_i_** ) can receive for the reward pool (**_p_**) is defined by the Cobb-Douglas production function. Where **_Reward~p~_** is the total SQT in the reward pool **_p_**, **_σ~ip~_** is the number of requests provided by Node Operator **_i_** for the reward pool **_p_**, **_σ~p~_** is the number of requests for reward pool **_p_**, **_θ~ip~_** is the staked amount for Node Operator **_i_** for reward pool **_p_**, **_θ~p~_** the total staked amount for the reward pool **_p_** across all participating Node Operators. **_α_** is a constant that changes the weight of these two parameters and how they affect total rewards.
+
+This approach was championed by the 0x team, and in simple terms, means that revenue is allocated to competing Node Operators as a proportion of both requests answered and revenues staked.
+
+## Minimum Staking Requirements
+
+The beauty of the Cobb Douglas equation (above) is that a rational Node Operator must maintain a stable level of staked SQT relative to the work they do in order in each reward pool in order to receive optimal revenue. As a result, the SubQuery Network does not need to enforce arbitrary staking requirements because Node Operators are incentivised to self-manage and maintain a stake or skin in the game.
+
+SubQuery does require Node Operator must stake a minimum amount of SQT on the relevant reward pool to be able to participate in its matching Open Agreement. They must also stake a minimum amount on an equivalent staking contract for any Closed Agreements in the same fashion. This Node Operator staked minimum value must be a certain percentage of the Agreement's per Era reward value, which means in order to renew the Agreement to higher volumes, the Node Operator must also increase their stake. When an Node Operator's stake decreases beneath this minimum amount, they will be unable to renew the Agreement at the existing price.
+
+:::warning
+
+Delegated SQT to a Node Operator do not count towards the Node Operators minimum staking requirements
+
+:::
+
+If an Node Operator is caught misbehaving (such as by providing invalid, incomplete, or incorrect data), they are liable to have a portion of their staked SQT (on the particular reward pool ip) reallocated to the SubQuery Foundation Treasury, diminishing their holdings of staked SQT in the network and therefore their potential reward. Since the Node Operator's allocated stake is determined by a percentage of their total SQT, this will have a flow on effect to all other reward pools that the Node Operator is party to.

docs/subquery_network/introduction.md

@@ -10,6 +10,8 @@ We’re building the most open, performant, reliable, and scalable web3 infrastr
 
 The SubQuery Network is facilitating an open web3 data revolution by allowing you to completely decentralise your infrastructure stack.
 
+_SubQuery will aim to power the future plethora of serverless applications in different blockchain ecosystems and accelerate our transition to a decentralised future._
+
 ![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.