chore: fix some typos in comments (#354)

Signed-off-by: laterlaugh <[email protected]>

Author: laterlaugh

development-guidelines/incident_response.md

@@ -1,6 +1,6 @@
 # Incident Response Recommendations
 
-How you respond during an incident is a direct reflection of your efforts to prepare for such an event. Each team or project's needs will vary so we provide the guidelines below as a starting point. Adherance to our guidelines can help you shift from a reactive approach to a **proactive** approach by planning with the assumption that incidents are inevitable. To fully leverage the following guidelines, consider them throughout the application development process.
+How you respond during an incident is a direct reflection of your efforts to prepare for such an event. Each team or project's needs will vary so we provide the guidelines below as a starting point. Adherence to our guidelines can help you shift from a reactive approach to a **proactive** approach by planning with the assumption that incidents are inevitable. To fully leverage the following guidelines, consider them throughout the application development process.
 
 ## Application Design
 

not-so-smart-contracts/cosmos/unregistered_msg_handler/README.md

@@ -179,4 +179,4 @@ And it is the `CancelCall` msg.
 
 ## External examples
 
-- The bug occured in the [Gravity Bridge](https://github.com/code-423n4/2021-08-gravitybridge-findings/issues/64). It was impossible to send evidence of malicious behavior, which impacted Gravity Bridge's security model.
+- The bug occurred in the [Gravity Bridge](https://github.com/code-423n4/2021-08-gravitybridge-findings/issues/64). It was impossible to send evidence of malicious behavior, which impacted Gravity Bridge's security model.

not-so-smart-contracts/solana/sysvar_account_check/README.md

@@ -6,7 +6,7 @@ The sysvar (system account) account is often used while validating access contro
 
 secp256k1 is an elliptic curve used by a number of blockchains for signatures. Validating signatures is crucial as by bypassing signature checks, an attacker can gain access to restricted functions that could lead to drainage of funds.
 
-Here, `load_current_index` and `load_instruction_at` are functions that don't verify that the inputted sysvar account is authorized, therefore allowing serialized maliciously fabricated data to sucessfully spoof as an authorized secp256k1 signature.
+Here, `load_current_index` and `load_instruction_at` are functions that don't verify that the inputted sysvar account is authorized, therefore allowing serialized maliciously fabricated data to successfully spoof as an authorized secp256k1 signature.
 
 ### Example Contract
 

not-so-smart-contracts/substrate/weights_and_fees/README.md

@@ -2,7 +2,7 @@
 
 Weights and transaction fees are the two main ways to regulate the consumption of blockchain resources. The overuse of blockchain resources can allow a malicious actor to spam the network to cause a denial-of-service (DoS). Weights are used to manage the time it takes to validate the block. The larger the weight, the more "resources" / time the computation takes. Transaction fees provide an economic incentive to limit the number of resources used to perform operations; the fee for a given transaction is a function of the weight required by the transaction.
 
-Weights can be fixed or a custom "weight annotation / function" can be implemented. A weight function can calculate the weight, for example, based on the number of database read / writes and the size of the input paramaters (e.g. a long `Vec<>`). To optimize the weight such that users do not pay too little or too much for a transaction, benchmarking can be used to empirically determine the correct weight in worst case scenarios.
+Weights can be fixed or a custom "weight annotation / function" can be implemented. A weight function can calculate the weight, for example, based on the number of database read / writes and the size of the input parameters (e.g. a long `Vec<>`). To optimize the weight such that users do not pay too little or too much for a transaction, benchmarking can be used to empirically determine the correct weight in worst case scenarios.
 
 Specifying the correct weight function and benchmarking it is crucial to protect the Substrate node from denial-of-service (DoS) attacks. Since fees are a function of weight, a bad weight function implies incorrect fees. For example, if some function performs heavy computation (which takes a lot of time) but specifies a very small weight, it is cheap to call that function. In this way an attacker can perform a low-cost attack while still stealing a large amount of block execution time. This will prevent regular transactions from being fit into those blocks.
 

program-analysis/slither/examples/coin.sol

@@ -6,7 +6,7 @@ contract Coin {
 
     mapping(address => uint256) balances;
 
-    // _mint must not be overriden
+    // _mint must not be overridden
     function _mint(address dst, uint256 val) internal virtual {
         require(msg.sender == owner);
         balances[dst] += val;

program-analysis/slither/exercises/exercise1/coin.sol

@@ -6,7 +6,7 @@ contract Coin {
 
     mapping(address => uint256) balances;
 
-    // _mint must not be overriden
+    // _mint must not be overridden
     function _mint(address dst, uint256 val) internal {
         require(msg.sender == owner);
         balances[dst] += val;