Typos

chapter1/bls-multisig/README.md

@@ -19,7 +19,7 @@ function getOperationPoint(Operation memory op) public view returns (BLS.G2Point
 }
 ```
 
-Second contract's method `verifyAndExecute` contains core logic for signature verification, let's walk through it.
+The contract's second method, `verifyAndExecute`, contains core logic for signature verification, let's walk through it.
 
 We start with aggregating the signers public keys into a single point on G1. This is done by simply invoking G1ADD precompile with all public keys. After this step, we will have a single point on G1 which represents the aggregated public key of all signers. We require signers to be sorted to ensure that all signers are unique and valid.
 
@@ -39,7 +39,7 @@ for (uint256 i = 0; i < operation.signers.length; i++) {
 }
 ```
 
-After that, we perform signature verification, by invoking the PAIRING precompile with the aggregated public key and the signature. Notice that we are invoking `getOperationPoint` method we've defined earlier to map the operation to a point on G2 which we can verify against the signature.
+After that, we perform signature verification, by invoking the PAIRING precompile with the aggregated public key and the signature. Notice that we are invoking the `getOperationPoint` method we've defined earlier to map the operation to a point on G2 which we can verify against the signature.
 ```solidity
 BLS.G1Point[] memory g1Points = new BLS.G1Point[](2);
 BLS.G2Point[] memory g2Points = new BLS.G2Point[](2);
@@ -58,7 +58,7 @@ If all of those steps are successful, we can execute the operation.
 
 ### Integration
 
-We've prepared 2 code snippets demonstrating integration of the above contract to aggregate and submit signatures obtained off-chain. Examples are written in [Rust](./rust) and [Python](./python). We will walk through the Rust code, but the Python code is very similar.
+We've prepared 2 code snippets demonstrating an integration of the above contract to aggregate and submit signatures obtained off-chain. Examples are written in [Rust](./rust) and [Python](./python). We will walk through the Rust code, but the Python code is very similar.
 
 We will use [blst](https://github.com/supranational/blst) library for BLS operations.
 

chapter1/delegate-p256/README.md

@@ -1,14 +1,14 @@
 # Delegating an account to a P256 key
 
-[EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) and [EIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md) allow to delegate control over an EOA to a P256 key. This has large potential for UX improvement as P256 keys are adopted by commonly used protocols like [Apple Secure Enclave](https://support.apple.com/en-au/guide/security/sec59b0b31ff/web) and [WebAuthn](https://webauthn.io). 
+[EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) and [EIP-7212](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7212.md) allow users to delegate control over an EOA to a P256 key. This has large potential for UX improvement as P256 keys are adopted by commonly used protocols like [Apple Secure Enclave](https://support.apple.com/en-au/guide/security/sec59b0b31ff/web) and [WebAuthn](https://webauthn.io). 
 
 ## Why do EIP-7702+EIP-7212 matter?
 The traditional flow of crypto onboarding experience can feel cumbersome: Users have to setup a wallet, back up their mnemonic phrase and make sure to keep it safe. What if there was a simpler and more secure way to manage private keys? Passkeys have already solved this problem by allowing users to authenticate using methods like Touch ID while keeping passwords safe. These keys are generated within secure hardware modules, such as Apple's Secure Enclave or a Trusted Platform Module (TPM), which are isolated from the operating system to protect them from being exposed. 
 
 EIP-7212 introduces a precompile for the **secp256r1** elliptic curve, a curve that is widely used in protocols like [Apple Secure Enclave](https://support.apple.com/en-au/guide/security/sec59b0b31ff/web) and [WebAuthn](https://webauthn.io). 
-EIP-7702 introduces a new transaction type, allowing an Externally Owned Accounts (EOAs) to function like a smart contract. This unlocks features such as gas sponsorship, transaction bundling or granting limited permissions to a sub-key.
+EIP-7702 introduces a new transaction type, allowing externally owned accounts (EOAs) to function like a smart contract. This unlocks features such as gas sponsorship, transaction bundling or granting limited permissions to a sub-key.
 
-This example demonstrates how the upcoming EIP's EIP-7720 and EIP-7212 (already live in Odyssey's Chapter 1), will enable you to use a passkey to sign an on-chain message, improving the onboarding experience for crypto novices using your Dapp.
+This example demonstrates how the upcoming EIP's EIP-7720 and EIP-7212 (already live in Odyssey's Chapter 1), will enable you to use a passkey to sign an onchain message, improving the onboarding experience for crypto novices using your Dapp.
 
 ## Steps involved
 
@@ -28,7 +28,7 @@ python p256.py gen
 
 This script will generate a `p256` private and public key pair, save them to `private.pem` and `public.pem` respectively, and print the keys in hex format.
 
-- Deploy [P256Delegation](../contracts/src/P256Delegation.sol) contract, which we will be delegating to
+- Deploy a [P256Delegation](../contracts/src/P256Delegation.sol) contract, which we will be delegating to
 
 ```bash
 forge create P256Delegation --private-key "0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
