Apply suggestions from code review

Co-authored-by: Sabrina <[email protected]>

content/tutorials/custom-zk-chain/10.index.md

@@ -14,7 +14,7 @@ This tutorial shows you how to use the `zk_inception` CLI to run an Elastic Chai
 - Make sure your machine satisfies the [system
   requirements](https://github.com/matter-labs/era-compiler-solidity/tree/main#system-requirements).
 - If you aren't already familiar with deploying smart contracts on ZKsync Era, please  refer to the first section of the [quickstart tutorial](https://docs.zksync.io/build/start-coding/quick-start/deploy-your-first-contract).
-- For background on the Elastic Chain or ZK chains, read the [ZK Chains](https://docs.zksync.io/zk-stack/concepts/zk-chains) section in our docs.
+- For background on the Elastic Chain or ZK chains, read the [ZK chains](https://docs.zksync.io/zk-stack/concepts/zk-chains) section in our docs.
 - Install the dependencies for the `zksync-era` repo by following the instructions [here](https://github.com/matter-labs/zksync-era/blob/main/docs/guides/setup-dev.md)
 (you can skip the "Environment" section).
 
@@ -30,11 +30,12 @@ There are two components needed for running a ZK chain locally:
 1. An Elastic Chain ecosystem to manage different chains
 2. A chain deployed within the ecosystem
 
-To setup both of these components, can use the `zk_inception` CLI.
+To setup both of these components, use the `zk_inception` CLI.
 You can use `cargo` to install the CLI with the command below:
 
 ```bash
-cargo install --git https://github.com/matter-labs/zksync-era/ --locked zk_inception --force
+cargo install --git https://github.com/matter-labs/zksync-era/ \
+--locked zk_inception --force
 ```
 
 Once you have that installed, the first step is to create a new ecosystem with the `ecosystem create` command:
@@ -155,7 +156,7 @@ To see more detailed logs of what is happening at each step, you can add the `--
 To summarize, the `init` command:
 
 - Checks to see if your environment has the necessary dependencies.
-- Compiles and deploys all of necessary contracts for the ecosystem.
+- Compiles and deploys all of the necessary contracts for the ecosystem.
 - Deploys `zk_chain_1` to the ecosystem.
 - Sets up a database for the default chain (in this case `zk_chain_1`).
 - Deploys a paymaster contract and some test ERC20 contracts (if selected) to use for development.
@@ -217,7 +218,9 @@ For testing purposes, we'll use one of the rich wallets as both the sender and r
 To see that it worked, let's check the balance of that address on `zk_chain_1`:
 
 ```bash
-zksync-cli wallet balance --address 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 --rpc http://localhost:3050
+zksync-cli wallet balance \
+--address 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 \
+--rpc http://localhost:3050
 ```
 
 Now this address has ETH available on `zk_chain_1` to use for testing.

content/tutorials/custom-zk-chain/20.customizing-your-chain.md

@@ -9,7 +9,7 @@ Let's try customizing a new chain by using a custom ERC20 base token.
 
 For the first release of the ZK stack, the base tokens you can use for your chain must be whitelisted.
 The whitelisted addresses are stored and checked in the `BridgeHub` contract on the L1.
-In the future it will be possible to add a new token in a permissionless proccess.
+In the future it will be possible to add a new token in a permissionless process.
 
 For now, you have the ability to whitelist tokens in your local ecosystem.
 
@@ -149,10 +149,11 @@ npx hardhat ignition deploy ./ignition/modules/CustomBaseToken.ts --network loca
 Select `y` to confirm to deploy the contract to the `localRethNode`.
 After deploying, the token contract address should be logged in your console.
 
-Let's verify that the tokens were minted to the deployer address using the `cast` CLI:
+Let's verify that the tokens were minted to the deployer address using the Foundry `cast` CLI:
 
 ```bash
-cast balance --erc20 0xYOUR_TOKEN_ADDRESS 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 --rpc-url http://localhost:8545
+cast balance --erc20 <0xYOUR_TOKEN_ADDRESS> 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 \
+--rpc-url http://localhost:8545
 ```
 
 Now that you have some tokens, the next step is to send some to the governor's address on the L1 so that you can register and deploy your chain.
@@ -167,7 +168,9 @@ cast send 0xYOUR_TOKEN_ADDRESS "transfer(address,uint256)" 0x_YOUR_GOVERNOR_ADDR
 To verify that this worked, check the balance of the governor's address:
 
 ```bash
-cast balance --erc20 0xYOUR_TOKEN_ADDRESS 0x_YOUR_GOVERNOR_ADDRESS --rpc-url http://localhost:8545
+cast balance --erc20 <0xYOUR_TOKEN_ADDRESS> \
+<0x_YOUR_GOVERNOR_ADDRESS> \ 
+--rpc-url http://localhost:8545
 ```
 
 ## Creating a new chain
@@ -208,7 +211,7 @@ $ zk_inception chain create
 │  Custom
 │
 ◇  What is the token address?
-│  0x_YOUR_TOKEN_ADDRESS
+│  <0x_YOUR_TOKEN_ADDRESS>
 │
 ◇  What is the base token price nominator?
 │  1
@@ -231,7 +234,7 @@ Next, initialize the chain in the ecosystem with:
 zk_inception chain init
 ```
 
-This time select no for the option to deploy a paymaster contract.
+This time select *no* for the option to deploy a paymaster contract.
 Use the default answers for all other prompts.
 
 Now that the chain is initialized, you can start the chain server:
@@ -248,7 +251,9 @@ Base tokens can not be minted on the L2 without being backed by the correspondin
 Open a new terminal and use the `zksync-cli` to bridge the tokens with the command below:
 
 ```bash
-npx zksync-cli bridge deposit --token 0x_YOUR_TOKEN_ADDRESS --rpc=http://localhost:3050 --l1-rpc=http://localhost:8545
+npx zksync-cli bridge deposit --token <0x_YOUR_TOKEN_ADDRESS> \
+--rpc=http://localhost:3050 \
+--l1-rpc=http://localhost:8545
 ```
 
 ```shell
@@ -260,7 +265,9 @@ npx zksync-cli bridge deposit --token 0x_YOUR_TOKEN_ADDRESS --rpc=http://localho
 To verify that this worked, let's check the new balance of our address on the L2 chain:
 
 ```bash
-zksync-cli wallet balance --address 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 --rpc http://localhost:3050
+zksync-cli wallet balance \
+--address 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049 \
+--rpc http://localhost:3050
 ```
 
 Note that we aren't checking for any specific token address here.
@@ -271,14 +278,16 @@ You can follow the steps in the previous section to deploy a contract to the new
 
 ## Bridging ETH to your chain
 
-If your ERC20 token bridged to the L2 "looks" like ETH, then what happens if you bridge ETH to your custom chain?
+If your ERC20 token bridged to the L2 "acts" like ETH, then what happens if you bridge ETH to your custom chain?
 
 The answer is that if you try to bridge regular ETH to this chain, it will just use a different token contract address.
 
 You can try this out by depositing ETH from the L1 to this new chain:
 
 ```bash
-npx zksync-cli bridge deposit --rpc=http://localhost:3050 --l1-rpc=http://localhost:8545
+npx zksync-cli bridge deposit \
+--rpc=http://localhost:3050 \
+--l1-rpc=http://localhost:8545
 ```
 
 ```shell
@@ -287,8 +296,7 @@ npx zksync-cli bridge deposit --rpc=http://localhost:3050 --l1-rpc=http://localh
 ? Recipient address on L2 0x36615Cf349d7F6344891B1e7CA7C72883F5dc049
 ```
 
-If you run the previous command to check the base token balance again, note how the balance is still `5`.
-This is because you have to look at the L2 token balance for ETH.
+If you run the previous command to check the base token balance again, note how the balance is still `5`. Because ETH is no longer the base token, it has a different token address on L2 you will need to reference.
 To find the L2 token address for ETH, you can use the `l2TokenAddress` method available through `zksync-ethers`.
 
 To try this out, open the `zk-chain-test` folder from the previous section,
@@ -299,7 +307,7 @@ mkdir scripts
 touch scripts/checkBalance.ts
 ```
 
-Next, copy and paste the script below to into the `checkBalance.ts` file:
+Next, copy and paste the script below into the `checkBalance.ts` file:
 
 ```ts
 import { ETH_ADDRESS_IN_CONTRACTS } from "zksync-ethers/build/utils.js";