diff --git a/EIPS/eip-5450.md b/EIPS/eip-5450.md
index 9c7c91bf7b9b7a..e546311640b6c8 100644
--- a/EIPS/eip-5450.md
+++ b/EIPS/eip-5450.md
@@ -36,7 +36,7 @@ It also has some disadvantages:
 - adds constraints to the code structure (similar to JVM, CPython bytecode, WebAssembly and others); however, these constraints can be lifted in a backward-compatible manner if they are shown to be user-unfriendly,
 - it is natural to implement stack validation as a second validation pass; however, it is not strictly required and validation's computational and space complexity remains linear in any implementation variant.
 
-The guarantees created by these validation rules also improve the feasabiliy of Ahead-Of-Time and Just-In-Time compilation of EVM code. Single pass transpilation passes can be safely executed with the code validation and advanced stack/register handling can be applied with the stack height validaitons. While not as impactful to a mainnet validator node that is bound mostly by storage state sizes, these can significantly speed up witness validation and other non-mainnet use cases.
+The guarantees created by these validation rules also improve the feasibility of Ahead-Of-Time and Just-In-Time compilation of EVM code. Single pass transpilation passes can be safely executed with the code validation and advanced stack/register handling can be applied with the stack height validations. While not as impactful to a mainnet validator node that is bound mostly by storage state sizes, these can significantly speed up witness validation and other non-mainnet use cases.
 
 ## Specification
 
@@ -59,13 +59,12 @@ In the second validation phase control-flow analysis is performed on the code.
 *Terminating instructions* refers to the instructions either:
 
 - ending function execution: `RETF`, `JUMPF`, or
-- ending whole EVM execution: `STOP`, `RETURN`, `RETURNCONTRACT`, `REVERT`, `INVALID`.
+- ending call frame execution: `STOP`, `RETURN`, `RETURNCONTRACT`, `REVERT`, `INVALID`.
 
 *note: `JUMPF` and `RETURNCONTRACT` are introduced in separate EIPs.*
 
 *Forward jump* refers to any of `RJUMP`/`RJUMPI`/`RJUMPV` instruction with relative offset greater than or equal to 0. *Backwards jump* refers to any of `RJUMP`/`RJUMPI`/`RJUMPV` instruction with relative offset less than 0, including jumps to the same jump instruction.
 
-
 Instructions in the code are scanned in a single linear pass over the code. For each instruction the operand stack height bounds are recorded as `stack_height_min` and `stack_height_max`.
 
 The first instruction's recorded stack height bounds are initialized to be equal to the number of inputs to the function type matching the code (`stack_height_min = stack_height_max = type[code_section_index].inputs`).
@@ -80,7 +79,7 @@ For each instruction:
       - for `RETF` instruction both the recorded lower and upper bound must be equal and must be exactly the number of outputs of the function matching the code,
       - for `JUMPF` into returning function both the recorded lower and upper bound must equal exactly `type[current_section_index].outputs + type[target_section_index].inputs - type[target_section_index].outputs`,
       - for `JUMPF` into non-returning function the recorded stack height lower bound must be at least the number of inputs of the target function according to its type defined in the type section,
-      - for any other instruction the recodrded stack height lower bound must be at least the number of inputs required by instruction,
+      - for any other instruction the recorded stack height lower bound must be at least the number of inputs required by instruction,
       - there is no additional check for terminating instructions other than `RETF` and `JUMPF`, this implies that extra items left on stack at instruction ending EVM execution are allowed.
    2. For `CALLF` and `JUMPF` **check** for possible stack overflow: if recorded stack height upper bound is greater than `1024 - types[target_section_index].max_stack_height + types[target_section_index].inputs`, validation fails.
    3. Compute new stack height bounds after the instruction execution. Upper and lower bound are updated by the same value:
@@ -154,7 +153,7 @@ This is required to make it possible to examine each instruction in one linear p
 
 ## Backwards Compatibility
 
-This change requires a "network upgrade", since it modifies consensus rules.
+This change requires a "network upgrade," since it modifies consensus rules.
 
 It poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).