From 479cc1d53d51d312b051c7decef3ebffe0b359ad Mon Sep 17 00:00:00 2001 From: Alfonso Acosta Date: Fri, 15 Nov 2024 17:31:37 +0100 Subject: [PATCH] Rename Soroban RPC to Stellar RPC (#1064) --- config/sidebars.ts | 4 +- .../guides/basics/automate-reset-data.mdx | 2 +- .../guides/conventions/extending-wasm-ttl.mdx | 2 +- docs/build/guides/dapps/docker.mdx | 2 +- docs/build/guides/dapps/frontend-guide.mdx | 2 +- docs/build/guides/dapps/initialization.mdx | 4 +- docs/build/guides/dapps/state-archival.mdx | 2 +- docs/build/guides/events/consume.mdx | 4 +- docs/build/guides/events/ingest.mdx | 12 ++-- .../guides/rpc/retrieve-contract-code-js.mdx | 2 +- .../rpc/retrieve-contract-code-python.mdx | 2 +- .../transactions/invoke-contract-tx-sdk.mdx | 12 ++-- .../simulateTransaction-Deep-Dive.mdx | 2 +- .../submit-transaction-wait-js.mdx | 4 +- .../resources/transactions/README.mdx | 2 +- .../resources/transactions/object.mdx | 2 +- docs/data/requirements.mdx | 2 +- docs/data/rpc/README.mdx | 24 +++++--- docs/data/rpc/admin-guide.mdx | 56 +++++++++---------- docs/data/rpc/api-reference/json-rpc.mdx | 8 +-- .../methods/getLedgerEntries.mdx | 2 +- docs/data/rpc/api-reference/pagination.mdx | 6 +- docs/data/rpc/rpc-providers.mdx | 4 +- .../stellar-transaction.mdx | 12 ++-- .../transaction-lifecycle.mdx | 2 +- .../encyclopedia/storage/state-archival.mdx | 4 +- docs/learn/fundamentals/networks.mdx | 4 +- docs/learn/fundamentals/stellar-stack.mdx | 4 +- .../interactive/dapps/scaffold-soroban.mdx | 4 +- .../migrate/evm/smart-contract-deployment.mdx | 2 +- docs/networks/README.mdx | 2 +- docs/tools/developer-tools/data-indexers.mdx | 2 +- docs/tools/developer-tools/lab/README.mdx | 2 +- docs/tools/sdks/library.mdx | 12 ++-- docs/validators/README.mdx | 2 +- meeting-notes/2024-02-22.mdx | 2 +- openrpc/README.md | 6 +- openrpc/scripts/build.mjs | 4 +- .../contentDescriptors/Pagination.json | 2 +- .../src/stellar-rpc/methods/getEvents.json | 2 +- .../stellar-rpc/methods/getTransaction.json | 2 +- openrpc/src/stellar-rpc/schemas/Hash.json | 2 +- .../stellar-rpc/schemas/LedgerCloseTime.json | 4 +- .../stellar-rpc/schemas/LedgerSequence.json | 4 +- .../stellar-rpc/schemas/NetworkConfig.json | 2 +- .../src/stellar-rpc/schemas/Pagination.json | 2 +- static/stellar-rpc.openrpc.json | 46 +++++++-------- 47 files changed, 149 insertions(+), 143 deletions(-) diff --git a/config/sidebars.ts b/config/sidebars.ts index 4210867f3..0527b9af4 100644 --- a/config/sidebars.ts +++ b/config/sidebars.ts @@ -23,7 +23,7 @@ const sidebars: SidebarsConfig = { 'data/README', 'data/requirements', { type: 'html', value: 'Data Availability', 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 index a9d2698f7..fbe13b563 100644 --- 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 index d6fac11b0..332048cf0 100644 --- 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 index c16c174cc..1002ef49e 100644 --- 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 index a6cc7d79b..5e6685c83 100644 --- 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 index 548429a4d..f72bb9c0b 100644 --- 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 index a2e66b784..86b012b96 100644 --- 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 index 896ed38ba..d011b3c51 100644 --- 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':
= 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 index 81d754d5d..8012b38d9 100644 --- a/docs/data/rpc/README.mdx +++ b/docs/data/rpc/README.mdx @@ -3,25 +3,31 @@ 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. +:::info -Soroban-RPC should provide all the basic data that a dapp developer would need, provided they are: +Stellar-RPC was previously known as Soroban-RPC. Soroban-RPC was renamed as Stellar-RPC in Nov 2024. + +::: + +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. + +Stellar-RPC should provide all the basic data that a dapp developer would need, provided they are: - Only interested in current state data, or are willing to ingest events into their own infrastructure to support reporting/analytics queries. - - Caveat: Soroban-RPC should provide enough data-retention to support reliable ingestion of events. + - Caveat: Stellar-RPC should provide enough data-retention to support reliable ingestion of events. - Only interested in building and submitting Soroban transactions (not Stellar Vanilla). -Soroban-RPC should support the developer from local testing (via the [quickstart] image), all the way through to production deployments. +Stellar-RPC should support the developer from local testing (via the [quickstart] image), all the way through to production deployments. - This implies it should be easy to deploy, and easy to maintain; with low cost, and little "admin" needed. - The developer should be able to simply run the [quickstart] docker image, and quickly be ready to serve requests without needing to set up or maintain dependent infrastructure. ## Anti-Goals -- Soroban-RPC is not a Horizon replacement. Horizon is better suited for historical reporting and analytics queries. Horizon is more concerned with "classic" Stellar data. -- Soroban-RPC should not depend on Horizon. Horizon is expensive and difficult to run, so if Soroban-RPC depended on Horizon, it would inherit that. -- Soroban-RPC should also provide an API basis for infrastructure providers to implement, but not necessarily be an off-the-shelf solution for them. -- Soroban-RPC is not a reporting/analytics tool and does not provide thorough historical data querying. It does not provide any data aggregation, compilations, or multi-server coordination requests. -- Soroban-RPC does not target ultra-low latency. The latency should be low enough to build and submit successful soroban transactions, but supporting high-frequency traders is not the goal. +- Stellar-RPC is not a Horizon replacement. Horizon is better suited for historical reporting and analytics queries. Horizon is more concerned with "classic" Stellar data. +- Stellar-RPC should not depend on Horizon. Horizon is expensive and difficult to run, so if Stellar-RPC depended on Horizon, it would inherit that. +- Stellar-RPC should also provide an API basis for infrastructure providers to implement, but not necessarily be an off-the-shelf solution for them. +- Stellar-RPC is not a reporting/analytics tool and does not provide thorough historical data querying. It does not provide any data aggregation, compilations, or multi-server coordination requests. +- Stellar-RPC does not target ultra-low latency. The latency should be low enough to build and submit successful soroban transactions, but supporting high-frequency traders is not the goal. [quickstart]: https://github.com/stellar/quickstart diff --git a/docs/data/rpc/admin-guide.mdx b/docs/data/rpc/admin-guide.mdx index c9e328112..c6afe6286 100644 --- a/docs/data/rpc/admin-guide.mdx +++ b/docs/data/rpc/admin-guide.mdx @@ -22,12 +22,12 @@ We don't recommend running the Quickstart image in production. See the [deploy y The Quickstart image with the RPC service can run on a standard laptop with 8GB of RAM and has minimal storage and CPU requirements. It is a single container that runs everything you need to test against a fully featured network. It contains: - [Stellar Core] - Node software that runs the network, coordinates consensus, and finalizes ledgers. -- [Soroban RPC] server - JSON RPC server for interacting with Soroban contracts. +- [Stellar RPC] server - JSON RPC server for interacting with Soroban contracts. - [Horizon server] - HTTP API for accessing ledger state and historical transactions. - [Friendbot server] - HTTP API for creating and funding new accounts on test networks. [Stellar Core]: https://github.com/stellar/stellar-core -[Soroban RPC]: https://github.com/stellar/soroban-rpc/tree/main/cmd/soroban-rpc +[Stellar RPC]: https://github.com/stellar/soroban-rpc/tree/main/cmd/soroban-rpc [Horizon server]: https://github.com/stellar/go/tree/master/services/horizon [Friendbot server]: https://github.com/stellar/go/tree/master/services/friendbot @@ -150,19 +150,19 @@ Now you can replace `--network standalone` with `--network futurenet` (or whatev We recommend the following ways to deploy your own RPC instance: 1. Deploy to Kubernetes using [Helm](https://helm.sh/docs/intro/install/) -2. Run the [soroban-rpc docker image](https://hub.docker.com/r/stellar/soroban-rpc) directly +2. Run the [stellar-rpc docker image](https://hub.docker.com/r/stellar/stellar-rpc) directly ### Hardware Requirements -For deployments expecting up to 1000 requests per second to Soroban RPC, we recommend at least 4GB of RAM and at least a dual core CPU with a 2.4GHz clock speed. +For deployments expecting up to 1000 requests per second to Stellar RPC, we recommend at least 4GB of RAM and at least a dual core CPU with a 2.4GHz clock speed. -For deployments expecting 1000-10000+ requests per second to Soroban RPC, we recommend at least 8GB of RAM and at least a quad core CPU with a 2.4GHz clock speed. +For deployments expecting 1000-10000+ requests per second to Stellar RPC, we recommend at least 8GB of RAM and at least a quad core CPU with a 2.4GHz clock speed. For all deployments, we recommend at least 10GB of disk/storage space. | Node Type | CPU | RAM | Disk | AWS SKU | Google Cloud SKU | | --- | --- | --- | --- | --- | --- | -| Soroban RPC | 2 vCPU | 4-8 GB | 30 GB persistent volume >= 3K IOPS | [c5.large] | [n4-highcpu-2] | +| Stellar RPC | 2 vCPU | 4-8 GB | 30 GB persistent volume >= 3K IOPS | [c5.large] | [n4-highcpu-2] | _\* Assuming a 7-day retention window for data storage._ @@ -182,7 +182,7 @@ helm repo update stellar 3. Deploy the RPC instance to Kubernetes using [our Helm chart](https://github.com/stellar/helm-charts/blob/main/charts/soroban-rpc): ```bash -helm install my-rpc stellar/soroban-rpc \ +helm install my-rpc stellar/stellar-rpc \ --namespace my-rpc-namespace-on-cluster \ --set global.image.sorobanRpc.tag=20.0.0-rc4-40 \ --set sorobanRpc.ingress.host=myrpc.example.org \ @@ -194,7 +194,7 @@ helm install my-rpc stellar/soroban-rpc \ This example of Helm chart usage highlights some key aspects: -- Set the `global.image.sorobanRpc.tag` to a tag from the [soroban-rpc dockerhub repo](https://hub.docker.com/r/stellar/soroban-rpc) for the image version you want to run. Refer to [the software versions page](/docs/networks/software-versions) to find the correct tag for the Soroban release you are running. +- Set the `global.image.sorobanRpc.tag` to a tag from the [stellar-rpc dockerhub repo](https://hub.docker.com/r/stellar/stellar-rpc) for the image version you want to run. Refer to [the software versions page](/docs/networks/software-versions) to find the correct tag for the Soroban release you are running. - The RPC server stores a revolving window of recent data from network ledgers to disk. The size of that data varies depending on the network and its transaction volumes, but it has an estimated range between 10 to 100 MB. To ensure the RPC pod has consistent access to disk storage space and read/write throughput, this example demonstrates how to optionally enable the Helm chart deployment to use a `PersistentVolumeClaim` (PVC) of 100MB from `default` storage class on Kubernetes by enabling these persistence parameters: @@ -224,10 +224,10 @@ By default, this is disabled (`sorobanRpc.persistence.enabled=false`) and the RP --set sorobanRpc.resources.limits.memory=2560Mi ``` -Even if you're not deploying Soroban RPC using Kubernetes, the manifests generated by the charts may still be a good reference for showing how to configure and run Soroban RPC as a docker container. Just run the `helm template` command to print the container configuration to screen: +Even if you're not deploying Stellar RPC using Kubernetes, the manifests generated by the charts may still be a good reference for showing how to configure and run Stellar RPC as a docker container. Just run the `helm template` command to print the container configuration to screen: ```bash -helm template my-rpc stellar/soroban-rpc +helm template my-rpc stellar/stellar-rpc ``` ### Docker Image @@ -240,12 +240,12 @@ Although we have a [Quickstart Image](https://github.com/stellar/quickstart), it ::: -Here's how to run the [soroban-rpc docker image](https://hub.docker.com/r/stellar/soroban-rpc): +Here's how to run the [stellar-rpc docker image](https://hub.docker.com/r/stellar/stellar-rpc): -1. Pull the image at the version you'd like to run from [the tags](https://hub.docker.com/r/stellar/soroban-rpc/tags): +1. Pull the image at the version you'd like to run from [the tags](https://hub.docker.com/r/stellar/stellar-rpc/tags): ```bash -docker pull stellar/soroban-rpc +docker pull stellar/stellar-rpc ``` 2. Create a configuration file for [Stellar Core](https://github.com/stellar/stellar-core). Here is a sample configuration file for Testnet: @@ -289,7 +289,7 @@ HISTORY="curl -sf http://history.stellar.org/prd/core-testnet/core_testnet_003/{ ```bash docker run -p 8001:8001 -p 8000:8000 \ --v :/config stellar/soroban-rpc \ +-v :/config stellar/stellar-rpc \ --captive-core-config-path="/config/" \ --captive-core-storage-path="/var/lib/stellar/captive-core" \ --captive-core-use-db=true \ @@ -305,18 +305,18 @@ docker run -p 8001:8001 -p 8000:8000 \ #### Configuration -For production, we recommend running Soroban RPC with a [TOML](https://toml.io/en/) configuration file rather than CLI flags. This is similar to creating a configuration file for Stellar-Core as we did previously. For example, using [our docker image](https://hub.docker.com/r/stellar/soroban-rpc): +For production, we recommend running Stellar RPC with a [TOML](https://toml.io/en/) configuration file rather than CLI flags. This is similar to creating a configuration file for Stellar-Core as we did previously. For example, using [our docker image](https://hub.docker.com/r/stellar/stellar-rpc): ```bash docker run -p 8001:8001 -p 8000:8000 \ --v :/config stellar/soroban-rpc \ +-v :/config stellar/stellar-rpc \ --config-path ``` -You can use Soroban RPC itself to generate a starter configuration file: +You can use Stellar RPC itself to generate a starter configuration file: ```bash -docker run stellar/soroban-rpc gen-config-file > soroban-rpc-config.toml +docker run stellar/stellar-rpc gen-config-file > soroban-rpc-config.toml ``` The resulting configuration should look like this: @@ -335,7 +335,7 @@ The resulting configuration should look like this: CAPTIVE_CORE_STORAGE_PATH = "/" # informs captive core to use on disk mode. the db will by default be created in -# current runtime directory of soroban-rpc, unless DATABASE= setting is +# current runtime directory of stellar-rpc, unless DATABASE= setting is # present in captive core config file. # CAPTIVE_CORE_USE_DB = false @@ -490,7 +490,7 @@ Note that the above generated configuration contains the default values and you ### Build From Source -Instructions for building Soroban RPC from source can be found [here](https://github.com/stellar/soroban-rpc/blob/main/cmd/soroban-rpc/README.md). +Instructions for building Stellar RPC from source can be found [here](https://github.com/stellar/soroban-rpc/blob/main/cmd/soroban-rpc/README.md). ## Use the RPC Instance @@ -512,20 +512,20 @@ See the tip above about command expansion (that's the note about `$(...)`) if yo :::caution -When interacting with the network in production you should run your own soroban-rpc or use a third-party infrastructure provider. +When interacting with the network in production you should run your own stellar-rpc or use a third-party infrastructure provider. ::: ## Verify the RPC Instance -After installation, it will be worthwhile to verify the installation of Soroban RPC is healthy. There are two methods: +After installation, it will be worthwhile to verify the installation of Stellar RPC is healthy. There are two methods: 1. Access the health status endpoint of the JSON RPC service using an HTTP client -2. Use our pre-built [System Test Docker image](https://hub.docker.com/r/stellar/system-test/tags) as a tool to run a set of live tests against Soroban RPC +2. Use our pre-built [System Test Docker image](https://hub.docker.com/r/stellar/system-test/tags) as a tool to run a set of live tests against Stellar RPC ### Health Status Endpoint -If you send a JSON RPC HTTP request to your running instance of Soroban RPC: +If you send a JSON RPC HTTP request to your running instance of Stellar RPC: ```bash curl --location 'http://localhost:8000' \ @@ -566,7 +566,7 @@ docker.io/stellar/system-test:soroban-preview11 \ Make sure you configure the system test correctly: -- Use a published [system test tag](https://hub.docker.com/r/stellar/system-test/tags) that aligns with the deployed Soroban RPC release version. For each release, there will be two tags published for different CPU architectures. Make sure to use the tag that matches your host machine's CPU architecture: +- Use a published [system test tag](https://hub.docker.com/r/stellar/system-test/tags) that aligns with the deployed Stellar RPC release version. For each release, there will be two tags published for different CPU architectures. Make sure to use the tag that matches your host machine's CPU architecture: - `docker.io/stellar/system-test:` for machines with AMD/Intel-based CPUs - `docker.io/stellar/system-test:-arm64` for machines with ARM CPUs - Set `--TargetNetworkRPCURL` to your RPC HTTP URL @@ -582,7 +582,7 @@ Make sure you configure the system test correctly: ## Monitor the RPC Instance -If you run Soroban RPC with the `--admin-endpoint` configured and [expose the port](https://docs.docker.com/engine/reference/commandline/run/#publish), you'll have access to the [Prometheus](https://prometheus.io/) metrics via the `/metrics` endpoint. For example, if the admin endpoint is `0.0.0.0:8001` and you're running the Soroban RPC Docker image: +If you run Stellar RPC with the `--admin-endpoint` configured and [expose the port](https://docs.docker.com/engine/reference/commandline/run/#publish), you'll have access to the [Prometheus](https://prometheus.io/) metrics via the `/metrics` endpoint. For example, if the admin endpoint is `0.0.0.0:8001` and you're running the Stellar RPC Docker image: ```bash curl localhost:8001/metrics @@ -590,14 +590,14 @@ curl localhost:8001/metrics You will see many of the default Go and Process metrics (prefixed by `go_` and `process_` respectively) such as memory usage, CPU usage, number of threads, etc. -We also expose metrics related to Soroban RPC (prefixed by `soroban_rpc`). There are many, but some notable ones are: +We also expose metrics related to Stellar RPC (prefixed by `soroban_rpc`). There are many, but some notable ones are: - `soroban_rpc_transactions_count` - count of transactions ingested with a sliding window of 10m - `soroban_rpc_events_count` - count of events ingested with a sliding window of 10m - `soroban_rpc_ingest_local_latest_ledger` - latest ledger ingested - `soroban_rpc_db_round_trip_time_seconds` - time required to run `SELECT 1` query in the DATABASE -Soroban RPC also provides logging to console for: +Stellar RPC also provides logging to console for: - Startup activity - Ingesting, applying, and closing ledgers diff --git a/docs/data/rpc/api-reference/json-rpc.mdx b/docs/data/rpc/api-reference/json-rpc.mdx index ba32429ae..7c0b4d245 100644 --- a/docs/data/rpc/api-reference/json-rpc.mdx +++ b/docs/data/rpc/api-reference/json-rpc.mdx @@ -3,11 +3,11 @@ sidebar_position: 40 title: JSON-RPC --- -Soroban-RPC will accept HTTP POST requests using the [JSON-RPC 2.0] specification. Errors are returned via the [jsonrpc error object] wherever possible (and makes sense). +Stellar-RPC will accept HTTP POST requests using the [JSON-RPC 2.0] specification. Errors are returned via the [jsonrpc error object] wherever possible (and makes sense). -For production and other publicly-accessible instances, the JSON-RPC endpoint should be served over SSL on port 443, where possible, for security and ease of use. Though, soroban-rpc does not terminate ssl by itself, so will need a load-balancer or other service to terminate SSL for it. +For production and other publicly-accessible instances, the JSON-RPC endpoint should be served over SSL on port 443, where possible, for security and ease of use. Though, stellar-rpc does not terminate ssl by itself, so will need a load-balancer or other service to terminate SSL for it. -To interact with soroban-rpc from inside a JavaScript application, use the [JavaScript SDK] package, which gives a convenient interface for the RPC methods inside of its `SorobanRpc` module. +To interact with stellar-rpc from inside a JavaScript application, use the [JavaScript SDK] package, which gives a convenient interface for the RPC methods inside of its `SorobanRpc` module. When XDR is passed as a parameter or returned, it is always a string encoded using standard base64. @@ -19,7 +19,7 @@ Please note that parameter structure must contain named parameters as a by-name ## Open-RPC Specification -Soroban-RPC provides an [OpenRPC] specification document that can be used to mock, build, and/or validate both server and client software implementations. This document is used to generate all of our [methods] documentation pages. You can view the full [specification document here]. Additionally, you can experiment with this specificaiton document in the [OpenRPC Playground]. +Stellar-RPC provides an [OpenRPC] specification document that can be used to mock, build, and/or validate both server and client software implementations. This document is used to generate all of our [methods] documentation pages. You can view the full [specification document here]. Additionally, you can experiment with this specificaiton document in the [OpenRPC Playground]. [JSON-RPC 2.0]: https://www.jsonrpc.org/specification [jsonrpc error object]: https://www.jsonrpc.org/specification#error_object diff --git a/docs/data/rpc/api-reference/methods/getLedgerEntries.mdx b/docs/data/rpc/api-reference/methods/getLedgerEntries.mdx index a7eb8206c..8962b905e 100644 --- a/docs/data/rpc/api-reference/methods/getLedgerEntries.mdx +++ b/docs/data/rpc/api-reference/methods/getLedgerEntries.mdx @@ -304,7 +304,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/data/rpc/api-reference/pagination.mdx b/docs/data/rpc/api-reference/pagination.mdx index a5b4780d8..406336a2f 100644 --- a/docs/data/rpc/api-reference/pagination.mdx +++ b/docs/data/rpc/api-reference/pagination.mdx @@ -3,12 +3,12 @@ sidebar_position: 50 title: Pagination --- -Pagination in soroban-rpc is similar to pagination in Horizon. +Pagination in stellar-rpc is similar to pagination in Horizon. For methods which support it, the pagination arguments are passed as a final object argument with two values: -- `cursor`: string - (optional) A string ID that points to a specific location in a collection of responses and is pulled from the paging*token value of a record. When a cursor is provided Soroban-RPC will \_not* include the element whose id matches the cursor in the response. Only elements which appear _after_ the cursor are included. -- `limit`: number - (optional) The maximum number of records returned. The limit for [getEvents](./methods/getEvents.mdx) can range from 1 to 10000 - an upper limit that is hardcoded in Soroban-RPC for performance reasons. If this argument isn't designated, it defaults to 100. +- `cursor`: string - (optional) A string ID that points to a specific location in a collection of responses and is pulled from the paging*token value of a record. When a cursor is provided Stellar-RPC will \_not* include the element whose id matches the cursor in the response. Only elements which appear _after_ the cursor are included. +- `limit`: number - (optional) The maximum number of records returned. The limit for [getEvents](./methods/getEvents.mdx) can range from 1 to 10000 - an upper limit that is hardcoded in Stellar-RPC for performance reasons. If this argument isn't designated, it defaults to 100. For example, calling a method with pagination parameter set: diff --git a/docs/data/rpc/rpc-providers.mdx b/docs/data/rpc/rpc-providers.mdx index b8968377e..94c202bbe 100644 --- a/docs/data/rpc/rpc-providers.mdx +++ b/docs/data/rpc/rpc-providers.mdx @@ -5,7 +5,7 @@ title: Ecosystem RPC Providers ## Ecosystem Providers -Multiple infrastructure providers have made Soroban RPC endpoint services available, and offer plans ranging from free to high throughput endpoints. These providers can be used for development, testing, and production. +Multiple infrastructure providers have made Stellar RPC endpoint services available, and offer plans ranging from free to high throughput endpoints. These providers can be used for development, testing, and production. These providers allow access to the Testnet network and Mainnet network. @@ -33,7 +33,7 @@ These providers allow access to the Testnet network and Mainnet network. ## SDF Provided RPC (Futurenet and Testnet only) {#sdf-provided-rpc} -SDF has made available Soroban RPC with access to the Futurenet and Testnet networks. These services are free to use, and are suitable for development and testing. +SDF has made available Stellar RPC with access to the Futurenet and Testnet networks. These services are free to use, and are suitable for development and testing. SDF will not be providing a publicly available RPC endpoint for Mainnet. Developers should select an ecosystem provider that works for their project before migrating to Mainnet. In some cases, projects may choose to [run their own RPC instance](./admin-guide.mdx). diff --git a/docs/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx b/docs/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx index 7ffba4a39..16471ea21 100644 --- a/docs/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx +++ b/docs/learn/encyclopedia/contract-development/contract-interactions/stellar-transaction.mdx @@ -57,7 +57,7 @@ npm install --save @stellar/stellar-sdk "SCQN3XGRO65BHNSWLSHYIR4B65AHLDUQ7YLHGIWQ4677AZFRS77TCZRB", ); - // Configure the SDK to use the `soroban-rpc` instance of your choosing. + // Configure the SDK to use the `stellar-rpc` instance of your choosing. const server = new SorobanRpc.Server( "https://soroban-testnet.stellar.org:443", ); @@ -101,7 +101,7 @@ npm install --save @stellar/stellar-sdk .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 { @@ -168,7 +168,7 @@ from stellar_sdk.soroban_rpc import GetTransactionStatus, SendTransactionStatus # GCWY3M4VRW4NXJRI7IVAU3CC7XOPN6PRBG6I5M7TAOQNKZXLT3KAH362 source_keypair = Keypair.from_secret('SCQN3XGRO65BHNSWLSHYIR4B65AHLDUQ7YLHGIWQ4677AZFRS77TCZRB') -# 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('https://soroban-testnet.stellar.org') # Here we will use a deployed instance of the `increment` example contract. @@ -215,7 +215,7 @@ prepared_transaction.sign(source_keypair) # Let's see the base64-encoded XDR of the transaction we just built. print(f"Signed prepared transaction XDR: {prepared_transaction.to_xdr()}") -# 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. send_response = soroban_server.send_transaction(prepared_transaction) @@ -285,7 +285,7 @@ public class SorobanExample { KeyPair sourceKeypair = KeyPair.fromSecretSeed("SCQN3XGRO65BHNSWLSHYIR4B65AHLDUQ7YLHGIWQ4677AZFRS77TCZRB"); - // 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. @@ -333,7 +333,7 @@ public class SorobanExample { // 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/learn/encyclopedia/contract-development/transaction-lifecycle.mdx b/docs/learn/encyclopedia/contract-development/transaction-lifecycle.mdx index dc2708d93..0b29f20f6 100644 --- a/docs/learn/encyclopedia/contract-development/transaction-lifecycle.mdx +++ b/docs/learn/encyclopedia/contract-development/transaction-lifecycle.mdx @@ -12,4 +12,4 @@ We're getting a lot of questions that relate to the transaction lifecycle and do The regular Stellar resources are confusing because: 1. they don't have any information on preflight and -2. soroban-rpc's tx submission is async +2. stellar-rpc's tx submission is async diff --git a/docs/learn/encyclopedia/storage/state-archival.mdx b/docs/learn/encyclopedia/storage/state-archival.mdx index 5eefb20c2..db558a929 100644 --- a/docs/learn/encyclopedia/storage/state-archival.mdx +++ b/docs/learn/encyclopedia/storage/state-archival.mdx @@ -176,13 +176,13 @@ The restored entry will have its live until ledger extended to the [minimum] the ## Examples -We've done our best to build tooling around state archival in both the Soroban RPC server as well as the JavaScript SDK to make it easier to deal with, and this set of examples demonstrates how to leverage it. +We've done our best to build tooling around state archival in both the Stellar RPC server as well as the JavaScript SDK to make it easier to deal with, and this set of examples demonstrates how to leverage it. ### Overview Both restoring and extending the TTL of ledger entries follows a three-step process regardless of their nature (contract data, instances, etc.): -1. **Identify the ledger entries**. This usually means acquiring them from a Soroban RPC server as part of your initial transaction simulation (see the [transaction simulation docs](../contract-development/contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](../../../data/rpc/api-reference/methods/simulateTransaction.mdx) RPC method). +1. **Identify the ledger entries**. This usually means acquiring them from a Stellar RPC server as part of your initial transaction simulation (see the [transaction simulation docs](../contract-development/contract-interactions/transaction-simulation.mdx) and the [`simulateTransaction`](../../../data/rpc/api-reference/methods/simulateTransaction.mdx) RPC method). 2. **Prepare your operation**. This means describing the ledger entries within the corresponding operation (i.e. `ExtendFootprintTTLOp` or `RestoreFootprintOp`) and its ledger footprint (the `SorobanTransactionData` field), then simulating it to fill out fee and resource usage information (when restoring, you usually have simulation results already). diff --git a/docs/learn/fundamentals/networks.mdx b/docs/learn/fundamentals/networks.mdx index 6593e67be..08006a16e 100644 --- a/docs/learn/fundamentals/networks.mdx +++ b/docs/learn/fundamentals/networks.mdx @@ -40,7 +40,7 @@ If you are creating multiple accounts, you can fund your first account with Frie ## Testnet and Futurenet data 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. 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. 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. Futurenet resets are on a less regular cadence than Testnet resets and don't have a set schedule. @@ -76,7 +76,7 @@ A script can automate this entire process by creating an account with Friendbot - Creating test accounts (with funding from Friendbot); - Developing applications and contracts and exploring tutorials on Stellar without the potential to lose any assets; -- Testing existing applications against new releases or release candidates of Stellar Core, Horizon, and the Soroban RPC; +- Testing existing applications against new releases or release candidates of Stellar Core, Horizon, and the Stellar RPC; - Performing data analysis on a smaller, non-trivial data set compared to the Mainnet. ### Testnet and Futurenet are bad for diff --git a/docs/learn/fundamentals/stellar-stack.mdx b/docs/learn/fundamentals/stellar-stack.mdx index 6cd52a4aa..f530a7431 100644 --- a/docs/learn/fundamentals/stellar-stack.mdx +++ b/docs/learn/fundamentals/stellar-stack.mdx @@ -31,7 +31,7 @@ Learn all there is to know about using Horizon in the Horizon [documentation](.. ## RPC -Soroban's RPC is a JSON RPC server that provides an interface for users and applications to interact with smart contracts on the Stellar blockchain. When an application would like to interact with smart contracts, it sends a request to the RPC server. The server interprets these requests, translates them into a format understandable by the blockchain nodes, and forwards them. After processing the requests, the blockchain nodes send back the results. The RPC server receives these results and sends them back to the requesting application. +Stellar's RPC is a JSON RPC server that provides an interface for users and applications to interact with smart contracts on the Stellar blockchain. When an application would like to interact with smart contracts, it sends a request to the RPC server. The server interprets these requests, translates them into a format understandable by the blockchain nodes, and forwards them. After processing the requests, the blockchain nodes send back the results. The RPC server receives these results and sends them back to the requesting application. SDF has RPC endpoints available for Futurenet and Testnet. These services are free to use, and are suitable for development and testing. @@ -39,6 +39,6 @@ SDF does not provide a publicly available RPC endpoint for Mainnet. Developers s ## SDKs -SDKs simplify some of the work of accessing Horizon and the Soroban RPC by converting the data into friendlier formats and allowing you to program in the language of your choice. Stellar’s SDKs show you how to request data and create and submit transactions. Soroban's SDKs allow you to write smart contracts in Rust and interact with smart contracts in a myriad of other languages. +SDKs simplify some of the work of accessing Horizon and the Stellar RPC by converting the data into friendlier formats and allowing you to program in the language of your choice. Stellar’s SDKs show you how to request data and create and submit transactions. Soroban's SDKs allow you to write smart contracts in Rust and interact with smart contracts in a myriad of other languages. View Stellar's [SDK library](../../tools/sdks/library.mdx) to access our SDKs and their documentation. diff --git a/docs/learn/interactive/dapps/scaffold-soroban.mdx b/docs/learn/interactive/dapps/scaffold-soroban.mdx index 86fdc8be0..0304ede10 100644 --- a/docs/learn/interactive/dapps/scaffold-soroban.mdx +++ b/docs/learn/interactive/dapps/scaffold-soroban.mdx @@ -73,11 +73,11 @@ Dive in and discover the power of Soroban! With the introduction of these dapps, let's delve deeper into some of their [standout features](https://github.com/stellar/soroban-react-atomic-swap/blob/main/src/helpers/soroban.ts) that showcase the power and innovation behind the dapps: -Functionality behind the dapps is extensive and diverse, leveraging the `@stellar/stellar-sdk` library to integrate with the Soroban RPC and facilitating direct communication with Soroban using a JSON RPC interface on the Stellar network. They are equipped to communicate across different network setups, as they incorporate the `RPC_URLS` and `getServer` functionalities, providing adaptability that is crucial for various development and deployment scenarios. Users can retrieve user-friendly token information without engaging with complex blockchain operations, by utilizing functions like `getTokenSymbol`, `getTokenName`, and `getTokenDecimals`. +Functionality behind the dapps is extensive and diverse, leveraging the `@stellar/stellar-sdk` library to integrate with the Stellar RPC and facilitating direct communication with Soroban using a JSON RPC interface on the Stellar network. They are equipped to communicate across different network setups, as they incorporate the `RPC_URLS` and `getServer` functionalities, providing adaptability that is crucial for various development and deployment scenarios. Users can retrieve user-friendly token information without engaging with complex blockchain operations, by utilizing functions like `getTokenSymbol`, `getTokenName`, and `getTokenDecimals`. A significant feature is the `simulateTx` function, which allows users to preview the outcome of a transaction before actually executing it. `simulateTx` allows users to submit a trial contract invocation by first running a simulation of the contract invocation as defined on the incoming transaction. The results are then applied to a new copy of the transaction, which is returned with the ledger footprint and authorization set, making it ready for signing and sending. The returned transaction will also have an updated fee, the sum of the fee set on the incoming transaction with the contract resource fees estimated from the simulation. It is advisable to check the fee on the returned transaction and validate or take appropriate measures for interaction with the user to confirm it is acceptable. -Other utilities such as `accountToScVal` and `numberToI128` are also provided to simplify transaction creation by converting user-friendly inputs into the formats expected by the Soroban RPC on the Stellar network. Furthermore, the dapps are built with premade helper functions such as the `makePayment` function which facilitates streamlined "transfer" operations and also includes memos for supplementary transaction-related information. +Other utilities such as `accountToScVal` and `numberToI128` are also provided to simplify transaction creation by converting user-friendly inputs into the formats expected by the Stellar RPC on the Stellar network. Furthermore, the dapps are built with premade helper functions such as the `makePayment` function which facilitates streamlined "transfer" operations and also includes memos for supplementary transaction-related information. The code referenced showcases various functionalities including sending transactions, retrieving token information, simulating transactions, building swaps, and authorizing contract calls, all of which are ready to be cloned, customized, and expanded upon to suit your unique needs and ideas. diff --git a/docs/learn/migrate/evm/smart-contract-deployment.mdx b/docs/learn/migrate/evm/smart-contract-deployment.mdx index d5a111d98..6d6fcee13 100644 --- a/docs/learn/migrate/evm/smart-contract-deployment.mdx +++ b/docs/learn/migrate/evm/smart-contract-deployment.mdx @@ -62,7 +62,7 @@ async function main() { ### Soroban Client -Soroban offers a comparable library, [`stellar-sdk`](../../../tools/sdks/library.mdx#javascript-sdk), that enables seamless interaction smart contracts deployed on the Stellar Network. This library supplies a comprehensive networking layer API for Soroban RPC methods as well as the traditional Horizon API, simplifying the process of building and signing transactions. Additionally, `stellar-sdk` streamlines communication with RPC instances and supports submitting transactions or querying network state with ease. +Soroban offers a comparable library, [`stellar-sdk`](../../../tools/sdks/library.mdx#javascript-sdk), that enables seamless interaction smart contracts deployed on the Stellar Network. This library supplies a comprehensive networking layer API for Stellar RPC methods as well as the traditional Horizon API, simplifying the process of building and signing transactions. Additionally, `stellar-sdk` streamlines communication with RPC instances and supports submitting transactions or querying network state with ease. ### Scripts diff --git a/docs/networks/README.mdx b/docs/networks/README.mdx index f1b04fc3f..be9fbbb22 100644 --- a/docs/networks/README.mdx +++ b/docs/networks/README.mdx @@ -16,7 +16,7 @@ Read more about the different networks in the [Networks section](../learn/fundam | :-- | --- | --- | --- | | Network Passphrase | `Public Global Stellar Network ; September 2015` | `Test SDF Network ; September 2015` | `Test SDF Future Network ; October 2022` | | Horizon API | See available [Horizon ecosystem providers] | https://horizon-testnet.stellar.org | https://horizon-futurenet.stellar.org | -| Soroban RPC | See available [RPC ecosystem providers] | `https://soroban-testnet.stellar.org` | `https://rpc-futurenet.stellar.org` | +| Stellar RPC | See available [RPC ecosystem providers] | `https://soroban-testnet.stellar.org` | `https://rpc-futurenet.stellar.org` | | Friendbot API | N/A | `https://friendbot.stellar.org` | `https://friendbot-futurenet.stellar.org` | | Validator | `core-live-a.stellar.org` `core-live-b.stellar.org` `core-live-c.stellar.org` | `core-live-testnet.stellar.org` | `core-live-futurenet.stellar.org` | | History Archive | `http://history.stellar.org/prd/core-live/core_live_001/`, `http://history.stellar.org/prd/core-live/core_live_002/`, `http://history.stellar.org/prd/core-live/core_live_003/` | https://history-testnet.stellar.org | https://history-futurenet.stellar.org | diff --git a/docs/tools/developer-tools/data-indexers.mdx b/docs/tools/developer-tools/data-indexers.mdx index 79c62fdbd..40e7a7ee7 100644 --- a/docs/tools/developer-tools/data-indexers.mdx +++ b/docs/tools/developer-tools/data-indexers.mdx @@ -15,7 +15,7 @@ Also offers RPC and Horizon instances. ### [BlockEden](https://blockeden.xyz/stellar-soroban/) -An all-in-one Soroban RPC, indexer GraphQL API, and data analytics web portal. +An all-in-one Stellar RPC, indexer GraphQL API, and data analytics web portal. ### [Goldsky](https://goldsky.com/) diff --git a/docs/tools/developer-tools/lab/README.mdx b/docs/tools/developer-tools/lab/README.mdx index c2decfad8..464b1f58c 100644 --- a/docs/tools/developer-tools/lab/README.mdx +++ b/docs/tools/developer-tools/lab/README.mdx @@ -16,7 +16,7 @@ Stellar Lab is our new go-to tool for development, experimenting, and testing, a ### Features of Stellar Lab - Easily Create Accounts: Create Accounts on Mainnet, Testnet, and Futurenet using a web UI. You can use Friendbot to fund those accounts directly on Lab for Testnet and Futurenet. -- Access RPC Methods and Horizon Endpoints: Leverage powerful Soroban RPC methods and Stellar Horizon endpoints in a web UI to interact with the Stellar network and obtain crucial data. Try RPC methods to get states from the ledger like accounts, trustlines, contract wasm, and more. +- Access RPC Methods and Horizon Endpoints: Leverage powerful Stellar RPC methods and Stellar Horizon endpoints in a web UI to interact with the Stellar network and obtain crucial data. Try RPC methods to get states from the ledger like accounts, trustlines, contract wasm, and more. - Simulate and Submit: Lab supports the ability to use custom RPC providers so that you could simulate transactions, save transactions, and submit transactions directly using Lab. You can also submit transactions using Horizon. - Save and Share API Requests: Easily save your requests and transactions for the future or share them with teammates to build faster together. - XDR ⇔ JSON Support: We have introduced a canonical [XDR to JSON mapping](https://www.npmjs.com/package/@stellar/stellar-xdr-json-web) which is used on Stellar Lab (also used in the [Stellar CLI](https://github.com/stellar/stellar-cli)). You can see this at work in the Lab where [XDR can be converted to JSON](https://lab.stellar.org/xdr/view). diff --git a/docs/tools/sdks/library.mdx b/docs/tools/sdks/library.mdx index c06aa07d1..f7684fa02 100644 --- a/docs/tools/sdks/library.mdx +++ b/docs/tools/sdks/library.mdx @@ -39,11 +39,11 @@ The AssemblyScript Soroban SDK is maintained by dedicated community developer, S [JavaScript SDK](https://github.com/stellar/js-stellar-sdk) | [Docs](https://stellar.github.io/js-stellar-sdk/) | [NPM](https://www.npmjs.com/package/@stellar/stellar-sdk) -`stellar-sdk` is the JavaScript library for communicating with a Soroban RPC server, communicating with the Horizon API, and building transactions on the Stellar network. It is used for building Stellar apps either on Node.js or in the browser. +`stellar-sdk` is the JavaScript library for communicating with a Stellar RPC server, communicating with the Horizon API, and building transactions on the Stellar network. It is used for building Stellar apps either on Node.js or in the browser. It provides: -- A networking layer API for Soroban RPC methods and the Horizon API. +- A networking layer API for Stellar RPC methods and the Horizon API. - Facilities for building and signing transactions, for communicating with an RPC instance, for communicating with a Horizon instance, and for submitting transactions or querying network state. ### Python SDK @@ -63,7 +63,7 @@ It provides: [iOS SDK](https://github.com/Soneso/stellar-ios-mac-sdk) | [Docs](https://github.com/Soneso/stellar-ios-mac-sdk/tree/master/docs) | [Smart Contract Docs](https://github.com/Soneso/stellar-ios-mac-sdk/blob/master/soroban.md) -The `stellar-ios-mac-sdk` is an open source Stellar SDK for iOS & Mac. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server. +The `stellar-ios-mac-sdk` is an open source Stellar SDK for iOS & Mac. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Stellar RPC Server. The iOS SDK is maintained by dedicated community developer, Soneso. @@ -71,7 +71,7 @@ The iOS SDK is maintained by dedicated community developer, Soneso. [Flutter SDK](https://github.com/Soneso/stellar_flutter_sdk) | [Docs](https://github.com/Soneso/stellar_flutter_sdk/blob/master/soroban.md) -The `stellar-flutter-sdk` is an open source Stellar SDK for Flutter developers. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server. +The `stellar-flutter-sdk` is an open source Stellar SDK for Flutter developers. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Stellar RPC Server. The Flutter Stellar SDK is maintained by dedicated community developer, Soneso. @@ -79,7 +79,7 @@ The Flutter Stellar SDK is maintained by dedicated community developer, Soneso. [PHP SDK](https://github.com/Soneso/stellar-php-sdk) | [Docs](https://github.com/Soneso/stellar-php-sdk/blob/main/soroban.md) -The `stellar-php-sdk` is an open source Stellar SDK for PHP developers. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server. +The `stellar-php-sdk` is an open source Stellar SDK for PHP developers. It provides APIs to build transactions and connect to Horizon. It also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Stellar RPC Server. The PHP Stellar SDK is maintained by dedicated community developer, Soneso. @@ -93,7 +93,7 @@ This SDK is maintained by dedicated community developers, kommitters Open Source [Java SDK](https://github.com/lightsail-network/java-stellar-sdk) | [Docs](https://lightsail-network.github.io/java-stellar-sdk/) -`java-stellar-sdk` provides APIs to build transactions and connect to Horizon and also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server. +`java-stellar-sdk` provides APIs to build transactions and connect to Horizon and also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Stellar RPC Server. ### Go diff --git a/docs/validators/README.mdx b/docs/validators/README.mdx index d3bec8db7..848b0f179 100644 --- a/docs/validators/README.mdx +++ b/docs/validators/README.mdx @@ -10,7 +10,7 @@ Stellar is a peer-to-peer network made up of nodes, which are computers that kee This section of the docs explains how to run a validator node, which participates in consensus to validate transactions and determine network settings. A validator node _should not_ be used for network data access and transaction submission. There are two varieties of _non-validating_ nodes that can be used for those purposes, each of which has its own process for set up, interaction, maintenance, and monitoring. They are: 1. [**Horizon Nodes**](../data/horizon/README.mdx) can be used for submitting transactions, as well as exposing a REST API service to query and retrieve network state. -2. [**Soroban RPC Nodes**](../data/rpc/README.mdx) can be used for simulating and/or submitting transactions, as well as exposing an RPC service to query and retrieve current network state. +2. [**Stellar RPC Nodes**](../data/rpc/README.mdx) can be used for simulating and/or submitting transactions, as well as exposing an RPC service to query and retrieve current network state. If you are interested in Horizon or RPC nodes, please explore those docs. diff --git a/meeting-notes/2024-02-22.mdx b/meeting-notes/2024-02-22.mdx index e12a1363c..3ab6227db 100644 --- a/meeting-notes/2024-02-22.mdx +++ b/meeting-notes/2024-02-22.mdx @@ -15,5 +15,5 @@ tags: [developer] 1. Latest and greatest on the TypeScript bindings with [@chadoh](https://github.com/chadoh) 2. [Available RPC providers](/docs/data/rpc/rpc-providers) -3. Standing up a [`soroban-rpc` docker container](/docs/data/rpc/admin-guide#docker-image) +3. Standing up a [`stellar-rpc` docker container](/docs/data/rpc/admin-guide#docker-image) 4. Installing and invoking a Stellar Asset Contract on mainnet in Phase 0 diff --git a/openrpc/README.md b/openrpc/README.md index 9e7a0e360..0c51bcbde 100644 --- a/openrpc/README.md +++ b/openrpc/README.md @@ -1,4 +1,4 @@ -# Soroban RPC API Specification +# Stellar RPC API Specification ## Table of Contents @@ -157,7 +157,7 @@ object allows us to embed a literal example of what the schema can look like. This collection of JSON files define the [example pairing objects] that will go into the generated specification file. The example pairing objects make up a -complete example request to the Soroban RPC service. This is where you can +complete example request to the Stellar RPC service. This is where you can specify a set of `params` that were supplied in the request, as well as the value(s) returned in the `result` from the node. The following properties are required in the example pairing objects: @@ -168,7 +168,7 @@ required in the example pairing objects: > _Note:_ The `result` property is not technically _required_ by the open-rpc > specification if the method is to be represented as a notification. However, -> Soroban RPC doesn't make use of any methods as notifications, so we've listed +> Stellar RPC doesn't make use of any methods as notifications, so we've listed > it as required here. [method objects]: https://spec.open-rpc.org/#method-object diff --git a/openrpc/scripts/build.mjs b/openrpc/scripts/build.mjs index b17e42567..d26f13052 100644 --- a/openrpc/scripts/build.mjs +++ b/openrpc/scripts/build.mjs @@ -122,8 +122,8 @@ const services = { starterFile: { openrpc: "1.2.6", info: { - title: "Soroban RPC", - description: "Soroban-RPC allows you to communicate directly with Soroban via a JSON RPC interface.", + title: "Stellar RPC", + description: "Stellar-RPC allows you to communicate directly with Soroban via a JSON RPC interface.", termsOfService: "https://stellar.org/terms-of-service", contact: { name: "Stellar Development Foundation", diff --git a/openrpc/src/stellar-rpc/contentDescriptors/Pagination.json b/openrpc/src/stellar-rpc/contentDescriptors/Pagination.json index c8162cc9f..9a5234159 100644 --- a/openrpc/src/stellar-rpc/contentDescriptors/Pagination.json +++ b/openrpc/src/stellar-rpc/contentDescriptors/Pagination.json @@ -2,7 +2,7 @@ "EventsPagination": { "name": "pagination", "summary": "pagination options", - "description": "Pagination in soroban-rpc is similar to pagination in Horizon. See [Pagination](https://developers.stellar.org/docs/data/rpc/api-reference/pagination).", + "description": "Pagination in stellar-rpc is similar to pagination in Horizon. See [Pagination](https://developers.stellar.org/docs/data/rpc/api-reference/pagination).", "required": false, "schema": { "$ref": "#/components/schemas/EventsPagination" diff --git a/openrpc/src/stellar-rpc/methods/getEvents.json b/openrpc/src/stellar-rpc/methods/getEvents.json index da2f3da17..1d6512e7a 100644 --- a/openrpc/src/stellar-rpc/methods/getEvents.json +++ b/openrpc/src/stellar-rpc/methods/getEvents.json @@ -1,7 +1,7 @@ { "name": "getEvents", "summary": "returns contract events", - "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nSoroban-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default soroban-rpc retains the most recent 24 hours of events.", + "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default stellar-rpc retains the most recent 24 hours of events.", "externalDocs": { "url": "https://developers.stellar.org/docs/data/rpc/api-reference/methods/getEvents" }, diff --git a/openrpc/src/stellar-rpc/methods/getTransaction.json b/openrpc/src/stellar-rpc/methods/getTransaction.json index 32c475ee0..bb4176e3d 100644 --- a/openrpc/src/stellar-rpc/methods/getTransaction.json +++ b/openrpc/src/stellar-rpc/methods/getTransaction.json @@ -1,7 +1,7 @@ { "name": "getTransaction", "summary": "returns transaction details", - "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The soroban-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 24 hours. For private soroban-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting, but we do not recommend values longer than 7 days. For debugging needs that extend beyond this timeframe, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).", + "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 24 hours. For private soroban-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting, but we do not recommend values longer than 7 days. For debugging needs that extend beyond this timeframe, it is advisable to index this data yourself, employ a third-party [indexer](https://developers.stellar.org/docs/tools/developer-tools/data-indexers), or query [Hubble](https://developers.stellar.org/docs/data/hubble) (our public BigQuery data set).", "externalDocs": { "url": "https://developers.stellar.org/docs/data/rpc/api-reference/methods/getTransaction" }, diff --git a/openrpc/src/stellar-rpc/schemas/Hash.json b/openrpc/src/stellar-rpc/schemas/Hash.json index f12fe2cfc..dd20709d6 100644 --- a/openrpc/src/stellar-rpc/schemas/Hash.json +++ b/openrpc/src/stellar-rpc/schemas/Hash.json @@ -13,7 +13,7 @@ }, "LedgerHash": { "title": "id", - "description": "Hash identifier of the latest ledger (as a hex-encoded string) known to Soroban RPC at the time it handled the request.", + "description": "Hash identifier of the latest ledger (as a hex-encoded string) known to Stellar RPC at the time it handled the request.", "$ref": "#/components/schemas/Hash" } } diff --git a/openrpc/src/stellar-rpc/schemas/LedgerCloseTime.json b/openrpc/src/stellar-rpc/schemas/LedgerCloseTime.json index ba6df7fea..81c16b8e6 100644 --- a/openrpc/src/stellar-rpc/schemas/LedgerCloseTime.json +++ b/openrpc/src/stellar-rpc/schemas/LedgerCloseTime.json @@ -6,12 +6,12 @@ }, "LatestLedgerCloseTime": { "title": "latestLedgerCloseTime", - "description": "The unix timestamp of the close time of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the latest ledger known to Stellar RPC at the time it handled the request.", "$ref": "#/components/schemas/LedgerCloseTime" }, "OldestLedgerCloseTime": { "title": "oldestLedgerCloseTime", - "description": "The unix timestamp of the close time of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "$ref": "#/components/schemas/LedgerCloseTime" } } diff --git a/openrpc/src/stellar-rpc/schemas/LedgerSequence.json b/openrpc/src/stellar-rpc/schemas/LedgerSequence.json index bd097ba91..ebfe2b6fd 100644 --- a/openrpc/src/stellar-rpc/schemas/LedgerSequence.json +++ b/openrpc/src/stellar-rpc/schemas/LedgerSequence.json @@ -6,12 +6,12 @@ }, "LatestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "$ref": "#/components/schemas/LedgerSequence" }, "OldestLedger": { "title": "oldestLedger", - "description": "The sequence number of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The sequence number of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "$ref": "#/components/schemas/LedgerSequence" } } diff --git a/openrpc/src/stellar-rpc/schemas/NetworkConfig.json b/openrpc/src/stellar-rpc/schemas/NetworkConfig.json index fdcf3a990..88bc9cd69 100644 --- a/openrpc/src/stellar-rpc/schemas/NetworkConfig.json +++ b/openrpc/src/stellar-rpc/schemas/NetworkConfig.json @@ -6,7 +6,7 @@ }, "NetworkPassphrase": { "title": "networkPassphrase", - "description": "Network passphrase configured for this Soroban RPC node.", + "description": "Network passphrase configured for this Stellar RPC node.", "type": "string" } } diff --git a/openrpc/src/stellar-rpc/schemas/Pagination.json b/openrpc/src/stellar-rpc/schemas/Pagination.json index a74f6ebdc..d1f5e2723 100644 --- a/openrpc/src/stellar-rpc/schemas/Pagination.json +++ b/openrpc/src/stellar-rpc/schemas/Pagination.json @@ -7,7 +7,7 @@ }, "limit": { "type": "number", - "description": "The maximum number of records returned. The limit for getEvents can range from 1 to 10000 - an upper limit that is hardcoded in Soroban-RPC for performance reasons. If this argument isn't designated, it defaults to 100." + "description": "The maximum number of records returned. The limit for getEvents can range from 1 to 10000 - an upper limit that is hardcoded in Stellar-RPC for performance reasons. If this argument isn't designated, it defaults to 100." } }, "required": [] diff --git a/static/stellar-rpc.openrpc.json b/static/stellar-rpc.openrpc.json index 39df57687..67016b77a 100644 --- a/static/stellar-rpc.openrpc.json +++ b/static/stellar-rpc.openrpc.json @@ -1,8 +1,8 @@ { "openrpc": "1.2.6", "info": { - "title": "Soroban RPC", - "description": "Soroban-RPC allows you to communicate directly with Soroban via a JSON RPC interface.", + "title": "Stellar RPC", + "description": "Stellar-RPC allows you to communicate directly with Soroban via a JSON RPC interface.", "termsOfService": "https://stellar.org/terms-of-service", "contact": { "name": "Stellar Development Foundation", @@ -33,7 +33,7 @@ { "name": "getEvents", "summary": "returns contract events", - "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nSoroban-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default soroban-rpc retains the most recent 24 hours of events.", + "description": "Clients can request a filtered list of events emitted by a given ledger range.\n\nStellar-RPC will support querying within a maximum 7 days of recent ledgers.\n\nNote, this could be used by the client to only prompt a refresh when there is a new ledger with relevant events. It should also be used by backend Dapp components to \"ingest\" events into their own database for querying and serving.\n\nIf making multiple requests, clients should deduplicate any events received, based on the event's unique id field. This prevents double-processing in the case of duplicate events being received.\n\nBy default soroban-rpc retains the most recent 24 hours of events.", "externalDocs": { "url": "https://developers.stellar.org/docs/data/rpc/api-reference/methods/getEvents" }, @@ -101,7 +101,7 @@ { "name": "pagination", "summary": "pagination options", - "description": "Pagination in soroban-rpc is similar to pagination in Horizon. See [Pagination](https://developers.stellar.org/docs/data/rpc/api-reference/pagination).", + "description": "Pagination in stellar-rpc is similar to pagination in Horizon. See [Pagination](https://developers.stellar.org/docs/data/rpc/api-reference/pagination).", "required": false, "schema": { "type": "object", @@ -114,7 +114,7 @@ }, "limit": { "type": "number", - "description": "The maximum number of records returned. The limit for getEvents can range from 1 to 10000 - an upper limit that is hardcoded in Soroban-RPC for performance reasons. If this argument isn't designated, it defaults to 100." + "description": "The maximum number of records returned. The limit for getEvents can range from 1 to 10000 - an upper limit that is hardcoded in Stellar-RPC for performance reasons. If this argument isn't designated, it defaults to 100." } } } @@ -127,7 +127,7 @@ "properties": { "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "events": { @@ -491,7 +491,7 @@ }, "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" } } @@ -617,7 +617,7 @@ "minLength": 64, "maxLength": 64, "pattern": "^[a-f\\d]{64}$", - "description": "Hash identifier of the latest ledger (as a hex-encoded string) known to Soroban RPC at the time it handled the request." + "description": "Hash identifier of the latest ledger (as a hex-encoded string) known to Stellar RPC at the time it handled the request." }, "protocolVersion": { "title": "protocolVersion", @@ -626,7 +626,7 @@ }, "sequence": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" } } @@ -682,7 +682,7 @@ "properties": { "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "entries": { @@ -826,7 +826,7 @@ "properties": { "passphrase": { "title": "networkPassphrase", - "description": "Network passphrase configured for this Soroban RPC node.", + "description": "Network passphrase configured for this Stellar RPC node.", "type": "string" }, "protocolVersion": { @@ -873,7 +873,7 @@ { "name": "getTransaction", "summary": "returns transaction details", - "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The soroban-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 1440 ledgers, approximately equivalent to a 2-hour timeframe. For private soroban-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting. For comprehensive debugging needs that extend beyond the 2-hour timeframe, it is advisable to retrieve transaction information from Horizon, as it provides a lasting and persistent record.", + "description": "The getTransaction method provides details about the specified transaction. Clients are expected to periodically query this method to ascertain when a transaction has been successfully recorded on the blockchain. The stellar-rpc system maintains a restricted history of recently processed transactions, with the default retention window set at 1440 ledgers, approximately equivalent to a 2-hour timeframe. For private stellar-rpc instances, it is possible to modify the retention window value by adjusting the transaction-retention-window configuration setting. For comprehensive debugging needs that extend beyond the 2-hour timeframe, it is advisable to retrieve transaction information from Horizon, as it provides a lasting and persistent record.", "externalDocs": { "url": "https://developers.stellar.org/docs/data/rpc/api-reference/methods/getTransaction" }, @@ -917,22 +917,22 @@ }, "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "latestLedgerCloseTime": { "title": "latestLedgerCloseTime", - "description": "The unix timestamp of the close time of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "string" }, "oldestLedger": { "title": "oldestLedger", - "description": "The sequence number of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The sequence number of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "type": "number" }, "oldestLedgerCloseTime": { "title": "oldestLedgerCloseTime", - "description": "The unix timestamp of the close time of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "type": "string" }, "ledger": { @@ -1147,22 +1147,22 @@ }, "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "latestLedgerCloseTimestamp": { "title": "latestLedgerCloseTime", - "description": "The unix timestamp of the close time of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "string" }, "oldestLedger": { "title": "oldestLedger", - "description": "The sequence number of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The sequence number of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "type": "number" }, "oldestLedgerCloseTimestamp": { "title": "oldestLedgerCloseTime", - "description": "The unix timestamp of the close time of the oldest ledger ingested by Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the oldest ledger ingested by Stellar RPC at the time it handled the request.", "type": "string" } } @@ -1466,12 +1466,12 @@ }, "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "latestLedgerCloseTime": { "title": "latestLedgerCloseTime", - "description": "The unix timestamp of the close time of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The unix timestamp of the close time of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "string" }, "errorResultXdr": { @@ -1629,7 +1629,7 @@ "properties": { "latestLedger": { "title": "latestLedger", - "description": "The sequence number of the latest ledger known to Soroban RPC at the time it handled the request.", + "description": "The sequence number of the latest ledger known to Stellar RPC at the time it handled the request.", "type": "number" }, "minResourceFee": {