Server

Get a new AssetsCallBuilder instance configured with the current Horizon server configuration.

Check if any of the destination accounts requires a memo.

This function implements a memo required check as defined in SEP-29. It will load each account which is the destination and check if it has the data field config.memo_required set to "MQ==".

Each account is checked sequentially instead of loading multiple accounts at the same time from Horizon.

Fetch the fee stats endpoint.

Fetch the base fee. Since this hits the server, if the server call fails, you might get an error. You should be prepared to use a default value if that happens!

Get timebounds for N seconds from now, when you're creating a transaction with TransactionBuilder.

By default, TransactionBuilder uses the current local time, but your machine's local time could be different from Horizon's. This gives you more assurance that your timebounds will reflect what you want.

Note that this will generate your timebounds when you init the transaction, not when you build or submit the transaction! So give yourself enough time to get the transaction built and signed before submitting.

Example:

const transaction = new StellarSdk.TransactionBuilder(accountId, {
 fee: await StellarSdk.Server.fetchBaseFee(),
 timebounds: await StellarSdk.Server.fetchTimebounds(100)
})
 .addOperation(operation)
 // normally we would need to call setTimeout here, but setting timebounds
 // earlier does the trick!
 .build();

Fetch a minimal set of current info about a Stellar account.

Needed to get the current sequence number for the account so you can build a successful transaction with TransactionBuilder.

Reads the current value of contract data ledger entries directly.

Allows you to directly inspect the current state of a contract. This is a backup way to access your contract data which may not be available via events or Server.simulateTransaction.

Fetch all events that match a given set of filters.

The given filters (see Api.EventFilter for detailed fields) are combined only in a logical OR fashion, and all of the fields in each filter are optional.

To page through events, use the pagingToken field on the relevant Api.EventResponse object to set the cursor parameter.

General node health check.

Fetch the latest ledger meta info from network which this Soroban RPC server is connected to.

Reads the current value of arbitrary ledger entries directly.

Allows you to directly inspect the current state of contracts, contract's code, accounts, or any other ledger entries.

To fetch a contract's WASM byte-code, built the appropriate xdr.LedgerKeyContractCode ledger entry key (or see Contract.getFootprint).

Fetch metadata about the network this Soroban RPC server is connected to.

Fetch the details of a submitted transaction.

After submitting a transaction, clients should poll this to tell when the transaction has completed.

Fetches an account's most current state in the ledger, then creates and returns an AccountResponse object.

People on the Stellar network can make offers to buy or sell assets. This endpoint represents all the offers on the DEX.

You can query all offers for account using the function .accountId:

server.offers()
 .forAccount(accountId).call()
 .then(function(offers) {
   console.log(offers);
 });

Submit a trial contract invocation, first run a simulation of the contract invocation as defined on the incoming transaction, and apply the results to a new copy of the transaction which is then returned. Setting the ledger footprint and authorization, so the resulting transaction is ready for signing & sending.

The returned transaction will also have an updated fee that is the sum of fee set on incoming transaction with the contract resource fees estimated from simulation. It is adviseable to check the fee on returned transaction and validate or take appropriate measures for interaction with user to confirm it is acceptable.

You can call the Server.simulateTransaction method directly first if you want to inspect estimated fees for a given transaction in detail first, then re-assemble it manually or via assembleTransaction.

Fund a new account using the network's friendbot faucet, if any.

Submit a real transaction to the Stellar network.

Unlike Horizon, Soroban RPC does not wait for transaction completion. It simply validates the transaction and enqueues it. Clients should call Server.getTransactionStatus to learn about transaction success/failure.

Submit a trial contract invocation to get back return values, expected ledger footprint, expected authorizations, and expected costs.

The Stellar Network allows payments to be made between assets through path payments. A strict receive path payment specifies a series of assets to route a payment through, from source asset (the asset debited from the payer) to destination asset (the asset credited to the payee).

A strict receive path search is specified using:

• The destination address.
• The source address or source assets.
• The asset and amount that the destination account should receive.

As part of the search, horizon will load a list of assets available to the source address and will find any payment paths from those source assets to the desired destination asset. The search's amount parameter will be used to determine if there a given path can satisfy a payment of the desired amount.

If a list of assets is passed as the source, horizon will find any payment paths from those source assets to the desired destination asset.

The Stellar Network allows payments to be made between assets through path payments. A strict send path payment specifies a series of assets to route a payment through, from source asset (the asset debited from the payer) to destination asset (the asset credited to the payee).

A strict send path search is specified using:

The asset and amount that is being sent. The destination account or the destination assets.

Submits a transaction to the network.