@@ -50,7 +50,7 @@ $ cast code 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
 0xef0100...
 ```
 
-- Prepare signature to be able to transact on behalf of the EOA account by using the `transact` function of the delegation contract. Let's generate a signature for sending 1 ether to zero address by using our P256 private key:
+- Prepare signature to be able to transact on behalf of the EOA account by using the `transact` function of the delegation contract. Let's generate a signature for sending 1 ether to the zero address by using our P256 private key:
 
 ```bash
 python p256.py sign $(cast abi-encode 'f(uint256,address,bytes,uint256)' $(cast call 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 'nonce()(uint256)') '0x0000000000000000000000000000000000000000' '0x' '1000000000000000000')
@@ -67,7 +67,7 @@ Let’s look at the command step-by-step
 
 The command output will respond with the signature r and s values. 
 
-- Send the message including signature via `transact` function of the delegation contract:
+- Send the message including signature via the `transact` function of the delegation contract:
 
 ```bash
 # use dev account

chapter1/eof/README.md

@@ -27,9 +27,9 @@ $ cast code <contract address>
 
 ## Inspecting EOF
 
-EOF defines separation of bytecode into sections which include header, code sections, container sections and data sections.
+EOF separates bytecode into sections that include a header, code sections, container sections and data sections.
 
-Let's take a look at such simple contract:
+Let's take a look at a simple contract:
 ```solidity
 contract Simple {}
 
@@ -88,11 +88,11 @@ Data section:
 +-----------------------------------------------------------------------------------------------------------------------------+
 ```
 
-We can see that contract has 1 container section. Container sections are used to store so-called subcontainers — contracts which can be deployed from our contract via `EOFCREATE` opcode. In this case our contract has a method deploying `Simple` contract, so we have a single subcontainer.
+We can see that the contract has 1 container section. Container sections are used to store so-called subcontainers — contracts which can be deployed from our contract via the `EOFCREATE` opcode. In this case our contract has a method deploying a `Simple` contract, so we have a single subcontainer.
 
-We can also see that our immutable `DATA` was placed into the data section. Data section is a separate part of bytecode which can store arbitrary immutable data which can be accessed via special `DATALOAD*` opcodes. The rest of the data section is contract metadata.
+We can also see that our immutable `DATA` was placed into the data section. The data section is a separate part of bytecode which can store arbitrary immutable data that can be accessed via special `DATALOAD*` opcodes. The rest of the data section is contract metadata.
 
-Deployed contract also has a single code section. Code sections are similar to functions. They accept fixed number of inputs and return fixed number of outputs. In this case optimizer decided to only include a single code section, but if you will try disabling the optimizer (with `--optimize=false`) you will see that without it we have 18 code sections each of which keeps either external function or internal compiler logic.
+The deployed contract also has a single code section. Code sections are similar to functions. They accept a fixed number of inputs and return a fixed number of outputs. In this case the optimizer decided to only include a single code section, but if you try disabling the optimizer (with `--optimize=false`) you will see that without it we have 18 code sections, each of which keeps either external function or internal compiler logic.
 
 
 ## Gas usage
@@ -154,4 +154,4 @@ assembly {
 }
 ```
 
