Fix history: leave "tombstones" for moved and removed rules

erc/ERCS/erc-7562.md

@@ -332,20 +332,25 @@ The following reputation rules apply for all staked entities, and for unstaked p
 ### Staked Entities Reputation Rules
 
 * **[SREP-010]** The "canonical mempool" defines a staked entity if it has `MIN_STAKE_VALUE` and unstake delay of `MIN_UNSTAKE_DELAY`
-* **[SREP-020]** An `OK` staked entity is unlimited by the reputation rule.
+* **[SREP-020]** MOVED TO GREP-010
+* **[SREP-030]** MOVED TO GREP-020
+* **[SREP-040]** An `OK` staked entity is unlimited by the reputation rule.
     * Allowed in unlimited numbers in the mempool.
     * Allowed in unlimited numbers in a bundle.
+* **[SREP-050]** MOVED TO GREP-040
 
 ### 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.
+* **[EREP-011]** REMOVED
 * **[EREP-015]** A `paymaster` should not have its opsSeen incremented on failure of factory or account
     * When running 2nd validation (before inclusion in a bundle), if a UserOperation fails because of factory or account error (either a FailOp revert or validation rule), then the paymaster's opsSeen valid is decremented by 1. 
 * **[EREP-020]** A staked factory is "accountable" for account breaking the rules. \
   That is, if the `validateUserOp()` is rejected for any reason in a `UserOperation` that has an `initCode`, it is treated as if the factory caused this failure, and thus this affects its reputation.
 * **[EREP-030]** A Staked Account is accountable for failures in other entities (`paymaster`, `aggregator`) even if they are staked.
 * **[EREP-040]** An `aggregator` must be staked, regardless of storage usage.
+* **[EREP-050]** REMOVED
 
 ### Unstaked Paymasters Reputation Rules
 
@@ -354,10 +359,12 @@ The following reputation rules apply for all staked entities, and for unstaked p
     * `UnstakedReputation` of an entity determines the maximum number of entries using this entity allowed in the mempool.
     * `opsAllowed` is a reputation-based calculation for an unstaked entity, representing how many `UserOperations` it is allowed to have in the mempool.
   * Rules:
-    * **[UREP-010]** An unstaked sender is only allowed to have `SAME_SENDER_MEMPOOL_COUNT` `UserOperation`s  in the mempool. A staked sender is only limited by the SREP rules.
+    * **[UREP-010]** An unstaked sender is only allowed to have `SAME_SENDER_MEMPOOL_COUNT` `UserOperation`s  in the mempool.
+    * **[UREP-011]** A staked sender is only limited by the [Staked Entities Reputation Rules](#staked-entities-reputation-rules).
     * **[UREP-020]** For an unstaked paymaster only that is not throttled/banned: \
       `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
+    * **[UREP-030]** REMOVED
 
 ### Alt-mempools Rules
 
@@ -379,6 +386,7 @@ Alt-mempools are served by the same bundlers participating in the canonical memp
 * **[AREP-010]** each alt-mempool manages "opsSeen" and "opsIncluded", much like entities. The opsSeen is incremented after `UserOperation` initial validation, where it is considered part of this mempool.
     The "opsIncluded" is incremented after this UserOperation is included on-chain (either by this bundler, or another)
 * **[AREP-020]** the alt-mempool becomes THROTTLED based on the [Reputation Calculation](#reputation-calculation)
+* **[AREP-030]** REMOVED
 
 ## Security Considerations