Fix typos and grammar across documentation.

README.md

@@ -22,7 +22,7 @@ This command starts a local development server and opens up a browser window. Mo
 npm build
 ```
 
-This command generates static content into the `build` directory and can be served using any static contents hosting service.
+This command generates static content into the `build` directory and can be served using any static content hosting service.
 
 ### Clear .docusaurus directory
 
@@ -47,4 +47,4 @@ npm clear
       © 2025 Wire Network. All rights reserved.
     </td>
   </tr>
-</table
+</table>

docs/api-reference/system-contracts/index.md

@@ -10,15 +10,15 @@ The Wire blockchain platform is unique in that the features and characteristics
 
 ## Concepts
 
-### System contracts, system accounts, priviledged accounts
+### System contracts, system accounts, privileged accounts
 
 At the genesis of a Wire-based blockchain, there is only one account present: `sysio`, which is the **main system account**. There are other system accounts, which are created by `sysio`, and control specific actions of the system contracts mentioned earlier.
 
 Privileged accounts are accounts which can execute a transaction while skipping the standard authorization check. To ensure that this is not a security hole, the permission authority over these accounts is granted to `sysio.prods`.
 
 Not all system accounts contain a system contract, but each system account has important roles in the blockchain functionality, as follows:
 
-|Account|Priviledged|Has contract|Description|
+|Account|Privileged|Has contract|Description|
 |---|---|---|---|
 |sysio|Yes|It contains the `sysio.system` contract|The main system account on a Wire based blockchain.|
 |sysio.msig|Yes|It contains the `sysio.msig` contract|Allows the signing of a multi-sig transaction proposal for later execution if all required parties sign the proposal before the expiration time.|
@@ -50,7 +50,7 @@ As CPU and RAM, NET is also a very important resource in Wire-based blockchains.
 
 - About System Contracts
   - [Concepts](#concepts)
-    - [System contracts, system accounts, priviledged accounts](#system-contracts-system-accounts-priviledged-accounts)
+    - [System contracts, system accounts, privileged accounts](#system-contracts-system-accounts-privileged-accounts)
     - [RAM](#ram)
     - [CPU](#cpu)
     - [NET](#net)
@@ -85,14 +85,14 @@ Below are listed the actions which are declared in the `sysio.bios` contract, ma
 |updateauth|Updates the permission for an account.|
 |deleteauth|Delete permission for an account.|
 |linkauth|Assigns a specific action from a contract to a permission you have created.|
-|unlinkauth|Assigns a specific action from a contract to a permission you have created.|
+|unlinkauth|Removes the assignment of a specific action from a contract to a permission you have created.|
 |canceldelay|Allows for cancellation of a deferred transaction.|
 |onerror|Called every time an error occurs while a transaction was processed.|
 |setcode|Allows for update of the contract code of an account.|
 
 ### `sysio.system` contract
 
-The `sysio.system` contract is another smart contract that Block.one provides an implementation for as a sample system contract.  It is a version of `sysio.bios` only this time it is not minimalist, it contains more elaborated structures, classes, methods, and actions needed for a Wire based blockchain core functionality:
+The `sysio.system` contract is another smart contract that Block.one provides an implementation for as a sample system contract.  It is a version of `sysio.bios` only this time it is not minimalist, it contains more elaborate structures, classes, methods, and actions needed for the core functionality of a Wire-based blockchain:
 
 The actions implemented and publicly exposed by the `sysio.system` system contract are presented in the table below. Just like the `sysio.bios` sample contract there are a few actions which are not implemented at the contract level (`newaccount`, `updateauth`, `deleteauth`, `linkauth`, `unlinkauth`, `canceldelay`, `onerror`, `setabi`, `setcode`), they are just declared in the contract so they will show in the contract's ABI and users will be able to push those actions to the chain via the account holding the 'sysio.system' contract, but the implementation is at the Wire Sysio core level. They are referred to as **native actions.**
 
@@ -102,7 +102,7 @@ The actions implemented and publicly exposed by the `sysio.system` system contra
 |updateauth|Updates the permission for an account.|
 |deleteauth|Delete permission for an account.|
 |linkauth|Assigns a specific action from a contract to a permission you have created.|
-|unlinkauth|Assigns a specific action from a contract to a permission you have created.|
+|unlinkauth|Removes the assignment of a specific action from a contract to a permission you have created.|
 |canceldelay|Allows for cancellation of a deferred transaction.|
 |onerror|Called every time an error occurs while a transaction was processed.|
 |setabi|Allows for updates of the contract ABI of an account.|

docs/api-reference/tooling/cdt/features/binary-extension.md

@@ -10,11 +10,11 @@ tags:
 
 You can find the implementation of `sysio::binary_extension` [here](https://github.com/Wire-Network/wire-cdt/blob/master/libraries/sysiolib/core/sysio/binary_extension.hpp).
 
-Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in an `sysio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration.
+Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in a `sysio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration.
 
-By wrapping the new field in an `sysio::binary_extension`, you are enabling your contract to be _backwards compatible_ for future use. Note that this new field/parameter **MUST** be appended at the end of a data structure (this is due to implementation details in `sysio::multi_index`, which relies on the `boost::multi_index` type), or at the end of the parameter list in an action declaration.
+By wrapping the new field in a `sysio::binary_extension`, you are enabling your contract to be _backwards compatible_ for future use. Note that this new field/parameter **MUST** be appended at the end of a data structure (this is due to implementation details in `sysio::multi_index`, which relies on the `boost::multi_index` type), or at the end of the parameter list in an action declaration.
 
-If you don't wrap the new field in an `sysio::binary_extension`, the `sysio::multi_index` table will be reformatted in such a way that disallows reads to the former datum; or in an action's case, the function will be uncallable.
+If you don't wrap the new field in a `sysio::binary_extension`, the `sysio::multi_index` table will be reformatted in such a way that disallows reads to the former datum; or in an action's case, the function will be uncallable.
 
 ***
 
@@ -423,7 +423,7 @@ warning: transaction executed locally, but may not be confirmed by the network y
 
 ***
 
-Now, let's upgrade the smart contract by adding a new field to the table and a new parameter to an action while **NOT** wrapping the new field/parameter in an `sysio::binary_extension` type and see what happens:
+Now, let's upgrade the smart contract by adding a new field to the table and a new parameter to an action while **NOT** wrapping the new field/parameter in a `sysio::binary_extension` type and see what happens:
 
 **binary_extension_contract.hpp**
 
@@ -558,7 +558,7 @@ Whoops! We aren't able to write to our table the original way with the upgraded
 
 ***
 
-Ok, let's back up and wrap the new field and the new action parameter in an `sysio::binary_extension` type:
+Ok, let's back up and wrap the new field and the new action parameter in a `sysio::binary_extension` type:
 
 **binary_extension_contract.hpp**
 
@@ -653,7 +653,7 @@ struct [[sysio::table]] structure {
 }
 ```
 