-Additionally, EOF call instructions return 0 on success and not on failure. For more context, check out the [corresponding EIP](https://eips.ethereum.org/EIPS/eip-7069).
+Additionally, EOF call instructions, rather than a boolean, return 0 on success, 1 for revert, and 2 for failure. For more context, check out the [corresponding EIP](https://eips.ethereum.org/EIPS/eip-7069).

chapter1/erc20-fee/README.md

@@ -53,7 +53,7 @@ $ cast code $ALICE_ADDRESS
 SIGNED_AUTH=$(cast wallet sign-auth $ERC20_FEE --private-key $ALICE_PK)
 ```
 
-- Alice can sign an off-chain data to authorize anyone to send ERC20 on behave of Alice in exchange of ERC20 fee
+- Alice can sign an off-chain data to authorize anyone to send ERC20 on behalf of Alice in exchange of ERC20 fee
 
 ```bash
 ERC20_TRANSFER_CALLDATA=$(cast calldata 'transfer(address,uint256)' $CHARLES_ADDRESS 1000000000000000000)

chapter1/simple-7702/README.md

@@ -1,6 +1,6 @@
 # Simple delegate transactions with 7702
 
-Onboarding novices onto Ethereum can be challenging: Users need to create a new wallet, buy some ETH for gas before they can send their first transaction. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) unlocks features such as gas sponsorship, but also other use cases such as transaction bundling or granting limited permissions to a sub-key. This EIP introduces a new transaction type, allowing an Externally Owned Account (EOA) to function like a smart contract. Essentially, the way it works is that we can associate smart contract bytecode with an EOA account, allowing EOA to act like a smart contract.
+Onboarding novices onto Ethereum can be challenging: Users need to create a new wallet, buy some ETH for gas before they can send their first transaction. [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) unlocks features such as gas sponsorship, but also other use cases such as transaction bundling or granting limited permissions to a sub-key. This EIP introduces a new transaction type, allowing an Externally Owned Account (EOA) to function like a smart contract. Essentially, the way it works is that we can associate smart contract bytecode with an EOA account, allowing the EOA to act like a smart contract.
 
 This example demonstrates how EIP-7702 allows Alice to authorize a smart contract to execute a transaction on her behalf, with Bob sponsoring the gas fees for a seamless experience.
 
@@ -50,7 +50,7 @@ SIGNED_AUTH=$(cast wallet sign-auth $SIMPLE_DELEGATE_ADDRESS --private-key $ALIC
 cast send $ALICE_ADDRESS "execute((bytes,address,uint256)[])" "[("0x",$(cast az),0)]" --private-key $BOB_PK --auth $SIGNED_AUTH
 ```
 
-This is done by passing `--auth` flag, which can accept either an address or an encoded authorization. The transaction above would firstly apply a signed authorization, making Alice’s EOA to have bytecode delegating to deployed contract. After that it will be executed as a call to Alice which code would already include the newly added bytecode, allowing us to successfully call `execute` and transact on her behalf.
+This is done by passing the `--auth` flag, which can accept either an address or an encoded authorization. The transaction above would firstly apply a signed authorization, making Alice’s EOA have bytecode that delegates to a deployed contract. After that it will be executed as a call to Alice whose code would already include the newly added bytecode, allowing us to successfully call `execute` and transact on her behalf.
 
 - Verify that our command was successful, by checking Alice's code which now contains the [delegation designation](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md#delegation-designation) prefix `0xef01`:
 
@@ -59,7 +59,7 @@ $ cast code $ALICE_ADDRESS
 0xef0100...
 ```
 
-Note that in this over-simplified example, you’ll already see some issues e.g. anyone could send the transaction to any address on Alice's behalf, since there’s such restriction in the signed authorization. To address this issue, you would need to add additional setup functions which would be called on user's bytecode once delegation has been applied.
+Note that in this over-simplified example, you’ll already see some issues e.g. anyone could send the transaction to any address on Alice's behalf, since there’s no such restriction in the signed authorization. To address this issue, you would need to add additional setup functions which would be called on user's bytecode once delegation has been applied.
 
 ## Testing with foundry