diff --git a/docs/build/agentic-payments/mpp/README.mdx b/docs/build/agentic-payments/mpp/README.mdx index 3887668879..2009de77af 100644 --- a/docs/build/agentic-payments/mpp/README.mdx +++ b/docs/build/agentic-payments/mpp/README.mdx @@ -37,19 +37,19 @@ Two credential modes are available: - **Pull** (default) — The client prepares and signs the Soroban authorization entries; the server broadcasts the transaction. Supports an optional sponsored path where the server rebuilds the transaction with its own account as source, so the client never pays network fees. - **Push** — The client broadcasts the transaction itself and sends a `signedHash` credential for server verification — the transaction hash plus a signature proving the client controls the paying (`from`) account. -See the [MPP Charge Guide](./charge-guide.mdx) to get started. +Learn more in the [MPP Charge Guide](./charge-guide.mdx) to get started. ### Session The session intent enables high-frequency, pay-as-you-go payments over unidirectional [payment channels](https://github.com/stellar-experimental/one-way-channel). The funder deposits tokens into the channel once, then makes many off-chain payments by signing cumulative commitments — no per-payment on-chain transactions, ideal for AI agent interactions. The server settles by closing the channel when convenient. -See the [MPP Session Guide](./channel-guide.mdx) to get started. +Learn more in the [MPP Session Guide](./channel-guide.mdx) to get started. ## Demo Try the live demo at [mpp.stellar.buzz](https://mpp.stellar.buzz), or run the [MPP Demo](https://github.com/stellar/stellar-mpp-sdk/tree/main/demo) locally. It runs a Node.js server that charges 0.01 USDC per request and a minimal browser UI for testing end-to-end payment flows on Stellar Testnet. -To build an MPP-enabled service or integrate payments into your app, see [Build Applications](../../apps/README.mdx) and the resources below. +To build an MPP-enabled service or integrate payments into your app, start with [Build Applications](../../apps/README.mdx) and the resources below. ## Install diff --git a/docs/build/agentic-payments/mpp/channel-guide.mdx b/docs/build/agentic-payments/mpp/channel-guide.mdx index 1f4e0631b8..acad1f561b 100644 --- a/docs/build/agentic-payments/mpp/channel-guide.mdx +++ b/docs/build/agentic-payments/mpp/channel-guide.mdx @@ -98,7 +98,7 @@ Before using channel mode, you need a deployed [one-way-channel contract](https: - A **commitment key** — an ed25519 keypair. The client signs commitments with the private key; the contract verifies with the public key. - A **token deposit** — the funder's initial balance in the channel asset. This example uses USDC. -See the [one-way-channel repo](https://github.com/stellar-experimental/one-way-channel) for deployment instructions. +Learn more in the [one-way-channel repo](https://github.com/stellar-experimental/one-way-channel) for deployment instructions. ## Session server diff --git a/docs/build/agentic-payments/mpp/charge-guide.mdx b/docs/build/agentic-payments/mpp/charge-guide.mdx index 38d0376f6e..be99088731 100644 --- a/docs/build/agentic-payments/mpp/charge-guide.mdx +++ b/docs/build/agentic-payments/mpp/charge-guide.mdx @@ -154,7 +154,7 @@ app.listen(PORT, () => { }); ``` -Set `STELLAR_RECIPIENT` to the Stellar public key (`G...`) for the account that should receive USDC payments. Your account will need a testnet USDC trustline — see [Setting up a testnet wallet](#setting-up-a-testnet-wallet) below. +Set `STELLAR_RECIPIENT` to the Stellar public key (`G...`) for the account that should receive USDC payments. Your account will need a testnet USDC trustline. Learn more in [Setting up a testnet wallet](#setting-up-a-testnet-wallet) below. Start the API locally: @@ -440,7 +440,7 @@ When `feePayer` is configured, the server automatically signals fee sponsorship :::info[Channel open removal] -The channel `open` MPP action was removed in v0.7 as it was dead code — the Soroban contract has no on-chain open entrypoint. Channels are created on-chain directly by signing and broadcasting a deploy transaction. See the [MPP Session Guide](./channel-guide.mdx) for channel setup details. +The channel `open` MPP action was removed in v0.7 as it was dead code — the Soroban contract has no on-chain open entrypoint. Channels are created on-chain directly by signing and broadcasting a deploy transaction. Learn more in the [MPP Session Guide](./channel-guide.mdx) for channel setup details. ::: diff --git a/docs/build/agentic-payments/x402/README.mdx b/docs/build/agentic-payments/x402/README.mdx index 821c60eed2..eea7dc5eb9 100644 --- a/docs/build/agentic-payments/x402/README.mdx +++ b/docs/build/agentic-payments/x402/README.mdx @@ -11,7 +11,7 @@ keywords: x402 is an open protocol from the Coinbase Developer Platform that enables programmatic, per request payments over HTTP, designed especially for AI agents and APIs. It effectively turns the old “402 Payment Required” HTTP status code into something usable, for both humans and AI agents. -On Stellar, x402 works with Soroban authorization so that clients can pay for API requests via signed auth entries, ideal for micropayments and payment enabled apps. To build an x402-enabled service or integrate payments into your app, see [Build Applications](../../apps/README.mdx) and the resources below. +On Stellar, x402 works with Soroban authorization so that clients can pay for API requests via signed auth entries, ideal for micropayments and payment enabled apps. To build an x402-enabled service or integrate payments into your app, start with [Build Applications](../../apps/README.mdx) and the resources below. ## Demo diff --git a/docs/build/agentic-payments/x402/built-on-stellar.mdx b/docs/build/agentic-payments/x402/built-on-stellar.mdx index 21acb6b4d6..cb5335e6f1 100644 --- a/docs/build/agentic-payments/x402/built-on-stellar.mdx +++ b/docs/build/agentic-payments/x402/built-on-stellar.mdx @@ -176,7 +176,7 @@ This approach provides several benefits: ## Self-hosting -If you want to run your own instance of the facilitator instead of using the hosted service, you can deploy the OpenZeppelin Relayer with the x402 Facilitator Plugin directly. See the [OpenZeppelin x402 Facilitator guide][oz-facilitator-guide] and the [plugin source code][oz-plugin] for setup instructions. +If you want to run your own instance of the facilitator instead of using the hosted service, you can deploy the OpenZeppelin Relayer with the x402 Facilitator Plugin directly. Learn more in the [OpenZeppelin x402 Facilitator guide][oz-facilitator-guide] and the [plugin source code][oz-plugin] for setup instructions. ## Resources diff --git a/docs/build/apps/example-application-tutorial/account-creation.mdx b/docs/build/apps/example-application-tutorial/account-creation.mdx index 924d4aa1d2..9e98b4587e 100644 --- a/docs/build/apps/example-application-tutorial/account-creation.mdx +++ b/docs/build/apps/example-application-tutorial/account-creation.mdx @@ -3,7 +3,7 @@ title: Account Creation sidebar_position: 20 --- -Accounts are the central data structure in Stellar and can only exist with a valid keypair (a public and secret key) and the required minimum balance of XLM. Read more in the [Accounts section]. +Accounts are the central data structure in Stellar and can only exist with a valid keypair (a public and secret key) and the required minimum balance of XLM. Learn more in the [Accounts section]. ## User experience diff --git a/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx b/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx index 0890e73a58..0136e1973f 100644 --- a/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx +++ b/docs/build/apps/example-application-tutorial/anchor-integration/setup.mdx @@ -3,7 +3,7 @@ title: "Setup for Anchored Assets" sidebar_position: 10 --- -An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Read more about anchors in this [anchor section](../../../../learn/fundamentals/anchors.mdx). +An anchor is a Stellar-specific term for the on and off-ramps that connect the Stellar network to traditional financial rails, such as financial institutions or fintech companies. When a user deposits with an anchor, that anchor will credit their Stellar account with the equivalent amount of digital tokens. The user can then hold, transfer, or trade those tokens just like any other Stellar asset. When a user withdraws those tokens, the anchor redeems them for cash in hand or money in the bank. Learn more about anchors in the [Anchors section](../../../../learn/fundamentals/anchors.mdx). When a customer downloads a wallet application that is connected to an anchor service, their Stellar account can either be created by the wallet application or the anchor service. In this example, the account has been created by the wallet application, BasicPay. Account creation strategies are described more in-depth [here](../../application-design-considerations.mdx#account-creation-strategies). @@ -11,7 +11,7 @@ In this example, we’ll use an anchor on Stellar’s Testnet to simulate a bank :::info -SEPs define community-decided standards for interoperability on Stellar. Read more in our [SEPs section](../../../../learn/fundamentals/stellar-ecosystem-proposals.mdx). +SEPs define community-decided standards for interoperability on Stellar. Learn more in our [SEPs section](../../../../learn/fundamentals/stellar-ecosystem-proposals.mdx). ::: diff --git a/docs/build/apps/example-application-tutorial/path-payment.mdx b/docs/build/apps/example-application-tutorial/path-payment.mdx index 02437b0835..d3d6cef865 100644 --- a/docs/build/apps/example-application-tutorial/path-payment.mdx +++ b/docs/build/apps/example-application-tutorial/path-payment.mdx @@ -3,7 +3,7 @@ title: Path Payment sidebar_position: 50 --- -A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Read more in the [Path Payments Guide](../../../build/guides/transactions/path-payments.mdx). +A path payment is where the asset sent can be different from the asset received. There are two possible path payment operations: 1) `path_payment_strict_send`, which allows the user to specify the amount of the asset to send, and 2) `path_payment_strict_receive`, which allows the user to specify the amount of the asset received. Learn more in the [Path Payments guide](../../../build/guides/transactions/path-payments.mdx). ## User experience diff --git a/docs/build/apps/example-application-tutorial/payment.mdx b/docs/build/apps/example-application-tutorial/payment.mdx index 3b097d9e4b..6669a5bd2b 100644 --- a/docs/build/apps/example-application-tutorial/payment.mdx +++ b/docs/build/apps/example-application-tutorial/payment.mdx @@ -13,7 +13,7 @@ In our BasicPay application, the user will navigate to the Payments page where c The user clicks the "Confirm Transaction" button. If the destination account exists and is properly funded with XLM, this will trigger a Transaction Preview where they can view the transaction details. -All Stellar transactions require a small fee to make it to the ledger. Read more in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx). +All Stellar transactions require a small fee to make it to the ledger. Learn more in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx). In BasicPay, we’ve set it up so that the user always pays a static fee of 100,000 [stroops](../../../learn/fundamentals/stellar-data-structures/assets.mdx#amount-precision) (one stroop equals 0.0000001 XLM) per operation. Alternatively, you can add a feature to your application that allows the user to set their own fee. diff --git a/docs/build/apps/guestbook/bindings.mdx b/docs/build/apps/guestbook/bindings.mdx index 13ba71b1b6..336c762052 100644 --- a/docs/build/apps/guestbook/bindings.mdx +++ b/docs/build/apps/guestbook/bindings.mdx @@ -104,7 +104,7 @@ That was a lot of steps and a lot of work wasn't it!? The good news is that our - Generate bindings from the deployed contracts - Create a `$lib/contracts/.ts` file for easy import into your frontend code -You can always customize this script to suit your needs. Check out the [source code here](https://github.com/ElliotFriend/soroban-template-sveltekit-passkeys/blob/main/initialize.js) (which has been documented with comments). Or, you can see the [officially maintained script](https://github.com/stellar/soroban-template-astro/blob/main/initialize.js) in the [`soroban-template-astro` repository](https://github.com/stellar/soroban-template-astro), as well. +You can always customize this script to suit your needs. Check out the [source code here](https://github.com/ElliotFriend/soroban-template-sveltekit-passkeys/blob/main/initialize.js) (which has been documented with comments). Or, you can learn more in the [officially-maintained script](https://github.com/stellar/soroban-template-astro/blob/main/initialize.js) in the [`soroban-template-astro` repository](https://github.com/stellar/soroban-template-astro), as well. Run the initialization script like so: diff --git a/docs/build/apps/overview.mdx b/docs/build/apps/overview.mdx index 4e15f56c94..560ff8913e 100644 --- a/docs/build/apps/overview.mdx +++ b/docs/build/apps/overview.mdx @@ -17,7 +17,7 @@ This documentation includes sections on how to build applications without smart Many Stellar assets connect to real-world currencies, and Stellar has open protocols for integrating deposits and withdrawals of these assets via the [anchor network](https://stellar.org/learn/anchor-basics). Because of this, a Stellar-based application can take advantage of real banking rails and connect to real money. -Read more about anchors in our [Anchors section](../../learn/fundamentals/anchors.mdx). +Learn more about anchors in our [Anchors section](../../learn/fundamentals/anchors.mdx). Set up an anchor using the [Anchor Platform](../../platforms/anchor-platform/README.mdx). diff --git a/docs/build/apps/wallet/component/kt/configClient.mdx b/docs/build/apps/wallet/component/kt/configClient.mdx index b7a087f07c..4b24a37c43 100644 --- a/docs/build/apps/wallet/component/kt/configClient.mdx +++ b/docs/build/apps/wallet/component/kt/configClient.mdx @@ -1,6 +1,6 @@ ### Configuring the Client -The Kotlin wallet SDK uses the [ktor client](https://ktor.io/docs/getting-started-ktor-client.html) for all network requests (excluding Horizon, where the Stellar SDK's HTTP client is used). Currently, the okhttp engine is configured to be used with the client. You can read more about how to configure the ktor client [here](https://ktor.io/docs/create-client.html#configure-client). +The Kotlin wallet SDK uses the [ktor client](https://ktor.io/docs/getting-started-ktor-client.html) for all network requests (excluding Horizon, where the Stellar SDK's HTTP client is used). Currently, the okhttp engine is configured to be used with the client. Learn more in the [Ktor client configuration documentation](https://ktor.io/docs/create-client.html#configure-client). For example, the client can be globally configured: diff --git a/docs/build/apps/wallet/component/kt/watcher.mdx b/docs/build/apps/wallet/component/kt/watcher.mdx index f5af354ee9..0c8dd04df8 100644 --- a/docs/build/apps/wallet/component/kt/watcher.mdx +++ b/docs/build/apps/wallet/component/kt/watcher.mdx @@ -20,6 +20,6 @@ This code example will consume all events coming from the channel until it's clo :::info -Events are stored in the channel until they are received, and calling the `receive()` method will block the channel until a message is received. You can read more about how channels work in the [channel documentation](https://kotlinlang.org/docs/coroutines-and-channels.html#channels). +Events are stored in the channel until they are received, and calling the `receive()` method will block the channel until a message is received. Learn more about how channels work in the [channel documentation](https://kotlinlang.org/docs/coroutines-and-channels.html#channels). ::: diff --git a/docs/build/apps/wallet/component/ts/configClient.mdx b/docs/build/apps/wallet/component/ts/configClient.mdx index 25526e8c06..294e30e1bc 100644 --- a/docs/build/apps/wallet/component/ts/configClient.mdx +++ b/docs/build/apps/wallet/component/ts/configClient.mdx @@ -1,6 +1,6 @@ ### Configuring the Client -The Typescript wallet SDK uses the [axios client](https://axios-http.com/docs/intro) for all network requests. You can read more about how to configure the axios client [here](https://axios-http.com/docs/instance). +The Typescript wallet SDK uses the [axios client](https://axios-http.com/docs/intro) for all network requests. Learn more in the [Axios instance documentation](https://axios-http.com/docs/instance). For example, we can configure our axios client to be globally configured with a timeout: diff --git a/docs/build/apps/wallet/intro.mdx b/docs/build/apps/wallet/intro.mdx index e44777c6c2..6b544035a4 100644 --- a/docs/build/apps/wallet/intro.mdx +++ b/docs/build/apps/wallet/intro.mdx @@ -123,7 +123,7 @@ Default configuration connects to the public Stellar Horizon instance. You can c ::: -You can read more about working with the Stellar network in the [respective section](./stellar.mdx). +Learn more in the [Stellar Network section](./stellar.mdx). ## Anchor Basics diff --git a/docs/build/apps/wallet/sep30.mdx b/docs/build/apps/wallet/sep30.mdx index 5fe5593e05..8d5b1da6a5 100644 --- a/docs/build/apps/wallet/sep30.mdx +++ b/docs/build/apps/wallet/sep30.mdx @@ -176,7 +176,7 @@ let identity2 = [ Here, stellar key and email are used as recovery methods. Other recovery servers may support phone as a recovery method as well. -You can read more about SEP-30 identities [here](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md#common-request-fields) +Learn more about SEP-30 identities in the [Common Request Fields section](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0030.md#common-request-fields). Next, let's create a recoverable account: @@ -233,7 +233,7 @@ let recoverableWallet = try await recovery.createRecoverableWallet(config: confi With the given parameters, this function will create a transaction that will: 1. Set `deviceKp` as the primary account key. Please note that the master key belonging to `accountKp` will be locked. `deviceKp` should be used as a primary signer instead. -2. Set all operation thresholds to 10. You can read more about threshold in the [documentation](../../../learn/fundamentals/transactions/signatures-multisig.mdx#thresholds) +2. Set all operation thresholds to 10. Learn more about thresholds in the [Signatures and Multisig section](../../../learn/fundamentals/transactions/signatures-multisig.mdx#thresholds). 3. Use identities that were defined earlier on both servers. (That means, both server will accept SEP-10 authentication via `recoveryKp` as an auth method) 4. Set device key weight to 10, and recovery server weight to 5. Given these account thresholds, both servers must be used to recover the account, as transaction signed by one will only have weight of 5, which is not sufficient to change account key. diff --git a/docs/build/apps/wallet/sep6.mdx b/docs/build/apps/wallet/sep6.mdx index 88d596564b..fb84441283 100644 --- a/docs/build/apps/wallet/sep6.mdx +++ b/docs/build/apps/wallet/sep6.mdx @@ -12,7 +12,7 @@ import Header from "./component/header.mdx"; The [SEP-6] standard defines a way for anchors and wallets to interact on behalf of users. Wallets use this standard to facilitate exchanges between on-chain assets (such as stablecoins) and off-chain assets (such as fiat, or other network assets such as BTC). -Please note, this is for _programmatic_ deposits and withdrawals. For hosted deposits and withdrawals, where the anchor interacts with wallets interactively using a popup, please see [Hosted Deposit and Withdrawal](./sep24.mdx). +Please note, this is for _programmatic_ deposits and withdrawals. For hosted deposits and withdrawals, where the anchor interacts with wallets interactively using a popup, learn more in [Hosted Deposit and Withdrawal](./sep24.mdx). ## Get Anchor Information diff --git a/docs/build/apps/wallet/stellar.mdx b/docs/build/apps/wallet/stellar.mdx index 5fee192274..65f5c4dde3 100644 --- a/docs/build/apps/wallet/stellar.mdx +++ b/docs/build/apps/wallet/stellar.mdx @@ -576,7 +576,7 @@ let signedTransaction = stellar.decodeTransaction(xdr: xdrStringFromBackend) :::note -You can read more about passing XDR transaction to the server in the [chapter below](#using-xdr-to-send-transaction-data). +Learn more about passing XDR transaction to the server in the [chapter below](#using-xdr-to-send-transaction-data). ::: diff --git a/docs/build/building-with-ai.mdx b/docs/build/building-with-ai.mdx index 4543f61736..cc28ce4969 100644 --- a/docs/build/building-with-ai.mdx +++ b/docs/build/building-with-ai.mdx @@ -35,7 +35,7 @@ Unlike the static [`llms.txt`](#using-llmstxt) file and the installable [Stellar ### Connect your agent -Add the server, then sign in. Sign-in happens inside your own client (Raven uses OAuth), so the first request opens your browser to authorize. For full setup details see [raven.stellar.buzz](https://raven.stellar.buzz). +Add the server, then sign in. Sign-in happens inside your own client (Raven uses OAuth), so the first request opens your browser to authorize. For full setup details learn more at [raven.stellar.buzz](https://raven.stellar.buzz). {/* Rendered from src/data/agentTools.ts, shared with the "For agents" panel. */} diff --git a/docs/build/guides/archival/README.mdx b/docs/build/guides/archival/README.mdx index 262b3078e2..0dd3c2661a 100644 --- a/docs/build/guides/archival/README.mdx +++ b/docs/build/guides/archival/README.mdx @@ -4,4 +4,4 @@ hide_table_of_contents: true sidebar_position: 77 --- -Soroban's novel strategy to combat state bloat can present a learning curve for developers. Here are some quick guides that will help you through the process. Read more in the [State Archival section](../../../learn/fundamentals/contract-development/storage/state-archival.mdx). +Soroban's novel strategy to combat state bloat can present a learning curve for developers. Here are some quick guides that will help you through the process. Learn more in the [State Archival section](../../../learn/fundamentals/contract-development/storage/state-archival.mdx). diff --git a/docs/build/guides/archival/test-ttl-extension.mdx b/docs/build/guides/archival/test-ttl-extension.mdx index f74747c634..8844076409 100644 --- a/docs/build/guides/archival/test-ttl-extension.mdx +++ b/docs/build/guides/archival/test-ttl-extension.mdx @@ -1,5 +1,5 @@ --- -title: Test TTL extension logic in smart contracts +title: Test TTL Extension Logic in Smart Contracts hide_table_of_contents: true description: Test contracts that extend contract data time to live (TTL) --- @@ -77,7 +77,7 @@ fn create_env() -> Env { You could also use the current [network settings](https://lab.stellar.org/network-limits) when setting up the tests, but keep in mind that these are subject to change, and the contract should be able to work with any values of these settings. -Now we run a test scenario that verifies the TTL extension logic (see [`test_extend_ttl_behavior`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L38) test for the full scenario). First, we setup the data and ensure that the initial TTL values correspond to the network settings we've defined above: +Now we run a test scenario that verifies the TTL extension logic (learn more in the [`test_extend_ttl_behavior`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L38) test for the full scenario). First, we set up the data and ensure that the initial TTL values correspond to the network settings we've defined above: ```rust // Create initial entries and make sure their TTLs correspond to @@ -142,7 +142,7 @@ env.as_contract(&contract_id, || { }); ``` -Soroban SDK also emulates the behavior for the entries that have their TTL expired. Temporary entries behave 'as if' they were deleted (see [`test_temp_entry_removal`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L112) test for the full scenario): +Soroban SDK also emulates the behavior for the entries that have their TTL expired. Temporary entries behave 'as if' they were deleted (learn more in the [`test_temp_entry_removal`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L112) test for the full scenario): ```rust // Extend the temporary entry TTL to 7000 ledgers. @@ -157,7 +157,7 @@ env.as_contract(&contract_id, || { }); ``` -Persistent entries are more subtle: when a transaction that is executed on-chain contains a persistent entry that has been archived (i.e., it has its TTL expired) in the footprint, then the entry will be automatically restored. Automatic restoration is mostly transparent, the main side effect is the increased fees. (see [`test_persistent_entry_auto_restored`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L136) test for the full scenario): +Persistent entries are more subtle: when a transaction that is executed on-chain contains a persistent entry that has been archived (i.e., it has its TTL expired) in the footprint, then the entry will be automatically restored. Automatic restoration is mostly transparent, the main side effect is the increased fees. (learn more in the [`test_persistent_entry_auto_restored`](https://github.com/stellar/soroban-examples/blob/v23.0.0/ttl/src/test.rs#L136) test for the full scenario): ```rust // Extend the persistent entry TTL to 5000 ledgers. diff --git a/docs/build/guides/auth/contract-authorization.mdx b/docs/build/guides/auth/contract-authorization.mdx index 7c372010b3..d6044fd523 100644 --- a/docs/build/guides/auth/contract-authorization.mdx +++ b/docs/build/guides/auth/contract-authorization.mdx @@ -8,7 +8,7 @@ description: Learn about smart contract auth on Stellar Smart contracts can be invoked without any caller authorization by default. The functionality of the smart contract can either justify, or even require, authorization. Let’s say we want to read or write sensitive information: then access to the contract should be restricted through authorization. Authorization is required if the contract signs transactions. -For a deeper understanding of how authorization works, see the [Security](../../../learn/fundamentals/contract-development/authorization.mdx) section. +For a deeper understanding of how authorization works, learn more in the [Security](../../../learn/fundamentals/contract-development/authorization.mdx) section. ### Address-based authorization @@ -362,7 +362,7 @@ fn test_account() { } ``` -That snippet highlights the key inputs: contract address, payload, signature, and authorization tree. For the full tests, see the [Simple Account example](../../smart-contracts/example-contracts/simple-account.mdx); the Complex Account doc includes multisig and policy coverage. +That snippet highlights the key inputs: contract address, payload, signature, and authorization tree. For the full tests, learn more in the [Simple Account example](../../smart-contracts/example-contracts/simple-account.mdx); the Complex Account doc includes multisig and policy coverage. #### `set_auths()` @@ -445,6 +445,6 @@ Similar to how the host executes authorization on Testnet and Mainnet, `set_auth A `SorobanAuthorizationEntry` contains authorization credentials and contract invocation details. The credentials part specifies the contract address of `the __check_auth()` function, and relevant authorization data. The root invocation part specifies the contract ID, the name of the function being tested, and the function’s arguments. -For more information about authorization details provided in `set_auths()`, see the [Stellar Transactions](../../../learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx) documentation. +Learn more about authorization details provided in `set_auths()` in the [Stellar Transactions](../../../learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx) documentation. Testing using `set_auths()` is more complex than testing using `try_invoke_contract_check_auth`, but in return, it allows for more advanced testing scenarios. If more advanced testing, e.g., testing specific authorization edge cases, is required, `set_auths()` might be a good choice. Otherwise, `try_invoke_contract_check_auth` generally is the recommended method for testing. diff --git a/docs/build/guides/basics/verify-trustlines.mdx b/docs/build/guides/basics/verify-trustlines.mdx index b7ddca4255..b37e10e329 100644 --- a/docs/build/guides/basics/verify-trustlines.mdx +++ b/docs/build/guides/basics/verify-trustlines.mdx @@ -10,7 +10,7 @@ When performing payments on Stellar for [Stellar Assets](../../../tokens/README. In Stellar, trustlines are used to establish a relationship between an account and a Stellar Asset. They indicate that the account is willing to hold and transact with that asset. If a trustline is not established for an asset, the account cannot receive payments in that asset, leading to transaction failures. -Furthermore, asset issuers may enforce specific requirements through trustlines, such as maximum balances an account can hold or granular authorization to receive/send the asset or to maintain liabilities. See the [Asset Design Considerations](../../../tokens/control-asset-access.mdx) for more details on how control flags and trustlines can be used to customize these behaviors. +Furthermore, asset issuers may enforce specific requirements through trustlines, such as maximum balances an account can hold or granular authorization to receive/send the asset or to maintain liabilities. Learn more about how control flags and trustlines can customize these behaviors in the [Asset Design Considerations](../../../tokens/control-asset-access.mdx). Verifying trustlines before sending transactions helps ensure that the receiving account meets the requirements and can successfully receive the asset. This allows for the application to handle cases where trustlines are not established or invalid, providing clear feedback and a smooth user experience while preventing failed transactions. diff --git a/docs/build/guides/contract-accounts/advanced-patterns.mdx b/docs/build/guides/contract-accounts/advanced-patterns.mdx index e8fc4fd586..77db2d4a51 100644 --- a/docs/build/guides/contract-accounts/advanced-patterns.mdx +++ b/docs/build/guides/contract-accounts/advanced-patterns.mdx @@ -12,7 +12,7 @@ Use these patterns to extend a basic contract account with guardrails. Put the l - Derive a window key from the ledger timestamp (for example, `day = timestamp / 86_400`) and reset the total when the window changes. - On each request, check the remaining allowance; if the amount would exceed it, reject and emit an event with the attempted amount and remaining allowance. -See the [Complex Account example](../../smart-contracts/example-contracts/complex-account.mdx) for a reference implementation with weighted signers and limits. +Learn more in the [Complex Account example](../../smart-contracts/example-contracts/complex-account.mdx) for a reference implementation with weighted signers and limits. ## Allow lists diff --git a/docs/build/guides/contract-accounts/smart-wallets.mdx b/docs/build/guides/contract-accounts/smart-wallets.mdx index 966db466ae..646c49f0df 100644 --- a/docs/build/guides/contract-accounts/smart-wallets.mdx +++ b/docs/build/guides/contract-accounts/smart-wallets.mdx @@ -30,7 +30,7 @@ Benefits: - WebAuthn is the browser standard for passwordless auth. - secp256r1 is the curve most authenticators use; Stellar verifies it on-chain. - Passkeys are the platform or hardware-backed credentials that implement WebAuthn. -- See [examples](./examples.mdx) for real projects. +- Learn more in [the examples](./examples.mdx) for real projects. ## Passkeys in practice diff --git a/docs/build/guides/conventions/workspace.mdx b/docs/build/guides/conventions/workspace.mdx index aa08d49fd7..338485b991 100644 --- a/docs/build/guides/conventions/workspace.mdx +++ b/docs/build/guides/conventions/workspace.mdx @@ -75,7 +75,7 @@ impl ContractAdd { :::tip -In this tutorial we use workspaces to import contract client. However, it's also possible to use contract's compiled code instead (for example, if you don't have a source code for it). See [making cross-contract calls](./cross-contract.mdx) guide for more info +In this tutorial we use workspaces to import contract client. However, it's also possible to use contract's compiled code instead (for example, if you don't have a source code for it). Learn more in the [Making Cross-Contract Calls guide](./cross-contract.mdx). ::: diff --git a/docs/build/guides/conversions/address-conversions.mdx b/docs/build/guides/conversions/address-conversions.mdx index dea10efd24..1268e284fa 100644 --- a/docs/build/guides/conversions/address-conversions.mdx +++ b/docs/build/guides/conversions/address-conversions.mdx @@ -4,7 +4,7 @@ hide_table_of_contents: true description: Convert an address to other types --- -The `Address` is an opaque type that represents either a 'default' externally owned account on the Stellar network, or a contract (that may also provide logic for custom externally owned accounts, see [authorization docs](../../../learn/fundamentals/contract-development/authorization.mdx#account-abstraction) for details). For the smart contracts it normally doesn't matter which kind of `Address` is used. However, in some contexts it's useful to convert `Address` to/from different data types, such as string or XDR. The conversions have distinctly different purpose depending on whether they happen in the smart contract itself, or in the client code. +The `Address` is an opaque type that represents either a 'default' externally owned account on the Stellar network, or a contract (that may also provide logic for custom externally owned accounts, learn more in the [authorization docs](../../../learn/fundamentals/contract-development/authorization.mdx#account-abstraction) for details). For the smart contracts it normally doesn't matter which kind of `Address` is used. However, in some contexts it's useful to convert `Address` to/from different data types, such as string or XDR. The conversions have distinctly different purpose depending on whether they happen in the smart contract itself, or in the client code. ## String conversions diff --git a/docs/build/guides/dapps/frontend-guide.mdx b/docs/build/guides/dapps/frontend-guide.mdx index 612c7543ef..74d2bd3442 100644 --- a/docs/build/guides/dapps/frontend-guide.mdx +++ b/docs/build/guides/dapps/frontend-guide.mdx @@ -377,7 +377,7 @@ Now that we have our basic UI components in place, let's integrate them with the - Test network: This is a test environment for developers to test their applications without using real lumens. - Futurenet network: This is a network for testing new features before they are deployed to the public network. -For this guide, we'll be using the Test network to avoid using real lumens during development. Read more about the [Stellar networks here](../../../networks/README.mdx). +For this guide, we'll be using the Test network to avoid using real lumens during development. Learn more in the [Networks section](../../../networks/README.mdx). ### Setting up the Stellar SDK diff --git a/docs/build/guides/fees/cost-analysis.mdx b/docs/build/guides/fees/cost-analysis.mdx index b82e365908..6c28094c7a 100644 --- a/docs/build/guides/fees/cost-analysis.mdx +++ b/docs/build/guides/fees/cost-analysis.mdx @@ -4,4 +4,4 @@ hide_table_of_contents: true draft: true --- -See [issue #552](https://github.com/stellar/soroban-docs/issues/552) for more context +For additional context, learn more in [issue #552](https://github.com/stellar/soroban-docs/issues/552). diff --git a/docs/build/guides/rpc/README.mdx b/docs/build/guides/rpc/README.mdx index 621fad9f35..7941c14e38 100644 --- a/docs/build/guides/rpc/README.mdx +++ b/docs/build/guides/rpc/README.mdx @@ -4,4 +4,4 @@ hide_table_of_contents: true sidebar_position: 75 --- -Using and interacting with the Stellar RPC is an important part of the smart contract development lifecycle. Read more about the RPC in our [RPC documentation](../../../data/apis/rpc/README.mdx). +Using and interacting with the Stellar RPC is an important part of the smart contract development lifecycle. Learn more about the RPC in our [RPC documentation](../../../data/apis/rpc/README.mdx). diff --git a/docs/build/guides/storage/choosing-the-right-storage.mdx b/docs/build/guides/storage/choosing-the-right-storage.mdx index 8fc6f8d8e4..bca474f746 100644 --- a/docs/build/guides/storage/choosing-the-right-storage.mdx +++ b/docs/build/guides/storage/choosing-the-right-storage.mdx @@ -28,7 +28,7 @@ State archival is a special mechanism defined by the Stellar protocol that ensur TTL also may be extended however many times are necessary, for a fee. -Read more about state archival [here](../../../learn/fundamentals/contract-development/storage/state-archival.mdx). +Learn more in the [State Archival section](../../../learn/fundamentals/contract-development/storage/state-archival.mdx). ## Persistent storage diff --git a/docs/build/guides/testing/code-coverage.mdx b/docs/build/guides/testing/code-coverage.mdx index 6986014d11..77461888e0 100644 --- a/docs/build/guides/testing/code-coverage.mdx +++ b/docs/build/guides/testing/code-coverage.mdx @@ -9,7 +9,7 @@ Measuring code coverage uses tools to identify lines of code that are and aren't :::tip -Mutation testing is another form of coverage testing. See [Mutation Testing]. +Mutation testing is another form of coverage testing. Learn more in the [Mutation Testing section]. ::: @@ -51,10 +51,10 @@ Load the `lcov.info` file into your IDE using its coverage feature. In VSCode th :::info -Measuring code coverage in fuzz tests requires different tooling. See [Fuzzing]. +Measuring code coverage in fuzz tests requires different tooling. Learn more in the [Fuzzing section]. ::: [Coverage Gutters]: https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters -[Mutation Testing]: mutation-testing.mdx -[Fuzzing]: fuzzing.mdx +[Mutation Testing section]: mutation-testing.mdx +[Fuzzing section]: fuzzing.mdx diff --git a/docs/build/guides/testing/differential-tests-with-test-snapshots.mdx b/docs/build/guides/testing/differential-tests-with-test-snapshots.mdx index 8877adf34d..ad31a04c54 100644 --- a/docs/build/guides/testing/differential-tests-with-test-snapshots.mdx +++ b/docs/build/guides/testing/differential-tests-with-test-snapshots.mdx @@ -11,7 +11,7 @@ However tests are limited, as they only show changes to values that the tests as :::tip -Test snapshots are one tool for performing differential testing. See [Differential Testing] for other ways. +Test snapshots are one tool for performing differential testing. Learn more in the [Differential Testing section] for other ways. ::: @@ -62,6 +62,6 @@ Test snapshots files are verbose. Test snapshots are most useful when changes ap To give this a go, check out the [Getting Started] contract or any of the [examples], run the tests, and look for the test snapshots on disk. -[Differential Testing]: ./differential-tests.mdx +[Differential Testing section]: ./differential-tests.mdx [Getting Started]: ../../smart-contracts/getting-started/README.mdx [examples]: ../../smart-contracts/example-contracts/README.mdx diff --git a/docs/build/guides/testing/differential-tests.mdx b/docs/build/guides/testing/differential-tests.mdx index 5f5bd7ece3..1856c3364a 100644 --- a/docs/build/guides/testing/differential-tests.mdx +++ b/docs/build/guides/testing/differential-tests.mdx @@ -15,7 +15,7 @@ This strategy can be used in the context of unit and integration tests, or in th :::tip -All contracts built with the Rust Soroban SDK have a form of differential testing built-in and enabled by default. See [Differential Testing with Test Snapshots]. +All contracts built with the Rust Soroban SDK have a form of differential testing built-in and enabled by default. Learn more in [Differential Testing with Test Snapshots]. ::: diff --git a/docs/build/guides/testing/fuzzing.mdx b/docs/build/guides/testing/fuzzing.mdx index 6fc11d6652..3a3718bd32 100644 --- a/docs/build/guides/testing/fuzzing.mdx +++ b/docs/build/guides/testing/fuzzing.mdx @@ -112,13 +112,13 @@ This test uses the same patterns used in [unit tests] and [integration tests]: :::tip -For a full detailed example, see the [fuzzing example]. +For a full detailed example, learn more in the [fuzzing example]. ::: :::info -There is another tool for fuzzing Rust code, `cargo-afl`. See the [Rust Fuzz book] for a tutorial for how to use it. +There is another tool for fuzzing Rust code, `cargo-afl`. Learn more in the [Rust Fuzz book] for a tutorial for how to use it. ::: @@ -159,7 +159,7 @@ Getting code coverage data for fuzz tests requires some different tooling than w :::tip -To measure code coverage of regular Rust tests, see [Code Coverage]. +To measure code coverage of regular Rust tests, learn more in the [Code Coverage section]. ::: @@ -171,5 +171,5 @@ To measure code coverage of regular Rust tests, see [Code Coverage]. [stellar/rs-soroban-sdk#1360]: https://github.com/stellar/rs-soroban-sdk/issues/1360 [fuzzing example]: ../../smart-contracts/example-contracts/fuzzing.mdx [Rust Fuzz Book]: https://rust-fuzz.github.io/book -[Code Coverage]: code-coverage.mdx +[Code Coverage section]: code-coverage.mdx [Coverage Gutters]: https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters diff --git a/docs/build/guides/testing/ledger-snapshot-testing.mdx b/docs/build/guides/testing/ledger-snapshot-testing.mdx index 92f41f53bc..6b5ca47212 100644 --- a/docs/build/guides/testing/ledger-snapshot-testing.mdx +++ b/docs/build/guides/testing/ledger-snapshot-testing.mdx @@ -83,7 +83,7 @@ Now we have a working, deployed smart contract function that has stored a value ## 2. Create a ledger snapshot -A snapshot of the ledger can be created using the Stellar CLI. The CLI command allows you to customize and limit the scope of the snapshot, since it’s most likely not necessary for you to create a snapshot of all ledger entries. See the [documentation](../../../tools/cli/stellar-cli.mdx#stellar-snapshot-create) for full details about how to limit the snapshot. +A snapshot of the ledger can be created using the Stellar CLI. The CLI command allows you to customize and limit the scope of the snapshot, since it’s most likely not necessary for you to create a snapshot of all ledger entries. Learn more in the [documentation](../../../tools/cli/stellar-cli.mdx#stellar-snapshot-create) for full details about how to limit the snapshot. For the examples used here, we want to limit the ledger snapshot to include entries related to: diff --git a/docs/build/guides/testing/mocking.mdx b/docs/build/guides/testing/mocking.mdx index e37eb717c8..c788b89ca9 100644 --- a/docs/build/guides/testing/mocking.mdx +++ b/docs/build/guides/testing/mocking.mdx @@ -9,7 +9,7 @@ Mocks are used in tests to exclude functionality that a test doesn't want to tes :::tip -The [Soroban Rust SDK] makes it just as easy to test against a real contract as it does to test against a mock of a contract. In some ecosystems integration tests are avoided. Not in the Stellar ecosystem. See [Integration Tests]. +The [Soroban Rust SDK] makes it just as easy to test against a real contract as it does to test against a mock of a contract. In some ecosystems integration tests are avoided. Not in the Stellar ecosystem. Learn more in [Integration Tests]. ::: @@ -114,9 +114,9 @@ impl Pause { This is one reason why it's helpful to test and fuzz using real dependencies and to code defensively assuming any external contract call could cause your contract to fail. -See [Integration Tests] for how to test with real dependencies. +Learn more in the [Integration Tests section] for how to test with real dependencies. -The [Soroban Rust SDK] handles contract calls defensively so that any unexpected error or unexpected type returned from the called contract will cause execution to stop. The SDK also provides methods to make these calls and to intercept error situations. See [Making Cross-Contract Calls] for more details. +The [Soroban Rust SDK] handles contract calls defensively so that any unexpected error or unexpected type returned from the called contract will cause execution to stop. The SDK also provides methods to make these calls and to intercept error situations. Learn more in the [Making Cross-Contract Calls section]. ::: diff --git a/docs/build/guides/testing/test-contract-auth.mdx b/docs/build/guides/testing/test-contract-auth.mdx index 17f8cec910..a4ac1a1011 100644 --- a/docs/build/guides/testing/test-contract-auth.mdx +++ b/docs/build/guides/testing/test-contract-auth.mdx @@ -55,7 +55,7 @@ fn test() { :::tip -For the full example the above snippet is extracted from, see the [auth example contract](../../smart-contracts/example-contracts/auth.mdx). +For the full example the above snippet is extracted from, learn more in the [auth example contract](../../smart-contracts/example-contracts/auth.mdx). ::: diff --git a/docs/build/guides/testing/test-contract-events.mdx b/docs/build/guides/testing/test-contract-events.mdx index d9882fcf76..a593d4bfb8 100644 --- a/docs/build/guides/testing/test-contract-events.mdx +++ b/docs/build/guides/testing/test-contract-events.mdx @@ -50,6 +50,6 @@ fn test() { :::tip -For the full example the above snippet is extracted from, see the [events example contract](../../smart-contracts/example-contracts/events.mdx). +For the full example the above snippet is extracted from, learn more in the [events example contract](../../smart-contracts/example-contracts/events.mdx). ::: diff --git a/docs/build/guides/tokens/stellar-asset-contract.mdx b/docs/build/guides/tokens/stellar-asset-contract.mdx index 716eb856cc..774babb35a 100644 --- a/docs/build/guides/tokens/stellar-asset-contract.mdx +++ b/docs/build/guides/tokens/stellar-asset-contract.mdx @@ -38,7 +38,7 @@ stellar contract id asset \ --asset [asset:issuer] ``` -E.g. for USDC, it would be `--asset USDC:G...` For the native asset, XLM, `--asset native`. See the [deploy SAC] guide for more details. +E.g. for USDC, it would be `--asset USDC:G...` For the native asset, XLM, `--asset native`. Learn more in the [deploy SAC] guide. [deploy SAC]: ../../../tools/cli/cookbook/deploy-stellar-asset-contract.mdx diff --git a/docs/build/guides/transactions/README.mdx b/docs/build/guides/transactions/README.mdx index 366b6c5873..25c8bf0ff8 100644 --- a/docs/build/guides/transactions/README.mdx +++ b/docs/build/guides/transactions/README.mdx @@ -4,4 +4,4 @@ hide_table_of_contents: true sidebar_position: 120 --- -Stellar transactions are comprised of operations. These guides will walk you through various Stellar operations, non-contract transactions, and smart contract transactions. Read more about operations and transactions in the [Operations and Transactions section](../../../learn/fundamentals/transactions/README.mdx). +Stellar transactions are comprised of operations. These guides will walk you through various Stellar operations, non-contract transactions, and smart contract transactions. Learn more about operations and transactions in the [Operations and Transactions section](../../../learn/fundamentals/transactions/README.mdx). diff --git a/docs/build/guides/transactions/claimable-balances.mdx b/docs/build/guides/transactions/claimable-balances.mdx index b18669ee87..5bfedb1399 100644 --- a/docs/build/guides/transactions/claimable-balances.mdx +++ b/docs/build/guides/transactions/claimable-balances.mdx @@ -55,7 +55,7 @@ This operation claws back a claimable balance, returning the asset to the issuer Clawback claimable balances require the claimable balance ID. -Learn more about clawbacks in our [Clawback Guide](./clawbacks.mdx). +Learn more about clawbacks in our [Clawbacks guide](./clawbacks.mdx). ## Example diff --git a/docs/build/guides/transactions/create-account.mdx b/docs/build/guides/transactions/create-account.mdx index 69bbbff453..dae27e247f 100644 --- a/docs/build/guides/transactions/create-account.mdx +++ b/docs/build/guides/transactions/create-account.mdx @@ -20,7 +20,7 @@ Before creating an account, you need to generate your own keypair; we'll learn h A valid keypair alone does not make an account. To prevent unused entries from bloating the ledger, Stellar requires every account to hold a [minimum balance](../../../learn/fundamentals/lumens.mdx#minimum-balance) of two base reserves before it actually exists (at the current base reserve of 0.5 XLM that works out to 1 XLM, but validators can change the base reserve — see the linked section for the current value). This is the ordinary, self-funded path shown throughout this tutorial. -Alternatively, an account can be created with a `startingBalance` of `0` when another account sponsors its reserves ([CAP-33](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md) sponsored reserves): the sponsor carries the two base reserves on the new account's behalf, so the account exists without holding the minimum balance itself. See the [Sponsored Reserves guide](sponsored-reserves.mdx) for how to set this up. +Alternatively, an account can be created with a `startingBalance` of `0` when another account sponsors its reserves ([CAP-33](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0033.md) sponsored reserves): the sponsor carries the two base reserves on the new account's behalf, so the account exists without holding the minimum balance itself. Learn more in the [Sponsored Reserves guide](sponsored-reserves.mdx) for how to set this up. On the test network you can ask Friendbot — a friendly funding service — to create and fund the account for you. In the SDK examples, below, you'll see that we "discover" the Friendbot endpoint via the RPC's `getNetwork` call, then issue a funding request. diff --git a/docs/build/guides/transactions/fee-bump-transactions.mdx b/docs/build/guides/transactions/fee-bump-transactions.mdx index c891bfb81b..b0c8341c2e 100644 --- a/docs/build/guides/transactions/fee-bump-transactions.mdx +++ b/docs/build/guides/transactions/fee-bump-transactions.mdx @@ -41,7 +41,7 @@ The account that will pay the fee for the fee-bump transaction. This account wil The maximum per-operation fee you’re willing to pay for the fee-bump transaction. The fee-bump transaction is one operation. Therefore, the total number of operations is equal to the number of operations in the inner transaction plus one. -Read more about transaction fees in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx). +Learn more about transaction fees in our [Fees section](../../../learn/fundamentals/fees-resource-limits-metering.mdx). ### Replace-by-fee diff --git a/docs/build/guides/transactions/path-payments.mdx b/docs/build/guides/transactions/path-payments.mdx index 5983d2c63f..a300397636 100644 --- a/docs/build/guides/transactions/path-payments.mdx +++ b/docs/build/guides/transactions/path-payments.mdx @@ -12,7 +12,7 @@ Account A sells XLM → [buy XLM / sell ETH → buy ETH / sell BTC → buy BTC / It is possible for path payments to fail if there are no viable exchange paths. -For more information on the Stellar Decentralized Exchange and Liquidity Pools, see the [Liquidity on Stellar section](../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx). +Learn more about the Stellar Decentralized Exchange and Liquidity Pools in the [Liquidity on Stellar section](../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx). ## Operations diff --git a/docs/build/guides/transactions/send-and-receive-payments.mdx b/docs/build/guides/transactions/send-and-receive-payments.mdx index 0ca3c7945c..2c6ffb3fa7 100644 --- a/docs/build/guides/transactions/send-and-receive-payments.mdx +++ b/docs/build/guides/transactions/send-and-receive-payments.mdx @@ -21,7 +21,7 @@ The approach you should take depends on the use case: - If you want to make a payment of a Stellar asset between a Stellar account and a contract address, or between two contract addresses, then the asset's contract must be used. Stellar's payment-related operations cannot have contract addresses as their source or destination. - If you want to make a payment of a custom contract token which is not a Stellar asset but follows the [SEP-41 token standard](../../../tokens/stellar-asset-contract.mdx#overview), you must use the token's contract. Stellar's payment operations can only be used to transfer Stellar assets. -To learn more about the differences between Stellar assets and contract tokens, see the [Tokens](../../../tokens/README.mdx) overview. +Learn more about the differences between Stellar assets and contract tokens in the [Tokens](../../../tokens/README.mdx) overview. :::info diff --git a/docs/build/guides/transactions/signing-soroban-invocations.mdx b/docs/build/guides/transactions/signing-soroban-invocations.mdx index 498a8e2b58..2a280859ce 100644 --- a/docs/build/guides/transactions/signing-soroban-invocations.mdx +++ b/docs/build/guides/transactions/signing-soroban-invocations.mdx @@ -152,7 +152,7 @@ Running Enforcing Mode simulation provides two critical benefits: - **Validates signatures and execution** — Catches auth errors and contract failures before submission. Failed simulations cost nothing; failed submissions cost real fees. - **Returns accurate resource estimates** — Recording Mode underestimates fees because it skips auth validation. -See [Transaction Simulation - Authorization](../../../learn/fundamentals/contract-development/contract-interactions/transaction-simulation.mdx#authorization) for more details. +Learn more in [Transaction Simulation - Authorization](../../../learn/fundamentals/contract-development/contract-interactions/transaction-simulation.mdx#authorization). ::: diff --git a/docs/build/guides/transactions/sponsored-reserves.mdx b/docs/build/guides/transactions/sponsored-reserves.mdx index bf8f9e7089..a9d47250eb 100644 --- a/docs/build/guides/transactions/sponsored-reserves.mdx +++ b/docs/build/guides/transactions/sponsored-reserves.mdx @@ -73,7 +73,7 @@ To learn more about minimum balance requirements, see our section on [Lumens](.. All claimable balances are sponsored through built-in logic in the claimable balance operations. The account that creates the claimable balance pays the base reserve to get the claimable balance on the ledger. When the claimable balance is claimed by the claimant(s), the claimable balance is removed from the ledger, and the account that created it gets the base reserve back. -Read more about claimable balances in our [Claimable Balances guide](./claimable-balances.mdx). +Learn more about claimable balances in our [Claimable Balances guide](./claimable-balances.mdx). ## Examples diff --git a/docs/build/security-docs/securing-web-based-projects.mdx b/docs/build/security-docs/securing-web-based-projects.mdx index f03f9288d2..ec049830f8 100644 --- a/docs/build/security-docs/securing-web-based-projects.mdx +++ b/docs/build/security-docs/securing-web-based-projects.mdx @@ -15,7 +15,7 @@ If you don’t have SSL/TLS enabled, stop everything and do this first. CSP headers tell the browser where it can download static resources from. For example, if you astralwallet.io and it requests a JavaScript file from myevilsite.com, your browser will block it unless it was whitelisted with CSP headers. You can read about how to implement CSP headers [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP). -Most web frameworks have a configuration file or extensions to specify your CSP policy, and the headers are auto-generated for you. For example, see [Helmet](https://www.npmjs.com/package/helmet) for Node.js. This would have prevented the [Blackwallet Hack](https://www.ccn.com/yet-another-crypto-wallet-hack-causes-users-lose-400000). +Most web frameworks have a configuration file or extensions to specify your CSP policy, and the headers are auto-generated for you. Learn more about configuring CSP for Node.js in [Helmet](https://www.npmjs.com/package/helmet). This would have prevented the [Blackwallet Hack](https://www.ccn.com/yet-another-crypto-wallet-hack-causes-users-lose-400000). ## HTTP strict-transport-security headers diff --git a/docs/build/smart-contracts/example-contracts/alloc.mdx b/docs/build/smart-contracts/example-contracts/alloc.mdx index 6f5ca2af46..f1bd10e1ca 100644 --- a/docs/build/smart-contracts/example-contracts/alloc.mdx +++ b/docs/build/smart-contracts/example-contracts/alloc.mdx @@ -105,7 +105,7 @@ Ref: https://github.com/stellar/soroban-examples/tree/v23.0.0/alloc extern crate alloc; ``` -Imports the `alloc` crate, which is required in order to support allocation under `no_std`. See [Contract Rust dialect] for more info about `no_std`. +Imports the `alloc` crate, which is required in order to support allocation under `no_std`. Learn more about `no_std` in [Contract Rust dialect]. [contract rust dialect]: ../../../learn/fundamentals/contract-development/rust-dialect.mdx diff --git a/docs/build/smart-contracts/example-contracts/delegate-auth.mdx b/docs/build/smart-contracts/example-contracts/delegate-auth.mdx index 0a46108de3..9b0415f82a 100644 --- a/docs/build/smart-contracts/example-contracts/delegate-auth.mdx +++ b/docs/build/smart-contracts/example-contracts/delegate-auth.mdx @@ -20,7 +20,7 @@ sidebar_position: 18 This example shows **auth delegation**: a `ModularAccount` contract performs no signature verification itself. Instead, it stores a set of registered signer addresses and, when `__check_auth` is called, forwards the authorization context to whichever of those signers the user attached to the transaction. Each delegate runs its own `__check_auth` independently. -Auth delegation was introduced in soroban-sdk v27 via [CAP-71](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md). For a single-key account see the [Simple Account example](./simple-account.mdx), and for a multi-sig account with spend-limit policies see the [Complex Account example](./complex-account.mdx). +Auth delegation was introduced in soroban-sdk v27 via [CAP-71](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0071.md). For a single-key account learn more in the [Simple Account example](./simple-account.mdx), and for a multi-sig account with spend-limit policies learn more in the [Complex Account example](./complex-account.mdx). :::danger diff --git a/docs/build/smart-contracts/example-contracts/deployer.mdx b/docs/build/smart-contracts/example-contracts/deployer.mdx index 8945caa3eb..f2b0fdd6e3 100644 --- a/docs/build/smart-contracts/example-contracts/deployer.mdx +++ b/docs/build/smart-contracts/example-contracts/deployer.mdx @@ -125,13 +125,13 @@ Open the `deployer/deployer/src/lib.rs` file to follow along. Before deploying the new contract instances, the Wasm code needs to be uploaded on-chain. Then it can be used to deploy an arbitrary number of contract instances. The upload should typically happen outside of the deployer contract, as it needs to happen just once. However, it is possible to use `env.deployer().upload_contract_wasm()` function to upload Wasm from a contract as well. -See the [tests](#tests) for an example of uploading the contract code programmatically. For the actual on-chain installation see the general deployment [tutorial](../../smart-contracts/getting-started/deploy-to-testnet.mdx). +Learn more in the [tests](#tests) for an example of uploading the contract code programmatically. For the actual on-chain installation see the general deployment [tutorial](../../smart-contracts/getting-started/deploy-to-testnet.mdx). ### Authorization :::info -For introduction to Soroban authorization see the [auth tutorial](./auth.mdx). +For introduction to Soroban authorization learn more in the [auth tutorial](./auth.mdx). ::: diff --git a/docs/build/smart-contracts/example-contracts/fuzzing.mdx b/docs/build/smart-contracts/example-contracts/fuzzing.mdx index 1abf224df7..47c37236ae 100644 --- a/docs/build/smart-contracts/example-contracts/fuzzing.mdx +++ b/docs/build/smart-contracts/example-contracts/fuzzing.mdx @@ -597,7 +597,7 @@ All the options to libfuzzer can be listed with cargo +nightly fuzz run fuzz_target_1 -- -help=1 ``` -See the [`libfuzzer` documentation] for more. +Learn more in the [`libfuzzer` documentation]. [`libfuzzer` documentation]: https://llvm.org/docs/LibFuzzer.html#output diff --git a/docs/build/smart-contracts/example-contracts/logging.mdx b/docs/build/smart-contracts/example-contracts/logging.mdx index 101c779fe2..ec1218a7c0 100644 --- a/docs/build/smart-contracts/example-contracts/logging.mdx +++ b/docs/build/smart-contracts/example-contracts/logging.mdx @@ -32,13 +32,13 @@ Logs in contracts are only visible in tests, or when executing contracts using [ :::tip -Logs are not a substitute for step-through debugging. Rust tests for Soroban can be step-through debugged in your Rust-enabled IDE. See [testing] for more details. +Logs are not a substitute for step-through debugging. Rust tests for Soroban can be step-through debugged in your Rust-enabled IDE. Learn more in [testing]. ::: :::caution -Logs are not accessible by dapps and other applications. See the [events example] for how to produce structured events. +Logs are not accessible by dapps and other applications. Learn more in the [events example] for how to produce structured events. ::: diff --git a/docs/build/smart-contracts/example-contracts/tokens.mdx b/docs/build/smart-contracts/example-contracts/tokens.mdx index 44d6528105..d4fea7530f 100644 --- a/docs/build/smart-contracts/example-contracts/tokens.mdx +++ b/docs/build/smart-contracts/example-contracts/tokens.mdx @@ -40,7 +40,7 @@ This example shows how to build a token from scratch using only the `soroban-sdk :::info[Whisk Changes] -With the release of Whisk, Protocol 23, the [token interface] has seen some changes to incorporate the `MuxedAddress` type into the `transfer` function. Please see the [Rust SDK documentation](https://docs.rs/soroban-token-sdk/latest/soroban_token_sdk/_migrating/v23_token_transfer/index.html) for more details. +With the release of Whisk, Protocol 23, the [token interface] has seen some changes to incorporate the `MuxedAddress` type into the `transfer` function. Learn more at the [Rust SDK documentation](https://docs.rs/soroban-token-sdk/latest/soroban_token_sdk/_migrating/v23_token_transfer/index.html). ::: diff --git a/docs/build/smart-contracts/getting-started/deploy-increment-contract.mdx b/docs/build/smart-contracts/getting-started/deploy-increment-contract.mdx index be983fae9d..c939aeb88d 100644 --- a/docs/build/smart-contracts/getting-started/deploy-increment-contract.mdx +++ b/docs/build/smart-contracts/getting-started/deploy-increment-contract.mdx @@ -130,7 +130,7 @@ Sometimes you'll need to run your own node: - Production apps! Stellar maintains public test RPC nodes for Testnet and Futurenet, but not for Mainnet. Instead, you will need to run your own node, and point your app at that. If you want to use a software-as-a-service platform for this, [various providers](../../../data/apis/rpc/providers.mdx) are available. - When you need a network that differs from the version deployed to Testnet. -The RPC team maintains Docker containers that make this as straightforward as possible. See the [RPC](../../../data/apis/rpc/admin-guide/README.mdx) reference for details. +The RPC team maintains Docker containers that make this as straightforward as possible. Learn more in the [RPC](../../../data/apis/rpc/admin-guide/README.mdx) reference for details. ## Up next diff --git a/docs/build/smart-contracts/getting-started/hello-world-frontend.mdx b/docs/build/smart-contracts/getting-started/hello-world-frontend.mdx index 8dfdc9a636..7c839e57e9 100644 --- a/docs/build/smart-contracts/getting-started/hello-world-frontend.mdx +++ b/docs/build/smart-contracts/getting-started/hello-world-frontend.mdx @@ -12,7 +12,7 @@ In the previous examples, we invoked the contracts using the Stellar CLI, and in :::info -This example shows one way of creating a binding between a contract and a frontend. For a more comprehensive guide to Dapp frontends, see the [Build a Dapp Frontend](../../apps/dapp-frontend.mdx) documentation. For tooling that helps you start with smart contracts integrated with a working frontend environment quickly, jump to learn more about [Scaffold Stellar](#using-scaffold-stellar-to-rapidly-develop-dapps). +This example shows one way of creating a binding between a contract and a frontend. For a more comprehensive guide to Dapp frontends, learn more in the [Build a Dapp Frontend](../../apps/dapp-frontend.mdx) documentation. For tooling that helps you start with smart contracts integrated with a working frontend environment quickly, jump to learn more about [Scaffold Stellar](#using-scaffold-stellar-to-rapidly-develop-dapps). ::: diff --git a/docs/build/smart-contracts/getting-started/hello-world.mdx b/docs/build/smart-contracts/getting-started/hello-world.mdx index f184ca304a..f9c25f1150 100644 --- a/docs/build/smart-contracts/getting-started/hello-world.mdx +++ b/docs/build/smart-contracts/getting-started/hello-world.mdx @@ -89,7 +89,7 @@ inherits = "release" debug-assertions = true ``` -See the [logging example] for more information about how to log. +Learn more about how to log in the [logging example]. [logging example]: ../example-contracts/logging.mdx @@ -145,7 +145,7 @@ The contract imports the types and macros that it needs from the `soroban-sdk` c use soroban_sdk::{contract, contractimpl, vec, Env, String, Vec}; ``` -Many of the types available in typical Rust programs, such as `std::vec::Vec`, are not available, as there is no allocator and no heap memory in Soroban contracts by default (the SDK does provide an opt-in allocator through its `alloc` feature — see the [alloc example](../example-contracts/alloc.mdx)). The `soroban-sdk` provides a variety of types like `Vec`, `Map`, `Bytes`, `BytesN`, `Symbol`, that all utilize the Soroban environment's memory and native capabilities. Primitive values like `u128`, `i128`, `u64`, `i64`, `u32`, `i32`, and `bool` can also be used. Floats and floating point math are not supported. +Many of the types available in typical Rust programs, such as `std::vec::Vec`, are not available, as there is no allocator and no heap memory in Soroban contracts by default (the SDK does provide an opt-in allocator through its `alloc` feature — learn more in the [alloc example](../example-contracts/alloc.mdx)). The `soroban-sdk` provides a variety of types like `Vec`, `Map`, `Bytes`, `BytesN`, `Symbol`, that all utilize the Soroban environment's memory and native capabilities. Primitive values like `u128`, `i128`, `u64`, `i64`, `u32`, `i32`, and `bool` can also be used. Floats and floating point math are not supported. Contract inputs must not be references. diff --git a/docs/build/smart-contracts/getting-started/setup.mdx b/docs/build/smart-contracts/getting-started/setup.mdx index 23bd013384..45a0ad016d 100644 --- a/docs/build/smart-contracts/getting-started/setup.mdx +++ b/docs/build/smart-contracts/getting-started/setup.mdx @@ -44,7 +44,7 @@ On Windows, download and run [rustup-init.exe](https://static.rust-lang.org/rust :::tip -The Stellar CLI uses emojis in its output. To properly render them on Windows, it is recommended to use the [Windows Terminal](https://learn.microsoft.com/en-us/windows/terminal). See [how to install Windows Terminal](https://learn.microsoft.com/en-us/windows/terminal/install) on Microsoft Learn. If the CLI is used in the built in Windows Command Prompt or Windows PowerShell the CLI will function as expected but the emojis will appear as question marks. +The Stellar CLI uses emojis in its output. To properly render them on Windows, it is recommended to use the [Windows Terminal](https://learn.microsoft.com/en-us/windows/terminal). Learn more at [how to install Windows Terminal](https://learn.microsoft.com/en-us/windows/terminal/install) on Microsoft Learn. If the CLI is used in the built-in Windows Command Prompt or Windows PowerShell, it will function as expected but the emojis will appear as question marks. ::: diff --git a/docs/build/smart-contracts/overview.mdx b/docs/build/smart-contracts/overview.mdx index 09608f940e..0481ef5ec7 100644 --- a/docs/build/smart-contracts/overview.mdx +++ b/docs/build/smart-contracts/overview.mdx @@ -132,8 +132,8 @@ Learn more in the [Environment Concepts section](../../learn/fundamentals/contra To the greatest extent possible, we recommend issuing tokens as Stellar assets. These tokens will benefit from being interoperable with the existing tools available in the Stellar ecosystem and are more performant because the - Stellar Asset Contract is built into the host. Read more in the [Tokens - Overview](../../tokens/README.mdx). + Stellar Asset Contract is built into the host. Learn more in the [Stellar + Assets and Contract Tokens section](../../tokens/README.mdx). {/* prettier-ignore-end */} diff --git a/docs/data/analytics/analytics-providers/analytics-providers.mdx b/docs/data/analytics/analytics-providers/analytics-providers.mdx index 72c8772d62..024b063f13 100644 --- a/docs/data/analytics/analytics-providers/analytics-providers.mdx +++ b/docs/data/analytics/analytics-providers/analytics-providers.mdx @@ -7,7 +7,7 @@ The following is a list of data analytics platforms that make a complete histori | Platform | Description | Home page and Signup | Pricing | Data Access | Dashboard access | | --- | --- | --- | --- | --- | --- | -| Hubble | SDF provides a publicly available raw dataset with a complete historical record of Stellar network data, updated every 15 minutes. | [Hubble](https://console.cloud.google.com/bigquery?project=crypto-stellar&ws=!1m4!1m3!3m2!1scrypto-stellar!2scrypto_stellar)

