build(deps): bump @stellar/stellar-sdk from 15.1.0 to 17.1.0

[dependabot]

Bumps @stellar/stellar-sdk from 15.1.0 to 17.1.0.

Release notes

Sourced from @​stellar/stellar-sdk's releases.

v17.1.0

v17.1.0

Added

• getClaimableBalanceIdFromResult(result, opIndex): reads the claimable balance ID created by a CreateClaimableBalance operation out of a submitted transaction's xdr.TransactionResult, unwrapping a fee bump when there is one. It returns the same 72-character hex form as Transaction.getClaimableBalanceId(opIndex), which derives the ID before submission; use this one when you only have the result. Horizon's result_xdr is base64, so decode it first with xdr.TransactionResult.fromXdr(result_xdr, "base64"), while rpc.Server.getTransaction already returns a parsed resultXdr. It throws a RangeError for an out-of-range opIndex, and a TypeError when result is not a transaction result, when the transaction failed, or when the operation at opIndex is not a successful CreateClaimableBalance (#1719).

Fixed

• Generated TypeScript bindings keep the raw spec name for a function parameter or struct field that is a reserved word or not a valid identifier, instead of renaming it: since #1345 a parameter new was typed as new_ while the runtime read new, so the typed call threw Missing field new, and a typed struct read of a renamed field was undefined. Methods and deploy now take a single args object, set(args: { new: number }, options?); call sites are unchanged, callers who used a renamed key switch to the raw name (new_ to new, _1st to args["1st"]), method names still get the trailing _, and a __constructor with no inputs now generates deploy(null, options) instead of deploy(options) (#1733).
• Horizon call builders now confine a resource identifier to one URL path segment, so a / in it no longer opens a new segment. An identifier that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint — accountId("") previously reached the collection endpoint and returned a page of records, and accountId([".."]) resolved to the server root. Affects accountId(), transaction(), operation(), offer(), claimableBalance(), ledger(), liquidityPoolId(), loadAccount() and the for*() neighbor filters; liquidityPoolId() was reachable the same way because its hex check is unanchored, which is tracked separately in #1703. A decimal number or bigint identifier still works, and well-formed identifiers are unaffected, since no valid Stellar identifier contains /, ., ? or # (#1702).
• These TypeErrors are thrown synchronously from call() and stream() rather than as a rejected promise, which matches the existing Too many filters specified error, so a caller that only attaches .catch() needs a try/catch. Three cases sit outside that, all unchanged by this release: loadAccount() is async, so it rejects and .catch() does work; liquidityPools().liquidityPoolId() throws from the builder method; and ledgers().ledger() with the forLedger() filters coerce the sequence with toString() first, so a nullish sequence throws there rather than reaching this guard (#1702).
• Templated Horizon _links functions now apply the call builders' path-segment guard to a path variable. One that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint: account.data({ key: ".." }) previously requested the account endpoint, not the data endpoint. Query values are unaffected. AccountResponse.data() and the server.root() links both take the path variable through an option TypeScript does not declare, so no call that compiles today changes behavior (#1718).
• StellarToml.Resolver.resolve() now validates the domain and throws Invalid domain before making a request (#1720). It previously put the string straight into the URL, so some inputs reached a different host, or a different path, than the caller named. A domain must be a plain host name with an optional port: credentials and an embedded /, ?, # or \ are rejected, as is an empty domain. Surrounding whitespace and a trailing / are stripped rather than rejected, so input that worked before keeps working. Host names, IP literals, IPv6 literals, and ports still work, but the request URL is normalized, so ACME.com is requested as acme.com.
• Asset.fromOperation preserves the assetTypeCreditAlphanum12 union arm even when the decoded code is four characters or shorter, instead of re-deriving the arm from code length. Such an asset now re-encodes to the same XDR bytes it was decoded from, and its getAssetType(), contractId(), equals(), and Asset.compare() results reflect the alphanum12 arm. equals() now also compares the asset type, so a decoded short-code alphanum12 asset is no longer equal to the alphanum4 asset with the same code and issuer. User-constructed assets are unaffected: new Asset(code, issuer) still derives the type from code length (#1584).
• rpc.Server.getContractData no longer reports a transport failure as a missing entry. It previously caught every error from the ledger lookup and rethrew { code: 404 }, so a 429, a 5xx, or a network error looked the same as an absent entry. Those errors now propagate untouched, and only a lookup that returns no entry throws the 404-shaped error, whose shape is unchanged (#1679).

Changed

• HorizonApi.Predicate gains the unconditional and abs_before_epoch fields it previously omitted, so the type now describes every predicate Horizon serves (#1701). It stays an interface, so declaration merging still works. One case does break at compile time: a consumer who already augmented the namespace to declare unconditional or abs_before_epoch with a different type than the SDK now uses gets TS2717 and must drop that part of their augmentation.
• Updated the production axios dependency from 1.18.0 to 1.20.0 (#1712).

New Contributors

• @​leocagli made their first contribution in stellar/js-stellar-sdk#1679
• @​yigitcangokmen made their first contribution in stellar/js-stellar-sdk#1670

Full Changelog: stellar/js-stellar-sdk@v17.0.1...v17.1.0

v17.0.1

v17.0.1

Added

• Every v16 XDR-acronym method spelling works again as a deprecated alias of its v17 name, easing migration. toXDR() / fromXDR() come back on xdr.* values (plus the static validateXDR()) and on Transaction / FeeBumpTransaction, TransactionBuilder, contract.AssembledTransaction, Claimant, and SorobanDataBuilder; toXDRObject() / fromXDRObject() come back on Asset (including toChangeTrustXDRObject() / toTrustLineXDRObject()), Memo, Operation, Claimant, MuxedAccount, LiquidityPoolAsset, and LiquidityPoolId. The aliases delegate to the v17 methods and keep their semantics: on xdr.* values, toXDR() returns a Uint8Array (not a Buffer) and fromXDR() requires a format for string input; the wrapper-class aliases behave as they did in v16. toXdrObject() / fromXdrObject() on xdr.* values are net-new methods with no legacy spelling, so they get no alias (#1690).

Fixed

• The type-generic xdr helpers — encodeArray, decodeArray, decodeStream and the fromXdr / validateXdr / fromJson statics — now throw a TypeError naming the helper and the argument when it has no static schema, such as an Int64/Uint32 shim or an abstract base (#1682). xdr.encodeArray(xdr.Uint32, [1]) previously threw TypeError: v.toXdrObject is not a function, and on an empty list returned a valid-looking 4-byte count. The four decode paths also name a missing static fromXdrObject, which only they need. Valid types are unaffected.
• xdr.Int32, xdr.Uint32, xdr.Int64 and xdr.Uint64 report their XDR type name from .name, instead of the internal "Shim" (#1682).
• BytesValue#toString() on the named byte aliases (Hash, Signature, AssetCode4, AssetCode12, PoolId, ContractId, …) now returns the class's declared encoding instead of base64 for every wrapper: new xdr.AssetCode4("KHL1").toString() is now "KHL1", was "S0hMMQ==". Use .toXdr("base64") for the wire form (#1689).

Full Changelog: stellar/js-stellar-sdk@v17.0.0...v17.0.1

v17.0.0: Protocol 28

v17.0.0: Protocol 28

Breaking Changes

• engines.node is now >=22.12.0, up from >=22.0.0. The CommonJS build require()s ESM-only dependencies, and require(esm) is only unflagged from Node 22.12.0, so on Node 22.0–22.11 require("@stellar/stellar-sdk") fails with ERR_REQUIRE_ESM. Installing on one of those versions now produces an EBADENGINE warning instead of a package that cannot be required. Nothing changes for ESM consumers, or on Node 22.12 and later (#1667).
• Public APIs use Uint8Array instead of Node's Buffer (#1457). Methods that returned Buffer (e.g. hash(), Keypair's sign/rawPublicKey/rawSecretKey, StrKey.decode*, Transaction.hash(), rpc.Server.getContractWasmByHash, getLiquidityPoolId(), AuthEntrySignature.signature, and the signing payload passed to a SigningCallback) now return a plain Uint8Array, so Buffer-only conveniences like .toString("hex") and .equals() on results must be replaced — see docs/migration/uint8array-migration.md for method-by-method recipes. Byte inputs still accept Buffer (it's a Uint8Array subclass), with three exceptions: a SigningCallback may no longer resolve to a raw ArrayBuffer (wrap it in a Uint8Array), SorobanDataBuilder's constructor no longer accepts non-Uint8Array typed arrays, and Memo.text no longer accepts a plain number[] (https://github.com/stellar/js-stellar-sdk/blob/HEAD/see the next entry). The buffer dependency is gone (base32.js, which needed a Buffer global, is replaced by @exodus/bytes), and browsers/edge runtimes need no Buffer polyfill. Note that DecoratedSignature.signature and .hint did not become raw bytes despite the name the first shares with AuthEntrySignature.signature — they are xdr.Signature / xdr.SignatureHint wrappers, unwrapped with .toBytes() (see docs/migration/xdr-migration.md § 6).
• Memo.text no longer accepts a plain number[]. Pass new Uint8Array(arr) instead (#1457). Through 16.2.0 it took a string, a plain array, or a Buffer, and rejected a bare Uint8Array. A Uint8Array is now the canonical byte input, and a plain array is the only input lost. Memo.text([]) was a valid zero-byte memo and now throws. The error message is unchanged (https://github.com/stellar/js-stellar-sdk/blob/HEAD/`Expects string or Uint8Array, max 28 bytes), so code that matches on it still works. See [docs/migration/uint8array-migration.md`](./docs/migration/uint8array-migration.md) § 3.
• The xdr namespace is rebuilt on @stellar/js-xdr v5, and every XDR value now has a different API (#1422). The wire format is unchanged: bytes and base64 written by older SDKs still decode, and vice versa. One caveat: v17 rejects malformed base64 outright, where v16's Buffer.from(str, "base64") silently dropped any character outside the alphabet (#1666). Any code that reads or builds xdr.* values must be updated. The main shifts:
  • Start here: docs/migration/xdr-migration.md covers every change below with before/after examples and a quick-reference table.
  • Unions are discriminated classes. .switch() becomes a .type string literal, arm getters like .contractData() become properties, and new xdr.LedgerEntryData(disc, val) becomes a factory call such as xdr.LedgerEntryData.contractData(val). The legacy new form throws a TypeError naming the factory method to call (#1658).
  • Enums are singletons, not factory calls: xdr.ContractDataDurability.persistent() becomes xdr.ContractDataDurability.persistent.
  • Primitives are plain JS values. Integers are number or bigint instead of class wrappers, anonymous opaque fields are Uint8Array, LargeInt subclasses are gone, and fields are readonly.

... (truncated)

Changelog

Sourced from @​stellar/stellar-sdk's changelog.

v17.1.0

Changed

• HorizonApi.Predicate gains the unconditional and abs_before_epoch fields it previously omitted, so the type now describes every predicate Horizon serves (#1701). It stays an interface, so declaration merging still works. One case does break at compile time: a consumer who already augmented the namespace to declare unconditional or abs_before_epoch with a different type than the SDK now uses gets TS2717 and must drop that part of their augmentation.
• Updated the production axios dependency from 1.18.0 to 1.20.0 (#1712).

Added

• getClaimableBalanceIdFromResult(result, opIndex): reads the claimable balance ID created by a CreateClaimableBalance operation out of a submitted transaction's xdr.TransactionResult, unwrapping a fee bump when there is one. It returns the same 72-character hex form as Transaction.getClaimableBalanceId(opIndex), which derives the ID before submission; use this one when you only have the result. Horizon's result_xdr is base64, so decode it first with xdr.TransactionResult.fromXdr(result_xdr, "base64"), while rpc.Server.getTransaction already returns a parsed resultXdr. It throws a RangeError for an out-of-range opIndex, and a TypeError when result is not a transaction result, when the transaction failed, or when the operation at opIndex is not a successful CreateClaimableBalance (#1719).

Fixed

• Generated TypeScript bindings keep the raw spec name for a function parameter or struct field that is a reserved word or not a valid identifier, instead of renaming it: since #1345 a parameter new was typed as new_ while the runtime read new, so the typed call threw Missing field new, and a typed struct read of a renamed field was undefined. Methods and deploy now take a single args object, set(args: { new: number }, options?); call sites are unchanged, callers who used a renamed key switch to the raw name (new_ to new, _1st to args["1st"]), method names still get the trailing _, and a __constructor with no inputs now generates deploy(null, options) instead of deploy(options) (#1733).
• Horizon call builders now confine a resource identifier to one URL path segment, so a / in it no longer opens a new segment. An identifier that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint — accountId("") previously reached the collection endpoint and returned a page of records, and accountId([".."]) resolved to the server root. Affects accountId(), transaction(), operation(), offer(), claimableBalance(), ledger(), liquidityPoolId(), loadAccount() and the for*() neighbor filters; liquidityPoolId() was reachable the same way because its hex check is unanchored, which is tracked separately in #1703. A decimal number or bigint identifier still works, and well-formed identifiers are unaffected, since no valid Stellar identifier contains /, ., ? or # (#1702).
• These TypeErrors are thrown synchronously from call() and stream() rather than as a rejected promise, which matches the existing Too many filters specified error, so a caller that only attaches .catch() needs a try/catch. Three cases sit outside that, all unchanged by this release: loadAccount() is async, so it rejects and .catch() does work; liquidityPools().liquidityPoolId() throws from the builder method; and ledgers().ledger() with the forLedger() filters coerce the sequence with toString() first, so a nullish sequence throws there rather than reaching this guard (#1702).
• Templated Horizon _links functions now apply the call builders' path-segment guard to a path variable. One that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint: account.data({ key: ".." }) previously requested the account endpoint, not the data endpoint. Query values are unaffected. AccountResponse.data() and the server.root() links both take the path variable through an option TypeScript does not declare, so no call that compiles today changes behavior (#1718).
• StellarToml.Resolver.resolve() now validates the domain and throws Invalid domain before making a request (#1720). It previously put the string straight into the URL, so some inputs reached a different host, or a different path, than the caller named. A domain must be a plain host name with an optional port: credentials and an embedded /, ?, # or \ are rejected, as is an empty domain. Surrounding whitespace and a trailing / are stripped rather than rejected, so input that worked before keeps working. Host names, IP literals, IPv6 literals, and ports still work, but the request URL is normalized, so ACME.com is requested as acme.com.
• Asset.fromOperation preserves the assetTypeCreditAlphanum12 union arm even when the decoded code is four characters or shorter, instead of re-deriving the arm from code length. Such an asset now re-encodes to the same XDR bytes it was decoded from, and its getAssetType(), contractId(), equals(), and Asset.compare() results reflect the alphanum12 arm. equals() now also compares the asset type, so a decoded short-code alphanum12 asset is no longer equal to the alphanum4 asset with the same code and issuer. User-constructed assets are unaffected: new Asset(code, issuer) still derives the type from code length (#1584).
• rpc.Server.getContractData no longer reports a transport failure as a missing entry. It previously caught every error from the ledger lookup and rethrew { code: 404 }, so a 429, a 5xx, or a network error looked the same as an absent entry. Those errors now propagate untouched, and only a lookup that returns no entry throws the 404-shaped error, whose shape is unchanged (#1679).

v17.0.1

Added

• Every v16 XDR-acronym method spelling works again as a deprecated alias of its v17 name, easing migration. toXDR() / fromXDR() come back on xdr.* values (plus the static validateXDR()) and on Transaction / FeeBumpTransaction, TransactionBuilder, contract.AssembledTransaction, Claimant, and SorobanDataBuilder; toXDRObject() / fromXDRObject() come back on Asset (including toChangeTrustXDRObject() / toTrustLineXDRObject()), Memo, Operation, Claimant, MuxedAccount, LiquidityPoolAsset, and LiquidityPoolId. The aliases delegate to the v17 methods and keep their semantics: on xdr.* values, toXDR() returns a Uint8Array (not a Buffer) and fromXDR() requires a format for string input; the wrapper-class aliases behave as they did in v16. toXdrObject() / fromXdrObject() on xdr.* values are net-new methods with no legacy spelling, so they get no alias (#1690).

Fixed

• The type-generic xdr helpers — encodeArray, decodeArray, decodeStream and the fromXdr / validateXdr / fromJson statics — now throw a TypeError naming the helper and the argument when it has no static schema, such as an Int64/Uint32 shim or an abstract base (#1682). xdr.encodeArray(xdr.Uint32, [1]) previously threw TypeError: v.toXdrObject is not a function, and on an empty list returned a valid-looking 4-byte count. The four decode paths also name a missing static fromXdrObject, which only they need. Valid types are unaffected.
• xdr.Int32, xdr.Uint32, xdr.Int64 and xdr.Uint64 report their XDR type name from .name, instead of the internal "Shim" (#1682).
• BytesValue#toString() on the named byte aliases (Hash, Signature, AssetCode4, AssetCode12, PoolId, ContractId, …) now returns the class's declared encoding instead of base64 for every wrapper: new xdr.AssetCode4("KHL1").toString() is now "KHL1", was "S0hMMQ==". Use .toXdr("base64") for the wire form (#1689).

v17.0.0

Breaking Changes

• engines.node is now >=22.12.0, up from >=22.0.0. The CommonJS build require()s ESM-only dependencies, and require(esm) is only unflagged from Node 22.12.0, so on Node 22.0–22.11 require("@stellar/stellar-sdk") fails with ERR_REQUIRE_ESM. Installing on one of those versions now produces an EBADENGINE warning instead of a package that cannot be required. Nothing changes for ESM consumers, or on Node 22.12 and later (#1667).

• Public APIs use Uint8Array instead of Node's Buffer (#1457). Methods that returned Buffer (e.g. hash(), Keypair's sign/rawPublicKey/rawSecretKey, StrKey.decode*, Transaction.hash(), rpc.Server.getContractWasmByHash, getLiquidityPoolId(), AuthEntrySignature.signature, and the signing payload passed to a SigningCallback) now return a plain Uint8Array, so Buffer-only conveniences like .toString("hex") and .equals() on results must be replaced — see docs/migration/uint8array-migration.md for method-by-method recipes. Byte inputs still accept Buffer (it's a Uint8Array subclass), with three exceptions: a SigningCallback may no longer resolve to a raw ArrayBuffer (wrap it in a Uint8Array), SorobanDataBuilder's constructor no longer accepts non-Uint8Array typed arrays, and Memo.text no longer accepts a plain number[] (https://github.com/stellar/js-stellar-sdk/blob/main/see the next entry). The buffer dependency is gone (base32.js, which needed a Buffer global, is replaced by @exodus/bytes), and browsers/edge runtimes need no Buffer polyfill. Note that DecoratedSignature.signature and .hint did not become raw bytes despite the name the first shares with AuthEntrySignature.signature — they are xdr.Signature / xdr.SignatureHint wrappers, unwrapped with .toBytes() (see docs/migration/xdr-migration.md § 6).

• Memo.text no longer accepts a plain number[]. Pass new Uint8Array(arr) instead (#1457). Through 16.2.0 it took a string, a plain array, or a Buffer, and rejected a bare Uint8Array. A Uint8Array is now the canonical byte input, and a plain array is the only input lost. Memo.text([]) was a valid zero-byte memo and now throws. The error message is unchanged (https://github.com/stellar/js-stellar-sdk/blob/main/`Expects string or Uint8Array, max 28 bytes), so code that matches on it still works. See [docs/migration/uint8array-migration.md`](./docs/migration/uint8array-migration.md) § 3.

• The xdr namespace is rebuilt on @stellar/js-xdr v5, and every XDR value now has a different API (#1422). The wire format is unchanged: bytes and base64 written by older SDKs still decode, and vice versa. One caveat: v17 rejects malformed base64 outright, where v16's Buffer.from(str, "base64") silently dropped any character outside the alphabet (#1666). Any code that reads or builds xdr.* values must be updated. The main shifts:

  • Start here: docs/migration/xdr-migration.md covers every change below with before/after examples and a quick-reference table.
  • Unions are discriminated classes. .switch() becomes a .type string literal, arm getters like .contractData() become properties, and new xdr.LedgerEntryData(disc, val) becomes a factory call such as xdr.LedgerEntryData.contractData(val). The legacy new form throws a TypeError naming the factory method to call (#1658).
  • Enums are singletons, not factory calls: xdr.ContractDataDurability.persistent() becomes xdr.ContractDataDurability.persistent.
  • Primitives are plain JS values. Integers are number or bigint instead of class wrappers, anonymous opaque fields are Uint8Array, LargeInt subclasses are gone, and fields are readonly.
  • Named byte aliases (Hash, Signature, AssetCode4, PoolId, ContractId, …) are classes wrapping the bytes, not bare Uint8Array. They take raw bytes or a string on the way in and validate length at construction; read the bytes back with .toBytes(). The string form is hex, except for AssetCode4 / AssetCode12, which take the asset code as ASCII text and zero-pad it (new xdr.AssetCode4("USD")). This includes uint256, whose class is named Uint256Bytes because xdr.Uint256 is the bigint wrapper over Uint256Parts — it covers the ed25519 keys, salts, and nonces on PublicKey (and its alias AccountId), SignerKey, MuxedAccount, MuxedAccountMed25519, MuxedEd25519Account, TransactionV0, SignerKeyEd25519SignedPayload, ContractIdPreimageFromAddress, ClaimOfferAtomV0, and the Hello, DontHave, and StellarMessage overlay messages. A wrapper is not a Uint8Array: it has no .length, and Array.from() on one returns [], so compare two of them with .equals().
  • Absent optional fields decode to null instead of undefined, so === undefined checks silently stop matching. Prefer == null.
  • Acronyms in method names collapse to single-initial-cap form, with no back-compat aliases (e.g. validateXDR() is now validateXdr()). This reaches beyond the xdr namespace to the wrapper classes: Transaction.toXDR(), TransactionBuilder.fromXDR(), Operation.fromXDRObject(), Asset.toXDRObject(), contract.AssembledTransaction.toXDR() and others all gained the Xdr spelling.
  • Struct field names are unchanged, but a few type names moved: UInt128Parts / UInt256Parts are now Uint128Parts / Uint256Parts, ThresholdIndices is now ThresholdIndexes, and the typedef aliases Duration, TimePoint, SequenceNumber, ScVec, ScMap, LedgerEntryChanges, ContractCostParams, SorobanAuthorizationEntries, ScString, ScSymbol, String32, String64, and SponsorshipDescriptor are gone in favor of what they stood for.
  • New: toJson() / fromJson() for SEP-0051 JSON, toXdrObject() / fromXdrObject() on XDR values, and equals() for structural comparison. Failures throw xdr.XdrError, which is now exported.
  • Removed: Reader and Writer; the v4 runtime type constructors (Hyper, UnsignedHyper, Option, Opaque, VarOpaque, XDRArray, XDRString, Bool, SignedInt, UnsignedInt), plus top-level Hyper / UnsignedHyper / cereal; and xdr.scvSortedMap (use the top-level scvSortedMap).
  • ScInt and XdrLargeInt lost their .int property; read .value (a bigint) instead, and note valueOf() now returns a bigint.

• Rebuilding the XDR layer changed a few SDK-level behaviors that don't involve typing xdr. yourself. Most of these fail silently, so they won't surface as compile errors (#1422):

  • scValToNative returns a Uint8Array for an scvString whose contents aren't valid UTF-8. It previously always returned a string, substituting U+FFFD — its byte-returning branch was unreachable. Guards like typeof result === "string" and calls like result.startsWith(...) are now data-dependent. (scvSymbol follows the same rule, but the host restricts symbols to [_0-9A-Za-z], so a symbol that came off the network always decodes to a string.) The same applies to contract.Spec.scValToNative and contract.Spec.funcResToNative for Bytes / BytesN, which return Uint8Array; those are generically typed, so TypeScript won't flag it.
  • Operation.fromXdrObject decodes manageData's name, setOptions's homeDomain, and revokeSponsorship's data-entry name as UTF-8 rather than ASCII. Only bytes ≥ 0x80 decode differently, and stellar-core rejects those in all three fields, so no valid operation is affected — but snapshots taken over synthetic or forged XDR will change ([0xC3, 0xA9] now decodes to "é", was "C)"). See the migration guide for the round-trip details.

... (truncated)

Commits

• e07ded5 chore(release): prepare v17.1.0 (#1735)
• fc652a0 fix(bindings): use raw spec names as property keys in generated types (#1733)
• 0e83a37 chore(deps): bump the minor-and-patch group across 1 directory with 13 update...
• 9492b6a fix(horizon): complete HorizonApi.Predicate, document the SEP-0051 path (#1701)
• 33cd064 fix(toml): keep a malformed domain from redirecting the request (#1720)
• cb7d998 chore(deps): bump stellar/stellar-cli in the all-actions group (#1711)
• 32a314f update contributing policy for external contributors (#1728)
• f106d0e feat(base): read claimable balance IDs from transaction results (#1719)
• 9330f2b fix: guard the path variables in templated Horizon links (#1718)
• d79f361 fix: keep Horizon call builder ids in one URL path segment (#1702)
• Additional commits viewable in compare view

Install script changes

This version modifies prepare script that runs during installation. Review the package contents before updating.