refactor: Update protocol/0074-BTCH-batch-market-instructions.md

Co-authored-by: David Siska <62546419+davidsiska-vega@users.noreply.github.com>

protocol/0074-BTCH-batch-market-instructions.md

@@ -34,7 +34,8 @@ Overall, building the ability to handle batches of market instructions in a sing
 - A batch is considered a single transaction, with a single transaction ID and a single timestamp applying to all instructions within it. Each instruction should be given a sub-identifier and index allowing it to be placed sequentially in the transaction (e.g. by consumers of the event stream). These identifiers must be sufficient for a user to determine which instruction within a batch any result (order updates, trades, errors, etc.) relates to.
 - The batches must be processed in the order **all cancellations, then all amendments, any margin mode update, then all submissions**. This is to prevent gaming the system, and to prevent any order being modified by more than one action in the batch. Updating the margin mode after cancellations and amendments allows the party to have control of which orders are outstanding when the margin mode changes.
 - When processing each list, the instructions within the list must be processed in the order they appear in the list (i.e. in the order prescribed by the submitter). (Notwithstanding that each list is processed in its entirety before moving onto the next list, in the order specified above).
-- All instructions within each list must be validated as normal **at the time that the instruction is enacted**. That is, instructions cannot be pre-validated as a batch. If a prior instruction, would create a state that would cause a later instruction to fail validation, the later instruction must fail validation (and vice verse). Any validation not dependent on other parameters or app state should be carried out as early as possible (e.g. check if type is numerical etc.).
+- All instructions within each list must be validated as normal **at the time that the instruction is enacted**. That is, instructions cannot be pre-validated as a batch. If a prior instruction, would create a state that would cause a later instruction to fail validation, the later instruction must fail validation (and vice verse).
+Any validation not dependent on other parameters or app state (i.e. static e.g. check if type is numerical etc.) should be carried on batch submission.
 - If validation fails, the execution of other instructions depends on the value specified for the `ON_ERROR` parameter. Any validation or other errors should be returned, as well as a reference to the instruction to which they relate, in the response.
 - Any errors encountered in processing an instruction after it passes validation must cause it to be skipped, and the errors, as well as the instruction to which they relate, must be available in the result of the transaction.
 - In addition to the usual validation and other errors that can occur in processing an instruction, the following also apply: