diff --git a/test/e2e/stylusDeployer.ts b/test/e2e/stylusDeployer.ts
index a2f30f5a..405d034b 100644
--- a/test/e2e/stylusDeployer.ts
+++ b/test/e2e/stylusDeployer.ts
@@ -185,7 +185,7 @@ const deploy = async (args: {
       args.salt,
       args.initData
     )
-    // calculate the epected address
+    // calculate the expected address
     const address = ethers.utils.getCreate2Address(
       args.deployer.address,
       initSalt,
@@ -422,7 +422,7 @@ describe('Stylus deployer', () => {
       expectRevert: true,
     })
 
-    // insufficent activatin value
+    // insufficient activation value
     await deploy({
       wallet: wall,
       bytecode,
diff --git a/test/foundry/fee-token-pricers/README.md b/test/foundry/fee-token-pricers/README.md
index 7f5c1177..e23a2f6f 100644
--- a/test/foundry/fee-token-pricers/README.md
+++ b/test/foundry/fee-token-pricers/README.md
@@ -20,7 +20,7 @@ In this option the chain owner simply updated the exchange rate manually. This i
 
 ### Type 2 - External oracle
 
-In this option an external oracle is used to fetch the exchange rate. Here the fee token pricer is responsible for ensuring the price is in the correct format and applying any safe guards that might be relevant. This option is easier to maintain that option 1. since an external party is reponsible for keep an up to date price on chain. However this places trust in the external party to keep the price up to date and to provide the correct price. To that end the pricer may apply some safe guards to avoid the price going too high or too low. This option also carries the same exchange risk as option 1, so a similar mitigation of marking up the price by a small amount might help to avoid under reimbursement
+In this option an external oracle is used to fetch the exchange rate. Here the fee token pricer is responsible for ensuring the price is in the correct format and applying any safe guards that might be relevant. This option is easier to maintain that option 1. since an external party is responsible for keep an up to date price on chain. However this places trust in the external party to keep the price up to date and to provide the correct price. To that end the pricer may apply some safe guards to avoid the price going too high or too low. This option also carries the same exchange risk as option 1, so a similar mitigation of marking up the price by a small amount might help to avoid under reimbursement
 
 An example of this approach can be seen in [UniswapV2TwapPricer.sol](./uniswap-v2-twap/UniswapV2TwapPricer.sol).
 
@@ -38,4 +38,4 @@ When implementing a fee token pricer the trust assumptions of each of the involv
 
 - **Chain owner** - the chain owner is always trusted as they can change the fee token pricer at any time
 - **Batch poster** - the batch poster is already trusted to provide valid batches that don't inflate data costs for users. In a type 3 fee token pricer they are additionally trusted to report the correct trade price
-- **External parties** - in a type 2 fee token pricer an external party is trusted to provide up to date price information. If the price provided is too low the batch poster will be under-refunded, if the price provided is too high the batch poster will be over-refunded. To that end implementers should consider including price guards in their pricer to ensure the external can't provide values too far from the correct price. As an example, if the external party chose to set the price to max(uint) it would drain the child chain's gas pool, and dramatically raise the price for users. The chain owner would need to call admin functions to reset the sytem. This could be avoided by putting logic in the pricer to prevent extreme values.
+- **External parties** - in a type 2 fee token pricer an external party is trusted to provide up to date price information. If the price provided is too low the batch poster will be under-refunded, if the price provided is too high the batch poster will be over-refunded. To that end implementers should consider including price guards in their pricer to ensure the external can't provide values too far from the correct price. As an example, if the external party chose to set the price to max(uint) it would drain the child chain's gas pool, and dramatically raise the price for users. The chain owner would need to call admin functions to reset the system. This could be avoided by putting logic in the pricer to prevent extreme values.