-Note the `$` after the types now; this indicates that this type is an `sysio::binary_extension` type field.
+Note the `$` after the types now; this indicates that this type is a `sysio::binary_extension` type field.
 
 ```diff
 {
@@ -725,4 +725,4 @@ Just keep these simple rules in mind when upgrading a smart contract.
 If you are adding a new field to a struct currently in use by a `sysio::multi_index` be **SURE** to:
 
 - add the field at the end of the struct.
-- wrap the type using an `sysio::binary_extension` type.
+- wrap the type using a `sysio::binary_extension` type.

docs/api-reference/tooling/cdt/features/crypto-extensions.mdx

@@ -75,7 +75,7 @@ C++ types were added to represent `G1` and `G2` points (read and write) and view
       ec_point(std::vector<char>& p);
 
       /**
-       *  Return serialzed point containing only x and y
+       *  Return serialized point containing only x and y
        */
       std::vector<char> serialized() const;
    };
@@ -125,7 +125,7 @@ C++ types were added to represent `G1` and `G2` points (read and write) and view
       ec_point_view(const ec_point<Size>& p);
 
       /**
-       *  Return serialzed point containing only x and y
+       *  Return serialized point containing only x and y
        */
       std::vector<char> serialized() const;
    };

docs/api-reference/tooling/cdt/features/native-tester-compilation.md

@@ -42,7 +42,7 @@ using namespace sysio;
 using namespace sysio::native;
 
 SYSIO_TEST_BEGIN(hello_test)
-   // These can be redefined by the user to suit there needs per unit test
+   // These can be redefined by the user to suit their needs per unit test
    // the idea is that in a future release there will be a base library that 
    // initializes these to "useable" default implementations and probably 
    // helpers to more easily define read_action_data and action_data_size intrinsics
@@ -107,24 +107,24 @@ Every `intrinsic` that is defined for sysio (prints, require_auth, etc.) is re-d
 
 ## CDT Native Tester API
 
-- CHECK_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed but allow the rest of the tests to run.  
+- CHECK_ASSERT(...) : This macro will check whether a particular assert has occurred and flag the tests as failed but allow the rest of the tests to run.  
   - This is called either by
     - `CHECK_ASSERT("<assert message>", [](<args>){ whatever_function(<args>); })`
     - `CHECK_ASSERT([](std::string msg){ user defined comparison function }, [](<args>){ whatever_function(<args>); })`
 - CHECK_PRINT(...) : This macro will check whether the print buffer holds the string that is expected and flag the tests as failed but allow the rest of the test to run.
   - This is called either by
     - `CHECK_PRINT("<print message>", [](<args>){ whatever_function(<args>); })`
     - `CHECK_PRINT([](std::string print_buffer){ user defined comparison function }, [](<args>){ whatever_function(<args>); })`
-- CHECK_EQUAL(X, Y) : This macro will check whether two inputs equal eachother and fail the test but allow the rest of the test to continue.
-- REQUIRE_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed and halt the test on failure.  
+- CHECK_EQUAL(X, Y) : This macro will check whether two inputs equal each other and fail the test but allow the rest of the test to continue.
+- REQUIRE_ASSERT(...) : This macro will check whether a particular assert has occurred and flag the tests as failed and halt the test on failure.  
   - This is called either by
     - `REQUIRE_ASSERT("<assert message>", [](<args>){ whatever_function(<args>); })`
     - `REQUIRE_ASSERT([](std::string msg){ user defined comparison function }, [](<args>){ whatever_function(<args>); })`
 - REQUIRE_PRINT(...) : This macro will check whether the print buffer holds the string that is expected and flag the tests as failed and halt the test on failure.
   - This is called either by
     - `REQUIRE_PRINT("<print message>", [](<args>){ whatever_function(<args>); })`
     - `REQUIRE_PRINT([](std::string print_buffer){ user defined comparison function }, [](<args>){ whatever_function(<args>); })`
-- REQUIRE_EQUAL(X, Y) : This macro will check whether two inputs `X` and `Y` equal eachother and fail the test and halt the test on failure.
+- REQUIRE_EQUAL(X, Y) : This macro will check whether two inputs `X` and `Y` equal each other and fail the test and halt the test on failure.
 - SYSIO_TEST_BEGIN(X) : This macro defines the beginning of a unit test and assigns `X` as the symbolic name of that test.
 - SYSIO_TEST_END : This macro defines the end of a unit test.
 - SYSIO_TEST(X) : This is used to run a particular named unit test `X` in the main function.

docs/api-reference/tooling/clio/command-reference/get/deprecated/accounts.md

@@ -9,7 +9,7 @@ tags:
 
 
 :::warning [Deprecation Notice]
-| **Important**: The command `clio get accounts <public_key>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
+**Important**: The command `clio get accounts <public_key>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
 :::
 
 ## Description

docs/api-reference/tooling/clio/command-reference/get/deprecated/servants.md

@@ -8,7 +8,7 @@ tags:
 ---
 
 :::warning Deprecation Notice
-| **Important**: The command `clio get servants <account>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
+**Important**: The command `clio get servants <account>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
 :::
 
 ## Description

docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction.md

@@ -8,7 +8,7 @@ tags:
 ---
 
 :::warning Deprecation Notice
-| **Important**: The command `clio get transaction <trx_id>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
+**Important**: The command `clio get transaction <trx_id>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
 :::
 
 ## Description

docs/api-reference/tooling/clio/command-reference/get/deprecated/transaction_id.md

@@ -8,7 +8,7 @@ tags:
 ---
 
 :::warning Deprecation Notice
-| **Important**: The command `clio get transaction_id <trx>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
+**Important**: The command `clio get transaction_id <trx>` relies on the `history_api_plugin`, which in turn depends on the `history_plugin`. Please be aware that the `history_plugin` is **deprecated** and will no longer be maintained. For accessing historical blockchain data, consider using the `state_history_plugin` for full-history solutions or the `trace_api_plugin`.
 :::
 
 ## Description

