Skip to content

Latest commit

 

History

History
1112 lines (791 loc) · 48.1 KB

CHANGELOG.md

File metadata and controls

1112 lines (791 loc) · 48.1 KB
Raw

Changelog

Unreleased

v8.2.1

Fix

  • Turn all XLM-like (i.e. casing agnostic) asset codes into the native asset with code XLM (#546).

v8.2.0

Add

  • Operation.setOptions now supports the new CAP-40 signed payload signer (ed25519SignedPayload) thanks to @orbitlens (#542).

v8.1.0

Add

  • TransactionBase.addDecoratedSignature is a clearer way to add signatures directly to a built transaction without fiddling with the underlying signatures array (#535).

  • Update the XDR definitions (and the way in which they're generated) to contain both the latest current XDR (which introduces CAP-42) and the "v-next" XDR (which contains XDR related to Soroban and should be considered unstable) (#537).

Fix

  • Correctly set minAccountSequence in TransactionBuilder for large values (#539, thank you @overcat!).

v8.0.1

Fix

  • Correctly predict claimable balance IDs with large sequence numbers (#530, thank you @overcat!).

v8.0.0

This is a promotion from the beta version without changes, now that the CAP-21 and CAP-40 implementations have made it into stellar/stellar-core#master.

v8.0.0-beta.0

This release adds support for Protocol 19, which includes CAP-21 (new transaction preconditions) and CAP-40 (signed payload signers).

This is considered a beta release until the XDR for the Stellar protocol stabilizes and is officially released.

Breaking

As of this release, the minimum supported version of NodeJS is 14.x.

  • Two XDR types have been renamed:
    • xdr.OperationId is now xdr.HashIdPreimage
    • xdr.OperationIdId is now xdr.HashIdPreimageOperationId

Add

  • Support for converting signed payloads (CAP-40) to and from their StrKey (P...) representation (#511):

    • Keypair.signPayloadDecorated(data)
    • StrKey.encodeSignedPayload(buf)
    • StrKey.decodeSignedPayload(str)
    • StrKey.isValidSignedPayload(str)

  • Support for creating transactions with the new preconditions (CAP-21) via TransactionBuilder (#513).

  • A way to convert between addresses (like G... and P..., i.e. the StrKey class) and their respective signer keys (i.e. xdr.SignerKeys), particularly for use in the new transaction preconditions (#520):

    • SignerKey.decodeAddress(address)
    • SignerKey.encodeSignerKey(address)
    • TransactionBuilder.setTimebounds(min, max)
    • TransactionBuilder.setLedgerbounds(min, max)
    • TransactionBuilder.setMinAccountSequence(seq)
    • TransactionBuilder.setMinAccountSequenceAge(age)
    • TransactionBuilder.setMinAccountSequenceLedgerGap(gap)
    • TransactionBuilder.setExtraSigners([signers])

Fix

  • Correct a TypeScript definition on the RevokeLiquidityPoolSponsorship operation (#522).

  • Resolves a bug that incorrectly sorted Assets with mixed-case asset codes (it preferred lowercase codes incorrectly) (#516).

  • Update developer dependencies:

v7.0.0

This release introduces unconditional support for muxed accounts (#485).

Breaking Changes

In v5.2.0, we introduced opt-in support for muxed accounts, where you would need to explicitly pass a true flag if you wanted to interpret muxed account objects as muxed addresses (in the form M..., see SEP-23). We stated that this would become the default in the future. That is now the case.

The following fields will now always support muxed properties:

  • FeeBumpTransaction.feeSource
  • Transaction.sourceAccount
  • Operation.sourceAccount
  • Payment.destination
  • PathPaymentStrictReceive.destination
  • PathPaymentStrictSend.destination
  • AccountMerge.destination
  • Clawback.from

The following functions had a withMuxing parameter removed:

  • Operation.fromXDRObject
  • Transaction.constructor
  • FeeBumpTransaction.constructor
  • TransactionBuilder.fromXDR
  • TransactionBuilder.buildFeeBumpTransaction

The following functions will no longer check the opts object for a withMuxing field:

  • TransactionBuilder.constructor
  • Operation.setSourceAccount

There are several other breaking changes:

  • TransactionBuilder.enableMuxedAccounts() is removed
  • decodeAddressToMuxedAccount() and encodeMuxedAccountToAddress() no longer accept a second boolean parameter
  • Account.createSubaccount() and MuxedAccount.createSubaccount() are removed (#487). You should prefer to create them manually:
  let mux1 = new MuxedAccount(someAccount, '1');

  // before:
  let mux2 = mux1.createSubaccount('2');

  // now:
  let mux2 = new MuxedAccount(mux1.baseAccount(), '2');
  • Introduced a new helper method to help convert from muxed account addresses to their underlying Stellar addresses (#485):
function extractBaseAddess(address: string): string;
  • The following muxed account validation functions are now available from Typescript (#483):
namespace StrKey {
  function encodeMed25519PublicKey(data: Buffer): string;
  function decodeMed25519PublicKey(data: string): Buffer;
  function isValidMed25519PublicKey(publicKey: string): boolean;
}

function decodeAddressToMuxedAccount(address: string, supportMuxing: boolean): xdr.MuxedAccount;
function encodeMuxedAccountToAddress(account: xdr.MuxedAccount, supportMuxing: boolean): string;
function encodeMuxedAccount(gAddress: string, id: string): xdr.MuxedAccount;
  • Added a helper function Transaction.getClaimableBalanceId(int) which lets you pre-determine the hex claimable balance ID of a createClaimableBalance operation prior to submission to the network (#482).

Fix

  • Add Buffer as a parameter type option for the Keypair constructor in Typescript (#484).

v6.0.6

Fix

  • Upgrades dependencies: path-parse (1.0.6 --> 1.0.7) and jszip (3.4.0 to 3.7.1) (#450, #458).

v6.0.5

This version bump fixes a security vulnerability in a developer dependency; please upgrade as soon as possible! You may be affected if you are working on this package in a developer capacity (i.e. you've cloned this repository) and have run yarn or yarn install any time on Oct 22nd, 2021.

Please refer to the security advisory for details.

Security Fix

  • Pin ua-parser-js to a known safe version (#477).

v6.0.4

Fix

  • Allow muxed accounts when decoding transactions via TransactionBuilder.fromXDR() (#470).

v6.0.3

Fix

  • When creating a Transaction, forward the optional withMuxing flag along to its operations so that their properties are also decoded with the appropriate muxing state (#469).

v6.0.2

Fix

  • Fix Typescript signatures for operations to universally allow setting the withMuxing flag (#466).

v6.0.1

Add

  • Introduced new CAP-38 operations LiquidityPoolDepositOp and LiquidityPoolWithdrawOp.
  • Introduced two new types of assets, LiquidityPoolId and LiquidityPoolAsset.

Update

  • The XDR definitions have been updated to support CAP-38.
  • Extended Operation class with the Operation.revokeLiquidityPoolSponsorship helper that allows revoking a liquidity pool sponsorship.
  • Asset types now include AssetType.liquidityPoolShares.
  • Operation.changeTrust and ChangeTrustOp can now use LiquidityPoolAsset in addition to Asset.
  • Operation.revokeTrustlineSponsorship can now use LiquidityPoolId in addition to Asset.

v5.3.2

Fix

  • Update various dependencies to secure versions. Most are developer dependencies which means no or minimal downstream effects (#446, #447, #392, #428); the only non-developer dependency upgrade is a patch version bump to lodash (#449).

v5.3.1

Fix

  • Creating operations with both muxed and unmuxed properties resulted in unintuitive XDR. Specifically, the unmuxed property would be transformed into the equivalent property with an ID of 0 (#441).

v5.3.0

Add

  • Opt-in support for muxed accounts. In addition to the support introduced in v5.2.0, this completes support for muxed accounts by enabling them for fee-bump transactions. Pass a muxed account address (in the M... form) as the first parameter (and explicitly opt-in to muxing by passing true as the last parameter) to TransactionBuilder.buildFeeBumpTransaction to make the feeSource a fully-muxed account instance (#434).

v5.2.1

Fix

  • Fix regression where raw public keys were sometimes being parsed incorrectly (#429).

v5.2.0

Add

  • Opt-in support for muxed accounts. This introduces M... addresses from SEP-23, which multiplex a Stellar G... address across IDs to eliminate the need for ad-hoc multiplexing via the Transaction.memo field (see the relevant SEP-29 and blog post on the topic). The following operations now support muxed accounts (#416):

    • Payment.destination
    • PathPaymentStrictReceive.destination
    • PathPaymentStrictSend.destination
    • Operation.sourceAccount
    • AccountMerge.destination
    • Transaction.sourceAccount

  • The above changeset also introduces a new high-level object, MuxedAccount (not to be confused with xdr.MuxedAccount, which is the underlying raw representation) to make working with muxed accounts easier. You can use it to easily create and manage muxed accounts and their underlying shared Account, passing them along to the supported operations and TransactionBuilder (#416):

  const PUBKEY = 'GA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJVSGZ';
  const ACC = new StellarBase.Account(PUBKEY, '1');

  const mux1 = new StellarBase.MuxedAccount(ACC, '1000');
  console.log(mux1.accountId(), mux1.id());
  // MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAAD5DTGC 1000

  const mux2 = ACC.createSubaccount('2000');
  console.log("Parent relationship preserved:", 
              mux2.baseAccount().accountId() === mux1.baseAccount().accountId());
  console.log(mux2.accountId(), mux2.id());
  // MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAAH2B4RU 2000

  mux1.setID('3000');
  console.log("Underlying account unchanged:", 
              ACC.accountId() === mux1.baseAccount().accountId());
  console.log(mux1.accountId(), mux1.id());
  // MA7QYNF7SOWQ3GLR2BGMZEHXAVIRZA4KVWLTJJFC7MGXUA74P7UJUAAAAAAAAAALXC5LE 3000

Update

  • Modernize the minimum-supported browser versions for the library (#419).

Fix

  • Update Typescript test for SetOptions to use authorization flags (e.g. AuthRequiredFlag) correctly (#418).

v5.1.0

Update

  • The Typescript definitions have been updated to support CAP-35 (#407).

v5.0.0

Add

  • Introduced new CAP-35 operations, ClawbackOp, ClawbackClaimableBalanceOp, and SetTrustLineFlagsOp (#397).

Update

  • Add an additional parameter check to claimClaimableBalance to fail faster (#390).

  • The XDR definitions have been updated to support CAP-35 (#394).

Breaking

  • AllowTrustOpAsset has been renamed to AssetCode (#394)

Deprecated

  • AllowTrustOp is now a deprecated operation.

v4.0.3

Update

  • Update TS definitions for XDRs (#381)
  • Fix typing for ManageData.value (#379)

v4.0.2

Update

  • Fix deployment script.

v4.0.1

Update

  • Update createAccount operation to accept 0 as the starting balance (#375).

v4.0.0

Add

  • Add the Claimant class which helps the creation of claimable balances. (#367). The default behavior of this class it to create claimants with an unconditional predicate if none is passed:
const claimant = new StellarBase.Claimant(
  'GCEZWKCA5VLDNRLN3RPRJMRZOX3Z6G5CHCGSNFHEYVXM3XOJMDS674JZ'
);

However, you can use any of the following helpers to create a predicate:

StellarBase.Claimant.predicateUnconditional();
StellarBase.Claimant.predicateAnd(left, right);
StellarBase.Claimant.predicateOr(left, right);
StellarBase.Claimant.predicateNot(predicate);
StellarBase.Claimant.predicateBeforeAbsoluteTime(unixEpoch);
StellarBase.Claimant.predicateBeforeRelativeTime(seconds);

And then pass the predicate in the constructor:

const left = StellarBase.Claimant.predicateBeforeRelativeTime('800');
const right = StellarBase.Claimant.predicateBeforeRelativeTime(
  '1200'
);
const predicate = StellarBase.Claimant.predicateOr(left, right);
const claimant = new StellarBase.Claimant(
  'GCEZWKCA5VLDNRLN3RPRJMRZOX3Z6G5CHCGSNFHEYVXM3XOJMDS674JZ',
  predicate
);
  • Add Operation.createClaimableBalance (#368) Extend the operation class with a new helper to create claimable balance operations.
const asset = new Asset(
  'USD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
const amount = '100.0000000';
const claimants = [
  new Claimant(
    'GCEZWKCA5VLDNRLN3RPRJMRZOX3Z6G5CHCGSNFHEYVXM3XOJMDS674JZ',
     Claimant.predicateBeforeAbsoluteTime("4102444800000")
  )
];

const op = Operation.createClaimableBalance({
  asset,
  amount,
  claimants
});
  • Add Operation.claimClaimableBalance (#368) Extend the operation class with a new helper to create claim claimable balance operations. It receives the balanceId as exposed by Horizon in the /claimable_balances end-point.
const op = Operation.createClaimableBalance({
  balanceId: '00000000da0d57da7d4850e7fc10d2a9d0ebc731f7afb40574c03395b17d49149b91f5be',
});
  • Add support for Sponsored Reserves (CAP33)(#369)

Extend the operation class with helpers that allow sponsoring reserves and also revoke sponsorships.

To start sponsoring reserves for an account use:

  • Operation.beginSponsoringFutureReserves
  • Operation.endSponsoringFutureReserves

To revoke a sponsorship after it has been created use any of the following helpers:

  • Operation.revokeAccountSponsorship
  • Operation.revokeTrustlineSponsorship
  • Operation.revokeOfferSponsorship
  • Operation.revokeDataSponsorship
  • Operation.revokeClaimableBalanceSponsorship
  • Operation.revokeSignerSponsorship

The following example contains a transaction which sponsors operations for an account and then revoke some sponsorships.

const transaction = new StellarSdk.TransactionBuilder(account, {
  fee: "100",
  networkPassphrase: StellarSdk.Networks.TESTNET
})
  .addOperation(
    StellarSdk.Operation.beginSponsoringFutureReserves({
      sponsoredId: account.accountId(),
      source: masterKey.publicKey()
    })
  )
  .addOperation(
    StellarSdk.Operation.accountMerge({ destination: destKey.publicKey() }),
  ).addOperation(
    StellarSdk.Operation.createClaimableBalance({
      amount: "10",
      asset: StellarSdk.Asset.native(),
      claimants: [
        new StellarSdk.Claimant(account.accountId())
      ]
    }),
  ).addOperation(
    StellarSdk.Operation.claimClaimableBalance({
      balanceId: "00000000da0d57da7d4850e7fc10d2a9d0ebc731f7afb40574c03395b17d49149b91f5be",
    }),
  ).addOperation(
    StellarSdk.Operation.endSponsoringFutureReserves({
    })
  ).addOperation(
    StellarSdk.Operation.revokeAccountSponsorship({
      account: account.accountId(),
    })
  ).addOperation(
      StellarSdk.Operation.revokeTrustlineSponsorship({
        account: account.accountId(),
        asset: usd,
      })
  ).addOperation(
    StellarSdk.Operation.revokeOfferSponsorship({
      seller: account.accountId(),
      offerId: '12345'
    })
  ).addOperation(
    StellarSdk.Operation.revokeDataSponsorship({
      account: account.accountId(),
      name: 'foo'
    })
  ).addOperation(
    StellarSdk.Operation.revokeClaimableBalanceSponsorship({
      balanceId: "00000000da0d57da7d4850e7fc10d2a9d0ebc731f7afb40574c03395b17d49149b91f5be",
    })
  ).addOperation(
    StellarSdk.Operation.revokeSignerSponsorship({
      account: account.accountId(),
      signer: {
        ed25519PublicKey: sourceKey.publicKey()
      }
    })
  ).addOperation(
    StellarSdk.Operation.revokeSignerSponsorship({
      account: account.accountId(),
      signer: {
        sha256Hash: "da0d57da7d4850e7fc10d2a9d0ebc731f7afb40574c03395b17d49149b91f5be"
      }
    })
  ).addOperation(
    StellarSdk.Operation.revokeSignerSponsorship({
      account: account.accountId(),
      signer: {
        preAuthTx: "da0d57da7d4850e7fc10d2a9d0ebc731f7afb40574c03395b17d49149b91f5be"
      }
    })
  ).build();

Breaking

  • The XDR generated in this code includes breaking changes on the internal XDR library since a bug was fixed which was causing incorrect code to be generated (see stellar/xdrgen#52).

The following functions were renamed:

  • xdr.OperationBody.setOption() -> xdr.OperationBody.setOptions()
  • xdr.OperationBody.manageDatum() -> xdr.OperationBody.manageData()
  • xdr.OperationType.setOption() -> xdr.OperationType.setOptions()
  • xdr.OperationType.manageDatum() -> xdr.OperationType.manageData()

The following enum values were rename in OperationType:

  • setOption -> setOptions
  • manageDatum -> manageData

v3.0.4

Update

  • Generate V1 transactions by default and allow V0 transactions to be fee bumped (#355).

v3.0.3

Remove

  • Rollback support for SEP23 (Muxed Account StrKey) (#349).

v3.0.2

Fix

  • Extend files in npm package to include XDR type definitions (#345).

v3.0.1

Add

  • Add TypeScript definitions for auto-generated XDR code (#342).

v3.0.0

This version brings protocol 13 support with backwards compatibility support for protocol 12.

Add

  • Add TransactionBuilder.buildFeeBumpTransaction which makes it easy to create FeeBumpTransaction (#321).
  • Adds a feature flag which allow consumers of this library to create V1 (protocol 13) transactions using the TransactionBuilder (#321).
  • Add support for CAP0027: First-class multiplexed accounts (#325).
  • Add Keypair.xdrMuxedAccount which creates a new xdr.MuxedAccount(#325).
  • Add FeeBumpTransaction which makes it easy to work with fee bump transactions (#328).
  • Add TransactionBuilder.fromXDR which receives an xdr envelope and return a Transaction or FeeBumpTransaction (#328).

Update

  • Update XDR definitions with protocol 13 (#317).

  • Extend Transaction to work with TransactionV1Envelope and TransactionV0Envelope (#317).

  • Add backward compatibility support for CAP0018 (#317). CAP0018 provides issuers with a new level of authorization between unauthorized and fully authorized, called "authorized to maintain liabilities". The changes in this release allow you to use the new authorization level and provides backward compatible support for Protocol 12.

    Before Protocol 13, the argument authorize in the AllowTrust operation was of type boolean where true was authorize and false deauthorize. Starting in Protocol 13, this value is now a number where 0 is deauthorize, 1 is authorize, and 2 is authorize to maintain liabilities.

    The syntax for authorizing a trustline is still the same, but the authorize parameter is now a number.

    Operation.allowTrust({
  trustor: trustor.publicKey(),
  assetCode: "COP",
  authorize: 1
});

    You can use still use a boolean; however, we recommend you update your code to pass a number instead. Finally, using the value 2 for authorize to maintain liabilities will only be valid if Stellar Core is running on Protocol 13; otherwise, you'll get an error.

  • Update operations builder to support multiplexed accounts (#337).

Breaking changes

  • Transaction.toEnvelope() returns a protocol 13 xdr.TransactionEnvelope which is an xdr.Union (#317). If you have code that looks like this - transaction.toEnvelope().tx - you have two options:

    • You can grab the value wrapped by the union, calling value() like transaction.toEnvelope().value().tx.
    • You can check which is the discriminant by using switch() and then call v0(), v1(), or feeBump().

  • The return value from Transaction.fee changed from number to string. This brings support for Int64 values (#321).

  • The const BASE_FEE changed from number to string (#321).

  • The option fee passed to new TransactionBuilder({fee: ..}) changed from number to string (#321).

  • The following fields, which were previously an xdr.AccountID are now a xdr.MuxedAccount (#325):

    • PaymentOp.destination
    • PathPaymentStrictReceiveOp.destination
    • PathPaymentStrictSendOp.destination
    • Operation.sourceAccount
    • Operation.destination (for ACCOUNT_MERGE)
    • Transaction.sourceAccount
    • FeeBumpTransaction.feeSource

    You can get the string representation by calling StrKey.encodeMuxedAccount which will return a G.. or M.. account.

  • Remove the following deprecated functions (#331):

    • Operation.manageOffer
    • Operation.createPassiveOffer
    • Operation.pathPayment
    • Keypair.fromBase58Seed

  • Remove the Network class (#331).

  • Remove vendor/base58.js (#331).

v3.0.0-alpha.1

Update

  • Update operations builder to support multiplexed accounts (#337).

    This allows you to specify an M account as the destination or source:

    var destination = 'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6';
var amount = '1000.0000000';
var asset = new StellarBase.Asset(
  'USDUSD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
var source =
  'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6';
StellarBase.Operation.payment({
  destination,
  asset,
  amount,
  source
});

    To use multiplexed accounts you need an instance of Stellar running on Protocol 13 or higher

v3.0.0-alpha.0

This version brings protocol 13 support with backwards compatibility support for protocol 12.

Add

  • Add TransactionBuilder.buildFeeBumpTransaction which makes it easy to create FeeBumpTransaction (#321).
  • Adds a feature flag which allow consumers of this library to create V1 (protocol 13) transactions using the TransactionBuilder (#321).
  • Add support for CAP0027: First-class multiplexed accounts (#325).
  • Add Keypair.xdrMuxedAccount which creates a new xdr.MuxedAccount(#325).
  • Add FeeBumpTransaction which makes it easy to work with fee bump transactions (#328).
  • Add TransactionBuilder.fromXDR which receives an xdr envelope and return a Transaction or FeeBumpTransaction (#328).

Update

  • Update XDR definitions with protocol 13 (#317).
  • Extend Transaction to work with TransactionV1Envelope and TransactionV0Envelope (#317).
  • Add backward compatibility support for CAP0018 (#317).

Breaking changes

  • Transaction.toEnvelope() returns a protocol 13 xdr.TransactionEnvelope which is an xdr.Union (#317). If you have code that looks like this transaction.toEnvelope().tx you have two options:

    • You can grab the value wrapped by the union, calling value() like transaction.toEnvelope().value().tx.
    • You can check which is the discriminant by using switch() and then call v0(), v1(), or feeBump().

  • The return value from Transaction.fee changed from number to string. This brings support for Int64 values (#321).

  • The const BASE_FEE changed from number to string (#321).

  • The option fee passed to new TransactionBuilder({fee: ..}) changed from number to string (#321).

  • The following fields, which were previously an xdr.AccountID are now a xdr.MuxedAccount (#325):

    • PaymentOp.destination
    • PathPaymentStrictReceiveOp.destination
    • PathPaymentStrictSendOp.destination
    • Operation.sourceAccount
    • Operation.destination (for ACCOUNT_MERGE)
    • Transaction.sourceAccount
    • FeeBumpTransaction.feeSource

    You can get the string representation by calling StrKey.encodeMuxedAccount which will return a G.. or M.. account.

  • Remove the following deprecated functions (#331):

    • Operation.manageOffer
    • Operation.createPassiveOffer
    • Operation.pathPayment
    • Keypair.fromBase58Seed

  • Remove the Network class (#331).

  • Remove vendor/base58.js (#331).

v2.1.9

Fix

  • Update dependencies which depend on minimist. (#332)

v2.1.8

Fix

  • Fix setTimeout(0) and partially defined timebounds (#315).

v2.1.7

Fix

  • Fix TypeScript options for ManageData operation to allow setting value to null (#310)
  • Fix crash on partially defined time bounds (#303)

v2.1.6

Fix

  • Fix npm deployment.

v2.1.5

Add

  • Add toXDR type to Transaction class (#296)

Fix

  • Fix doc link (#298)

Remove

  • Remove node engine restriction (#294)

Update

  • Update creating an account example (#299)
  • Use console.trace to get line num in Networks.use (#300)

v2.1.4

Update

  • Regenerate the XDR definitions to include MetaV2 (#288)

v2.1.3

Update 📣

  • Throw errors when obviously invalid network passphrases are used in new Transaction(). (284)

v2.1.2

Update 📣

  • Update documentation for Operation to show pathPaymentStrictSend and pathPaymentStrictReceive. (279)

v2.1.1

Update 📣

  • Update asset.toString() to return canonical representation for asset. (277).

    Calling asset.toString() will return native for XLM or AssetCode:AssetIssuer for issued assets. See this PR for more information.

v2.1.0

This release adds support for stellar-core protocol 12 release and CAP 24 ("Make PathPayment Symmetrical").

Add ➕

  • Operation.pathPaymentStrictSend: Sends a path payments, debiting from the source account exactly a specified amount of one asset, crediting at least a given amount of another asset. (#274).

    The following operation will debit exactly 10 USD from the source account, crediting at least 9.2 EUR in the destination account 💸:

    var sendAsset = new StellarBase.Asset(
  'USD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
var sendAmount = '10';
var destination =
  'GCEZWKCA5VLDNRLN3RPRJMRZOX3Z6G5CHCGSNFHEYVXM3XOJMDS674JZ';
var destAsset = new StellarBase.Asset(
  'USD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
var destMin = '9.2';
var path = [
  new StellarBase.Asset(
    'USD',
    'GBBM6BKZPEHWYO3E3YKREDPQXMS4VK35YLNU7NFBRI26RAN7GI5POFBB'
  ),
  new StellarBase.Asset(
    'EUR',
    'GDTNXRLOJD2YEBPKK7KCMR7J33AAG5VZXHAJTHIG736D6LVEFLLLKPDL'
  )
];
let op = StellarBase.Operation.pathPaymentStrictSend({
  sendAsset,
  sendAmount,
  destination,
  destAsset,
  destMin,
  path
});

  • Operation.pathPaymentStrictReceive: This behaves the same as the former pathPayments operation. (#274).

    The following operation will debit maximum 10 USD from the source account, crediting exactly 9.2 EUR in the destination account 💸:

    var sendAsset = new StellarBase.Asset(
  'USD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
var sendMax = '10';
var destination =
  'GCEZWKCA5VLDNRLN3RPRJMRZOX3Z6G5CHCGSNFHEYVXM3XOJMDS674JZ';
var destAsset = new StellarBase.Asset(
  'USD',
  'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7'
);
var destAmount = '9.2';
var path = [
  new StellarBase.Asset(
    'USD',
    'GBBM6BKZPEHWYO3E3YKREDPQXMS4VK35YLNU7NFBRI26RAN7GI5POFBB'
  ),
  new StellarBase.Asset(
    'EUR',
    'GDTNXRLOJD2YEBPKK7KCMR7J33AAG5VZXHAJTHIG736D6LVEFLLLKPDL'
  )
];
let op = StellarBase.Operation.pathPaymentStrictReceive({
  sendAsset,
  sendMax,
  destination,
  destAsset,
  destAmount,
  path
});

Deprecated ❗️

  • Operation.pathPayment is being deprecated in favor of Operation.pathPaymentStrictReceive. Both functions take the same arguments and behave the same. (#274).

v2.0.2

Fix

  • Fix issue #269. ManageBuyOffer should extend BaseOptions and inherited property "source". (#270).

v2.0.1

No changes. Fixes deploy script and includes changes from v2.0.0.

v2.0.0

BREAKING CHANGES

  • Drop Support for Node 6 since it has been end-of-lifed and no longer in LTS. We now require Node 10 which is the current LTS until April 1st, 2021. (#255)

v1.1.2

Fix

  • Fix no-network warnings (#248)

v1.1.1

Fix

  • Add types for new networkPassphrase argument. Fix #237. (#238)

v1.1.0

Deprecated

Deprecate global singleton for Network. The following classes and methods take an optional network passphrase, and issue a warning if it is not passed:

Keypair.master

Keypair.master(Networks.TESTNET)

constructor for Transaction

const xenv = new xdr.TransactionEnvelope({ tx: xtx });
new Transaction(xenv, Networks.TESTNET);

constructor for TransactionBuilder and method TransactionBuilder.setNetworkPassphrase

const transaction = new StellarSdk.TransactionBuilder(account, {
  fee: StellarSdk.BASE_FEE,
  networkPassphrase: Networks.TESTNET
})

See #207 and #112 for more information.

The Network class will be removed on the 2.0 release.

Add

  • Add docs for BASE_FEE const. (#211)

Fix

v1.0.3

Add

  • Add toString() to Asset (#172)
  • Add types for missing Network functions (#208)
  • Add BASE_FEE to TS types (#209)

Fix

  • Fix typo in types (#194)
  • Fix types: Fee is no longer optional (#195)
  • Fix typings for Account Sequence Number (#203)
  • Fix typings for Transaction Sequence Number (#205)

v1.0.2

  • Fix a bug where sodium-native was making it into the browser bundle, which is supposed to use tweetnacl.

v1.0.1

  • Restore Operation.manageOffer and Operation.createPassiveOffer, and issue a warning if they're called.
  • Add type definitions for the timeBounds property of transactions.

v1.0.0

  • Breaking change Stellar Protocol 11 compatibility
    • Rename Operation.manageOffer to Operation.manageSellOffer.
    • Rename Operation.createPassiveOffer to Operation.createPassiveSellOffer.
    • Add Operation.manageBuyOffer.
  • Breaking change The fee parameter to TransactionBuilder is now required. Failing to provide a fee will throw an error.

v0.13.2

  • Bring DefinitelyTyped definitions into the repo for faster updating.
  • Add missing Typescript type definitions.
  • Add code to verify signatures when added to transactions.
  • Replace ed25519 with sodium-native.
  • Fix the xdr for SCP_MESSAGE.
  • Update the README for the latest info.

v0.13.1

  • Travis: Deploy NPM with an environment variable instead of an encrypted API key.
  • Instruct Travis to cache node_modules

v0.13.0

  • Remove the crypto library. This reduces the number of Node built-ins we have to shim into the production bundle, and incidentally fixes a bug with Angular 6.

v0.12.0

  • Warning Calling TransactionBuilder without a fee param is now deprecated and will issue a warning. In a later release, it will throw an error. Please update your transaction builders as soon as you can!
  • Add a toXDR function for transactions that lets you get the transaction as a base64-encoded string (so you may enter it into the Stellar Laboratory XDR viewer, for one)
  • Fix TransactionBuilder example syntax errors
  • Use more thorough "create account" documentation
  • Add Date support for TransactionBuilder timebounds
  • Add two functions to Transaction that support pre-generated transactions:
    • getKeypairSignature helps users sign pre-generated transaction XDRs
    • addSignature lets you add pre-generated signatures to a built transaction

0.11.0

  • Added ESLint and Prettier to enforce code style
  • Upgraded dependencies, including Babel to 6
  • Bump local node version to 6.14.0
  • Change Operations._fromXDRAmount to not use scientific notation (1e-7) for small amounts like 0.0000001.

0.10.0

  • Breaking change Added TransactionBuilder.setTimeout method that sets timebounds.max_time on a transaction. Because of the distributed nature of the Stellar network it is possible that the status of your transaction will be determined after a long time if the network is highly congested. If you want to be sure to receive the status of the transaction within a given period you should set the TimeBounds with maxTime on the transaction (this is what setTimeout does internally; if there's minTime set but no maxTime it will be added). Call to TransactionBuilder.setTimeout is required if Transaction does not have max_time set. If you don't want to set timeout, use TimeoutInfinite. In general you should set TimeoutInfinite only in smart contracts. Please check TransactionBuilder.setTimeout docs for more information.
  • Fixed decoding empty homeDomain.

0.9.0

  • Update js-xdr to support unmarshaling non-utf8 strings.
  • String fields returned by Operation.fromXDRObject() are of type Buffer now (except SetOptions.home_domain and ManageData.name - both required to be ASCII by stellar-core).

0.8.3

  • Update xdr files to V10.

0.8.2

  • Upgrade js-xdr.

0.8.1

  • Removed src from .npmignore.

0.8.0

  • Added support for bump_sequence operation.
  • Fixed many code style issues.
  • Updated docs.

0.7.8

  • Updated dependencies.

0.7.7

  • Updated docs.

0.7.6

  • Updated docs.

0.7.5

  • Keypair.constructor now requires type field to define public-key signature system used in this instance (so Keypair can support other systems in a future). It also checks if public key and secret key match if both are passed (to prevent nasty bugs).
  • Keypair.fromRawSeed has been renamed to Keypair.fromRawEd25519Seed to make it clear that the seed must be Ed25519 seed.
  • It's now possible to instantiate Memo class so it's easier to check it's type and value (without dealing with low level xdr.Memo objects).
  • Changed Asset.toXdrObject to Asset.toXDRObject and Operation.operationToObject to Operation.toXDRObject for consistency.
  • Time bounds support for numeric input values.
  • Added browser prop to package.json.

0.7.4

  • Update dependencies.
  • Remove unused methods.

0.7.3

  • Allow hex string in setOptions signers

0.7.2

  • Updated XDR files

0.7.1

  • Checking hash preimage length

0.7.0

  • Support for new signer types: sha256Hash, preAuthTx.
  • StrKey helper class with strkey encoding related methods.
  • Removed deprecated methods: Keypair.isValidPublicKey (use StrKey), Keypair.isValidSecretKey (use StrKey), Keypair.fromSeed, Keypair.seed, Keypair.rawSeed.
  • Breaking changes:
    • Network must be explicitly selected. Previously testnet was a default network.
    • Operation.setOptions() method signer param changed.
    • Keypair.fromAccountId() renamed to Keypair.fromPublicKey().
    • Keypair.accountId() renamed to Keypair.publicKey().
    • Dropping support for End-of-Life node versions.

0.6.0

  • Breaking change ed25519 package is now optional dependency.
  • Export account flags constants.

0.5.7

  • Fixes XDR decoding issue when using firefox

0.5.6

  • UTF-8 support in Memo.text().

0.5.5

  • Make 0 a valid number for transaction fee,
  • Fix signer in Operation.operationToObject() - close #82

0.5.4

  • Fixed Lodash registering itself to global scope.

0.5.3

  • Add support for ManageData operation.

0.5.2

  • Moved Account.isValidAccountId to Keypair.isValidPublicKey. It's still possible to use Account.isValidAccountId but it will be removed in the next minor release (breaking change). (af10f2a)
  • signer.address option in Operation.setOptions was changed to signer.pubKey. It's still possible to use signer.address but it will be removed in the next minor release (breaking change). (07f43fb)
  • Operation.setOptions now accepts strings for clearFlags, setFlags, masterWeight, lowThreshold, medThreshold, highThreshold, signer.weight options. (665e018)
  • Fixed TransactionBuilder timebounds option. (854f275)
  • Added CHANGELOG.md file.

0.5.1

  • Now it's possible to pass price params as {n: numerator, d: denominator} object. Thanks @FredericHeem. (#73)

0.5.0

  • Breaking change sequence in Account constructor must be a string. (4da5dfc)
  • Breaking change Removed deprecated methods (180a5b8):
    • Account.isValidAddress (replaced by Account.isValidAccountId)
    • Account.getSequenceNumber (replaced by Account.sequenceNumber)
    • Keypair.address (replaced by Keypair.accountId)
    • Network.usePublicNet (replaced by Network.usePublicNetwork)
    • Network.useTestNet (replaced by Network.useTestNetwork)
    • TransactionBuilder.addSigner (call Transaction.sign on build Transaction object)