spelling

docs/src/getting_started/agents.md

@@ -1,3 +1,3 @@
 # Configuring agents
 
-Once your contract state is initialized you can think about itterating over your stocastic process and designing your agents to react to certain changes in the systems and contracts. For example an arbitraguer will want to react to price changes in the system.
+Once your contract state is initialized you can think about iterating over your stochastic process and designing your agents to react to certain changes in the systems and contracts. For example an arbitraguer will want to react to price changes in the system.

docs/src/getting_started/getting_started.md

@@ -43,7 +43,7 @@ This initializes a new Arbiter project with a template. You can generate the bin
 ```bash
 arbiter bind
 ```
-Arbiter bind wraps arround `forge bind` and is configured from your cargo.toml. There are three optional fields you can add to your toml to configure arbiter bind. 
+Arbiter bind wraps `forge bind` and is configured from your cargo.toml. There are three optional fields you can add to your toml to configure arbiter bind. 
 ```toml
 [arbiter]
 bindings_workspace = "simulation" # must be a valid workspace member

docs/src/getting_started/setting_up_simulations.md

@@ -1,14 +1,13 @@
 # Setting up Simulations
 
-At a high level it could be a good idea map out your simulation before you start writing it. Understand some key objectives of your simulation for example maybe you want to look for anomoly behavior and attempt to identify any critical failure points in the system. In this case you want to understand what a failure point is and how you can identify it. Another key thing to think about is what random process do you want to simulate over. Maybe you want to simulate over a random process that represents the price of a token with Geometric Brownian Motion or something more complex like a jump diffusion process, arbiter reexports rust quant and a binding for a liquid exchange that supports this. The last thing to consider is who are the agents in your simulation. Are they arbitrage bots, are they liquidity providers, are they random agents, or are they a combination of all of these. Identify key externally owned accounts and thing about what actions they can take in your simulation.
+At a high level it could be a good idea map out your simulation before you start writing it. Understand some key objectives of your simulation for example maybe you want to look for anomaly behavior and attempt to identify any critical failure points in the system. In this case you want to understand what a failure point is and how you can identify it. Another key thing to think about is what random process do you want to simulate over. Maybe you want to simulate over a random process that represents the price of a token with Geometric Brownian Motion or something more complex like a jump diffusion process, arbiter reexports rust quant and a binding for a liquid exchange that supports this. The last thing to consider is who are the agents in your simulation. Are they arbitrage bots, are they liquidity providers, are they random agents, or are they a combination of all of these. Identify key externally owned accounts and thing about what actions they can take in your simulation.
 
 When deisigning a simulation the first thing you need to think about is what contracts are in your simulation systems. You can start with just a one like in the template repository and add them as you continue your development. Almost all simulation design will start like this.
 
 ## Set up Steps
-- Idenfity key contracts
+- Identify key contracts
 - Generate bindings for those contracts
-- Deploy these contracts to the local in memeory instnace of revm (you can also skip this step in favor of using the forking feature)
+- Deploy these contracts to the local in memory instance of revm (you can also skip this step in favor of using the forking feature)
 
 After you have a system deployed in your in memory revm instance you are going to want to make sure your system state is correct. This could mean making sure you contracts hold enough balance of some specific tokens. Maybe you want to mint some tokens to a specific address, or you need to do token aprovals for your contracts.
 
-Once your contract state is initialized you can think about itterating over your stocastic process and designing your agents to react to certain changes in the systems and contracts. For example an arbitraguer will want to react to price changes in the system.