🔗 SDF to Actual Repo Links

docs/build/apps/example-application-tutorial/anchor-integration/sep6.mdx

@@ -23,7 +23,7 @@ export async function getTransferServerSep6(domain) {
 
 ## Get `/info`
 
-Now that we know where the transfer server is located, BasicPay needs to fetch the `/info` endpoint from the anchor's transfer server to understand the supported transfer methods ([deposit, withdraw, deposit-exchange, and withdraw-exchange](https://stellar.org/protocol/sep-6#info)) and available endpoints, as well as additional features that may be available during transfers.
+Now that we know where the transfer server is located, BasicPay needs to fetch the `/info` endpoint from the anchor's transfer server to understand the supported transfer methods ([deposit, withdraw, deposit-exchange, and withdraw-exchange](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0006.md#info)) and available endpoints, as well as additional features that may be available during transfers.
 
 :::note
 

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://stellar.org/protocol/cap-27), introduced in Protocol 13, and their string representation is described in [SEP-0023](https://stellar.org/protocol/sep-23).
+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-0023](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0023.md).
 
 It is safe for all wallets to implement sending to muxed accounts.
 
@@ -432,7 +432,7 @@ This error message indicates that the `trustor` failed to parse as a Stellar acc
 
 **How do I validate Stellar addresses?**
 
-You should use the validation methods provided by your SDK or carefully adhere to [SEP-23](https://stellar.org/protocol/sep-23). For example, the JavaScript SDK provides the following methods for validating Stellar addresses:
+You should use the validation methods provided by your SDK or carefully adhere to [SEP-23](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0023.md). For example, the JavaScript SDK provides the following methods for validating Stellar addresses:
 
 ```ts
 namespace StrKey {

docs/data/indexers/build-your-own/processors/token-transfer-processor/README.mdx

@@ -7,7 +7,7 @@ sidebar_position: 0
 
 The Token Transfer Processor (TTP) is a [Go package](https://github.com/stellar/go-stellar-sdk/tree/main/ingest/processors/token_transfer) which uses the [ingest-sdk](../../ingest-sdk/README.mdx) to parse Stellar network transaction data and derive token transfer events. Before TTP, developers had to manually parse complex ledger data, operation results, and ledger entry changes to understand when and how value moved between accounts, contracts, and other entities on the network.
 
-Prior to [CAP-67 Unified Events][cap67], tracking token transfers required significant custom logic to handle different operation types, interpret ledger changes, and reconstruct the flow of assets. CAP-67 introduced a standardized event format that simplifies this process by providing a unified way to represent all token transfer activities.
+Prior to [CAP-67 Unified Events](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md), tracking token transfers required significant custom logic to handle different operation types, interpret ledger changes, and reconstruct the flow of assets. CAP-67 introduced a standardized event format that simplifies this process by providing a unified way to represent all token transfer activities.
 
 TTP serves as a facade to CAP-67, automatically generating these standardized events from Stellar ledger data. It can operate in two modes:
 
@@ -28,7 +28,7 @@ For more details on operational modes, see the [Modes of Operation](#modes-of-op
   - Liquidity pool operations
   - Clawback operations
   - Stellar Asset Contract events
-  - [SEP-41][sep41] compliant token events
+  - [SEP-41](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md) compliant token events
 
 - Generates CAP-67 standardized token events:
   - Transfer: Movement of tokens between accounts
@@ -84,7 +84,7 @@ Every token transfer event includes comprehensive metadata to provide context ab
 | --- | --- | --- |
 | `ledgerSequence` | `uint32` | The ledger number where this event occurred. This provides chronological ordering across the entire network. |
 | `txHash` | `string` | The transaction hash that generated this event. This allows you to trace events back to their originating transaction. |
-| `operationIndex` | `uint32*` | The one-based index of the operation within the transaction that caused this event as defined by [SEP-35][sep35]. This field is `nil` for transaction-level events like fees. |
+| `operationIndex` | `uint32*` | The one-based index of the operation within the transaction that caused this event as defined by [SEP-35](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0035.md). This field is `nil` for transaction-level events like fees. |
 | `contractAddress` | `string` | The contract address associated with the asset/token being moved. For classic operations or Stellar Asset Contract Events, this field will be the contractId of the underlying classic asset. This enables integration with Stellar's smart contract ecosystem. |
 
 :::note
@@ -95,7 +95,7 @@ The `toMuxedInfo` field is included in Transfer and Mint events when the destina
 
 Please refer to [this](../../../../../build/guides/transactions/pooled-accounts-muxed-accounts-memos.mdx) section for more information on muxed account/memo usage.
 
-Please refer to [this](https://stellar.org/protocol/cap-67#prohibit-the-transaction-memo-and-muxed-source-accounts-from-being-set-on-soroban-transactions) section in CAP-67 to learn more on what to expect in the `toMuxedInfo` field.
+Please refer to [this](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md#prohibit-the-transaction-memo-and-muxed-source-accounts-from-being-set-on-soroban-transactions) section in CAP-67 to learn more on what to expect in the `toMuxedInfo` field.
 
 :::note
 
@@ -225,11 +225,7 @@ The chronological ordering ensures that when you process events in the order ret
 
 ## References
 
-- [CAP-67: Unified Events][cap67]
-- [SEP-41: Asset Token Contract Specification][sep41]
-- [CAP-38: Automated Market Makers](https://stellar.org/protocol/cap-38)
-- [SEP-35: ID Scheme for Stellar Operations][sep35]
-
-[sep41]: https://stellar.org/protocol/sep-41
-[cap67]: https://stellar.org/protocol/cap-67
-[sep35]: https://stellar.org/protocol/sep-35
+- [CAP-67: Unified Events](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md)
+- [SEP-41: Asset Token Contract Specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md)
+- [CAP-38: Automated Market Makers](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md)
+- [SEP-35: ID Scheme for Stellar Operations](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0035.md)

docs/learn/fundamentals/stellar-data-structures/events.mdx

@@ -188,7 +188,7 @@ Events are ephemeral: RPC providers typically only keep short chunks (less than
 
 To learn more about working with events, take a look at the [events guides](../../../build/guides/events/README.mdx) and [this example contract](../../../build/smart-contracts/example-contracts/events.mdx).
 
-For a quick high-level demonstration, though, we'll use the [TypeScript SDK](../../../tools/sdks/README.mdx) to infinitely fetch all `transfer` events (defined by the [Soroban Token Interface](https://stellar.org/protocol/sep-41#interface)) involving the [XLM contract](https://stellar.expert/explorer/testnet/contract/CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC) and display them in a human-friendly format.
+For a quick high-level demonstration, though, we'll use the [TypeScript SDK](../../../tools/sdks/README.mdx) to infinitely fetch all `transfer` events (defined by the [Soroban Token Interface](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md#interface)) involving the [XLM contract](https://stellar.expert/explorer/testnet/contract/CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC) and display them in a human-friendly format.
 
 <CodeExample>
 
@@ -212,7 +212,7 @@ async function main() {
     type: "contract",
     contractIds: [Asset.native().contractId(Networks.TESTNET)],
     topics: [
-      // Defined in https://stellar.org/protocol/sep-41#interface
+      // Defined in https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md#interface
       // for all compatible transfer events.
       [
         nativeToScVal("transfer", { type: "symbol" }).toXDR("base64"),

docs/platforms/anchor-platform/api-reference/platform/rpc/anchor-platform.openrpc.json

@@ -1276,7 +1276,7 @@
               "type": "string"
             },
             "customers": {
-              "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
+              "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
               "type": "object",
               "properties": {
                 "sender": {
@@ -1992,7 +1992,7 @@
                     "type": "string"
                   },
                   "customers": {
-                    "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
+                    "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
                     "type": "object",
                     "properties": {
                       "sender": {

docs/platforms/stellar-disbursement-platform/admin-guide/making-your-wallet-sdp-ready.mdx

@@ -170,5 +170,5 @@ The SDP supports a basic link format, such as `https://<host-with-optional-path>
 [deferred deep linking]: https://en.wikipedia.org/wiki/Mobile_deep_linking#Deferred_deep_linking
 [deep link]: https://en.wikipedia.org/wiki/Mobile_deep_linking
 [deep linking]: https://en.wikipedia.org/wiki/Mobile_deep_linking
-[sep-10]: https://stellar.org/protocol/sep-10
-[sep-24]: https://stellar.org/protocol/sep-24
+[sep-10]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md
+[sep-24]: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0024.md

openapi/anchor-platform/bundled-callbacks.yaml

@@ -14,7 +14,7 @@ servers:
   - url: https://callback.business-server.exampleanchor.com
 tags:
   - name: Unique Address
-    description: (optional) Provide a unique `stellar_address:memo` pair that will be used to correlate a Stellar payment 1-to-1 with a Platform resource such as a [SEP-31](https://stellar.org/protocol/sep-31) transaction.
+    description: (optional) Provide a unique `stellar_address:memo` pair that will be used to correlate a Stellar payment 1-to-1 with a Platform resource such as a [SEP-31](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md) transaction.
   - name: Rates
     description: Requests containing data that can be used to provide exchange rates between on & off-chain assets.
   - name: Customers
@@ -1111,7 +1111,7 @@ components:
         customers:
           type: object
           description: |
-            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),
+            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),
             this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.
           properties:
             sender:

openapi/anchor-platform/bundled-platform.yaml

@@ -637,7 +637,7 @@ components:
         customers:
           type: object
           description: |
-            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),
+            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),
             this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.
           properties:
             sender:

openapi/anchor-platform/main-callbacks.yaml

@@ -14,7 +14,7 @@ servers:
   - url: https://callback.business-server.exampleanchor.com
 tags:
   - name: "Unique Address"
-    description: "(optional) Provide a unique `stellar_address:memo` pair that will be used to correlate a Stellar payment 1-to-1 with a Platform resource such as a [SEP-31](https://stellar.org/protocol/sep-31) transaction."
+    description: "(optional) Provide a unique `stellar_address:memo` pair that will be used to correlate a Stellar payment 1-to-1 with a Platform resource such as a [SEP-31](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0031.md) transaction."
   - name: "Rates"
     description: "Requests containing data that can be used to provide exchange rates between on & off-chain assets."
   - name: "Customers"

openapi/anchor-platform/schemas.yaml

@@ -469,7 +469,7 @@ components:
         customers:
           type: object
           description: |
-            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),
+            The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),
             this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.
           properties:
             sender:

openrpc/src/anchor-platform/schemas/customer.json

@@ -18,7 +18,7 @@
     }
   },
   "customers": {
-    "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://stellar.org/protocol/sep-12),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
+    "description": "The Identification info of the sending and receiving customers. If they were created through [SEP-12](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md),\n            this object should contain the SEP-12 customer `id`. Otherwise, the `account` address of the customer.",
     "type": "object",
     "properties": {
       "sender": {
@@ -29,4 +29,4 @@
       }
     }
   }
-}
+}