[CAP-77] Exclude issuer trustlines from the frozen keys.

core/cap-0077.md

@@ -224,7 +224,7 @@ Two new configuration settings types are introduced to support ledger key freezi
 
 `frozenLedgerKeys` can not be upgraded by the regular setting upgrade mechanism that involves overriding the full contents of the configuration entry. Instead, the upgrade is performed via a `frozenLedgerKeysDelta` setting that contains vectors of `LedgerKey`s to freeze and unfreeze, encoded as XDR bytes.
 
-`frozenLedgerKeysDelta` upgrade is considered invalid if any of the ledger keys can't be decoded as `LedgerKey` XDR, if any of the keys doesn't belong to the following allowed types: `ACCOUNT`, `TRUSTLINE`, `CONTRACT_DATA`, `CONTRACT_CODE`, or if any one of the keys is a pool share trustline.
+`frozenLedgerKeysDelta` upgrade is considered invalid if any of the ledger keys can't be decoded as `LedgerKey` XDR, if any of the keys doesn't belong to the following allowed types: `ACCOUNT`, `TRUSTLINE`, `CONTRACT_DATA`, `CONTRACT_CODE`, or if any one of the keys is either a pool share trustline, or an issuer trustline.
 
 When an upgrade to that contains `frozenLedgerKeysDelta` setting is applied to the ledger, all the keys in `keysToFreeze` are encoded and added to `frozenLedgerKeys` and all the keys in `keysToUnfreeze` are removed from `frozenLedgerKeys`. The upgrade process gracefully handles the addition of duplicate keys and removal of non-existent keys, these are simply ignored during the upgrade application process.
 
@@ -315,9 +315,17 @@ The bespoke upgrade procedure is introduced in order to work around the limit fo
 
 The validation of the incremental upgrades is also relaxed (duplicates/missing entries are allowed) in order to make the upgrade process faster and more reliable, as the assumption is that if this mechanism is ever used, it needs to be used rather fast. Under that requirement it's better to miss updates to a few keys instead of missing the whole upgrade.
 
+### Unsupported key types
+
+The CAP aims at supporting freezing the minimum viable set of ledger key types in order to minimize the maintenance burden and complexity.
+Soroban keys are a straightforward choice as they contain arbitrary data. Account and trustline entries are the only remaining entries that contain user value. Claimable balances and liquidity pools technically contain user value as well, but they might be frozen by a trustline proxy (e.g. a claimable balance can be frozen by freezing the trustlines of the claimers). It's also important to note that the data corruption or hack risk is much lower for the claimable balances and liquidity pools, as these are not interfacing with Soroban, are not actively developed, and can't be used standalone to transfer value.
+For the trustline keys we also exclude:
+- Pool share trustlines, as they are only used for liquidity pools and thus can be frozen by freezing the respective liquidity pool's asset trustlines.
+- Issuer trustlines, as these cannot exist as real ledger entries, but can introduce some unnecessary maintenance complexity in the apply paths.
+
 ### DEX handling
 
-A simple approach to handling the DEX operations would be to fail the operation if an offer that would update a frozen account/trustline is crossed. However, since DEX greedily picks the best offer to cross, this approach might effectively disable DEX for an asset pair for an unknown period of time and block all the more offers that are more expensive than the affected offer.
+A simple approach to handling the DEX operations would be to fail the operation if an offer that would update a frozen account/trustline is crossed. However, since DEX greedily picks the best offer to cross, this approach might effectively disable DEX for an asset pair for an unknown period of time and block all the offers that are more expensive than the affected offer.
 
 In order to avoid DEX disruption the approach described in this CAP is proposed: the offer is automatically removed and liabilities are released. This comes with the minimal DEX disruption with a tradeoff of modifying a frozen entry. However, the modification is minimal (only the liabilities are modified, the actual balance stays the same) and thus is unlikely to make data corruption worse. In the worst case, if an entry is in an arbitrarily broken state and update of liabilities would violate the protocol invariants for the liabilities, the transaction will fail with an internal error, which is equivalent to what would unconditionally happen in the 'simple' approach.