By default this function calls Server#checkMemoRequired, you can skip this check by setting the option skipMemoRequiredCheck to true.

If you submit any number of manageOffer operations, this will add an attribute to the response that will help you analyze what happened with your offers.

Ex:

const res = {
  ...response,
  offerResults: [
    {
      // Exact ordered list of offers that executed, with the exception
      // that the last one may not have executed entirely.
      offersClaimed: [
        sellerId: String,
        offerId: String,
        assetSold: {
          type: 'native|credit_alphanum4|credit_alphanum12',

          // these are only present if the asset is not native
          assetCode: String,
          issuer: String,
        },

        // same shape as assetSold
        assetBought: {}
      ],

      // What effect your manageOffer op had
      effect: "manageOfferCreated|manageOfferUpdated|manageOfferDeleted",

      // Whether your offer immediately got matched and filled
      wasImmediatelyFilled: Boolean,

      // Whether your offer immediately got deleted, if for example the order was too small
      wasImmediatelyDeleted: Boolean,

      // Whether the offer was partially, but not completely, filled
      wasPartiallyFilled: Boolean,

      // The full requested amount of the offer is open for matching
      isFullyOpen: Boolean,

      // The total amount of tokens bought / sold during transaction execution
      amountBought: Number,
      amountSold: Number,

      // if the offer was created, updated, or partially filled, this is
      // the outstanding offer
      currentOffer: {
        offerId: String,
        amount: String,
        price: {
          n: String,
          d: String,
        },

        selling: {
          type: 'native|credit_alphanum4|credit_alphanum12',

          // these are only present if the asset is not native
          assetCode: String,
          issuer: String,
        },

        // same as `selling`
        buying: {},
      },

      // the index of this particular operation in the op stack
      operationIndex: Number
    }
  ]
}

For example, you'll want to examine offerResults to add affordances like these to your app:

• If wasImmediatelyFilled is true, then no offer was created. So if you normally watch the Server.offers endpoint for offer updates, you instead need to check Server.trades to find the result of this filled offer.
• If wasImmediatelyDeleted is true, then the offer you submitted was deleted without reaching the orderbook or being matched (possibly because your amounts were rounded down to zero). So treat the just-submitted offer request as if it never happened.
• If wasPartiallyFilled is true, you can tell the user that amountBought or amountSold have already been transferred.

Returns

Get a new AssetsCallBuilder instance configured with the current Horizon server configuration.

Check if any of the destination accounts requires a memo.

This function implements a memo required check as defined in SEP-29. It will load each account which is the destination and check if it has the data field config.memo_required set to "MQ==".

Each account is checked sequentially instead of loading multiple accounts at the same time from Horizon.

Fetch the fee stats endpoint.

Fetch the base fee. Since this hits the server, if the server call fails, you might get an error. You should be prepared to use a default value if that happens!

Get timebounds for N seconds from now, when you're creating a transaction with TransactionBuilder.

By default, TransactionBuilder uses the current local time, but your machine's local time could be different from Horizon's. This gives you more assurance that your timebounds will reflect what you want.

Note that this will generate your timebounds when you init the transaction, not when you build or submit the transaction! So give yourself enough time to get the transaction built and signed before submitting.

Example:

const transaction = new StellarSdk.TransactionBuilder(accountId, {
 fee: await StellarSdk.Server.fetchBaseFee(),
 timebounds: await StellarSdk.Server.fetchTimebounds(100)
})
 .addOperation(operation)
 // normally we would need to call setTimeout here, but setting timebounds
 // earlier does the trick!
 .build();

Fetch a minimal set of current info about a Stellar account.

Needed to get the current sequence number for the account so you can build a successful transaction with TransactionBuilder.

Reads the current value of contract data ledger entries directly.

Allows you to directly inspect the current state of a contract. This is a backup way to access your contract data which may not be available via events or Server.simulateTransaction.

Fetch all events that match a given set of filters.

The given filters (see Api.EventFilter for detailed fields) are combined only in a logical OR fashion, and all of the fields in each filter are optional.

To page through events, use the pagingToken field on the relevant Api.EventResponse object to set the cursor parameter.

General node health check.

Fetch the latest ledger meta info from network which this Soroban RPC server is connected to.

Reads the current value of arbitrary ledger entries directly.

Allows you to directly inspect the current state of contracts, contract's code, accounts, or any other ledger entries.

To fetch a contract's WASM byte-code, built the appropriate xdr.LedgerKeyContractCode ledger entry key (or see Contract.getFootprint).

Fetch metadata about the network this Soroban RPC server is connected to.

Fetch the details of a submitted transaction.

