docs: fix typos

contracts/README.md

@@ -23,7 +23,7 @@ Running the following command will regenerate the bindings in the `generated` di
 npx hardhat generate-abi-bindings --output-dir generated
 ```
 
-The command internally uses the abi and bytecode exporter plugins and searches the path configured in their configs for exporting for relevant files in order to launch the `abigen` executable with the correct paramaters. More info on installing `abigen` can be found [here](https://geth.ethereum.org/docs/dapp/abigen)
+The command internally uses the abi and bytecode exporter plugins and searches the path configured in their configs for exporting for relevant files in order to launch the `abigen` executable with the correct parameters. More info on installing `abigen` can be found [here](https://geth.ethereum.org/docs/dapp/abigen)
 
 
 Additionally you can pass the `noCompile` flag which will disable running the contract compilation beforehand. This allows to build go bindings for abi/bins where the actual solidity source files are missing.

design/bridge/bridge_design.md

@@ -202,7 +202,7 @@ When a transaction on the `L2` results in `LogMessagePublished`, the event will
 
 ### Alternative approaches
 
-1. Ten only ever pushes the hash of the message. The user has the responsibility of providing the full message which will only be accepted if it matches one of the hashes, if neccessary.
+1. Ten only ever pushes the hash of the message. The user has the responsibility of providing the full message which will only be accepted if it matches one of the hashes, if necessary.
   * This simplifies gas cost calculations, but the problem described in the `Fees` section remains.
   * Contracts can hash their messages before passing them to the `MessageBus` and achieve nearly the same outcome if they want to. 
 2. Ten only pushes to L2. Messages on L1 are provided signed by the enclave through an RPC and the MessageBus contract verifies that they have been signed by a correct enclave-owned key. 

design/scratchpad/Design_escape_hatch.md

@@ -9,7 +9,7 @@ It describes the ultimate way by which users can exit Ten.
 ## High level requirement
 
 The "escape hatch" is the mechanism that kicks in when **all hope is lost**, the last resort. 
-Something that happens just before the network goes down permanently for some unforseen reason.
+Something that happens just before the network goes down permanently for some unforeseen reason.
 
 For example, wen the central sequencer is no longer able to produce blocks and the Ten foundation is unable to replace it with something working in due time.
 
@@ -29,7 +29,7 @@ The "Escape mode" will be a flag on the Management contract, that can be set und
 
 ### Assumptions
 
-There will be at least one node in posession of the master seed that is able to publish it when this event is triggered.
+There will be at least one node in possession of the master seed that is able to publish it when this event is triggered.
 
 
 ## High level overview of the solution

design/security/high_availability.md

@@ -20,7 +20,7 @@ Introducing startup delays does not help too much in this case, because the oper
 
 
 An alternative solution is to introduce transparency into the lifecycle events of the sequencer enclaves, such that the Ten network 
-can assess the likelyhood of bad behaviour.  
+can assess the likelihood of bad behaviour.  
 
 Lifecycle events:
 - enclave starting up

design/ux/Ten_Gateway.md

@@ -8,7 +8,7 @@ The TG will be a superset of the WE functionality, so this document will only co
 
 The TG will be a [Confidential Web Service](https://medium.com/p/983a2a67fc08), running inside SGX.
 
-The current WE is designed to be used by a single user holding multiple addresses accross potentially multiple wallets. 
+The current WE is designed to be used by a single user holding multiple addresses across potentially multiple wallets. 
 
 The TG must support mutiple users, each with multiple addresses. It can be seen as offering a WE per user.
 

design/ux/user_data_incentives.md

@@ -58,18 +58,18 @@ Node operators could charge fees for this service.
 Given that everyone is now expecting this to be a free service, this is unlikely to be something that has a chance.
 
 
-#### 3. Incentives payed by the protocol.
+#### 3. Incentives paid by the protocol.
 
 The network (or protocol) charges fees from user when submitting transactions. This is something that users expect to pay.
 
-The Ten protocol is designed in such a way that it decouples the income from the costs by maintaing a buffer.
+The Ten protocol is designed in such a way that it decouples the income from the costs by maintaining a buffer.
 
 We can use this designed mechanism to pay for node usage as well along with the L1 gas fees and the general incentives to follow the protocol.
 
 
 ##### Measuring node usage
 
-As a proxy for a node responding to user requests, we can use a model where a node is payed a percentage of the gas fees that originated from their node. 
+As a proxy for a node responding to user requests, we can use a model where a node is paid a percentage of the gas fees that originated from their node. 
 
 A user that is connected to a node that doesn't respond to requests (like transaction receipts, or events), will leave that node and connect to a different node.
 

docs/README.md

@@ -6,7 +6,7 @@ This is the Ten Doc Site and it looks like [this](https://docs.obscu.ro/).
 
 1. Clone this repository: https://github.com/ten-protocol/go-ten
 2. Create your new content as a Markdown file in the `/docs` folder of the repo. Take care with the folder structure. 
-   As a general rule, new titles in the left hand navigation menu should have their content contained in a seperate 
+   As a general rule, new titles in the left hand navigation menu should have their content contained in a separate 
    subfolder under docs, for example, `/docs/testnet` contains all the Markdown files relation to the testnet docs.
 3. To have this new content shown in the left-hand navigation menu you need to modify the file 
    `/docs/_data/navigation.yml`. Follow the same format to add new headings and content titles. Remember to specify the 

docs/_docs/testnet/changelog.md

@@ -512,7 +512,7 @@
 
 # February 2023-02-23 (v0.10)
 * A list of the PRs merged in this release is as below;
-  * `d81f5f9a` Run a schedule deploy on the l1, and trigger l2 if succesful (#1129)
+  * `d81f5f9a` Run a schedule deploy on the l1, and trigger l2 if successful (#1129)
   * `481dc317` Wrap leveldb so its error types don't leak into our codebase (#1128)
   * `e5d8c398` Resilient to rpc requests while sequencer unknown (#1130)
   * `aa3eaea2` Updated go version and ego version. (#1124)

planning/testnet-kpis.md

@@ -2,8 +2,8 @@
 The launch of a testnet in Web3 is a significant milestone for all projects. It demonstrates the capability of the solution, whether the project is likely to meet the promises shared with investors and with the community and it signifies a confident step towards mainnet. The final iterations of a testnet should very closely emulate mainnet and give assurances to users, developers and investors that the final product will be of a high quality with a high chance of success. As a result, the impression left by testnet is crucial to the expected success of a project and how it is perceived. The primary contributors of success for Ten testnet are whether it is attractive, it is being used and whether or not users have a positive experience with it. Making the degree of success quantifiable means defining mesaurable success criteria and collecting data to know whether those criteria are being met.
 
 ## Testnet Success Criteria
-Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsquently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare Ten to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed.  
-The testnet success critera have been expressed below in the form of Key Performance Indicators with the rationale for their inclusion, the data source, the actual metric and the target value.
+Determining success for testnet will be a data-driven exercise, this being the best way to make measurable and repeatable observations. These observations can subsequently feed into decision-making with outcomes again being measured and compared. Included in the measurements will be criteria which, on the face of it, do not provide value however they have gained traction in the Web3 communicty as success indicators by which projects are judged. We need commentators to be able to compare Ten to other projects using like-for-like data points which the Web3 community are comfortable with even if they offer little value, or can even be misleading. For example, total number of transactions in a given period of time is a data point commonly used to compare projects yet it can be easily gamed.  
+The testnet success criteria have been expressed below in the form of Key Performance Indicators with the rationale for their inclusion, the data source, the actual metric and the target value.
 
 ## Testnet KPIs
 Key performance indicators (KPIs) will be used to determine the amount of Testnet traction over time.
@@ -13,8 +13,8 @@ Key performance indicators (KPIs) will be used to determine the amount of Testne
 |--|--|--|--|--|
 | Testnet uptime | Captures how robust and ready for mainnet Ten is | DataDog avg:system.uptime{*} | Average Testnet uptime over the last 4 weeks|99.9%|
 | Number of wallets connected to Ten Gateway| Good proxy for the number of active users. Straightforward to capture.| Datadog? |Number of daily connections|500|
-| Number of transactions| Typical guage of the amount of activity on testnet (even though it can be gamed).| Datadog? |Number of daily transactions|2000|
-| Number of RPC requests| Alternative guage of the amount of activity on testnet. Can also show where RPC performance degrades.| Datadog? |Number of daily RPC requests|2000|
+| Number of transactions| Typical gauge of the amount of activity on testnet (even though it can be gamed).| Datadog? |Number of daily transactions|2000|
+| Number of RPC requests| Alternative gauge of the amount of activity on testnet. Can also show where RPC performance degrades.| Datadog? |Number of daily RPC requests|2000|
 
 ### Selected KPIs for Developers
 | KPI NAME | RATIONALE | SOURCE | METRIC | TARGET |