Removed blank sections from the document.

EIPS/eip-7099.md

@@ -46,13 +46,13 @@ interface IERC20Check {
      * For bundled Check, beginId < endId, representing a Check sequence
      */
     struct Check {
-        address tokenAddr;
-        address issuerAddr;
-        address receiverAddr;
-        uint256 beginId;
-        uint256 endId;
-        uint256 amt;
-    }
+        address tokenAddr;
+        address issuerAddr;
+        address receiverAddr;
+        uint256 beginId;
+        uint256 endId;
+        uint256 amt;
+    }
 
     /**
      * Issuer register a token with the Check contract
@@ -183,7 +183,7 @@ sequenceDiagram
     participant CheckContract
     actor Receiver
 
-    Issuer->>+CheckContract: "registers token addr and the Check signing addr with the Check contract"
+    Issuer->>+CheckContract: registers token addr and the Check signing addr with the Check contract
     CheckContract-->>-Issuer: success on chain
     Issuer->>+Erc-20 Token: authorizes the Check contract to mint tokens with the ERC-20 contract
     Erc-20 Token-->>-Issuer: success on chain
@@ -207,26 +207,12 @@ sequenceDiagram
     end
 ```
 
-## Rationale
-
 ## Backwards Compatibility
 
 No backward compatibility issues found
 
-## Test Cases
-
-## Reference Implementation
-
 ## Security Considerations
 
-<!--
-  All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
 To maintain the integrity of the Check sequence issued for a (tokenAddr, receiverAddr), Check ids must follow the numbering rules specified. The Check contract keeps the last minted Check id for each (tokenAddr, receiverAddr) and refuse to mint if the coming beginId in the mint request is out of order. Enforcing the Check sequencing numbers also defies same Check double issue by the issuer or double mint by the receiver.
 
 Off-chain checks are signed by the issuer and are not reputable once issued. After receiving multiple Checks from the issuer, if the issuer refuses to bundle, the receiver can still submit Checks to batch mint, albeit with reduced gas saving effect.