fix: typos

doc/src/build/sui-json.md

@@ -58,7 +58,7 @@ Unsigned Integer (128 bit max)
   <tr>
    <td>Array
    </td>
-   <td>Must be homogenous JSON and of SuiJSON type
+   <td>Must be homogeneous JSON and of SuiJSON type
    </td>
    <td>Vector
    </td>
@@ -262,7 +262,7 @@ Two formats are supported
 <code>[[3,600],[],[0,7,4]]</code>: nested U64 vector
 
    </td>
-   <td><code>[1,2,3,false]</code>: not homogenous JSON
+   <td><code>[1,2,3,false]</code>: not homogeneous JSON
 
 <code>[1,2,null,4]</code>: invalid elements
 

doc/src/explore/tutorials.md

@@ -324,7 +324,7 @@ This is a chance for Player X to win! X now mints the winning mark at (2, 0):
 $ wallet call --package $PACKAGE --module TicTacToe --function send_mark_to_game --args \"0x$XCAP\" \"0x$ADMIN\" 2 0 --gas $X_GAS --gas-budget 1000
 ```
 
-And its ouput:
+And its output:
 ```shell
 ----- Certificate ----
 ...

doc/src/learn/architecture/validators.md

@@ -22,10 +22,10 @@ A validator can handle two types of write requests: transactions and certificate
 ### Transactions
 When a validator receives a transaction from a client, it will first perform transaction validity checks (e.g., validity of the sender's signature). If the checks pass, the validator will sign the transaction bytes and return the signature to the client. The client repeats this process with multiple validators until it has collected signatures on its transaction from a committee, thereby forming a certificate.
 
-Note that the process of collecting validator signatures on a transaction into a certificate and the process of submitting certifcates can be performed in parallel. The client can simultaneously broadcast transactions/certificates to an arbitrary number of validators. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (e.g., it can refuse to form a certificate), but not for safety (e.g., it cannot change the effects of the transaction).
+Note that the process of collecting validator signatures on a transaction into a certificate and the process of submitting certificates can be performed in parallel. The client can simultaneously broadcast transactions/certificates to an arbitrary number of validators. Alternatively, a client can outsource either or both of these tasks to a third-party service provider. This provider must be trusted for liveness (e.g., it can refuse to form a certificate), but not for safety (e.g., it cannot change the effects of the transaction).
 
 ### Certificates
-Once the client forms a certificate, it submits the certificate to a validator, which will perform certificate validity checks (e.g., ensuring the signers are validators in the current epoch, and the signatures are cryptographically valid). If the checks pass, the auhority will execute the transaction inside the certificate. Execution of a transaction will either succeed and commit all of its effects to the ledger, or abort (e.g., due to an explicit `abort` instruction, a runtime error such as divison by zero, or exceeding the maximum gas budget) and have no effects other than debiting the transaction's gas input. In either case, the transaction will durably store the certificate indexed by the hash of its inner transaction.
+Once the client forms a certificate, it submits the certificate to a validator, which will perform certificate validity checks (e.g., ensuring the signers are validators in the current epoch, and the signatures are cryptographically valid). If the checks pass, the auhority will execute the transaction inside the certificate. Execution of a transaction will either succeed and commit all of its effects to the ledger, or abort (e.g., due to an explicit `abort` instruction, a runtime error such as division by zero, or exceeding the maximum gas budget) and have no effects other than debiting the transaction's gas input. In either case, the transaction will durably store the certificate indexed by the hash of its inner transaction.
 
 As with transactions, we note that the process of sharing a certificate with validators can be parallelized and (if desired) outsourced to a third-party service provider. A client should broadcast its certificate to >1/3 of the validators to ensure that (up to BFT assumptions) at least one honest validator has executed and committed the certificate. Other validators may learn about the certificate via inter-validator state sync or via client-assisted state sync.
 

doc/src/learn/sui-security.md

@@ -79,7 +79,7 @@ on which address and how the shared assets may be used.
 
 A valid transaction submitted to all validators to be certified and its certificate also has to be submitted to all validators
 to be finalized. Even if a subset of validators do not follow the protocol, the transaction can be finalized through the
-remaining validators that correctly follow the Sui protocol. This is achieved throught the use of cryptographic
+remaining validators that correctly follow the Sui protocol. This is achieved through the use of cryptographic
 Byzantine fault tolerant agremment protocols for broadcast and consensus defined by the Sui protocol. These protocols
 ensure both safety, meaning that the incorrect validators cannot convince correct clients of incorrect state, and
 liveness, meaning that incorrect validators cannot prevent transaction processing.
@@ -88,7 +88,7 @@ All transactions in Sui have to be associated with a gas asset to cover the cost
 transaction may result in a status of successful execution or an aborted execution. An execution may abort due to a 
 condition within the smart contract defining the asset, or because it has ran out of sufficient gas to pay for
 the cost of execution. In cases of success, the effects of the operation will be finalized; otherwise, the state of 
-assets in the transaction is not changed. However, the gas asset is always charged some amount of gas, to aleviate
+assets in the transaction is not changed. However, the gas asset is always charged some amount of gas, to alleviate
 denial-of-service attacks on the system as a whole.
 
 A user client can perform the process of submitting the transaction and certificate itself or rely on third party