formatting fixes

Signed-off-by: Matt Rice <[email protected]>

ERCS/erc-7683.md

@@ -32,7 +32,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 - **Origin chain**: the chain where the user sends funds.
 - **Settlement System**: a system that custodies user deposits, verifies fills, and pays fillers for the purpose of faciliating intents.
 - **Settler**: a contract that implements part of the settlement system on a particular chain.
-- **User**: for the purposes of this document, the user is the end-user who is sending the ERC-7683 order.
+- **User**: for the purposes of this document, the user is the end-user who is sending the order.
 
 ### Order structs
 
@@ -274,7 +274,30 @@ additional implementation costs on fillers.
 This functionality also makes it feasible for a user, filler, or order distribution system to perform an end-to-end simulation of the order initiation
 and fill to evaluate all resulting state transitions without understanding the nuances of a particular execution system.
 
-## Examples
+### Cross-compatibility
+
+Since this standard is intended to reduce friction for users moving value across chains, non-EVM ecosystems should not be excluded. However, attempting
+to pull each non-EVM ecosystem in would dramatically increase the size and complexity of this standard, while ommitting any that come in the future.
+
+Instead, this standard is intended to be cross-compatible with other ecosystems. It standardizes interfaces and data types on EVM chains, but allows
+for the creation of sibling standards that define compatible interfaces, data types, and flows within other ecosystems. Intents created within these
+sibling standards should be able to be filled on an EVM chain and vice versa.
+
+To ensure this cross-compatibility, all foreign addresses use `bytes32` rather than `address` to allow for larger address identifiers.
+
+### Usage of Permit2
+
+Permit2 is not specifically required by this standard, but does provide an efficient and straightforward approach to building standard-adherent protocols. Specifically, the `witness` functions of permit2 allow users to both approve the token transfer _and_ the order itself with a single signature. This also nicely couples the transfer of tokens with a successful initiation of the order.
+
+In contrast, a standard approval model would require two separate signatures - a token approval (either [ERC-2612](./eip-2612.md) or on-chain) and a signature to approve the terms of the order. It also decouples the token approval from the order, meaning approved tokens could potentially be taken at any time due to a buggy or untrusted settler contract.
+
+When building a standard-compliant settler system around Permit2, the following considerations should be made
+
+- `nonce` in the order struct should be a permit2 nonce
+- `openDeadline` in the order struct should be the permit2 deadline
+- A full order struct including the parsed `orderData` should be used as the witness type during the permit2 call. This ensures maximum transparency to the user as they sign their order permit.
+
+### Examples
 
 This is an example of how a 7683 cross-chain value transfer order can include instructions to the filler to execute arbitrary calldata on behalf of the recipient on the destination chain. This calldata execution is performed by the settlement contract atomically within the filler's fill() execution, so the arbitrary contract execution can take advantage of the destination chain recipient's newly transferred value. A hypothetical user in this example would select a `originSettler` that is known to support the `Message` sub-type.
 
@@ -329,38 +352,16 @@ function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerD
     }
 ```
 
-In this example, the Message sub-type allows the user to delegate destination chain contract execution to fillers. However, because transactions are executed via filler, the `msg.sender` would be the `DestinationSettler`, making this `Message` sub-type limited if the target contract authenticates based on the `msg.sender`. Ideally, 7683 orders containing Messages can be combined with smart contract wallets like implementations of [ERC4337](https://github.com/across-protocol/ERCs/blob/master/ERCS/erc-4337.md) or [EIP7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) to allow complete cross-chain delegated execution.
+In this example, the Message sub-type allows the user to delegate destination chain contract execution to fillers. However, because transactions are executed via filler, the `msg.sender` would be the `DestinationSettler`, making this `Message` sub-type limited if the target contract authenticates based on the `msg.sender`. Ideally, 7683 orders containing Messages can be combined with smart contract wallets like implementations of [ERC-4337](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-4337.md) or [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) to allow complete cross-chain delegated execution.
 
-### Cross-compatibility
-
-Since this standard is intended to reduce friction for users moving value across chains, non-EVM ecosystems should not be excluded. However, attempting
-to pull each non-EVM ecosystem in would dramatically increase the size and complexity of this standard, while ommitting any that come in the future.
-
-Instead, this standard is intended to be cross-compatible with other ecosystems. It standardizes interfaces and data types on EVM chains, but allows
-for the creation of sibling standards that define compatible interfaces, data types, and flows within other ecosystems. Intents created within these
-sibling standards should be able to be filled on an EVM chain and vice versa.
-
-To ensure this cross-compatibility, all foreign addresses use `bytes32` rather than `address` to allow for larger address identifiers.
-
-### Usage of Permit2
-
-Permit2 is not specifically required by this standard, but does provide an efficient and straightforward approach to building standard-adherent protocols. Specifically, the `witness` functions of permit2 allow users to both approve the token transfer _and_ the order itself with a single signature. This also nicely couples the transfer of tokens with a successful initiation of the order.
-
-In contrast, a standard approval model would require two separate signatures - a token approval (either [ERC-2612](./eip-2612.md) or on-chain) and a signature to approve the terms of the order. It also decouples the token approval from the order, meaning approved tokens could potentially be taken at any time due to a buggy or untrusted settler contract.
-
-When building a standard-compliant settler system around Permit2, the following considerations should be made
-
-- `nonce` in the order struct should be a permit2 nonce
-- `openDeadline` in the order struct should be the permit2 deadline
-- A full order struct including the parsed `orderData` should be used as the witness type during the permit2 call. This ensures maximum transparency to the user as they sign their order permit.
 
 ## Security Considerations
 
 #### Evaluating settlement contract security
 
 This ERC is agnostic of how the settlement system validates a 7683 order fulfillment and refunds the filler. In fact, this ERC is designed to delegate the responsibility of evaluating the settlement contract's security to the filler and the application that creates the user's 7683 order.
 
-This design decision is motivated by the existence of many viable cross-chain messaging systems today offering settlement contracts a variety of tradeoffs. We hope that ERC7683 can eventually support an ERC dedicated to standardizing a safe, trustless, cross-chain verification system.
+This design decision is motivated by the existence of many viable cross-chain messaging systems today offering settlement contracts a variety of tradeoffs. We hope that this standard can eventually support an ERC dedicated to standardizing a safe, trustless, cross-chain verification system.
 
 <!-- TODO -->