[Signup](https://cloud.google.com/?hl=en) | End users incur the cost to execute queries. Visit the [BigQuery Pricing](https://cloud.google.com/bigquery/pricing#analysis_pricing_models) page to learn more. | Please see the [Analyst Guide](./hubble/analyst-guide) for more information. | N/A | +| Hubble | SDF provides a publicly available raw dataset with a complete historical record of Stellar network data, updated every 15 minutes. | [Hubble](https://console.cloud.google.com/bigquery?project=crypto-stellar&ws=!1m4!1m3!3m2!1scrypto-stellar!2scrypto_stellar)

[Signup](https://cloud.google.com/?hl=en) | End users incur the cost to execute queries. Visit the [BigQuery Pricing](https://cloud.google.com/bigquery/pricing#analysis_pricing_models) page to learn more. | Learn more in the [Analyst Guide](./hubble/analyst-guide). | N/A | | Dune | Raw dataset for the Stellar network available in the Dune portal. Updated every hour. You can compare different chains on the platform. | [Dune](https://dune.com)

[Signup](https://dune.com/auth/register) | Free for simpler queries. Need to pay for complex queries. | To access datasets, click [here](https://dune.com/queries?category=canonical&namespace=stellar). | Explore community dashboards, network overview, and datasets [here](https://dune.com/blockchains/stellar). | | Artemis | Aggregated dataset for the Stellar network available in BigQuery as well as the Artemis portal. Provides dashboards to compare Stellar chain activity with ecosystem chains. | [Artemis](https://www.artemis.xyz)

[Signup](https://app.artemisanalytics.com/artemis-terminal-auth?flow=SIGN_UP) | Free dashboards. Need to pay for accessing the raw dataset. | For accessing Artemis-transformed Stellar dataset, upgrade to the enterprise plan and then star [this dataset](https://console.cloud.google.com/bigquery?ws=!1m4!1m3!3m2!1sartemis-bigquery-share!2sshared_us). | Explore [chain compare](https://app.artemisanalytics.com/chains?selectedChains=stellar) and [application activity](https://app.artemis.xyz/application-activity/stellar) dashboards. | | Nansen | Aggregated dataset for the Stellar network available in the Nansen portal. Provides dashboards to compare Stellar chain activity with ecosystem chains. | [Nansen](https://app.nansen.ai)

[Signup](https://app.nansen.ai/auth/signup) | Free dashboards. Need to pay for accessing the raw dataset. | For accessing Nansen-transformed Stellar dataset, upgrade to the Pioneer plan and then star [this dataset](https://console.cloud.google.com/bigquery?project=nansen-query). | Explore [chain activity, entity, and ecosystem](https://app.nansen.ai/macro/blockchains?chain=stellar&tab=overview). | diff --git a/docs/data/analytics/hubble/analyst-guide/connecting.mdx b/docs/data/analytics/hubble/analyst-guide/connecting.mdx index a1e79f9f54..cc18fcae6c 100644 --- a/docs/data/analytics/hubble/analyst-guide/connecting.mdx +++ b/docs/data/analytics/hubble/analyst-guide/connecting.mdx @@ -119,7 +119,7 @@ for row in query_job: -There are various ways to extract and load data using BigQuery. See the [BigQuery Client Documentation](https://cloud.google.com/python/docs/reference/bigquery/latest/google.cloud.bigquery.client.Client) for more information. +There are various ways to extract and load data using BigQuery. Learn more at the [BigQuery Client Documentation](https://cloud.google.com/python/docs/reference/bigquery/latest/google.cloud.bigquery.client.Client). ## Looker Studio diff --git a/docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/history-operations.mdx b/docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/history-operations.mdx index 254d52a5b3..98203af7db 100644 --- a/docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/history-operations.mdx +++ b/docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/history-operations.mdx @@ -148,7 +148,7 @@ description: "" | batch_insert_ts | The timestamp in UTC when a batch of records was inserted into the database. This field can help identify if a batch executed in real time or as part of a backfill | timestamp | | Yes | | | closed_at | Timestamp in UTC when this ledger closed and committed to the network. Ledgers are expected to close ~every 5 seconds | timestamp | | Yes | We are aiming to repartition this table on closed_at | | operation_result_code | The result code returned when an operation is applied. This code is helpful for understanding failed operations | string | | Yes | Field will be backfilled at a future date | -| operation_trace_code | The trace code returned when an operation is applied to the Stellar Network. This code is helpful for understanding nuanced failures by operation type. This code provides the lowest level detail regarding why a transaction fails | string | | Yes | See the XDR [documentation](https://pkg.go.dev/github.com/stellar/go-stellar-sdk/xdr#OperationResultTr) for more details | +| operation_trace_code | The trace code returned when an operation is applied to the Stellar Network. This code is helpful for understanding nuanced failures by operation type. This code provides the lowest level detail regarding why a transaction fails | string | | Yes | Learn more in the [XDR documentation](https://pkg.go.dev/github.com/stellar/go-stellar-sdk/xdr#OperationResultTr) | | details_json | Record that contains details based on the type of operation executed. Each operation will return its own relevant details, with the rest of the details as null | json | | | | diff --git a/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/liquidity-pools-snapshot.mdx b/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/liquidity-pools-snapshot.mdx index 11244a6ad5..35042a725f 100644 --- a/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/liquidity-pools-snapshot.mdx +++ b/docs/data/analytics/hubble/data-catalog/data-dictionary/silver/liquidity-pools-snapshot.mdx @@ -20,7 +20,7 @@ description: "" | Name | Description | Data Type | Domain Values | Required? | Notes | | --- | --- | --- | --- | --- | --- | | liquidity_pool_id | Unique identifier for a liquidity pool. | STRING | | Yes | Natural Key. Cluster Field. Cannot be duplicated for same asset pair. | -| type | Mechanism that calculates pricing and division of shares for the pool. | STRING | constant_product | Yes | Initially only constant product pools are supported. See [Cap-38](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md). | +| type | Mechanism that calculates pricing and division of shares for the pool. | STRING | constant_product | Yes | Initially only constant product pools are supported. Learn more in [Cap-38](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md). | | fee | Basis points charged as trade fee. | INTEGER | Default = 30 | Yes | Fees are distributed immediately to accounts as transactions complete. | | trustline_count | Total number of accounts with trustlines authorized to the pool. | INTEGER | | Yes | Revoking authorization on an asset will withdraw accounts from all pools with that asset. | | pool_share_count | Total number of pool shares representing participation in the liquidity pool. | FLOAT | | Yes | Shares are not transferable. Can only be adjusted via deposit/withdraw. | diff --git a/docs/data/analytics/hubble/data-catalog/data-model-diagram.mdx b/docs/data/analytics/hubble/data-catalog/data-model-diagram.mdx index 1e50681c68..e33dc9926e 100644 --- a/docs/data/analytics/hubble/data-catalog/data-model-diagram.mdx +++ b/docs/data/analytics/hubble/data-catalog/data-model-diagram.mdx @@ -5,7 +5,7 @@ sidebar_position: 0 :::info -For more detailed information see the [Full Hubble Data Model Diagram](https://dbdiagram.io/d/Hubble-Public-Data-Model-66671e056bc9d447b1501801) or the [Compressed Hubble Data Model Diagram](https://dbdiagram.io/d/Hubble-Public-Data-Model-Compressed-666730996bc9d447b151a181). +For more detailed information learn more at the [Full Hubble Data Model Diagram](https://dbdiagram.io/d/Hubble-Public-Data-Model-66671e056bc9d447b1501801) or the [Compressed Hubble Data Model Diagram](https://dbdiagram.io/d/Hubble-Public-Data-Model-Compressed-666730996bc9d447b151a181). ::: diff --git a/docs/data/analytics/hubble/developer-guide/connecting-to-bigquery/README.mdx b/docs/data/analytics/hubble/developer-guide/connecting-to-bigquery/README.mdx index a1e79f9f54..cc18fcae6c 100644 --- a/docs/data/analytics/hubble/developer-guide/connecting-to-bigquery/README.mdx +++ b/docs/data/analytics/hubble/developer-guide/connecting-to-bigquery/README.mdx @@ -119,7 +119,7 @@ for row in query_job: -There are various ways to extract and load data using BigQuery. See the [BigQuery Client Documentation](https://cloud.google.com/python/docs/reference/bigquery/latest/google.cloud.bigquery.client.Client) for more information. +There are various ways to extract and load data using BigQuery. Learn more at the [BigQuery Client Documentation](https://cloud.google.com/python/docs/reference/bigquery/latest/google.cloud.bigquery.client.Client). ## Looker Studio diff --git a/docs/data/analytics/hubble/developer-guide/data-curation/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/data-curation/getting-started.mdx index d7d625ec9d..fd3b3e0907 100644 --- a/docs/data/analytics/hubble/developer-guide/data-curation/getting-started.mdx +++ b/docs/data/analytics/hubble/developer-guide/data-curation/getting-started.mdx @@ -125,4 +125,4 @@ dbt build dbt build --select ``` -Please see the [stellar-dbt-public/modles/marts](https://github.com/stellar/stellar-dbt-public/tree/master/models/marts) directory to see a full list of the available models that dbt can run +Learn more in the [stellar-dbt-public/modles/marts](https://github.com/stellar/stellar-dbt-public/tree/master/models/marts) directory to see a full list of the available models that dbt can run diff --git a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx index 5eb25a0678..b683204b72 100644 --- a/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx +++ b/docs/data/analytics/hubble/developer-guide/scheduling-and-orchestration/getting-started.mdx @@ -36,7 +36,7 @@ There are two things required for the configuration and setup of GCP Composer Ai - Upload DAGs to the Composer Airflow Bucket - Configure the Airflow variables for your GCP setup -For more detailed instructions please see the [stellar-etl-airflow Installation and Setup](https://github.com/stellar/stellar-etl-airflow?tab=readme-ov-file#installation-and-setup) documentation. +For more detailed instructions learn more in the [stellar-etl-airflow Installation and Setup](https://github.com/stellar/stellar-etl-airflow?tab=readme-ov-file#installation-and-setup) documentation. ### Uploading DAGs @@ -46,7 +46,7 @@ This can also be done using the [gcloud CLI or console](https://cloud.google.com ### Configuring Airflow Variables -Please see the [Airflow Variables Explanation](https://github.com/stellar/stellar-etl-airflow?tab=readme-ov-file#airflow-variables-explanation) documentation for more information about what should and needs to be configured. +Learn more about the required configuration at [Airflow Variables Explanation](https://github.com/stellar/stellar-etl-airflow?tab=readme-ov-file#airflow-variables-explanation). ## Running the DAGs diff --git a/docs/data/analytics/hubble/developer-guide/visualization/getting-started.mdx b/docs/data/analytics/hubble/developer-guide/visualization/getting-started.mdx index 8600d04958..139a8b4651 100644 --- a/docs/data/analytics/hubble/developer-guide/visualization/getting-started.mdx +++ b/docs/data/analytics/hubble/developer-guide/visualization/getting-started.mdx @@ -38,4 +38,4 @@ When you create a new report you should be able to now access data from `crypto- You have now created a new report with a pie chart. -Looker Studio has many resources to help visualize and explore data. Learn more [here](https://support.google.com/looker-studio?sjid=9035399711189270749-NA#topic=6267740) +Looker Studio has many resources to help visualize and explore data. Learn more in the [Looker Studio Help Center](https://support.google.com/looker-studio?sjid=9035399711189270749-NA#topic=6267740) diff --git a/docs/data/apis/horizon/api-reference/aggregations/paths/README.mdx b/docs/data/apis/horizon/api-reference/aggregations/paths/README.mdx index b7fe0ce321..217b2e6f6d 100644 --- a/docs/data/apis/horizon/api-reference/aggregations/paths/README.mdx +++ b/docs/data/apis/horizon/api-reference/aggregations/paths/README.mdx @@ -7,7 +7,7 @@ Paths provide information about potential path payments. A path can be used to p The [latest ledger](../../structure/consistency.mdx) known to Horizon is included as an HTTP header in the response. -Learn more about the two types of path payment: [`path payment strict send`](../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#path-payment-strict-send) and [`path payment strict receive`](../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#path-payment-strict-receive) +Learn more about the two types of path payment: [`path payment strict send`](../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#path-payment-strict-send) and [`path payment strict receive`](../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#path-payment-strict-receive). diff --git a/docs/data/apis/horizon/api-reference/errors/error-handling.mdx b/docs/data/apis/horizon/api-reference/errors/error-handling.mdx index 90a226f7d7..b246fd3f1c 100644 --- a/docs/data/apis/horizon/api-reference/errors/error-handling.mdx +++ b/docs/data/apis/horizon/api-reference/errors/error-handling.mdx @@ -200,15 +200,15 @@ Here, we will cover specific errors commonly encountered during transaction subm | Result | Code | Description | | --- | --- | --- | -| `FAILED` | -1 | One of the operations failed (see [List of Operations](../../../../../learn/fundamentals/transactions/list-of-operations.mdx) for errors) | +| `FAILED` | -1 | One of the operations failed (learn more about errors in the [List of Operations](../../../../../learn/fundamentals/transactions/list-of-operations.mdx)) | | `TOO_EARLY` | -2 | Ledger `closeTime` before `minTime` value in the transaction | | `TOO_LATE` | -3 | Ledger `closeTime` after `maxTime` value in the transaction | | `MISSING_OPERATION` | -4 | No operation was specified | | `BAD_SEQ` | -5 | Sequence number does not match source account | | `BAD_AUTH` | -6 | Too few valid signatures / wrong network | -| `INSUFFICIENT_BALANCE` | -7 | Fee would bring account below minimum balance; see our section on [Lumens](../../../../../learn/fundamentals/lumens.mdx#minimum-balance) for more info | +| `INSUFFICIENT_BALANCE` | -7 | Fee would bring account below minimum balance; learn more in our [Lumens section](../../../../../learn/fundamentals/lumens.mdx#minimum-balance) | | `NO_ACCOUNT` | -8 | Source account not found | -| `INSUFFICIENT_FEE` | -9 | Fee is too small; see our section on [Fees](../../../../../learn/fundamentals/fees-resource-limits-metering.mdx) for more info | +| `INSUFFICIENT_FEE` | -9 | Fee is too small; learn more in our [Fees section](../../../../../learn/fundamentals/fees-resource-limits-metering.mdx) | | `BAD_AUTH_EXTRA` | -10 | Unused signatures attached to transaction | | `INTERNAL_ERROR` | -11 | An unknown error occurred | | `NOT_SUPPORTED` | -12 | The transaction type is not supported | @@ -217,7 +217,7 @@ Here, we will cover specific errors commonly encountered during transaction subm ### Insufficient fees and surge pricing -See the [Fees section](../../../../../learn/fundamentals/fees-resource-limits-metering.mdx) +Learn more in the [Fees section](../../../../../learn/fundamentals/fees-resource-limits-metering.mdx) ### Rate limiting @@ -227,4 +227,4 @@ Horizon may rate limit requests and return `429 Too Many Requests` error when ex Any transaction that would reduce an account’s balance to less than the minimum will be rejected with an `INSUFFICIENT_BALANCE` error. Likewise, lumen selling liabilities that would reduce an account’s balance to less than the minimum plus lumen selling liabilities will be rejected with an `INSUFFICIENT_BALANCE` error. -For more on minimum balances, see our [Lumens section](../../../../../learn/fundamentals/lumens.mdx#minimum-balance). +Learn more about minimum balances in our [Lumens section](../../../../../learn/fundamentals/lumens.mdx#minimum-balance). diff --git a/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/change-trust.mdx b/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/change-trust.mdx index e95f5f05e8..9a880b3bd2 100644 --- a/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/change-trust.mdx +++ b/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/change-trust.mdx @@ -5,7 +5,7 @@ sidebar_position: 90 These are result codes that communicate success (200) or failure (400) specific to the `Change Trust` operation. -Learn more about the [`Change Trust` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#change-trust) +Learn more about the [`Change Trust` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#change-trust). diff --git a/docs/data/apis/horizon/api-reference/resources/ledgers/object.mdx b/docs/data/apis/horizon/api-reference/resources/ledgers/object.mdx index f12c00717c..32a149a5cd 100644 --- a/docs/data/apis/horizon/api-reference/resources/ledgers/object.mdx +++ b/docs/data/apis/horizon/api-reference/resources/ledgers/object.mdx @@ -54,7 +54,7 @@ When Horizon returns information about a ledger, it uses the following format: - The reserve the network uses when calculating an account’s minimum balance. - max_tx_set_size - number - - The maximum number of operations validators have agreed to process in a given ledger. Since Protocol 11, ledger capacity has been measured in operations rather than transactions. For more info on that decision, see [CAP-5](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md#repurposing-ledgerheadermaxtxsetsize). + - The maximum number of operations validators have agreed to process in a given ledger. Since Protocol 11, ledger capacity has been measured in operations rather than transactions. For more info on that decision, learn more in [CAP-5](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0005.md#repurposing-ledgerheadermaxtxsetsize). - protocol_version - number - The protocol version that the Stellar network was running when this ledger was committed. diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/README.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/README.mdx index ecb440f360..383010107f 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/README.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/README.mdx @@ -5,7 +5,7 @@ order: 0 Each of Stellar’s operations have unique response shapes. Below are the attributes that are common across individual operation objects. -See the [generic Operation errors](../../../errors/result-codes/operations.mdx). +Learn more in the [generic Operation errors](../../../errors/result-codes/operations.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/account-merge.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/account-merge.mdx index cae8a28800..d0cea55309 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/account-merge.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/account-merge.mdx @@ -5,7 +5,7 @@ order: 110 Removes the source account from the Stellar and transfers the source account's lumens to another account. -See the [`Account Merge` errors](../../../errors/result-codes/operation-specific/account-merge.mdx). +Learn more in the [`Account Merge` errors](../../../errors/result-codes/operation-specific/account-merge.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/allow-trust.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/allow-trust.mdx index 3f0cdf2a94..ae5297bbb3 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/allow-trust.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/allow-trust.mdx @@ -5,7 +5,7 @@ order: 100 Updates the “authorized” flag of an existing trust line. This must be called by the issuer of the asset. -See the [`Allow Trust` errors](../../../errors/result-codes/operation-specific/allow-trust.mdx). +Learn more in the [`Allow Trust` errors](../../../errors/result-codes/operation-specific/allow-trust.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/bump-sequence.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/bump-sequence.mdx index 496e2f269c..84c9163083 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/bump-sequence.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/bump-sequence.mdx @@ -5,7 +5,7 @@ order: 130 Bumps forward the sequence number of the source account, allowing it to invalidate any transactions with a smaller sequence number. -See the [`Bump Sequence` errors](../../../errors/result-codes/operation-specific/bump-sequence.mdx). +Learn more in the [`Bump Sequence` errors](../../../errors/result-codes/operation-specific/bump-sequence.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/buy-offer.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/buy-offer.mdx index f38a78cd29..3adcebd32d 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/buy-offer.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/buy-offer.mdx @@ -5,7 +5,7 @@ order: 60 Creates, updates, or deletes a buy offer to trade assets. A buy offer specifies a certain amount of the buying asset that should be sold in exchange for the minimum quantity of the selling asset. -See the [`Manage Buy Offer` errors](../../../errors/result-codes/operation-specific/manage-buy-offer.mdx). +Learn more in the [`Manage Buy Offer` errors](../../../errors/result-codes/operation-specific/manage-buy-offer.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/change-trust.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/change-trust.mdx index 1832a97cf9..e8f2ab7b4c 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/change-trust.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/change-trust.mdx @@ -5,7 +5,7 @@ order: 90 Creates, updates, or deletes a trust line from the source account to another account's issued asset. -See the [`Change Trust` errors](../../../errors/result-codes/operation-specific/change-trust.mdx). +Learn more in the [`Change Trust` errors](../../../errors/result-codes/operation-specific/change-trust.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/create-account.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/create-account.mdx index 4ca9eb52cf..21f38a1a44 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/create-account.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/create-account.mdx @@ -5,7 +5,7 @@ order: 10 Creates and funds a new account with the specified starting balance. -See the [`Create Account` errors](../../../errors/result-codes/operation-specific/create-account.mdx). +Learn more in the [`Create Account` errors](../../../errors/result-codes/operation-specific/create-account.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-deposit.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-deposit.mdx index 586f11455a..b574918a2d 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-deposit.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-deposit.mdx @@ -5,7 +5,7 @@ order: 200 Deposit asset reserves into a liquidity pool. -See the [`Liquidity Pool Deposit` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#liquidity-pool-deposit) for parameters, errors, etc. +Learn more in the [`Liquidity Pool Deposit` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#liquidity-pool-deposit) for parameters, errors, etc. diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-withdraw.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-withdraw.mdx index e6a637988a..783e8bc611 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-withdraw.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/liquidity-pool-withdraw.mdx @@ -5,7 +5,7 @@ order: 210 Withdraws asset reserves from a liquidity pool by redeeming pool shares. -See the [`Liquidity Pool Withdraw` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#liquidity-pool-withdraw) for parameters, errors, etc. +Learn more in the [`Liquidity Pool Withdraw` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#liquidity-pool-withdraw) for parameters, errors, etc. diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx index 2425fea1a0..6cd1226ab8 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx @@ -5,7 +5,7 @@ order: 120 Set, modify, or delete a data entry (name/value pair) for an account. -See the [`Manage Data` errors](../../../errors/result-codes/operation-specific/manage-data.mdx). +Learn more in the [`Manage Data` errors](../../../errors/result-codes/operation-specific/manage-data.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/passive-sell-offer.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/passive-sell-offer.mdx index 28c46509a9..c346b0bd11 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/passive-sell-offer.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/passive-sell-offer.mdx @@ -5,7 +5,7 @@ order: 70 Creates an offer that will not consume a counter offer that exactly matches this offer. This is useful for offers meant to be 1:1 exchanges for path payments. Use Manage Sell Offer to manage this offer after using this operation to create it. -See the [`Create Passive Sell Offer` errors](../../../errors/result-codes/operation-specific/create-passive-sell-offer.mdx). +Learn more in the [`Create Passive Sell Offer` errors](../../../errors/result-codes/operation-specific/create-passive-sell-offer.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-receive.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-receive.mdx index fc37474eee..2d91acd922 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-receive.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-receive.mdx @@ -5,7 +5,7 @@ order: 30 Sends a payment from one account to another in a path through the order books, starting as one asset and ending as another. Path payments that are `Strict Receive` designate the payment amount in the asset received. -See the [`Path Payment Strict Receive` errors](../../../errors/result-codes/operation-specific/path-payment-strict-receive.mdx). +Learn more in the [`Path Payment Strict Receive` errors](../../../errors/result-codes/operation-specific/path-payment-strict-receive.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-send.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-send.mdx index a6d94dbac8..8effb052e2 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-send.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/path-payment-strict-send.mdx @@ -5,7 +5,7 @@ order: 40 Sends a payment from one account to another in a path through the order books, starting as one asset and ending as another. Path payments that are `Strict Send` designate the payment amount in the asset sent. -See the [`Path Payment Strict Send` errors](../../../errors/result-codes/operation-specific/path-payment-strict-send.mdx). +Learn more in the [`Path Payment Strict Send` errors](../../../errors/result-codes/operation-specific/path-payment-strict-send.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/sell-offer.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/sell-offer.mdx index dae575f37c..97f0663cfc 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/sell-offer.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/sell-offer.mdx @@ -5,7 +5,7 @@ order: 50 Creates, updates, or deletes a sell offer to trade assets. A sell offer specifies a certain amount of the selling asset that should be sold in exchange for the maximum quantity of the buying asset. -See the [`Manage Sell Offer` errors](../../../errors/result-codes/operation-specific/manage-sell-offer.mdx). +Learn more in the [`Manage Sell Offer` errors](../../../errors/result-codes/operation-specific/manage-sell-offer.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/operations/object/set-options.mdx b/docs/data/apis/horizon/api-reference/resources/operations/object/set-options.mdx index 27bc4c1350..e23234b43e 100644 --- a/docs/data/apis/horizon/api-reference/resources/operations/object/set-options.mdx +++ b/docs/data/apis/horizon/api-reference/resources/operations/object/set-options.mdx @@ -5,7 +5,7 @@ order: 80 Sets an account's flags, inflation destination, signers, and home domain. -See the [`Set Options` errors](../../../errors/result-codes/operation-specific/set-options.mdx). +Learn more in the [`Set Options` errors](../../../errors/result-codes/operation-specific/set-options.mdx). diff --git a/docs/data/apis/horizon/api-reference/resources/payments/object.mdx b/docs/data/apis/horizon/api-reference/resources/payments/object.mdx index 8d4ae6cb4a..8dda21de56 100644 --- a/docs/data/apis/horizon/api-reference/resources/payments/object.mdx +++ b/docs/data/apis/horizon/api-reference/resources/payments/object.mdx @@ -5,7 +5,7 @@ order: 20 Sends an amount in a specific asset to a destination account. -See the [`Payment` errors](../../errors/result-codes/operation-specific/payment.mdx). +Learn more in the [`Payment` errors](../../errors/result-codes/operation-specific/payment.mdx). diff --git a/docs/data/apis/migrate-from-horizon-to-rpc.mdx b/docs/data/apis/migrate-from-horizon-to-rpc.mdx index 8725ba9ed1..bee7e44f29 100644 --- a/docs/data/apis/migrate-from-horizon-to-rpc.mdx +++ b/docs/data/apis/migrate-from-horizon-to-rpc.mdx @@ -8,9 +8,9 @@ Applications using [Horizon's REST-like API] will need to be updated to use the ## Request / Response Format -Horizon's REST-like API uses HTTP methods and status codes to communicate with clients. Responses are JSON in the HAL format. See [Horizon's Response Format]. +Horizon's REST-like API uses HTTP methods and status codes to communicate with clients. Responses are JSON in the HAL format. Learn more in [Horizon's Response Format]. -RPC's JSON-RPC API uses JSON-RPC 2.0 to communicate with clients. Requests to the API are JSON objects that contain one or more method invocations. Responses are also JSON objects that contain a result for each invocation in the request. See [JSON-RPC]. +RPC's JSON-RPC API uses JSON-RPC 2.0 to communicate with clients. Requests to the API are JSON objects that contain one or more method invocations. Responses are also JSON objects that contain a result for each invocation in the request. Learn more in [JSON-RPC]. Both formats utilise JSON for the overall structure which are relatively simple and do not require any special client code, although there are client [SDKs] available. Some values contained within are XDR encoded and can be decoded using Stellar [SDKs]. diff --git a/docs/data/apis/rpc/admin-guide/development.mdx b/docs/data/apis/rpc/admin-guide/development.mdx index 2bb1d7ad5f..b7b8aa86f9 100644 --- a/docs/data/apis/rpc/admin-guide/development.mdx +++ b/docs/data/apis/rpc/admin-guide/development.mdx @@ -7,7 +7,7 @@ For local development, we recommend [downloading](https://hub.docker.com/r/stell :::caution -We don't recommend running the Quickstart image in production. See the [deploy your own RPC instance](./installing.mdx) section. +We don't recommend running the Quickstart image in production. Learn more in the [deploy your own RPC instance](./installing.mdx) section. ::: @@ -77,6 +77,6 @@ stellar contract invoke \ --to friend ``` -When you're done with your local node, you can close it with ctrlc (not cmd). This will fully remove the container (that's what the `--rm` option to the `docker` command does), which means you will need to re-deploy your contract and re-fund your identity the next time you start it. If you work with local nodes often, you may want to create scripts to make these initialization steps easier. For example, see the [example dapp's `initialize.sh`](https://github.com/stellar/soroban-example-dapp/blob/abdac3afdb6c410cc426831ece93371c1a27347d/initialize.sh). +When you're done with your local node, you can close it with ctrlc (not cmd). This will fully remove the container (that's what the `--rm` option to the `docker` command does), which means you will need to re-deploy your contract and re-fund your identity the next time you start it. If you work with local nodes often, you may want to create scripts to make these initialization steps easier. Learn more in the [example dapp's `initialize.sh`](https://github.com/stellar/soroban-example-dapp/blob/abdac3afdb6c410cc426831ece93371c1a27347d/initialize.sh). [Testnet]: ../../../../networks/README.mdx diff --git a/docs/data/apis/rpc/api-reference/methods/README.mdx b/docs/data/apis/rpc/api-reference/methods/README.mdx index 3d8a016cad..768fb20980 100644 --- a/docs/data/apis/rpc/api-reference/methods/README.mdx +++ b/docs/data/apis/rpc/api-reference/methods/README.mdx @@ -12,14 +12,14 @@ All you need to know about available RPC methods, parameters and responses, and Don't know which endpoint you need to get what you want? A lot of the returned fields are deeply-nested [XDR structures](../../../../../learn/fundamentals/data-format/xdr.mdx#more-about-xdr), so it can be hard to figure out what kind of information is available in each of these. Here's a bit of a dive into what the "workhorse" endpoints provide, in decreasing order of granularity: - [`getLedgers`](./getLedgers.mdx) operates at the block level, providing you with the full, complete details of what occurred during application of that ledger (known as "ledger metadata", defined in the protocol by the [`LedgerCloseMeta`](https://github.com/stellar/stellar-xdr/blob/v22.0/Stellar-ledger.x#L539) union, specifically the `V1` iteration). Each of the subsequent endpoints is just a microscope into a subset of the data available provided by this endpoint. Metadata includes things like: - - Details for recreating the blockchain's state (see [Ledger Headers](../../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx#ledger-headers) for more). - - The consensus information that led to the block closing (see [Stellar Consensus Protocol](../../../../../learn/fundamentals/stellar-consensus-protocol.mdx)). - - The set of transactions, their respective operations, and the results of applying those transactions in this block (see [Transactions](../../../../../learn/fundamentals/transactions/operations-and-transactions.mdx)). + - Details for recreating the blockchain's state (learn more in the [Ledger Headers section](../../../../../learn/fundamentals/stellar-data-structures/ledgers.mdx#ledger-headers)). + - The consensus information that led to the block closing (learn more in the [Stellar Consensus Protocol section](../../../../../learn/fundamentals/stellar-consensus-protocol.mdx)). + - The set of transactions, their respective operations, and the results of applying those transactions in this block (learn more in the [Transactions section](../../../../../learn/fundamentals/transactions/operations-and-transactions.mdx)). - [`getTransaction(s)`](./getTransactions.mdx) operates across a span of ledgers or on a single transaction hash depending on the variant. The structured data here includes details such as: - The exact transaction structure ("envelope") that was submitted. - Results for each of the operations within the transaction. - All side-effects to ledger state that occurred as a result of this transaction. -- [`getEvents`](./getEvents.mdx) lets you search for events that occurred over a ledger range. Events are emitted by the system and by smart contracts to communicate meaningful state changes to off chain indexers (see [Events](../../../../../learn/fundamentals/stellar-data-structures/events.mdx) for more). Each event is made up of topics (which you can filter on) and data which are `ScVal`s, Stellar's generic "value" type (see [Contract Development](../../../../../learn/fundamentals/contract-development/types/built-in-types.mdx) for more). -- [`getLedgerEntries`](./getLedgerEntries.mdx), in contrast to the above endpoints, provides information about **live** on-chain state rather than historical actions. The [getLedgerEntries](./getLedgerEntries.mdx) page itself goes into detail on the different kinds of state stored on chain and how to fetch them. +- [`getEvents`](./getEvents.mdx) lets you search for events that occurred over a ledger range. Events are emitted by the system and by smart contracts to communicate meaningful state changes to off-chain indexers (learn more in the [Events section](../../../../../learn/fundamentals/stellar-data-structures/events.mdx)). Each event is made up of topics (which you can filter on) and data which are `ScVal`s, Stellar's generic "value" type (learn more in the [Contract Development section](../../../../../learn/fundamentals/contract-development/types/built-in-types.mdx)). +- [`getLedgerEntries`](./getLedgerEntries.mdx), in contrast to the above endpoints, provides information about **live** on-chain state rather than historical actions. The [getLedgerEntries](./getLedgerEntries.mdx) page itself goes into detail on the different kinds of state stored on-chain and how to fetch them. If you still aren't sure what you're looking for, remember that you can pass `xdrFormat: "json"` as a parameter to each of these endpoints to get a fully unpacked, human-readable JSON version of the XDR structures returned. You can look through these until you find what you need and go back to the Base64+unpack variation in your app. Equipped with an understanding of how to traverse XDR, the structure of the protocol, and your [favorite SDK](../../../../../tools/sdks/README.mdx), you should be able to find anything you want about the Stellar network with these endpoints. diff --git a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx index 58018d4324..61c93ac79a 100644 --- a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx +++ b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx @@ -20,12 +20,12 @@ The `getLedgerEntries` method returns the "values" (or "entries") for a given se The source of truth should always be the XDR defined in the protocol. `LedgerKey`s are a union type defined in [Stellar-ledger-entries.x](https://github.com/stellar/stellar-xdr/blob/v25.0/Stellar-ledger-entries.x#L588). There are 10 different forms a ledger key can take: -1. **Account:** holistically defines a Stellar account, including its balance, signers, etc. (see [Accounts](../../../../../learn/fundamentals/stellar-data-structures/accounts.mdx)) -2. **Trustline:** defines a balance line to a non-native asset issued on the network (see [`changeTrustOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#change-trust)) -3. **Offer:** defines an offer made on the Stellar DEX (see [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx)) -4. **Account Data:** defines key-value data entries attached to an account (see [`manageDataOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data)) -5. **Claimable Balance:** defines a balance that may or may not actively be claimable (see [Claimable Balances](../../../../../build/guides/transactions/claimable-balances.mdx)) -6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (see [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx)) +1. **Account:** holistically defines a Stellar account, including its balance, signers, etc. (learn more in [Accounts](../../../../../learn/fundamentals/stellar-data-structures/accounts.mdx)) +2. **Trustline:** defines a balance line to a non-native asset issued on the network (learn more in [`changeTrustOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#change-trust)) +3. **Offer:** defines an offer made on the Stellar DEX (learn more in [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx)) +4. **Account Data:** defines key-value data entries attached to an account (learn more in [`manageDataOp`](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data)) +5. **Claimable Balance:** defines a balance that may or may not actively be claimable (learn more in [Claimable Balances](../../../../../build/guides/transactions/claimable-balances.mdx)) +6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (learn more in [Liquidity on Stellar](../../../../../learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx)) 7. **Contract Data:** defines a piece of data being stored in a contract under a key 8. **Contract Code:** defines the Wasm bytecode of a contract 9. **Config Setting:** defines the currently active network configuration @@ -305,7 +305,7 @@ print(get_ledger_key_contract_code( -Once we have the ledger entry (via `getLedgerEntries`, see [below](#actually-fetching-the-ledger-entry-data)), we can extract the Wasm hash: +Once we have the ledger entry (via `getLedgerEntries`; learn more in [Actually fetching the ledger entry data](#actually-fetching-the-ledger-entry-data)), we can extract the Wasm hash: #### 2. Request the `ContractCode` using the retrieved `LedgerKey` diff --git a/docs/data/indexers/README.mdx b/docs/data/indexers/README.mdx index 28b10b7923..14d3eb6e35 100644 --- a/docs/data/indexers/README.mdx +++ b/docs/data/indexers/README.mdx @@ -52,7 +52,7 @@ Well-known options: - [Goldsky]: one of the currently-most-loved options on Ethereum for this use-case. Goldsky provides [two main products](https://docs.goldsky.com/subgraph-vs-mirror): 1. **Subgraphs**: similar to those offered by The Graph, but data lives on Goldsky's own infrastructure rather than a decentralized network. Goldsky only offers this for EVM-based chains, with no plans to offer Subgraph support for Stellar. - 2. **Mirror**, also called **Pipelines**: a highly efficient tool to Extract, Transform, & Load (ETL) data into your own database. Goldsky Mirrors already support Stellar; see [their documentation](https://docs.goldsky.com/chains/stellar). + 2. **Mirror**, also called **Pipelines**: a highly efficient tool to Extract, Transform, & Load (ETL) data into your own database. Goldsky Mirrors already support Stellar; learn more at [their documentation](https://docs.goldsky.com/chains/stellar). - [Mercury]: a home-grown Stellar-native team providing streamlined Soroban (Smart Contract) support via their [Retroshades](https://docs.mercurydata.app/retroshades/introduction-to-retroshades) product. Note that this streamlined Soroban support comes at the cost of _only_ supporting Soroban! Mercury also provide [Mercury "Classic"](https://docs.mercurydata.app/mercury-classic/introduction), giving access to contract events & Stellar transactions via a GraphQL interface, which might fit Indexer Use Case #1 more. @@ -72,7 +72,7 @@ For business intelligence, compliance, tracing suspicious operations, DeFi metri The companies building tools for Indexer Use Case #2 above (The Graph, Goldsky, Allium, etc) tend to also have tools for Use Case #3. -While often referred to as _indexing_, you can also think of this category as _analytics_. See the [analytics documentation](../analytics/README.mdx) for solutions custom-tailored to this use-case. +While often referred to as _indexing_, you can also think of this category as _analytics_. Learn more in the [analytics documentation](../analytics/README.mdx) for solutions custom-tailored to this use-case. ## Build Your Own diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/configuring.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/configuring.mdx index 40b5e679a0..5755c3e821 100644 --- a/docs/data/indexers/build-your-own/galexie/admin_guide/configuring.mdx +++ b/docs/data/indexers/build-your-own/galexie/admin_guide/configuring.mdx @@ -49,13 +49,13 @@ files_per_partition = 64000 You can specify a custom `core.cfg` file in the Galexie `config.toml` to use that will override the default core parameters used with the Stellar Network specified in the `network` parameter. -Copy an existing `core.cfg` file such as the `captive-core-pubnet.cfg` provided [here](https://github.com/stellar/go-stellar-sdk/blob/main/ingest/ledgerbackend/configs/captive-core-pubnet.cfg) and add the following to your `config.toml` +Copy an existing `core.cfg` file (such as the `captive-core-pubnet.cfg` provided [here](https://github.com/stellar/go-stellar-sdk/blob/main/ingest/ledgerbackend/configs/captive-core-pubnet.cfg)) and add the following to your `config.toml` ```toml captive_core_toml_path = "my-captive-core.cfg" ``` -- Please see the [Choosing Your Quorum Set](../../../../../validators/admin-guide/configuring.mdx#choosing-your-quorum-set) for more information about `core.cfg` quorum set configuration +- Learn more about `core.cfg` quorum-set configuration in the [Choosing Your Quorum Set section](../../../../../validators/admin-guide/configuring.mdx#choosing-your-quorum-set). - A list of customizable core parameters can be found [here](https://github.com/stellar/stellar-core/blob/master/src/main/Config.h) The default `core.cfg` used by Galexie will enable the following core parameters: diff --git a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx index 543e3fc9ed..e51b39542b 100644 --- a/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx +++ b/docs/data/indexers/build-your-own/galexie/admin_guide/prerequisites.mdx @@ -45,4 +45,4 @@ The minimum hardware requirements for running Galexie are:\ ### Full History Export -Please see the [Full History Exporting](./full-history-exporting.mdx) guide for more information. +Learn more in the [Full History Exporting guide](./full-history-exporting.mdx). diff --git a/docs/data/indexers/build-your-own/processors/README.mdx b/docs/data/indexers/build-your-own/processors/README.mdx index 1f6ef8fc8e..25163339b3 100644 --- a/docs/data/indexers/build-your-own/processors/README.mdx +++ b/docs/data/indexers/build-your-own/processors/README.mdx @@ -3,7 +3,7 @@ title: Processors sidebar_position: 0 --- -Learn more about the processors library in the [Stellar Go SDK](https://github.com/stellar/go) +Learn more about the processors library in the [Stellar Go SDK](https://github.com/stellar/go). ## [Token Transfer Processor](./token-transfer-processor/README.mdx) diff --git a/docs/data/indexers/build-your-own/processors/token-transfer-processor/README.mdx b/docs/data/indexers/build-your-own/processors/token-transfer-processor/README.mdx index ad075bb1c4..e2998aab36 100644 --- a/docs/data/indexers/build-your-own/processors/token-transfer-processor/README.mdx +++ b/docs/data/indexers/build-your-own/processors/token-transfer-processor/README.mdx @@ -14,7 +14,7 @@ TTP serves as a facade to CAP-67, automatically generating these standardized ev - **Standalone mode**: TTP analyzes operations, operation results, and ledger entry changes to derive transfer events - **Unified events mode**: TTP reads directly from CAP-67 compliant unified events when available in the ledger data -For more details on operational modes, see the [Modes of Operation](#modes-of-operation) section. +Learn more about operational modes in the [Modes of Operation](#modes-of-operation) section. ## Key Features @@ -117,7 +117,7 @@ func (p *EventsProcessor) EventsFromLedger(lcm xdr.LedgerCloseMeta) ([]*TokenTra This function processes an entire ledger and returns a flattened list of `TokenTransferEvent` objects. The order of events in the returned slice represents the chronological ordering of debits, credits, and fees as they were applied to accounts, trustlines, and contracts during ledger processing. -The chronological ordering is critical for applications that need to maintain accurate balance tracking or audit trails. For detailed information about how events are ordered, see the [Event Ordering](#event-ordering) section. +The chronological ordering is critical for applications that need to maintain accurate balance tracking or audit trails. For detailed information about how events are ordered, learn more in the [Event Ordering](#event-ordering) section. ### EventsFromTransaction diff --git a/docs/data/oracles/oracle-providers.mdx b/docs/data/oracles/oracle-providers.mdx index 17feb0cbf9..b6a567076a 100644 --- a/docs/data/oracles/oracle-providers.mdx +++ b/docs/data/oracles/oracle-providers.mdx @@ -50,7 +50,7 @@ The network is designed to modularize and offload the task of constatly monitori | [`CCQXWMZVM3KRTXTUPTN53YHL272QGKF32L7XEDNZ2S6OSUFK3NFBGG5M`](https://stellar.expert/explorer/public/contract/CCQXWMZVM3KRTXTUPTN53YHL272QGKF32L7XEDNZ2S6OSUFK3NFBGG5M) | Mainnet | | [`CBRV5ZEQSSCQ4FFO64OF46I3UASBVEJNE5C2MCFWVIXL4Z7DMD7PJJMF`](https://stellar.expert/explorer/testnet/contract/CBRV5ZEQSSCQ4FFO64OF46I3UASBVEJNE5C2MCFWVIXL4Z7DMD7PJJMF) | Testnet | -To learn more about this oracle, please see their [docs](https://docs.bandchain.org) or visit their [GitHub](https://github.com/bandprotocol/band-std-reference-contracts-soroban). +Learn more at the [Band Protocol documentation](https://docs.bandchain.org) or visit [their GitHub repository](https://github.com/bandprotocol/band-std-reference-contracts-soroban). ## [DIA Oracles](https://www.diadata.org) diff --git a/docs/learn/fundamentals/anchors.mdx b/docs/learn/fundamentals/anchors.mdx index 9a4a3ea438..18d3ea4ee4 100644 --- a/docs/learn/fundamentals/anchors.mdx +++ b/docs/learn/fundamentals/anchors.mdx @@ -23,7 +23,7 @@ Learn how to integrate anchor services into your blockchain-based application by Stellar is an open-source network that is designed to interoperate with traditional financial institutions, various types of assets, and other networks. Network participants implement Stellar Ecosystem Proposals (SEPs) to ensure they can interoperate with other products and services on the network. SEPs are publicly created, open-source documents that live in a [GitHub repository](https://github.com/stellar/stellar-protocol/tree/master/ecosystem#stellar-ecosystem-proposals-seps.mdx) and they define how anchors, asset issuers, applications, exchanges, and other service providers should interact and interoperate. -Read more about SEPs in the [SEPs section](../fundamentals/stellar-ecosystem-proposals.mdx). +Learn more about SEPs in the [SEPs section](../fundamentals/stellar-ecosystem-proposals.mdx). For anchors, the most important SEPs are [SEP-6]: Programmatic Deposit and Withdrawal, [SEP-24]: Hosted Deposit and Withdrawal, and [SEP-31]: Cross Border Payments API. You’ll also work with [SEP-10]: Stellar Authentication, [SEP-12]: KYC API, and [SEP-38]: Anchor RFQ API. diff --git a/docs/learn/fundamentals/contract-development/authorization.mdx b/docs/learn/fundamentals/contract-development/authorization.mdx index abe178d21b..c1a0ed3e9c 100644 --- a/docs/learn/fundamentals/contract-development/authorization.mdx +++ b/docs/learn/fundamentals/contract-development/authorization.mdx @@ -35,9 +35,9 @@ Contracts have an exclusive read and write access to their [storage](../../../bu The storage-based approach described in the previous section requires a way to represent the user identities and authenticate them. `Address` type is a host-managed type that performs these functions. -From the contract perspective `Address` is an opaque identifier type. The contract logic doesn't need to depend on the internal representation of the `Address` (see [Account Abstraction](#account-abstraction) section below for more details). +From the contract perspective `Address` is an opaque identifier type. The contract logic doesn't need to depend on the internal representation of the `Address`. Learn more in the [Account Abstraction section](#account-abstraction) below. -`Address` type has two similar methods in Soroban SDK: `require_auth` and `require_auth_for_args` (these methods call the respective Soroban host function). The only difference between the functions is the ability to customize the invocation arguments. See [auth example] that demonstrates how to use these functions. +`Address` type has two similar methods in Soroban SDK: `require_auth` and `require_auth_for_args` (these methods call the respective Soroban host function). The only difference between the functions is the ability to customize the invocation arguments. Learn more in [auth example] that demonstrates how to use these functions. Both functions ensure that the `Address` has authorized the call of the current function within the current context (where context is defined by `require_auth` calls in the current call stack; see more formal definition in the [section below](#require_auth-implementation-details)). The authentication rules for this authorization are defined by the `Address` and are enforced by the Soroban host. Replay protection is also implemented in the host, i.e., there is normally no need for a contract to manage its own nonces. @@ -45,7 +45,7 @@ Both functions ensure that the `Address` has authorized the call of the current #### Authorizing Sub-contract Calls -One of the key features of Soroban Authorization Framework is the ability to easily make authorized sub-contract calls. For example, it is possible for a contract to call `require_auth` for an `Address` and then call `token.xfer` authorized for the same `Address` (see [timelock example] that demonstrates this pattern). +One of the key features of Soroban Authorization Framework is the ability to easily make authorized sub-contract calls. For example, it is possible for a contract to call `require_auth` for an `Address` and then call `token.xfer` authorized for the same `Address` (learn more in [timelock example] that demonstrates this pattern). Contracts don't need to do anything special to benefit from this feature. Just calling a sub-contract that calls `require_auth` will ensure that the sub-contract call has been properly authorized. @@ -115,13 +115,13 @@ This is the extension point of account abstraction. A contract that implements t Contract accounts can also be treated as a custodial wallet. It holds the user's funds (token balances, NFTs etc.) and provides the user(s) with ways to authorize operations on these funds. Nothing prevents contract accounts from authorizing operations unrelated to balances; for example, they can perform administrative functions for tokens (contract accounts define what to do when `require_auth` is called). -For the exact interface and more details, see the [Simple Account example]. +For the exact interface and more details, learn more in the [Simple Account example]. [Simple Account example]: ../../../build/smart-contracts/example-contracts/simple-account.mdx ### Secp256r1, passkeys and contract accounts -After a successful public validator vote to upgrade Stellar's Mainnet to Protocol 21, the secp256r1 signature scheme was enabled for smart contract transactions. This allows developers to implement passkeys to sign transactions instead of using secret keys or seed phrases. For guidance, see the [passkey wallet guide](../../../build/guides/contract-accounts/smart-wallets.mdx). +After a successful public validator vote to upgrade Stellar's Mainnet to Protocol 21, the secp256r1 signature scheme was enabled for smart contract transactions. This allows developers to implement passkeys to sign transactions instead of using secret keys or seed phrases. For guidance, learn more in the [passkey wallet guide](../../../build/guides/contract-accounts/smart-wallets.mdx). ### Advanced Concepts diff --git a/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx b/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx index bbf31c9a11..e04a887c86 100644 --- a/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx +++ b/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx @@ -349,7 +349,7 @@ Additionally, Soroban transactions containing `InvokeHostFunctionOp` have the fo - The transaction **source account cannot be a muxed account**. - The **operation source account, if set, cannot be a muxed account**. -See [Send to and receive payments from Contract Accounts](../../../../build/guides/transactions/send-and-receive-c-accounts.mdx) for information on how to provide a muxed ID when making payments in Soroban. +Learn more in [Send to and Receive Payments from Contract Accounts](../../../../build/guides/transactions/send-and-receive-c-accounts.mdx) for information on how to provide a muxed ID when making payments in Soroban. ### InvokeHostFunctionOp @@ -544,7 +544,7 @@ struct SorobanAuthorizedContractFunction - `SOROBAN_AUTHORIZED_FUNCTION_TYPE_CONTRACT_FN` is a contract function that includes the address of the contract, name of the function being invoked, and arguments of the `require_auth`/`require_auth_for_args` call performed on behalf of the address. Note, that if `require_auth[_for_args]` wasn't called, there shouldn't be a `SorobanAuthorizedInvocation` entry in the transaction. - `SOROBAN_AUTHORIZED_FUNCTION_TYPE_CREATE_CONTRACT_HOST_FN` is authorization for `HOST_FUNCTION_TYPE_CREATE_CONTRACT` or for `create_contract` host function called from a contract. It only contains the `CreateContractArgs` XDR structure corresponding to the created contract. -Building `SorobanAuthorizedInvocation` trees may be simplified by using the recording auth mode in Soroban's `simulateTransaction` mechanism (see the [docs][simulate-transaction-doc] for more details). +Building `SorobanAuthorizedInvocation` trees may be simplified by using the recording auth mode in Soroban's `simulateTransaction` mechanism (learn more in the [Transaction Simulation section][simulate-transaction-doc]). [envelope-xdr]: https://github.com/stellar/stellar-xdr/blob/v27.0/Stellar-transaction.x#L747-L754 [simulate-transaction-doc]: transaction-simulation.mdx#authorization diff --git a/docs/learn/fundamentals/contract-development/contract-lifecycle.mdx b/docs/learn/fundamentals/contract-development/contract-lifecycle.mdx index 0324291192..53e6953033 100644 --- a/docs/learn/fundamentals/contract-development/contract-lifecycle.mdx +++ b/docs/learn/fundamentals/contract-development/contract-lifecycle.mdx @@ -67,4 +67,4 @@ Contracts can be monitored in two main ways: by observing events emitted during ## Upgrading contracts -See the [Upgrading Contracts page](../../../build/guides/conventions/upgrading-contracts.mdx) for details on this. +Learn more in the [Upgrading Contracts page](../../../build/guides/conventions/upgrading-contracts.mdx) for details on this. diff --git a/docs/learn/fundamentals/contract-development/overview.mdx b/docs/learn/fundamentals/contract-development/overview.mdx index 33792ebbc1..2a2a4e7d48 100644 --- a/docs/learn/fundamentals/contract-development/overview.mdx +++ b/docs/learn/fundamentals/contract-development/overview.mdx @@ -47,7 +47,7 @@ In addition to the ledger entries that are created during the contract upload/de Now that you have learned the basics of a Stellar contract, let's understand some concepts about contract invocation. When a transaction attempts invokes a function on the contract, the Wasm bytecode is first retrieved from the ledger, and a secure, isolated runtime virtual machine ("VM") is instantiated so it can run the bytecode for the contract and then exit. This approach offers several benefits, including security as the virtual machine (VM) operates in a sandboxed environment and provides deterministic execution. -To test out invoking contracts on Testnet, please see [Stellar Lab's contract explorer](https://lab.stellar.org/smart-contracts/contract-explorer?$=network$id=testnet&label=Testnet&horizonUrl=https:////horizon-testnet.stellar.org&rpcUrl=https:////soroban-testnet.stellar.org&passphrase=Test%20SDF%20Network%20/;%20September%202015;&smartContracts$explorer$contractId=CB2RXGQVNGOMHW3XYCPKREXHD45M4DMJ2PTBETV6P3EMV22QLJFUQHWB;;). +To test out invoking contracts on Testnet, learn more at [Stellar Lab's contract explorer](https://lab.stellar.org/smart-contracts/contract-explorer?$=network$id=testnet&label=Testnet&horizonUrl=https:////horizon-testnet.stellar.org&rpcUrl=https:////soroban-testnet.stellar.org&passphrase=Test%20SDF%20Network%20/;%20September%202015;&smartContracts$explorer$contractId=CB2RXGQVNGOMHW3XYCPKREXHD45M4DMJ2PTBETV6P3EMV22QLJFUQHWB;;). ## Contract Info @@ -63,13 +63,13 @@ _Explore contract info at [Stellar Lab's Contract Explorer](https://lab.stellar. ### Environment Meta -Contracts must contain a Wasm custom section with name `contractenvmetav0` and containing a serialized `SCEnvMetaEntry`. The interface version stored within should match the version of the host functions supported. For reference, please see [CAP-46-1 Env Meta](https://github.com/stellar/stellar-protocol/blob/603a55b018a8ce12ac16aa8621d189d5b78d0d02/core/cap-0046-01.md?plain=1#L508). +Contracts must contain a Wasm custom section with name `contractenvmetav0` and containing a serialized `SCEnvMetaEntry`. The interface version stored within should match the version of the host functions supported. For reference, learn more in [CAP-46-1 Env Meta](https://github.com/stellar/stellar-protocol/blob/603a55b018a8ce12ac16aa8621d189d5b78d0d02/core/cap-0046-01.md?plain=1#L508). To view the Environment Meta, please consider using Stellar Lab's Contract Explorer, or Stellar CLI's command `stellar contract info env-meta --contract-id `. ### Contract Meta -Contracts can optionally include a custom Wasm section named `contractmetav0`, which contains a serialized `SCMetaEntry`. This section is not used by the network itself, but allows contracts to embed arbitrary metadata, including contract name, version, author, supported interfaces, source repo, or home domain. Applications and tooling can read this metadata to provide richer developer experiences, better indexing, or enhanced contract discovery. For reference, please see [SEP-46 Contract Meta](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0046.md). +Contracts can optionally include a custom Wasm section named `contractmetav0`, which contains a serialized `SCMetaEntry`. This section is not used by the network itself, but allows contracts to embed arbitrary metadata, including contract name, version, author, supported interfaces, source repo, or home domain. Applications and tooling can read this metadata to provide richer developer experiences, better indexing, or enhanced contract discovery. For reference, learn more in [SEP-46 Contract Meta](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0046.md). To add metadata to Contract Meta, please use the Stellar CLI command `stellar contract build --meta `, or use the Rust SDK (e.g. `contractmeta!(key="name", val="Defi Swap Contract")`). @@ -77,7 +77,7 @@ To view the Contract Meta, please use the Stellar Lab's Contract Explorer, or th ### Contract Spec -Contracts should contain a Wasm custom section with name `contractspecv0` and containing a serialized stream of [`SCSpecEntry`]. There should be a [`SCSpecEntry`] for every function, struct, and union exported by the contract. For reference, please see [SEP-48 Contract Interface Specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0048.md). +Contracts should contain a Wasm custom section with name `contractspecv0` and containing a serialized stream of [`SCSpecEntry`]. There should be a [`SCSpecEntry`] for every function, struct, and union exported by the contract. For reference, learn more in [SEP-48 Contract Interface Specification](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0048.md). A contract spec is just like an ABI (Application Binary Interface) in Ethereum. It is a standardized description of a smart contract's interface, typically in JSON format or XDR format. It defines the contract's functions, data structures, events, and errors in a way that external applications can understand and use. diff --git a/docs/learn/fundamentals/contract-development/rust-dialect.mdx b/docs/learn/fundamentals/contract-development/rust-dialect.mdx index 36ec03965a..878dcf8946 100644 --- a/docs/learn/fundamentals/contract-development/rust-dialect.mdx +++ b/docs/learn/fundamentals/contract-development/rust-dialect.mdx @@ -12,7 +12,7 @@ These constraints and priorities are _similar_ to those encountered when writing :::note -These constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. See [debugging contracts](./errors-and-debugging/debugging.mdx) for more details. +These constraints and priorities are **not enforced when building in local-testing mode**, and in fact local contract tests will _frequently_ use facilities -- to generate test input, inspect test output, and guide testing -- that are not supported in the deployment guest environment. Developers **must understand** the difference between code that is compiled-in to Wasm modules for deployment and code that is conditionally compiled for testing. Learn more in [debugging contracts](./errors-and-debugging/debugging.mdx). ::: diff --git a/docs/learn/fundamentals/contract-development/storage/persisting-data.mdx b/docs/learn/fundamentals/contract-development/storage/persisting-data.mdx index 440163e191..dc287e3783 100644 --- a/docs/learn/fundamentals/contract-development/storage/persisting-data.mdx +++ b/docs/learn/fundamentals/contract-development/storage/persisting-data.mdx @@ -72,7 +72,7 @@ In addition to the types of state, it is also helpful to consider the type of co ### Best Practices - Prefer `Temporary` over `Persistent` and `Instance` storage - - Anything that can have a timeout should be `Temporary` with TTL set to the timeout. See the [resource limits table](https://lab.stellar.org/network-limits) on the Stellar Lab for the current maximum TTL/timeout. + - Anything that can have a timeout should be `Temporary` with TTL set to the timeout. Learn more at the [resource limits table](https://lab.stellar.org/network-limits) on the Stellar Lab for the current maximum TTL/timeout. - Ideally, `Temporary` entries should be associated with an absolute ledger boundary and thus never need a TTL extension - Example: Soroban Auth signatures have an absolute expiration ledger, so nonces can be stored in `Temporary` entries without security risks - Example: SAC allowance that lives only until a given ledger (so that some old allowance signature can not be used in the future if not exhausted) diff --git a/docs/learn/fundamentals/contract-development/storage/state-archival.mdx b/docs/learn/fundamentals/contract-development/storage/state-archival.mdx index 2b57c5b095..01ec020907 100644 --- a/docs/learn/fundamentals/contract-development/storage/state-archival.mdx +++ b/docs/learn/fundamentals/contract-development/storage/state-archival.mdx @@ -14,7 +14,7 @@ description: Smart contract state archival. /> -Contract data is made up of three different types: `Persistent`, `Temporary`, and `Instance`. In a contract, these are accessed with `env.storage().persistent()`, `env.storage().temporary()`, and `env.storage().instance()` respectively; see the [`storage()` docs](https://docs.rs/soroban-sdk/latest/soroban_sdk/storage/struct.Storage.html). +Contract data is made up of three different types: `Persistent`, `Temporary`, and `Instance`. In a contract, these are accessed with `env.storage().persistent()`, `env.storage().temporary()`, and `env.storage().instance()` respectively; learn more at the [`storage()` docs](https://docs.rs/soroban-sdk/latest/soroban_sdk/storage/struct.Storage.html). Learn about choosing the right storage for your use case in this [How-To Guide](../../../../build/guides/storage/choosing-the-right-storage.mdx) and other state archival related guides [here](../../../../build/guides/archival). @@ -94,7 +94,7 @@ If you would like to extend the contract code or contract instance separately, y Here are some important points to keep in mind when it comes to archived entries - 1. A Soroban transaction that has a key to an archived Persistent entry in the footprint, but not in the transaction's restore list, will fail immediately during the apply stage prior to contract execution. It does not matter if the contract itself was going to access the entry. (If the entry _is_ included in the restore list, it's [automatically restored](#contract-data-automatic-restoration) before the host function runs instead.) -2. Due to the previous point that archived entries can never make it into smart contract logic, there is no reason to write code in your contract to handle archived entries. The same applies to contract test cases - while you may want to write tests that check if your extension logic is correct, you don't need to write archival tests because the transaction will fail before getting to the contract. It is possible though to access an archived entry in a Soroban test case, in which case the host will panic. You can read more about this in [Test TTL Extensions](../../../../build/guides/archival/test-ttl-extension.mdx). +2. Due to the previous point that archived entries can never make it into smart contract logic, there is no reason to write code in your contract to handle archived entries. The same applies to contract test cases - while you may want to write tests that check if your extension logic is correct, you don't need to write archival tests because the transaction will fail before getting to the contract. It is possible though to access an archived entry in a Soroban test case, in which case the host will panic. Learn more about this in the [Test TTL Extension guide](../../../../build/guides/archival/test-ttl-extension.mdx). 3. Archived persistent entries can never be re-created. They must instead be restored. Once they are restored, then they can be modified or deleted. ## Terms and Semantics @@ -115,7 +115,7 @@ Minimum TTL is a network parameter. Refer to the [resource reference](https://la ### Maximum TTL -On any given ledger, an entry's TTL can be extended up to the maximum TTL. This is a network parameter (see the [resource limits table](https://lab.stellar.org/network-limits) on the Stellar Lab for the current maximum TTL). Maximum TTL is not enforced based on when an entry was created, but based on the current ledger. For example, if an entry is created on January 1st, 2024, its TTL could initially be extended up to January 1st, 2025. After this initial TTL extension, if the entry received another TTL extension later on January 10th, 2024, the TTL could be extended up to January 10th, 2025. The `max_ttl()` function can be used to determine the current maximum allowed TTL. +On any given ledger, an entry's TTL can be extended up to the maximum TTL. This is a network parameter (learn more at the [resource limits table](https://lab.stellar.org/network-limits) on the Stellar Lab for the current maximum TTL). Maximum TTL is not enforced based on when an entry was created, but based on the current ledger. For example, if an entry is created on January 1st, 2024, its TTL could initially be extended up to January 1st, 2025. After this initial TTL extension, if the entry received another TTL extension later on January 10th, 2024, the TTL could be extended up to January 10th, 2025. The `max_ttl()` function can be used to determine the current maximum allowed TTL. ## Operations @@ -207,7 +207,7 @@ The manual operation (`RestoreFootprintOp`) is, for the most part, no longer nee Both restoring and extending the TTL of ledger entries follows a three-step process regardless of their nature (contract data, instances, etc.): -1. **Identify the ledger entries**. This usually means acquiring them from a Stellar RPC server as part of your initial transaction simulation (see the [transaction simulation docs](../contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](../../../../data/apis/rpc/api-reference/methods/simulateTransaction.mdx) RPC method). +1. **Identify the ledger entries**. This usually means acquiring them from a Stellar RPC server as part of your initial transaction simulation (learn more in the [transaction simulation docs](../contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](../../../../data/apis/rpc/api-reference/methods/simulateTransaction.mdx) RPC method). 2. **Prepare your operation**. This means describing the ledger entries within the corresponding operation (i.e., `ExtendFootprintTTLOp` or `RestoreFootprintOp`) and its ledger footprint (the `SorobanTransactionData` field), then simulating it to fill out fee and resource usage information (when restoring, you usually have simulation results already). diff --git a/docs/learn/fundamentals/contract-development/transaction-lifecycle.mdx b/docs/learn/fundamentals/contract-development/transaction-lifecycle.mdx index 0b29f20f69..cd6ba9eb51 100644 --- a/docs/learn/fundamentals/contract-development/transaction-lifecycle.mdx +++ b/docs/learn/fundamentals/contract-development/transaction-lifecycle.mdx @@ -5,7 +5,7 @@ description: here's how a transaction works, and stuff. draft: true --- -See [GH issue #532](https://github.com/stellar/soroban-docs/issues/532) for details. +Learn more in [GitHub issue #532](https://github.com/stellar/soroban-docs/issues/532) for details. We're getting a lot of questions that relate to the transaction lifecycle and don't have a great resource to send people to. diff --git a/docs/learn/fundamentals/contract-development/types/built-in-types.mdx b/docs/learn/fundamentals/contract-development/types/built-in-types.mdx index b3f43d223b..5a8ebb7287 100644 --- a/docs/learn/fundamentals/contract-development/types/built-in-types.mdx +++ b/docs/learn/fundamentals/contract-development/types/built-in-types.mdx @@ -86,7 +86,7 @@ Address is a universal opaque identifier to use in contracts. It may represent a Address can be used as a contract function input argument (for example, to identify the payment recipient), as a data key (for example, to store the balance), as the authentication & authorization source (for example, to authorize a token transfer) etc. -See [authorization documentation](../authorization.mdx) for more details on how to use the `Address` type. +Learn more about how to use the `Address` type in the [authorization documentation](../authorization.mdx). ## Option (`Option`) diff --git a/docs/learn/fundamentals/contract-development/types/custom-types.mdx b/docs/learn/fundamentals/contract-development/types/custom-types.mdx index 0388f6f704..436db38551 100644 --- a/docs/learn/fundamentals/contract-development/types/custom-types.mdx +++ b/docs/learn/fundamentals/contract-development/types/custom-types.mdx @@ -29,7 +29,7 @@ The [custom types example] demonstrates how to define your own types. :::info -Error enum types are another type contracts can define that have some unique behaviors. See [Errors](../errors-and-debugging/errors.mdx) for more information. +Error enum types are another type contracts can define that have some unique behaviors. Learn more in [Errors](../errors-and-debugging/errors.mdx). ::: diff --git a/docs/learn/fundamentals/fees-resource-limits-metering.mdx b/docs/learn/fundamentals/fees-resource-limits-metering.mdx index cab2d7dc58..12c2506739 100644 --- a/docs/learn/fundamentals/fees-resource-limits-metering.mdx +++ b/docs/learn/fundamentals/fees-resource-limits-metering.mdx @@ -15,7 +15,7 @@ There are two types of fees on Stellar: **Resource fee: _only applies to smart contract transactions_**. The amount the submitter must pay for their transaction to execute. This amount is based on a transaction’s resource consumption and the state of network storage (described in the [Storage Dynamic Pricing section](#dynamic-pricing-for-storage)). Read about resource fees [below](#resource-fee). -**Inclusion fee:** the maximum amount the submitter is willing to pay for the transaction to be included in the ledger. Read more [below](#inclusion-fee). +**Inclusion fee:** the maximum amount the submitter is willing to pay for the transaction to be included in the ledger. Learn more in the [Inclusion fee section](#inclusion-fee). When competing for space on the ledger, smart contract transactions are _only_ competing with other smart contract transactions, and transactions that do not execute a smart contract are _only_ competing with other transactions that do not execute a smart contract. @@ -163,7 +163,7 @@ Cost types are carefully selected to: Each cost type has a separate model for both resource types (CPU and memory). -The parameters for each model, `a` and `b`, are calibrated and fitted offline against inputs of various sizes. The collection of all model cost parameters from the network configurable entries (see [`ConfigSettingsEntry`](https://github.com/stellar/stellar-xdr/blob/e372df9f677961aac04c5a4cc80a3667f310b29f/Stellar-contract-config-setting.x#L223-L226) can be updated through network consensus. +The parameters for each model, `a` and `b`, are calibrated and fitted offline against inputs of various sizes. The collection of model cost parameters in the network configuration entries can be updated through network consensus. Learn more in [`ConfigSettingsEntry`](https://github.com/stellar/stellar-xdr/blob/e372df9f677961aac04c5a4cc80a3667f310b29f/Stellar-contract-config-setting.x#L223-L226). ### Metering process diff --git a/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx b/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx index f31709881d..e2f7fdf97a 100644 --- a/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx +++ b/docs/learn/fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx @@ -33,7 +33,7 @@ A couple of notes on order books on Stellar: - Order books contain all orders that are acceptable to parties on either side to make a trade. - Some assets will have a small or nonexistent order book between them. In these cases, Stellar facilitates path payments, which we’ll discuss later. -To view an order book chart, see the [Order Book Wikipedia Page](https://en.wikipedia.org/wiki/Order_book). In addition, there are also plenty of video tutorials and articles out there that can help you understand how order books work in greater detail. +To view an order book chart, learn more at the [Order Book Wikipedia Page](https://en.wikipedia.org/wiki/Order_book). In addition, there are also plenty of video tutorials and articles out there that can help you understand how order books work in greater detail. ### Orders diff --git a/docs/learn/fundamentals/lumens.mdx b/docs/learn/fundamentals/lumens.mdx index f29a0aee9c..d564521fe2 100644 --- a/docs/learn/fundamentals/lumens.mdx +++ b/docs/learn/fundamentals/lumens.mdx @@ -17,7 +17,7 @@ Stellar requires a small fee for all transactions to prevent ledger spam and pri To learn about fees on Stellar, see our [Fees section](./fees-resource-limits-metering.mdx). -Smart contract transactions on Stellar employ a different fee structure based on an inclusion fee and resource consumption (which includes [rent](#rent)). Read more in the [Fees and Metering section](./fees-resource-limits-metering.mdx). +Smart contract transactions on Stellar employ a different fee structure based on an inclusion fee and resource consumption (which includes [rent](#rent)). Learn more in the [Fees, Resource Limits, and Metering section](./fees-resource-limits-metering.mdx). ## Base reserves diff --git a/docs/learn/fundamentals/stellar-data-structures/assets.mdx b/docs/learn/fundamentals/stellar-data-structures/assets.mdx index 41d1da2230..d2b4fa036f 100644 --- a/docs/learn/fundamentals/stellar-data-structures/assets.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/assets.mdx @@ -21,7 +21,7 @@ Assets exist in two forms on Stellar: "Classic" assets issued by Stellar accounts (`G...` addresses) and their built-in Stellar Asset Contract (SAC) implementation, and contract tokens issued by a deployed Wasm contract (`C...` addresses). -Learn more about the differences in the [Assets and Tokens section](../../../tokens/README.mdx). +Learn more about the differences in the [Stellar Assets and Contract Tokens section](../../../tokens/README.mdx). ::: @@ -35,7 +35,7 @@ An asset’s identifying code. There are three different formats: Alphanumeric 4 Learn about liquidity pool shares in the [Liquidity Pool section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). -Learn more about asset codes in the [Naming an Asset section](../../../tokens/control-asset-access.mdx#naming-an-asset) +Learn more about asset codes in the [Naming an Asset section](../../../tokens/control-asset-access.mdx#naming-an-asset). ### Issuer diff --git a/docs/learn/fundamentals/stellar-data-structures/events.mdx b/docs/learn/fundamentals/stellar-data-structures/events.mdx index 593dbda537..1b432bee0a 100644 --- a/docs/learn/fundamentals/stellar-data-structures/events.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/events.mdx @@ -139,7 +139,7 @@ There are three `ContractEventType`'s - 1. `CONTRACT` events are events emitted by contracts that use the `contract_event` host function to convey state changes. 2. `SYSTEM` events are events emitted by the host. At the moment, there's only one system event emitted by the host. It is emitted when the `update_current_contract_wasm` host function is called, where `topics = ["executable_update", old_executable: ContractExecutable, new_executable: ContractExecutable]` and `data = []`. -3. `DIAGNOSTIC` events are meant for debugging and will not be emitted unless the host instance explicitly enables it. You can read more about this below. +3. `DIAGNOSTIC` events are meant for debugging and will not be emitted unless the host instance explicitly enables it. ## What are diagnosticEvents? diff --git a/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx b/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx index 7c91cf0ead..f08e298526 100644 --- a/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/ledgers.mdx @@ -125,7 +125,7 @@ The maximum number of operations validators have agreed to process in a given le ### Base fee -The fee the network charges per operation in a transaction. Calculated in stroops. See the [Fees section](../../fundamentals/fees-resource-limits-metering.mdx) for more information. +The fee the network charges per operation in a transaction. Calculated in stroops. Learn more in the [Fees section](../../fundamentals/fees-resource-limits-metering.mdx). ### Base reserve diff --git a/docs/learn/fundamentals/stellar-stack.mdx b/docs/learn/fundamentals/stellar-stack.mdx index 06c92f8dbc..bb9740e14b 100644 --- a/docs/learn/fundamentals/stellar-stack.mdx +++ b/docs/learn/fundamentals/stellar-stack.mdx @@ -15,7 +15,7 @@ The Stellar stack is made up of the following components: the networks (Mainnet, Stellar has three networks: the public network (Mainnet, also called Pubnet or the Public Network), the test network (Testnet), and a dev network (Futurenet). Mainnet is the main network used by applications in production. The Testnet is a smaller, free-to-use network maintained by SDF that functions like the Mainnet but doesn’t connect to real money and is the best place for developers to test their applications. Futurenet is a dev network you can use to test more bleeding edge features. -Read more about the different networks in the [Networks section](../../networks/README.mdx). +Learn more about the different networks in the [Networks section](../../networks/README.mdx). ## Stellar Core diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx index d69f6e6ab2..d6628aedbf 100644 --- a/docs/learn/fundamentals/transactions/list-of-operations.mdx +++ b/docs/learn/fundamentals/transactions/list-of-operations.mdx @@ -66,7 +66,7 @@ Sends an amount in a specific asset to a destination account | `PAYMENT_SRC_NO_TRUST` | -3 | The source account does not trust the issuer of the asset it is trying to send. | | `PAYMENT_SRC_NOT_AUTHORIZED` | -4 | The source account is not authorized to send this payment. | | `PAYMENT_NO_DESTINATION` | -5 | The receiving account does not exist. Note that this error will **not** be returned if the receiving account is the issuer of `asset` (i.e, when the asset is being _burned_). | -| `PAYMENT_NO_TRUST` | -6 | The receiver does not trust the issuer of the asset being sent. For more information, see the [Assets section](../stellar-data-structures/assets.mdx). | +| `PAYMENT_NO_TRUST` | -6 | The receiver does not trust the issuer of the asset being sent. Learn more in the [Assets section](../stellar-data-structures/assets.mdx). | | `PAYMENT_NOT_AUTHORIZED` | -7 | The destination account is not authorized by the asset's issuer to hold the asset. | | `PAYMENT_LINE_FULL` | -8 | The destination account (receiver) does not have sufficient limits to receive `amount` and still satisfy its buying liabilities. | @@ -74,7 +74,7 @@ Sends an amount in a specific asset to a destination account A payment where the asset sent can be different than the asset received; allows the user to specify the amount of the asset to send -Learn more about path payments: [Path Payments Guide](../../../build/guides/transactions/path-payments.mdx) +Learn more about path payments in our [Path Payments guide](../../../build/guides/transactions/path-payments.mdx). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.pathPaymentStrictSend) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/PathPaymentStrictSendOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#PathPaymentStrictSend) **Threshold**: Medium @@ -99,7 +99,7 @@ Learn more about path payments: [Path Payments Guide](../../../build/guides/tran | `PATH_PAYMENT_STRICT_SEND_SRC_NO_TRUST` | -3 | The source account does not trust the issuer of the asset it is trying to send. | | `PATH_PAYMENT_STRICT_SEND_SRC_NOT_AUTHORIZED` | -4 | The source account is not authorized to send this payment. | | `PATH_PAYMENT_STRICT_SEND_NO_DESTINATION` | -5 | The destination account does not exist. | -| `PATH_PAYMENT_STRICT_SEND_NO_TRUST` | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](../stellar-data-structures/assets.mdx). | +| `PATH_PAYMENT_STRICT_SEND_NO_TRUST` | -6 | The destination account does not trust the issuer of the asset being sent. For more, learn more in the [Assets section](../stellar-data-structures/assets.mdx). | | `PATH_PAYMENT_STRICT_SEND_NOT_AUTHORIZED` | -7 | The destination account is not authorized by the asset's issuer to hold the asset. | | `PATH_PAYMENT_STRICT_SEND_LINE_FULL` | -8 | The destination account does not have sufficient limits to receive `destination amount` and still satisfy its buying liabilities. | | `PATH_PAYMENT_STRICT_SEND_TOO_FEW_OFFERS` | -10 | There is no path of offers connecting the `send asset` and `destination asset`. Stellar only considers paths of length 5 or shorter. | @@ -110,7 +110,7 @@ Learn more about path payments: [Path Payments Guide](../../../build/guides/tran A payment where the asset received can be different from the asset sent; allows the user to specify the amount of the asset received -Learn more about path payments: [Path Payments Guide](../../../build/guides/transactions/path-payments.mdx) +Learn more about path payments in our [Path Payments guide](../../../build/guides/transactions/path-payments.mdx). **SDKs**: [JavaScript](https://stellar.github.io/js-stellar-sdk/Operation.html#.pathPaymentStrictReceive) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/PathPaymentStrictReceiveOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#PathPaymentStrictReceive) **Threshold**: Medium @@ -135,7 +135,7 @@ Learn more about path payments: [Path Payments Guide](../../../build/guides/tran | `PATH_PAYMENT_STRICT_RECEIVE_SRC_NO_TRUST` | -3 | The source account does not trust the issuer of the asset it is trying to send. | | `PATH_PAYMENT_STRICT_RECEIVE_SRC_NOT_AUTHORIZED` | -4 | The source account is not authorized to send this payment. | | `PATH_PAYMENT_STRICT_RECEIVE_NO_DESTINATION` | -5 | The destination account does not exist. | -| `PATH_PAYMENT_STRICT_RECEIVE_NO_TRUST` | -6 | The destination account does not trust the issuer of the asset being sent. For more, see the [Assets section](../stellar-data-structures/assets.mdx). | +| `PATH_PAYMENT_STRICT_RECEIVE_NO_TRUST` | -6 | The destination account does not trust the issuer of the asset being sent. For more, learn more in the [Assets section](../stellar-data-structures/assets.mdx). | | `PATH_PAYMENT_STRICT_RECEIVE_NOT_AUTHORIZED` | -7 | The destination account is not authorized by the asset's issuer to hold the asset. | | `PATH_PAYMENT_STRICT_RECEIVE_LINE_FULL` | -8 | The destination account does not have sufficient limits to receive `destination amount` and still satisfy its buying liabilities. | | `PATH_PAYMENT_STRICT_RECEIVE_TOO_FEW_OFFERS` | -10 | There is no path of offers connecting the `send asset` and `destination asset`. Stellar only considers paths of length 5 or shorter. | @@ -146,7 +146,7 @@ Learn more about path payments: [Path Payments Guide](../../../build/guides/tran Creates, updates, or deletes an offer to buy a specific amount of an asset for another -Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../liquidity-on-stellar-sdex-liquidity-pools.mdx) +Learn more about manage buy offers in our [Liquidity on Stellar section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageBuyOffer) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ManageBuyOfferOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#ManageBuyOffer) **Threshold**: Medium @@ -180,7 +180,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Creates, updates, or deletes an offer to sell a specific amount of an asset for another -Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../liquidity-on-stellar-sdex-liquidity-pools.mdx) +Learn more about manage sell offers in our [Liquidity on Stellar section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageSellOffer) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ManageSellOfferOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#ManageSellOffer) **Threshold**: Medium @@ -214,7 +214,7 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Creates an offer to sell one asset for another without taking a reverse offer of equal price -Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Pools](../liquidity-on-stellar-sdex-liquidity-pools.mdx) +Learn more about passive sell offers in our [Liquidity on Stellar section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). **SDKs**: [JavaScript](https://stellar.github.io/js-stellar-sdk/Operation.html#.createPassiveSellOffer) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/CreatePassiveSellOfferOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#CreatePassiveSellOffer) **Threshold**: Medium @@ -247,9 +247,11 @@ Learn more about passive sell offers: [Liquidity on Stellar: SDEX and Liquidity Set options for an account such as flags, inflation destination, signers, home domain, and master key weight -Learn more about flags: [Flags Section](../../../tokens/control-asset-access.mdx#controlling-access-to-an-asset-with-flags) -Learn more about the home domain: [Stellar Ecosystem Proposals SEP-0001](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md) -Learn more about signers operations and key weight: [Signature and Multisignature Section](../../fundamentals/transactions/signatures-multisig.mdx) +Learn more about flags in our [Flags section](../../../tokens/control-asset-access.mdx#controlling-access-to-an-asset-with-flags). + +Learn more about home domains in [SEP-1](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md). + +Learn more about signer operations and key weights in our [Signatures and Multisig section](../../fundamentals/transactions/signatures-multisig.mdx). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.setOptions) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/SetOptionsOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#SetOptions) **Threshold**: High (when updating signers or other thresholds) or Medium (when updating everything else) @@ -265,7 +267,7 @@ Learn more about signers operations and key weight: [Signature and Multisignatur | Low threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a low threshold](../../fundamentals/transactions/signatures-multisig.mdx). | | Medium threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a medium threshold](../../fundamentals/transactions/signatures-multisig.mdx). | | High threshold | integer | A number from 0-255 (inclusive) representing the threshold this account sets on all operations it performs that have [a high threshold](../../fundamentals/transactions/signatures-multisig.mdx). | -| Home domain | string | Sets the home domain of an account. See [Federation](../../glossary.mdx#federation). | +| Home domain | string | Sets the home domain of an account. Learn more in [Federation](../../glossary.mdx#federation). | | Signer | \{Public Key, weight} | Add, update, or remove a signer from an account. Signer weight is a number from 0-255 (inclusive). The signer is deleted if the weight is 0. | **Possible errors**: @@ -286,7 +288,7 @@ Learn more about signers operations and key weight: [Signature and Multisignatur Creates, updates, or deletes a trustline -Learn more about trustlines: [Trustlines section](../stellar-data-structures/accounts.mdx#trustlines) +Learn more about trustlines in our [Accounts section](../stellar-data-structures/accounts.mdx#trustlines). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.changeTrust) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ChangeTrustOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#ChangeTrust) **Threshold**: Medium @@ -376,7 +378,7 @@ Sponsorship also blocks a merge (`ACCOUNT_MERGE_IS_SPONSOR`), and this covers tw Sets, modifies, or deletes a data entry (name/value pair) that is attached to an account -Learn more about entries and subentries: [Accounts section](../stellar-data-structures/accounts.mdx#subentries) +Learn more about entries and subentries in our [Accounts section](../stellar-data-structures/accounts.mdx#subentries). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.manageData) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ManageDataOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#ManageData) **Threshold**: Medium @@ -420,7 +422,7 @@ Bumps forward the sequence number of the source account to the given sequence nu Moves an amount of asset from the operation source account into a new ClaimableBalanceEntry -Learn more about claimable balances: [Claimable Balances Guide](../../../build/guides/transactions/claimable-balances.mdx) +Learn more about claimable balances in our [Claimable Balances guide](../../../build/guides/transactions/claimable-balances.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/CreateClaimableBalanceOperation.java) **Threshold**: Medium @@ -447,7 +449,7 @@ Learn more about claimable balances: [Claimable Balances Guide](../../../build/g Claims a ClaimableBalanceEntry that corresponds to the BalanceID and adds the amount of an asset on the entry to the source account -Learn more about claimable balances and view more parameters: [Claimable Balances Guide](../../../build/guides/transactions/claimable-balances.mdx) +Learn more about claimable balances and their parameters in our [Claimable Balances guide](../../../build/guides/transactions/claimable-balances.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ClaimClaimableBalanceOperation.java) **Threshold**: Low @@ -456,7 +458,7 @@ Learn more about claimable balances and view more parameters: [Claimable Balance | Parameters | Type | Description | | --- | --- | --- | -| BalanceID | claimableBalanceID | BalanceID on the ClaimableBalanceEntry that the source account is claiming. The balanceID can be retrieved from a successful `CreateClaimableBalanceResult`. See [Claimable Balance Guide](../../../build/guides/transactions/claimable-balances.mdx#create-claimable-balance) for more information. | +| BalanceID | claimableBalanceID | BalanceID on the ClaimableBalanceEntry that the source account is claiming. The balanceID can be retrieved from a successful `CreateClaimableBalanceResult`. Learn more in the [Claimable Balances Guide](../../../build/guides/transactions/claimable-balances.mdx#create-claimable-balance). | **Possible errors**: @@ -474,7 +476,7 @@ Allows an account to pay the base reserves for another account; sponsoring accou There must also be an end sponsoring future reserves operation in the same transaction -Learn more about sponsored reserves: [Sponsored Reserves Guide](../../../build/guides/transactions/sponsored-reserves.mdx) +Learn more about sponsored reserves in our [Sponsored Reserves guide](../../../build/guides/transactions/sponsored-reserves.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/BeginSponsoringFutureReservesOperation.java) **Threshold**: Medium @@ -497,7 +499,7 @@ Learn more about sponsored reserves: [Sponsored Reserves Guide](../../../build/g Terminates the current is-sponsoring-future-reserves relationship in which the source account is sponsored -Learn more about sponsored reserves: [Sponsored Reserves Guide](../../../build/guides/transactions/sponsored-reserves.mdx) +Learn more about sponsored reserves in our [Sponsored Reserves guide](../../../build/guides/transactions/sponsored-reserves.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/EndSponsoringFutureReservesOperation.java) **Threshold**: Medium @@ -518,7 +520,7 @@ Learn more about sponsored reserves: [Sponsored Reserves Guide](../../../build/g Sponsoring account can remove or transfer sponsorships of existing ledgerEntries and signers; the logic of this operation depends on the state of the source account -Learn more about sponsored reserves: [Sponsored Reserves Guide](../../../build/guides/transactions/sponsored-reserves.mdx) +Learn more about sponsored reserves in our [Sponsored Reserves guide](../../../build/guides/transactions/sponsored-reserves.mdx). **Threshold**: Medium **Result**: `RevokeSponsorshipResult` @@ -527,7 +529,7 @@ This operation is a union with **two** possible types: | Union Type | Parameters | Type | Description | | --- | --- | --- | --- | -| `REVOKE_SPONSORSHIP_LEDGER_ENTRY` | LedgerKey | ledgerKey | Ledger key that holds information to identify a specific ledgerEntry that may have its sponsorship modified. See [LedgerKey](../../glossary.mdx#ledgerkey) for more information. | +| `REVOKE_SPONSORSHIP_LEDGER_ENTRY` | LedgerKey | ledgerKey | Ledger key that holds information to identify a specific ledgerEntry that may have its sponsorship modified. Learn more in [LedgerKey](../../glossary.mdx#ledgerkey). | Or @@ -549,7 +551,7 @@ Or Burns an amount in a specific asset from an account. Only the issuing account for the asset can perform this operation. -Learn more about clawbacks: [Clawback Guide](../../../build/guides/transactions/clawbacks.mdx) +Learn more about clawbacks in our [Clawbacks guide](../../../build/guides/transactions/clawbacks.mdx). **SDKs**: [JavaScript](http://stellar.github.io/js-stellar-sdk/Operation.html#.clawback) | [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ClawbackOperation.java) | [Go](https://godoc.org/github.com/stellar/go-stellar-sdk/txnbuild#Clawback) **Threshold**: Medium @@ -575,9 +577,9 @@ Learn more about clawbacks: [Clawback Guide](../../../build/guides/transactions/ Claws back an unclaimed ClaimableBalanceEntry, burning the pending amount of the asset. Only the issuing account for the asset can perform this operation. -Learn more about clawbacks: [Clawback Guide](../../../build/guides/transactions/clawbacks.mdx) +Learn more about clawbacks in our [Clawbacks guide](../../../build/guides/transactions/clawbacks.mdx). -Learn more about claimable balances: [Claimable Balances Guide](../../../build/guides/transactions/claimable-balances.mdx) +Learn more about claimable balances in our [Claimable Balances guide](../../../build/guides/transactions/claimable-balances.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/ClawbackClaimableBalanceOperation.java) **Threshold**: Medium @@ -602,7 +604,7 @@ Allows issuing account to configure authorization and trustline flags to an asse The Asset parameter is of the `TrustLineAsset` type. If you are modifying a trustline to a regular asset (i.e. one in a Code:Issuer format), this is equivalent to the Asset type. If you are modifying a trustline to a pool share, however, this is composed of the liquidity pool's unique ID. -Learn more about flags: [Flags Glossary Entry](../../glossary.mdx#flags) +Learn more about flags in the [Flags glossary entry](../../glossary.mdx#flags). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/SetTrustlineFlagsOperation.java) **Threshold**: Low @@ -634,7 +636,7 @@ Parameters to this operation depend on the ordering of assets in the liquidity p If the pool is empty, then this operation deposits maxAmountA of A and maxAmountB of B into the pool. If the pool is not empty, then this operation deposits at most maxAmountA of A and maxAmountB of B into the pool. The actual amounts deposited are determined using the current reserves of the pool. You can use these parameters to control a percentage of slippage. -Learn more about liquidity pools: [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx) +Learn more about liquidity pools in our [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/LiquidityPoolDepositOperation.java) **Threshold**: Medium @@ -667,7 +669,7 @@ Withdraw assets from a liquidity pool, reducing the number of pool shares in exc The minAmountA and minAmountB parameters can be used to control a percentage of slippage from the "spot price" on the pool. -Learn more about liquidity pools: [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx) +Learn more about liquidity pools in our [Liquidity Pools section](../liquidity-on-stellar-sdex-liquidity-pools.mdx). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/LiquidityPoolWithdrawOperation.java) **Threshold**: Medium @@ -703,7 +705,7 @@ The `InvokeHostFunctionOp` can be used to perform the following Soroban operatio Note that Soroban transactions can only contain one operation per transaction. -Learn more [here](../../fundamentals/contract-development/contract-interactions/stellar-transaction.mdx#invokehostfunctionop). +Learn more in the [Stellar Transaction section](../../fundamentals/contract-development/contract-interactions/stellar-transaction.mdx#invokehostfunctionop). **SDKs**: [Java](https://github.com/lightsail-network/java-stellar-sdk/blob/master/src/main/java/org/stellar/sdk/operations/InvokeHostFunctionOperation.java) **Threshold**: Medium diff --git a/docs/learn/fundamentals/transactions/operations-and-transactions.mdx b/docs/learn/fundamentals/transactions/operations-and-transactions.mdx index f0c340e44b..5b335a2553 100644 --- a/docs/learn/fundamentals/transactions/operations-and-transactions.mdx +++ b/docs/learn/fundamentals/transactions/operations-and-transactions.mdx @@ -23,13 +23,13 @@ Operations are individual commands that modify the ledger. Operations are used t All operations fall into one of three threshold categories: low, medium, or high, and each threshold category has a weight between 0 and 255 (which can be determined using set_options). Thresholds determine what signature weight is required for the operation to be accepted. For example, let’s say an account sets the medium threshold weight to 5. If the account wants to successfully establish a trustline with the `changeTrust` operation, the weight of the signature(s) must be greater than or equal to 5. -To learn more about signature weight, see the [Signatures and Multisig section](../../fundamentals/transactions/signatures-multisig.mdx). +Learn more about signature weight in the [Signatures and Multisig section](../../fundamentals/transactions/signatures-multisig.mdx). View a comprehensive list of Stellar operations and their threshold levels in the [List of Operations section](./list-of-operations.mdx). ### Transactions -The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). You can read more about this in our [XDR Section](../data-format/xdr.mdx). +The Stellar network encodes transactions using a standardized protocol called External Data Representation (XDR). Learn more about this in our [XDR section](../data-format/xdr.mdx). Accounts can only perform one transaction at a time. @@ -41,7 +41,7 @@ Transactions are atomic. Meaning if one operation in a transaction fails, all op Operations are executed for the source account of the transaction unless an operation override is defined. -Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Read more in the [Soroban docs](../../fundamentals/contract-development/contract-interactions/transaction-simulation.mdx). +Smart contract transactions also go through a simulation process where developers can test how the transaction would be executed on the network using the RPC endpoint `simulateTransaction`. Learn more in the [Transaction Simulation section](../../fundamentals/contract-development/contract-interactions/transaction-simulation.mdx). ## Memo diff --git a/docs/learn/fundamentals/transactions/signatures-multisig.mdx b/docs/learn/fundamentals/transactions/signatures-multisig.mdx index c38f5dd40c..da014f2e88 100644 --- a/docs/learn/fundamentals/transactions/signatures-multisig.mdx +++ b/docs/learn/fundamentals/transactions/signatures-multisig.mdx @@ -5,7 +5,7 @@ sidebar_position: 20 :::note -This section details signing non-smart contract transactions. For auth related to smart contract transactions, see [authorization](../../fundamentals/contract-development/authorization.mdx).) +This section details signing transactions that do not involve smart contracts. For smart contract authorization, learn more in [Authorization](../../fundamentals/contract-development/authorization.mdx). ::: @@ -15,7 +15,7 @@ Transaction signatures are created by signing the transaction object contents wi ### Thresholds -Each operation falls under a specific threshold category: low, medium, or high with a number level between 0-255 (to read more about this see our section on [Operations and Transactions](../../fundamentals/transactions/operations-and-transactions.mdx#operations)). This threshold determines what signature weight is needed to authorize an operation. +Each operation falls under a specific threshold category: low, medium, or high with a number level between 0-255. Learn more in the [Operations and Transactions section](../../fundamentals/transactions/operations-and-transactions.mdx#operations). This threshold determines what signature weight is needed to authorize an operation. To view each operation’s threshold, see our [List of Operations section](../../fundamentals/transactions/list-of-operations.mdx). diff --git a/docs/learn/fundamentals/transactions/transaction-lifecycle.mdx b/docs/learn/fundamentals/transactions/transaction-lifecycle.mdx index 881defc96b..371d19fecd 100644 --- a/docs/learn/fundamentals/transactions/transaction-lifecycle.mdx +++ b/docs/learn/fundamentals/transactions/transaction-lifecycle.mdx @@ -9,11 +9,11 @@ A user creates a transaction by setting the source account, sequence number, lis #### 1b. Transaction Simulation -Smart contract transactions undergo transaction simulation, where the transaction is run in a simulated environment to check for errors and ensure it can be executed successfully. Read more in the [Transaction Simulation section](../contract-development/contract-interactions/transaction-simulation.mdx). +Smart contract transactions undergo transaction simulation, where the transaction is run in a simulated environment to check for errors and ensure it can be executed successfully. Learn more in the [Transaction Simulation section](../contract-development/contract-interactions/transaction-simulation.mdx). ### 2. Signing (Transaction Signers) -Once the transaction is complete, it becomes a transaction envelope containing the transaction itself and a list of signers. All the required signatures must be collected and added to the transaction envelope’s list of signers. Commonly, it’s just the signature of the account doing the transaction, but more complicated setups can require collecting signatures from multiple parties. Read more about signatures in the [Signatures and Multisig section](./signatures-multisig.mdx). +Once the transaction is complete, it becomes a transaction envelope containing the transaction itself and a list of signers. All the required signatures must be collected and added to the transaction envelope’s list of signers. Commonly, it’s just the signature of the account doing the transaction, but more complicated setups can require collecting signatures from multiple parties. Learn more about signatures in the [Signatures and Multisig section](./signatures-multisig.mdx). ### 3. Submitting (Transaction Submitter) diff --git a/docs/learn/glossary.mdx b/docs/learn/glossary.mdx index ce486a0946..cd8ecbb86c 100644 --- a/docs/learn/glossary.mdx +++ b/docs/learn/glossary.mdx @@ -11,7 +11,7 @@ description: "Explore a comprehensive glossary of blockchain terms. Learn key co A central Stellar data structure to hold balances, sign transactions, and issue assets. -See the [Accounts section](./fundamentals/stellar-data-structures/accounts.mdx) to learn more. +Learn more in the [Accounts section](./fundamentals/stellar-data-structures/accounts.mdx). ### Account ID @@ -21,7 +21,7 @@ The public key used to create an account. This key persists across different key The on and off-ramps on the Stellar network that facilitate one-to-one conversion of off-chain representations to and from tokenized assets, for example, digital tokens representing bank deposits. -Read more in the [Anchors section](./fundamentals/anchors.mdx). +Learn more in the [Anchors section](./fundamentals/anchors.mdx). ### Application (app) {/* #app */} @@ -31,7 +31,7 @@ A software program designed for users to carry out a specific task (other than o Fiat, physical, or other tokens of value that are tracked, held, or transferred by the Stellar distributed network. -See the [Assets section](./fundamentals/stellar-data-structures/assets.mdx) to learn more. +Learn more in our [Assets section](./fundamentals/stellar-data-structures/assets.mdx). ### Balance @@ -39,7 +39,7 @@ The amount of a given asset an account holds. Each asset has its own balance and ### BalanceID -Parameter required when claiming a newly created entry via the Claim claimable balance operation. See [ClaimableBalanceID](#claimablebalanceid). +Parameter required when claiming a newly created entry via the Claim claimable balance operation. Learn more in [ClaimableBalanceID](#claimablebalanceid). ### Base Fee @@ -63,19 +63,25 @@ Remove an asset from circulation, which can happen in two ways: 1) a holder send A recursive data structure used to construct complex conditionals with different values of ClaimPredicateType. +Learn more in our [Claimable Balances guide](../build/guides/transactions/claimable-balances.mdx). + ### ClaimableBalanceID A SHA-256 hash of the OperationID for claimable balances. +Learn more in our [Claimable Balances guide](../build/guides/transactions/claimable-balances.mdx). + ### Claimant An object that holds both the destination account that can claim the ClaimableBalanceEntry and a ClaimPredicate that must evaluate to true for the claim to succeed. +Learn more in our [Claimable Balances guide](../build/guides/transactions/claimable-balances.mdx). + ### Clawback An amount of asset from a trustline or claimable balance removed (clawed back) from a recipient’s balance sheet. -Learn more in our [Clawback guide](../build/guides/transactions/clawbacks.mdx). +Learn more in our [Clawbacks guide](../build/guides/transactions/clawbacks.mdx). ### Composable Data Platform {/* #cdp */} @@ -111,6 +117,8 @@ Makes a payment to a 0-balance public key (Stellar address), thereby creating th A payment that automatically handles the conversion of dissimilar assets. +Learn more in our [Path Payments guide](../build/guides/transactions/path-payments.mdx). + ### Custom Token This term has been deprecated in favor of [contract tokens](#contract-token). @@ -119,7 +127,7 @@ This term has been deprecated in favor of [contract tokens](#contract-token). A distributed exchange that allows the trading and conversion of assets on the network. -Learn more in our [Liquidity on Stellar](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx#sdex) section. +Learn more in our [Liquidity on Stellar section](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx#sdex). ### External Data Representation (XDR) @@ -129,7 +137,7 @@ The type of encoding used for operations and data running on stellar-core. The Stellar federation protocol maps Stellar addresses to an email-like identifier that provides more information about a given user. It’s a way for Stellar client software to resolve email-like addresses such as name\*yourdomain.com into `G...` account IDs. Federated addresses provide an easy way for users to share payment details by using a syntax that interoperates across different domains and providers. -Read more in [GitHub](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0002.md). +Learn more about federation in [SEP-2](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0002.md). ### Flags @@ -139,7 +147,7 @@ Flags control access to an asset on the account level. Learn more about flags in An automated test that rapidly stuffs massive amounts of randomized, malformed data into a system to reveal adverse or unexpected results that indicate vulnerabilities. -Read more in the [Fuzz Testing Tutorial](../build/smart-contracts/example-contracts/fuzzing.mdx). +Learn more in the [Fuzz Testing tutorial](../build/smart-contracts/example-contracts/fuzzing.mdx). ### GitHub @@ -147,7 +155,9 @@ An online repository for documents that can be accessed and shared among multipl ### Home Domain -A fully qualified domain name (FQDN) linked to a Stellar account, used to generate an on-chain link to a Stellar Info File, which holds off-chain metadata. See the Set Options operation. Can be up to 32 characters. +A fully qualified domain name (FQDN) linked to a Stellar account, used to generate an on-chain link to a Stellar Info File, which holds off-chain metadata. The domain can be up to 32 characters. To set or update it, include the domain in the Set Options operation's `homeDomain` field; the network stores it on the account entry. + +Learn more about the [Set Options operation](./fundamentals/transactions/list-of-operations.mdx#set-options). ### Inflation @@ -193,7 +203,7 @@ Learn more about lumens in our [Lumens section](./fundamentals/lumens.mdx). The Stellar Public Network, aka mainnet, the main network used by applications in production. -Read more in our [Networks section](../networks/README.mdx). +Learn more in our [Networks section](../networks/README.mdx). ### Master key @@ -217,7 +227,7 @@ The number of entries owned by an account, used to calculate the account’s min An individual command that modifies the ledger. -Learn more in our [Operations and Transactions](./fundamentals/transactions/operations-and-transactions.mdx) section. +Learn more in our [Operations and Transactions section](./fundamentals/transactions/operations-and-transactions.mdx). ### OperationID @@ -233,12 +243,14 @@ Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools section](./fun A record of outstanding orders on the Stellar network. -Learn more in our [Liquidity on Stellar: SDEX and Liquidity Pools section](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx#order-books). +Learn more in our [Liquidity on Stellar section](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx#order-books). ### Passive Order An order that does not execute against a marketable counter order with the same price; filled only if the prices are not equal. +Learn more in our [Liquidity on Stellar section](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx). + ### Passphrase The Mainnet and Testnet each have their own unique passphrase, which are used to validate signatures on a given transaction. @@ -259,12 +271,14 @@ Allows two parties who frequently transact with one another to move the bulk of Optional requirements you can add to control a transaction’s validity. -See the [Operation and Transaction Validity section](./fundamentals/transactions/operations-and-transactions.mdx#preconditions) for more information. +Learn more in the [Operation and Transaction Validity section](./fundamentals/transactions/operations-and-transactions.mdx#preconditions). ### Price The ratio of the quote asset and the base asset in an order. +Learn more in our [Liquidity on Stellar section](./fundamentals/liquidity-on-stellar-sdex-liquidity-pools.mdx). + ### Public Key The public part of a keypair that identifies a Stellar account. The public key is public- it is visible on the ledger, anyone can look it up, and it is used when sending payments to the account, identifying the issuer of an asset, and verifying that a transaction is authorized. @@ -283,7 +297,7 @@ A transaction’s sequence number must always increase by one (unless minimum se Refers to the master key or to any other signing keys added later. A signer is defined as the pair: public key + weight. Signers can be set with the Set Options operation. -See our [Signatures and Multisig section](./fundamentals/transactions/signatures-multisig.mdx) for more information. +Learn more in our [Signatures and Multisig section](./fundamentals/transactions/signatures-multisig.mdx). ### Smart Contract @@ -309,7 +323,7 @@ A decentralized, federated peer-to-peer network that allows people to send payme Provides a way to reach consensus without relying on a closed system to accurately record financial transactions. -See our [SCP section](./fundamentals/stellar-consensus-protocol.mdx) to learn more. +Learn more in our [SCP section](./fundamentals/stellar-consensus-protocol.mdx). ### Stellar Core @@ -325,6 +339,8 @@ Learn more in our [Liquidity on Stellar section](./fundamentals/liquidity-on-ste A non-profit organization founded to support the development and growth of the Stellar network. +Learn more on the [SDF website](https://stellar.org/foundation). + ### Stellar Ecosystem Proposals (SEPs) {/* #seps */} Standards and protocols to allow the Stellar ecosystem to interoperate. @@ -337,7 +353,7 @@ A node that provides an interface for submitting transactions and reading data f ### Stellar.toml {/* #stellar-toml */} -A formatted configuration file containing published information about a node and an organization. For more, see the [Stellar Info File spec (SEP-0001)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md). +A formatted configuration file containing published information about a node and an organization. For more, learn more in the [Stellar Info File spec (SEP-0001)](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md). ### Stroop @@ -347,7 +363,7 @@ As cents are to dollars, stroops are to assets: the smallest unit of an asset, o The Stellar Test Network is maintained by the Stellar Development Foundation, which developers can use to test applications. Testnet is free to use and provides the same functionality as the main (public) network. -Read more in our [Networks](../networks/README.mdx). +Learn more in our [Networks section](../networks/README.mdx). ### Threshold @@ -355,7 +371,7 @@ The level of access for an operation. Also used to describe the ratio of validator nodes in a quorum set that must agree in order to reach consensus as part of the Stellar Consensus Protocol. -Read more about operation thresholds in the [Operations and Transactions section](./fundamentals/transactions/operations-and-transactions.mdx#operations). +Learn more about operation thresholds in the [Operations and Transactions section](./fundamentals/transactions/operations-and-transactions.mdx#operations). Learn more about quorum set validators in our [Stellar Consensus Protocol section](./fundamentals/stellar-consensus-protocol.mdx). @@ -363,13 +379,13 @@ Learn more about quorum set validators in our [Stellar Consensus Protocol sectio An optional feature you can apply to a transaction to enforce a time limit on the transaction; either the transaction makes it to the ledger or times out (fails) depending on your time parameters. -Read more about time bounds in our [Operation and Transaction Validity section](./fundamentals/transactions/operations-and-transactions.mdx#transaction-and-operation-validity). +Learn more about time bounds in our [Operation and Transaction Validity section](./fundamentals/transactions/operations-and-transactions.mdx#transaction-and-operation-validity). ### Transaction A group of 1 to 100 operations that modify the ledger state. -Read more in the [Operations and Transactions section](./fundamentals/transactions/operations-and-transactions.mdx#transactions). +Learn more in the [Operations and Transactions section](./fundamentals/transactions/operations-and-transactions.mdx#transactions). ### Transaction Envelope @@ -391,7 +407,7 @@ Learn more in our [Accounts section](./fundamentals/stellar-data-structures/acco A smart contract's TTL is how many ledgers remain until the data entry is no longer live. -Read more in the [State Archival section](./fundamentals/contract-development/storage/state-archival.mdx#ttl). +Learn more in the [State Archival section](./fundamentals/contract-development/storage/state-archival.mdx#ttl). ### Type @@ -412,3 +428,5 @@ An interface that gives a user access to an account stored on the ledger; that a ### XLM (lumens) The native currency of the Stellar network. + +Learn more in the [Lumen Supply Metrics section](./fundamentals/lumens.mdx#lumen-supply-metrics). diff --git a/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx b/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx index 0cbb1f2483..a249a39966 100644 --- a/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx +++ b/docs/learn/migrate/evm/solidity-and-rust-advanced-concepts.mdx @@ -542,7 +542,7 @@ In contrast to Solidity's global variables, Soroban relies on passing an [`Env`] The `Env` provides access to information about the currently executing contract, who invoked it, contract data, functions for signing, hashing, etc. -For instance, you would use `env.storage().persistent().get(key)` to access a `persistent` target value from the contract's [storage](https://docs.rs/soroban-sdk/latest/soroban_sdk/struct.Env.html). Read more about the different storage types [here](../../fundamentals/contract-development/storage/persisting-data.mdx). +For instance, you would use `env.storage().persistent().get(key)` to access a `persistent` target value from the contract's [storage](https://docs.rs/soroban-sdk/latest/soroban_sdk/struct.Env.html). Learn more about the different storage types in the [Persisting Data section](../../fundamentals/contract-development/storage/persisting-data.mdx). - `env.storage()` is used to get a struct for accessing and updating contract data that has been stored. - Used as `env.storage().persistent().get()` or `env.persistent().storage().set()`. diff --git a/docs/networks/README.mdx b/docs/networks/README.mdx index fa73ef3240..3b9f343279 100644 --- a/docs/networks/README.mdx +++ b/docs/networks/README.mdx @@ -32,7 +32,7 @@ Stellar has three networks: the public network (Mainnet, also called Pubnet or t | **Friendbot API** | N/A | `https://friendbot.stellar.org` | `https://friendbot-futurenet.stellar.org` | | **History Archive** | `http://history.stellar.org/prd/core-live/core_live_001/`, `http://history.stellar.org/prd/core-live/core_live_002/`, `http://history.stellar.org/prd/core-live/core_live_003/` | `http://history.stellar.org/prd/core-testnet/core_testnet_001`, `http://history.stellar.org/prd/core-testnet/core_testnet_002`, `http://history.stellar.org/prd/core-testnet/core_testnet_003` ([more info](https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_testnet.cfg)) | `http://history.stellar.org/dev/core-futurenet/core_futurenet_001/`, `http://history.stellar.org/dev/core-futurenet/core_futurenet_002/`, `http://history.stellar.org/dev/core-futurenet/core_futurenet_003/` | -\*Values as of July 2026. These limits are set by validator vote and can change over time — check the current values on Stellar Lab's [Network Limits](https://lab.stellar.org/network-limits) page, or see [Resource Limits & Fees](./resource-limits-fees.mdx) for other ways to query them live. The precise smart contract capacity per ledger can also vary based on [resource limits](../learn/fundamentals/fees-resource-limits-metering.mdx#resource-limitations). See [Fees and Metering](../learn/fundamentals/fees-resource-limits-metering.mdx) for detailed smart contract network settings. +\*Values as of July 2026. These limits are set by validator vote and can change over time — check the current values on Stellar Lab's [Network Limits](https://lab.stellar.org/network-limits) page, or learn more in [Resource Limits & Fees](./resource-limits-fees.mdx) for other ways to query them live. The precise smart contract capacity per ledger can also vary based on [resource limits](../learn/fundamentals/fees-resource-limits-metering.mdx#resource-limitations). Learn more in [Fees and Metering](../learn/fundamentals/fees-resource-limits-metering.mdx) for detailed smart contract network settings. ## Friendbot diff --git a/docs/networks/resource-limits-fees.mdx b/docs/networks/resource-limits-fees.mdx index 01906df444..8423cebe16 100644 --- a/docs/networks/resource-limits-fees.mdx +++ b/docs/networks/resource-limits-fees.mdx @@ -17,4 +17,4 @@ You can also query current network settings directly from the command line using stellar network settings ``` -For more details on using this command, see the [Stellar CLI documentation](https://developers.stellar.org/docs/tools/cli/stellar-cli#stellar-network-settings). +Learn more about using this command in the [Stellar CLI documentation](https://developers.stellar.org/docs/tools/cli/stellar-cli#stellar-network-settings). diff --git a/docs/networks/software-versions.mdx b/docs/networks/software-versions.mdx index 1ec1127328..5061bc6a97 100644 --- a/docs/networks/software-versions.mdx +++ b/docs/networks/software-versions.mdx @@ -225,7 +225,7 @@ New features in X-Ray, Protocol 25: ### Release notes -Protocol 24 is a stability upgrade following Whisk (Protocol 23). Read more about the upgrade here: +Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade: - [Release Notes](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0076.md) - [Stability Upgrade After Whisk](https://stellar.org/blog/developers/addressing-state-archival-inconsistencies-protocol-upgrade-vote-next-week) @@ -258,7 +258,7 @@ Protocol 24 is a stability upgrade following Whisk (Protocol 23). Read more abou ### Release notes -Protocol 24 is a stability upgrade following Whisk (Protocol 23). Read more about the upgrade here: +Protocol 24 is a stability upgrade following Whisk (Protocol 23). Learn more about the upgrade: - [Stability Upgrade After Whisk](https://stellar.org/blog/developers/addressing-state-archival-inconsistencies-protocol-upgrade-vote-next-week) @@ -1693,7 +1693,7 @@ This release includes a major overhaul of the value representation at the XDR le - Added `String` which is a `Bytes`-like object but displays as text - Enhanced `Symbol` to have a maximum size of 32 bytes (no more 10-char limit) -SDK support has also been added/updated for these types. See [xdr](https://github.com/stellar/stellar-xdr/pull/70), [env](https://github.com/stellar/rs-soroban-env/pull/682) and [sdk](https://github.com/stellar/rs-soroban-sdk/pull/879) changes for more details. +SDK support has also been added/updated for these types. Learn more in the [XDR](https://github.com/stellar/stellar-xdr/pull/70), [environment](https://github.com/stellar/rs-soroban-env/pull/682), and [SDK](https://github.com/stellar/rs-soroban-sdk/pull/879) changes. ### Changelog diff --git a/docs/platforms/anchor-platform/CONTRIBUTING.md b/docs/platforms/anchor-platform/CONTRIBUTING.md index bf1c8dd94b..fb3fbced9c 100644 --- a/docs/platforms/anchor-platform/CONTRIBUTING.md +++ b/docs/platforms/anchor-platform/CONTRIBUTING.md @@ -185,7 +185,8 @@ This should help to make it a bit clearer. > `/platforms/stellar-disbursement-platform` plugin instance in the above > examples, and it all works pretty much identically. -Read more about links [here](https://docusaurus.io/docs/markdown-features/links) +Learn more in the +[Docusaurus links documentation](https://docusaurus.io/docs/markdown-features/links) (especially toward the bottom of the page). ## Directories to Know diff --git a/docs/platforms/anchor-platform/admin-guide/architecture.mdx b/docs/platforms/anchor-platform/admin-guide/architecture.mdx index 47f604d648..52551e87cf 100644 --- a/docs/platforms/anchor-platform/admin-guide/architecture.mdx +++ b/docs/platforms/anchor-platform/admin-guide/architecture.mdx @@ -57,7 +57,7 @@ In addition to the components described above, the Anchor Platform includes seve #### Event Service -The event service enables the Anchor Platform to send HTTP webhooks to registered clients and your business server when the state of transactions change, removing the need for clients and/or your business server to poll the Anchor Platform's APIs. It works by reading events from published to a Kafka topic by the other Anchor Platform components. [Read more][events] about using the event service. +The event service enables the Anchor Platform to send HTTP webhooks to registered clients and your business server when the state of transactions change, removing the need for clients and/or your business server to poll the Anchor Platform's APIs. It works by reading events from published to a Kafka topic by the other Anchor Platform components. Learn more about using the [event service][events]. #### Payment Observer diff --git a/docs/platforms/anchor-platform/admin-guide/assets-and-client-wallets.mdx b/docs/platforms/anchor-platform/admin-guide/assets-and-client-wallets.mdx index a7b263fa2e..93597bcb36 100644 --- a/docs/platforms/anchor-platform/admin-guide/assets-and-client-wallets.mdx +++ b/docs/platforms/anchor-platform/admin-guide/assets-and-client-wallets.mdx @@ -11,7 +11,7 @@ This guide covers how to configure assets and wallet clients in the Anchor Platf Assets define the tokens and currencies that your Anchor Platform supports for deposits and withdrawals. In the "Getting Started" guide, assets are configured in the `config/assets.yaml` file by the `ap_start.sh`. -For the complete list of fields and defaults, see the [asset configuration reference](https://github.com/stellar/anchor-platform/blob/develop/core/src/main/resources/config/anchor-asset-default-values.yaml). +For the complete list of fields and defaults, learn more in the [asset configuration reference](https://github.com/stellar/anchor-platform/blob/develop/core/src/main/resources/config/anchor-asset-default-values.yaml). ### Example Asset Configuration @@ -66,7 +66,7 @@ items: Wallet clients are the wallet apps that connect to your Anchor Platform to perform transactions on behalf of users. -For the full list of client fields and defaults, see the [client configuration reference](https://github.com/stellar/anchor-platform/blob/main/platform/src/main/resources/config/anchor-client-default-values.yaml). +For the full list of client fields and defaults, learn more in the [client configuration reference](https://github.com/stellar/anchor-platform/blob/main/platform/src/main/resources/config/anchor-client-default-values.yaml). ### Example Client Configuration diff --git a/docs/platforms/anchor-platform/admin-guide/events/integration.mdx b/docs/platforms/anchor-platform/admin-guide/events/integration.mdx index 8b9f7527f4..0c6da3f5aa 100644 --- a/docs/platforms/anchor-platform/admin-guide/events/integration.mdx +++ b/docs/platforms/anchor-platform/admin-guide/events/integration.mdx @@ -36,7 +36,7 @@ events: -Anchor Platform allows a subset of the Kafka producer's client configuration to be set. See the [default values file][default-values-file] for more information what is available. For more information on the Kafka producer's client configuration, see the [Kafka documentation](https://kafka.apache.org/documentation/#producerconfigs). +Anchor Platform allows a subset of the Kafka producer's client configuration to be set. Learn more about the available options in the [default values file][default-values-file]. Learn more about the Kafka producer's client configuration in the [Kafka documentation](https://kafka.apache.org/documentation/#producerconfigs). Next, the event processor needs to be configured in the `event_processor` section of the Anchor Platform Configuration file or setting the environment variables. @@ -71,7 +71,7 @@ Client applications can receive updates about their users' transactions and cust To receive events as a client application, you will need to expose callback URLs that the event service can send events to. The event service will send a POST request to this endpoint with the event data in the request body. The schema of the event data will depend on the type of event being sent. Anchor Platform allows unique endpoints to be configured by event type. -Anchor Platform will only send events to clients listed in the client configuration. See the [client configuration documentation][clients-config] for more information. +Anchor Platform will only send events to clients listed in the client configuration. Learn more in the [client configuration documentation][clients-config]. #### Callback Signing diff --git a/docs/platforms/anchor-platform/admin-guide/getting-started.mdx b/docs/platforms/anchor-platform/admin-guide/getting-started.mdx index b2f310c358..423f675ff1 100644 --- a/docs/platforms/anchor-platform/admin-guide/getting-started.mdx +++ b/docs/platforms/anchor-platform/admin-guide/getting-started.mdx @@ -66,7 +66,7 @@ The `quick-run` setup includes: :::tip -For more information about configuring assets and client wallets, see the [Assets and Client Wallets](./assets-and-client-wallets.mdx) guide. +Learn more about configuring assets and client wallets in the [Assets and Client Wallets](./assets-and-client-wallets.mdx) guide. ::: diff --git a/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx b/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx index 544a5413ec..d97373264d 100644 --- a/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx +++ b/docs/platforms/anchor-platform/api-reference/platform/rpc/overview.mdx @@ -13,4 +13,4 @@ All member names exchanged between the Client and the Server that are considered ::: -You can read more about JSON-RPC protocol [here](https://www.jsonrpc.org/specification). +Learn more in the [JSON-RPC specification](https://www.jsonrpc.org/specification). diff --git a/docs/platforms/anchor-platform/sep-guide/sep1/README.mdx b/docs/platforms/anchor-platform/sep-guide/sep1/README.mdx index 22a8beebdd..bbbe9dcc8b 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep1/README.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep1/README.mdx @@ -36,7 +36,7 @@ ORG_DESCRIPTION = "A description of your organization" :::tip -For a complete list of all available `stellar.toml` attributes, see the [SEP-1 specification][sep-1]. You'll need to add additional sections like `[[CURRENCIES]]`, `TRANSFER_SERVER`, `TRANSFER_SERVER_SEP0024`, `WEB_AUTH_ENDPOINT`, `WEB_AUTH_FOR_CONTRACTS_ENDPOINT`, `DIRECT_PAYMENT_SERVER` etc., as you configure the supported assets and other SEPs. +For a complete list of all available `stellar.toml` attributes, learn more in the [SEP-1 specification][sep-1]. You'll need to add additional sections like `[[CURRENCIES]]`, `TRANSFER_SERVER`, `TRANSFER_SERVER_SEP0024`, `WEB_AUTH_ENDPOINT`, `WEB_AUTH_FOR_CONTRACTS_ENDPOINT`, `DIRECT_PAYMENT_SERVER` etc., as you configure the supported assets and other SEPs. ::: diff --git a/docs/platforms/anchor-platform/sep-guide/sep10/README.mdx b/docs/platforms/anchor-platform/sep-guide/sep10/README.mdx index 55981438fe..8f3c042110 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep10/README.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep10/README.mdx @@ -7,7 +7,7 @@ sidebar_position: 60 SEP-10 (Stellar Web Authentication) enables wallet applications to create authenticated sessions with Stellar anchors by proving control over a Stellar account. Once authenticated, wallets receive a JSON Web Token (JWT) that they use in subsequent requests to the anchor's standardized services. -For the complete specification, see [SEP-0010: Stellar Web Authentication](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md). +For the complete specification, learn more in [SEP-0010: Stellar Web Authentication](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md). The Anchor Platform implements SEP-10 with support for: @@ -256,7 +256,7 @@ The JWT token should be included in subsequent API requests as a Bearer token in :::tip -**Testing Your Configuration**: You can test SEP-10 authentication using curl and Stellar CLI. For more information about Stellar CLI, see the [Stellar CLI documentation](../../../../tools/cli/README.mdx). +**Testing Your Configuration**: You can test SEP-10 authentication using curl and Stellar CLI. Learn more about Stellar CLI in the [Stellar CLI documentation](../../../../tools/cli/README.mdx). ```bash # Verify if `stellar` command line is installed diff --git a/docs/platforms/anchor-platform/sep-guide/sep24/integration.mdx b/docs/platforms/anchor-platform/sep-guide/sep24/integration.mdx index 3e514f5f8a..e44c97cc88 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep24/integration.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep24/integration.mdx @@ -27,7 +27,7 @@ This is done by making JSON-RPC requests to the Platform API's endpoint. JSON-RP The Anchor Platform JSON-RPC API is designed to notify the platform about changes in the status of the transaction. Given that, the API will be called every time a user or the anchor takes any action that progresses the transaction status in the flow. -Communication from the Anchor Platform about transaction updates, customer updates, and quote creation is handled through the event service. This is an optional feature that needs to be configured separately from the SEP-6 integration. For more information, see [Event Handling][event-handling]. +Communication from the Anchor Platform about transaction updates, customer updates, and quote creation is handled through the event service. This is an optional feature that needs to be configured separately from the SEP-6 integration. Learn more in [Event Handling][event-handling]. You can find out more about transaction flow and statuses in the [SEP-24 protocol document][sep-24] @@ -898,23 +898,23 @@ To execute this, you need to run: ### Refund Sent -The refund logic works in the same way as for the deposit flow. For more details, see [Refund Sent](#refund-sent) of the deposit flow. +The refund logic works in the same way as for the deposit flow. Learn more in [Refund Sent](#refund-sent) of the deposit flow. ### Transaction Error -Works in the same manner as for the deposit flow. For more details, see [Transaction Error](#transaction-error) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Transaction Error](#transaction-error) of the deposit flow. ### Expired Transaction -Works in the same manner as for the deposit flow. For more details, see [Expired Transaction](#expired-transaction) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Expired Transaction](#expired-transaction) of the deposit flow. ### On-Hold Transaction -Works in the same manner as for the deposit flow. For more details, see [On-Hold Transaction](#on-hold-transaction) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [On-Hold Transaction](#on-hold-transaction) of the deposit flow. ### Transaction Recovery -Works in the same manner as for the deposit flow. For more details, see [Transaction Recovery](#transaction-recovery) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Transaction Recovery](#transaction-recovery) of the deposit flow. ## Tracking Stellar Transactions diff --git a/docs/platforms/anchor-platform/sep-guide/sep31/configuration.mdx b/docs/platforms/anchor-platform/sep-guide/sep31/configuration.mdx index 05dab1a9d6..c2c584b398 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep31/configuration.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep31/configuration.mdx @@ -122,7 +122,7 @@ You should get the following. Businesses need to collect and validate KYC information on the customers they're facilitating transactions for. Clients determine what KYC information needs to be collected and send that information via a SEP-12 KYC API hosted by the Anchor Platform, but the Anchor Platform never stores personally-identifiable information (PII). Instead, it forwards requests from clients to the business server, and returns the business' responses back to the client, acting as a proxy server. -See the [Anchor Platform KYC API specification][platform-api-kyc] for details on the endpoints that must be implemented on your business' server. +Learn more in the [Anchor Platform KYC API specification][platform-api-kyc] for details on the endpoints that must be implemented on your business' server. To make this API available to clients, lets add the service URL to our Stellar Info File. diff --git a/docs/platforms/anchor-platform/sep-guide/sep45/README.mdx b/docs/platforms/anchor-platform/sep-guide/sep45/README.mdx index 4800dc9fff..9802185b45 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep45/README.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep45/README.mdx @@ -7,7 +7,7 @@ sidebar_position: 70 SEP-45 (Stellar Web Authentication for Contract Accounts) enables smart wallet applications to create authenticated sessions with Stellar anchors by proving control over a contract account (`C...`). Once authenticated, wallets receive a JSON Web Token (JWT) that they use in subsequent requests to the anchor's standardized services. -For the complete specification, see [SEP-0045: Stellar Web Authentication for Contract Accounts][sep-45]. +For the complete specification, learn more in [SEP-0045: Stellar Web Authentication for Contract Accounts][sep-45]. The Anchor Platform implements SEP-45 with support for: diff --git a/docs/platforms/anchor-platform/sep-guide/sep6/configuration.mdx b/docs/platforms/anchor-platform/sep-guide/sep6/configuration.mdx index 57252eb139..b15898ddf9 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep6/configuration.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep6/configuration.mdx @@ -152,7 +152,7 @@ SECRET_CALLBACK_API_AUTH_SECRET="a secret used to sign JWTs" The above tells the Anchor Platform to include a [JWT][how-to-use-jwt], signed with the configured secret, in the `Authorization` header of requests made to `/callbacks/` so your server can authenticate the Anchor Platform before processing requests. -See the [KYC API][platform-api-kyc] and [Rates API][get-rates-api] for details on the endpoints that must be implemented on your business server. +Learn more in the [KYC API][platform-api-kyc] and [Rates API][get-rates-api] for details on the endpoints that must be implemented on your business server. ### Additional Optional Configuration @@ -168,7 +168,7 @@ SECRET_SEP6_MORE_INFO_URL_JWT_SECRET="your encryption key shared with your busin -Businesses can set a deadline for user actions on transactions using the `user_action_required_by` field. For examples, see [JSON-RPC Methods][json-rpc-methods]. In addition, the `initial_user_deadline_seconds` parameter sets a default time (in seconds) a user has to act before the transaction moves into the `EXPIRED` status. +Businesses can set a deadline for user actions on transactions using the `user_action_required_by` field. For examples, learn more in [JSON-RPC Methods][json-rpc-methods]. In addition, the `initial_user_deadline_seconds` parameter sets a default time (in seconds) a user has to act before the transaction moves into the `EXPIRED` status. diff --git a/docs/platforms/anchor-platform/sep-guide/sep6/integration.mdx b/docs/platforms/anchor-platform/sep-guide/sep6/integration.mdx index 8e621ee803..a2d74a319e 100644 --- a/docs/platforms/anchor-platform/sep-guide/sep6/integration.mdx +++ b/docs/platforms/anchor-platform/sep-guide/sep6/integration.mdx @@ -28,7 +28,7 @@ This is done by making JSON-RPC requests to the Platform API's endpoint. JSON-RP The Anchor Platform JSON-RPC API is designed to notify the platform about changes in the status of the transaction. Given that, the API will be called every time a user or the anchor takes any action that progresses the transaction status in the flow. -Communication from the Anchor Platform about transaction updates, customer updates, and quote creation is handled through the event service. This is an optional feature that needs to be configured separately from the SEP-6 integration. For more information, see [Event Handling][event-handling]. +Communication from the Anchor Platform about transaction updates, customer updates, and quote creation is handled through the event service. This is an optional feature that needs to be configured separately from the SEP-6 integration. Learn more in [Event Handling][event-handling]. You can find out more about transaction flow and statuses in the [SEP-6 protocol document][sep-6]. @@ -872,19 +872,19 @@ To execute this, you need to run: ### Refund Sent -The refund logic works in the same way as for the deposit flow. For more details, see [Refund Sent](#refund-sent) of the deposit flow. +The refund logic works in the same way as for the deposit flow. Learn more in [Refund Sent](#refund-sent) of the deposit flow. ### Transaction Error -Works in the same manner as for the deposit flow. For more details, see [Transaction Error](#transaction-error) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Transaction Error](#transaction-error) of the deposit flow. ### Expired Transaction -Works in the same manner as for the deposit flow. For more details, see [Expired Transaction](#expired-transaction) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Expired Transaction](#expired-transaction) of the deposit flow. ### Transaction Recovery -Works in the same manner as for the deposit flow. For more details, see [Transaction Recovery](#transaction-recovery) of the deposit flow. +Works in the same manner as for the deposit flow. Learn more in [Transaction Recovery](#transaction-recovery) of the deposit flow. ## Tracking Stellar Transactions diff --git a/docs/platforms/stellar-disbursement-platform/admin-guide/advanced-configuration.mdx b/docs/platforms/stellar-disbursement-platform/admin-guide/advanced-configuration.mdx index 4c67b22ecf..1b2b13eb72 100644 --- a/docs/platforms/stellar-disbursement-platform/admin-guide/advanced-configuration.mdx +++ b/docs/platforms/stellar-disbursement-platform/admin-guide/advanced-configuration.mdx @@ -219,7 +219,7 @@ Once a tenant is created, the `distribution_account_type` cannot be changed. If Embedded Wallets allow receivers to receive disbursements without downloading a separate wallet application. Instead, the SDP creates lightweight, passkey-secured smart contract wallets on the Stellar network. This feature requires configuration across the SDP backend, Transaction Submission Service (TSS), and frontend dashboard. -For a complete guide on using Embedded Wallets, see the [Embedded Wallets](./embedded-wallets) documentation. +For a complete guide on using Embedded Wallets, learn more in the [Embedded Wallets](./embedded-wallets) documentation. ### Overview diff --git a/docs/platforms/stellar-disbursement-platform/admin-guide/embedded-wallets.mdx b/docs/platforms/stellar-disbursement-platform/admin-guide/embedded-wallets.mdx index 259239e195..d800da2ef2 100644 --- a/docs/platforms/stellar-disbursement-platform/admin-guide/embedded-wallets.mdx +++ b/docs/platforms/stellar-disbursement-platform/admin-guide/embedded-wallets.mdx @@ -102,13 +102,13 @@ When a receiver logs in with their passkey, several things happen: Before using Embedded Wallets, ensure your SDP instance is properly configured: -1. **Backend Configuration**: Embedded Wallets require specific environment variables to be set. See the [Embedded Wallets Configuration](./advanced-configuration#embedded-wallets-configuration) section in the Advanced Configuration guide. +1. **Backend Configuration**: Embedded Wallets require specific environment variables to be set. Learn more in the [Embedded Wallets Configuration](./advanced-configuration#embedded-wallets-configuration) section in the Advanced Configuration guide. 2. **Frontend HTTPS Requirement**: The frontend dashboard **must** be served over HTTPS for passkeys to work. WebAuthn requires a secure context and will not function over plain HTTP. 3. **Network Selection**: Deploy the SEP-45 contract and the embedded wallet Wasm. -For detailed configuration instructions, see the [Embedded Wallets Configuration](./advanced-configuration#embedded-wallets-configuration) section. +For detailed configuration instructions, learn more in the [Embedded Wallets Configuration](./advanced-configuration#embedded-wallets-configuration) section. --- @@ -205,7 +205,7 @@ The verification step ensures that the receiver is who they claim to be. Dependi The verification process uses the SDP's native SEP-24 implementation. The receiver authenticates with a SEP-24 JWT token that's generated during the passkey authentication flow. -For background on SEP-45 (contract-account web authentication), see [SEP-0045](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0045.md). +For background on SEP-45 (contract-account web authentication), learn more in [SEP-0045](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0045.md). ::: diff --git a/docs/platforms/stellar-disbursement-platform/admin-guide/troubleshooting.mdx b/docs/platforms/stellar-disbursement-platform/admin-guide/troubleshooting.mdx index 4dd2106c21..aa30288c1f 100644 --- a/docs/platforms/stellar-disbursement-platform/admin-guide/troubleshooting.mdx +++ b/docs/platforms/stellar-disbursement-platform/admin-guide/troubleshooting.mdx @@ -76,7 +76,7 @@ The receiver's account hasn't been created on the Stellar network. The account m -Channel accounts may disappear after testnet resets. See [Recreating Channel Accounts](#recreating-channel-accounts) below. +Channel accounts may disappear after testnet resets. Learn more in [Recreating Channel Accounts](#recreating-channel-accounts). @@ -132,7 +132,7 @@ Extras=transaction: tx_fee_bump_inner_failed - inner transaction: tx_failed - op **Solution:** The receiver must add a trustline for the asset before the payment can succeed. Once they've done so, use the **Retry** button in the dashboard to resubmit the payment. -For a complete list of operation result codes, see the [Stellar documentation](https://developers.stellar.org/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/payment). +For a complete list of operation result codes, learn more in the [Stellar documentation](https://developers.stellar.org/docs/data/apis/horizon/api-reference/errors/result-codes/operation-specific/payment). --- @@ -261,7 +261,7 @@ If you see the receiver's attempted contact info here, it means: #### 2. Check for Provider Issues -If the contact info matches but the OTP still isn't arriving, the issue is likely with the messaging provider. See [Check SDP Logs for Submission Failures](#check-logs-submission-failures) above for common provider issues and how to diagnose them. +If the contact info matches but the OTP still isn't arriving, the issue is likely with the messaging provider. Learn more about common provider issues and how to diagnose them in [Check SDP Logs for Submission Failures](#check-logs-submission-failures). --- diff --git a/docs/tokens/README.mdx b/docs/tokens/README.mdx index 523b489a7b..b2e3d85d1e 100644 --- a/docs/tokens/README.mdx +++ b/docs/tokens/README.mdx @@ -50,7 +50,7 @@ Assets issued on the Stellar network are accessible to smart contracts with the The Stellar Asset Contract (SAC) is compiled into the protocol layer and allows smart contracts to interact with assets issued on Stellar. An instance of the SAC can be deployed for every Stellar asset by anyone who wants to interact with the asset from a contract. The SAC has access to all account balances (for XLM) and trustline balances (for all other assets) as well as smart contract token balances. -Read more about the SAC [here][sac]. +Learn more in the [Stellar Asset Contract section][sac]. Learn how to deploy a Stellar Asset Contract for an asset in [this How-To Guide](../tools/cli/cookbook/deploy-stellar-asset-contract.mdx). diff --git a/docs/tokens/anatomy-of-an-asset.mdx b/docs/tokens/anatomy-of-an-asset.mdx index 39a45e3b8f..58b705f64d 100644 --- a/docs/tokens/anatomy-of-an-asset.mdx +++ b/docs/tokens/anatomy-of-an-asset.mdx @@ -48,7 +48,7 @@ All assets issued by Stellar accounts (G…` addresses) are **Stellar Assets**. ### How they work -- For protocol-level behavior and trustline semantics, see [Asset Design Considerations](./control-asset-access.mdx). +- For protocol-level behavior and trustline semantics, learn more in [Asset Design Considerations](./control-asset-access.mdx). - Implemented at the protocol level, the **Stellar Asset Contract (SAC)** provides a smart contract interface that enables Stellar assets to interoperate seamlessly with Stellar smart contracts. - Transfers between accounts and contracts using SAC resolve to the same trustline balance updates the Stellar protocol has always used. - Transfers to and from a `G...` account results in the same modifications to trustline ledger entries. - Transfers to and from contracts result in updates to the token contract's data entries. @@ -189,7 +189,7 @@ The SAC has read/write access to: This allows Stellar assets to interoperate seamlessly with smart contracts. -- [Read more about the Stellar Asset Contract](./stellar-asset-contract.mdx) +- Learn more about the [Stellar Asset Contract](./stellar-asset-contract.mdx) - [How to deploy a Stellar Asset Contract](../tools/cli/cookbook/deploy-stellar-asset-contract.mdx) ### Benefits of the SAC diff --git a/docs/tokens/control-asset-access.mdx b/docs/tokens/control-asset-access.mdx index 29381d2bbe..433400b65d 100644 --- a/docs/tokens/control-asset-access.mdx +++ b/docs/tokens/control-asset-access.mdx @@ -74,7 +74,7 @@ There are three levels of authorization an asset issuer can remove using the `Se #### Clawback Enabled (0x8) -With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. You can read more about clawbacks (and selectively controlling them on a per-trustline basis) [here](../build/guides/transactions/clawbacks.mdx). +With the `AUTH_CLAWBACK_ENABLED_FLAG` flag set, any _subsequent_ trustlines established with this account will have clawbacks enabled. Learn more about clawbacks (and selectively controlling them per-trustline basis) in the [Clawbacks guide](../build/guides/transactions/clawbacks.mdx). Note that this flag requires that revocable is also set. diff --git a/docs/tokens/how-to-issue-an-asset.mdx b/docs/tokens/how-to-issue-an-asset.mdx index 4310bf34b8..1a33b101dc 100644 --- a/docs/tokens/how-to-issue-an-asset.mdx +++ b/docs/tokens/how-to-issue-an-asset.mdx @@ -19,7 +19,7 @@ If you'd like to interact with an asset issued on the Stellar network in smart c You must ensure you have the required amount of XLM to create your issuing and distribution accounts and cover the minimum balance and transaction fees. If you’re issuing an asset on the testnet, you can fund your account by getting test XLM from friendbot. If you’re issuing an asset in production, you will need to acquire XLM from another wallet or exchange. -If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Read more in our [Fee-Bump Transaction Guide](../build/guides/transactions/fee-bump-transactions.mdx). +If you’d like to avoid your users having to deal with transaction fees, consider using fee-bump transactions. Learn more in our [Fee-Bump Transaction guide](../build/guides/transactions/fee-bump-transactions.mdx). Learn about the testnet and mainnet in our [Networks section](../networks/README.mdx). @@ -84,7 +84,7 @@ Many users secure their issuing account with cold storage techniques, such as a ### Distribution account keypair -Your asset can be issued and transferred between accounts through a payment, contract, or claimable balance. Although it is not required to create a distribution account, it is best practice, so we will do so in this example. Read more in our [Issuing and Distribution Accounts section](./control-asset-access.mdx#issuing-and-distribution-accounts). +Your asset can be issued and transferred between accounts through a payment, contract, or claimable balance. Although it is not required to create a distribution account, it is best practice, so we will do so in this example. Learn more in our [Issuing and Distribution Accounts section](./control-asset-access.mdx#issuing-and-distribution-accounts). #### Three Operations @@ -194,7 +194,7 @@ Accounts must establish a [trustline](../learn/fundamentals/stellar-data-structu :::note -If you’d like to avoid your users having to deal with trustlines or XLM, consider using sponsored reserves. Read more in our [Sponsored Reserves guide](../build/guides/transactions/sponsored-reserves.mdx). +If you’d like to avoid your users having to deal with trustlines or XLM, consider using sponsored reserves. Learn more in our [Sponsored Reserves guide](../build/guides/transactions/sponsored-reserves.mdx). ::: diff --git a/docs/tokens/stellar-asset-contract.mdx b/docs/tokens/stellar-asset-contract.mdx index 9f5abd9728..1c454d7538 100644 --- a/docs/tokens/stellar-asset-contract.mdx +++ b/docs/tokens/stellar-asset-contract.mdx @@ -69,7 +69,7 @@ The Stellar Asset Contract is the only way for contracts to interact with Stella The issuer of the asset will be the initial administrator of the deployed contract (administrative authority can later be moved with `set_admin`). Because the Native Stellar token doesn't have an issuer, it will not have an administrator either. It also cannot be burned. -After the contract has been deployed, users can use their classic account (for lumens) or trustline (for other assets) balance. There are some differences depending on if you are using a classic account `Address` vs a contract `Address` (corresponding either to a regular contract or to a custom account contract). The following section references some issuer and trustline flags from Stellar classic, which you can learn more about [here](./control-asset-access.mdx#controlling-access-to-an-asset-with-flags). +After the contract has been deployed, users can use their classic account (for lumens) or trustline (for other assets) balance. There are some differences depending on if you are using a classic account `Address` vs a contract `Address` (corresponding either to a regular contract or to a custom account contract). Learn more about issuer and trustline flags in the [Controlling Access to an Asset with Flags section](./control-asset-access.mdx#controlling-access-to-an-asset-with-flags). - Using `Address::Account` - The balance must exist in a trustline (or an account for the native balance). This means the contract will not store the balance in ContractData. If the trustline or account is missing, any function that tries to interact with that balance will fail (as of Yardstick, Protocol 26, a contract can create the missing trustline itself by first calling the SAC's [`trust` function](#creating-trustlines-from-a-contract)). @@ -81,11 +81,11 @@ After the contract has been deployed, users can use their classic account (for l - Using `Address::Contract` - The balance and authorization state will be stored in contract storage, as opposed to a trustline. - Balances are stored in a 128-bit signed integer. - - A balance can only be clawed back if the issuer account had the `AUTH_CLAWBACK_ENABLED_FLAG` set when the balance was created. A balance is created when either an `Address::Contract` is on the receiving end of a successful transfer, or if the admin sets the authorization state. Read more about `AUTH_CLAWBACK_ENABLED_FLAG` [here](./control-asset-access.mdx#clawback-enabled-0x8). + - A balance can only be clawed back if the issuer account had the `AUTH_CLAWBACK_ENABLED_FLAG` set when the balance was created. A balance is created when either an `Address::Contract` is on the receiving end of a successful transfer, or if the admin sets the authorization state. Learn more about `AUTH_CLAWBACK_ENABLED_FLAG` in the [Clawback Enabled section](./control-asset-access.mdx#clawback-enabled-0x8). ### Balance Authorization Required -In the `Address::Contract` case, if the issuer has `AUTH_REQUIRED_FLAG` set, then the specified `Address::Contract` will need to be explicitly authorized with `set_auth` before it can receive a balance. This logic lines up with how trustlines interact with the `AUTH_REQUIRED_FLAG` issuer flag, allowing asset issuers to have the same control in Soroban as they do in Stellar classic. Read more about `AUTH_REQUIRED_FLAG` [here](./control-asset-access.mdx#authorization-required-0x1). +In the `Address::Contract` case, if the issuer has `AUTH_REQUIRED_FLAG` set, then the specified `Address::Contract` will need to be explicitly authorized with `set_auth` before it can receive a balance. This logic lines up with how trustlines interact with the `AUTH_REQUIRED_FLAG` issuer flag, allowing asset issuers to have the same control in Soroban as they do in Stellar classic. Learn more about `AUTH_REQUIRED_FLAG` in the [Authorization Required section](./control-asset-access.mdx#authorization-required-0x1). ### Revoking Authorization @@ -95,7 +95,7 @@ The admin can only revoke authorization from an `Address`, if the issuer of the As of Yardstick, Protocol 26 ([CAP-73]), the SAC's `trust` function allows a contract to create an asset's trustline for a `G...` address as part of a contract invocation. Before Yardstick, Protocol 26, a missing trustline could only be created with a separate `changeTrust` operation, so any contract function touching a trustline balance would fail until the account holder set up the trustline in a separate transaction. -The `trust` function is useful any time a contract distributes an asset to accounts that may not hold it yet: for example, an airdrop or payout contract calling `trust` before `mint` or `transfer`, or bridging and chain abstraction flows that deliver assets to freshly created accounts. See [setting a custom SAC admin](../build/guides/tokens/custom-sac-admin.mdx) for a worked example of a contract calling `trust` before minting to a recipient. +The `trust` function is useful any time a contract distributes an asset to accounts that may not hold it yet: for example, an airdrop or payout contract calling `trust` before `mint` or `transfer`, or bridging and chain abstraction flows that deliver assets to freshly created accounts. Learn more in [setting a custom SAC admin](../build/guides/tokens/custom-sac-admin.mdx) for a worked example of a contract calling `trust` before minting to a recipient. A few things to keep in mind: @@ -105,7 +105,7 @@ A few things to keep in mind: ## Authorization semantics -See the [authorization overview](../learn/fundamentals/contract-development/authorization.mdx) and [auth example](../build/smart-contracts/example-contracts/auth.mdx) for general information about authorization in Soroban. +Learn more in the [authorization overview](../learn/fundamentals/contract-development/authorization.mdx) and [auth example](../build/smart-contracts/example-contracts/auth.mdx) for general information about authorization in Soroban. The token contract contains three kinds of operations that follow the token [interface](./token-interface.mdx#code): diff --git a/docs/tokens/token-interface.mdx b/docs/tokens/token-interface.mdx index 991ccd5ba8..1166f7fcef 100644 --- a/docs/tokens/token-interface.mdx +++ b/docs/tokens/token-interface.mdx @@ -188,7 +188,7 @@ pub trait TokenInterface { :::caution[CAUTION WHEN MODIFYING ALLOWANCES] -The `approve` function overwrites the previous value with `amount`, so it is possible for the previous allowance to be spent in an earlier transaction before `amount` is written in a later transaction. The result of this is that `spender` can spend more than intended. This issue can be avoided by first setting the allowance to 0, verifying that the spender didn't spend any portion of the previous allowance, and then setting the allowance to the new desired amount. You can read more about this issue here - https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729. +The `approve` function overwrites the previous value with `amount`, so it is possible for the previous allowance to be spent in an earlier transaction before `amount` is written in a later transaction. The result of this is that `spender` can spend more than intended. This issue can be avoided by first setting the allowance to 0, verifying that the spender didn't spend any portion of the previous allowance, and then setting the allowance to the new desired amount. Learn more about this issue in the [EIP-20 discussion](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729). ::: @@ -210,19 +210,19 @@ Code written against the shapes above will therefore mis-parse an event emitted | `set_authorized` | not part of this interface | `["set_authorized", id, sep0011_asset]` | | `set_admin` | not part of this interface | `["set_admin", admin, sep0011_asset]` | -On the Stellar Asset Contract side, the extra topic does not change the data payload: `amount: i128` for `transfer`, `mint`, `burn`, and `clawback`; `[amount: i128, live_until_ledger: u32]` for `approve`; `authorize: bool` for `set_authorized`; and `new_admin: Address` for `set_admin`. When the destination of a Stellar Asset Contract `transfer` or `mint` carries a multiplexing id, the data becomes `{ amount: i128, to_muxed_id }: Map` instead — see [Monitoring Payments as event stream](../build/guides/transactions/send-and-receive-payments.mdx#monitoring-payments-as-event-stream) for a worked example. +On the Stellar Asset Contract side, the extra topic does not change the data payload: `amount: i128` for `transfer`, `mint`, `burn`, and `clawback`; `[amount: i128, live_until_ledger: u32]` for `approve`; `authorize: bool` for `set_authorized`; and `new_admin: Address` for `set_admin`. When the destination of a Stellar Asset Contract `transfer` or `mint` carries a multiplexing id, the data becomes `{ amount: i128, to_muxed_id }: Map` instead. Learn more in [Monitoring Payments as event stream](../build/guides/transactions/send-and-receive-payments.mdx#monitoring-payments-as-event-stream), which includes a worked example. A SEP-41 contract token keeps whatever payload the interface above documents for it, so do not carry these payload shapes back across the table. :::caution[A Stellar Asset Contract transfer does not always emit a transfer event] -When the asset issuer is one side of the transfer, the contract emits a different event: `mint` if `from` is the issuer, `burn` if `to` is the issuer — and the `burn` drops any multiplexing id. You only get a `transfer` event when neither side is the issuer, or when both are. See [Interacting with classic Stellar assets](./stellar-asset-contract.mdx#interacting-with-classic-stellar-assets). +When the asset issuer is one side of the transfer, the contract emits a different event: `mint` if `from` is the issuer, `burn` if `to` is the issuer — and the `burn` drops any multiplexing id. You only get a `transfer` event when neither side is the issuer, or when both are. Learn more in [Interacting with classic Stellar assets](./stellar-asset-contract.mdx#interacting-with-classic-stellar-assets). ::: #### Telling a classic operation from a contract invocation -Since protocol 23, classic operations emit these same events, published under the asset's Stellar Asset Contract address whether or not that contract has been deployed — see [Tracking the movement of value](../learn/fundamentals/stellar-data-structures/events.mdx#tracking-the-movement-of-value). +Since protocol 23, classic operations emit these same events, published under the asset's Stellar Asset Contract address whether or not that contract has been deployed — learn more in [Tracking the movement of value](../learn/fundamentals/stellar-data-structures/events.mdx#tracking-the-movement-of-value). Not all of them, though. `approve` and `set_admin` are never emitted by a classic operation, because no classic operation is equivalent to them: allowances and contract administration exist only on the contract side. So those two always come from a contract invocation, and the rest — `transfer`, `mint`, `burn`, `clawback`, and `set_authorized` — can come from either path. diff --git a/docs/tools/cli/README.mdx b/docs/tools/cli/README.mdx index 1f8f428513..44d2c5824f 100644 --- a/docs/tools/cli/README.mdx +++ b/docs/tools/cli/README.mdx @@ -8,6 +8,6 @@ sidebar_position: 20 The command line interface to Soroban smart contracts. It allows you to build, deploy, and interact with smart contracts; configure identities; generate key pairs; manage networks; and more. -Install Stellar CLI as explained in [Setup](../../build/smart-contracts/getting-started/setup.mdx#install-the-stellar-cli). For examples on how to use the Stellar CLI, please see [Stellar CLI Guides](./cookbook/README.mdx). +Install Stellar CLI as explained in [Setup](../../build/smart-contracts/getting-started/setup.mdx#install-the-stellar-cli). For examples on how to use the Stellar CLI, learn more in the [Stellar CLI Guides](./cookbook/README.mdx). The auto-generated comprehensive reference documentation is available [here](stellar-cli.mdx). diff --git a/docs/tools/cli/install-cli.mdx b/docs/tools/cli/install-cli.mdx index 84d1afea28..35777e88af 100644 --- a/docs/tools/cli/install-cli.mdx +++ b/docs/tools/cli/install-cli.mdx @@ -86,7 +86,7 @@ echo "source <(stellar completion --shell bash)" >> ~/.bashrc ## Stellar CLI Cookbook -To understand how to get the most of the Stellar CLI, see the [Stellar CLI Cookbook](./cookbook/README.mdx) for recipes and a collection of resources to teach you how to use the CLI. Examples of recipes included in the CLI cookbook include: send payments, manage contract lifecycle, extend contract instance/storage/wasm, and more. +To understand how to get the most of the Stellar CLI, learn more in the [Stellar CLI Cookbook](./cookbook/README.mdx) for recipes and a collection of resources to teach you how to use the CLI. Examples of recipes included in the CLI cookbook include: send payments, manage contract lifecycle, extend contract instance/storage/wasm, and more. ## Video Tutorials diff --git a/docs/tools/developer-tools/wallets.mdx b/docs/tools/developer-tools/wallets.mdx index 8db712fd93..b8acfc9a14 100644 --- a/docs/tools/developer-tools/wallets.mdx +++ b/docs/tools/developer-tools/wallets.mdx @@ -5,8 +5,6 @@ sidebar_label: Wallet Integration sidebar_position: 130 --- -# Wallet Integration - ### [Stellar Wallet Kit](https://github.com/Creit-Tech/Stellar-Wallets-Kit) A simple-to-use wallet kit to manage integration to multiple Stellar ecosystem wallet. Learn more about how to integrate this library from [the Stellar Wallets Kit Docs](https://stellarwalletskit.dev). @@ -38,7 +36,7 @@ SDF’s flagship non-custodial wallet extension that allows users to sign Stella NEAR Intents is a multichain transaction protocol for wallets that allows users or AI agents to simply state the outcome they want (like swapping Token A for Token B), and then lets a network of off‑chain market makers (called solvers) compete to fulfill that request; once the best solution is selected, it is sent to the user for approval, then execution is verified and executed through a Verifier smart contract on NEAR. -Read the [docs](https://docs.near.org/chain-abstraction/intents/overview). +Learn more in the [NEAR Intents docs](https://docs.near.org/chain-abstraction/intents/overview). ### [Stellar Wallet Sponsorship Calculator](https://docs.google.com/spreadsheets/d/1LgVMFRggdjBAxSpI4nxucUmbZIsnUbMPT8RJQ_rJ5k4/edit?gid=1771515065#gid=1771515065) @@ -79,11 +77,11 @@ For developers, Blux ships with a comprehensive set of pre-built hooks and modal Learn more in the [Blux documentation](https://docs.blux.cc/). -### [Dfns](https://www.dfns.co/) +### [DFNS](https://www.dfns.co) A wallet-as-a-service platform that streamlines digital asset operations, offering full wallet feature support, including automatic detection of asset and NFT balances (when applicable), on-chain transfer history, asset transfers, transaction broadcasting, and signature generation. -View the [docs](https://docs.dfns.co/d/api-docs/wallets/broadcast-transaction/stellar). +Learn more in the [DFNS docs](https://docs.dfns.co/d/api-docs/wallets/broadcast-transaction/stellar). ### [Privy](https://docs.privy.io/wallets/overview/chains) diff --git a/docs/tools/lab/api-explorer/horizon-endpoint.mdx b/docs/tools/lab/api-explorer/horizon-endpoint.mdx index fa97f0f549..ff09e504b6 100644 --- a/docs/tools/lab/api-explorer/horizon-endpoint.mdx +++ b/docs/tools/lab/api-explorer/horizon-endpoint.mdx @@ -145,7 +145,7 @@ The Payments for Account endpoint `/accounts/:account-id/payments` provides succ ![Lab: Horizon - Payments](/assets/lab/horizon-payments.png) -When I click the **Submit** button, the endpoint returns the records of payments (see the [api reference](../../../data/apis/horizon/api-reference/get-payments-by-account-id.api.mdx) for more information on the response format) including the [payment object](../../../data/apis/horizon/api-reference/resources/payments/object.mdx) that were submitted successfully in the account in `JSON` format. +When I click the **Submit** button, the endpoint returns the account's payment records in `JSON` format, including successfully submitted [payment objects](../../../data/apis/horizon/api-reference/resources/payments/object.mdx). Learn more about the response format in the [API reference](../../../data/apis/horizon/api-reference/get-payments-by-account-id.api.mdx). ![Lab: Horizon - Payments Response](/assets/lab/horizon-payments-response.png) diff --git a/docs/tools/lab/api-explorer/rpc-methods.mdx b/docs/tools/lab/api-explorer/rpc-methods.mdx index 5f2eaeeee1..a5d9c5dff6 100644 --- a/docs/tools/lab/api-explorer/rpc-methods.mdx +++ b/docs/tools/lab/api-explorer/rpc-methods.mdx @@ -1,6 +1,6 @@ # RPC Methods -RPC methods are a set of functions that allow developers to interact directly with the Stellar network. You can learn more about all the RPC methods [here](../../../data/apis/rpc/api-reference/methods). The Lab provides an easy way to use these methods from the UI. To access the "RPC Methods" items, click on the "API Explorer" link in the main navigation, then click the "RPC Methods" submenu link, which will open another submenu listing all RPC methods by name. Click on the method name to open that page. +RPC methods are a set of functions that allow developers to interact directly with the Stellar network. Learn more in the [RPC Methods reference](../../../data/apis/rpc/api-reference/methods). The Lab provides an easy way to use these methods from the UI. To access the "RPC Methods" items, click on the "API Explorer" link in the main navigation, then click the "RPC Methods" submenu link, which will open another submenu listing all RPC methods by name. Click on the method name to open that page. :::warning diff --git a/docs/tools/lab/smart-contracts/contract-explorer.mdx b/docs/tools/lab/smart-contracts/contract-explorer.mdx index 6ab32108d6..5d847f5377 100644 --- a/docs/tools/lab/smart-contracts/contract-explorer.mdx +++ b/docs/tools/lab/smart-contracts/contract-explorer.mdx @@ -11,7 +11,7 @@ The [Contract Explorer](https://lab.stellar.org/smart-contracts/contract-explore :::warning -RPC URL is required to view the contract information. You can update or set the RPC URL in the network selector in the top right corner. See [RPC Providers](../../../data/apis/rpc/providers.mdx). +RPC URL is required to view the contract information. You can update or set the RPC URL in the network selector in the top right corner. Learn more in [RPC Providers](../../../data/apis/rpc/providers.mdx). ::: @@ -88,7 +88,7 @@ In this section, you can find the Wasm history of changes. ## Bindings -Bindings are a feature of the [Stellar CLI](../../cli) that generate fully typed client libraries for your smart contracts, tailored to your chosen programming language, including TypeScript, JSON, Rust, Python, and Java. This makes it easy to integrate Stellar contracts into your application as if they were native modules. Each binding provides type-safe functions corresponding to your contract’s methods. To learn more about generating bindings, please see the [Stellar CLI’s bindings command](../../cli/stellar-cli#stellar-contract-bindings). +Bindings are a feature of the [Stellar CLI](../../cli) that generate fully typed client libraries for your smart contracts, tailored to your chosen programming language, including TypeScript, JSON, Rust, Python, and Java. This makes it easy to integrate Stellar contracts into your application as if they were native modules. Each binding provides type-safe functions corresponding to your contract’s methods. Learn more about generating bindings in the [Stellar CLI’s bindings command](../../cli/stellar-cli#stellar-contract-bindings). ## Invoke Contract diff --git a/docs/tools/lab/transaction-dashboard.mdx b/docs/tools/lab/transaction-dashboard.mdx index b13bdf0d68..e938d778eb 100644 --- a/docs/tools/lab/transaction-dashboard.mdx +++ b/docs/tools/lab/transaction-dashboard.mdx @@ -20,7 +20,7 @@ The dashboard automatically detects whether you're viewing a classic transaction This feature uses an RPC and RPC retains at maximum 7 days of historical data. Any transaction older than 7 days will be displayed as invalid. -See [Indexers](../../data/indexers/README.mdx) and [Block Explorers](../developer-tools/block-explorers.mdx#stellarexpert) for reference +Learn more in [Indexers](../../data/indexers/README.mdx) and [Block Explorers](../developer-tools/block-explorers.mdx#stellarexpert) for reference ::: diff --git a/docs/tools/lab/view-xdr/README.mdx b/docs/tools/lab/view-xdr/README.mdx index 4ea9dc0181..bdf0d48d3c 100644 --- a/docs/tools/lab/view-xdr/README.mdx +++ b/docs/tools/lab/view-xdr/README.mdx @@ -7,6 +7,6 @@ import DocCardList from "@theme/DocCardList"; # View XDR -This section provides tools to work with [XDR](../../../learn/fundamentals/data-format/xdr.mdx) (External Data Representation) data. You can decode XDR into easy-to-read JSON format, convert JSON back into XDR format, or compare two XDR data sets to view their differences side-by-side. Learn more about XDR-JSON conversion [here](../../../learn/fundamentals/data-format/xdr-json.mdx). +This section provides tools to work with [XDR](../../../learn/fundamentals/data-format/xdr.mdx) (External Data Representation) data. You can decode XDR into easy-to-read JSON format, convert JSON back into XDR format, or compare two XDR data sets to view their differences side-by-side. Learn more about conversion in the [XDR-JSON section](../../../learn/fundamentals/data-format/xdr-json.mdx). diff --git a/docs/tools/lab/view-xdr/diff-xdr.mdx b/docs/tools/lab/view-xdr/diff-xdr.mdx index a53f6f69df..f86316a16f 100644 --- a/docs/tools/lab/view-xdr/diff-xdr.mdx +++ b/docs/tools/lab/view-xdr/diff-xdr.mdx @@ -7,9 +7,9 @@ sidebar_position: 2 # Diff XDRs -:::info +:::info[Spot what changed] -Learn more about XDR to JSON conversion tools [here](../../../learn/fundamentals/data-format/xdr-json.mdx). +This tool renders both XDR payloads as XDR-JSON before highlighting their differences. Learn more in the [XDR-JSON section](../../../learn/fundamentals/data-format/xdr-json.mdx). ::: diff --git a/docs/tools/lab/view-xdr/json-to-xdr.mdx b/docs/tools/lab/view-xdr/json-to-xdr.mdx index e273e78dcb..cc16509a7b 100644 --- a/docs/tools/lab/view-xdr/json-to-xdr.mdx +++ b/docs/tools/lab/view-xdr/json-to-xdr.mdx @@ -7,9 +7,9 @@ sidebar_position: 1 # JSON to XDR -:::info +:::info[Encode for Stellar] -Learn more about JSON to XDR conversion tools [here](../../../learn/fundamentals/data-format/xdr-json.mdx). +Input must follow the XDR-JSON schema and be paired with the correct selected XDR type, because the JSON does not identify its top-level type. Learn more in the [XDR-JSON section](../../../learn/fundamentals/data-format/xdr-json.mdx). ::: diff --git a/docs/tools/lab/view-xdr/xdr-to-json.mdx b/docs/tools/lab/view-xdr/xdr-to-json.mdx index f33da65372..7ccb63463f 100644 --- a/docs/tools/lab/view-xdr/xdr-to-json.mdx +++ b/docs/tools/lab/view-xdr/xdr-to-json.mdx @@ -7,9 +7,9 @@ sidebar_position: 0 # XDR to JSON -:::info +:::info[Decode at a glance] -Learn more about XDR to JSON conversion tools [here](../../../learn/fundamentals/data-format/xdr-json.mdx). +This converter uses the lossless XDR-JSON schema, which preserves the encoded value but does not identify its top-level XDR type. To convert the JSON back to its original XDR, pair it with the selected XDR type. Learn more in the [XDR-JSON section](../../../learn/fundamentals/data-format/xdr-json.mdx). ::: diff --git a/docs/tools/openzeppelin-relayer.mdx b/docs/tools/openzeppelin-relayer.mdx index e56daf8d70..467634ab7e 100644 --- a/docs/tools/openzeppelin-relayer.mdx +++ b/docs/tools/openzeppelin-relayer.mdx @@ -21,7 +21,7 @@ The application is based on the Next.js framework and has server side code and c ### Prerequisites -This guide assumes you have deployed the Increment smart contract example code found [here](https://github.com/stellar/soroban-examples/tree/v22.0.1/increment). See the [Getting Started](../build/smart-contracts/getting-started) tutorial section 3 and 4 for more information about building and deploying the Increment contract. +This guide assumes you have deployed the Increment smart contract example code found [here](https://github.com/stellar/soroban-examples/tree/v22.0.1/increment). Learn more about building and deploying the Increment contract in sections 3 and 4 of the [Getting Started tutorial](../build/smart-contracts/getting-started). ### Server Side diff --git a/docs/tools/quickstart/advanced-usage/README.mdx b/docs/tools/quickstart/advanced-usage/README.mdx index ef067ee06d..1d96a6c404 100644 --- a/docs/tools/quickstart/advanced-usage/README.mdx +++ b/docs/tools/quickstart/advanced-usage/README.mdx @@ -11,6 +11,6 @@ import DocCardList from "@theme/DocCardList"; Quickstart works out of the box, and when launched using the Stellar CLI, no setup or configuration is required. While the standard configuration may work for many use cases, it may not fit everyone’s needs. If a custom setup and configuration is needed, the Quickstart container can be run using the docker CLI. -Read more about Quickstart configuration and setup: +Learn more about Quickstart configuration and setup: diff --git a/docs/tools/quickstart/cloud/fly.io.mdx b/docs/tools/quickstart/cloud/fly.io.mdx index 8f3d462792..5deb196851 100644 --- a/docs/tools/quickstart/cloud/fly.io.mdx +++ b/docs/tools/quickstart/cloud/fly.io.mdx @@ -13,7 +13,7 @@ import { getPlatform } from "@site/src/helpers/getPlatform"; Deploy to Fly.io using the following steps. -Install the Fly CLI. See [fly.io/docs/flyctl/install](https://fly.io/docs/flyctl/install) for instructions. +Install the Fly CLI. Learn more at [fly.io/docs/flyctl/install](https://fly.io/docs/flyctl/install) for instructions. Launch the image: diff --git a/docs/tools/quickstart/network-modes.mdx b/docs/tools/quickstart/network-modes.mdx index 81bf2f95f7..24a3e2b115 100644 --- a/docs/tools/quickstart/network-modes.mdx +++ b/docs/tools/quickstart/network-modes.mdx @@ -42,7 +42,7 @@ Public Key: GBZXN7PIRZGNMHGA7MUUUF4GWPY5AYPV6LY4UV2GL6VJGIQRXFDNMADI Secret Key: S... ``` -The root account is derived from the network passphrase and if the network passphrase is changed, the root account will change. To retrieve the root account details when changing the network passphrase, view the logs for stellar-core on its first start. See [Viewing](https://github.com/stellar/quickstart?tab=readme-ov-file#viewing-logs) logs for more details. +The root account is derived from the network passphrase and if the network passphrase is changed, the root account will change. To retrieve the root account details when changing the network passphrase, view the logs for stellar-core on its first start. Learn more in [Viewing logs](https://github.com/stellar/quickstart?tab=readme-ov-file#viewing-logs). In local network mode, a ledger occurs every one second and so transactions are finalized faster than on deployed networks. diff --git a/docs/tools/sdks/client-sdks.mdx b/docs/tools/sdks/client-sdks.mdx index 7b01bec0cf..9edd2ee631 100644 --- a/docs/tools/sdks/client-sdks.mdx +++ b/docs/tools/sdks/client-sdks.mdx @@ -11,7 +11,7 @@ Client and XDR SDKs are used by applications to interact with the network. :::note -For SDKs for building smart contracts, see [Contract SDKs](./contract-sdks.mdx). +For SDKs for building smart contracts, learn more in [Contract SDKs](./contract-sdks.mdx). ::: diff --git a/docs/validators/README.mdx b/docs/validators/README.mdx index 37f879807c..a7c0ca4cf1 100644 --- a/docs/validators/README.mdx +++ b/docs/validators/README.mdx @@ -18,7 +18,7 @@ If you are interested in running a validator node — because you issue an asset :::tip[Interested in Tier 1?] -If your organization is evaluating or planning to join the Tier 1 quorum — the core group of organizations whose validators bear the safety and liveness of the network — see [Tier 1 Organizations](./tier-1-orgs.mdx) for requirements, estimated costs, and a step-by-step onboarding path. The Admin Guide below covers the technical setup for a single validator; the Tier 1 page covers what it takes to run three and join the quorum. +If your organization is evaluating or planning to join the Tier 1 quorum — the core group of organizations whose validators bear the safety and liveness of the network — learn more about the requirements, estimated costs, and step-by-step onboarding path in [Tier 1 Organizations](./tier-1-orgs.mdx). The Admin Guide below covers the technical setup for a single validator; the Tier 1 page covers what it takes to run three and join the quorum. ::: diff --git a/docs/validators/admin-guide/advanced.mdx b/docs/validators/admin-guide/advanced.mdx index a681feb3df..03fccc4e25 100644 --- a/docs/validators/admin-guide/advanced.mdx +++ b/docs/validators/admin-guide/advanced.mdx @@ -15,7 +15,7 @@ Stellar-core can be started directly from the command line, or through a supervi Stellar-core can be gracefully exited at any time by delivering `SIGINT` or pressing `CTRL-C`. It can be safely, forcibly terminated with `SIGTERM` or `SIGKILL`. The latter may leave a stale lock file in the `BUCKET_DIR_PATH`, and you may need to remove this file before stellar-core will restart. Broadly speaking, all components are designed to recover from abrupt termination. -Stellar-core can also be packaged in a container system such as Docker, so long as `BUCKET_DIR_PATH` and the database are stored on persistent volumes. For an example, see [`stellar/quickstart`]. +Stellar-core can also be packaged in a container system such as Docker, so long as `BUCKET_DIR_PATH` and the database are stored on persistent volumes. For an example, learn more in [`stellar/quickstart`]. ## In-depth Architecture diff --git a/docs/validators/admin-guide/configuring.mdx b/docs/validators/admin-guide/configuring.mdx index 631c4ad60e..39f768d5a9 100644 --- a/docs/validators/admin-guide/configuring.mdx +++ b/docs/validators/admin-guide/configuring.mdx @@ -39,7 +39,7 @@ While we're looking at some of the config basics on this page, we've written thi - If you want to connect to the Mainnet network, check out this [example Mainnet config] for a full validator. It includes a properly crafted quorum set with all the current [Tier 1 validators](../tier-1-orgs.mdx), which is a good place to start for most configurations. This node is set up to both [validate](#validating-node) and write history to a [public archive](./environment-preparation.mdx#configuring-to-publish-data-to-an-archive), but you can disable either feature by adjusting this config so it's a little lighter. -Auditing of the P2P network is enabled by default, see the [overlay topology](./monitoring.mdx#overlay-topology-survey) section for more detail if you'd like to disable it +Auditing of the P2P network is enabled by default. Learn more about disabling it in the [Overlay Topology section](./monitoring.mdx#overlay-topology-survey). ### Network Passphrase @@ -52,7 +52,7 @@ For more about the Network Passphrase and how it works, check out the [Networks ### Database -You specify your node's database by using the aptly named `DATABASE` field of your config file, which you can can read more about in the [complete example config][complete-example-database]. It defaults to an in-memory database, but you can specify a path as per the example. +You specify your node's database by using the aptly named `DATABASE` field of your config file. Learn more in the [complete example config][complete-example-database]. It defaults to an in-memory database, but you can specify a path as per the example. ### Buckets diff --git a/docs/validators/admin-guide/installation.mdx b/docs/validators/admin-guide/installation.mdx index 1fc68cc579..47e479fdb0 100644 --- a/docs/validators/admin-guide/installation.mdx +++ b/docs/validators/admin-guide/installation.mdx @@ -99,7 +99,7 @@ docker run -v "/path/to/config/dir:/etc/stellar/" stellar/stellar-core:latest ne docker run -d -v "/path/to/config/dir:/etc/stellar/" stellar/stellar-core:latest run ``` -The image utilizes deb packages so it's possible to confirm the checksum of the `stellar-core` binary in the docker image matches what is in the cryptographically signed deb package. See [package based installation section](#package-based-installation) for information. To calculate this checksum in the docker image you can run: +The image utilizes deb packages so it's possible to confirm the checksum of the `stellar-core` binary in the docker image matches what is in the cryptographically signed deb package. Learn more in the [package-based installation section](#package-based-installation) for information. To calculate this checksum in the docker image you can run: ```bash docker run --entrypoint=/bin/sha256sum stellar/stellar-core:latest /usr/bin/stellar-core diff --git a/docs/validators/admin-guide/network-upgrades.mdx b/docs/validators/admin-guide/network-upgrades.mdx index 349938cf9a..91d156788b 100644 --- a/docs/validators/admin-guide/network-upgrades.mdx +++ b/docs/validators/admin-guide/network-upgrades.mdx @@ -7,7 +7,7 @@ The network itself has network wide settings that can be updated. This is performed by validators voting for and agreeing to new values the same way that consensus is reached for transaction sets, etc. -A node can be configured to vote for upgrades using the `upgrades` endpoint . See [Commands](./commands.mdx) for more information. +A node can be configured to vote for upgrades using the `upgrades` endpoint . Learn more in [Commands](./commands.mdx). The network settings are: diff --git a/docs/validators/admin-guide/prerequisites.mdx b/docs/validators/admin-guide/prerequisites.mdx index 7826ffd6b0..017c0b26bf 100644 --- a/docs/validators/admin-guide/prerequisites.mdx +++ b/docs/validators/admin-guide/prerequisites.mdx @@ -15,7 +15,7 @@ CPU, RAM, Disk and network depends on network activity. If you decide to colloca :::tip[For Tier 1 organizations] -[Tier 1 organizations](../tier-1-orgs.mdx) run three geographically dispersed Full Validators, each meeting these requirements independently. Each node needs its own hardware, its own unique validator key, and its own history archive. Plan for three times the resources listed below, spread across different data centers or cloud regions. See [Tier 1 Organizations](../tier-1-orgs.mdx) for the full requirements and onboarding path. +[Tier 1 organizations](../tier-1-orgs.mdx) run three geographically dispersed Full Validators, each meeting these requirements independently. Each node needs its own hardware, its own unique validator key, and its own history archive. Plan for three times the resources listed below, spread across different data centers or cloud regions. Learn more in [Tier 1 Organizations](../tier-1-orgs.mdx) for the full requirements and onboarding path. ::: @@ -29,7 +29,7 @@ The following recommendations were verified against production nodes in April 20 PostgreSQL co-located on the same machine performs well at this spec — a separate database host is not required for a single validator. -_\* Disk sizing assumes a 30-day retention window (`AUTOMATIC_MAINTENANCE_COUNT` at default). See [Storage](#storage) below for details._ +_\* Disk sizing assumes a 30-day retention window (`AUTOMATIC_MAINTENANCE_COUNT` at default). Learn more in [Storage](#storage) below._ {/* Last verified: April 2024. If you're an SDF maintainer updating this, bump the date in the paragraph above. */} @@ -55,7 +55,7 @@ Stellar Core also needs to connect to certain internal systems, though exactly h - The `HTTP_PORT` is used by other systems (such as Stellar RPC) to submit transactions, so this port may have to be exposed to the rest of your internal IP addresses. - It's also used to query Stellar Core [info](./commands.mdx) and provide [metrics](./monitoring.mdx). - And to perform administrative commands such as [scheduling upgrades](./network-upgrades.mdx) and changing log levels -- For more on that, see [commands](./commands.mdx) +- For more on that, learn more in [commands](./commands.mdx) :::note[Note on exposing the HTTP endpoint] @@ -66,7 +66,7 @@ If you need to expose this endpoint to other hosts in your local network, we str ### Outbound - Stellar Core requires access to a database (PostgreSQL, for example). If that database resides on a different machine on your network, you'll need to allow that connection. You'll specify the database when you [configure] Stellar Core. -- Your node needs outbound NTP (UDP port 123) so that its clock stays synchronized and Stellar Core can check for clock drift — see [Clock Synchronization](#clock-synchronization) below. +- Your node needs outbound NTP (UDP port 123) so that its clock stays synchronized and Stellar Core can check for clock drift. Learn more in [Clock Synchronization](#clock-synchronization) below. - You can safely block all other connections. ## Clock Synchronization @@ -127,7 +127,7 @@ chronyc sources -v ## Storage -Stellar Core's local storage needs come from two sources: the **buckets directory** (which serves as the primary database backend under BucketListDB, the default since stellar-core 21.0) and a much smaller **SQL database** for metadata. Both are managed entirely by Stellar Core. Local disk usage stays bounded over time — see [Why local disk stays bounded](#why-local-disk-stays-bounded) below. +Stellar Core's local storage needs come from two sources: the **buckets directory** (which serves as the primary database backend under BucketListDB, the default since stellar-core 21.0) and a much smaller **SQL database** for metadata. Both are managed entirely by Stellar Core. Local disk usage stays bounded over time. Learn more in [Why local disk stays bounded](#why-local-disk-stays-bounded) below. ### How storage breaks down @@ -149,7 +149,7 @@ A common misconception is that validators need to provision storage proportional **Classic ledger entries — accounts, trustlines, offers, claimable balances, liquidity pool shares, and data entries — do not expire.** They persist on the live state indefinitely. They grow slowly, though, because [reserve requirements](../../learn/fundamentals/stellar-data-structures/accounts.mdx#base-reserves-and-subentries) act as anti-spam friction on creation. In practice, the resulting working set still lands in the 30–60 GB range cited above, so local validator state stays compact even as cumulative network history grows. -**History archives live on object storage, not on the validator.** Full validators publish history archives to a separate object store (S3, R2, Backblaze B2, etc.) — that's where the multi-TB archive data lives. The validator process itself doesn't hold the archive on its local disk. See [Publishing History Archives](./publishing-history-archives.mdx) for the recommended setup. +**History archives live on object storage, not on the validator.** Full validators publish history archives to a separate object store (S3, R2, Backblaze B2, etc.) — that's where the multi-TB archive data lives. The validator process itself doesn't hold the archive on its local disk. Learn more in [Publishing History Archives](./publishing-history-archives.mdx) for the recommended setup. **`CATCHUP_COMPLETE=true` is almost never the right choice.** This setting makes the node sync the entire ledger from genesis on startup and is rarely appropriate for a validator. The standard pattern for new validators — including new Tier 1 candidates — is to sync against current network state, publish a history archive forward from that point, and use `stellar-archivist mirror` to backfill historical data into the published archive as a separate operation. The validator's local disk requirements are determined by the live state model above, not by historical depth. diff --git a/docs/validators/admin-guide/running-node.mdx b/docs/validators/admin-guide/running-node.mdx index 7738c8479f..fe921ca93b 100644 --- a/docs/validators/admin-guide/running-node.mdx +++ b/docs/validators/admin-guide/running-node.mdx @@ -95,7 +95,7 @@ And will then move through the various phases of downloading and applying state, For the fastest sync — including for new Full Validators and Tier 1 candidates — leave `CATCHUP_RECENT` at its default and do **not** set `CATCHUP_COMPLETE=true`. Your node will sync against current network state in minutes to hours rather than weeks. -`CATCHUP_COMPLETE=true` makes the node replay the _entire history_ of the network on startup, which takes weeks and is almost never the right choice for a validator — see [Why local disk stays bounded](./prerequisites.mdx#why-local-disk-stays-bounded). The standard pattern for new validators that want to publish a complete history archive is to sync against current state first, publish forward from that point, and use the [`stellar-archivist mirror`](https://github.com/stellar/go-stellar-sdk/tree/main/tools/stellar-archivist) tool to backfill historical data into the published archive as a separate offline operation. See the [complete example configuration] for more details. +`CATCHUP_COMPLETE=true` makes the node replay the _entire history_ of the network on startup, which takes weeks and is almost never the right choice for a validator — learn more in [Why local disk stays bounded](./prerequisites.mdx#why-local-disk-stays-bounded). The standard pattern for new validators that want to publish a complete history archive is to sync against current state first, publish forward from that point, and use the [`stellar-archivist mirror`](https://github.com/stellar/go-stellar-sdk/tree/main/tools/stellar-archivist) tool to backfill historical data into the published archive as a separate offline operation. Learn more in the [complete example configuration]. :::info diff --git a/docs/validators/tier-1-orgs.mdx b/docs/validators/tier-1-orgs.mdx index 00c136c032..651d9cceb8 100644 --- a/docs/validators/tier-1-orgs.mdx +++ b/docs/validators/tier-1-orgs.mdx @@ -94,7 +94,7 @@ No single dimension is disqualifying on its own, but organizations that strength ## Step-by-Step Path to Tier 1 -The checklist below covers the operational work. Completing it is necessary but not sufficient — see [What SDF and Existing Tier 1 Organizations Evaluate](#what-sdf-and-existing-tier-1-organizations-evaluate) above for the qualitative dimensions that determine whether existing Tier 1 organizations add you to their quorum sets. +The checklist below covers the operational work. Completing it is necessary but not sufficient. Learn more about the qualitative dimensions that determine whether existing Tier 1 organizations add you to their quorum sets in [What SDF and Existing Tier 1 Organizations Evaluate](#what-sdf-and-existing-tier-1-organizations-evaluate) above. ### Phase 1: First Full Validator diff --git a/meetings/2024-07-11.mdx b/meetings/2024-07-11.mdx index 3a763c41f5..821d8251db 100644 --- a/meetings/2024-07-11.mdx +++ b/meetings/2024-07-11.mdx @@ -9,6 +9,6 @@ import DriveVideo from "@site/src/components/DriveVideo"; 1. SDF Data team gave a crash course in analysis of Stellar data, and covered how to access Hubble, tips for efficient querying, and how to get started with data exploration. -2. [Slides](https://docs.google.com/presentation/d/1QsCwFLFcDF4RmNIwtSSnNrUfZb0RM0kLxOOxC7ENY5M/edit#slide=id.g2cb5821e4de_1_1143) are publicly available and legible async. -3. Tips for data anlaysis are also covered in [docs](/docs/data/analytics/hubble/analyst-guide) +2. [Slides](https://docs.google.com/presentation/d/1QsCwFLFcDF4RmNIwtSSnNrUfZb0RM0kLxOOxC7ENY5M/edit#slide=id.g2cb5821e4de_1_1143) are publicly-available and legible async. +3. Tips for data anlaysis are also covered in Hubble's [Analyst Guide](/docs/data/analytics/hubble/analyst-guide) 4. Share your queries and post questions in #hubble in Stellar discord, which is a dedicated channel for data-related topics.