diff --git a/CODE_OF_CODUCT.md b/CODE_OF_CONDUCT.md similarity index 100% rename from CODE_OF_CODUCT.md rename to CODE_OF_CONDUCT.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f043049e3d..bd1593b980 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -29,7 +29,7 @@ All types of contributions are encouraged and valued. See the [Table of Contents ## Code of Conduct This project and everyone participating in it is governed by the -[Lava Code of Conduct](https://github.com/lavanet/lava/blob/main/CODE_OF_CODUCT.md). +[Lava Code of Conduct](https://github.com/lavanet/lava/blob/main/CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to <>. diff --git a/x/conflict/README.md b/x/conflict/README.md index ff44f151dc..41a533fbc7 100644 --- a/x/conflict/README.md +++ b/x/conflict/README.md @@ -71,7 +71,7 @@ Providers in the jury that did not vote are punished by jail and slashing, their For the conflict resolution there needs to be a majority met of votes for Provider A, Provider B or None of them. If a majority was not met, conflict reward pool is given to the consumer that reported the conflict. Once a majority is met providers that voted to the wrong side of the conflict are slashed and frozen, the slashed amount is added to the conflict reward pool. -Now the reward pool is distributed between the comsumer and the providers that voted for the correct provider. +Now the reward pool is distributed between the consumer and the providers that voted for the correct provider. ## Parameters @@ -122,8 +122,8 @@ The conflict module has the following events: | ---------- | --------------- | | `response_conflict_detection` | A new conflict has been opened, which involves all of the jury providers. It is now entering the commit stage | | `conflict_vote_reveal_started` | conflict has transitioned to reveal state | -| `conflict_vote_got_commit` | provider commited his vote | +| `conflict_vote_got_commit` | provider committed his vote | | `conflict_vote_got_reveal` | provider revealed his vote | | `conflict_unstake_fraud_voter` | provider was unstaked due to conflict | -| `conflict_detection_vote_resolved` | conflict was succesfully resolved | +| `conflict_detection_vote_resolved` | conflict was successfully resolved | | `conflict_detection_vote_unresolved` | conflict was not resolved (did not reach majority) | diff --git a/x/pairing/README.md b/x/pairing/README.md index d884d67091..593aaad6b4 100644 --- a/x/pairing/README.md +++ b/x/pairing/README.md @@ -4,7 +4,7 @@ This document specifies the pairing module of Lava Protocol. -The pairing module is responsible for handling providers staking, providers freezing, calulating the providers pairing list for consumers, punishing unresponsive providers and handling providers relay payment requests. +The pairing module is responsible for handling providers staking, providers freezing, calculating the providers pairing list for consumers, punishing unresponsive providers and handling providers relay payment requests. The Pairing Engine is a sophisticated algorithmic mechanism designed to match consumers with the most appropriate service providers, considering a wide array of inputs and constraints. It upholds the network's principles of fairness, security, and quality of service, while ensuring each consumer's experience is personalized and in line with their specific requirements. diff --git a/x/rewards/README.md b/x/rewards/README.md index 72f717f9b8..c47ef9375e 100644 --- a/x/rewards/README.md +++ b/x/rewards/README.md @@ -39,7 +39,7 @@ The rewards module is responsible on distributing rewards for validators that cr To manage the rewards, the module uses two rewards pools: allocation pools and distribution pools. Note that there are two allocation pools and two distribution pools to manage the validators and providers rewards independently. -The allocation pools get some of the treasury account's tokens and hold onto it. Once a month, the allocation pools transfer a fixed amount of funds to the distribution pools. This monthly transfer will last for 4 years, after which the alocation pools' funds will be depleted (the allocation pools lifetime (4 years) is a pre-defined constant in the module's code). Note that before the allocation pools transfer the funds, the distribution pools' tokens are burned according to the `LeftOverBurnRate` parameter (see [below](#leftoverburnrate)). +The allocation pools get some of the treasury account's tokens and hold onto it. Once a month, the allocation pools transfer a fixed amount of funds to the distribution pools. This monthly transfer will last for 4 years, after which the allocation pools' funds will be depleted (the allocation pools lifetime (4 years) is a pre-defined constant in the module's code). Note that before the allocation pools transfer the funds, the distribution pools' tokens are burned according to the `LeftOverBurnRate` parameter (see [below](#leftoverburnrate)). The distribution pools use the monthly quota of funds to distribute rewards for validators and providers. @@ -82,7 +82,7 @@ Where: * SpecStake = Total effective stake of providers in this spec. * SpecShares = Weight factor for the spec (determined in each spec) -The total spec payout is distributed between providers proportional to the rewards they collected from subscriptions throughtout the month. Each provider will get bonus rewards according to the following formula: +The total spec payout is distributed between providers proportional to the rewards they collected from subscriptions throughout the month. Each provider will get bonus rewards according to the following formula: ```math Provider Bonus Rewards = Total Spec Payout \cdot \frac{\sum_{\text{payment} \; i} (\text{{provider base rewards}}_{i,j} \times \text{{adjustment}}_{i,j})}{\sum_{\text{provider}\;j'}\sum_{\text{payment} \; i} (\text{{provider base rewards}}_{i,j'} )} diff --git a/x/spec/README.md b/x/spec/README.md index f7a3f7c527..6f43a1f00d 100644 --- a/x/spec/README.md +++ b/x/spec/README.md @@ -46,8 +46,8 @@ type Spec struct { ProvidersTypes Spec_ProvidersTypes // determines if the spec is for lava or chains Imports []string // list of chains to import ApiCollections from ApiCollections []*ApiCollection // list of ApiCollections that defines all the interfaces and APIs of the chain - Contributor []string // list of contributers (public lava address {lava@...}) - ContributorPercentage *Dec // the percentage of coins the contributers will get from each reward a provider get + Contributor []string // list of contributors (public lava address {lava@...}) + ContributorPercentage *Dec // the percentage of coins the contributors will get from each reward a provider get Shares uint64 // factor for bonus rewards at the end of the month (see rewards module) AllowedBlockLagForQosSync int64 // defines the accepted blocks a provider can be behind the chain without QOS degradation BlockLastUpdated uint64 // the last block this spec was updated on chain @@ -102,7 +102,7 @@ The `AddOn` field lets you use additional optional APIs like debug, trace etc. ### Extension -this field defines an extansion for the api collection. +this field defines an extension for the api collection. ```go type Extension struct { @@ -207,7 +207,7 @@ type ParseDirective struct { ``` const ( FUNCTION_TAG_GET_BLOCKNUM FUNCTION_TAG = 1 // get latest block number - FUNCTION_TAG_GET_BLOCK_BY_NUM FUNCTION_TAG = 2 // get a specific block by block numer + FUNCTION_TAG_GET_BLOCK_BY_NUM FUNCTION_TAG = 2 // get a specific block by block number FUNCTION_TAG_SET_LATEST_IN_METADATA FUNCTION_TAG = 3 FUNCTION_TAG_SET_LATEST_IN_BODY FUNCTION_TAG = 4 FUNCTION_TAG_VERIFICATION FUNCTION_TAG = 5 @@ -229,7 +229,7 @@ type Verification struct { ### Headers -Thie struct defines for the provider what action to take on the headers of the relayed message. +This struct defines for the provider what action to take on the headers of the relayed message. ```go type Header struct {