Rename Soroban RPC to Stellar RPC (#1064)

stellar · Nov 15, 2024 · 479cc1d · 479cc1d
1 parent 143aee6
commit 479cc1d
Show file tree

Hide file tree

Showing 47 changed files with 149 additions and 143 deletions.
diff --git a/config/sidebars.ts b/config/sidebars.ts
@@ -23,7 +23,7 @@ const sidebars: SidebarsConfig = {
     'data/README',
     'data/requirements',
     { type: 'html', value: '<small>Data Availability</small>', defaultStyle: true, className: 'networkMenuHtmlItem'},
-    { type: 'ref', id: 'data/rpc/README', label: 'Soroban RPC'},
+    { type: 'ref', id: 'data/rpc/README', label: 'Stellar RPC'},
     { type: 'ref', id: 'data/hubble/README', label: 'Hubble'},
     { type: 'ref', id: 'data/horizon/README', label: 'Horizon'},
     { type: 'ref', id: 'data/galexie/README', label: 'Galexie'},
@@ -91,7 +91,7 @@ const sidebars: SidebarsConfig = {
   soroban_rpc: [
     {
       type: "category",
-      label: "Soroban RPC",
+      label: "Stellar RPC",
       items: [
         {
           type: 'autogenerated',

diff --git a/docs/build/guides/basics/automate-reset-data.mdx b/docs/build/guides/basics/automate-reset-data.mdx
@@ -22,7 +22,7 @@ Stellar operates two primary testing environments: the [Testnet and the Futurene
 
 ## What is the Testnet and Futurenet reset?
 
-Testnet and Futurenet are reset periodically to the genesis ledger to declutter the network, remove spam, reduce the time needed to catch up on the latest ledger, and help maintain the system. These resets take place approximately quarterly. Resets clear all ledger entries (accounts, trustlines, offers, smart contract data, etc.), transactions, and historical data from Stellar Core, Horizon, and the Soroban RPC, which is why developers should not rely on the persistence of accounts or the state of any balances when using Testnet or Futurenet.
+Testnet and Futurenet are reset periodically to the genesis ledger to declutter the network, remove spam, reduce the time needed to catch up on the latest ledger, and help maintain the system. These resets take place approximately quarterly. Resets clear all ledger entries (accounts, trustlines, offers, smart contract data, etc.), transactions, and historical data from Stellar Core, Horizon, and the Stellar RPC, which is why developers should not rely on the persistence of accounts or the state of any balances when using Testnet or Futurenet.
 
 You can check current reset dates [here](../../../learn/fundamentals/networks.mdx#testnet-and-futurenet-data-reset).
 

diff --git a/docs/build/guides/conventions/extending-wasm-ttl.mdx b/docs/build/guides/conventions/extending-wasm-ttl.mdx
@@ -14,7 +14,7 @@ This guide will show you how to extend the TTL of a deployed contract's Wasm cod
 ## Prerequisites
 
 - Stellar SDK: `npm install @stellar/stellar-sdk`
-- A Soroban RPC endpoint (e.g., `https://soroban-testnet.stellar.org`)
+- A Stellar RPC endpoint (e.g., `https://soroban-testnet.stellar.org`)
 - Basic knowledge of Stellar SDK
 
 ## Process overview

diff --git a/docs/build/guides/dapps/docker.mdx b/docs/build/guides/dapps/docker.mdx
@@ -131,7 +131,7 @@ The `quickstart.sh` script sets up the Docker environment for running the dapp.
 - Creates the Docker network named `soroban-network` if it doesn't exist.
 - Removes any existing `soroban-preview` Docker container.
 - Runs the `soroban-preview` container, which provides the Soroban Preview environment for development.
-- Runs the `stellar/quickstart` Docker image, which sets up the Stellar network using the chosen network type and enables Soroban RPC.
+- Runs the `stellar/quickstart` Docker image, which sets up the Stellar network using the chosen network type and enables Stellar RPC.
 
 [`stellar/quickstart` docker image]: https://hub.docker.com/r/stellar/quickstart
 [example crowdfund dapp]: https://github.com/stellar/soroban-example-dapp
diff --git a/docs/build/guides/dapps/frontend-guide.mdx b/docs/build/guides/dapps/frontend-guide.mdx
@@ -743,7 +743,7 @@ This is made possible by using the `server.getEvents` method which allows you to
 
 We will be editing the `CounterPage` component to read events from the counter smart contract immediately the page loads to get the initial counter value and update instead of using "Unknown". Before we continue, please take a look at the [contract code](https://github.com/stellar/soroban-examples/blob/main/events/src/lib.rs). In the contract code, an event named `increment` is emitted whenever the `increment` function is called. It is published over 2 topics, `increment` and `COUNTER` and we need to listen to these topics to get the events.
 
-The topics are stored in a data type called `symbol` and we will need to convert both `increment` and `COUNTER` to `symbol` before we can use them in the [`server.getEvents`](https://developers.stellar.org/docs/data/rpc/api-reference/methods/getEvents) method. At maximum, soroban RPCs keep track of events for 7 days and you can query events that happened within the last 7 days, so if you need to store events for longer, you may need to make use of an [indexer](/docs/tools/developer-tools/data-indexers).
+The topics are stored in a data type called `symbol` and we will need to convert both `increment` and `COUNTER` to `symbol` before we can use them in the [`server.getEvents`](https://developers.stellar.org/docs/data/rpc/api-reference/methods/getEvents) method. At maximum, stellar RPCs keep track of events for 7 days and you can query events that happened within the last 7 days, so if you need to store events for longer, you may need to make use of an [indexer](/docs/tools/developer-tools/data-indexers).
 
 To use events,we edit our counter page and add the following code:
 

diff --git a/docs/build/guides/dapps/initialization.mdx b/docs/build/guides/dapps/initialization.mdx
@@ -199,8 +199,8 @@ echo "Done"
 Here's a summary of what the `initialize.sh` script does:
 
 - Identifies the network (standalone or futurenet) based on user input
-- Determines the Soroban RPC host URL depending on its execution environment (either inside the soroban-preview Docker container or locally)
-- Sets the Soroban RPC URL based on the previously determined host URL
+- Determines the Stellar RPC host URL depending on its execution environment (either inside the soroban-preview Docker container or locally)
+- Sets the Stellar RPC URL based on the previously determined host URL
 - Sets the Soroban network passphrase and Friendbot URL depending on the chosen network
 - Adds the network configuration using `stellar network add`
 - Generates a token-admin identity using `stellar keys generate`

diff --git a/docs/build/guides/dapps/state-archival.mdx b/docs/build/guides/dapps/state-archival.mdx
@@ -131,7 +131,7 @@ When developing a dapp on Stellar, you may encounter situations where contract d
 
 - Stellar SDK: `npm install @stellar/stellar-sdk`
 - Freighter API: `npm install @stellar/freighter-api`
-- A Soroban RPC endpoint (e.g., `https://soroban-testnet.stellar.org`)
+- A Stellar RPC endpoint (e.g., `https://soroban-testnet.stellar.org`)
 
 #### Step 1: Set up the SDK and Freighter
 

diff --git a/docs/build/guides/events/consume.mdx b/docs/build/guides/events/consume.mdx
@@ -3,7 +3,7 @@ title: Consume previously ingested events
 description: Consume ingested events without querying the RPC again
 ---
 
-Once events have been ingested into a database, for instance as done in the [ingest guide], they can be consumed without having the need to query again Soroban RPC. In the following, we will show how we can consume these events.
+Once events have been ingested into a database, for instance as done in the [ingest guide], they can be consumed without having the need to query again Stellar RPC. In the following, we will show how we can consume these events.
 
 Let's get started!
 
@@ -182,7 +182,7 @@ Event listener: {'topic_1': 'transfer', 'topic_2': <Address [type=ACCOUNT, addre
 INFO sqlalchemy.engine.Engine COMMIT
 ```
 
-Congratulations, you are ready to consume events from Soroban RPC!
+Congratulations, you are ready to consume events from Stellar RPC!
 
 ## Going further
 

diff --git a/docs/build/guides/events/ingest.mdx b/docs/build/guides/events/ingest.mdx
@@ -1,6 +1,6 @@
 ---
 title: Ingest events published from a contract
-description: Use Soroban RPC's getEvents method for querying events, with a 7 day retention window
+description: Use Stellar RPC's getEvents method for querying events, with a 7 day retention window
 ---
 
 import Tabs from "@theme/Tabs";
@@ -10,7 +10,7 @@ Soroban RPC provides a `getEvents` method which allows you to query events from
 
 There are many strategies you can use to ingest and keep the events published by a smart contract. Among the simplest might be using a community-developed tool such as [Mercury](https://mercurydata.app) which will take all the infrastructure work off your plate for a low subscription fee.
 
-Another approach we'll explore here is using a cron job to query Soroban RPC periodically and store the relevant events in a locally stored SQLite database. We are going to use an Object Relational Mapper (ORM), allowing us to write database query directly in Python or JavaScript.
+Another approach we'll explore here is using a cron job to query Stellar RPC periodically and store the relevant events in a locally stored SQLite database. We are going to use an Object Relational Mapper (ORM), allowing us to write database query directly in Python or JavaScript.
 
 ## Setup
 
@@ -125,13 +125,13 @@ Using a database model is very convenient as it allows us to control the databas
 
 We'll use this model to create and query for the events stored in our database.
 
-## Query Events from Soroban RPC
+## Query Events from Stellar RPC
 
-First, we'll need to query the events from Soroban RPC. This simple example makes an RPC request using the `getEvents` method, filtering for all `transfer` events that are emitted by the native XLM contract.
+First, we'll need to query the events from Stellar RPC. This simple example makes an RPC request using the `getEvents` method, filtering for all `transfer` events that are emitted by the native XLM contract.
 
 :::note
 
-We are making some assumptions here. We'll assume that your contract sees enough activity, and that you are querying for events frequently enough that you aren't in danger of needing to figure out the oldest ledger Soroban RPC is aware of. The approach we're taking is to find the largest (most recent) ledger sequence number in the database and query for events starting there. Your use-case may require some logic to determine what the latest ledger is, and what the oldest ledger available is, etc.
+We are making some assumptions here. We'll assume that your contract sees enough activity, and that you are querying for events frequently enough that you aren't in danger of needing to figure out the oldest ledger Stellar RPC is aware of. The approach we're taking is to find the largest (most recent) ledger sequence number in the database and query for events starting there. Your use-case may require some logic to determine what the latest ledger is, and what the oldest ledger available is, etc.
 
 :::
 
@@ -158,7 +158,7 @@ with orm.Session(engine) as session:
     ledger = session.scalars(stmt).first()
 ```
 
-Let's get events from Soroban RPC!
+Let's get events from Stellar RPC!
 
 ```python
 from stellar_sdk.soroban_rpc import EventFilter, EventFilterType

diff --git a/docs/build/guides/rpc/retrieve-contract-code-js.mdx b/docs/build/guides/rpc/retrieve-contract-code-js.mdx
@@ -92,7 +92,7 @@ console.log(
 // OUTPUT: AAAAB+QzbW3JDhlUbDVW/C+1/5SIQDstqORuhpCyl73O1vH6
 ```
 
-Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `ContractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to the Soroban-RPC endpoint.
+Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `ContractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to the Stellar-RPC endpoint.
 
 ```json
 {

diff --git a/docs/build/guides/rpc/retrieve-contract-code-python.mdx b/docs/build/guides/rpc/retrieve-contract-code-python.mdx
@@ -90,7 +90,7 @@ print(
 # OUTPUT: AAAAB+QzbW3JDhlUbDVW/C+1/5SIQDstqORuhpCyl73O1vH6
 ```
 
-Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `ContractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to the Soroban-RPC endpoint.
+Now, finally we have a `LedgerKey` that correspond to the Wasm byte-code that has been deployed under the `ContractId` we started out with so very long ago. This `LedgerKey` can be used in a final request to the Stellar-RPC endpoint.
 
 ```json
 {

diff --git a/docs/build/guides/transactions/invoke-contract-tx-sdk.mdx b/docs/build/guides/transactions/invoke-contract-tx-sdk.mdx
@@ -37,7 +37,7 @@ Please go to [the project homepage](https://github.com/stellar/js-stellar-sdk) o
     "SCQN3XGRO65BHNSWLSHYIR4B65AHLDUQ7YLHGIWQ4677AZFRS77TCZRB",
   );
 
-  // Configure SorobanClient to use the `soroban-rpc` instance of your
+  // Configure SorobanClient to use the `stellar-rpc` instance of your
   // choosing.
   const server = new SorobanRpc.Server(
     "https://soroban-testnet.stellar.org:443",
@@ -89,7 +89,7 @@ Please go to [the project homepage](https://github.com/stellar/js-stellar-sdk) o
       .toXDR("base64")}`,
   );
 
-  // Submit the transaction to the Soroban-RPC server. The RPC server will
+  // Submit the transaction to the Stellar-RPC server. The RPC server will
   // then submit the transaction into the network for us. Then we will have to
   // wait, polling `getTransaction` until the transaction completes.
   try {
@@ -160,7 +160,7 @@ network_passphrase = Network.TESTNET_NETWORK_PASSPHRASE
 contract_id = "CDOGJBJMRVVXW5K3UJ5BGVJ5RSQXQB4UFVQYVFOIARC2UYXSEPF4YAVR"
 # The source account will be used to sign and send the transaction.
 source_keypair = Keypair.from_secret(secret)
-# Configure SorobanClient to use the `soroban-rpc` instance of your choosing.
+# Configure SorobanClient to use the `stellar-rpc` instance of your choosing.
 soroban_server = SorobanServer(rpc_server_url)
 # Transactions require a valid sequence number (which varies from one account to another).
 # We fetch this sequence number from the RPC server.
@@ -198,7 +198,7 @@ tx.sign(source_keypair)
 # Let's see the base64-encoded XDR of the transaction we just built.
 print(f"Signed prepared transaction XDR: {tx.to_xdr()}")
 
-# Submit the transaction to the Soroban-RPC server. The RPC server will
+# Submit the transaction to the Stellar-RPC server. The RPC server will
 # then submit the transaction into the network for us. Then we will have to
 # wait, polling `get_transaction` until the transaction completes.
 send_transaction_data = soroban_server.send_transaction(tx)
@@ -266,7 +266,7 @@ public class Example {
         // The source account will be used to sign and send the transaction.
         KeyPair sourceKeypair = KeyPair.fromSecretSeed("SAAPYAPTTRZMCUZFPG3G66V4ZMHTK4TWA6NS7U4F7Z3IMUD52EK4DDEV");
 
-        // Configure SorobanClient to use the `soroban-rpc` instance of your choosing.
+        // Configure SorobanClient to use the `stellar-rpc` instance of your choosing.
         SorobanServer sorobanServer = new SorobanServer("https://soroban-testnet.stellar.org");
 
         // Here we will use a deployed instance of the `increment` example contract.
@@ -314,7 +314,7 @@ public class Example {
         // Let's see the base64-encoded XDR of the transaction we just built.
         System.out.println("Signed prepared transaction XDR: " + transaction.toEnvelopeXdrBase64());
 
-        // Submit the transaction to the Soroban-RPC server. The RPC server will then
+        // Submit the transaction to the Stellar-RPC server. The RPC server will then
         // submit the transaction into the network for us. Then we will have to wait,
         // polling `getTransaction` until the transaction completes.
         SendTransactionResponse response = sorobanServer.sendTransaction(transaction);

diff --git a/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx b/docs/build/guides/transactions/simulateTransaction-Deep-Dive.mdx
@@ -5,7 +5,7 @@ description: simulateTransaction examples and tutorials guide
 
 ## Overview
 
-The `simulateTransaction` endpoint in Soroban RPC allows you to submit a trial contract invocation to simulate how it would be executed by the Stellar network. This simulation calculates the effective transaction data, required authorizations, and minimal resource fee. It provides a way to test and analyze the potential outcomes of a transaction without actually submitting it to the network. It can be a nice way to get contract data as well sometimes.
+The `simulateTransaction` endpoint in Stellar RPC allows you to submit a trial contract invocation to simulate how it would be executed by the Stellar network. This simulation calculates the effective transaction data, required authorizations, and minimal resource fee. It provides a way to test and analyze the potential outcomes of a transaction without actually submitting it to the network. It can be a nice way to get contract data as well sometimes.
 
 While calling the method on the rpc server is not the ONLY way to simulate a transaction, it will likely be the most common and easiest way.
 

diff --git a/docs/build/guides/transactions/submit-transaction-wait-js.mdx b/docs/build/guides/transactions/submit-transaction-wait-js.mdx
@@ -1,10 +1,10 @@
 ---
-title: Submit a transaction to Soroban RPC using the JavaScript SDK
+title: Submit a transaction to Stellar RPC using the JavaScript SDK
 hide_table_of_contents: true
 description: Use a looping mechanism to submit a transaction to the RPC
 ---
 
-Here is a simple, rudimentary looping mechanism to submit a transaction to Soroban RPC and wait for a result.
+Here is a simple, rudimentary looping mechanism to submit a transaction to Stellar RPC and wait for a result.
 
 ```typescript
 import {

diff --git a/docs/data/horizon/api-reference/resources/transactions/README.mdx b/docs/data/horizon/api-reference/resources/transactions/README.mdx
@@ -5,7 +5,7 @@ order: 0
 
 :::info
 
-Transaction meta `result_meta_xdr` will be removed from the SDF hosted Horizon API (`horizon.stellar.org`) in Q3 2024. Instead of using Horizon to access transaction metadata, developers could access it with the [`getTransactions`](../../../../rpc/api-reference/methods/getTransactions.mdx) endpoint in the Soroban RPC.
+Transaction meta `result_meta_xdr` will be removed from the SDF hosted Horizon API (`horizon.stellar.org`) in Q3 2024. Instead of using Horizon to access transaction metadata, developers could access it with the [`getTransactions`](../../../../rpc/api-reference/methods/getTransactions.mdx) endpoint in the Stellar RPC.
 
 :::
 

diff --git a/docs/data/horizon/api-reference/resources/transactions/object.mdx b/docs/data/horizon/api-reference/resources/transactions/object.mdx
@@ -5,7 +5,7 @@ order: 10
 
 :::info
 
-Transaction meta `result_meta_xdr` will be removed from the SDF hosted Horizon API (`horizon.stellar.org`) in Q3 2024. Instead of using Horizon to access transaction metadata, developers could access it with the [`getTransactions`](../../../../rpc/api-reference/methods/getTransactions.mdx) endpoint in the Soroban RPC.
+Transaction meta `result_meta_xdr` will be removed from the SDF hosted Horizon API (`horizon.stellar.org`) in Q3 2024. Instead of using Horizon to access transaction metadata, developers could access it with the [`getTransactions`](../../../../rpc/api-reference/methods/getTransactions.mdx) endpoint in the Stellar RPC.
 
 :::
 

diff --git a/docs/data/requirements.mdx b/docs/data/requirements.mdx
@@ -10,7 +10,7 @@ Here you can find the requirements for running the various types of nodes the op
 | Core Validator Node | 8x Intel Xeon @ 3.4 GHz | 16 GB | 100 GB NVMe SSD | [c5d.2xlarge] | [n4-highcpu-8] | [Click here](../validators/admin-guide/README.mdx) |
 | Horizon API Service | 4 vCPU | 16 GB | 100 GB SSD >= 1.5K IOPS | [c5d.xlarge] | [n4-standard-4] | [Click here](./horizon/admin-guide/overview.mdx) |
 | Horizon PostgreSQL | 4 vCPU | 32 GB | 2 TB\* SSD (NVMe or Direct Attached Storage) >= 7K IOPS | [i4g.xlarge] | [c3-highmem-8] | [Click here](./horizon/admin-guide/overview.mdx) |
-| Soroban RPC | 2 vCPU | 4 GB | 30 GB persistent volume >= 3K IOPS | [c5.large] | [n4-highcpu-2] | [Click here](./rpc/admin-guide.mdx) |
+| Stellar RPC | 2 vCPU | 4 GB | 30 GB persistent volume >= 3K IOPS | [c5.large] | [n4-highcpu-2] | [Click here](./rpc/admin-guide.mdx) |
 
 _\* Assuming a 30-day retention window for data storage._