Releases: stellar/js-stellar-sdk
v13.1.0
v13.1.0
Added
- Added
Horizon.Server.root
to obtain information from the Horizon root endpoint (#1122).
Fixed
- When using a friendbot that points to a Horizon instance that has ledger metadata disabled, you can no longer extract the account sequence from the response. Instead, we hit RPC directly (#1107).
rpc.Server.getEvents()
now correctly returns thecursor
field at the top-level response (#1124).
Contributors
Full Changelog: v13.0.0...v13.1.0
v13.0.0
v13.0.0: Protocol 22
This is a direct re-tag of rc.2 with the only change being an upgrade to the stellar-base
library to incorporate a patch release. Nonetheless, the entire changelog from the prior major version here is replicated for a comprehensive view on what's broken, added, and fixed.
Breaking Changes
- We stopped supporting Node 18 explicitly a while ago, but now the Babelification of the codebase will transform to Node 18 instead of 16.
TypeScript Bindings: the contract
module.
contract.AssembledTransaction#signAuthEntries
now takes anaddress
instead of apublicKey
. This brings the API more inline with its actual functionality: It can be used to sign all the auth entries for a particular address, whether that is the address of an account (public key) or a contract. (#1044).- The
ClientOptions.signTransaction
type has been updated to reflect the latest SEP-43 protocol, which matches the latest major version of Freighter and other wallets. It now acceptsaddress
,submit
, andsubmitUrl
options, and it returns a promise containing thesignedTxXdr
and thesignerAddress
. It now also returns anError
type if an error occurs during signing.basicNodeSigner
has been updated to reflect this new type.
ClientOptions.signAuthEntry
type has been updated to reflect the SEP-43 protocol, which returns a promise containing thesignerAddress
in addition to thesignAuthEntry
that was returned previously. It also can return anError
type.SentTransaction.init
andnew SentTransaction
now take one (1) argument instead of two (2). The first argument had previously been deprecated and ignored. To update:
-SentTransaction(nonsense, realStuff)
+SentTransaction(realStuff)
-new SentTransaction(nonsense, realStuff)
+new SentTransaction(realStuff)
Server APIs: the rpc
and Horizon
modules.
- Deprecated RPC APIs have been removed (#1084):
simulateTransaction
'scost
field is removedrpc.Server.getEvents
'spagingToken
field is deprecated, usecursor
instead
- Deprecated Horizon APIs have been removed (deprecated since v10.0.1, ):
- removed fields
transaction_count
,base_fee
, andbase_reserve
- removed fields
num_accounts
andamount
from assets
- removed fields
- The
SorobanRpc
import, previously deprecated, has been removed. You can importrpc
instead:
-import { SorobanRpc } from '@stellar/stellar-sdk'
+import { rpc } from '@stellar/stellar-sdk'
// alternatively, you can also import from the `rpc` entrypoint:
import { Server } from '@stellar/stellar-sdk/rpc'
Added
TypeScript Bindings: the contract
module.
contract.Client
now has a staticdeploy
method that can be used to deploy a contract instance from an existing uploaded/"installed" Wasm hash. The first arguments to this method are the arguments for the contract's__constructor
method in accordance with CAP-42 (#1086). For example, using theincrement
test contract as modified in https://github.com/stellar/soroban-test-examples/pull/2/files#diff-8734809100be3803c3ce38064730b4578074d7c2dc5fb7c05ca802b2248b18afR10-R45:
const tx = await contract.Client.deploy(
{ counter: 42 },
{
networkPassphrase,
rpcUrl,
wasmHash: uploadedWasmHash,
publicKey: someKeypair.publicKey(),
...basicNodeSigner(someKeypair, networkPassphrase),
},
);
const { result: client } = await tx.signAndSend();
const t = await client.get();
expect(t.result, 42);
contract.AssembledTransaction#signAuthEntries
now allows you to overrideauthorizeEntry
. This can be used to streamline novel workflows using cross-contract auth. (#1044).
Server modules: the rpc
, Horizon
, and stellartoml
modules.
Horizon.ServerApi
now has anEffectType
exported so that you can compare and infer effect types directly (#1099).Horizon.ServerApi.Trade
type now has atype_i
field for type inference (#1099).- All effects now expose their type as an exact string (#947).
stellartoml.Resolver.resolve
now has aallowedRedirects
option to configure the number of allowed redirects to follow when resolving a stellar toml file.rpc.Server.getEvents
now returns acursor
field that matchespagingToken
andid
rpc.Server.getTransactions
now returns atxHash
fieldrpc.Server
has two new methods:
export interface BalanceResponse {
latestLedger: number;
/** present only on success, otherwise request malformed or no balance */
balanceEntry?: {
/** a 64-bit integer */
amount: string;
authorized: boolean;
clawback: boolean;
lastModifiedLedgerSeq?: number;
liveUntilLedgerSeq?: number;
};
}
New bundles without dependencies
- You can now build the browser bundle without various dependencies:
- Set
USE_AXIOS=false
to build without theaxios
dependency: this will buildstellar-sdk-no-axios.js
andstellar-sdk-no-axios.min.js
in thedist/
directory, or just runyarn build:browser:no-axios
to generate these files. - You can import Node packages without the
axios
dependency via@stellar/stellar-sdk/no-axios
. For Node environments that don't support modern imports, use@stellar/stellar-sdk/lib/no-axios/index
. - Set
USE_EVENTSOURCE=false
to build without theeventsource
dependency: this will buildstellar-sdk-no-eventsource.js
andstellar-sdk-no-eventsource.min.js
in thedist/
directory, or just runyarn build:browser:no-eventsource
to generate these files. - You can import Node packages without the
eventsource
dependency via@stellar/stellar-sdk/no-eventsource
. For Node.js environments that don't support modern imports, use@stellar/stellar-sdk/lib/no-eventsource/index
. - To use a minimal build without both Axios and EventSource, use
stellar-sdk-minimal.js
for the browser build and import from@stellar/stellar-sdk/minimal
for the Node package.
- Set
Fixed
contract.AssembledTransaction#nonInvokerSigningBy
now correctly returns contract addresses, in instances of cross-contract auth, rather than throwing an error.sign
will ignore these contract addresses, since auth happens via cross-contract call (#1044).buildInvocationTree
now correctly handles V2 contract creation and displays constructor args (js-stellar-base#785).
v13.0.0-rc.2
v13.0.0-rc.2
Breaking Changes
- The
ClientOptions.signTransaction
type has been updated to reflect the latest SEP-43 protocol, which matches the latest major version of Freighter and other wallets. It now acceptsaddress
,submit
, andsubmitUrl
options, and it returns a promise containing thesignedTxXdr
and thesignerAddress
. It now also returns anError
type if an error occurs during signing.basicNodeSigner
has been updated to reflect the new type.
ClientOptions.signAuthEntry
type has also been updated to reflect the SEP-43 protocol, which also returns a promise containing thesignerAddress
in addition to thesignAuthEntry
that was returned previously. It also can return anError
type.
Added
contract.Client
now has a staticdeploy
method that can be used to deploy a contract instance from an existing uploaded/"installed" Wasm hash. The first arguments to this method are the arguments for the contract's__constructor
method in accordance with CAP-42 (#1086).
For example, using the increment
test contract as modified in https://github.com/stellar/soroban-test-examples/pull/2/files#diff-8734809100be3803c3ce38064730b4578074d7c2dc5fb7c05ca802b2248b18afR10-R45:
const tx = await contract.Client.deploy(
{ counter: 42 },
{
networkPassphrase,
rpcUrl,
wasmHash: uploadedWasmHash,
publicKey: someKeypair.publicKey(),
...basicNodeSigner(someKeypair, networkPassphrase),
},
);
const { result: client } = await tx.signAndSend();
const t = await client.get();
expect(t.result, 42);
Horizon.ServerApi
now has anEffectType
exported so that you can compare and infer effect types directly (#1099).Horizon.ServerApi.Trade
type now has atype_i
field for type inference.- All effects now expose their type as an exact string (#947).
stellartoml-Resolver.resolve
now has aallowedRedirects
option to configure the number of allowed redirects to follow when resolving a stellar toml file.
v13.0.0-rc.1
v13.0.0-rc.1
: Protocol 22
Breaking Changes
-
Deprecated RPC APIs have been removed (#1084):
simulateTransaction
'scost
field is removedgetEvents
returns acursor
field that matchespagingToken
andid
getTransactions
returns atxHash
field
-
Horizon Server API types: removed fields
transaction_count
,base_fee
, andbase_reserve
(deprecated since v10.0.1) -
SentTransaction.init
andnew SentTransaction
now take one (1) argument instead of two (2). The first argument had previously been deprecated and ignored. To update:-SentTransaction(nonsense, realStuff) +SentTransaction(realStuff) -new SentTransaction(nonsense, realStuff) +new SentTransaction(realStuff)
-
SorobanRpc
import, previously deprecated, has been removed. You can importrpc
instead:-import { SorobanRpc } from '@stellar/stellar-sdk' +import { rpc } from '@stellar/stellar-sdk'
As an alternative, you can also import from the
rpc
entrypoint:import { Server } from '@stellar/stellar-sdk/rpc'
Added
rpc.Server
now has apollTransaction
method to retry transaction retrieval (#1092).
Full Changelog: v13.0.0-beta.1...v13.0.0-rc.1
v13.0.0-beta.1: Protocol 22
v13.0.0-beta.1
This is the first release that supports Protocol 22. While the network has not upgraded yet, you can start integrating the new features into your codebase if you want a head start. Keep in mind that while the binary XDR is backwards-compatible, the naming and layout of structures is not. In other words, this build will continue to work on Protocol 21, but you may have to update code that references XDR directly.
Breaking Changes
contract.AssembledTransaction#signAuthEntries
now takes anaddress
instead of apublicKey
. This brings the API more inline with its actual functionality: It can be used to sign all the auth entries for a particular address, whether that is the address of an account (public key) or a contract. (#1044).- The Node.js code will now Babelify to Node 18 instead of Node 16, but we stopped supporting Node 16 long ago so this shouldn't be a breaking change.
Added
- You can now build the browser bundle without various dependencies:
- Set
USE_AXIOS=false
to build without theaxios
dependency: this will buildstellar-sdk-no-axios.js
andstellar-sdk-no-axios.min.js
in thedist/
directory, or just runyarn build:browser:no-axios
to generate these files. - You can import Node packages without the
axios
dependency via@stellar/stellar-sdk/no-axios
. For Node environments that don't support modern imports, use@stellar/stellar-sdk/lib/no-axios/index
. - Set
USE_EVENTSOURCE=false
to build without theeventsource
dependency: this will buildstellar-sdk-no-eventsource.js
andstellar-sdk-no-eventsource.min.js
in thedist/
directory, or just runyarn build:browser:no-eventsource
to generate these files. - You can import Node packages without the
eventsource
dependency via@stellar/stellar-sdk/no-eventsource
. For Node.js environments that don't support modern imports, use@stellar/stellar-sdk/lib/no-eventsource/index
. - To use a minimal build without both Axios and EventSource, use
stellar-sdk-minimal.js
for the browser build and import from@stellar/stellar-sdk/minimal
for the Node package.
- Set
contract.AssembledTransaction#signAuthEntries
now allows you to overrideauthorizeEntry
. This can be used to streamline novel workflows using cross-contract auth. (#1044)rpc.Server
now has agetSACBalance
helper which lets you fetch the balance of a built-in Stellar Asset Contract token held by a contract (#1046):
export interface BalanceResponse {
latestLedger: number;
/** present only on success, otherwise request malformed or no balance */
balanceEntry?: {
/** a 64-bit integer */
amount: string;
authorized: boolean;
clawback: boolean;
lastModifiedLedgerSeq?: number;
liveUntilLedgerSeq?: number;
};
}
Fixed
contract.AssembledTransaction#nonInvokerSigningBy
now correctly returns contract addresses, in instances of cross-contract auth, rather than throwing an error.sign
will ignore these contract addresses, since auth happens via cross-contract call (#1044).
Contributors
@Shaptic @psheth9 @BlaineHeffron @chadoh
New Contributors
- @ElliotFriend made their first contribution in #965
- @omahs made their first contribution in #1069
Full Changelog: v12.3.0...v13.0.0-beta.1
v12.3.0
Added
rpc.Server
now has agetTransactions
, which has the same response schema asgetTransactions
except with bundles of transactions (#1037).rpc.Server
now has agetVersionInfo
method which reports version information of the RPC instance it is connected to (#1028):
export interface GetVersionInfoResponse {
version: string;
commit_hash: string;
build_time_stamp: string;
captive_core_version: string;
protocol_version: number;
}
Fixed
- Lower authorization entry's default signature expiration to ~8min for security reasons (#1023).
- Remove
statusText
error check to broaden compatibility (#1001). - Upgraded
stellar-base
which includes various fixes (release notes, #1045).
Contributors
@Shaptic @chadoh @aditya1702 @psheth9
New Contributors
- @jeesunikim made their first contribution in #1025
- @cah4a made their first contribution in #1001
Full Changelog: v12.2.0...v12.3.0
v12.2.0
Fixed
@stellar/stellar-base
and its underlying dependency@stellar/js-xdr
have been upgraded to their latest versions; reference their release notes (v12.1.0 and v3.1.2, respectively) for details (#1013).
Added
- You can now pass custom headers to both
rpc.Server
andHorizon.Server
(#1013):
import { Server } from "@stellar/stellar-sdk/rpc";
const s = new Server("<some URL>", { headers: { "X-Custom-Header": "hello" }})
Horizon.Server
now supports the newPOST /transactions_async
endpoint via thesubmitAsyncTransaction
method (#989). Its purpose is to provide an immediate response to the submission rather than waiting for Horizon to determine its status. The response schema is as follows:
interface SubmitAsyncTransactionResponse {
// the submitted transaction hash
hash: string;
// one of "PENDING", "DUPLICATE", "TRY_AGAIN_LATER", or "ERROR"
tx_status: string;
// a base64-encoded xdr.TransactionResult iff `tx_status` is "ERROR"
error_result_xdr: string;
}
rpc.Server
now has agetFeeStats
method which retrieves fee statistics for a previous chunk of ledgers to provide users with a way to provide informed decisions about getting their transactions included in the following ledgers (#998):
export interface GetFeeStatsResponse {
sorobanInclusionFee: FeeDistribution;
inclusionFee: FeeDistribution;
latestLedger: number; // uint32
}
interface FeeDistribution {
max: string; // uint64
min: string; // uint64
mode: string; // uint64
p10: string; // uint64
p20: string; // uint64
p30: string; // uint64
p40: string; // uint64
p50: string; // uint64
p60: string; // uint64
p70: string; // uint64
p80: string; // uint64
p90: string; // uint64
p95: string; // uint64
p99: string; // uint64
transactionCount: string; // uint32
ledgerCount: number; // uint32
}
New Contributors
- @celestialkylin made their first contribution in #988
- @aditya1702 made their first contribution in #989
- @kanwalpreetd made their first contribution in #1008
Full Changelog: v12.1.0...v12.2.0
v12.1.0
v12.1.0
Added
contract
now exports theDEFAULT_TIMEOUT
(#984).contract.AssembledTransaction
now has:toXDR
andfromXDR
methods for serializing the transaction to and from XDR. These methods should be used in place ofAssembledTransaction.toJSON
andAssembledTransaction.fromJSON
for multi-auth signing. The JSON methods are now deprecated. Note: you must now callsimulate
on the transaction before the finalsignAndSend
call after all required signatures are gathered when using the XDR methods (#977).- a
restoreFootprint
method which accepts therestorePreamble
returned when a simulation call fails due to some contract state that has expired. When invoking a contract function, one can now setrestore
totrue
in theMethodOptions
. When enabled, arestoreFootprint
transaction will be created and await signing when required (#991). - separate
sign
andsend
methods so that you can sign a transaction without sending it (signAndSend
still works as before; #922).
contract.Client
now has atxFromXDR
method which should be used in place oftxFromJSON
for multi-auth signing (#977).
Deprecated
- In
contract.AssembledTransaction
,toJSON
andfromJSON
should be replaced withtoXDR
andfromXDR
. - In
contract.Client
,txFromJSON
should be replaced withtxFromXDR
.
Fixed
- If you edit an
AssembledTransaction
withtx.raw = cloneFrom(tx.build)
, thetx.simulationData
will now be updated correctly (#985).
v12.0.1
v12.0.1: Protocol 21 Stable Release
This update supports Protocol 21. It is an additive change to the protocol so there are no binary (i.e. XDR-level) incompatibilities, but your software may break if you encounter new unexpected or renamed fields from this Protocol (#949).
The following changelog is a concatenation of all of the RCs since the previous stable release and includes one additional added feature.
Breaking Changes
- The default timeout for transaction calls is now set to 300 seconds (5 minutes) when using
ContractClient
from the previous default of 10 seconds. 10 seconds is often not enough time to review transactions before signing, especially in Freighter or using a hardware wallet like a Ledger, which would cause atxTooLate
error response from the server. Five minutes is also the value used by the CLI, so this brings the two into alignment (#956). ContractClient
functionality previously added in v11.3.0 was exported in a non-standard way. You can now import it as any otherstellar-sdk
module (#962):
-import { ContractClient } from '@stellar/stellar-sdk/lib/contract_client'
+import { contract } from '@stellar/stellar-sdk'
+const { Client } = contract
Note that this top-level contract
export is a container for ContractClient and related functionality. The ContractClient
class is now available at contract.Client
, as shown. Further note that there is a capitalized Contract
export as well, which comes from stellar-base. You can remember which is which because capital-C Contract
is a class, whereas lowercase-c contract
is a container/module with a bunch of classes, functions, and types.
Additionally, this is available from the /contract
entrypoint, if your version of Node and TypeScript support the exports
declaration. Finally, some of its exports have been renamed:
import {
AssembledTransaction,
SentTransaction,
- ContractClient,
- ContractClientOptions,
-} from '@stellar/stellar-sdk/lib/contract_client'
+ Client,
+ ClientOptions,
+} from '@stellar/stellar-sdk/contract'
- The
ContractSpec
class is now nested under thecontract
module, and has been renamed toSpec
(#962). Alternatively, you can import this from thecontract
entrypoint, if your version of Node and TypeScript support theexports
declaration:
-import { ContractSpec } from '@stellar/stellar-sdk'
+import { contract } from '@stellar/stellar-sdk'
+const { Spec } = contract
// OR
+import { Spec } from '@stellar/stellar-sdk/contract'
- Previously,
AssembledTransaction.signAndSend()
would return aSentTransaction
even if the transaction never finalized. That is, if it successfully sent the transaction to the network, but the transaction was stillstatus: 'PENDING'
, then it wouldconsole.error
an error message, but return the indeterminate transaction anyhow. It now throws aSentTransaction.Errors.TransactionStillPending
error with that error message instead (#962).
Deprecated
SorobanRpc
module is now also exported asrpc
(#962). You can import it with either name for now, butSorobanRpc
will be removed in a future release:
-import { SorobanRpc } from '@stellar/stellar-sdk'
+import { rpc } from '@stellar/stellar-sdk'
You can also now import it at the /rpc
entrypoint, if your version of Node and TypeScript support the exports
declaration.
-import { SorobanRpc } from '@stellar/stellar-sdk'
-const { Api } = SorobanRpc
+import { Api } from '@stellar/stellar-sdk/rpc'
Added
- New methods on
contract.Client
(#960):from(opts: ContractClientOptions)
instantiatescontract.Client
by fetching thecontractId
's WASM from the network to fill out the client'sContractSpec
.fromWasm
andfromWasmHash
methods to instantiate acontract.Client
when you already have the WASM bytes or hash alongside thecontract.ClientOptions
.
- New methods on
rpc.Server
(#960):getContractWasmByContractId
andgetContractWasmByHash
to retrieve a contract's WASM bytecode via itscontractId
orwasmHash
, respectively.
rpc.server.simulateTransaction
now supports an optionalstateChanges?: LedgerEntryChange[]
field (#963):- If
Before
is omitted, it constitutes a creation, ifAfter
is omitted, it constitutes a deletions, note thatBefore
andAfter
cannot be be omitted at the same time. Each item follows this schema:
- If
interface LedgerEntryChange {
type: number;
key: xdr.LedgerKey;
before: xdr.LedgerEntry | null;
after: xdr.LedgerEntry | null;
}
Fixed
- The breaking changes above (strictly speaking, they are not breaking changes because importing from the inner guts of the SDK is not supported) enable the
contract
module to be used in non-Node environments. - Dependencies have been properly updated to pull in Protocol 21 XDR, where RC1 was not pulling properly for existing installs (#959).
- Each item in the
GetEventsResponse.events
list will now have atxHash
item corresponding to the transaction hash that triggered a particular event (#939). ContractClient
now properly handles methods that take no arguments by makingMethodOptions
the only parameter, bringing it inline with the types generated by Soroban CLI'ssoroban contract bindings typescript
(#940).ContractClient
now allowspublicKey
to be undefined (#941).SentTransaction
will only passallowHttp
if (and only if) its correspondingAssembledTransaction#options
config allowed it (#952).
New Contributors
- @silence48 made their first contribution in #934
- @BlaineHeffron made their first contribution in #951
- @psheth9 made their first contribution in #963
Full Changelog: v11.3.0...v12.0.1
v12.0.0-rc.3
v12.0.0-rc.3: Protocol 21 Release Candidate 3
This update supports Protocol 21. It is an additive change to the protocol so there are no true backwards incompatibilities, but your software may break if you encounter new unexpected fields from this Protocol (#949).
Breaking Changes
ContractClient
functionality previously added in v11.3.0 was exported in a non-standard way. You can now import it as any otherstellar-sdk
module (#962):
-import { ContractClient } from '@stellar/stellar-sdk/lib/contract_client'
+import { contract } from '@stellar/stellar-sdk'
+const { Client } = contract
Note that this top-level contract
export is a container for ContractClient and related functionality. The ContractClient
class is now available at contract.Client
, as shown. Further note that there is a capitalized Contract
export as well, which comes from stellar-base. You can remember which is which because capital-C Contract
is a class, whereas lowercase-c contract
is a container/module with a bunch of classes, functions, and types.
Additionally, this is available from the /contract
entrypoint, if your version of Node and TypeScript support the exports
declaration. Finally, some of its exports have been renamed:
import {
AssembledTransaction,
SentTransaction,
- ContractClient,
- ContractClientOptions,
-} from '@stellar/stellar-sdk/lib/contract_client'
+ Client,
+ ClientOptions,
+} from '@stellar/stellar-sdk/contract'
- The
ContractSpec
class is now nested under thecontract
module, and has been renamed toSpec
(#962). Alternatively, you can import this from thecontract
entrypoint, if your version of Node and TypeScript support theexports
declaration:
-import { ContractSpec } from '@stellar/stellar-sdk'
+import { contract } from '@stellar/stellar-sdk'
+const { Spec } = contract
// OR
+import { Spec } from '@stellar/stellar-sdk/contract'
- Previously,
AssembledTransaction.signAndSend()
would return aSentTransaction
even if the transaction never finalized. That is, if it successfully sent the transaction to the network, but the transaction was stillstatus: 'PENDING'
, then it wouldconsole.error
an error message, but return the indeterminate transaction anyhow. It now throws aSentTransaction.Errors.TransactionStillPending
error with that error message instead (#962).
Deprecated
SorobanRpc
module is now also exported asrpc
(#962). You can import it with either name for now, butSorobanRpc
will be removed in a future release:
-import { SorobanRpc } from '@stellar/stellar-sdk'
+import { rpc } from '@stellar/stellar-sdk'
You can also now import it at the /rpc
entrypoint, if your version of Node and TypeScript support the exports
declaration.
-import { SorobanRpc } from '@stellar/stellar-sdk'
-const { Api } = SorobanRpc
+import { Api } from '@stellar/stellar-sdk/rpc'
Added
- New methods on
contract.Client
(#960):from(opts: ContractClientOptions)
instantiatescontract.Client
by fetching thecontractId
's WASM from the network to fill out the client'sContractSpec
.fromWasm
andfromWasmHash
methods to instantiate acontract.Client
when you already have the WASM bytes or hash alongside thecontract.ClientOptions
.
- New methods on
rpc.Server
(#960):getContractWasmByContractId
andgetContractWasmByHash
to retrieve a contract's WASM bytecode via itscontractId
orwasmHash
, respectively.
Fixed
- The breaking changes above (strictly speaking, they are not breaking changes because importing from the inner guts of the SDK is not supported) enable the
contract
module to be used in non-Node environments.
Full Changelog: v11.3.0...v12.0.0-rc.3