docs/api-reference/tooling/clio/command-reference/get/table.md

@@ -27,7 +27,7 @@ clio get table
   [[-l | --limit] <rows>]          # The maximum number of rows to return
   [[-k | --key] <key_name>]        # (Deprecated) The name of the key to index by as defined by the abi, defaults to primary key
   [[-L | --lower] <value>]         # JSON representation of lower bound value of key, defaults to first
-  [[-U | --upper] <value>]         # JSON representation of upper bound value value of key, defaults to last
+  [[-U | --upper] <value>]         # JSON representation of upper bound value of key, defaults to last
   [--index <number>]               # Index number, `1`: primary (first), `2`: secondary index (in order defined by multi_index), `3`: third index, etc. Number or name of index can be specified, e.g. `secondary` or `2`
   [--key-type <type>]              # The key type of `--index`; primary only supports `i64`. All others support `i64`, `i128`, `i256`, `float64`, `float128`, `ripemd160`, `sha256`. Special type `name` indicates an account name
   [--encode-type <type>]           # The encoding type of `--key_type`; `dec` for decimal encoding of (`i[64|128|256]`, `float[64|128]`); `hex` for hexadecimal encoding of (`i256`, `ripemd160`, `sha256`)

docs/api-reference/tooling/clio/command-reference/net/connect.md

