Skip to main content

Introduction

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.

Soroban-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.
  • 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.

  • 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.