Additional information about cap-0003 upgrade approach 2

core/cap-0003.md

@@ -146,7 +146,7 @@ It is possible, after the protocol version is upgraded to `PROPOSAL_VERSION`, th
 As the description suggests, this approach would delete all existing offers when the protocol is upgraded to `PROPOSAL_VERSION`. As of ledger 18178688, there are 12734 offers owned by 2653 accounts (out of 474454 total accounts). One disadvantage to this approach is that it would likely cause a considerable decrease in available liquidity for some time while new offers are created. Some offers which have been created belong to accounts that would not be able to recreate them. There are 5 offers owned by 4 accounts with no signers and a master key weight of 0, with 2 of these offers selling an asset issued by the account. There is 1 other offer owned by an account whose total weight of signers and master key does not exceed the medium threshold, and it is also selling an asset issued by the account. It is worth repeating that this is only a simple lower bound on the number of offers that could not be recreated.
 
 #### Approach 2: Delete offers owned by accounts with excess liabilities
-For any account `A` and assets `X` and `Y`, this approach would delete any offer owned by `A` and selling `X` in exchange for `Y` if `A` has excess selling liabilities of `X` or excess buying liabilities of `Y`. As of ledger 18178688, there are a maximum of 6053 offers that would be deleted, owned by a maximum of 983 accounts. One disadvantage to this approach is that it would likely cause a considerable decrease in available liquidity for some time while new offers are created, although this impact would be smaller than in the previous approach. A further disadvantage to this approach is that, for some accounts, some offers may be deleted while others remain which could be undesirable in some cases. But at least offers selling an asset issued by the account are less likely to be deleted, since there is no limit on liabilities for the issuer of an asset. Regarding the specific offers mentioned above, none of the 3 that are selling an asset issued by that account would be deleted.
+For any account `A` and assets `X` and `Y`, this approach would delete any offer owned by `A` and selling `X` in exchange for `Y` if `A` has excess selling liabilities of `X` or excess buying liabilities of `Y`. As of ledger 18178688, there are a maximum of 6053 offers that would be deleted, owned by a maximum of 983 accounts. One disadvantage to this approach is that it would likely cause a considerable decrease in available liquidity for some time while new offers are created, although this impact would be smaller than in the previous approach. A further disadvantage to this approach is that, for some accounts, some offers may be deleted while others remain which could be undesirable in some cases. Both of these disadvantages could potentially be mitigated by giving an advance notice of a few weeks to the community and developers so that they have time to update their offers such that they do not have excess liabilities. As in the previous approach, it could occur that it is impossible to recreate some offers. But at least offers selling an asset issued by that account are less likely to be deleted, since there is no limit on liabilities for the issuer of an asset. Regarding the specific offers mentioned above, none of the 3 that are selling an asset issued by that account would be deleted.
 
 ### Base Reserve
 The previous section details only a single point of backward incompatibility, but the process of increasing the base reserve presents a similar issue of backward incompatibility which would be repeatedly possible in the future. The reason for this is that increasing the base reserve could cause offers selling the native asset to no longer be IEIF. The potential solutions presented in the previous section would also apply here, but the same disadvantages would still apply as well.