merge conflicts

docs/build/guides/basics/classic-transition.mdx

@@ -0,0 +1,47 @@
+---
+title: Add support for smart contracts
+sidebar_position: 40
+description: Considerations for integrating with Stellar’s smart contracts specifically for wallets and exchanges
+---
+
+Stellar recently [upgraded its protocol](https://stellar.org/blog/developers/protocol-20-preparing-smart-contracts-to-stellar) to support smart contracts, adding a new way to interact with the network. This one-pager highlights key considerations for integrating with Stellar’s smart contracts specifically for wallets and exchanges that already support Stellar’s “classic” operations. It quickly outlines what changes to expect, provides links to detailed documentation, and is a starting point for adapting existing Stellar Classic processes to the new smart contract environment.
+
+## 1. Infrastructure
+
+### Transitioning from Horizon to RPC
+
+To properly support Stellar's smart contracts, you must use [Stellar RPC](../../../data/rpc). More specifically, you need RPC to simulate transactions that execute smart contracts, as described in the "Simulating Transactions" section, and it provides a convenient [API](../../../data/rpc/api-reference) for consuming contract events. Both of these features are not available in Horizon.
+
+### Running Your Own RPC vs. Leveraging Third-Party Providers
+
+You can set up an RPC environment by hosting your own node or using a third-party provider. For guidance on hosting your own instance, including a Docker-based setup, refer to the [Admin Guide](../../../data/rpc/admin-guide). Alternatively, a list of trusted providers is available in the [ecosystem RPC providers documentation](../../../data/rpc/rpc-providers).
+
+## 2. Data Ingestion
+
+### Ingesting Smart Contract Events
+
+Horizon offers an effects endpoint that describes state changes executed by classic operations. Similarly, contracts emit [events](../../../learn/encyclopedia/contract-development/events.mdx) that describe changes to their state, which can be fetched via RPC's API. Off-chain solutions can [monitor and ingest these events](../../../build/guides/events/ingest.mdx) (for token transfers or protocol updates) and remain in sync with on-chain data. Each event is defined by the contract and is subject to standards applied to the implementation. Depending on the requirements for retention, a solution might have to handle ingestion directly or use a [third-party service](../../../data/data-indexers/indexer-providers) for a longer-term history.
+
+### Simulating Transaction
+
+While events should be used to monitor changes to a contract’s state, clients may also need to determine the current state of a contract. [Simulation](../../../build/guides/transactions/simulateTransaction-Deep-Dive.mdx) allows clients to execute contract invocations with incurring fees or finalizing changes, making it an ideal approach for fetching contracts’ current state. For example, clients can call the balance function on a [SEP-0041](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0041.md)-compliant token contract to fetch a user’s current balance.
+
+## 3. Transaction Workflow Changes
+
+### Building Transactions
+
+Transaction construction involves specifying a call to a contract function rather than any of the built-in operations Stellar offers. When building these contract calls, it is necessary to specify the relevant contract ID and function arguments according to the contract interface. See more at [Documentation for Contract Interaction - Stellar Transaction](../../../learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx).
+
+You can still use the libraries or tools you’re already familiar with to assemble these transactions, [but keep in mind the extra steps required for contract invocation](../../../build/guides/transactions/invoke-contract-tx-sdk.mdx).
+
+### Simulating Transaction
+
+Transactions that execute smart contracts must be [simulated](../../../build/guides/transactions/simulateTransaction-Deep-Dive.mdx) before sending. That is because simulation doesn’t just provide the results of executing transactions; it also provides essential information such as the transaction’s read/write [footprint](../../../learn/encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx#footprint) and [authorizations](../../../learn/encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx#authorization) needed, and clients must add this information to the transaction before sending it to the network for execution.
+
+### Signing & Auth Entries
+
+Smart contracts can define their own [custom authorization logic](../../../learn/encyclopedia/security/authorization.mdx), meaning you might need [additional signatures for specific authorization data](../../../learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx#authorization-data) to prove permission for certain contract calls. Each contract can have its own requirements, so a good practice is to [leverage transaction simulations to identify specific authorization requirements for a transaction](../../../learn/encyclopedia/contract-development/contract-interactions/transaction-simulation.mdx#authorization).
+
+### Asynchronous Transaction Submission
+
+Unlike Horizon, [RPC only queues transactions for inclusion rather than waiting for final confirmation](../../../data/rpc/api-reference/methods/sendTransaction). Therefore, it is necessary to [poll the transaction’s status](../../../data/rpc/api-reference/methods/getTransaction) to determine if a transaction eventually succeeds or fails. This asynchronous model, as well as other common challenges, can be seen at the [Documentation for Dapp Development - Common Pitfalls](../../../build/guides/dapps/frontend-guide.mdx#7-common-pitfalls).

docs/build/guides/basics/send-and-receive-payments.mdx

@@ -25,7 +25,7 @@ In the following code samples, proper error checking is omitted for brevity. How
 
 ## Send a Payment
 
-Stellar stores and communicates transaction data in a binary format called [XDR](../../../learn/encyclopedia/data-format/xdr.mdx), which is optimized for network performance but unreadable to the human eye. Luckily, [Horizon](../../../data/horizon/README.mdx), the Stellar API, and the [Stellar SDKs](../../../tools/sdks/library.mdx) convert XDRs into friendlier formats. Here’s how you might send 10 lumens to an account:
+Stellar stores and communicates transaction data in a binary format called [XDR](../../../learn/encyclopedia/data-format/xdr.mdx), which is optimized for network performance but unreadable to the human eye. Luckily, [Horizon](../../../data/horizon/README.mdx), the Stellar API, and the [Stellar SDKs](../../../tools/sdks/README.mdx) convert XDRs into friendlier formats. Here’s how you might send 10 lumens to an account:
 
 <CodeExample>
 

docs/build/guides/conventions/deploy-sac-with-code.mdx

@@ -20,7 +20,7 @@ description: Deploy a SAC for a Stellar asset using Javascript SDK
 
 ## Overview
 
-In this guide, you'll learn how to deploy a [Stellar Asset Contract (SAC)](../../../tokens/stellar-asset-contract.mdx) for a Stellar asset using the [Stellar SDK](../../../tools/sdks/library.mdx#javascript-sdk). The Stellar SDK is a set of tools and library designed to help developers build applications that interact with the Stellar blockchain network.
+In this guide, you'll learn how to deploy a [Stellar Asset Contract (SAC)](../../../tokens/stellar-asset-contract.mdx) for a Stellar asset using the [Stellar SDK](../../../tools/sdks/client-sdks.mdx#javascript-sdk). The Stellar SDK is a set of tools and library designed to help developers build applications that interact with the Stellar blockchain network.
 
 ### Prerequisites:
 

docs/build/guides/conventions/extending-wasm-ttl.mdx

@@ -96,7 +96,7 @@ impl ExtendTTLContract {
 </TabItem>
 <TabItem value="js" label="JS">
 
-The code below uses Nodejs environment but same concept can also be applied in the browser using Freighter wallet or using any other [Stellar SDK](../../../tools/sdks/library.mdx).
+The code below uses Nodejs environment but same concept can also be applied in the browser using Freighter wallet or using any other [Stellar SDK](../../../tools/sdks/client-sdks.mdx).
 
 ```javascript
 import * as StellarSdk from "@stellar/stellar-sdk";

docs/build/guides/dapps/working-with-contract-specs.mdx

@@ -22,10 +22,10 @@ These details guide how you interact with the contract, regardless of the progra
 Before diving into contract interactions, ensure you have the following:
 
 - Stellar CLI ([`stellar`](../../smart-contracts/getting-started/setup.mdx#install-the-stellar-cli)) installed
-- A Soroban-compatible SDK for your programming language. View the [list of available SDKs](../../../tools/sdks/library.mdx) to find one that suits your needs
+- A Soroban-compatible SDK for your programming language. View the [list of available SDKs](../../../tools/sdks/README.mdx) to find one that suits your needs
 - Access to a Stellar [RPC server](../../../learn/fundamentals/networks.mdx) (local or on a test network)
 
-For this guide, we will focus on the [Java](/docs/tools/sdks/library#java-sdk), [Python](/docs/tools/sdks/library#python-sdk), and [PHP](/docs/tools/sdks/library#php-sdk) SDKs for reference, but the concepts can also be applied to other languages.
+For this guide, we will focus on the [Java](../../../tools/sdks/client-sdks.mdx#java-sdk), [Python](../../../tools/sdks/client-sdks.mdx#python-sdk), and [PHP](../../../tools/sdks/client-sdks.mdx#php-sdk) SDKs for reference, but the concepts can also be applied to other languages.
 
 ## What are contract specs?
 

docs/build/guides/testing/differential-tests.mdx

@@ -52,10 +52,10 @@ Assuming the contract has been deployed, and changes are being made to the local
 
    #[test]
    fn differential_test() {
-       let env = Env::default();
        assert_eq!(
            // Baseline – the deployed contract
            {
+               let env = Env::default();
                let contract_id = env.register(deployed::WASM, ());
                let client = IncrementContractClient::new(&env, &contract_id);
                (
@@ -66,11 +66,12 @@ Assuming the contract has been deployed, and changes are being made to the local
                        client.increment(),
                    ),
                    // Events
-                   env.events.all(),
+                   env.events().all(),
                )
            },
            // Local – the changed or refactored contract
            {
+               let env = Env::default();
                let contract_id = env.register(IncrementContract, ());
                let client = IncrementContractClient::new(&env, &contract_id);
                (
@@ -81,7 +82,7 @@ Assuming the contract has been deployed, and changes are being made to the local
                        client.increment(),
                    ),
                    // Events
-                   env.events.all(),
+                   env.events().all(),
                )
            },
        );
@@ -104,12 +105,6 @@ Differential tests work best when less assumptions are made. Rather than asserti
 
 :::
 
-:::info
-
-Depending on the test complexity it can be desirable to use an independent `Env` for testing the deployed vs local. However at the moment it is only possible to compare host values, like `String`, `Bytes`, `Vec`, `Map`, if they've been created using the same `Env`. The tracking issue for supportin comparisons across environments is [stellar/rs-soroban-sdk#1360].
-
-:::
-
 [Getting Started]: ../../smart-contracts/getting-started
 [increment example]: https://github.com/stellar/soroban-examples/blob/main/increment/src/lib.rs
 [Differential Testing with Test Snapshots]: ./differential-tests-with-test-snapshots.mdx

docs/build/guides/testing/integration-tests-with-mainnet-data.mdx → docs/build/guides/testing/fork-testing.mdx

@@ -1,11 +1,11 @@
 ---
-title: Integration Tests with Mainnet Data
+title: Fork Testing
 hide_table_of_contents: true
-description: Integration testing uses dependency contracts instead of mocks.
+description: Integration testing using mainnet data.
 sidebar_position: 6
 ---
 
-Testing with mainnet data is another form of [integration test], where not only mainnet contracts can be used, but also their data on mainnet.
+Fork testing is another form of [integration test], where not only mainnet contracts can be used, but also their data on mainnet. A snapshot of the ledger is taken and used to create an environment for testing. The test operates as a fork of that initial state.
 
 Our ability to test a contract that relies on another contract is limited to our own knowledge of this other contract and the different states it can get into. Integration testing, where real dependencies are used removes some assumptions, but if a dependency has complex state it may also be useful to test against mainnet data as it exists at different points in time.
 
@@ -79,5 +79,5 @@ A snapshot can be created of any contract deployed to mainnet or testnet using t
 [pause contract]: https://github.com/stellar/soroban-examples/blob/main/pause/src/lib.rs
 [integration test]: ./integration-tests.mdx
 [Making Cross-Contract Calls]: ../conventions/cross-contract.mdx
-[Soroban Rust SDK]: ../../../tools/sdks/library.mdx#soroban-rust-sdk
+[Soroban Rust SDK]: ../../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk
 [Stellar CLI]: ../../../tools/developer-tools/cli/README.mdx

docs/build/guides/testing/integration-tests.mdx

@@ -69,4 +69,4 @@ Most tests, whether they're unit, mocks, or integration tests, will look very si
 [pause contract]: https://github.com/stellar/soroban-examples/blob/main/pause/src/lib.rs
 [Integration Tests]: ./integration-tests.mdx
 [Making Cross-Contract Calls]: ../conventions/cross-contract.mdx
-[Soroban Rust SDK]: ../../../tools/sdks/library.mdx#soroban-rust-sdk
+[Soroban Rust SDK]: ../../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk

docs/build/guides/testing/mocking.mdx

@@ -123,4 +123,4 @@ The [Soroban Rust SDK] handles contract calls defensively so that any unexpected
 [increment-with-pause contract]: https://github.com/stellar/soroban-examples/blob/main/increment-with-pause/src/lib.rs
 [Integration Tests]: ./integration-tests.mdx
 [Making Cross-Contract Calls]: ../conventions/cross-contract.mdx
-[Soroban Rust SDK]: ../../../tools/sdks/library.mdx#soroban-rust-sdk
+[Soroban Rust SDK]: ../../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk

docs/build/guides/tokens/deploying-a-sac.mdx

@@ -28,7 +28,7 @@ In this guide, you'll learn how to deploy a [Stellar Asset Contract (SAC)](../..
 Before you begin, make sure you have the following:
 
 - Basic understanding of [Rust programming language](https://www.rust-lang.org/). To brush up on Rust, check out [Rustlings](https://github.com/rust-lang/rustlings) or [The Rust book](https://doc.rust-lang.org/book/).
-- [Soroban Rust SDK](../../../tools/sdks/library.mdx#soroban-rust-sdk) installed and configured in your development environment.
+- [Soroban Rust SDK](../../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk) installed and configured in your development environment.
 - Basic understanding of the Soroban Rust SDK and familiarity with Soroban's core concepts and Rust programming.
 
 ## 1. Define the SacDeployer contract

docs/build/smart-contracts/overview.mdx

@@ -21,7 +21,7 @@ Support for other languages may be supported in the future, but at this time, on
 
 ## Soroban Rust SDK
 
-Contracts are developed using a software development kit (SDK). The [Soroban Rust SDK](../../tools/sdks/library.mdx#soroban-rust-sdk) consists of a Rust crate and a command-line tool.
+Contracts are developed using a software development kit (SDK). The [Soroban Rust SDK](../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk) consists of a Rust crate and a command-line tool.
 
 The SDK crate acts as a substitute for the Rust standard library — providing data structures and utility functions for contracts — as well as providing access to smart-contract-specific functionality from the contract environment, like cryptographic hashing and signature verification, access to on-chain persistent storage, and location and invocation of secondary contracts via stable identifiers.
 

docs/data/horizon/README.mdx

@@ -15,7 +15,7 @@ On August 1, 2024, the SDF truncated historical data on its Horizon instances to
 
 Horizon provides an HTTP API to data in the Stellar network. It ingests and re-serves the data produced by the Stellar network in a form that is easier to consume by the average application relative to the performance-oriented data representations used by Stellar Core. This API serves the bridge between apps and [Stellar Core](../../validators/README.mdx). Projects like wallets, decentralized exchanges, and asset issuers use Horizon to submit transactions, query an account balance, or stream events like transactions to an account.
 
-Horizon can be accessed via cURL, a browser, or one of the [Stellar SDKs](../../tools/sdks/library.mdx). To reduce the complexity of your project, we recommend you use an SDK instead of making direct API calls.
+Horizon can be accessed via cURL, a browser, or one of the [Stellar SDKs](../../tools/sdks/README.mdx). To reduce the complexity of your project, we recommend you use an SDK instead of making direct API calls.
 
 This guide describes how to administer a production Horizon instance (refer to the [Developers' Blog](https://www.stellar.org/developers-blog/a-new-sun-on-the-horizon) for some background on the performance and architectural improvements of this major version bump). For information about developing on the Horizon codebase, check out the [Development Guide](https://github.com/stellar/go/blob/master/services/horizon/internal/docs/GUIDE_FOR_DEVELOPERS.md).
 

docs/data/migrate-from-horizon-to-rpc/README.mdx

@@ -82,7 +82,7 @@ In the interim the [`getTransactions`] method can be used to retrieve the meta X
 [RPC JSON-RPC API]: rpc/api-reference
 [JSON-RPC]: rpc/api-reference/json-rpc
 [Data]: ../data
-[SDKs]: ../tools/sdks/library
+[SDKs]: ../tools/sdks
 [`GET /`]: horizon/api-reference
 [`GET /ledgers`]: horizon/api-reference/list-all-ledgers
 [`GET /ledgers/{seq}`]: horizon/api-reference/retrieve-a-ledger

docs/data/rpc/admin-guide.mdx

@@ -11,7 +11,7 @@ The RPC service allows you to communicate directly with Soroban via a [JSON RPC
 
 For example, you can build an application and have it [send a transaction](./api-reference/methods/getTransaction.mdx), [get ledger](./api-reference/methods/getLedgerEntries.mdx) and [event data](./api-reference/methods/getEvents.mdx), or [simulate transactions](./api-reference/methods/simulateTransaction.mdx).
 
-Alternatively, you can use one of Soroban's [client SDKs](/docs/tools/sdks/library), such as the [@stellar/stellar-sdk](/docs/tools/sdks/library#javascript-sdk), which will need to communicate with an RPC instance to access the network.
+Alternatively, you can use one of Soroban's [client SDKs](/docs/tools/sdks/client-sdks), such as the [@stellar/stellar-sdk](/docs/tools/sdks/client-sdks#javascript-sdk), which will need to communicate with an RPC instance to access the network.
 
 ## Run Your Own Instance for Development
 

docs/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx

@@ -458,7 +458,7 @@ The `hostFunction` in `InvokeHostFunctionOp` will be executed by the Soroban hos
 
 ##### JavaScript Usage
 
-Each of these variations of host function invocation has convenience methods in the [JavaScript SDK](../../../../tools/sdks/library.mdx#javascript-sdk):
+Each of these variations of host function invocation has convenience methods in the [JavaScript SDK](../../../../tools/sdks/client-sdks.mdx#javascript-sdk):
 
 - [`Operation.invokeHostFunction`](https://stellar.github.io/js-stellar-sdk/Operation.html#.invokeHostFunction) is the lowest-level method that corresponds directly to the XDR.
 - [`Operation.invokeContractFunction`](https://stellar.github.io/js-stellar-sdk/Operation.html#.invokeContractFunction) is an abstraction to invoke the method of a particular contract, similar to [`Contract.call`](https://stellar.github.io/js-stellar-sdk/Contract.html#call).

docs/learn/encyclopedia/contract-development/types/built-in-types.mdx

@@ -20,7 +20,7 @@ description: Built-in types used as smart contract inputs and outputs.
 Built-in types are available to all contracts for use as contract function inputs and outputs, and are defined by the [environment] and the [Rust SDK].
 
 [environment]: ../environment-concepts.mdx
-[rust sdk]: ../../../../tools/sdks/library.mdx#soroban-rust-sdk
+[rust sdk]: ../../../../tools/sdks/contract-sdks.mdx#soroban-rust-sdk
 
 :::tip