From 1da7ae190ac00eb98a4c5c1130a2b18c7b06d556 Mon Sep 17 00:00:00 2001
From: Eric <5089238+emizzle@users.noreply.github.com>
Date: Wed, 13 Sep 2023 10:03:31 +1000
Subject: [PATCH] clean up

---
 contracts/TestToken.sol | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contracts/TestToken.sol b/contracts/TestToken.sol
index 4a99c29..0a7f961 100644
--- a/contracts/TestToken.sol
+++ b/contracts/TestToken.sol
@@ -3,7 +3,7 @@ pragma solidity ^0.8.0;
 
 import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
 
-/* The `increaseAllowance` funcation of OpenZeppelin's ERC20 implementation is
+/* The `increaseAllowance` function of OpenZeppelin's ERC20 implementation is
 being used, which is not part of the standard ERC20 interface. If the Codex
 token must be an ERC20 token (eg DAI), then that token will need to be wrapped in
 OpenZeppelin's ERC20Wrapped to ensure that `increaseAllowance` is available.
@@ -12,7 +12,7 @@ The reason `increaseAllowance` is needed is because the sales state machine
 handles concurrent slot fills, which requires token approval. Because these
 approvals happen concurrently, simply calling `approve` is not sufficient as
 each `approve` amount will overwrite the previous. As an example, if a single
-node attempts to fill two slots simulataneously, it will send two `approve`
+node attempts to fill two slots simultaneously, it will send two `approve`
 transactions followed by two `fillSlot` transactions. The first two `approve`
 transactions will each approve the collateral amount for one `fillSlot`, the
 second overwriting the first, so the total approved will only ever be enough for