diff --git a/docs/.vuepress/config.ts b/docs/.vuepress/config.ts index 8f7d27b6b93..78515a0384d 100644 --- a/docs/.vuepress/config.ts +++ b/docs/.vuepress/config.ts @@ -216,6 +216,10 @@ export default defineUserConfig({ include: { deep: true, }, + // Enable Subscript + sub: true, + // Enable Superscript + sup: true, }, pwa: { diff --git a/docs/.vuepress/public/assets/img/network/cobb_douglas.png b/docs/.vuepress/public/assets/img/network/cobb_douglas.png new file mode 100644 index 00000000000..4d527fff68a Binary files /dev/null and b/docs/.vuepress/public/assets/img/network/cobb_douglas.png differ diff --git a/docs/.vuepress/public/assets/img/network/reward_pools.png b/docs/.vuepress/public/assets/img/network/reward_pools.png new file mode 100644 index 00000000000..b87cf8d2a20 Binary files /dev/null and b/docs/.vuepress/public/assets/img/network/reward_pools.png differ diff --git a/docs/.vuepress/sidebar.ts b/docs/.vuepress/sidebar.ts index 0079ff9d2ff..e26fc99ec7b 100644 --- a/docs/.vuepress/sidebar.ts +++ b/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`, ], }, { diff --git a/docs/subquery_network/delegators/introduction.md b/docs/subquery_network/delegators/introduction.md index 991025363a3..ae0693736d5 100644 --- a/docs/subquery_network/delegators/introduction.md +++ b/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. diff --git a/docs/subquery_network/delegators/rewards.md b/docs/subquery_network/delegators/rewards.md index 712a9efe8c0..f42a03fec81 100644 --- a/docs/subquery_network/delegators/rewards.md +++ b/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. diff --git a/docs/subquery_network/design/design-philosophy.md b/docs/subquery_network/design/design-philosophy.md index 668bbeaffbc..6d184d780f2 100644 --- a/docs/subquery_network/design/design-philosophy.md +++ b/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 diff --git a/docs/subquery_network/design/era.md b/docs/subquery_network/design/era.md new file mode 100644 index 00000000000..095d680250a --- /dev/null +++ b/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) diff --git a/docs/subquery_network/design/payment-methods.md b/docs/subquery_network/design/payment-methods.md index 18fae80ade1..e7438ae19c3 100644 --- a/docs/subquery_network/design/payment-methods.md +++ b/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. diff --git a/docs/subquery_network/design/reward-distribution.md b/docs/subquery_network/design/reward-distribution.md new file mode 100644 index 00000000000..39e3e08c2c9 --- /dev/null +++ b/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. diff --git a/docs/subquery_network/introduction.md b/docs/subquery_network/introduction.md index 5d0db154b35..014cc71e726 100644 --- a/docs/subquery_network/introduction.md +++ b/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. diff --git a/docs/subquery_network/node_operators/indexers/become-an-indexer.md b/docs/subquery_network/node_operators/indexers/become-an-indexer.md index 35ba71fffc7..c7c06d0bd6f 100644 --- a/docs/subquery_network/node_operators/indexers/become-an-indexer.md +++ b/docs/subquery_network/node_operators/indexers/become-an-indexer.md @@ -21,7 +21,7 @@ Welcome to this guide on how to become an Indexer. Let's take an overview of the In the first phase of Kepler, Indexers will be Sponsored by the SubQuery Council to run common good sponsored projects. These will be run using standardised plans so that the SubQuery Council can easily create agreements with each Indexer and sponsor them in bulk. -- All plans will be orientated around the length of an Era, which is currently one week but may be increased to a fortnight (two weeks). +- All plans will be orientated around the length of an [Era](../../design/era.md), which is currently one week. - Indexers should only index from a list of standardised projects that will be listed [here](./index-project.md#2-add-a-project). You won't be rewarded for indexing any projects that are not on this list. - Towards the end of each era, we will release the suggested plan templates, recommended pricing, and other instructions for the start of the next period. You can create plans under [step 5](#5-create-a-plan-from-a-plan-template). These will be shared on [Discord](https://discord.com/invite/subquery) in `kepler-indexer-chat` - We use the [Indexer Excellency programme](https://kepler.subquery.network/delegator/indexers/top) to rank Indexers and plans will be allocated to Indexers with a higher score. In order to maximise your rewards, we suggest trying to maximise your score in this programme (you can hover over the column header to see how each score is calculated). @@ -74,7 +74,7 @@ This will overwrite the existing docker-compose.yml file. Always use the latest | Service | Version Tag | | :-------------------------------------------------------------------------------------------------- | :---------- | -| [subquerynetwork/indexer-coordinator](https://hub.docker.com/r/subquerynetwork/indexer-coordinator) | `v1.4.10` | +| [subquerynetwork/indexer-coordinator](https://hub.docker.com/r/subquerynetwork/indexer-coordinator) | `v1.4.10` | | [subquerynetwork/indexer-proxy](https://hub.docker.com/r/subquerynetwork/indexer-proxy) | `v1.3.9` | ::: warning Important @@ -184,7 +184,7 @@ Enter a new value (in a percent) and submit via Metamask. ![Changing your ICR](/assets/img/network/indexer_icr_change.png) -Changes will come into effect at the start of the next Era. +Changes will come into effect at the start of the next [Era](../../design/era.md). ## Additional Notes diff --git a/docs/subquery_network/node_operators/indexers/plans.md b/docs/subquery_network/node_operators/indexers/plans.md index c04285b0454..665482ca0f2 100644 --- a/docs/subquery_network/node_operators/indexers/plans.md +++ b/docs/subquery_network/node_operators/indexers/plans.md @@ -4,7 +4,7 @@ For the initial stages of Kepler, the SubQuery Council will recommend various pl ## Creating a Fixed Price Plan -All plans will be orientated around the length of an Era, which is currently one week but may be increased to a fortnight (two weeks). Towards the end of each era, we will release the suggested plan templates, recommended pricing, an and other instructions for the start of the next period. +All plans will be orientated around the length of an [Era](../../design/era.md), which is currently one week. Towards the end of each era, we will release the suggested plan templates, recommended pricing, an and other instructions for the start of the next period. **We strongly recommend not exceeding our recommended pricing when setting your price, otherwise you might not be picked for the next era** diff --git a/docs/subquery_network/node_operators/indexers/rewards.md b/docs/subquery_network/node_operators/indexers/rewards.md index f805411ef38..877b96d6413 100644 --- a/docs/subquery_network/node_operators/indexers/rewards.md +++ b/docs/subquery_network/node_operators/indexers/rewards.md @@ -4,7 +4,7 @@ Indexers are rewarded in SQT in two ways: -- Rewards from SQT reward pools based on distribution defined by the Cobb-Douglas Production Function. +- Rewards from SQT reward pools based on distribution defined by the [Cobb-Douglas Production Function](../../design/reward-distribution.md). - Direct SQT query fee rewards from Closed Agreements that an indexer is party to. Indexers are rewarded the fees that Consumers pay for providing blockchain data that the Consumer has reqested. An Indexer will receive all the fees from a Closed Agreement. Otherwise, the fees are split based on the amount of work performed (requests served) and the amount of delegated SQT - this split is determined by applying the Cobb-Douglas Production Function. @@ -13,9 +13,9 @@ There may be multiple reward pools simultaneously active for a given Indexer. Th ## Indexer Staking -In order to earn rewards from query revenue as an Indexer it is proposed that Indexers must stake SQT against a particular SubQuery Project that they are providing the service to. The Cobb-Douglas production function will be used to determine the rewards distributed to each Indexer. +In order to earn rewards from query revenue as an Indexer it is proposed that Indexers must stake SQT against a particular SubQuery Project that they are providing the service to. The [Cobb-Douglas production function](../../design/reward-distribution.md#cobb-douglas-production-function) will be used to determine the rewards distributed to each Indexer. -SubQuery plans to add a constraint to the network where an indexer 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 indexer 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 indexer must also increase their stake. When an indexer’s stake decreases beneath this minimum amount, they will be unable to renew the Agreement at the existing price. +SubQuery plans to add a constraint to the network where an indexer 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 indexer staked minimum value must be a certain percentage of the Agreement’s per [Era](../../design/era.md) reward value, which means in order to renew the Agreement to higher volumes, the indexer must also increase their stake. When an indexer’s stake decreases beneath this minimum amount, they will be unable to renew the Agreement at the existing price. If an Indexer 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 indexer’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 indexer is party to. @@ -37,7 +37,7 @@ You should read more about how Delegators will pick Indexers [here](../../delega The main two aspects of how Delegators will pick indexers is the [Indexer Score from the Indexer Leaderboard](https://kepler.subquery.network/delegator/indexers/top), and the Indexer Commission Rate (ICR). The Indexer’s Commission Rate (ICR) is the percentage Indexers earn. The remaining is then shared amongst the Indexer and all Delegators propotionally by staked/delegated amount. Therefore, Indexers need to decide on the proportion of rewards an Indexer wishes to retain versus the amount to share with their Delegators. A lower ICR will be more attractive for Delegators. -You can [change this rate at any time](./become-an-indexer.md#6-configure-an-indexer-commission-rate-icr), it takes about two era for the new value to take effect. +You can [change this rate at any time](./become-an-indexer.md#6-configure-an-indexer-commission-rate-icr), it takes an entire [Era](../../design/era.md) for the new value to take effect. ## Security & Performance considerations @@ -102,7 +102,7 @@ Indexers are highly encouraged to provide a communication method for its custome ## Claiming Rewards from a Plan Agreement -Note, you need to wait for the Era completes before the rewards can be claimed. So if you receive rewards during Era 1, you can only claim them after Era 2 starts. This gives consumers sufficient time to lodge any disputes. +Note, you need to wait for the [Era](../../design/era.md) completes before the rewards can be claimed. So if you receive rewards during Era 1, you can only claim them after Era 2 starts. This gives consumers sufficient time to lodge any disputes. To claim your rewards, head to `Rewards` under your profile. Then click `Claim`.