Fix typos

SEMANTICS.md

@@ -344,8 +344,8 @@ It just ends up returning `Err` to contract-A's `reply` function.
 
 Note that errors are not handled with `ReplyOn::Success`, meaning, in such a
 case, an error will be treated just like a normal `message` returning an error.
-This diagram may help explain. Imagine a contract returned two submesssages -
-(a) with `ReplyOn::Success` and (b) with `ReplyOn::Error`:
+This diagram may help explain. Imagine a contract returned two submessages - (a)
+with `ReplyOn::Success` and (b) with `ReplyOn::Error`:
 
 | processing a) | processing b) | reply called | may overwrite result from reply | note                                              |
 | ------------- | ------------- | ------------ | ------------------------------- | ------------------------------------------------- |

contracts/burner/src/msg.rs

@@ -18,7 +18,7 @@ pub struct InstantiateMsg {}
 #[cw_serde]
 pub enum ExecuteMsg {
     /// Cleans up the given number of state elements.
-    /// Call this multiple times to increamentally clean up state.
+    /// Call this multiple times to incrementally clean up state.
     Cleanup {
         /// The number of state elements to delete.
         ///

contracts/crypto-verify/src/ethereum.rs

@@ -63,7 +63,7 @@ fn serialize_unsigned_transaction(
 
 /// Get the recovery param from the value `v` when no chain ID for replay protection is used.
 ///
-/// This is needed for chain-agnostig aignatures like signed text.
+/// This is needed for chain-agnostic signatures like signed text.
 ///
 /// See [EIP-155] for how `v` is composed.
 ///
@@ -78,7 +78,7 @@ pub fn get_recovery_param(v: u8) -> StdResult<u8> {
 
 /// Get the recovery param from the value `v` when a chain ID for replay protection is used.
 ///
-/// This is needed for chain-agnostig aignatures like signed text.
+/// This is needed for chain-agnostic signatures like signed text.
 ///
 /// See [EIP-155] for how `v` is composed.
 ///

docs/CAPABILITIES.md

@@ -96,7 +96,7 @@ contract checks the availability early on.
 
 When functionality is always present in the VM (such as a new import implemented
 directly in the VM, see [#1299]), we should not use capability. They just create
-fragmentation in the CosmWasm ecosystem and increase the barrier for adoption.
+fragmentation in the CosmWasm ecosystem and increase the barrier to adoption.
 Instead the `check_wasm_imports` check is used to validate this when the
 contract is stored.