Merge pull request #54 from omahs/patch-1

fix: typos

Author: dimsome

docs/Build/contract-setup/configuring-plugs.md

@@ -15,7 +15,7 @@ You can read more about Plugs [here](../../Learn/Components/Plugs.md). Once conn
 
 ## Configuring Plug Parameters
 
-Plugs should be deployed on respective chains before they can be connected to their sibling Plugs deployed on other chains. Once you are ready with Plugs deployed on the networks you want to work with, its time to get Plugged!
+Plugs should be deployed on respective chains before they can be connected to their sibling Plugs deployed on other chains. Once you are ready with Plugs deployed on the networks you want to work with, it's time to get Plugged!
 
 **Here's the parameters required for connection**
 
@@ -30,7 +30,7 @@ You can find addresses for all verified Switchboards and Socket contracts in [De
 
 ## Connecting your Plugs
 
-Once you have the Socket address you are connecting to, you just need call the `connect` method on it to configure your Plug on that chain. Remember, you need to call `connect` on both the chains you want to work with.
+Once you have the Socket address you are connecting to, you just need to call the `connect` method on it to configure your Plug on that chain. Remember, you need to call `connect` on both the chains you want to work with.
 
 Below is a quick example for how your Plug can call the `connect` method on Socket
 
@@ -66,4 +66,4 @@ Furthermore, you can do the following to check the connection is successful :
 - Call the `getPlugConfig` function on the Socket contract that returns the config for your Plug for a given destination ChainSlug
 - Use the [Check Connection API](../../dev-resources/APIReference/CheckConnection.md) that reads the configs and aids you to make sure your connection is correct
 
-<!-- // TODO: ADD GIF; ITs time to send it -->
+<!-- // TODO: ADD GIF; ITs time to send it -->

docs/Build/contract-setup/sending.md

@@ -10,7 +10,7 @@ sidebar_position: 2
 
 | Parameters | Description |
 | --- | --- |
-| remoteChainSlug | ChainSlug of the network where you want to send your messsage to |
+| remoteChainSlug | ChainSlug of the network where you want to send your message to |
 | payload | The message you want to send to the plug on remoteChainSlug |
 | msgGasLimit | gasLimit required to execute the `payload` on remoteChainSlug |
 
@@ -41,7 +41,7 @@ Equipped with the payload we want to send, we can now call the outbound on Socke
 <!-- // TODO: add API link -->
 
 Once the tx is finalised:
-- An event `MessageOutbound` is emitted by Socket containing all relavent details.
+- An event `MessageOutbound` is emitted by Socket containing all relevant details.
 - Your message will be allocated a unique ID called (`msgId`) you can look it up in the `MessageOutbound` log
 
 You can use the tx-hash to track the delivery and execution on the destination chain via [this API](../../dev-resources/APIReference/Track.md).  

docs/Learn/Components/Capacitors.md

@@ -12,10 +12,10 @@ Anything can become a capacitor, it should be able to compress messages lossless
 // capacitor compresses multiple messages into a bytes32 variable
 bytes32 capacitor_hat root = Capacitor(msg1, msg2, msg3...)
 ```
-Usually, since a capacitor batches messages together but messages on destination are executed individually, capacitors are paired with decapcitors automatically. 
+Usually, since a capacitor batches messages together but messages on destination are executed individually, capacitors are paired with decapacitors automatically. 
 
 ```javascript
-// a decapacitor should be able to retrive the messsage from the root via a proof
+// a decapacitor should be able to retrieve the message from the root via a proof
 bytes msg1 = Decapacitor(capacitor_root, proof) 
 ```
 
@@ -27,4 +27,4 @@ CapacitorFactory is an upgradable contract that lists different kinds of Capacit
 
 CapacitorFactory assigns each type of Capacitor a "type" which is a unique identifier(uint32) used to refer to a specific capacitor. While registering a switchboard to Socket like defined here, you specify a capacitor_type, the registration function deploys the switchboard specific capacitor and decapacitor. Developers have the ability to define the level of batching they want while they register the switchboard. 
 
-More details around access control and ownership of CapacitorFactory [contract here](../Ownership.md).
+More details around access control and ownership of CapacitorFactory [contract here](../Ownership.md).

docs/Learn/Components/Plugs.md

@@ -1,3 +1,3 @@
 Smart contracts that connect to Socket to send messages to each other across chains are called Plugs. Before your Plugs can communicate to each other directly, you need to connect to Socket and inform Socket about your sibling Plugs. Plugs must “connect” or get “plugged into” Socket for each unique sibling network for sending/receiving messages.  
 
-It's recommended to keep this action permissioned, malicious configration while connecting to Socket will cause unintended actions. In case a connection between two plugs already exists on a chain, re-connecting will override the previous configuration, Socket by default doesnt block this behaviour. However you are free to block this behaviour from your Plug.
+It's recommended to keep this action permissioned, malicious configuration while connecting to Socket will cause unintended actions. In case a connection between two plugs already exists on a chain, re-connecting will override the previous configuration, Socket by default doesn't block this behaviour. However you are free to block this behaviour from your Plug.

docs/Learn/Components/Switchboards.md

@@ -1,18 +1,18 @@
-Plugs connect to Socket via Switchboards(just like in real life). Switchboards are like open-source permissionless configration bundles that plugs can opt into OR build their own configration bundles.
+Plugs connect to Socket via Switchboards(just like in real life). Switchboards are like open-source permissionless configuration bundles that plugs can opt into OR build their own configuration bundles.
 
 Switchboards contain the following things:
-- Packet authenticaion via `allowPacket` method
+- Packet authentication via `allowPacket` method
 - Capacitor to be used for that switchboard
 - Decapacitor to be used for verifying message inclusion in Packet
 - minFees for packet validation
 
-Switchboards allow developers to permissionlessly authenticate Packets before they get executed on their Plugs, we think there are various authenticaion models that people can leverage to manage tradeoffs for their applications. 
+Switchboards allow developers to permissionlessly authenticate Packets before they get executed on their Plugs, we think there are various authentication models that people can leverage to manage tradeoffs for their applications. 
 
 Anyone can build a switchboard that satisfies the [ISwitchboard interface](../../dev-resources/Interfaces/ISwitchboard.md). It needs to be registered to Socket before Plugs can use it via the `registerSwitchboard()` method on Socket. Registering a Switchboard is completely permissionless. 
 
 Socket Labs has bootstrapped some switchboards with different tradeoffs for end developers, we encourage developers to feel free to leverage these switchboards if they are suitable for their usecase.
 - Optimistic Switchboard: Allow 1/N trust-minimised and cheap validation by introducing a challenge mechanism pre-execution where N parties can stop the packet from getting executed. This Switchboard will be extremely cheap to leverage but will have a latency of the challenge period. 
 - Fast Switchboard: Allow 1/N trust minimised validation by having all N parties attest on-chain, this is still as secure as the OptimisticSwitchboard but might cost more on-chain depending on the destination chain.
-- Native Switchboard: Allows developers to leverage native verification for eg: rollup-validation whereever it's available, we have built these connectors for Polygon, Arbitrum and Optimism right now. Developers who want to leverage security of the native-security should leverage these.
+- Native Switchboard: Allows developers to leverage native verification for eg: rollup-validation wherever it's available, we have built these connectors for Polygon, Arbitrum and Optimism right now. Developers who want to leverage security of the native-security should leverage these.
 
-We encourage developers to build their own Switchboards and register them on the Socket contract, we would love to drive innnovation on the verification layer. 
+We encourage developers to build their own Switchboards and register them on the Socket contract, we would love to drive innovation on the verification layer. 

docs/Learn/Components/TransmitManager.md

@@ -1,9 +1,9 @@
 As messages get accumulated by the capacitor, transmitters can seal the capacitors whenever it's ready to discharge to seal the Packet and create
 SealedPacket. Once the packet is sealed it's ready to be transmitted and submitted to the propose method on the destination Socket. To seal and to propose the msg.sender needs to have the transmitter's signature over the Packet.  
 
-Transmitters are part of the delivery layer and are responsible for only the liveliness of the protocol. Transmitters operations are completely on-chain and publicly visible to everyone, this is a very important property. Transmitters are also a very light-weight and can be extended to any chain quickly. 
+Transmitters are part of the delivery layer and are responsible for only the liveliness of the protocol. Transmitters operations are completely on-chain and publicly visible to everyone, this is a very important property. Transmitters are also very light-weight and can be extended to any chain quickly. 
 
 Transmitters are managed by TransmitManager contract which takes care of the following:
 - Leader selection between multiple transmitters  
 - Fee collection and distribution
-- Managing the set of transmitters
+- Managing the set of transmitters

docs/Learn/Concepts/Fees.md

@@ -29,7 +29,7 @@ Fees can be estimated off-chain using the [Fee Estimation API](../../dev-resourc
 
 ### Estimating Fees on-chain 
 
-Sending a cross-chain message requires the message to be verified and executed on the destination chain and the fees for this need to be calculated with the destination chain `gasPrice`. But the gasPrice of the destination chain is not known on the source chain. To enable this calculation, Socket maintains an siblingChain gas fee mapping on the ExecutionManager, TransmitManager and Switchboards. These fees are updated periodically by off-chain agents with the `FEES_UPDATER_ROLE`
+Sending a cross-chain message requires the message to be verified and executed on the destination chain and the fees for this need to be calculated with the destination chain `gasPrice`. But the gasPrice of the destination chain is not known on the source chain. To enable this calculation, Socket maintains a siblingChain gas fee mapping on the ExecutionManager, TransmitManager and Switchboards. These fees are updated periodically by off-chain agents with the `FEES_UPDATER_ROLE`
 
 #### How to fetch fee estimate
 Plugs can use [ISocket](../../dev-resources/Interfaces/ISocket.md) to call `getMinFees` method on Socket. This method takes the payload execution gasLimit, destination chain ID, payload size and plug address as input and calculates the total fee. This enables Plugs to be completely on-chain and not rely on any off-chain services for fee calculation or to interact with Socket. 

docs/Learn/Ownership.md

@@ -1,12 +1,12 @@
 We strongly believe that contracts should be immutable, non-upgradable, upgrades should be opt-in by clients. We have clear roles on the contract and plans on how to remove them. All roles are listed in the [AccessRoles.sol contract](https://github.com/SocketDotTech/socket-DL/blob/master/contracts/utils/AccessRoles.sol)
 
 Here are some of the roles and the purpose:
-- `RESCUE_ROLE`: It's only used to rescue funds if stuck in a contract which isnt supposed to hold funds. This is just a safety role to allow us to give back people their ERC20s or ETHER that they might have accidently sent.
+- `RESCUE_ROLE`: It's only used to rescue funds if stuck in a contract which isnt supposed to hold funds. This is just a safety role to allow us to give back people their ERC20s or ETHER that they might have accidentally sent.
 - `WITHDRAW_ROLE`: We haven't built a permissionless way to execute fee distribution via TransmitManager, ExecutionManager and Switchboard yet, hence we have this special role to allow us to withdraw and distribute the fees. This role will deprecate once the fee distribution logic is on-chain. This does not impact the security implications for the end user and only affects the off-chain agents.
 - `EXECUTOR_ROLE`: This role whitelists addresses to allow them to execute messages post permissionless validation by the switchboard. This role is currently permissioned to prevent users from harmful effects of REV. This role holds no security implications.
 - `TRANSMITTER_ROLE`: This role is not part of Socket protocol. This role is used by TransmitManager to grant approval to a particular transmitter to seal and propose packets. TransmitterManager is a modular contract. 
-- `GOVERNANCE_ROLE`: This one is an interesting one. The role is minimally used by intention. This role CANNOT UPDATE the security properties of a message and or modify user preferences. This role is minimally used in the core-contracts to update the `TransmitManager` and `ExecutionManager` modules, both of which cannot harm the end developer and in the worst case just pause the protocol as the current `TransmitManager` and `ExecutionManager` modules are implemented. Apart from the core-contracts, the GOVERNANCE_ROLE can be utilised with a different setting in the swithboards but switchboards are permissionless already and developers can remove or update the usage of the role according to their preferences.
+- `GOVERNANCE_ROLE`: This one is an interesting one. The role is minimally used by intention. This role CANNOT UPDATE the security properties of a message and or modify user preferences. This role is minimally used in the core-contracts to update the `TransmitManager` and `ExecutionManager` modules, both of which cannot harm the end developer and in the worst case just pause the protocol as the current `TransmitManager` and `ExecutionManager` modules are implemented. Apart from the core-contracts, the GOVERNANCE_ROLE can be utilised with a different setting in the switchboards but switchboards are permissionless already and developers can remove or update the usage of the role according to their preferences.
 - `TRIP_ROLE`: This role allows holder to trip or pause a `Switchboard`, in case of smart contract bugs on a specific `Switchboard`
 - `UN_TRIP_ROLE`: This role allows holder to untrip or unpause a `Switchboard`
 - `WATCHER_ROLE`: Role assigned to `Switchboard` watchers. Watchers play different a different role depending on the Switchboard used. For example, in Optimistic Switchboards, Watchers can trip a specific path/packet if any fraud was detected.
-- `FEES_UPDATER_ROLE`: Role assigned to off-chain agents that update gas fees for each siblingChain on a given switchboard, TransmitManager and ExecutionManager
+- `FEES_UPDATER_ROLE`: Role assigned to off-chain agents that update gas fees for each siblingChain on a given switchboard, TransmitManager and ExecutionManager

docs/Learn/glossary.md

@@ -9,10 +9,10 @@ We have introduced a lot of new terms and that is by design. We think for someth
 Here is a quick run-down of some of the terms that you will come across the entire documentation:
 - **Socket**: Socket is the [core contract](https://github.com/SocketDotTech/socket-DL/blob/master/contracts/socket/Socket.sol) deployed on all networks that are supported. All core modules and functions exist within Socket
 - **Plug/Plugs**: Plugs are smart contract applications that connect with Socket to send and receive cross-chain messages via the [IPlug interface](../dev-resources/Interfaces/IPlug.md). Plugs are generally adapter contracts that connect your main Smart contract to the messaging infrastructure.
-- **Message**: Message is the payload you want to transmit along with relavent meta-data like destination chainSlug etc. 
+- **Message**: Message is the payload you want to transmit along with relevant meta-data like destination chainSlug etc. 
 - **Packet**: Packets are a collection of messages sent from one chain to another. The validity of messages in a packet is verified on the destination chain based on the logic prescribed in the configured switchboard. [Read more](./Components/Packet.md).
 - **Sealed Packet**: As soon as the transmitter seals the packet on the source-chain with their signature it's called "SealedPacket". Read more about how transmitters work [here](./lifecycle.md#sending-a-message). 
-- **Capacitor**: Capacitor is responsibile for storing messages in the form of a Packet. The packet is released when the transmitter calls the `sealPacket` method on the capacitor. Capacitors allow for native batching of payloads for better gas-performance. [Read more](./Components/Capacitors.md).
-- **Switchboard**: Switchboards are the authenticaion/verification modules that allow developers to have custom verification for their payloads/messages. They can be permissionlessly built and deployed by the community. [Read more](./Components/Switchboards.md)
+- **Capacitor**: Capacitor is responsible for storing messages in the form of a Packet. The packet is released when the transmitter calls the `sealPacket` method on the capacitor. Capacitors allow for native batching of payloads for better gas-performance. [Read more](./Components/Capacitors.md).
+- **Switchboard**: Switchboards are the authentication/verification modules that allow developers to have custom verification for their payloads/messages. They can be permissionlessly built and deployed by the community. [Read more](./Components/Switchboards.md)
 - **Transmitter**: Transmitters are the entities responsible for transmission of Packet across layers, their activity is completely on-chain and managed by TransmitManager. [Read more](./Components/TransmitManager.md)
-- **ChainSlug**: ChainSlug is a unique identifier for a particular network or Socket deployment. It's different than Chain ID or Network ID used on EVM networks. You can find the assigned ChainSlugs in the [deployments section](../dev-resources/Deployments.mdx)
+- **ChainSlug**: ChainSlug is a unique identifier for a particular network or Socket deployment. It's different than Chain ID or Network ID used on EVM networks. You can find the assigned ChainSlugs in the [deployments section](../dev-resources/Deployments.mdx)

docs/Learn/protocol-architecture.md

@@ -18,7 +18,7 @@ There are several components in the Socket protocol that work together to make t
 
 ## Architecture
 
-Socket is built in a modular fashion with various layers with defined APIs/Interfaces between them which allows developers the ability to leverage the software-stack in different and more efficent ways depending on their application context. 
+Socket is built in a modular fashion with various layers with defined APIs/Interfaces between them which allows developers the ability to leverage the software-stack in different and more efficient ways depending on their application context. 
 
 The protocol consists of four key layers:
 1. **Application Layer**: This layer consists of `Plugs`, which are smart contract applications built to interact with Socket. Plugs follow a specified API and communicate through deployed Socket instances between any two supported chains. The core Socket contract functions as an on-chain endpoint that sends and receives payloads between chains. As applications send payloads through Plugs, Socket compresses them into cryptographic hashes called `Packets`, which represent thousands of payloads across apps.
@@ -29,4 +29,4 @@ The protocol consists of four key layers:
 
 <img src="/img/dl-layers.png"/>
 
-Learn more about individual compoenents in [Components](./Components/Capacitors.md) and [Offchain Agents](./OffChain-Agents.md).
+Learn more about individual components in [Components](./Components/Capacitors.md) and [Offchain Agents](./OffChain-Agents.md).