Adjusted based on recommendations

packages/website/pages/docs/concepts/overview.mdx

@@ -81,7 +81,7 @@ Upon a proposer's submission of a block, the signature granted by the chosen pro
 
 As an additional incentive for proposers, the system incorporates the issuance of TKO tokens. This serves as an extra motivator, as proposing blocks alone may not always prove profitable, especially when considering Ethereum's on-chain fees plus the proving fee. The issuance of TKO tokens operates on a dynamic 'emission rate per second,' comparing each block proposal to the last.
 
-The reward depends on the proof service provider (and the agreement). For EOAs and Prover pools that implement the IERC1271 interface, the reward is disbursed in ETH. However, in cases where providers implement the IProver interface, the prover fee can be ETH, any other ERC20 tokens, or even NFTs, based on the negotiated terms.
+The reward depends on the proof service provider and the agreement. For EOAs and Prover pools that implement the IERC1271 interface, the reward is disbursed in ETH. However, in cases where providers implement the IProver interface, the prover fee can be ETH, any other ERC20 tokens, or even NFTs, based on the negotiated terms.
 
 To add a layer of security and commitment to the process, provers must provide a substantial amount of TKO tokens per block, effectively serving as insurance. In the unfortunate event of a failure to deliver the proof within the given time, a portion, specifically 1/4, is directed to the actual prover, while the remaining 3/4 are permanently burnt. Conversely, successful and timely proof delivery ensures the return of these tokens to the Prover.
 

packages/website/pages/docs/concepts/proposing.mdx

@@ -10,18 +10,18 @@ On Taiko, the next L2 state is known immediately and deterministically at the ti
 
 ## Building the blocks
 
-The Ethereum yellow paper has a well defined set of rules to compute the state transition. We use these same rules to take a proposed block, and compute the post-block state on Taiko. The high level overview of creating L2 blocks as follows:
+The Ethereum yellow paper has well-defined rules to compute the state transition. We use these same rules to take a proposed block, and compute the post-block state on Taiko. The high level overview of creating L2 blocks as follows:
 
 1. The system starts by creating a new L2 block with an anchor transaction. This anchor transaction is always the first transaction in the block even if the block is empty. (More about anchor transactions in the next section.)
-2. There are validity checks which are performed on node (or sometimes on protocol) level as well:
+2. There are validity checks performed at the node (or sometimes protocol) level as well:
 2.1 Asserts that the length of the transaction list does not exceed a predefined maximum (MAX_TX_LIST_BYTES), ensuring that the list is within the limits.
 2.2 The transaction list is (RLP) decoded into a list of transactions (txList). If the bytes are not decodeable it will result in an empty block.
-2.3 The amount of gas required to include transactions are available. (If a transaction cannot fit into a block, it is simply excluded from it, but the block is still valid with other transactions.)
+2.3 The amount of gas required to include transactions is available. (If a transaction cannot fit into a block, it is simply excluded from it, but the block is still valid with other transactions.)
 2.4 The transaction signature is valid.
 2.5 The transaction nonce is valid.
 2.6 The sender account has no contract code deployed (EIP-3607).
 2.7 The transaction's gas limit is no smaller than the intrinsic gas.
-2.8. The sender has enought balance to cover the transaction (gasLimit * gasPrice + tx.value).
+2.8. The sender has enough balance to cover the transaction (gasLimit * gasPrice + tx.value).
 
 ## Anchor transaction