Constructor

# new Server(serverURL, optsopt)

Horizon Server URL (ex. https://horizon-testnet.stellar.org)

Parameters:

Name	Type	Attributes	Description
`serverURL`	`string`		Horizon Server URL (ex. `https://horizon-testnet.stellar.org`).
`opts`	`module:Horizon.Server.Options`	<optional>	Options object

To Do:

Solve `URI(this.serverURL as any)`.

View Source lib/horizon/server.js, line 64

Members

Type: URI

# serverURL

Horizon Server URL (ex. https://horizon-testnet.stellar.org)

To Do:

Solve `URI(this.serverURL as any)`.

View Source lib/minimal/horizon/server.d.ts, line 31

Type: number

# static constant SUBMIT_TRANSACTION_TIMEOUT

Default transaction submission timeout for Horizon requests, in milliseconds

Default Value:

60000

View Source lib/horizon/server.js, line 44

Methods

# accounts() → {AccountCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 203

Returns:

New AccountCallBuilder object configured by a current Horizon server configuration.

Type: AccountCallBuilder

# assets() → {AssetsCallBuilder}

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

View Source lib/minimal/horizon/server.d.ts, line 330

Returns:

New AssetsCallBuilder instance

Type: AssetsCallBuilder

# checkMemoRequired(transaction) → {Promise.<void, Error>}

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.

Parameters:

Name	Type	Description
`transaction`	`Transaction`	The transaction to check.

See:

SEP-29: Account Memo Requirements

View Source lib/minimal/horizon/server.d.ts, line 373

Throws:

Type: AccountRequiresMemoError

Returns:

If any of the destination account requires a memo, the promise will throw AccountRequiresMemoError.

Type: Promise.<void, Error>

# claimableBalances() → {ClaimableBalanceCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 208

Returns:

New ClaimableBalanceCallBuilder object configured by a current Horizon server configuration.

Type: ClaimableBalanceCallBuilder

# effects() → {EffectCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 315

Returns:

New EffectCallBuilder instance configured with the current Horizon server configuration

Type: EffectCallBuilder

# feeStats() → {Promise.<HorizonApi.FeeStatsResponse>}

Fetch the fee stats endpoint.

See:

Fee Stats

View Source lib/minimal/horizon/server.d.ts, line 76

Returns:

Promise that resolves to the fee stats returned by Horizon.

Type: Promise.<HorizonApi.FeeStatsResponse>

# fetchBaseFee() → {Promise.<number>}

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!

View Source lib/minimal/horizon/server.d.ts, line 69

Returns:

Promise that resolves to the base fee.

Type: Promise.<number>

# fetchTimebounds(seconds, _isRetryopt) → {Promise.<Timebounds>}

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.

Parameters:

Name	Type	Attributes	Description
`seconds`	`number`		Number of seconds past the current time to wait.
`_isRetry`	`boolean`	<optional>	True if this is a retry. Only set this internally! This is to avoid a scenario where Horizon is horking up the wrong date.

View Source lib/minimal/horizon/server.d.ts, line 61

Returns:

Promise that resolves a timebounds object (with the shape { minTime: 0, maxTime: N }) that you can set the timebounds option to.

Type: Promise.<Timebounds>

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();

# ledgers() → {LedgerCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 213

Returns:

New LedgerCallBuilder object configured by a current Horizon server configuration.

Type: LedgerCallBuilder

# liquidityPools() → {LiquidityPoolCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 258

Returns:

New LiquidityPoolCallBuilder object configured to the current Horizon server settings.

Type: LiquidityPoolCallBuilder

# loadAccount(accountId) → {Promise}

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

Parameters:

Name	Type	Description
`accountId`	`string`	The account to load.

View Source lib/minimal/horizon/server.d.ts, line 341

Returns:

Returns a promise to the AccountResponse object with populated sequence number.

Type: Promise

# offers() → {OfferCallBuilder}

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.

View Source lib/minimal/horizon/server.d.ts, line 234

Returns:

New OfferCallBuilder object

Type: OfferCallBuilder

Example

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

# operations() → {OperationCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 252

Returns:

New OperationCallBuilder object configured by a current Horizon server configuration.

Type: OperationCallBuilder

# orderbook(selling, buying) → {OrderbookCallBuilder}

Parameters:

Name	Type	Description
`selling`	`Asset`	Asset being sold
`buying`	`Asset`	Asset being bought

View Source lib/minimal/horizon/server.d.ts, line 241

Returns:

New OrderbookCallBuilder object configured by a current Horizon server configuration.

Type: OrderbookCallBuilder

# payments() → {PaymentCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 309

Returns:

New PaymentCallBuilder instance configured with the current Horizon server configuration.

Type: PaymentCallBuilder

# strictReceivePaths(source, destinationAsset, destinationAmount) → {StrictReceivePathCallBuilder}

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.

Parameters:

Name	Type	Description
`source`	`string` \| `Array.<Asset>`	The sender's account ID or a list of assets. Any returned path will use a source that the sender can hold.
`destinationAsset`	`Asset`	The destination asset.
`destinationAmount`	`string`	The amount, denominated in the destination asset, that any returned path should be able to satisfy.

View Source lib/minimal/horizon/server.d.ts, line 286

Returns:

New StrictReceivePathCallBuilder object configured with the current Horizon server configuration.

Type: StrictReceivePathCallBuilder

# strictSendPaths(sourceAsset, sourceAmount, destination) → {StrictSendPathCallBuilder}

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.

Parameters:

Name	Type	Description
`sourceAsset`	`Asset`	The asset to be sent.
`sourceAmount`	`string`	The amount, denominated in the source asset, that any returned path should be able to satisfy.
`destination`	`string` \| `Array.<Asset>`	The destination account or the destination assets.

View Source lib/minimal/horizon/server.d.ts, line 303

Returns:

New StrictSendPathCallBuilder object configured with the current Horizon server configuration.

Type: StrictSendPathCallBuilder

# submitAsyncTransaction(transaction, optsopt) → {Promise}

Submits an asynchronous transaction to the network. Unlike the synchronous version, which blocks and waits for the transaction to be ingested in Horizon, this endpoint relays the response from core directly back to the user.

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

Parameters:

Name	Type	Attributes	Description
`transaction`	`Transaction` \| `FeeBumpTransaction`		The transaction to submit.
`opts`	`object`	<optional>	Options object
`skipMemoRequiredCheck`	`boolean`	<optional>	Allow skipping memo required check, default: `false`. See SEP0029.

See:

Submit-Async-Transaction

View Source lib/minimal/horizon/server.d.ts, line 198

Returns:

Promise that resolves or rejects with response from horizon.

Type: Promise

# submitTransaction(transaction, optsopt) → {Promise}

Submits a transaction to the network.

By default this function calls Horizon.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.

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.

Parameters:

Name	Type	Attributes	Description
`transaction`	`Transaction` \| `FeeBumpTransaction`		The transaction to submit.
`opts`	`object`	<optional>	Options object
`skipMemoRequiredCheck`	`boolean`	<optional>	Allow skipping memo required check, default: `false`. See SEP0029.

See:

Submit a Transaction

View Source lib/minimal/horizon/server.d.ts, line 179

Returns:

Promise that resolves or rejects with response from horizon.

Type: Promise

Example

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
    }
  ]
}

