Rebrand soroban-rpc to stellar-rpc

stellar · Sep 30, 2024 · ab91a56 · ab91a56
1 parent 27c1fa2
commit ab91a56
Show file tree

Hide file tree

Showing 31 changed files with 76 additions and 76 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'},
   ],

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/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,16 +1,16 @@
 ---
 title: Ingest events published from a contract
-description: Use Soroban RPC's getEvents method for querying events, with a 24-hour retention window
+description: Use Stellar RPC's getEvents method for querying events, with a 24-hour retention window
 ---
 
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
-Soroban RPC provides a `getEvents` method which allows you to query events from a smart contract. However, the data retention window for these events is roughly 24 hours. If you need access to a longer-lived record of these events you'll want to "ingest" the events as they are published, maintaining your own record or database as events are ingested.
+Stellar RPC provides a `getEvents` method which allows you to query events from a smart contract. However, the data retention window for these events is roughly 24 hours. If you need access to a longer-lived record of these events you'll want to "ingest" the events as they are published, maintaining your own record or database as events are ingested.
 
 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/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._
 

diff --git a/docs/data/rpc/README.mdx b/docs/data/rpc/README.mdx
@@ -3,7 +3,7 @@ title: RPC Introduction
 sidebar_position: 5
 ---
 
-The Soroban-RPC can be described as a "live network gateway for Soroban." It provides information that the network currently has in its view (i.e. current state). It also has the ability to send a transaction to the network, and query the network for the status of previously sent transactions. It is meant to be simple, minimal, scalable, and familiar to blockchain developers from other ecosystems.
+The Stellar-RPC can be described as a "live network gateway for Soroban." It provides information that the network currently has in its view (i.e. current state). It also has the ability to send a transaction to the network, and query the network for the status of previously sent transactions. It is meant to be simple, minimal, scalable, and familiar to blockchain developers from other ecosystems.
 
 Soroban-RPC should provide all the basic data that a dapp developer would need, provided they are: