diff --git a/EIPS/eip-5732.md b/EIPS/eip-5732.md
index e208ec9edb1d9a..0828f88c2a39e0 100644
--- a/EIPS/eip-5732.md
+++ b/EIPS/eip-5732.md
@@ -4,12 +4,11 @@ title: Commit Interface
 description: A simple but general commit interface to support commit-reveal scheme.
 author: Zainan Victor Zhou (@xinbenlv), Matt Stam (@mattstam)
 discussions-to: https://ethereum-magicians.org/t/erc-5732-simple-commit-interface-to-support-commit-reveal-schemes/11115
-status: Last Call
-last-call-deadline: 2022-11-13
+status: Final
 type: Standards Track
 category: ERC
 created: 2022-09-29
-requires: 165
+requires: 165, 1271
 ---
 
 ## Abstract
@@ -66,7 +65,7 @@ interface IERC_COMMIT_GENERAL {
 
 But there MUST be a way to supply an extra field of `secret_salt`, so that committer can later open the `secret_salt` in the reveal TX that exposes the `secret_salt`. The size and location of `secret_salt` is intentionally unspecified in this EIP to maximize flexibility for integration.
 
-8. Compliant contract is RECOMMENDED to implement [EIP-165](./eip-165.md).
+8. It is RECOMMENDED for compliant contracts to implement [EIP-165](./eip-165.md).
 
 ## Rationale
 
@@ -112,14 +111,14 @@ function commit(bytes32 commitment, bytes calldata data) public {
 ## Security Considerations
 
 1. Do not use the reference implementation in production. It is just for demonstration purposes.
-2. The reveal transactions, parameters, especially `secret_salt` MUST be kept in secrecy before revealing to achieve privacy.
-3. The length of `secret_salt` cryptographically long enough and the way to generate a `secret_salt` shall be cryptographically safe.
-4. User shall NEVER reuse a used `secret_salt`. It's RECOMMENDED for client application to warn User for reusing a secret_salt.
-5. Contract implementations SHOULD consider deleting the commitment of a given sender immediately to reduce chance of replay attack or re-entry attack by adversaries.
-6. Contract implementations MAY consider also include the ordering of commitment received to add restriction on the order of reveal TX transactions.
-7. Cautious on the potential replay attack across different chain-ids or chains resulting from forks, in which case, a ChainId shall be included in the generation of commitment.
-8. Proper time-gap is suggested if the purpose is to avoid front-running attack.
-9. For compliant contract that requires the `_timePoint` from next TX to be _strictly greater_ than a previous TX, `block.timestamp` and `block.number` are not reliable as two TX could co-exist in the same block resulting in the same `_timePoint` value. In such case, compliant contract is to take extra measures to enforce this strict-monotone-ness. For example, use a separate state variable in the contract to keep track of number of commits it receives, or reject any second/other TX that shares the same `block.timestamp` or `block.number`.
+2. The reveal transactions and parameters, especially `secret_salt`, MUST be kept secret before they are revealed.
+3. The length of `secret_salt` must be cryptographically long enough and the random values used to generate `secret_salt` must be cryptographically safe.
+4. Users must NEVER reuse a used `secret_salt`. It's recommended for client applications to warn users who attempt to do so.
+5. Contract implementations should consider deleting the commitment of a given sender immediately to reduce the chances of a replay attack or re-entry attack.
+6. Contract implementations may consider including the ordering of commitment received to add restrictions on the order of reveal transactions.
+7. There is potential for replay attacks across different chainIds or chains resulting from forks. In these cases, the chainId must be included in the generation of commitment. For applications with a higher risk of replay attacks, implementors should consider battle-tested and cryptographically-secure solutions such as [EIP-712](./eip-712.md) to compose commitments before creating their own new solution.
+8. Proper time gaps are suggested if the purpose is to avoid frontrunning attacks.
+9. For compliant contract that requires the `_timePoint` from the next transaction to be _strictly greater_ than that of any previous transaction, `block.timestamp` and `block.number` are not reliable as two transactions could co-exist in the same block resulting in the same `_timePoint` value. In such case, extra measures to enforce this strict monotonicity are required, such as the use of a separate sate variable in the contract to keep track of number of commits it receives, or to reject any second/other TX that shares the same `block.timestamp` or `block.number`.
 
 ## Copyright