From bf38d58764421a063d9b10d56a95fe98a2151538 Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Wed, 16 Apr 2025 15:54:58 -0400 Subject: [PATCH 1/8] format links back to `manageData` operation --- .../resources/operations/object/manage-data.mdx | 2 +- .../rpc/api-reference/methods/getLedgerEntries.mdx | 12 ++++++------ .../stellar-data-structures/accounts.mdx | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) 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 829e52f17a..5e4099c823 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 @@ -6,7 +6,7 @@ order: 120 import { ExampleResponse } from "@site/src/components/ExampleResponse"; import { AttributeTable } from "@site/src/components/AttributeTable"; -Set, modify, or delete a data entry (name/value pair) for an account. +For more information on how to set, modify, or delete a data entry (`name:value` pair) for an account, see the [`manageData` operation](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data). See the [`Manage Data` errors](../../../errors/result-codes/operation-specific/manage-data.mdx). diff --git a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx index 4fe124411e..0af5226594 100644 --- a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx +++ b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx @@ -21,12 +21,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/v22.0/Stellar-ledger-entries.x#L600). There are 10 different forms a ledger key can take: -1. **Account:** holistically defines a Stellar account, including its balance, signers, etc. (see [Accounts](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/accounts)) -2. **Trustline:** defines a balance line to a non-native asset issued on the network (see [`changeTrustOp`](https://developers.stellar.org/docs/learn/fundamentals/transactions/list-of-operations#change-trust)) -3. **Offer:** defines an offer made on the Stellar DEX (see [Liquidity on Stellar](https://developers.stellar.org/docs/learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools)) -4. **Account Data:** defines key-value data entries attached to an account (see [`manageDataOp`](https://developers.stellar.org/docs/learn/fundamentals/transactions/list-of-operations#manage-data)) -5. **Claimable Balance:** defines a balance that may or may not actively be claimable (see [Claimable Balances](https://developers.stellar.org/docs/learn/encyclopedia/transactions-specialized/claimable-balances)) -6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (see [Liquidity on Stellar](https://developers.stellar.org/docs/learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools)) +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#change-trust.mdx)) +3. **Offer:** defines an offer made on the Stellar DEX (_see_ [Liquidity on Stellar](../../../../learn/encyclopedia/sdex/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](../../../../learn/encyclopedia/transactions-specialized/claimable-balances.mdx)) +6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (_see_ [Liquidity on Stellar](../../../../learn/encyclopedia/sdex/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 diff --git a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx index 2d18519a63..548440bb88 100644 --- a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx @@ -46,7 +46,7 @@ Account data is stored in subentries, each of which increases an account’s min - Trustlines (includes traditional assets and pool shares) - Offers - Additional signers -- Data entries (includes data made with the `manageData` operation, not smart contract ledger entries) +- Data entries (includes data made with the [`manageData` operation](../transactions/list-of-operations.mdx#manage-data), not smart contract ledger entries) ## Trustlines From 45493d940de321622af575a150a579b23f4b5c6c Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Wed, 16 Apr 2025 15:56:25 -0400 Subject: [PATCH 2/8] Add slightly more info I'll polish this off in #723 --- docs/learn/fundamentals/transactions/list-of-operations.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx index 251f72364d..5c440b133b 100644 --- a/docs/learn/fundamentals/transactions/list-of-operations.mdx +++ b/docs/learn/fundamentals/transactions/list-of-operations.mdx @@ -370,7 +370,7 @@ Transfers the XLM balance of an account to another account and removes the sourc ## Manage data -Sets, modifies, or deletes a data entry (name/value pair) that is attached to an account +Sets, modifies, or deletes a persistent data entry (`name:value` string pair) that is attached to an account. Learn more about entries and subentries: [Accounts section](../stellar-data-structures/accounts.mdx#subentries) From 1fea4bff5c16977725f830cfd5b994cc3b7f1673 Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 20 May 2025 11:17:00 -0400 Subject: [PATCH 3/8] Here's what I mean I just want a clear explanation to show up when someone looks up the `ManageData` function of Stellar. It's not exactly something to write a whole Medium article on. More generally, it has technical nuances which could be updated over time, lending itself to a community documentation page like this. Relevantly, I've found that the `#` hash page entries on list-of-operations don't show up well in SEO. While they make a great reference for cross-linking the guides (and generally I've sincerely appreciated a single place to learn all the functionality over the years), standalone references help simplify new discoverability! --- .../operations/object/manage-data.mdx | 2 +- .../methods/getLedgerEntries.mdx | 12 +++++------ .../encyclopedia/storage/manage-data.mdx | 20 +++++++++++++++++++ .../stellar-data-structures/accounts.mdx | 2 +- .../transactions/list-of-operations.mdx | 2 ++ 5 files changed, 30 insertions(+), 8 deletions(-) create mode 100644 docs/learn/encyclopedia/storage/manage-data.mdx 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 5e4099c823..694902c407 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 @@ -6,7 +6,7 @@ order: 120 import { ExampleResponse } from "@site/src/components/ExampleResponse"; import { AttributeTable } from "@site/src/components/AttributeTable"; -For more information on how to set, modify, or delete a data entry (`name:value` pair) for an account, see the [`manageData` operation](../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data). +For more information on how to set, modify, or delete a data entry (`name:value` pair) for an account, see the [`manageData` operation](../../../../../../../learn/fundamentals/transactions/list-of-operations.mdx#manage-data). See the [`Manage Data` errors](../../../errors/result-codes/operation-specific/manage-data.mdx). diff --git a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx index 0af5226594..45a58c52e3 100644 --- a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx +++ b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx @@ -21,12 +21,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/v22.0/Stellar-ledger-entries.x#L600). 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#change-trust.mdx)) -3. **Offer:** defines an offer made on the Stellar DEX (_see_ [Liquidity on Stellar](../../../../learn/encyclopedia/sdex/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](../../../../learn/encyclopedia/transactions-specialized/claimable-balances.mdx)) -6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (_see_ [Liquidity on Stellar](../../../../learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools.mdx)) +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#change-trust.mdx)) +3. **Offer:** defines an offer made on the Stellar DEX (_see_ [Liquidity on Stellar](../../../../../learn/encyclopedia/sdex/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](../../../../../learn/encyclopedia/transactions-specialized/claimable-balances.mdx)) +6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (_see_ [Liquidity on Stellar](../../../../../learn/encyclopedia/sdex/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 diff --git a/docs/learn/encyclopedia/storage/manage-data.mdx b/docs/learn/encyclopedia/storage/manage-data.mdx new file mode 100644 index 0000000000..82cd590731 --- /dev/null +++ b/docs/learn/encyclopedia/storage/manage-data.mdx @@ -0,0 +1,20 @@ +--- +sidebar_position: 10 +title: Classic Data +description: Associate information with an account. +--- + +You can manage data associated with [accounts](../../fundamentals/stellar-data-structures/accounts.mdx) using the [`ManageData` operation](../../fundamentals/transactions/list-of-operations.mdx#manage-data). The data entry uses up one account subentry, increasing base reserves. In exchange for this slight cost, you can retrieve an account with [user-defined](../../../data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx) key-value pairs. + +Existing community projects use this field for [IPFS direction](https://docs.ipfs.tech/concepts/content-addressing/), verification attestations, and much more. The information shows up towards the end of a Horizon response for a base account URL: + +```curl +"signers": [ + { ... } +], +"data": { + "ipns": "azUxcXppNXVxdTVka2l0MjdnYzc4a2RmcWpneGxxaW9mdnBtOXFiY2NrZGtzbzVodHUxcWVjYnl5azQwY3o=", + "your": "value" +}, +"num_sponsoring": ... +``` diff --git a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx index 548440bb88..b0fa70ae15 100644 --- a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx @@ -46,7 +46,7 @@ Account data is stored in subentries, each of which increases an account’s min - Trustlines (includes traditional assets and pool shares) - Offers - Additional signers -- Data entries (includes data made with the [`manageData` operation](../transactions/list-of-operations.mdx#manage-data), not smart contract ledger entries) +- Data entries (includes data made with the [`manageData` function](../../encyclopedia/storage/manage-data.mdx), not smart contract ledger entries) ## Trustlines diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx index 5c440b133b..8de050d349 100644 --- a/docs/learn/fundamentals/transactions/list-of-operations.mdx +++ b/docs/learn/fundamentals/transactions/list-of-operations.mdx @@ -374,6 +374,8 @@ Sets, modifies, or deletes a persistent data entry (`name:value` string pair) th Learn more about entries and subentries: [Accounts section](../stellar-data-structures/accounts.mdx#subentries) +Learn more about ManageData functionality: [Storage page](../../encyclopedia/storage/manage-data.mdx) + **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/txnbuild#ManageData) **Threshold**: Medium **Result**: `ManageDataResult` From aedcb5567b419db6d8d8a5a315bff5bda57b0367 Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 20 May 2025 12:43:03 -0400 Subject: [PATCH 4/8] remove old SEO, `routes.txt` --- docs/learn/encyclopedia/storage/persisting-data.mdx | 10 ---------- docs/learn/encyclopedia/storage/state-archival.mdx | 10 ---------- routes.txt | 1 + 3 files changed, 1 insertion(+), 20 deletions(-) diff --git a/docs/learn/encyclopedia/storage/persisting-data.mdx b/docs/learn/encyclopedia/storage/persisting-data.mdx index 12d2297f1b..02372f1fc5 100644 --- a/docs/learn/encyclopedia/storage/persisting-data.mdx +++ b/docs/learn/encyclopedia/storage/persisting-data.mdx @@ -4,16 +4,6 @@ title: Persisting Data description: Store and access smart contract data. --- - - Store and access smart contract data. - - - - - ## Ledger entries Contracts can access ledger entries of type `CONTRACT_DATA`. Host functions are provided to probe, read, write, and delete `CONTRACT_DATA` ledger entries. diff --git a/docs/learn/encyclopedia/storage/state-archival.mdx b/docs/learn/encyclopedia/storage/state-archival.mdx index 2647caed5d..2cbd1bb5d1 100644 --- a/docs/learn/encyclopedia/storage/state-archival.mdx +++ b/docs/learn/encyclopedia/storage/state-archival.mdx @@ -4,16 +4,6 @@ title: State Archival description: Smart contract state archival. --- - - 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). 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). diff --git a/routes.txt b/routes.txt index 0f23169e83..26958e8296 100644 --- a/routes.txt +++ b/routes.txt @@ -462,6 +462,7 @@ /docs/learn/encyclopedia/security/securing-web-based-projects /docs/learn/encyclopedia/security/signatures-multisig /docs/learn/encyclopedia/storage +/docs/learn/encyclopedia/storage/manage-data /docs/learn/encyclopedia/storage/persisting-data /docs/learn/encyclopedia/storage/state-archival /docs/learn/encyclopedia/transactions-specialized From e2dc80ebdb8090129e89a38d4ffd2f65dd2460a9 Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 11 Nov 2025 12:27:32 -0500 Subject: [PATCH 5/8] conform diction to #1557 routes Really great work there from Bri, and I love the use of a draft PR when scope expands based on collaboration from Jane! --- .../contract-development/storage/manage-data.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/learn/fundamentals/contract-development/storage/manage-data.mdx b/docs/learn/fundamentals/contract-development/storage/manage-data.mdx index 82cd590731..0fcb875e15 100644 --- a/docs/learn/fundamentals/contract-development/storage/manage-data.mdx +++ b/docs/learn/fundamentals/contract-development/storage/manage-data.mdx @@ -1,10 +1,10 @@ --- sidebar_position: 10 -title: Classic Data -description: Associate information with an account. +title: Native Data +description: Associate information with a classic account. --- -You can manage data associated with [accounts](../../fundamentals/stellar-data-structures/accounts.mdx) using the [`ManageData` operation](../../fundamentals/transactions/list-of-operations.mdx#manage-data). The data entry uses up one account subentry, increasing base reserves. In exchange for this slight cost, you can retrieve an account with [user-defined](../../../data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx) key-value pairs. +You can manage data associated with [accounts](../../fundamentals/stellar-data-structures/accounts.mdx) using the [`ManageData` operation](../../fundamentals/transactions/list-of-operations.mdx#manage-data), no smart contract needed! The data entry uses up one account subentry, increasing base reserves. In exchange for this slight cost, you can retrieve an account with [user-defined](../../../data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx) key-value pairs. Existing community projects use this field for [IPFS direction](https://docs.ipfs.tech/concepts/content-addressing/), verification attestations, and much more. The information shows up towards the end of a Horizon response for a base account URL: From b416b58ba3acedc4942683e15216f71c3f2553cd Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 11 Nov 2025 12:51:30 -0500 Subject: [PATCH 6/8] fix links --- docs/build/guides/conventions/extending-wasm-ttl.mdx | 2 ++ docs/build/guides/fees/analyzing-smart-contract-cost.mdx | 2 ++ .../build/guides/transactions/send-and-receive-payments.mdx | 1 + .../guides/transactions/simulateTransaction-Deep-Dive.mdx | 4 ++++ .../threat-modeling/pizza-restaurant-example.mdx | 4 ++++ docs/data/apis/horizon/admin-guide/configuring.mdx | 1 + docs/data/apis/horizon/admin-guide/upgrading.mdx | 2 ++ .../apis/rpc/api-reference/methods/getLedgerEntries.mdx | 6 +++--- .../ingest-sdk/developer_guide/ledgerbackends/README.mdx | 2 ++ .../developer_guide/ledgerbackends/captivecore.mdx | 1 + .../processors/token-transfer-processor/README.mdx | 2 ++ .../contract-interactions/stellar-transaction.mdx | 2 ++ .../errors-and-debugging/debugging-errors.mdx | 3 +++ .../contract-development/storage/manage-data.mdx | 2 +- .../learn/fundamentals/stellar-data-structures/accounts.mdx | 2 +- docs/learn/fundamentals/transactions/list-of-operations.mdx | 2 +- docs/learn/migrate/evm/solidity-and-rust-basics.mdx | 1 + docs/tools/scaffold-stellar.mdx | 2 ++ platforms/anchor-platform/CONTRIBUTING.md | 2 ++ 19 files changed, 37 insertions(+), 6 deletions(-) diff --git a/docs/build/guides/conventions/extending-wasm-ttl.mdx b/docs/build/guides/conventions/extending-wasm-ttl.mdx index b427b6a407..4d70e17b0a 100644 --- a/docs/build/guides/conventions/extending-wasm-ttl.mdx +++ b/docs/build/guides/conventions/extending-wasm-ttl.mdx @@ -33,10 +33,12 @@ Before we demonstrate the TTL extension methods, you should note that in Soroban This guide will cover three ways to extend a contract's TTL: 1. Self-Extension: Extending the TTL from within the contract itself, in Rust. + - Use case: When a contract needs to manage its own lifetime - Process: Directly accessing the contract's instance storage to extend its TTL 2. External Extension: Extending the TTL from another contract (the deployer), in Rust. + - Use case: When managing multiple contract instances or implementing administrative control - Process: Using the deployer's authority to extend TTL for any contract it has deployed diff --git a/docs/build/guides/fees/analyzing-smart-contract-cost.mdx b/docs/build/guides/fees/analyzing-smart-contract-cost.mdx index 4a5fffc5b2..77a8f65dc6 100644 --- a/docs/build/guides/fees/analyzing-smart-contract-cost.mdx +++ b/docs/build/guides/fees/analyzing-smart-contract-cost.mdx @@ -243,6 +243,7 @@ The current approach using events is indeed optimized for gas efficiency, but it ##### Current Approach (Using Events) - Pros: + - Extremely gas-efficient as it minimizes storage operations - Useful for off-chain applications that can listen to and process events - Ideal for data that doesn't need to be accessed on-chain frequently @@ -257,6 +258,7 @@ The current approach using events is indeed optimized for gas efficiency, but it This approach offers a balance between accessibility and efficiency. - Pros: + - Latest move is always accessible on-chain - Historical data is available within the same transaction - More flexible for in-contract logic that might need recent history diff --git a/docs/build/guides/transactions/send-and-receive-payments.mdx b/docs/build/guides/transactions/send-and-receive-payments.mdx index 0dfa85a04d..f1db8f0d92 100644 --- a/docs/build/guides/transactions/send-and-receive-payments.mdx +++ b/docs/build/guides/transactions/send-and-receive-payments.mdx @@ -1124,6 +1124,7 @@ go build -o monitor monitor/monitor.go ## Summary - Payments from transaction operations or contract invocations on Stellar network can be monitored by leveraging the unified events model as of [Protocol 23 (Whisk)](https://stellar.org/blog/developers/introducing-whisk-stellar-protocol-23) and the RPC `getEvents` method. + - **Payments are 'transfer' events**: the [unified events model](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) ensures whether a payment happened through an operation or contract invocation it will result in the same 'transfer' event being emitted. - **Event Type**: `"contract"` denotes payments are an application level event rather than 'system' event. - **Transfer Topics Model**: an array of four topics, specified in [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) and summarized: diff --git a/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx b/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx index 412f62280e..0b3d1bef07 100644 --- a/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx +++ b/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx @@ -384,15 +384,19 @@ The transaction simulation mechanism provides an estimation of CPU and memory co The `simulateTransaction` endpoint leverages various backend components to simulate the execution of a transaction. Here is a brief explanation of how it works: 1. **Invocation of Simulation**: + - The simulation is initiated by calling `simulate_invoke_host_function_op` which takes in parameters such as the transaction to be simulated, resource configuration, and other necessary details. 2. **Snapshot Source and Network Configuration**: + - The simulation utilizes a snapshot source (`MockSnapshotSource`) and network configuration (`NetworkConfig`) to mimic the state of the ledger and network conditions. 3. **Resource Calculation**: + - The function `simulate_invoke_host_function_op_resources` computes the resources (CPU instructions, memory bytes) required for the transaction by analyzing ledger changes. 4. **Execution and Result Handling**: + - The core of the execution is handled by `invoke_host_function_in_recording_mode`, which records the transaction's impact on the ledger. - The results are then processed, including any required authorizations, emitted events, and transaction data. diff --git a/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx b/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx index f8ec857cb1..d895f9362f 100644 --- a/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx +++ b/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx @@ -58,15 +58,19 @@ The project being reviewed is an online pizza restaurant. To help make the exper ## Did we do a good job? - Has the data flow diagram been referenced since it was created? + - Yes, it was invaluable in building the threat profile. - Did the STRIDE model uncover any new design issues or concerns that had not been previously addressed or thought of? + - Yes. We realized we needed to change the pizza station authentication scheme. Additionally, we reframed the queries for the pizza order social display to only deliver the needed information. - Did the treatments identified in the “What are we going to do about it” section adequately address the issues identified? + - Yes. We are continuing to monitor these in the event additional mitigations are needed. - Have additional issues been found after the threat model? + - None yet. As new features are added, the threat model will be updated to reflect the new additions. - Any additional thoughts or insights on the threat modeling process that could help improve it next time? diff --git a/docs/data/apis/horizon/admin-guide/configuring.mdx b/docs/data/apis/horizon/admin-guide/configuring.mdx index dd53a7450c..3e187230c4 100644 --- a/docs/data/apis/horizon/admin-guide/configuring.mdx +++ b/docs/data/apis/horizon/admin-guide/configuring.mdx @@ -8,6 +8,7 @@ import { Alert } from "@site/src/components/Alert"; ## Prerequisites - You have identified the [installation](./installing.mdx) method for the host system: + - For bare-metal, you have two executables installed on the host operation system path: `stellar-horizon` and `stellar-core`. - For running Horizon image with Docker daemon, you will use the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) hosted on Docker Hub. You have already pulled the stellar/stellar-horizon image via `docker pull stellar/stellar-horizon:` onto host. This image contains the `stellar-horizon` and `stellar-core` within. - For Kubernetes with [Horizon Helm Chart](https://github.com/stellar/helm-charts/tree/main/charts/horizon), you have followed the [Install Horizon with Helm Chart](./installing.mdx#helm-chart-installation). diff --git a/docs/data/apis/horizon/admin-guide/upgrading.mdx b/docs/data/apis/horizon/admin-guide/upgrading.mdx index 420ce0a447..3d15a16baf 100644 --- a/docs/data/apis/horizon/admin-guide/upgrading.mdx +++ b/docs/data/apis/horizon/admin-guide/upgrading.mdx @@ -19,6 +19,7 @@ Here we'll describe the recommended steps for upgrading a Horizon 2.x installati ### Assess current installation - Identify the list of all instances of Horizon that need to be upgraded. + - Bare-metal installations: the list of hosts is managed by you. - Docker daemon deployments: the list of hosts and running containers is managed by you. - Kubernetes deployments: get the list of pods that are deployed from your prior Helm installation, they will have an annotation for `release=your_helm_horizon_installation_name`: @@ -32,6 +33,7 @@ Here we'll describe the recommended steps for upgrading a Horizon 2.x installati - Identify your current Horizon software version: + - Obtain command line access to the operating system of each Horizon instance: - Bare-metal installations, this is typically ssh on Linux or powershell on Windows. - Docker daemon deployments, use `docker exec -it /bin/bash` diff --git a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx index f9f36e6fd5..dfd9ef6fef 100644 --- a/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx +++ b/docs/data/apis/rpc/api-reference/methods/getLedgerEntries.mdx @@ -23,10 +23,10 @@ The source of truth should always be the XDR defined in the protocol. `LedgerKey 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#change-trust.mdx)) -3. **Offer:** defines an offer made on the Stellar DEX (_see_ [Liquidity on Stellar](../../../../../learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools.mdx)) +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](../../../../../learn/encyclopedia/transactions-specialized/claimable-balances.mdx)) -6. **Liquidity Pool:** defines the configuration of a native constant liquidity pool between two assets (_see_ [Liquidity on Stellar](../../../../../learn/encyclopedia/sdex/liquidity-on-stellar-sdex-liquidity-pools.mdx)) +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)) 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 diff --git a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx index dc2cd0d95d..b9bbee2727 100644 --- a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx +++ b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx @@ -16,6 +16,7 @@ Each backend has its own setup and configuration requirements, which are covered `xdr.LedgerCloseMeta` captures a detailed record of all state changes during the closing of a Stellar ledger. It includes: - `LedgerHeader` – Metadata about the ledger, including: + - Ledger sequence number - Previous ledger hash - Close time @@ -24,6 +25,7 @@ Each backend has its own setup and configuration requirements, which are covered - `TxSet` – The set of transactions included in the ledger. - `TxProcessing` – Execution results of each transaction, including: + - Success or failure of operations within transactions - `OperationMeta`, which tracks `LedgerEntryChanges` caused by transactions diff --git a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx index 03f46e7cd6..3df61fc78d 100644 --- a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx +++ b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx @@ -12,6 +12,7 @@ Using captive Core requires stellar-core binary to be [installed](/docs/validato ### Installation 1. Install Stellar Core: + - Option 1: Build from source by following the [Installation Guide](/docs/validators/admin-guide/installation#installing-from-source) - Option 2: Install via a package manager by referring to the [Package-based Installation Guide](/docs/validators/admin-guide/installation#package-based-installation) 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 c3094179b1..725c7f0688 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 @@ -19,6 +19,7 @@ For more details on operational modes, see the [Modes of Operation](#modes-of-op ## Key Features - Captures token movements resulting from: + - Simple payments - Path payments - DEX operations @@ -31,6 +32,7 @@ For more details on operational modes, see the [Modes of Operation](#modes-of-op - [SEP-41][sep41] compliant token events - Generates CAP-67 standardized token events: + - Transfer: Movement of tokens between accounts - Mint: Creation of new tokens - Burn: Destruction of tokens 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 ac8d0bcdfc..0a599bf868 100644 --- a/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx +++ b/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx @@ -374,6 +374,7 @@ struct InvokeHostFunctionOp The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban host environment. The supported functions are: 1. `HOST_FUNCTION_TYPE_INVOKE_CONTRACT` + - This will invoke a function of the deployed contract with arguments specified in `invokeContract` struct. ```cpp @@ -390,6 +391,7 @@ The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban hos - This will upload the contract Wasm using the provided `wasm` blob. - Uploaded Wasm can be identified by the SHA-256 hash of the uploaded Wasm. 3. `HOST_FUNCTION_TYPE_CREATE_CONTRACT` + - This will deploy a contract instance to the network using the specified `executable`. The 32-byte contract identifier is based on `contractIDPreimage` value and the network identifier (so every network has a separate contract identifier namespace). ```cpp diff --git a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx index 3e4a817ceb..14734a2920 100644 --- a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx +++ b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx @@ -11,14 +11,17 @@ To understand how to debug Soroban errors, first we must understand how the erro The typical transaction submission process can be broken down into the following sequential steps, excluding external interactions like wallet interactions. Each step has its own set of potential errors: 1. **Transaction Simulation (optional):** + - **What happens:** This step involves executing the RPC endpoint [`simulateTransaction`](../../../../data/apis/rpc/api-reference/methods/simulateTransaction). The endpoint executes a transaction in 'simulation' mode of host and records the necessary ledger entries, CPU instructions, required authorizations. The end result is akin to running transactions in Core with maxed-out resources, unrestricted ledger access, and no fees. - **Common failures:** Errors typically involve exceeding the network limit or encountering contract logic issues. 2. **Core Accepts the Transaction:** + - **What happens:** Core evaluates each transaction to decide whether to accept or reject it. Rejected transactions are usually invalid or have insufficient fees, especially during high traffic periods. - **Common failures:** Invalid transactions, such as those with incorrect resource fees or overly high resource values, and invalid footprint are rejected. Other common errors include bad transaction signatures or insufficient funds in the source account. Valid transactions may only be rejected due to a low inclusion fee. 3. **Core Includes the Transaction in the Ledger:** + - **What happens:** Accepted transactions remain in Core’s memory until they are either included in the ledger or evicted. - **Common failures:** Transactions may fail to be included in the ledger if they have a low inclusion fee and need to be evicted during traffic surges to accommodate more transactions. diff --git a/docs/learn/fundamentals/contract-development/storage/manage-data.mdx b/docs/learn/fundamentals/contract-development/storage/manage-data.mdx index 0fcb875e15..079bd62f01 100644 --- a/docs/learn/fundamentals/contract-development/storage/manage-data.mdx +++ b/docs/learn/fundamentals/contract-development/storage/manage-data.mdx @@ -4,7 +4,7 @@ title: Native Data description: Associate information with a classic account. --- -You can manage data associated with [accounts](../../fundamentals/stellar-data-structures/accounts.mdx) using the [`ManageData` operation](../../fundamentals/transactions/list-of-operations.mdx#manage-data), no smart contract needed! The data entry uses up one account subentry, increasing base reserves. In exchange for this slight cost, you can retrieve an account with [user-defined](../../../data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx) key-value pairs. +You can manage data associated with [accounts](../../stellar-data-structures/accounts.mdx) using the [`ManageData` operation](../../transactions/list-of-operations.mdx#manage-data), no smart contract needed! The data entry uses up one account subentry, increasing base reserves. In exchange for this slight cost, you can retrieve an account with [user-defined](../../../../data/apis/horizon/api-reference/resources/operations/object/manage-data.mdx) key-value pairs. Existing community projects use this field for [IPFS direction](https://docs.ipfs.tech/concepts/content-addressing/), verification attestations, and much more. The information shows up towards the end of a Horizon response for a base account URL: diff --git a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx index 272575bfab..197c5c9d0f 100644 --- a/docs/learn/fundamentals/stellar-data-structures/accounts.mdx +++ b/docs/learn/fundamentals/stellar-data-structures/accounts.mdx @@ -46,7 +46,7 @@ Account data is stored in subentries, each of which increases an account’s min - Trustlines (includes traditional assets and pool shares) - Offers - Additional signers -- Data entries (includes data made with the [`manageData` function](../../encyclopedia/storage/manage-data.mdx), not smart contract ledger entries) +- Data entries (includes data made with the [`manageData` function](../contract-development/storage/manage-data.mdx), not smart contract ledger entries) ## Trustlines diff --git a/docs/learn/fundamentals/transactions/list-of-operations.mdx b/docs/learn/fundamentals/transactions/list-of-operations.mdx index 0f67be0c81..bf10b951a4 100644 --- a/docs/learn/fundamentals/transactions/list-of-operations.mdx +++ b/docs/learn/fundamentals/transactions/list-of-operations.mdx @@ -374,7 +374,7 @@ Sets, modifies, or deletes a persistent data entry (`name:value` string pair) th Learn more about entries and subentries: [Accounts section](../stellar-data-structures/accounts.mdx#subentries) -Learn more about ManageData functionality: [Storage page](../../encyclopedia/storage/manage-data.mdx) +Learn more about ManageData's functionality: [Storage page](../contract-development/storage/manage-data.mdx) **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/txnbuild#ManageData) **Threshold**: Medium diff --git a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx index fec9533bbb..20b5515d1c 100644 --- a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx +++ b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx @@ -135,6 +135,7 @@ The [Soroban Rust SDK](https://docs.rs/soroban-sdk/latest/soroban_sdk/index.html - Address (`Address`): universal opaque identifier used in contracts - String (`String`): a contiguous growable array type containing u8s and requires an env to be passed in - Symbol: + - (`Symbol::new`): small efficient strings up to 32 characters in length and requires an env to be passed in - (`symbol_short!`) small efficient strings up to 9 characters in length diff --git a/docs/tools/scaffold-stellar.mdx b/docs/tools/scaffold-stellar.mdx index c6b7808274..6b9de30232 100644 --- a/docs/tools/scaffold-stellar.mdx +++ b/docs/tools/scaffold-stellar.mdx @@ -88,6 +88,7 @@ This template provides a ready-to-use frontend application with example smart co ## Features - **CLI Plugins for Stellar** + - `stellar scaffold init`: Initialize new Stellar smart contract projects - `stellar scaffold upgrade`: Transform existing Stellar contract workspaces into Scaffold projects - `stellar scaffold build`: Build contracts and generate TypeScript clients @@ -95,6 +96,7 @@ This template provides a ready-to-use frontend application with example smart co - `stellar registry`: Publish, deploy, and manage smart contracts - **Environment Management** + - Environment-specific builds (development, testing, staging, production) - Seamless integration with both local and deployed contracts - Network configuration via `environments.toml` diff --git a/platforms/anchor-platform/CONTRIBUTING.md b/platforms/anchor-platform/CONTRIBUTING.md index 81cede6349..f246fd3bcd 100644 --- a/platforms/anchor-platform/CONTRIBUTING.md +++ b/platforms/anchor-platform/CONTRIBUTING.md @@ -184,6 +184,7 @@ versioned AP documentation. they'll be told it's the unreleased version. There is also a new directory here you should know about: + - `/platforms/anchor-platform/assets` Since it's likely that the various images, diagrams, etc. will need to update/change from one version to another, we're co-locating the relevant assets in this directory. This @@ -199,6 +200,7 @@ versioned AP documentation. `v3.x` (and beyond, eventually), you'll want to be updating _specfiles here_. There is also a new directory here you should know about: + - `/openapi/anchor-platform/versions` This directory stores a copy of the _bundled_ specfiles for each version that is released. The plugin we use to generate the API documentation for these specfiles gets configured to use From b5f75f7489952deb35f23aa298ffeaf4d087752c Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 11 Nov 2025 13:25:09 -0500 Subject: [PATCH 7/8] yarn build --- routes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/routes.txt b/routes.txt index aea24d7967..792e010280 100644 --- a/routes.txt +++ b/routes.txt @@ -486,6 +486,7 @@ /docs/learn/fundamentals/contract-development/overview /docs/learn/fundamentals/contract-development/rust-dialect /docs/learn/fundamentals/contract-development/storage +/docs/learn/fundamentals/contract-development/storage/manage-data /docs/learn/fundamentals/contract-development/storage/persisting-data /docs/learn/fundamentals/contract-development/storage/state-archival /docs/learn/fundamentals/contract-development/types From 60e903094a7acbf33572d1e76b2c0a280674ea42 Mon Sep 17 00:00:00 2001 From: "john.xlm" <60260750+JFWooten4@users.noreply.github.com> Date: Tue, 11 Nov 2025 14:17:43 -0500 Subject: [PATCH 8/8] chore: run npm run format:mdx on docs --- docs/build/guides/conventions/extending-wasm-ttl.mdx | 2 -- docs/build/guides/fees/analyzing-smart-contract-cost.mdx | 2 -- docs/build/guides/transactions/send-and-receive-payments.mdx | 1 - .../guides/transactions/simulateTransaction-Deep-Dive.mdx | 4 ---- .../threat-modeling/pizza-restaurant-example.mdx | 4 ---- docs/data/apis/horizon/admin-guide/configuring.mdx | 1 - docs/data/apis/horizon/admin-guide/upgrading.mdx | 2 -- .../ingest-sdk/developer_guide/ledgerbackends/README.mdx | 2 -- .../ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx | 1 - .../processors/token-transfer-processor/README.mdx | 2 -- .../contract-interactions/stellar-transaction.mdx | 2 -- .../errors-and-debugging/debugging-errors.mdx | 3 --- docs/learn/migrate/evm/solidity-and-rust-basics.mdx | 1 - docs/tools/scaffold-stellar.mdx | 2 -- platforms/anchor-platform/CONTRIBUTING.md | 2 -- 15 files changed, 31 deletions(-) diff --git a/docs/build/guides/conventions/extending-wasm-ttl.mdx b/docs/build/guides/conventions/extending-wasm-ttl.mdx index 4d70e17b0a..b427b6a407 100644 --- a/docs/build/guides/conventions/extending-wasm-ttl.mdx +++ b/docs/build/guides/conventions/extending-wasm-ttl.mdx @@ -33,12 +33,10 @@ Before we demonstrate the TTL extension methods, you should note that in Soroban This guide will cover three ways to extend a contract's TTL: 1. Self-Extension: Extending the TTL from within the contract itself, in Rust. - - Use case: When a contract needs to manage its own lifetime - Process: Directly accessing the contract's instance storage to extend its TTL 2. External Extension: Extending the TTL from another contract (the deployer), in Rust. - - Use case: When managing multiple contract instances or implementing administrative control - Process: Using the deployer's authority to extend TTL for any contract it has deployed diff --git a/docs/build/guides/fees/analyzing-smart-contract-cost.mdx b/docs/build/guides/fees/analyzing-smart-contract-cost.mdx index 77a8f65dc6..4a5fffc5b2 100644 --- a/docs/build/guides/fees/analyzing-smart-contract-cost.mdx +++ b/docs/build/guides/fees/analyzing-smart-contract-cost.mdx @@ -243,7 +243,6 @@ The current approach using events is indeed optimized for gas efficiency, but it ##### Current Approach (Using Events) - Pros: - - Extremely gas-efficient as it minimizes storage operations - Useful for off-chain applications that can listen to and process events - Ideal for data that doesn't need to be accessed on-chain frequently @@ -258,7 +257,6 @@ The current approach using events is indeed optimized for gas efficiency, but it This approach offers a balance between accessibility and efficiency. - Pros: - - Latest move is always accessible on-chain - Historical data is available within the same transaction - More flexible for in-contract logic that might need recent history diff --git a/docs/build/guides/transactions/send-and-receive-payments.mdx b/docs/build/guides/transactions/send-and-receive-payments.mdx index f1db8f0d92..0dfa85a04d 100644 --- a/docs/build/guides/transactions/send-and-receive-payments.mdx +++ b/docs/build/guides/transactions/send-and-receive-payments.mdx @@ -1124,7 +1124,6 @@ go build -o monitor monitor/monitor.go ## Summary - Payments from transaction operations or contract invocations on Stellar network can be monitored by leveraging the unified events model as of [Protocol 23 (Whisk)](https://stellar.org/blog/developers/introducing-whisk-stellar-protocol-23) and the RPC `getEvents` method. - - **Payments are 'transfer' events**: the [unified events model](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) ensures whether a payment happened through an operation or contract invocation it will result in the same 'transfer' event being emitted. - **Event Type**: `"contract"` denotes payments are an application level event rather than 'system' event. - **Transfer Topics Model**: an array of four topics, specified in [CAP-67](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0067.md) and summarized: diff --git a/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx b/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx index 0b3d1bef07..412f62280e 100644 --- a/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx +++ b/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx @@ -384,19 +384,15 @@ The transaction simulation mechanism provides an estimation of CPU and memory co The `simulateTransaction` endpoint leverages various backend components to simulate the execution of a transaction. Here is a brief explanation of how it works: 1. **Invocation of Simulation**: - - The simulation is initiated by calling `simulate_invoke_host_function_op` which takes in parameters such as the transaction to be simulated, resource configuration, and other necessary details. 2. **Snapshot Source and Network Configuration**: - - The simulation utilizes a snapshot source (`MockSnapshotSource`) and network configuration (`NetworkConfig`) to mimic the state of the ledger and network conditions. 3. **Resource Calculation**: - - The function `simulate_invoke_host_function_op_resources` computes the resources (CPU instructions, memory bytes) required for the transaction by analyzing ledger changes. 4. **Execution and Result Handling**: - - The core of the execution is handled by `invoke_host_function_in_recording_mode`, which records the transaction's impact on the ledger. - The results are then processed, including any required authorizations, emitted events, and transaction data. diff --git a/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx b/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx index d895f9362f..f8ec857cb1 100644 --- a/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx +++ b/docs/build/security-docs/threat-modeling/pizza-restaurant-example.mdx @@ -58,19 +58,15 @@ The project being reviewed is an online pizza restaurant. To help make the exper ## Did we do a good job? - Has the data flow diagram been referenced since it was created? - - Yes, it was invaluable in building the threat profile. - Did the STRIDE model uncover any new design issues or concerns that had not been previously addressed or thought of? - - Yes. We realized we needed to change the pizza station authentication scheme. Additionally, we reframed the queries for the pizza order social display to only deliver the needed information. - Did the treatments identified in the “What are we going to do about it” section adequately address the issues identified? - - Yes. We are continuing to monitor these in the event additional mitigations are needed. - Have additional issues been found after the threat model? - - None yet. As new features are added, the threat model will be updated to reflect the new additions. - Any additional thoughts or insights on the threat modeling process that could help improve it next time? diff --git a/docs/data/apis/horizon/admin-guide/configuring.mdx b/docs/data/apis/horizon/admin-guide/configuring.mdx index 3e187230c4..dd53a7450c 100644 --- a/docs/data/apis/horizon/admin-guide/configuring.mdx +++ b/docs/data/apis/horizon/admin-guide/configuring.mdx @@ -8,7 +8,6 @@ import { Alert } from "@site/src/components/Alert"; ## Prerequisites - You have identified the [installation](./installing.mdx) method for the host system: - - For bare-metal, you have two executables installed on the host operation system path: `stellar-horizon` and `stellar-core`. - For running Horizon image with Docker daemon, you will use the [stellar/stellar-horizon](https://hub.docker.com/r/stellar/stellar-horizon) hosted on Docker Hub. You have already pulled the stellar/stellar-horizon image via `docker pull stellar/stellar-horizon:` onto host. This image contains the `stellar-horizon` and `stellar-core` within. - For Kubernetes with [Horizon Helm Chart](https://github.com/stellar/helm-charts/tree/main/charts/horizon), you have followed the [Install Horizon with Helm Chart](./installing.mdx#helm-chart-installation). diff --git a/docs/data/apis/horizon/admin-guide/upgrading.mdx b/docs/data/apis/horizon/admin-guide/upgrading.mdx index 3d15a16baf..420ce0a447 100644 --- a/docs/data/apis/horizon/admin-guide/upgrading.mdx +++ b/docs/data/apis/horizon/admin-guide/upgrading.mdx @@ -19,7 +19,6 @@ Here we'll describe the recommended steps for upgrading a Horizon 2.x installati ### Assess current installation - Identify the list of all instances of Horizon that need to be upgraded. - - Bare-metal installations: the list of hosts is managed by you. - Docker daemon deployments: the list of hosts and running containers is managed by you. - Kubernetes deployments: get the list of pods that are deployed from your prior Helm installation, they will have an annotation for `release=your_helm_horizon_installation_name`: @@ -33,7 +32,6 @@ Here we'll describe the recommended steps for upgrading a Horizon 2.x installati - Identify your current Horizon software version: - - Obtain command line access to the operating system of each Horizon instance: - Bare-metal installations, this is typically ssh on Linux or powershell on Windows. - Docker daemon deployments, use `docker exec -it /bin/bash` diff --git a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx index b9bbee2727..dc2cd0d95d 100644 --- a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx +++ b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/README.mdx @@ -16,7 +16,6 @@ Each backend has its own setup and configuration requirements, which are covered `xdr.LedgerCloseMeta` captures a detailed record of all state changes during the closing of a Stellar ledger. It includes: - `LedgerHeader` – Metadata about the ledger, including: - - Ledger sequence number - Previous ledger hash - Close time @@ -25,7 +24,6 @@ Each backend has its own setup and configuration requirements, which are covered - `TxSet` – The set of transactions included in the ledger. - `TxProcessing` – Execution results of each transaction, including: - - Success or failure of operations within transactions - `OperationMeta`, which tracks `LedgerEntryChanges` caused by transactions diff --git a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx index 3df61fc78d..03f46e7cd6 100644 --- a/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx +++ b/docs/data/indexers/build-your-own/ingest-sdk/developer_guide/ledgerbackends/captivecore.mdx @@ -12,7 +12,6 @@ Using captive Core requires stellar-core binary to be [installed](/docs/validato ### Installation 1. Install Stellar Core: - - Option 1: Build from source by following the [Installation Guide](/docs/validators/admin-guide/installation#installing-from-source) - Option 2: Install via a package manager by referring to the [Package-based Installation Guide](/docs/validators/admin-guide/installation#package-based-installation) 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 725c7f0688..c3094179b1 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 @@ -19,7 +19,6 @@ For more details on operational modes, see the [Modes of Operation](#modes-of-op ## Key Features - Captures token movements resulting from: - - Simple payments - Path payments - DEX operations @@ -32,7 +31,6 @@ For more details on operational modes, see the [Modes of Operation](#modes-of-op - [SEP-41][sep41] compliant token events - Generates CAP-67 standardized token events: - - Transfer: Movement of tokens between accounts - Mint: Creation of new tokens - Burn: Destruction of tokens 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 0a599bf868..ac8d0bcdfc 100644 --- a/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx +++ b/docs/learn/fundamentals/contract-development/contract-interactions/stellar-transaction.mdx @@ -374,7 +374,6 @@ struct InvokeHostFunctionOp The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban host environment. The supported functions are: 1. `HOST_FUNCTION_TYPE_INVOKE_CONTRACT` - - This will invoke a function of the deployed contract with arguments specified in `invokeContract` struct. ```cpp @@ -391,7 +390,6 @@ The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban hos - This will upload the contract Wasm using the provided `wasm` blob. - Uploaded Wasm can be identified by the SHA-256 hash of the uploaded Wasm. 3. `HOST_FUNCTION_TYPE_CREATE_CONTRACT` - - This will deploy a contract instance to the network using the specified `executable`. The 32-byte contract identifier is based on `contractIDPreimage` value and the network identifier (so every network has a separate contract identifier namespace). ```cpp diff --git a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx index 14734a2920..3e4a817ceb 100644 --- a/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx +++ b/docs/learn/fundamentals/contract-development/errors-and-debugging/debugging-errors.mdx @@ -11,17 +11,14 @@ To understand how to debug Soroban errors, first we must understand how the erro The typical transaction submission process can be broken down into the following sequential steps, excluding external interactions like wallet interactions. Each step has its own set of potential errors: 1. **Transaction Simulation (optional):** - - **What happens:** This step involves executing the RPC endpoint [`simulateTransaction`](../../../../data/apis/rpc/api-reference/methods/simulateTransaction). The endpoint executes a transaction in 'simulation' mode of host and records the necessary ledger entries, CPU instructions, required authorizations. The end result is akin to running transactions in Core with maxed-out resources, unrestricted ledger access, and no fees. - **Common failures:** Errors typically involve exceeding the network limit or encountering contract logic issues. 2. **Core Accepts the Transaction:** - - **What happens:** Core evaluates each transaction to decide whether to accept or reject it. Rejected transactions are usually invalid or have insufficient fees, especially during high traffic periods. - **Common failures:** Invalid transactions, such as those with incorrect resource fees or overly high resource values, and invalid footprint are rejected. Other common errors include bad transaction signatures or insufficient funds in the source account. Valid transactions may only be rejected due to a low inclusion fee. 3. **Core Includes the Transaction in the Ledger:** - - **What happens:** Accepted transactions remain in Core’s memory until they are either included in the ledger or evicted. - **Common failures:** Transactions may fail to be included in the ledger if they have a low inclusion fee and need to be evicted during traffic surges to accommodate more transactions. diff --git a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx index 20b5515d1c..fec9533bbb 100644 --- a/docs/learn/migrate/evm/solidity-and-rust-basics.mdx +++ b/docs/learn/migrate/evm/solidity-and-rust-basics.mdx @@ -135,7 +135,6 @@ The [Soroban Rust SDK](https://docs.rs/soroban-sdk/latest/soroban_sdk/index.html - Address (`Address`): universal opaque identifier used in contracts - String (`String`): a contiguous growable array type containing u8s and requires an env to be passed in - Symbol: - - (`Symbol::new`): small efficient strings up to 32 characters in length and requires an env to be passed in - (`symbol_short!`) small efficient strings up to 9 characters in length diff --git a/docs/tools/scaffold-stellar.mdx b/docs/tools/scaffold-stellar.mdx index 6b9de30232..c6b7808274 100644 --- a/docs/tools/scaffold-stellar.mdx +++ b/docs/tools/scaffold-stellar.mdx @@ -88,7 +88,6 @@ This template provides a ready-to-use frontend application with example smart co ## Features - **CLI Plugins for Stellar** - - `stellar scaffold init`: Initialize new Stellar smart contract projects - `stellar scaffold upgrade`: Transform existing Stellar contract workspaces into Scaffold projects - `stellar scaffold build`: Build contracts and generate TypeScript clients @@ -96,7 +95,6 @@ This template provides a ready-to-use frontend application with example smart co - `stellar registry`: Publish, deploy, and manage smart contracts - **Environment Management** - - Environment-specific builds (development, testing, staging, production) - Seamless integration with both local and deployed contracts - Network configuration via `environments.toml` diff --git a/platforms/anchor-platform/CONTRIBUTING.md b/platforms/anchor-platform/CONTRIBUTING.md index f246fd3bcd..81cede6349 100644 --- a/platforms/anchor-platform/CONTRIBUTING.md +++ b/platforms/anchor-platform/CONTRIBUTING.md @@ -184,7 +184,6 @@ versioned AP documentation. they'll be told it's the unreleased version. There is also a new directory here you should know about: - - `/platforms/anchor-platform/assets` Since it's likely that the various images, diagrams, etc. will need to update/change from one version to another, we're co-locating the relevant assets in this directory. This @@ -200,7 +199,6 @@ versioned AP documentation. `v3.x` (and beyond, eventually), you'll want to be updating _specfiles here_. There is also a new directory here you should know about: - - `/openapi/anchor-platform/versions` This directory stores a copy of the _bundled_ specfiles for each version that is released. The plugin we use to generate the API documentation for these specfiles gets configured to use