Updated malformed evictedSorobanEntries section

Author: SirTyson

core/cap-0063.md

@@ -214,12 +214,23 @@ on in-memory read limits and fees. If an archived Soroban entry has been evicted
 on on-disk limits and fees. All evicted keys must be declared in the `evictedSorobanEntries` vector via `SorobanResourcesExtV0`.
 If no evicted entries are present in the footprint, `SorobanResourcesExtV0` may be omitted.
 
+##### Incorrect Entries in `evictedSorobanEntries` Vector
+
+If a key is not marked as evicted, but the entry is actually evicted, then the TX fails. If a Soroban key is marked as evicted when
+it is not, the transaction does not fail. The entry is treated as if it is evicted from a resource and fee perspective.
+This is appropriate, as on disk reads are more expensive than in-memory. So long as the TX pays the disk based fees,
+there is no issue with actually loading an in-memory entry.
+
+If a classic key is marked as evicted, the TX fails, as the footprint is malformed.
+
 ##### Failure Codes
 
 If an evicted entry is included in the TX's footprint but is not specified via the `evictedSorobanEntries` vector, the
 tx will fail with the `INVOKE_HOST_FUNCTION_ENTRY_ARCHIVED` code. If there are insufficient resources for entry restoration,
 the tx will fail with the `INVOKE_HOST_FUNCTION_RESOURCE_LIMIT_EXCEEDED` code.
 
+If a classic entry is marked as evicted, the TX fails with `INVOKE_HOST_FUNCTION_MALFORMED` during apply time.
+
 ##### Meta
 
 Whenever an entry is restored, it will be emitted as a `LedgerEntryChangeType` of type `LEDGER_ENTRY_RESTORE`.