diff --git a/docs/build/apps/privacy.mdx b/docs/build/apps/privacy.mdx
index 478bc6e0e9..7a0a462333 100644
--- a/docs/build/apps/privacy.mdx
+++ b/docs/build/apps/privacy.mdx
@@ -83,10 +83,10 @@ A verifier for circuits built with Aztec's Noir language and Barretenberg backen
Stellar's Protocol [22](https://stellar.org/blog/developers/announcing-protocol-22), [25 ("X-Ray")](https://stellar.org/blog/developers/announcing-stellar-x-ray-protocol-25) and [26 ("Yardstick")](https://stellar.org/blog/foundation-news/stellar-yardstick-protocol-26-upgrade-guide) releases introduced native host functions into Stellar smart contracts that underpin all ZK-based privacy on Stellar:
-**BLS12-381** ([CAP-0059](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md)) – pairing-friendly elliptic curve with 128-bit security and efficient signature aggregation, enabling zk-SNARKs.
+**BLS12-381** ([CAP-59](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0059.md)) – pairing-friendly elliptic curve with 128-bit security and efficient signature aggregation, enabling zk-SNARKs.
-**BN254** ([CAP-0074](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0074.md)) — the pairing-friendly elliptic curve used by most ZK applications in production today. Adds `bn254_g1_add`, `bn254_g1_mul`, and `bn254_multi_pairing_check` host functions, mirroring Ethereum's EIP-196/197 precompiles. Existing BN254-based circuits and tooling can be ported to Stellar without modification.
+**BN254** ([CAP-74](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0074.md)) — the pairing-friendly elliptic curve used by most ZK applications in production today. Adds `bn254_g1_add`, `bn254_g1_mul`, and `bn254_multi_pairing_check` host functions, mirroring Ethereum's EIP-196/197 precompiles. Existing BN254-based circuits and tooling can be ported to Stellar without modification.
-**Poseidon / Poseidon2** ([CAP-0075](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0075.md)) — permutation primitives for building hash functions designed for ZK circuits. Far more efficient inside proofs than SHA-256, used for commitments, Merkle trees, and nullifiers. Available as host functions (`poseidon_permutation` and `poseidon2_permutation`) from which developers construct the hash function their application needs, keeping hashing logic consistent between off-chain circuits and onchain contracts.
+**Poseidon / Poseidon2** ([CAP-75](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0075.md)) — permutation primitives for building hash functions designed for ZK circuits. Far more efficient inside proofs than SHA-256, used for commitments, Merkle trees, and nullifiers. Available as host functions (`poseidon_permutation` and `poseidon2_permutation`) from which developers construct the hash function their application needs, keeping hashing logic consistent between off-chain circuits and onchain contracts.
Navigate to [this page](../apps/zk.mdx) For full details and code examples.
diff --git a/docs/build/guides/transactions/claimable-balances.mdx b/docs/build/guides/transactions/claimable-balances.mdx
index b18669ee87..f3623127c0 100644
--- a/docs/build/guides/transactions/claimable-balances.mdx
+++ b/docs/build/guides/transactions/claimable-balances.mdx
@@ -6,7 +6,7 @@ sidebar_position: 20
import Details from "@theme/Details";
-Claimable balances were introduced in [CAP-0023](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md) and are used to split a payment into two parts.
+Claimable balances were introduced in [CAP-23](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0023.md) and are used to split a payment into two parts.
- Part 1: sending account creates a payment, or ClaimableBalanceEntry, using the Create Claimable Balance operation
- Part 2: destination account(s), or claimant(s), accepts the ClaimableBalanceEntry using the Claim Claimable Balance operation
diff --git a/docs/build/guides/transactions/clawbacks.mdx b/docs/build/guides/transactions/clawbacks.mdx
index 3656667290..389d32014a 100644
--- a/docs/build/guides/transactions/clawbacks.mdx
+++ b/docs/build/guides/transactions/clawbacks.mdx
@@ -4,7 +4,7 @@ description: Use clawbacks to burn a specific amount of a clawback-enabled asset
sidebar_position: 30
---
-Clawbacks were introduced in [CAP-0035: Asset Clawback](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0035.md) and allow an asset issuer to burn a specific amount of a clawback-enabled asset from a trustline or claimable balance, effectively destroying it and removing it from a recipient's balance.
+Clawbacks were introduced in [CAP-35: Asset Clawback](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0035.md) and allow an asset issuer to burn a specific amount of a clawback-enabled asset from a trustline or claimable balance, effectively destroying it and removing it from a recipient's balance.
They were designed to allow asset issuers to meet securities regulations, which in many jurisdictions require asset issuers (or designated transfer agents) to have the ability to revoke assets in the event of a mistaken or fraudulent transaction or other regulatory action regarding a specific person or asset.
diff --git a/docs/build/guides/transactions/fee-bump-transactions.mdx b/docs/build/guides/transactions/fee-bump-transactions.mdx
index c891bfb81b..e8bed2615d 100644
--- a/docs/build/guides/transactions/fee-bump-transactions.mdx
+++ b/docs/build/guides/transactions/fee-bump-transactions.mdx
@@ -4,7 +4,7 @@ description: Use fee-bump transactions to pay for transaction fees on behalf of
sidebar_position: 40
---
-Fee-bump transactions were introduced in [CAP-0015](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) and enable an account to pay the transaction fees for an existing transaction without having to re-sign the transaction or manage sequence numbers.
+Fee-bump transactions were introduced in [CAP-15](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0015.md) and enable an account to pay the transaction fees for an existing transaction without having to re-sign the transaction or manage sequence numbers.
A fee-bump transaction is made of two parts:
diff --git a/docs/build/guides/transactions/pooled-accounts-muxed-accounts-memos.mdx b/docs/build/guides/transactions/pooled-accounts-muxed-accounts-memos.mdx
index cfd4bffbcd..a6f5ee47ee 100644
--- a/docs/build/guides/transactions/pooled-accounts-muxed-accounts-memos.mdx
+++ b/docs/build/guides/transactions/pooled-accounts-muxed-accounts-memos.mdx
@@ -26,7 +26,7 @@ Muxed accounts are embedded into the protocol for convenience and standardizatio
Muxed accounts do not exist on the ledger, but their shared underlying `GABC…` account does.
-Muxed accounts are defined in [CAP-0027](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md), introduced in Protocol 13, and their string representation is described in [SEP-23](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0023.md).
+Muxed accounts are defined in [CAP-27](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md), introduced in Protocol 13, and their string representation is described in [SEP-23](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0023.md).
It is safe for all wallets to implement sending to muxed accounts.
diff --git a/docs/build/guides/transactions/send-and-receive-payments.mdx b/docs/build/guides/transactions/send-and-receive-payments.mdx
index 0ca3c7945c..62e591811e 100644
--- a/docs/build/guides/transactions/send-and-receive-payments.mdx
+++ b/docs/build/guides/transactions/send-and-receive-payments.mdx
@@ -578,7 +578,7 @@ async function monitorPayments() {
// Decode transfer amount from the event data
try {
- // Protocol 23+ unified events model per CAP-0067
+ // Protocol 23+ unified events model per CAP-67
// https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md
// Event value field is scMap with {amount: i128, to_muxed_id: u64|bytes|string} (when muxed info present)
const amount = StellarSdk.scValToNative(event.value)["amount"];
diff --git a/docs/build/guides/transactions/sponsored-reserves.mdx b/docs/build/guides/transactions/sponsored-reserves.mdx
index bf8f9e7089..22131664b3 100644
--- a/docs/build/guides/transactions/sponsored-reserves.mdx
+++ b/docs/build/guides/transactions/sponsored-reserves.mdx
@@ -6,7 +6,7 @@ sidebar_position: 50
import Details from "@theme/Details";
-Sponsored reserves were introduced in [CAP-0033](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md) and allow an account (sponsoring account) to pay the base reserves for another account (sponsored account). While this relationship exists, base reserve requirements that would normally accumulate on the sponsored account now accumulate on the sponsoring account.
+Sponsored reserves were introduced in [CAP-33](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md) and allow an account (sponsoring account) to pay the base reserves for another account (sponsored account). While this relationship exists, base reserve requirements that would normally accumulate on the sponsored account now accumulate on the sponsoring account.
Both the Begin Sponsoring Future Reserves and the End Sponsoring Future Reserves operations must appear in the sponsorship transaction, guaranteeing that both accounts agree to the sponsorship.
@@ -507,7 +507,7 @@ For example, the following is an identical expression of the earlier Golang exam
### Other examples
-If you’d like other examples or want to view a more-generic pseudo-code breakdown of these sponsorship scenarios, you can refer to [CAP-0033](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md#example-revoke-sponsorship) directly.
+If you’d like other examples or want to view a more-generic pseudo-code breakdown of these sponsorship scenarios, you can refer to [CAP-33](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md#example-revoke-sponsorship) directly.
### Footnote
diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/running.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/running.mdx
index 3a76940cf9..30052c70fd 100644
--- a/docs/data/indexers/build-your-own/galexie/admin_guide/running.mdx
+++ b/docs/data/indexers/build-your-own/galexie/admin_guide/running.mdx
@@ -117,7 +117,7 @@ The `replace` command is a new addition in Galexie v24.1.0 that simplifies re-ex
Unlike `append` or `scan-and-fill`, which skip existing files, `replace` will overwrite existing files within a specified range.
-It is primarily used when Stellar Core starts emitting new or updated metadata for previously processed ledgers (e.g., the introduction of [CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) Stellar Events). This allows operators to re-export affected ledgers to ensure the data lake contains the latest, most complete metadata.
+It is primarily used when Stellar Core starts emitting new or updated metadata for previously processed ledgers (e.g., the introduction of [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) Stellar Events). This allows operators to re-export affected ledgers to ensure the data lake contains the latest, most complete metadata.
Syntax:
diff --git a/docs/learn/fundamentals/contract-development/storage/state-archival.mdx b/docs/learn/fundamentals/contract-development/storage/state-archival.mdx
index 2b57c5b095..fd513f5885 100644
--- a/docs/learn/fundamentals/contract-development/storage/state-archival.mdx
+++ b/docs/learn/fundamentals/contract-development/storage/state-archival.mdx
@@ -54,7 +54,7 @@ The general usage and interface are identical for all storage types. They differ
## Contract Data Automatic Restoration
-Starting in Protocol 23 ([CAP-0066: Soroban In-Memory Read Resource](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md#automatic-entry-restoration)), archived `Persistent` or `Instance` contract entries can be automatically restored before a host function runs, but only if they're included in the transaction's restore list. In practice, this list is usually populated by the contract invocation simulation (via the Stellar RPC): if the simulation detects an access to an archived entry, it adds that entry to the restore list. When the resulting `InvokeHostFunction` operation executes, those entries are restored first, and then the host function runs; normal rent and fees still apply.
+Starting in Protocol 23 ([CAP-66: Soroban In-Memory Read Resource](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md#automatic-entry-restoration)), archived `Persistent` or `Instance` contract entries can be automatically restored before a host function runs, but only if they're included in the transaction's restore list. In practice, this list is usually populated by the contract invocation simulation (via the Stellar RPC): if the simulation detects an access to an archived entry, it adds that entry to the restore list. When the resulting `InvokeHostFunction` operation executes, those entries are restored first, and then the host function runs; normal rent and fees still apply.
:::important
diff --git a/docs/tokens/anatomy-of-an-asset.mdx b/docs/tokens/anatomy-of-an-asset.mdx
index eb4a33d520..e8447d9834 100644
--- a/docs/tokens/anatomy-of-an-asset.mdx
+++ b/docs/tokens/anatomy-of-an-asset.mdx
@@ -59,7 +59,7 @@ All assets issued by Stellar accounts (G…` addresses) are **Stellar Assets**.
- Maintains issuer controls and trustline semantics even when used from contracts.
- Wide ecosystem wallet and indexer support. Assets issued by `G...` accounts are compatible with Stellar ecosystem products (such as Stellar wallets) and other ecosystem products (such as exchanges). For example, benefit from [anchors](../learn/fundamentals/anchors.mdx), the bridges between the Stellar network and traditional financial systems. Explore the global [Stellar anchor directory](https://anchors.stellar.org) for further details.
- Give the issuer granular control over asset management with features that allow the issuer to [name the asset](./control-asset-access.mdx#naming-an-asset), [determine access control](./control-asset-access.mdx#controlling-access-to-an-asset-with-flags), [limit asset supply](./control-asset-access.mdx#limiting-the-supply-of-an-asset), [publish asset information](./publishing-asset-info.mdx), and [ensure compliance](./anatomy-of-an-asset.mdx#compliance). Stellar assets provide built-in issuer control mechanisms by default. In contrast, contract tokens offer flexibility but require all control and compliance features to be explicitly designed and implemented in the contract.
-- Native operations on Stellar Assets emit standardized events through the Stellar Asset Contract, allowing off-chain systems and indexers to observe asset activity in a uniform way. Event semantics are defined at the protocol level according to [CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md).
+- Native operations on Stellar Assets emit standardized events through the Stellar Asset Contract, allowing off-chain systems and indexers to observe asset activity in a uniform way. Event semantics are defined at the protocol level according to [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md).
- Operations on Stellar Assets emit the same standardized events defined by SEP-41, because the Stellar Asset Contract implements the SEP-41 token interface, Payment operations on Stellar Assets surface identical transfer events, allowing off-chain systems and indexers to observe asset activity through a uniform way.
- By default, the admin of a Stellar Asset Contract (SAC) is the asset issuer (a `G...` address). However, the admin can be changed to a smart contract. Assigning a contract as the SAC admin enables custom, onchain policy for administrative actions for privileged operations.
- As accounts must have an active trustline to receive, hold, and transact assets, accounts can choose which asset they receive. This opt-in property holds even when a trustline is created by a smart contract via the SAC's `trust` function, because the account holder must still authorize the trustline's creation.
diff --git a/docs/tokens/token-interface.mdx b/docs/tokens/token-interface.mdx
index 991ccd5ba8..9aa3565131 100644
--- a/docs/tokens/token-interface.mdx
+++ b/docs/tokens/token-interface.mdx
@@ -198,7 +198,7 @@ The event shapes in the interface above are the ones a SEP-41 contract token emi
Code written against the shapes above will therefore mis-parse an event emitted by a Stellar Asset Contract, reading the asset identifier as a missing field or ignoring it entirely.
-[CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) is the normative source for the Stellar Asset Contract shapes below, and for the unification of classic events described further down.
+[CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) is the normative source for the Stellar Asset Contract shapes below, and for the unification of classic events described further down.
| Event | SEP-41 contract token | Stellar Asset Contract |
| --- | --- | --- |
diff --git a/docs/validators/admin-guide/prerequisites.mdx b/docs/validators/admin-guide/prerequisites.mdx
index 7826ffd6b0..7fcd089ca9 100644
--- a/docs/validators/admin-guide/prerequisites.mdx
+++ b/docs/validators/admin-guide/prerequisites.mdx
@@ -187,7 +187,7 @@ Buckets should be stored on a fast, local disk with sufficient space for several
Last estimated: May 2026. Reflects post-BucketListDB defaults
(stellar-core 21.0+) and the state archival design described in
- CAP-0046-12 / CAP-0057.
+ CAP-46-12 / CAP-57.
NOTE: As of the original state archival announcement, the user-facing
rent interface was live on mainnet but archived entries were not yet
diff --git a/meetings/2025-01-23.mdx b/meetings/2025-01-23.mdx
index ae36d5a326..0e2da587a9 100644
--- a/meetings/2025-01-23.mdx
+++ b/meetings/2025-01-23.mdx
@@ -18,10 +18,10 @@ In this week's meeting Hoops Finance's founders Bastian and Tim talk about the p
Recording from a protocol meeting where two Core Advancement Proposals -
-CAP-0062 (Soroban Live State Prioritization) and CAP-0066 (Soroban In-memory Read Resource) where discussed.
+CAP-62 (Soroban Live State Prioritization) and CAP-66 (Soroban In-memory Read Resource) where discussed.
Here's are some resources to read up on:
-CAP-0062 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0062.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1575
+CAP-62 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0062.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1575
-CAP-0066 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1585
+CAP-66 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1585
diff --git a/meetings/2025-01-30.mdx b/meetings/2025-01-30.mdx
index c7200899ba..60a7f71b3f 100644
--- a/meetings/2025-01-30.mdx
+++ b/meetings/2025-01-30.mdx
@@ -18,10 +18,10 @@ Visit their website here: https://rampmedaddy.com
Part 2
-In this protocol meeting two Core Advancement Proposals are discussed - Dima will be presenting CAP-0064 (Memo Authorization for Soroban), and Graydon will be presenting CAP-0065 (Reusable Module Cache).
+In this protocol meeting two Core Advancement Proposals are discussed - Dima will be presenting CAP-64 (Memo Authorization for Soroban), and Graydon will be presenting CAP-65 (Reusable Module Cache).
Here are some resources:
-CAP-0064 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0064.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1610
+CAP-64 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0064.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1610
-CAP-0065 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1615
+CAP-65 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md
Discussion - https://github.com/stellar/stellar-protocol/discussions/1615
diff --git a/meetings/2025-02-06.mdx b/meetings/2025-02-06.mdx
index 5b3d96daa7..8838abb0b5 100644
--- a/meetings/2025-02-06.mdx
+++ b/meetings/2025-02-06.mdx
@@ -18,14 +18,14 @@ Visit their website here: https://reflector.network
-In this protocol meeting we discuss two Core Advancement Proposals - Dima will be presenting CAP-0063 (Parallelism-friendly Transaction Scheduling), and Siddharth will be presenting CAP-0067 (Unified Asset Events).
+In this protocol meeting we discuss two Core Advancement Proposals - Dima will be presenting CAP-63 (Parallelism-friendly Transaction Scheduling), and Siddharth will be presenting CAP-67 (Unified Asset Events).
Here are some resources to read up on:
-- [CAP-0063](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0063.md)
+- [CAP-63](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0063.md)
-- [CAP-0063 Discussion](https://github.com/stellar/stellar-protocol/discussions/1602)
+- [CAP-63 Discussion](https://github.com/stellar/stellar-protocol/discussions/1602)
-- [CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
+- [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
-- [CAP-0067 Discussion](https://github.com/stellar/stellar-protocol/discussions/1553)
+- [CAP-67 Discussion](https://github.com/stellar/stellar-protocol/discussions/1553)
diff --git a/meetings/2025-02-13.mdx b/meetings/2025-02-13.mdx
index 7139876294..d71d1d2621 100644
--- a/meetings/2025-02-13.mdx
+++ b/meetings/2025-02-13.mdx
@@ -22,14 +22,14 @@ Links:
-This protocol meeting we discuss two Core Advancement Proposals - Dima is presenting CAP-0068 and CAP-0069, both of which add new host functions.
+This protocol meeting we discuss two Core Advancement Proposals - Dima is presenting CAP-68 and CAP-69, both of which add new host functions.
Here are some resources to read up on:
-- [CAP-0068](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0068.md)
+- [CAP-68](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0068.md)
-- [CAP-0068 Discussion](https://github.com/stellar/stellar-protocol/discussions/1626)
+- [CAP-68 Discussion](https://github.com/stellar/stellar-protocol/discussions/1626)
-- [CAP-0069](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0069.md)
+- [CAP-69](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0069.md)
-- [CAP-0069 Discussion](https://github.com/stellar/stellar-protocol/discussions/1633)
+- [CAP-69 Discussion](https://github.com/stellar/stellar-protocol/discussions/1633)
diff --git a/meetings/2025-02-20.mdx b/meetings/2025-02-20.mdx
index 5467d4a49a..48745d5966 100644
--- a/meetings/2025-02-20.mdx
+++ b/meetings/2025-02-20.mdx
@@ -24,10 +24,10 @@ Links:
-In this protocol meeting, a Core Advancement Proposals is discussed - Siddharth Suresh will will be presenting the memo related updates to CAP-0067.
+In this protocol meeting, a Core Advancement Proposals is discussed - Siddharth Suresh will will be presenting the memo related updates to CAP-67.
Here are some resources to read up on:
-- [CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
+- [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
- [Discussion](https://github.com/stellar/stellar-protocol/discussions/1553)
diff --git a/meetings/2025-02-27.mdx b/meetings/2025-02-27.mdx
index bdc56a428e..578c6b1085 100644
--- a/meetings/2025-02-27.mdx
+++ b/meetings/2025-02-27.mdx
@@ -22,14 +22,14 @@ Links:
-In this protocol meeting Dima's and Leigh's prototypes for dealing with memos/muxed accounts in CAP-0067 are discussed, as well as updates to CAP-0066 (Soroban In-memory Read Resource).
+In this protocol meeting Dima's and Leigh's prototypes for dealing with memos/muxed accounts in CAP-67 are discussed, as well as updates to CAP-66 (Soroban In-memory Read Resource).
Links:
-- [CAP-0066](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md)
+- [CAP-66](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md)
-- [CAP-0066 Discussion](https://github.com/stellar/stellar-protocol/discussions/1585)
+- [CAP-66 Discussion](https://github.com/stellar/stellar-protocol/discussions/1585)
-- [CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
+- [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
-- [CAP-0067 Discussions](https://github.com/stellar/stellar-protocol/discussions/1553#discussioncomment-12306846) and [CAP-0067 Discussions](https://github.com/stellar/stellar-protocol/discussions/1553#discussioncomment-12309408)
+- [CAP-67 Discussions](https://github.com/stellar/stellar-protocol/discussions/1553#discussioncomment-12306846) and [CAP-67 Discussions](https://github.com/stellar/stellar-protocol/discussions/1553#discussioncomment-12309408)
diff --git a/meetings/2025-05-01.mdx b/meetings/2025-05-01.mdx
index 548b2fd11e..53aa78fc2c 100644
--- a/meetings/2025-05-01.mdx
+++ b/meetings/2025-05-01.mdx
@@ -12,18 +12,18 @@ We are close to completing the implementation of Whisk, Protocol 23 CAPs, the ne
Read up on the CAPs here:
-[CAP-0062](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0062.md) - [Discussion](https://github.com/orgs/stellar/discussions/1575)
+[CAP-62](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0062.md) - [Discussion](https://github.com/orgs/stellar/discussions/1575)
-[CAP-0063](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0063.md) - [Discussion](https://github.com/orgs/stellar/discussions/1602)
+[CAP-63](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0063.md) - [Discussion](https://github.com/orgs/stellar/discussions/1602)
-[CAP-0065](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md) - [Discussion](https://github.com/orgs/stellar/discussions/1615)
+[CAP-65](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md) - [Discussion](https://github.com/orgs/stellar/discussions/1615)
-[CAP-0066](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md) - [Discussion](https://github.com/orgs/stellar/discussions/1585)
+[CAP-66](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md) - [Discussion](https://github.com/orgs/stellar/discussions/1585)
-[CAP-0067](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) - [Discussion](https://github.com/orgs/stellar/discussions/1553)
+[CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) - [Discussion](https://github.com/orgs/stellar/discussions/1553)
-[CAP-0068](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0068.md) - [Discussion](https://github.com/orgs/stellar/discussions/1626)
+[CAP-68](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0068.md) - [Discussion](https://github.com/orgs/stellar/discussions/1626)
-[CAP-0069](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0069.md) - [Discussion](https://github.com/orgs/stellar/discussions/1633)
+[CAP-69](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0069.md) - [Discussion](https://github.com/orgs/stellar/discussions/1633)
-[CAP-0070](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0070.md) - [Discussion](https://github.com/orgs/stellar/discussions/1719)
+[CAP-70](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0070.md) - [Discussion](https://github.com/orgs/stellar/discussions/1719)
diff --git a/meetings/2025-09-25.mdx b/meetings/2025-09-25.mdx
index 03e1d8ac6d..df796b3711 100644
--- a/meetings/2025-09-25.mdx
+++ b/meetings/2025-09-25.mdx
@@ -12,8 +12,8 @@ In this week’s Stellar Developer Meeting we discuss new Core Advancement Propo
Here are some resources to read up on:
-[CAP-0071](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
+[CAP-71](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
-[CAP-0072](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0072.md) - [Discussion](https://github.com/orgs/stellar/discussions/1763)
+[CAP-72](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0072.md) - [Discussion](https://github.com/orgs/stellar/discussions/1763)
-[CAP-0073](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0073.md) - [Discussion](https://github.com/orgs/stellar/discussions/1668)
+[CAP-73](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0073.md) - [Discussion](https://github.com/orgs/stellar/discussions/1668)
diff --git a/meetings/2025-10-02.mdx b/meetings/2025-10-02.mdx
index 761d88a5b4..896ee24d57 100644
--- a/meetings/2025-10-02.mdx
+++ b/meetings/2025-10-02.mdx
@@ -10,4 +10,4 @@ import YouTube from "@site/src/components/YouTube";
In this meeting we will discuss CAP-74, BN254 and Poseidon hash functions.
-[CAP-0074](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0074.md) - [Discussion](https://github.com/orgs/stellar/discussions/1780)
+[CAP-74](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0074.md) - [Discussion](https://github.com/orgs/stellar/discussions/1780)
diff --git a/meetings/2025-10-09.mdx b/meetings/2025-10-09.mdx
index 51df60ab29..cc468c9165 100644
--- a/meetings/2025-10-09.mdx
+++ b/meetings/2025-10-09.mdx
@@ -20,8 +20,8 @@ This time Steve will demo UI Builder, an easy way to spin up a front-end for any
## Protocol Discussion
-In this Core Advancement Proposal discussion CAP-0075 (Host functions for enabling Poseidon and Poseidon2 hash functions) is presented.
+In this Core Advancement Proposal discussion CAP-75 (Host functions for enabling Poseidon and Poseidon2 hash functions) is presented.
This CAP proposes adding host functions for cryptographic primitives enabling Poseidon family of hash functions, which are widely-adopted hash choices in efficient zero-knowledge proof systems. Supporting these as host functions in Soroban can facilitate adoption of ZK applications and interoperability with other ecosystems.
-Link to [CAP-0075](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0075.md)
+Link to [CAP-75](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0075.md)
diff --git a/meetings/2026-01-22.mdx b/meetings/2026-01-22.mdx
index 086d51894c..1bbd620261 100644
--- a/meetings/2026-01-22.mdx
+++ b/meetings/2026-01-22.mdx
@@ -20,8 +20,8 @@ We had three CAPs prepared for this meeting. CAP-77 will provide a way to make l
Read more about the proposals here:
-[CAP-0077](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0078.md) - [Discussion](https://github.com/orgs/stellar/discussions/1811)
+[CAP-77](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0077.md) - [Discussion](https://github.com/orgs/stellar/discussions/1811)
-[CAP-0078](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0078.md) - [Discussion](https://github.com/orgs/stellar/discussions/1825)
+[CAP-78](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0078.md) - [Discussion](https://github.com/orgs/stellar/discussions/1825)
-[CAP-0079](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0079.md) - [Discussion](https://github.com/orgs/stellar/discussions/1840)
+[CAP-79](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0079.md) - [Discussion](https://github.com/orgs/stellar/discussions/1840)
diff --git a/meetings/2026-01-29.mdx b/meetings/2026-01-29.mdx
index 6fdc887bb8..48a4ea9f08 100644
--- a/meetings/2026-01-29.mdx
+++ b/meetings/2026-01-29.mdx
@@ -16,6 +16,6 @@ We also follow up on a previous CAP - the CAP-73.
Read more about the proposal here:
-[CAP-0080](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0080.md) - [Discussion](https://github.com/orgs/stellar/discussions/1826)
+[CAP-80](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0080.md) - [Discussion](https://github.com/orgs/stellar/discussions/1826)
-[CAP-0073](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0073.md) - [Discussion](https://github.com/orgs/stellar/discussions/1668)
+[CAP-73](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0073.md) - [Discussion](https://github.com/orgs/stellar/discussions/1668)
diff --git a/meetings/2026-02-26.mdx b/meetings/2026-02-26.mdx
index b5ca8ee377..9dab0a04f3 100644
--- a/meetings/2026-02-26.mdx
+++ b/meetings/2026-02-26.mdx
@@ -18,6 +18,6 @@ CAP-82: This CAP adds checked variants of the existing 256-bit integer arithmeti
Read more about the proposals here:
-[CAP-0081](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0081.md) - [Discussion](https://github.com/orgs/stellar/discussions/1868)
+[CAP-81](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0081.md) - [Discussion](https://github.com/orgs/stellar/discussions/1868)
-[CAP-0082](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0082.md) - [Discussion](https://github.com/orgs/stellar/discussions/1834)
+[CAP-82](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0082.md) - [Discussion](https://github.com/orgs/stellar/discussions/1834)
diff --git a/meetings/2026-04-16.mdx b/meetings/2026-04-16.mdx
index a944e5f86f..ec974fa41c 100644
--- a/meetings/2026-04-16.mdx
+++ b/meetings/2026-04-16.mdx
@@ -18,9 +18,9 @@ Two CAPs shipped with this release:
**CAP-82** adds checked arithmetic variants for the existing 256-bit integer host functions. Where the current functions trap on overflow, the new checked variants return `Void` instead, letting contracts handle arithmetic errors explicitly and gracefully rather than panicking. If you're writing DeFi contracts — lending protocols, swap routers, pricing curves — this matters: checked arithmetic means operations fail explicitly and predictably instead of silently wrapping or trapping.
-[CAP-0081](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0081.md) — [Discussion](https://github.com/orgs/stellar/discussions/1868)
+[CAP-81](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0081.md) — [Discussion](https://github.com/orgs/stellar/discussions/1868)
-[CAP-0082](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0082.md) — [Discussion](https://github.com/orgs/stellar/discussions/1834)
+[CAP-82](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0082.md) — [Discussion](https://github.com/orgs/stellar/discussions/1834)
## Ecosystem Snapshot: $2B in Tokenized Real-World Assets
diff --git a/meetings/2026-04-30.mdx b/meetings/2026-04-30.mdx
index aa99f7bd51..9acd5fabce 100644
--- a/meetings/2026-04-30.mdx
+++ b/meetings/2026-04-30.mdx
@@ -10,15 +10,15 @@ import YouTube from "@site/src/components/YouTube";
## Protocol Discussion: Modular Custom Accounts and Signature Security in Protocol 27
-This protocol meeting covered two related authorization changes coming in Protocol 27, presented by Dmytro Kozhevin: a recap of CAP-71's authentication delegation for custom accounts, and a newly published security addendum, CAP-0071-02, that closes a narrow signature replay gap.
+This protocol meeting covered two related authorization changes coming in Protocol 27, presented by Dmytro Kozhevin: a recap of CAP-71's authentication delegation for custom accounts, and a newly published security addendum, CAP-71-02, that closes a narrow signature replay gap.
## CAP-71 Recap: Authentication Delegation for Custom Accounts
CAP-71 has been around for a while and hasn't changed — the news is that it is actually being implemented in Protocol 27. It improves what modular custom accounts can do by adding **built-in delegation support at the protocol level**. A "root" account can delegate logic — for example, the cryptography implementation — to separate "sub-account" contracts. That makes it possible to have an abstract, configurable meta-account shared by multiple users, with the actual signing logic living in different contracts.
-This architecture has already been attempted in the wild (OpenZeppelin's contract examples use it), but until now it was painful: delegating the authorization context required several rounds of pre-simulation to propagate the context. CAP-0071-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.
+This architecture has already been attempted in the wild (OpenZeppelin's contract examples use it), but until now it was painful: delegating the authorization context required several rounds of pre-simulation to propagate the context. CAP-71-01 builds the delegation mechanism directly into the protocol, which should make life significantly easier for anyone developing custom accounts.
-## CAP-0071-02: Closing a Signature Replay Gap
+## CAP-71-02: Closing a Signature Replay Gap
The reason a separate addendum exists: CAP-71 introduced a new kind of signature payload preimage, and that surfaced a small oversight in the original design. Soroban uses a unified format for signature payloads — a preimage carrying most of the necessary context, hashed with SHA-256 and then signed with an arbitrary cryptographic algorithm. "Most" is the key word: the standard authorization payload does **not** include the signer's address.
@@ -40,8 +40,8 @@ As of Protocol 27, the old address credentials are **not** being deprecated —
Read more about the proposals here:
-[CAP-0071](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
+[CAP-71](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
-[CAP-0071-01](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071-01.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
+[CAP-71-01](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071-01.md) - [Discussion](https://github.com/orgs/stellar/discussions/1784)
-[CAP-0071-02](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071-02.md) - [Discussion](https://github.com/orgs/stellar/discussions/1899)
+[CAP-71-02](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071-02.md) - [Discussion](https://github.com/orgs/stellar/discussions/1899)
diff --git a/meetings/2026-05-21.mdx b/meetings/2026-05-21.mdx
index 6af8c3b429..2a1a78cc97 100644
--- a/meetings/2026-05-21.mdx
+++ b/meetings/2026-05-21.mdx
@@ -16,7 +16,7 @@ A quick reframing before he starts, because it's load-bearing for everything he
## The Substrate: Why the Economics Only Work on Stellar
-He grounds the whole talk in CAP-0059, which shipped the native BLS12-381 host functions to Soroban: G1/G2 addition, scalar multiplication, multi-scalar multiplication, pairing checks, and full scalar-field arithmetic. That's the complete substrate you need to do production-grade Groth16 verification natively, available to any contract.
+He grounds the whole talk in CAP-59, which shipped the native BLS12-381 host functions to Soroban: G1/G2 addition, scalar multiplication, multi-scalar multiplication, pairing checks, and full scalar-field arithmetic. That's the complete substrate you need to do production-grade Groth16 verification natively, available to any contract.
His pitch for _why Stellar_ comes down to cost. A pairing check that would take tens of millions of Wasm instructions on another chain runs as a single host call here. No other smart-contract chain has this combination at this cost point today — which is exactly what pulled him to the network and got him researching ZK on it in the first place.