diff --git a/core/cap-0065.md b/core/cap-0065.md
index a69c77266..5d58a7d83 100644
--- a/core/cap-0065.md
+++ b/core/cap-0065.md
@@ -30,7 +30,7 @@ This change is aligned with the goal of lowering the cost and increasing the sca
 ## Abstract
 It would be ideal to cache modules in memory across transactions or even across ledgers. However, until recently there has been no consensus on how to attribute and charge fees to cover the cost of populating a longer-lived cache. The design of the module cache has therefore been limited to operating within a single transaction (with a clearly defined fee, and account that pays the fee).
 
-With the protocol changes proposed in [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md) the soroban state of the ledger is effectively partitioned into:
+With the protocol changes proposed in [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md) the soroban state of the ledger is effectively partitioned into:
 
   1. a smaller, size-bounded, live (directly-usable), in-memory component (the "live bucketlist")
   2. a larger, unbounded, archived (not-directly-usable), on-disk component (the "hot archive bucketlist")
@@ -42,7 +42,7 @@ Because of this new organization, a new caching strategy is possible: the module
 Moreover this cost may even be subsumed entirely into the IO resource fees associated with the upload or restore operation; correct calibration will be required to determine if a residual cost has to be charged for the parsing, validation and translation, separate from the IO costs.
 
 ## Specification
-This change depends on the adoption of [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md).
+This change depends on the adoption of [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md).
 
 The API between stellar-core and the soroban host is modified to allow the module cache to be reused across multiple soroban hosts.
 
@@ -52,7 +52,7 @@ When a `ContractCodeEntry` is uploaded or restored from the hot archive bucketli
 
 When a `ContractCodeEntry` is evicted from the live bucketlist to the hot archive bucketlist, it is removed from the reusable module cache.
 
-No other changes occur. Users should observe no behavioural differences, just lower fees due to the elimination of parsing, validation and translation costs during transaction execution. The "cache" will have a 100% hit rate since transactions can only invoke contracts currently in the live bucketlist. Ther cache therefore no longer behaves like a cache so much as simply a ready-to-run representation of the content of the live bucketlist.
+No other changes occur. Users should observe no behavioural differences, just lower fees due to the elimination of parsing, validation and translation costs during transaction execution. The "cache" will have a 100% hit rate since transactions can only invoke contracts currently in the live bucketlist. The cache therefore no longer behaves like a cache so much as simply a ready-to-run representation of the content of the live bucketlist.
 
 ### XDR changes
 None.
@@ -67,23 +67,23 @@ The only real "rationale" is in explaining why we _didn't_ have a persistent (cr
 
 It was frequently suggested that the network could charge fees to everyone "as if" they were experiencing a cache miss, and then refund the fee on a cache hit. Unfortunately the dominant cost being saved by caching is CPU time, which is not a refundable resource: there is a fixed amount of time _per transaction set_ (based on the close time target) and that time has to be allocated to transactions as part of admission control, when building transaction sets, after which the time is "consumed" whether _actually_ spent on-CPU while executing, or simply having excluded other transactions from the transaction set when building it. Various other strategies were proposed but none (until now) seemed satisfactory.
 
-With [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md), the population and eviction events are visible and controlled by the user (using rent bumps) and so we can move ahead with the simple, obvious design of "not clearing the cache after each transaction". Moreover since the design in CAP-0062 places _all_ live ledger data in memory, we can ensure the cache is actually always full of every possibly-invocable contract: a 100% hit rate.
+With [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md), the population and eviction events are visible and controlled by the user (using rent bumps) and so we can move ahead with the simple, obvious design of "not clearing the cache after each transaction". Moreover since the design in CAP-0062 places _all_ live ledger data in memory, we can ensure the cache is actually always full of every possibly-invocable contract: a 100% hit rate.
 
 While there is a small risk that the cumulative size of the live bucketlist will exceed available memory, this is controlled by a network setting that the validators can vote to raise or lower as necessary to balance the needs of the network against the cost to node operators of validators with more memory.
 
 In practice we expect the live bucketlist to remain comfortably within the memory of any reasonably modern computer: ledger entries range from hundreds of bytes to low-kilobytes, most servers used as validators have tens of gigabytes of memory, and the great majority of ledger entries are _dormant_ and can therefore be safely evicted to the disk without causing any inconvenience to users. Should they ever become active, the user only has to issue a restore operation.
 
 ## Protocol Upgrade Transition
-Besides the changes in [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md), upgrading to the changes in this CAP should impose no additional requirements for ecosystem users. CPU costs of transaction execution, and therefore fees charged, will decrease. That should be the only effect.
+Besides the changes in [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md), upgrading to the changes in this CAP should impose no additional requirements for ecosystem users. CPU costs of transaction execution, and therefore fees charged, will decrease. That should be the only effect.
 
 ### Backwards Incompatibilities
-Besides the changes in [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md), this CAP represents no additional backward incompatibilities.
+Besides the changes in [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md), this CAP represents no additional backward incompatibilities.
 
 ### Resource Utilization
 This CAP will substantially reduce transaction execution costs.
 
 ## Security Concerns
-There is a slightly elevated hypothetical risk of service denial due to memory exhaustion, beyond [CAP-0062](./cap-0062.md) and [CAP-0063](./cap-0063.md): for example if a user determines a way to allocate a disproportionate amount of memory in a cached module such that the ledger entry byte-size limits of the live bucketlist imposed by the previous CAPs do not adequately limit the memory consumption of those same ledger entries _when translated_.
+There is a slightly elevated hypothetical risk of service denial due to memory exhaustion, beyond [CAP-0062](./cap-0062.md) and [CAP-0066](./cap-0066.md): for example if a user determines a way to allocate a disproportionate amount of memory in a cached module such that the ledger entry byte-size limits of the live bucketlist imposed by the previous CAPs do not adequately limit the memory consumption of those same ledger entries _when translated_.
 
 We are not presently aware of any method of attack that fits this hypothetical risk, but it is not out of the realm of possibility. We will continue to perform testing, code inspection and monitoring with an eye to this hypothetical risk.