@@ -31,7 +31,7 @@ Make sure you meet the following requirements:
 * Install the currently supported version of `clio`.
 
 :::note
-| The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
+The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
 :::
 
 * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded.

docs/api-reference/tooling/clio/command-reference/net/disconnect.md

@@ -31,7 +31,7 @@ clio net disconnect
 * Install the currently supported version of `clio`.
 
 :::note
-  | The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
+  The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
 :::
 
 * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded.

docs/api-reference/tooling/clio/command-reference/net/peers.md

@@ -29,7 +29,7 @@ clio net peers
 
 * Install the currently supported version of `clio`.
   :::note
-  | The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
+  The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
   :::
 
 * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded.

docs/api-reference/tooling/clio/command-reference/net/status.md

@@ -31,7 +31,7 @@ clio net status
 * Install the currently supported version of `clio`.
 
 :::note
-| The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
+The `clio` tool is bundled with the Wire software. [Installing Wire core](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
 :::
 
 * You have access to a producing node instance with the [`net_api_plugin`](../../../nodeop/plugins/net-api-plugin.md) loaded.

docs/api-reference/tooling/clio/command-reference/set/set-action-permission.md

@@ -54,7 +54,7 @@ clio set action permission
 * Install the currently supported version of `clio`.
 
 :::note
-| The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
+The `clio` tool is bundled with the Wire software. [Installing Wire Sysio](/docs/getting-started/install-dependencies.md) will install the `clio` and `kiod` command line tools.
 :::
 
 * You have access to a local Wire node.