📝 Simplify CAP reference formatting

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.

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

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.
 

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:
 

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.
 

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"];

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
 

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:
 

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
 

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.

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 |
 | --- | --- | --- |

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

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<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1575
+CAP-62 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0062.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1575
 
-CAP-0066 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1585
+CAP-66 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0066.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1585

meetings/2025-01-30.mdx

@@ -18,10 +18,10 @@ Visit their website here: https://rampmedaddy.com
 
 <b>Part 2</b>
 
-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<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1610
+CAP-64 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0064.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1610
 
-CAP-0065 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1615
+CAP-65 - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0065.md<br /> Discussion - https://github.com/stellar/stellar-protocol/discussions/1615

meetings/2025-02-06.mdx

@@ -18,14 +18,14 @@ Visit their website here: https://reflector.network
 
 <YouTube ID="lzxv5ij6TLw" />
 
-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)

meetings/2025-02-13.mdx

@@ -22,14 +22,14 @@ Links:
 
 <YouTube ID="u204TwiHJpE" />
 
-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)

meetings/2025-02-20.mdx

@@ -24,10 +24,10 @@ Links:
 
 <YouTube ID="hDIP22z6nq4" />
 
-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)