diff --git a/pages/stack/fault-proofs/fp-components.mdx b/pages/stack/fault-proofs/fp-components.mdx
index d3132d21e..6cb238e0b 100644
--- a/pages/stack/fault-proofs/fp-components.mdx
+++ b/pages/stack/fault-proofs/fp-components.mdx
@@ -63,7 +63,7 @@ In the Dispute protocol, different types of dispute games can be created, manage
 This opens the door to innovative features, like aggregate proof systems and the ability to expand the protocol to allow for disputing things apart from the state of L2, such as a `FaultDisputeGame` geared towards onchain binary verification.
 
 A dispute game is a core primitive to the dispute protocol. It models a simple state machine, and it is initialized with a 32 byte commitment to any piece of information of which the validity can be disputed.
-They contain a function to resolve this commitment to be true or false, which is left for the implementor of the primitive to define. Dispute games themselves rely on two fundamental properties:
+They contain a function to resolve this commitment to be true or false, which is left for the implementer of the primitive to define. Dispute games themselves rely on two fundamental properties:
 
 *   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.