# tradeAggregation(base, counter, start_time, end_time, resolution, offset) → {TradeAggregationCallBuilder}

Parameters:

Name	Type	Description
`base`	`Asset`	base asset
`counter`	`Asset`	counter asset
`start_time`	`number`	lower time boundary represented as millis since epoch
`end_time`	`number`	upper time boundary represented as millis since epoch
`resolution`	`number`	segment duration as millis since epoch. *Supported values are 5 minutes (300000), 15 minutes (900000), 1 hour (3600000), 1 day (86400000) and 1 week (604800000).
`offset`	`number`	segments can be offset using this parameter. Expressed in milliseconds. *Can only be used if the resolution is greater than 1 hour. Value must be in whole hours, less than the provided resolution, and less than 24 hours. Returns new TradeAggregationCallBuilder object configured with the current Horizon server configuration.

View Source lib/minimal/horizon/server.d.ts, line 354

Returns:

New TradeAggregationCallBuilder instance

Type: TradeAggregationCallBuilder

# trades() → {TradesCallBuilder}

Returns

View Source lib/minimal/horizon/server.d.ts, line 247

Returns:

New TradesCallBuilder object configured by a current Horizon server configuration.

Type: TradesCallBuilder

# transactions() → {TransactionCallBuilder}

View Source lib/minimal/horizon/server.d.ts, line 218

Returns:

New TransactionCallBuilder object configured by a current Horizon server configuration.

Type: TransactionCallBuilder

Type Definitions

Type: object

# Options

Options for configuring connections to Horizon servers.

Properties:

Name	Type	Attributes	Description
`allowHttp`	`boolean`	<optional>	Allow connecting to http servers, default: `false`. This must be set to false in production deployments! You can also use Config class to set this globally.
`appName`	`string`	<optional>	Allow set custom header `X-App-Name`, default: `undefined`.
`appVersion`	`string`	<optional>	Allow set custom header `X-App-Version`, default: `undefined`.
`authToken`	`string`	<optional>	Allow set custom header `X-Auth-Token`, default: `undefined`.

View Source lib/horizon/server.js, line 714

@stellar/stellar-sdk

# new Server(serverURL, optsopt)

Parameters:

Members

# serverURL

# static constant SUBMIT_TRANSACTION_TIMEOUT

Methods

# accounts() → {AccountCallBuilder}

# assets() → {AssetsCallBuilder}

# checkMemoRequired(transaction) → {Promise.<void, Error>}

Parameters:

# claimableBalances() → {ClaimableBalanceCallBuilder}

# effects() → {EffectCallBuilder}

# feeStats() → {Promise.<HorizonApi.FeeStatsResponse>}

# fetchBaseFee() → {Promise.<number>}

# fetchTimebounds(seconds, _isRetryopt) → {Promise.<Timebounds>}

Parameters:

Example

# ledgers() → {LedgerCallBuilder}

# liquidityPools() → {LiquidityPoolCallBuilder}

# loadAccount(accountId) → {Promise}

Parameters:

# offers() → {OfferCallBuilder}

Example

# operations() → {OperationCallBuilder}

# orderbook(selling, buying) → {OrderbookCallBuilder}

Parameters:

# payments() → {PaymentCallBuilder}

# strictReceivePaths(source, destinationAsset, destinationAmount) → {StrictReceivePathCallBuilder}

Parameters:

# strictSendPaths(sourceAsset, sourceAmount, destination) → {StrictSendPathCallBuilder}

Parameters:

# submitAsyncTransaction(transaction, optsopt) → {Promise}

Parameters:

# submitTransaction(transaction, optsopt) → {Promise}

Parameters:

Example

# tradeAggregation(base, counter, start_time, end_time, resolution, offset) → {TradeAggregationCallBuilder}

Parameters:

# trades() → {TradesCallBuilder}

# transactions() → {TransactionCallBuilder}

Type Definitions

# Options

Properties: