diff --git a/erc/ERCS/erc-7562.md b/erc/ERCS/erc-7562.md
index be798ce9..f87c38d6 100644
--- a/erc/ERCS/erc-7562.md
+++ b/erc/ERCS/erc-7562.md
@@ -44,7 +44,7 @@ However, the rules apply to any account-abstraction framework that uses EVM code
 
 All transactions initiated by EOAs have an implicit validation phase where balance, nonce, and signature are
 checked to be valid for the current state of the Ethereum blockchain.
-Once the transaction is checked to be valid by a node, only another transaction by the same EOA can modify the Ethereum.
+Once the transaction is checked to be valid by a node, only another transaction by the same EOA can modify the Ethereum
 state in a way that makes the first transaction invalid.
 
 With Account Abstraction, however, the validation can also include an arbitrary EVM code and rely on storage as well,
@@ -137,7 +137,7 @@ Also, if the invalidation of `N` UserOperations from the mempool costs `N*X` wit
 
 ## Specification
 
-### Rule types
+### Rule Types
 
 There are two types of rules:
 
@@ -156,7 +156,7 @@ There are two types of rules:
   - Bundlers SHOULD NOT propagate such UserOperations to other bundlers.
   - Bundlers SHOULD NOT consider another bundler a "spammer" if it does.
 
-### Constants:
+### Constants
 
 | Title                                | Value                       | Comment                                                                         |
 |--------------------------------------|-----------------------------|---------------------------------------------------------------------------------|
@@ -193,7 +193,7 @@ There are two types of rules:
 6. **Using an address**: accessing the code of a given address in any way.
    This can be done by executing `*CALL` or `EXTCODE*` opcodes for a given address.
 
-### Reputation Definitions:
+### Reputation Definitions
 1. **opsSeen**: a per-entity counter of how many times a unique valid `UserOperation` referencing this entity
    was received by this bundler.
    This includes `UserOperation` received via incoming RPC calls or through a P2P mempool protocol.
@@ -207,7 +207,7 @@ There are two types of rules:
 4. **inclusionRate**: Relation of `opsIncluded`  to `opsSeen`
 
 
-### Reputation calculation
+### Reputation Calculation
 
 We define a value `max_seen = opsSeen // MIN_INCLUSION_RATE_DENOMINATOR`.
 
@@ -298,7 +298,7 @@ To help make sense of these params, note that a malicious paymaster can at most
   entity, or referenced library, may not be changed.\
   If the code is modified, the UserOperation is considered invalid.
 
-### Storage rules.
+### Storage Rules
 
 The permanent storage access with `SLOAD` and `SSTORE` instructions within each phase is limited as follows:
 
@@ -318,8 +318,8 @@ Local storage rules protect the bundler against denial of service at the time of
   This means that `Paymaster` and `Factory` contracts cannot practically be an "account" contract as well.
 * **[STO-041]** `UserOperation` may not use associated storage (of either its account or from staked entity) in a contract that is a "sender" of another UserOperation in the mempool.
 
+### General Reputation Rules
 
-### General Reputation rules
 The following reputation rules apply for all staked entities, and for unstaked paymasters. All rules apply to all of these entities unless specified otherwise.
 
 * **[GREP-010]** A `BANNED` address is not allowed into the mempool.\
@@ -337,7 +337,7 @@ The following reputation rules apply for all staked entities, and for unstaked p
     * Allowed in unlimited numbers in the mempool.
     * Allowed in unlimited numbers in a bundle.
 
-### Entity-specific rules:
+### Entity-specific Rules
 
 * **[EREP-010]** For each `paymaster`, the mempool must maintain the total gas `UserOperations` using this `paymaster` may consume.
     * Do not add a `UserOperation` to the mempool if the maximum total gas cost, including the new `UserOperation`, is above the deposit of the `paymaster` at the current gas price.
@@ -360,7 +360,7 @@ The following reputation rules apply for all staked entities, and for unstaked p
       `opsAllowed = SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT + inclusionRate * min(opsIncluded, MAX_OPS_ALLOWED_UNSTAKED_ENTITY)`.
     * This is a default of `SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT` for new entity
 
-### Alt-mempools rules:
+### Alt-mempools Rules
 
 Alternate mempool is an agreed-upon rule that the bundlers may opt into, in addition to the canonical mempool
 The alt-mempool "topic" is a unique identifier. By convention, this is the IPFS hash of the document describing (in clear test and YAML file) the specifics of this alt mempool
@@ -373,7 +373,7 @@ The alt-mempool "topic" is a unique identifier. By convention, this is the IPFS
   The receiving bundler validates the `UserOperations`, and based on the above rules (and subscribed alt-mempools) decides which alt-mempools to propagate it to.
 * **[ALT-040]** opsInclude and opsSeen of entities are kept per alt-mempool. That is, an entity can be considered throttled (or banned) in one mempool, while still active on another.
 
-### Alt-mempool reputation:
+### Alt-mempool Reputation
 
 Alt-mempools are served by the same bundlers participating in the canonical mempool, but change the rules and may introduce denial-of-service attack vectors. To prevent them from taking the canonical mempool or other alt mempools down with them, a reputation is managed for each. An alt mempool that causes too many invalidations gets throttled. This limits the scope of the attack and lets the bundler continue doing its work for other mempools.