fix: typos across various docs (#867)

Co-authored-by: iwantanode <[email protected]>
Co-authored-by: Dushyant Goswami <[email protected]>
Co-authored-by: pandabadger <[email protected]>
Co-authored-by: Vehorny <[email protected]>

docs/build/developer-reference/differences-with-ethereum.md

@@ -89,7 +89,7 @@ Since the bytecode differs from Ethereum as zkSync uses a modified version of th
 For calls, you specify a memory slice to write the return data to, e.g. `out` and `outsize` arguments for
 `call(g, a, v, in, insize, out, outsize)`. In EVM, if `outsize != 0`, the allocated memory will grow to `out + outsize`
 (rounded up to the words) regardless of the `returndatasize`. On zkSync Era, `returndatacopy`, similar to `calldatacopy`,
-is implemented as a cycle iterating over return data with a few additional checks and trigerring a panic if
+is implemented as a cycle iterating over return data with a few additional checks and triggering a panic if
 `out + outsize > returndatasize` to simulate the same behavior as in EVM.
 
 Thus, unlike EVM where memory growth occurs before the call itself, on zkSync Era, the necessary copying of return data

docs/build/developer-reference/fee-model.md

@@ -52,7 +52,7 @@ On zkSync Era this varies because we support custom and paymaster accounts. Thes
 
 The transaction fee estimate depends on the entire transaction flow, including validation and execution. The `eth_estimateGas` function uses binary search to find the smallest gas value under which the transaction succeeds.
 
-For more information, find out [how to estimate gas for various transactions types](../tutorials/how-to/estimate-gas.md).
+For more information, find out [how to estimate gas for various transaction types](../tutorials/how-to/estimate-gas.md).
 
 For any Rust developers interested in the zkSync Era implementation for gas estimation, see the [Rust code in our repo](https://github.com/matter-labs/zksync-era/blob/48fe6e27110c1fe1a438c5375fb256890e8017b1/sdk/zksync-rs/src/operations/execute_contract.rs#L129).
 

docs/build/developer-reference/l1-l2-interop.md

@@ -46,6 +46,6 @@ L2 to L1 communication is based on transferring the data as a message, and not o
 
 ## Priority queue
 
-1. All transactions types are supported by the priority queue.
+1. All transaction types are supported by the priority queue.
 
 2. The priority queue must be fully permissionless to prevent malicious activity. For example, malicious users might send multiple transactions which push up the block gas limit to unworkable levels. To mitigate against this, submitting transactions to the priority queue is no longer free and users must pay a fee to the operator. To obtain the cost for sending an L2 to L1 message, please refer to [step 5 of how to send an L1 to L2 transaction](../../build/tutorials/how-to/send-transaction-l1-l2.md#step-by-step).

docs/build/sdks/go/accounts.md

@@ -394,7 +394,7 @@ fmt.Println("L1 deposit transaction: ", tx.Hash())
 
 ### `EstimateGasDeposit`
 
-Estimates the amount of gas required for a deposit transaction on L1 network. Gas of approving ERC20 token is not included in estimation.
+Estimates the amount of gas required for a deposit transaction on L1 network. Gas of approving ERC20 token is not included in the estimation.
 
 #### Inputs
 
@@ -456,11 +456,11 @@ Proves the inclusion of the L2 -> L1 withdrawal message.
 
 #### Inputs
 
-| Parameter        | Type                                                         | Description                                                                                                                |
-| ---------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
-| `auth`           | [`*TransactOpts`](types/accounts.md#transactopts) (optional) | Transaction options.                                                                                                       |
-| `withdrawalHash` | `common.Hash`                                                | Hash of the L2 transaction where the withdrawal was initiated.                                                             |
-| `index`          | `int`                                                        | In case there where multiple withdrawals in one transaction, you may pass an index of the withdrawal you want to finalize. |
+| Parameter        | Type                                                         | Description                                                                                                               |
+| ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
+| `auth`           | [`*TransactOpts`](types/accounts.md#transactopts) (optional) | Transaction options.                                                                                                      |
+| `withdrawalHash` | `common.Hash`                                                | Hash of the L2 transaction where the withdrawal was initiated.                                                            |
+| `index`          | `int`                                                        | In case there were multiple withdrawals in one transaction, you may pass an index of the withdrawal you want to finalize. |
 
 ```go
 FinalizeWithdraw(auth *TransactOpts, withdrawalHash common.Hash, index int) (*types.Transaction, error)

docs/build/sdks/go/features.md

@@ -21,7 +21,7 @@ This document will focus solely on how to pass these arguments to the SDK.
 
 ## EIP-712 Metadata
 
-[`EIP712Meta`](types/types.md#eip712meta) contains EIP-712 transaction metadata. Following objects contain `EIP712Meta` and provides working with
+[`EIP712Meta`](types/types.md#eip712meta) contains EIP-712 transaction metadata. The following objects contain `EIP712Meta` and provides working with
 EIP-712 transactions:
 
 - [`types.CallMsg`](types/types.md#callmsg)

docs/build/support/faq.md

@@ -169,7 +169,7 @@ Our [Block Explorer](https://explorer.zksync.io) will show everything you may ne
 
 The contract address derivation formula is different from the regular EVM approach. Even if a contract is deployed from the same account address with the same nonce, the zkSync Era contract address will not be the same as it is in another EVM network. This means, for example, that no one will be able to claim an existing Ethereum address of your protocol to try to trick users into interacting with a malicious version of it.
 
-## What is the storage limit for smart contract on zkSync Era?
+## What is the storage limit for smart contracts on zkSync Era?
 
 The current limit is 3600000000 gas.
 

docs/build/tooling/hardhat/getting-started.md

@@ -189,7 +189,7 @@ export default async function (hre: HardhatRuntimeEnvironment) {
   // // Wait until the deposit is processed on zkSync
   // await depositHandle.wait();
 
-  // Deploy this contract. The returned object will be of a `Contract` type, similarly to ones in `ethers`.
+  // Deploy this contract. The returned object will be of a `Contract` type, similar to ones in `ethers`.
   // `greeting` is an argument for contract constructor.
   const parsedFee = ethers.formatEther(deploymentFee);
   console.log(`The deployment is estimated to cost ${parsedFee} ETH`);

docs/build/tooling/hardhat/hardhat-zksync-deploy.md

@@ -97,7 +97,7 @@ class Deployer {
 
   /**
     * Sends a deploy transaction to the zkSync network.
-    * For now it uses defaults values for the transaction parameters:
+    * For now it uses default values for the transaction parameters:
     *
     * @param artifact The previously loaded artifact object.
     * @param constructorArguments The list of arguments to be passed to the contract constructor.
@@ -163,7 +163,7 @@ This plugin facilitates the compilation and deployment of missing libraries for
 Starting from version 1.13.14, the zksolc compiler has been enhanced to identify missing libraries.
 :::
 
-Complex library dependecy tree is also supported. It ensures libraries are compiled and deployed in a structured manner, starting from the most foundational library to the topmost dependent one.
+Complex library dependency tree is also supported. It ensures libraries are compiled and deployed in a structured manner, starting from the most foundational library to the topmost dependent one.
 
 Example:
 

docs/build/tooling/node-providers.md

@@ -25,7 +25,7 @@ head:
 
 ### DRPC
 
-[DRPC](https://drpc.org/) offers access to distributed network of independent third-party partners and public nodes for Base. They provide a free tier that allows for an unlimited amount of requests over public nodes, or a paid tier which provides access to all providers, as well as other additional features.
+[DRPC](https://drpc.org/public-endpoints/zksync) offers access to distributed network of independent third-party partners and public nodes for Base. They provide a free tier that allows for an unlimited amount of requests over public nodes, or a paid tier which provides access to all providers, as well as other additional features.
 
 ### Quicknode
 

docs/build/tooling/zksync-cli/examples/contract-interaction.md

@@ -32,7 +32,7 @@ The `npx zksync-cli contract read` command executes read-only methods on contrac
 
 ### Read Options
 
-You do not need to specify options bellow, you will be prompted to enter them if they are not specified.
+You do not need to specify options below, you will be prompted to enter them if they are not specified.
 
 - `--chain <chain-name>`: Select the chain to use
 - `--rpc <url>`: Provide RPC URL instead of selecting a chain
@@ -58,7 +58,7 @@ The `npx zksync-cli contract write` command performs write operations on smart c
 
 ### Write Options
 
-You do not need to specify options bellow, you will be prompted to enter them if they are not specified.
+You do not need to specify options below, you will be prompted to enter them if they are not specified.
 
 - `--chain <chain-name>`: Select the chain to use
 - `--rpc <url>`: Provide RPC URL instead of selecting a chain

docs/build/tutorials/dapp-development/gated-nft-paymaster-tutorial.md

@@ -12,7 +12,7 @@ Discover how to construct a tailored paymaster that enables users to sidestep ga
 - Write a `mint` function for the `ERC721.sol` contract.
 - Design and implement the validation logic for the `ERC721GatedPaymaster.sol` contract.
 - Deploy `Greeter.sol`, `ERC721.sol`, and `ERC721GatedPaymaster.sol` contracts.
-- Connect our frontend application with users MetaMask wallets.
+- Connect our frontend application with users' MetaMask wallets.
 - Initialize our contracts to facilitate interaction on the client side.
 - Fetch data to display in a React component.
 - Harness the capabilities of our paymaster based on NFT possession.
@@ -380,7 +380,7 @@ function validateAndPayForPaymasterTransaction(
 }
 ```
 
-Amazing! We have successfully written the smart contracts lets proceed to deploy them using the deployment scripts provided.
+Amazing! We have successfully written the smart contracts let's proceed to deploy them using the deployment scripts provided.
 
 #### Contract Deployment
 
@@ -398,7 +398,7 @@ The output of the command should resemble the following:
 Successfully compiled 43 Solidity files
 ```
 
-2. Deploy the contracts to zkSync Era Testnet. This will also programatically verify the contracts on zkSync Era Testnet.
+2. Deploy the contracts to zkSync Era Testnet. This will also programmatically verify the contracts on zkSync Era Testnet.
 
 ```bash
 yarn deploy:contracts
@@ -499,7 +499,7 @@ cd app/components/WalletButton.tsx
 
 2. Let implement the requirements for the `connectWallet` function
 
-The `connectWallet` function requirements indicates that we need to ensure we are connected to the correct network, connect to the users MetaMask account, store some variables using React's Context API, and then call `initContracts` function to instantiate our contracts. Lets proceed to do that:
+The `connectWallet` function requirements indicates that we need to ensure we are connected to the correct network, connect to the users MetaMask account, store some variables using React's Context API, and then call `initContracts` function to instantiate our contracts. Let's proceed to do that:
 
 ```typescript
 const connectWallet = async () => {

docs/build/tutorials/smart-contract-development/account-abstraction/daily-spend-limit.md

@@ -928,7 +928,7 @@ Time to reset limit:  1683027630
 
 ## Perform ETH Transfer
 
-Let's test the `SpendLimit` contract works to make it refuses ETH transfers that exceed the daily limit.
+Let's test the `SpendLimit` contract works to make it refuse ETH transfers that exceed the daily limit.
 
 1. Create `transferETH.ts` and copy/paste the example code below, replacing the placeholder constants as before and adding an account address for `RECEIVER_ACCOUNT`.
 

docs/zk-stack/concepts/transaction-lifecycle.md

@@ -87,7 +87,7 @@ For more information on when a transaction is considered complete and unalterabl
 
 ## Transaction types
 
-For compatibility, the majority of zkSync Era transactions types are similar to those on Ethereum.
+For compatibility, the majority of zkSync Era transaction types are similar to those on Ethereum.
 
 :::tip
 The transaction type hex value is output by any RPC method call which returns a transaction type, such as [`eth_getTransactionByHash`](https://ethereum.github.io/execution-apis/api-documentation/) for example.