fix link and typos in BindGen readme

op-bindings/ast/canonicalize.go

@@ -63,7 +63,7 @@ func CanonicalizeASTIDs(in *solc.StorageLayout, monorepoBase string) *solc.Stora
 			continue
 		}
 
-		// The storage types include the size when its a fixed size.
+		// The storage types include the size when it's a fixed size.
 		// This is subject to breaking in the future if a type with
 		// an ast id is added in a fixed storage type. We don't want
 		// to skip a type with `_storage` in it if it has a subtype

op-bindings/bindgen/README.md

@@ -33,12 +33,12 @@ If you're running the CLI inside the Optimism monorepo, please make sure you've
 
 # Running BindGen
 
-BindGen can be ran one of two ways:
+BindGen can be ran in one of two ways:
 
 1. Using the provided [Makefile](../Makefile) which defaults some of the required flags
 2. Executing the CLI directly with `go run`, or building a Go binary and executing it
 
-Before executing BindGen, please review the [artifacts.json](../artifacts.json) file which specifies what contracts BindGen should generate Go bindings and metadata files for. More information on how to configure `artifacts.json` can be found [here]().
+Before executing BindGen, please review the [artifacts.json](../artifacts.json) file which specifies what contracts BindGen should generate Go bindings and metadata files for. More information on how to configure `artifacts.json` can be found [here](#anatomy-of-artifactsjson).
 
 ## Using the Makefile Commands
 
@@ -163,7 +163,7 @@ Flag                   | Type   | Description
 
 **Note** While we encourage hacking on the OP stack, we are not actively looking to integrate more contracts to the official OP stack genesis.
 
-BindGen uses the provided `contracts-list` to generate Go bindings and metadata files which are used when building the L2 genesis. The first step in adding a new preinstall to L2 genesis is adding the contract to your `contracts-list` (by default this list if [artifacts.json](../artifacts.json)).
+BindGen uses the provided `contracts-list` to generate Go bindings and metadata files which are used when building the L2 genesis. The first step in adding a new preinstall to L2 genesis is adding the contract to your `contracts-list` (by default this list is [artifacts.json](../artifacts.json)).
 
 ## Anatomy of `artifacts.json`
 
@@ -253,7 +253,7 @@ Name                   | Description
 `deploymentSalt` | If the contract was deployed using CREATE2 or a CREATE2 proxy deployer, here is where you specify the salt that was used for creation
 `deployer` | The address used to deploy the contract, used to mimic CREATE2 deployments
 `abi` | The ABI of the contract, required if the contract is **not** verified on Etherscan
-`initBytecode` | The initialization bytecode for the contract, required if the contract is apart of the initialization of another contract (i.e. the `input` data of the deployment transaction contains initialization bytecode other than what belongs to the specific contract you're adding)
+`initBytecode` | The initialization bytecode for the contract, required if the contract is a part of the initialization of another contract (i.e. the `input` data of the deployment transaction contains initialization bytecode other than what belongs to the specific contract you're adding)
 
 ### Adding A New `"remote"` Contract
 
@@ -291,7 +291,7 @@ switch contract.Name {
 ...
 ```
 
-If you contract is verified on Etherscan, doesn't contain any Solidity `immutable`s, and doesn't require any special handling, than you most likely can add your contract's `name` to the first switch case. The will use the `standardHandler` which:
+If your contract is verified on Etherscan, doesn't contain any Solidity `immutable`s, and doesn't require any special handling, then you most likely can add your contract's `name` to the first switch case. Then will use the `standardHandler` which:
 
 1. Fetches the required contract metadata from Etherscan (i.e. initialization and deployed bytecode, ABI, deployment transaction hash, etc.)
 2. Compares the retrieved deployed bytecode from Etherscan against the response of `eth_codeAt` from an RPC node for each network specified in `RemoteContract.deployments` (this is a sanity check to verify Etherscan is returning correct data)
@@ -304,9 +304,9 @@ If you contract is verified on Etherscan, doesn't contain any Solidity `immutabl
 
 All other default `"remote"` contract have some variation of the above execution flow depending on the nuances of each contract. For example:
 
-- `Create2Deployer`'s initialization and deployed bytecode is expected to differ from it's Optimism Mainnet deployment
-- `MultiSend_v130` has an `immutable` Solidity variable the resolves to `address(this)`, so we can't use the deployment bytecode from Ethereum Mainnet, we must get it's deployment bytecode from Optimism Mainnet
-- `SenderCreator` is deployed by `EntryPoint`, so it's initialization bytecode is provided in [artifacts.json](../artifacts.json) and not being fetched from Etherscan like other contracts
+- `Create2Deployer`'s initialization and deployed bytecode is expected to differ from its Optimism Mainnet deployment
+- `MultiSend_v130` has an `immutable` Solidity variable the resolves to `address(this)`, so we can't use the deployment bytecode from Ethereum Mainnet, we must get its deployment bytecode from Optimism Mainnet
+- `SenderCreator` is deployed by `EntryPoint`, so its initialization bytecode is provided in [artifacts.json](../artifacts.json) and not being fetched from Etherscan like other contracts
 
 #### Contracts that Don't Make Good Preinstalls
 
@@ -317,7 +317,7 @@ Not every contract can be added as a preinstall, and some contracts have nuances
 - Related to above, contracts that may become deprecated/unsupported relatively soon
   - As mentioned above, you're limited to options A, B, or C
 - Upgradeable Contracts
-  - While it's certainly feasible to preinstall an upgradeable contract, great care should be taken to minimize security risks to users if the contract is upgraded to a malicious or buggy implementation. Understanding who has the ability to upgrade the contract is key to avoiding this. Additionally, user's might be expecting a preinstall to do something and may be caught off guard if the implementation was upgraded without their knowledge
+  - While it's certainly feasible to preinstall an upgradeable contract, great care should be taken to minimize security risks to users if the contract is upgraded to a malicious or buggy implementation. Understanding who has the ability to upgrade the contract is key to avoiding this. Additionally, users might be expecting a preinstall to do something and may be caught off guard if the implementation was upgraded without their knowledge
 - Contracts with Privileged Roles and Configuration Parameters
   - Similar to the upgradeable contracts, simply having an owner or other privileged role with the ability to make configuration changes can present a security risk and result in unexpected different behaviors across chains.
 - Contracts that have dependencies