diff --git a/ERCS/erc-7683.md b/ERCS/erc-7683.md
index ef27ce5ef3..d56701d538 100644
--- a/ERCS/erc-7683.md
+++ b/ERCS/erc-7683.md
@@ -30,7 +30,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 - **Filler**: a participant who fulfils a user intent on the destination chain(s) and receives payment as a reward.
 - **Leg**: a portion of the user intent that can be executed independently from others. All legs must be executed for an intent to be considered fulfilled.
 - **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.
+- **Settlement System**: a system that custodies user deposits, verifies fills, and pays fillers for the purpose of facilitating 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 order.
 
@@ -106,7 +106,7 @@ struct ResolvedCrossChainOrder {
 	/// @dev The max outputs that the filler will send. It's possible the actual amount depends on the state of the destination
 	///      chain (destination dutch auction, for instance), so these outputs should be considered a cap on filler liabilities.
 	Output[] maxSpent;
-	/// @dev The minimum outputs that must to be given to the filler as part of order settlement. Similar to maxSpent, it's possible
+	/// @dev The minimum outputs that must be given to the filler as part of order settlement. Similar to maxSpent, it's possible
 	///      that special order types may not be able to guarantee the exact amount at open time, so this should be considered
 	///      a floor on filler receipts.
 	Output[] minReceived;
@@ -115,7 +115,7 @@ struct ResolvedCrossChainOrder {
 	FillInstruction[] fillInstructions;
 }
 
-/// @notice Tokens that must be receive for a valid order fulfillment
+/// @notice Tokens that must be received for a valid order fulfillment
 struct Output {
 	/// @dev The address of the ERC20 token on the destination chain
 	/// @dev address(0) used as a sentinel for the native token
@@ -277,7 +277,7 @@ and fill to evaluate all resulting state transitions without understanding the n
 ### 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.
+to pull each non-EVM ecosystem in would dramatically increase the size and complexity of this standard, while omitting 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
@@ -299,7 +299,7 @@ When building a standard-compliant settler system around Permit2, the following
 
 ### 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.
+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 an `originSettler` that is known to support the `Message` sub-type.
 
 Let there be a sub-type called `Message`, which is defined by the following structs:
 
@@ -319,7 +319,7 @@ struct Message {
 }
 ```
 
-The `Message` sub-type is designed to be used by a 7683 user to incentivize a filler to to execute arbitrary calldata on a target destination chain contracton the user's behalf. For example, the settlement contract might decode the `orderData` containing the message information as follows:
+The `Message` sub-type is designed to be used by a 7683 user to incentivize a filler to execute arbitrary calldata on a target destination chain contract on the user's behalf. For example, the settlement contract might decode the `orderData` containing the message information as follows:
 
 ```solidity
 function fill(bytes32 orderId, bytes calldata originData, bytes calldata fillerData) public {