fix: minor typos in the docs

docs/data-providers/running-oracle-node.md

@@ -40,15 +40,15 @@ The table below contains the main environment variables required for running a n
 | Param | Description | Example value |
 |------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------|
 | ECDSA_PRIVATE_KEY | Your ECDSA private key | `ECDSA_PRIVATE_KEY=0x123...` |
-| OVERRIDE_DIRECT_CACHE_SERVICE_URLS | Your personal private URLs of gateways to the RedStone Data Distribution Layer (DDL). For running a local node you can simply put `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://httpbin.org/anything"]`. But for production node running you should [request them](https://redstone.finance/discord) from the RedStone team. | `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://xxx.yyy.secret-url-1.com","https://zzz.aaa.secret-url-2.com"]` |
+| OVERRIDE_DIRECT_CACHE_SERVICE_URLS | Your personal private URLs of gateways to the RedStone Data Distribution Layer (DDL). For running a local node you can simply put `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://httpbin.org/anything"]`. But for the production node running you should [request them](https://redstone.finance/discord) from the RedStone team. | `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://xxx.yyy.secret-url-1.com","https://zzz.aaa.secret-url-2.com"]` |
 | OVERRIDE_MANIFEST_USING_FILE | Path to your manifest file. Manifest is a public JSON file that defines the provider's obligation regarding the data that they provide. It sets fetching interval, tokens, sources and other public technical details for the provided data. You can check available manifests [here.](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/oracle-node/manifests) | `OVERRIDE_MANIFEST_USING_FILE=./manifests/dev/dev.json` |
 | LEVEL_DB_LOCATION | Path to the level DB. Each RedStone oracle node relies on a single-level DB. It is used to store recently fetched values from the last 15 minutes. These values are used for checking value deviations, filtering outliers and preventing price manipulation attacks. <br/><br/> You don't need to create a Level DB instance manually, it will be created automatically at the specified path during the first node launch. | `LEVEL_DB_LOCATION=/oracle-node-level-db` |
 
 ### Launch using Docker
 
 - [Link to the oracle-node Docker repository](https://gallery.ecr.aws/y7v2w8b2/redstone-oracle-node)
 
-Be sure to put your environment variables in the `.env` file using the instruction above.
+Be sure to put your environment variables in the `.env` file using the instructions above.
 
 Then, you can launch the RedStone oracle node using the following command:
 

docs/smart-contract-devs/get-started/redstone-core.mdx

@@ -88,7 +88,7 @@ You need to do 2 things:
 :::
 
 
-You need to apply a minimum change to the source code to enable smart contract to access data. Your contract needs to extend one of our [base contracts](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/contracts/data-services), depending on which data service are you going to use.
+You need to apply a minimum change to the source code to enable smart contract to access data. Your contract needs to extend one of our [base contracts](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/contracts/data-services), depending on which data service you are going to use.
 
 <details>
     <summary> List of base contracts with data services </summary>
@@ -228,7 +228,7 @@ We have prepared [repository](https://github.com/redstone-finance/minimal-foundr
 This approach is helpful if you need to pass the pricing data from one contract to another in your protocol. 
 
 It's also a solution for a case, where your contracts are written in solidity in a version lower than `0.8.4` it could be problematic to extend from the `RedstoneConsumerBase` contract.
-In that case we recomment to deploy a separate `Extractor` contract that will contain the verification logic: 
+In that case we recommend to deploy a separate `Extractor` contract that will contain the verification logic: 
 
 ```js
 pragma solidity 0.8.4;

docs/smart-contract-devs/get-started/redstone-x.md

@@ -30,7 +30,7 @@ TLDR; You need to do 2 things:
 
 When a user wants to execute a price-sensitive transaction we need to collect some collateral, record request parameters, and ask keepers to provide price data. 
 
-To clarify the steps, let's look at them in the context of a more concrete example. There is a simple protocol that allows swaping a native currency (like ETH) to a stable coin (like USDC). The sample code to record the transaction may look as follows:
+To clarify the steps, let's look at them in the context of a more concrete example. There is a simple protocol that allows swapping a native currency (like ETH) for a stable coin (like USDC). The sample code to record the transaction may look as follows:
 ```
 function changeEthToUsdc() external payable {
         bytes32 requestHash = calculateHashForSwapRequest(
@@ -55,12 +55,12 @@ In the function above we:
 
 We do not need to store all the data on-chain. It's sufficient to record a hash of the  values mentioned above. 
 
-3) Notify the keepers' network about the new request to receive price data by emiting the `NewOracleDataRequest` event.
+3) Notify the keepers' network about the new request to receive price data by emitting the `NewOracleDataRequest` event.
 
 ### Phase 2 - execution
 
 In this phase, the request from a user is executed with data received from the keeper network. 
-Let us analyse the necessary steps in the context of our example with swapping eth -> usdc. 
+Let us analyze the necessary steps in the context of our example with swapping eth -> usdc. 
 
 ```
 function executeWithOracleData(

docs/smart-contract-devs/how-it-works.md

@@ -9,7 +9,7 @@ sidebar_label: "💡 How it works?"
 
 Putting data directly into storage is the easiest way to make information accessible to smart contracts. This approach used to work well for large update intervals and small number of assets. However, there are more and more tokens coming to DeFi and modern derivative protocols require much lower latency boosting the maintenance costs of the simple model.
 
-That's why, RedStone proposes a completely new modular design where data is first put into a data availability layer and then fetched on-chain. This allow us to broadcast a large number of assets at high frequency to a cheaper layer and put it on chain only when required by the protocol.
+That's why, RedStone proposes a completely new modular design where data is first put into a data availability layer and then fetched on-chain. This allows us to broadcast a large number of assets at high frequency to a cheaper layer and put it on chain only when required by the protocol.
 
 ## 3 Ways to integrate
 
@@ -69,11 +69,11 @@ _All of the steps are executed automatically by the ContractWrapper and transpar
    - Extract value for each unique signer
    - Calculate the aggregated value (median by default)
 
-_This logic is executed in the on-chain environment and we optimised the execution using a low-level assembly code to reduce gas consumption to the absolute minimum_
+_This logic is executed in the on-chain environment and we optimized the execution using a low-level assembly code to reduce gas consumption to the absolute minimum_
 
 ## On-chain aggregation
 
-To increase the security of the RedStone oracle system, we've created the on-chain aggregation mechanism. This mechanism adds an additional requirement of passing at least X signatures from different authorised data providers for a given data feed. The values of different providers are then aggregated before returning to a consumer contract (by default, we use median value calculation for aggregation). This way, even if some small subset of providers corrupt (e.g. 2 of 10), it should not significantly affect the aggregated value.
+To increase the security of the RedStone oracle system, we've created the on-chain aggregation mechanism. This mechanism adds an additional requirement of passing at least X signatures from different authorized data providers for a given data feed. The values of different providers are then aggregated before returning to a consumer contract (by default, we use median value calculation for aggregation). This way, even if some small subset of providers corrupt (e.g. 2 of 10), it should not significantly affect the aggregated value.
 
 There are the following on-chain aggregation params in RedStone consumer base contract:
 
@@ -94,7 +94,7 @@ We support 2 types of data to be received in a contract:
 - Do not override the `getUniqueSignersThreshold` function, unless you are 100% sure about it
 - Pay attention to the timestamp validation logic. For some use-cases (e.g. synthetic DEX), you would need to cache the latest values in your contract storage to avoid arbitrage attacks
 - Enable a secure upgradability mechanism for your contract (ideally based on multi-sig or DAO)
-- Monitor the RedStone data services registry and quickly modify signer authorisation logic in your contracts in case of changes (we will also notify you if you are a paying client)
+- Monitor the RedStone data services registry and quickly modify signer authorization logic in your contracts in case of changes (we will also notify you if you are a paying client)
 
 ## Recommendations