diff --git a/DEVNET.md b/DEVNET.md
index 664e010d..2bc1bace 100644
--- a/DEVNET.md
+++ b/DEVNET.md
@@ -10,7 +10,7 @@ A publicly accessible Lilypad network.
 
 ### Resource providers
 
-As is, the network cannot execute jobs, it needs resource providers to connect to the network and these in turn will be the ones running the jobs. Follow this instructions to [run a node in the Lilypad network](https://docs.lilypad.tech/lilypad/lilypad-milky-way-reference/run-a-node).
+As is, the network cannot execute jobs, it needs resource providers to connect to the network and these in turn will be the ones running the jobs. Follow these instructions to [run a node in the Lilypad network](https://docs.lilypad.tech/lilypad/lilypad-milky-way-reference/run-a-node).
 
 ## Deployments
 
@@ -49,7 +49,7 @@ These steps have been used for [AWS](https://aws.amazon.com/) so maybe some chan
 
 ### VM instance
 
-The VM should have a running Docker daemon and should be able to pull an image from the chosen container registry. These instructions asssume an Ubuntu image.
+The VM should have a running Docker daemon and should be able to pull an image from the chosen container registry. These instructions assume an Ubuntu image.
 
 Create a virtual machine to execute the component. When creating the VM, attach an instance profile that gives it access to pull from an ECR registry. In our ops setup, we have a role named `LilypadService` that has the necessary permissions.
 
diff --git a/LOCAL_DEVELOPMENT.md b/LOCAL_DEVELOPMENT.md
index ae811d5d..0292099c 100644
--- a/LOCAL_DEVELOPMENT.md
+++ b/LOCAL_DEVELOPMENT.md
@@ -25,9 +25,9 @@ Order matters because the `solver`, `job creator` and `resource provider` will r
 
 ### 1. Blockchain node
 
-The node can can run directly from an existing docker image. It will initialize itself to a blank state with the admin address holding the funds to deploy the smart contracts (including the Lilypad token) and fund the accounts used by the different services. The blockchain is ephemeral, meaning every time you restart the node the state will be reset, you can work around this by keeping the node active if needed.
+The node can run directly from an existing docker image. It will initialize itself to a blank state with the admin address holding the funds to deploy the smart contracts (including the Lilypad token) and fund the accounts used by the different services. The blockchain is ephemeral, meaning every time you restart the node the state will be reset, you can work around this by keeping the node active if needed.
 
-These are the commands to run the node and boot the network: `./stack chain-clean` (the first time this won't do anything, but I find it better to get in the habit of resetting artifacts everytime), `./stack chain` to run the node and `./stack chain-boot` to fund the accounts with ETH (for gas fees), compile the contracts, add Golang bindings to use the contracts directly in go code, deploy the contracts and fund the accounts with Lilypad tokens.
+These are the commands to run the node and boot the network: `./stack chain-clean` (the first time this won't do anything, but I find it better to get in the habit of resetting artifacts every time), `./stack chain` to run the node and `./stack chain-boot` to fund the accounts with ETH (for gas fees), compile the contracts, add Golang bindings to use the contracts directly in go code, deploy the contracts and fund the accounts with Lilypad tokens.
 
 #### Summary of command sequence
 
@@ -50,7 +50,7 @@ This process can be executed directly if Golang has been installed or in a docke
 
 ### 4. IPFS node
 
-This process can be run directly using an IPFS Kubo binary. [Download a Kubo binary](https://dist.ipfs.tech/#kubo) for your platform and architecture. Initiliaze an repository where Kubo will store settings and internal data:
+This process can be run directly using an IPFS Kubo binary. [Download a Kubo binary](https://dist.ipfs.tech/#kubo) for your platform and architecture. Initiliaze a repository where Kubo will store settings and internal data:
 
 ```sh
 ipfs init
diff --git a/docs/smart-contract-jobs.md b/docs/smart-contract-jobs.md
index 3b34446c..a1e7b56b 100644
--- a/docs/smart-contract-jobs.md
+++ b/docs/smart-contract-jobs.md
@@ -1,6 +1,6 @@
 ## Running jobs from smart contracts
 
-We have deloyed the [LilypadOnChainJobCreator](../hardhat/contracts/LilypadOnChainJobCreator.sol) contract which you can use to trigger running jobs on the lilypad network from other smart contracts.
+We have deployed the [LilypadOnChainJobCreator](../hardhat/contracts/LilypadOnChainJobCreator.sol) contract which you can use to trigger running jobs on the lilypad network from other smart contracts.
 
 It works in tandem with the `lilypad jobcreator` on-chain which will watch the on-chain contract and manage jobs on behalf of contracts that submit them.
 
@@ -18,7 +18,7 @@ Running a job involves 2 phases:
 Now we know the address of the on-chain job controller - we can ask it for 3 things:
 
  * the address of the ERC-20 token contract - `getTokenAddress()`
- * how much the required deposit it - `getRequiredDeposit()`
+ * how much is the required deposit - `getRequiredDeposit()`
  * the address of the solver that will handle running the job for us - `getControllerAddress()`
 
 Knowing these 3 things means we can call the standard ERC-20 `approve` to allow the solver to spend our tokens on our behalf.
@@ -26,7 +26,7 @@ Knowing these 3 things means we can call the standard ERC-20 `approve` to allow
 Now - we can call the `runJob` method of the on chain controller from another contract.  This will cause the job-creator service to kick in and do the following things:
 
  * check that funds have been approved for the solver
- * transfer those funds to it's wallet
+ * transfer those funds to its wallet
  * run the job on lilypad
  * call the `submitResults` method on the on-chain job creator
  * the on-chain job creator will call the `submitResults` of the original calling contract