Naming + starting typos

src/zksync-specifics/cheatcodes/zk-use-factory-dep.md

@@ -8,7 +8,7 @@ function zkUseFactoryDep(string calldata name) external pure;
 
 ### Description
 
-Marks a given contract as a factory dependency only for the next CREATE or CALL, unmarking it afterwards, similar to [`prank`](../../cheatcodes/prank.md).
+Sets a flag on a given contract as a factory dependency only for the next `CREATE` or `CALL` operation, clearing the flag afterwards, similar to [`prank`](../../cheatcodes/prank.md).
 
 This cheatcode is useful when deploying contracts through factories that do not directly depend on a given contract, as it allows explicitly marking this type of contract as a factory dependency, enabling the factory to deploy the contract.
 More information on factory dependencies can be found in the [official ZKsync docs](https://docs.zksync.io/build/developer-reference/ethereum-differences/contract-deployment#note-on-factory_deps).

src/zksync-specifics/cheatcodes/zk-vm-skip.md

@@ -8,7 +8,7 @@ function zkVmSkip() external pure;
 
 ### Description
 
-When running in zkEVM context, skips the next CREATE or CALL, executing it on the EVM instead.
+When running in zkEVM context, skips the next `CREATE` or `CALL`, executing it on the EVM instead.
 All `CREATE`s executed within this skip, will automatically have `CALL`s to their target addresses
 executed in the EVM, and need not be marked with this cheatcode at every usage location.
 

src/zksync-specifics/examples/smart-account.md

@@ -208,7 +208,7 @@ contract TwoUserMultisig is IAccount, IERC1271 {
             // in order for the fee estimation to work correctly
             _signature = new bytes(130);
 
-            // Making sure that the signatures look like a valid ECDSA signature and are not rejected rightaway
+            // Making sure that the signatures look like a valid ECDSA signature and are not rejected right away
             // while skipping the main verification process.
             _signature[64] = bytes1(uint8(27));
             _signature[129] = bytes1(uint8(27));

src/zksync-specifics/gas.md

@@ -3,7 +3,7 @@
 ### Gas reported back to the EVM
 Foundry has an `isolate` mode for the EVM where all `CALL`/`CREATE` operations at the root level of a test (i.e: with depth 1) will be intercepted and treated as independent transactions. This allows for accounting of the actual transaction gas and include for example the fixed 21000 gas cost charged to the user.
 
-Running in zkEVM mode is anologous to running in `isolate` mode but using the zkEVM instead. Every `CALL`/`CREATE` will be intercepted, a transaction representing the operation built, and finally a VM with that transaction in the bootloader's heap will be spawned and run in order to simulate the execution of that transaction. The gas used reported back to the EVM, and hence the one seen on traces and gas-reports, is what would be charged to the user for submitting that transaction. That value differs from the computational cost of running the called contract code and includes: 
+Running in zkEVM mode is analogous to running in `isolate` mode, but using the zkEVM is better. Every `CALL`/`CREATE` will be intercepted, a transaction representing the operation built. Finally, a VM with that transaction in the bootloader's heap will be spawned and run to simulate the execution of that transaction. The gas used is reported back to the EVM; hence, the one seen on traces and gas reports would be charged to the user for submitting that transaction. That value differs from the computational cost of running the called contract code and includes: 
 
   1. Intrinsic costs: Overhead charged on each transaction.
   2. Validation costs: Gas spent on transaction validation. May vary depending on the account making the transaction. See [Account Abstraction](https://docs.zksync.io/build/developer-reference/account-abstraction) docs.
@@ -22,7 +22,7 @@ The gas cost mentioned above is influenced by transaction and network values. Th
 
 2. Network Params:
 
-* `fair_l2_gas_price`: set to the minumum of `max_fee_per_gas` and the base fee of the root evm transaction (e.g: when running tests, the value of the `--base-fee` option).
+* `fair_l2_gas_price`: set to the minimum of `max_fee_per_gas` and the base fee of the root evm transaction (e.g: when running tests, the value of the `--base-fee` option).
 * `l1_gas_price`: set to the same as `fair_l2_gas_price`, with a minimum value of `1000`.
 
 #### Deriving relevant transaction gas values

src/zksync-specifics/limitations/compilation.md

@@ -4,7 +4,7 @@ These limitations apply to `zksolc` compilation of source contracts.
 
 ### Contract Bytecode Access
 
-Contract bytecode [cannot](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#extcodecopy) be accessed on zkEVM architecture, therefore EXTCODECOPY always produces a compile-time error with zksolc. As such using `address(..).code` in a solidity contract will produce a compile-time error.
+Contract bytecode [cannot](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#extcodecopy) be accessed on zkEVM architecture, therefore `EXTCODECOPY` always produces a compile-time error with zksolc. As such using `address(..).code` in a solidity contract will produce a compile-time error.
 
 ```solidity
 contract FooBar {
@@ -79,9 +79,9 @@ There are three possible solutions to address this issue:
     }
     ```
 
-### Non inlinable libraries
+### _Non-inlinable_ libraries
 
-Compiling contracts without linking non-inlinable libraries is currently not supported. Libraries need to be deployed before building contracts using them. 
+Compiling contracts without linking _non-inlinable_ libraries is currently not supported. Libraries need to be deployed before building contracts using them. 
 
 When building the contracts, the addresses need to be passed using the `libraries` config which contains a list of `CONTRACT_PATH`:`ADDRESS` mappings.
 

src/zksync-specifics/limitations/events.md

@@ -1,6 +1,6 @@
 ## Emitted Events
 
-zkEVM in addition to user events, emits its [own system events](https://github.com/search?q=repo%3Amatter-labs%2Fera-contracts+%2Fevent+%5BA-Za-z%5D%2B%5C%28%2F&type=code), like `Transfer`, `Withdrawl`, `ContractCreated`, etc. These events are not printed as part of traces, as currently it's not trivial to match emitted events with zkEVM traces.
+zkEVM in addition to user events, emits its [own system events](https://github.com/search?q=repo%3Amatter-labs%2Fera-contracts+%2Fevent+%5BA-Za-z%5D%2B%5C%28%2F&type=code), like `Transfer`, `Withdraw`, `ContractCreated`, etc. These events are not printed as part of traces, as currently it's not trivial to match emitted events with zkEVM traces.
 
 These system events can be observed via setting the `RUST_LOG` env variable:
 ```bash

src/zksync-specifics/limitations/general.md

@@ -92,7 +92,7 @@ Any code making assumptions about bytecode hashes around EVM-scope, would need t
 
 ### Address Derivation
 
-zkEVM uses a different CREATE and CREATE2 [address derivation strategy](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#address-derivation) compared to EVM. This can lead to issues for tests that have the CREATE2 addresses hard-coded for EVM. These tests would therefore need to be updated to reflect the ZKsync derived addresses.
+zkEVM uses a different `CREATE` and `CREATE2` [address derivation strategy](https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions#address-derivation) compared to EVM. This can lead to issues for tests that have the CREATE2 addresses hard-coded for EVM. These tests would therefore need to be updated to reflect the ZKsync derived addresses.
 
 ```javascript
 function create2Address(sender: Address, bytecodeHash: BytesLike, salt: BytesLike, input: BytesLike) {