diff --git a/pages/stack/protocol/fault-proofs/fp-components.mdx b/pages/stack/protocol/fault-proofs/fp-components.mdx
index 49299483d..72e8bb0a1 100644
--- a/pages/stack/protocol/fault-proofs/fp-components.mdx
+++ b/pages/stack/protocol/fault-proofs/fp-components.mdx
@@ -68,12 +68,12 @@ They contain a function to resolve this commitment to be true or false, which is
 *   Incentive Compatibility: The system penalizes false claims and rewards truthful ones to ensure fair participation.
 *   Resolution: Each game has a mechanism to definitively validate or invalidate the root claim.
 
-The standard is the bi-section game. This is a specific type of dispute game, and the first game built in the OP Stack's dispute protocol.
+The standard is the bisection game. This is a specific type of dispute game, and the first game built in the OP Stack's dispute protocol.
 We bisect over output roots (which each correspond to single L2 blocks), until we get to a single block `n -> n+1` state transition. Then, we bisect over a single block state transition's execution trace as described before. This is an optimization to reduce the runtime of the off-chain VM.
 After bisection has reached commitments to the state at individual trace instructions, the `FaultDisputeGame` executes a single instruction step on chain using a generic VM.
 The VM's state transition function, which we'll call `T`, can be anything, so long as it adheres to the form `T(s, i) -> s'`, where `s` = the agreed upon prestate, `i` = the state transition inputs, and `s'` = the post state.
 
-The first full implementation of the VM generic in the bisection game includes a single MIPS thread context on top of the EVM to execute single instructions within an execution trace generated by `Cannon` and the `op-program`.
+The first full implementation of the VM generic in the bisection game includes a single MIPS thread context on top of the EVM to execute a single instruction within an execution trace generated by `Cannon` and the `op-program`.
 
 ## Next Steps