After submitting a transaction, clients should poll this to tell when the transaction has completed.

Fetches an account's most current state in the ledger, then creates and returns an AccountResponse object.

People on the Stellar network can make offers to buy or sell assets. This endpoint represents all the offers on the DEX.

You can query all offers for account using the function .accountId:

server.offers()
 .forAccount(accountId).call()
 .then(function(offers) {
   console.log(offers);
 });

Submit a trial contract invocation, first run a simulation of the contract invocation as defined on the incoming transaction, and apply the results to a new copy of the transaction which is then returned. Setting the ledger footprint and authorization, so the resulting transaction is ready for signing & sending.

The returned transaction will also have an updated fee that is the sum of fee set on incoming transaction with the contract resource fees estimated from simulation. It is adviseable to check the fee on returned transaction and validate or take appropriate measures for interaction with user to confirm it is acceptable.

You can call the Server.simulateTransaction method directly first if you want to inspect estimated fees for a given transaction in detail first, then re-assemble it manually or via assembleTransaction.

Fund a new account using the network's friendbot faucet, if any.

Submit a real transaction to the Stellar network.

Unlike Horizon, Soroban RPC does not wait for transaction completion. It simply validates the transaction and enqueues it. Clients should call Server.getTransactionStatus to learn about transaction success/failure.

Submit a trial contract invocation to get back return values, expected ledger footprint, expected authorizations, and expected costs.

The Stellar Network allows payments to be made between assets through path payments. A strict receive path payment specifies a series of assets to route a payment through, from source asset (the asset debited from the payer) to destination asset (the asset credited to the payee).

A strict receive path search is specified using:

• The destination address.
• The source address or source assets.
• The asset and amount that the destination account should receive.

As part of the search, horizon will load a list of assets available to the source address and will find any payment paths from those source assets to the desired destination asset. The search's amount parameter will be used to determine if there a given path can satisfy a payment of the desired amount.

If a list of assets is passed as the source, horizon will find any payment paths from those source assets to the desired destination asset.

The Stellar Network allows payments to be made between assets through path payments. A strict send path payment specifies a series of assets to route a payment through, from source asset (the asset debited from the payer) to destination asset (the asset credited to the payee).

A strict send path search is specified using:

The asset and amount that is being sent. The destination account or the destination assets.

Submits a transaction to the network.

By default this function calls Server#checkMemoRequired, you can skip this check by setting the option skipMemoRequiredCheck to true.

If you submit any number of manageOffer operations, this will add an attribute to the response that will help you analyze what happened with your offers.

Ex:

const res = {
  ...response,
  offerResults: [
    {
      // Exact ordered list of offers that executed, with the exception
      // that the last one may not have executed entirely.
      offersClaimed: [
        sellerId: String,
        offerId: String,
        assetSold: {
          type: 'native|credit_alphanum4|credit_alphanum12',

          // these are only present if the asset is not native
          assetCode: String,
          issuer: String,
        },

        // same shape as assetSold
        assetBought: {}
      ],

      // What effect your manageOffer op had
      effect: "manageOfferCreated|manageOfferUpdated|manageOfferDeleted",

      // Whether your offer immediately got matched and filled
      wasImmediatelyFilled: Boolean,

      // Whether your offer immediately got deleted, if for example the order was too small
      wasImmediatelyDeleted: Boolean,

      // Whether the offer was partially, but not completely, filled
      wasPartiallyFilled: Boolean,

      // The full requested amount of the offer is open for matching
      isFullyOpen: Boolean,

      // The total amount of tokens bought / sold during transaction execution
      amountBought: Number,
      amountSold: Number,

      // if the offer was created, updated, or partially filled, this is
      // the outstanding offer
      currentOffer: {
        offerId: String,
        amount: String,
        price: {
          n: String,
          d: String,
        },

        selling: {
          type: 'native|credit_alphanum4|credit_alphanum12',

          // these are only present if the asset is not native
          assetCode: String,
          issuer: String,
        },

        // same as `selling`
        buying: {},
      },

      // the index of this particular operation in the op stack
      operationIndex: Number
    }
  ]
}

For example, you'll want to examine offerResults to add affordances like these to your app:

• If wasImmediatelyFilled is true, then no offer was created. So if you normally watch the Server.offers endpoint for offer updates, you instead need to check Server.trades to find the result of this filled offer.
• If wasImmediatelyDeleted is true, then the offer you submitted was deleted without reaching the orderbook or being matched (possibly because your amounts were rounded down to zero). So treat the just-submitted offer request as if it never happened.
• If wasPartiallyFilled is true, you can tell the user that amountBought or amountSold have already been transferred.

Returns