All notable changes to this project will be documented in this file. The format is based on Keep a Changelog and this project adheres to Semantic Versioning.
As this project is pre 1.0, breaking changes may happen for minor version bumps. A breaking change will get clearly notified in this log.
0.32.0 (2022-05-17)
0.31.0 (2022-02-20)
- unconditionally use muxed accounts in tx builder (#250)
0.30.0 (2021-10-14)
Stellar::Amount
class moved tostellar-base
gem fromstellar-sdk
Stellar::Horizon::Problem
class moved tostellar-horizon
gemtoml-rb
gem is replaced withtomlrb
gem to work around segfaults in Ruby 3.0
0.29.0 (2021-09-07)
- No changes
0.28.0 (2021-07-17)
0.27.0 (2021-05-08)
0.26.0 - 2021-02-05
- No changes
0.25.0 - 2020-10-30
MuxedAccount
implements#to_keypair
conversion protocolMuxedAccount
correctly responds to#address
with strkey encoded public key
Transaction::V0#source_account
now properly returnsMuxedAccount
instead of raw bytes
0.24.0 - 2020-10-20
- Add conversion methods for KeyPair and Asset
- Stellar Protocol 14 support
- Regenerate XDR wrappers from definitions in stellar-core 14.1.1
- Add CAP-23 Two-Part Payments support
- Add ClaimPredicate DSL methods which help with creation of claim predicates.
# use class-level helpers to create simple predicates unconditional = Stellar::ClaimPredicate.unconditional before_rel_time = Stellar::ClaimPredicate.before_relative_time(1.hour) before_abs_time = Stellar::ClaimPredicate.before_absolute_time(Date.tomorrow.beginning_of_day) # negate predicates using `~` unary operator ~predicate # same as predicate.not # build complex predicates using `&` and `|` infix operators predicate & other_predicate # same as `predicate.and(other_predicate)` predicate | other_predicate # same as `predicate.or(other_predicate)` # quickly define complex predicates using `.compose` class method with the block unconditional = Stellar::ClaimPredicate.compose { } complex = Stellar::ClaimPredicate.compose do before_relative_time(1.week) & ~before_relative_time(10.seconds) | end # here's what building this predicate would look like without DSL complex = Stellar::ClaimPredicate.new( Stellar::ClaimPredicateType::AND, Stellar::ClaimPredicate.new( Stellar::ClaimPredicateType::BEFORE_RELATIVE_TIME, 7 * 24 * 60 * 60 ), Stellar::ClaimPredicate.new( Stellar::ClaimPredicateType::NOT, Stellar::ClaimPredicate.new( Stellar::ClaimPredicateType::BEFORE_RELATIVE_TIME, 10 ) ) )
- Extend Operation with
create_claimable_balance
andclaim_claimable_balance
helpers - Add Claimant and ClaimPredicate DSL methods to reduce the noise.
include Stellar::DSL sender = KeyPair('S....') recipient = 'G....' op = Operation.create_claimable_balance( asset: Stellar::Asset.native, amount: 100, claimants: [ Claimant(recipient) { after(10.seconds) & before(1.week) }, Claimant(sender), # allow unconditional claim-back ] ) ])
- Add simple predicate evaluation feature so that developers can sanity-check their predicates
include Stellar::DSL predicate = ClaimPredicate { before_relative_time(1.week) & ~before_relative_time(10.seconds) } # predicate.evaluate(balance_creation_time, claim_evaluation_time) predicate.evaluate("2020-10-20 09:00:00", "2020-10-20 09:00:05") # => false predicate.evaluate("2020-10-20 09:00:00", "2020-10-20 09:01:00") # => true predicate.evaluate("2020-10-20 09:00:00", "2020-10-27 08:50:00") # => true # you can also pass an instance of ActiveSupport::Duration as a second parameter, in this case # it works as a relative offset from `balance_creation_time` predicate.evaluate("2020-10-20 09:00:00", 1.week + 1.second) # => false # it is effectively the same as predicate.evaluate("2020-10-20 09:00:00", "2020-10-27 09:00:01") # => false
- Add ClaimPredicate DSL methods which help with creation of claim predicates.
- Add CAP-33 Sponsored Reserves support
- Extend the operation class with helpers that allow sponsoring reserves and also revoke sponsorships.
Operation.begin_sponsoring_future_reserves
Operation.end_sponsoring_future_reserves
Operation.revoke_sponsorship(account_id:)
Operation.revoke_sponsorship(account_id:, asset:)
Operation.revoke_sponsorship(account_id:, offer_id:)
Operation.revoke_sponsorship(account_id:, data_name:)
Operation.revoke_sponsorship(account_id:, balance_id:)
Operation.revoke_sponsorship(account_id:, signer:)
- Extend the operation class with helpers that allow sponsoring reserves and also revoke sponsorships.
0.23.1 - 2020-06-18
- Transaction builder now builds V1 transactions
- FeeBumpTransaction can wrap V0 transaction
0.23.0 - 2020-06-11
- Stellar Protocol 13 support
0.22.0 - 2020-03-26
- Add TransactionBuilder (#54)
0.21.0 - 2019-10-04
- Stellar Protocol 12 compatibility.
- XDR changes for path payment
- constant renames, which may cause breaking changes if referred to directly
0.20.0 - 2019-05-22
- Stellar Protocol 11 compatibility (#48)
- XDR changes for CAP-0006 Buy Offers
- XDR changes for CAP-0020 Bucket Initial Entries
- Add
manage_buy_offer
,manage_sell_offer
andcreate_passive_sell_offer
factory methods toStellar::Transaction
andStellar::Operation
- Deprecate
manage_offer
andcreate_passive_offer
factory methods inStellar::Transaction
andStellar::Operation
- Add an option to pass the exact stellar-core revision into
xdr:update
Rake task
- Loosen ActiveSupport to >= 5.0.0
- Update XDR definitions for stellar-core v10.0.0 (introduces Liabilities and other changes to support asset-backed offers as per CAP-0003 Specification)
- Add factories for ledger, transaction, operation.
- Use rbnacl instead of rbnacl-libsodium (the latter has been deprecated)
- Rename
Stellar::SignerKey#onetime_signer
helper toStellar::SignerKey#hash_x
, add preimage validations
- Create co-signers conveniently using helpers
ed25519(keypair)
,preauthorized_transaction(tx)
andonetime_signer(preimage)
fromStellar::SignerKey
module - Merge two transactions with
Stellar::TransactionEnvelope#merge
- Source account overriding in Stellar::Transaction#to_operations
Stellar::Operation.change_trust
can acceptStellar::Asset
instance forline
- Protect
Stellar::Operation.change_trust
against malicious arguments, in the event that developers pass this argument directly from user input
- We now support the bump sequence operation with
Operation.bump_sequence
.
- Update XDR definitions for stellar-core 0.10.0 support
Operation.change_trust
learned how to use a default for the:limit
parameterStrKey
learned about new version bytespre_auth_tx
andhash_x
- Update XDR definitions for stellar-core 0.9.1 support
- Added
#signer_key
helper toKeyPair
- Avoid modifying $LOAD_PATH to fix load order issues
- Update XDR definitions for stellar-core 0.6 support
- BREAKING CHANGE: Removed support for JRuby.
- Added support for
manage_data
operations
Stellar::Transaction#to_envelope
can now be used without arguments, returning aStellar::TransactionEnvelope
with zero signatures.
- Added memo helpers to
Stellar::Transaction.for_account
, allowing any operation builder (such asStellar::Transaction.payment) to provide a custom memo using the
:memo` attribute.
- XDR Definitions have been updated to stellar-core commit eed89649c2060b8e9dacffe2cec4e8b258b32416
- BREAKING CHANGE: The default network for this library is now the stellar test network.
To enable this library for the production network use
Stellar.default_network = Stellar::Networks::PUBLIC
at the head of your script or in your configuration function.
- Bump xdr dependency to 1.0.0
- Update default fee for transactions to new minimum of 100 stroops
- Update to latest xdr (stellar-core commit ad22bccafbbc14a358f05a989f7b95714dc9d4c6)
- Update to latest xdr
- BREAKING CHANGE: "Amounts", that is, input parameters that represent a
certain amount of a given asset, such as the
:starting_balance
option forOperation.create_account
are now interpreted using the convention of 7 fixed-decimal places. For example, specifying a payment where the amount is50
will result in a transaction with an amount set to500000000
.