docs: fix typo

contracts/docs/overview.md

@@ -26,7 +26,7 @@ immediately usable form on Ethereum L1.
 The contracts are split between "core" and "periphery". Where core is responsible for order
 validation & settlement, underlying AMM reward management and store for user deposits. 
 
-The periphery contracts (WIP 🚧) implement the finer details of acccess control, as well as managing
+The periphery contracts (WIP 🚧) implement the finer details of access control, as well as managing
 collection and distribution of node & referral fees.
 
 ### Assumptions
@@ -50,7 +50,7 @@ own *decrease* over time.
 Ethereum L1 Mainnet or canonical testnets with identical semantics.
 - **The `_controller` is sound:** The controller will maintain the approved set of nodes such that
 the _economic security assumption_ and _sufficiently staked assumption_ is maintained over time.
-Furthermore is will trustlessly verify that `pullFee` is only ever called for unclaimed amounts that
+Furthermore it will trustlessly verify that `pullFee` is only ever called for unclaimed amounts that
 have been committed to for later claiming via the fee summary events.
 - **Integrity of state dependencies:** Running off-chain the nodes of the Angstrom network expect to
   be tightly coupled with builders meaning roughly it can expect that *most of the time* the way it
@@ -110,7 +110,7 @@ The _solvency_ invariant it maintains for every asset $\alpha$ is:
 \text{TotalTokenBalance}_{\alpha}=\text{Delta}_{\alpha} + \sum^N_i \text{UserBalance}_{i,\alpha} + \sum^N_i \text{LPReward}_{i,\alpha}
 ```
 
-Here a visualization of how each action in a bundle is accountd for:
+Here a visualization of how each action in a bundle is accounted for:
 
 ![](./assets/angstrom-accounting.png)
 

contracts/docs/pade-encoding-format.md

@@ -43,7 +43,7 @@ Types can be aliased or composed into larger product types aka "structs" e.g.
 struct Trade {
     asset_in: address,
     asset_out: address,
-    quanitity: uint64
+    quantity: uint64
 }
 
 struct Matched {
@@ -66,7 +66,7 @@ enum OrderInvalidation {
     },
     Standing {
         deadline: uint40,
-        nocne: uint64
+        nonce: uint64
     }
 }
 
@@ -81,7 +81,7 @@ Note that recursive type definitions are **disallowed** (reasoning: makes specif
 
 ### Builtins
 
-While these types are not first class citizens of the type system they are useful contructs that
+While these types are not first class citizens of the type system they are useful constructs that
 will later have to have some functions like the EIP712 struct hashing defined for them.
 
 ```rust
@@ -140,7 +140,7 @@ field / struct).
 LIST_MAX_LENGTH_BYTES = 3
 
 def pade_encode(x: PadeValue, T: PadeType) -> bytes:
-    if T.is_abi_primitve():
+    if T.is_abi_primitive():
         return x.abi_encode_packed()
     if T.is_enum():
         variant_size = full_bytes(bits(len(T.variants)))

contracts/docs/pool-config-store.md

@@ -13,7 +13,7 @@ initialized separately once a new set of parameters is set.
 ## Pool Config Store
 
 To minimize the gas cost of looking up & validating these parameters when processing an Angstrom
-bundle they're stored in a "store contract", this is a conract that holds the data as its raw
+bundle they're stored in a "store contract", this is a contract that holds the data as its raw
 bytecode (padded with one leading `00` byte to prevent execution/destruction).
 
 The store's bytecode is structured as follows:

docs/node/network/Overview.md

@@ -4,11 +4,11 @@
 The network manager facilitates the communication of order and consensus data between modules.
 
 ## Swarm
-The swarm deals with message dispatch allong with peer tracking and is just a middle struct that acts as a
-seperator to the manager
+The swarm deals with message dispatch along with peer tracking and is just a middle struct that acts as a
+separator to the manager
 ## State
 The state tracker, tracks the state of the network and contains the set of valid validators. The state tracker is
-in charge of making sure that we always know who is a validator. The state tracker also hold the peer manager, which
-is just a behavior rating system for each peer so that we can monitor and possible disconnect from any missbehaving peer.
-## Sessions.
+in charge of making sure that we always know who is a validator. The state tracker also holds the peer manager, which
+is just a behavior rating system for each peer so that we can monitor and possible disconnect from any misbehaving peer.
+## Sessions
 The Sessions manager deals with handling new sessions along with propagating messages to the sessions.

docs/node/order-pool/Overview.md

@@ -8,7 +8,7 @@ Peer order tracking simply tracks what orders a given peer has sent to us to avo
 wasting network resources.
 # Order Indexer
 The Order Indexer is the heart of the order pool. This controls the movement of orders via incoming information from the manager,
-The indexing of orders. Handling of subscriptions to order's. As well as the order lifecycle.
+The indexing of orders. Handling of subscriptions to orders. As well as the order lifecycle.
 # Order Storage
 The order storage as the name suggests, is the place in which verified and indexed orders are stored as well as canceled and filled orders for
 the remainder of their life-cycle.

docs/node/validation/Overview.md

@@ -7,13 +7,13 @@ This goes over the specific uses of each module.
 The Order validator struct acts as the holder and dispatcher for the different
 tools that are used for validating an order.
 ### Gas Module
-Gas module is currently in the works but will have the calculations that are needed in order to see how a order fairs on gas.
+Gas module is currently in the works but will have the calculations that are needed in order to see how an order fares on gas.
 This will include simulations on the specific execution parts of a given order
 ### Hook Simulation
 The hook simulator is for simulating the hooks to make sure that they don't invalidate any state.
 ### User State Tracker
-The User state tracker contains the state of a users account Nonces, Balances and Approvals. The User state tracker
-also stores all current user pending orders (sorted by nonce) to enable multiple orders on same tokens for a given bundle.
+The User state tracker contains the state of a user's account Nonces, Balances and Approvals. The User state tracker
+also stores all current user pending orders (sorted by nonce) to enable multiple orders on the same tokens for a given bundle.
 
 ## Bundle Validator
 Used for calculating the bundle gas cost. Simply simulates the bundle at the top of the block and will let us know if bundle