mirror of
https://github.com/aljazceru/breez-sdk-liquid.git
synced 2026-01-27 18:04:28 +01:00
e8cd66f81f
* prepare-pay-onchain: add option for drain in req * Fix clippy * ChainSwapStateHandler: gracefully handle building both drain and non-drain lockups * Send Chain swap: use standard feerate when estimating lockup tx fee * UDL: move new drain field above the last PreparePayOnchainRequest optional field * UDL: move new drain field optional * prepare-pay-onchain: treat normal payment as drain if receiver amount is high enough If the receiver amount is as high as it would be in case of drain, treat the current prepare-pay-onchain as drain, even if the drain flag is not set. * build_drain_tx: add optional amount validation * Add PayOnchainAmount enum to cover amount types (drain, receiver) * Add ability to find max_receiver_amount_sat for non-drain sends * Revert "Add ability to find max_receiver_amount_sat for non-drain sends" This reverts commit 60ee1c768021810f72bc64a8ada69d35b638185e. * prepare_pay_onchain: treat drain and non-drain cases separately If the non-drain case is chosen with a receiver_amount equivalent to what drain would have calculated, it results in an error. For drain, the caller has to explicitly choose PayOnchainAmount::Drain. * CLI: send-onchain-payment accepts optional amount * CLI: add docs for send-onchain-payment drain arg * SDK: expand docs for prepare_pay_onchain * Re-generate RN bindings * Re-generate flutter bindings
Breez Liquid SDK
To get started with the Breez Liquid SDK, follow these examples.
Getting Started
let mnemonic = Mnemonic::generate_in(Language::English, 12)?;
// Create the default config
let mut config = LiquidSdk::default_config(LiquidNetwork::Mainnet);
// Customize the config object according to your needs
config.working_dir = "path to an existing directory".into();
let connect_request = ConnectRequest {
mnemonic: mnemonic.to_string(),
config,
};
let sdk = LiquidSdk::connect(connect_request).await?;
Tests
In order to run tests, you can execute cargo test -- --nocapture --test-threads 1. This is due to the fact that currently tests require some degree of interaction (e.g. adding the funding invoice) in order to work, and thus should be run with a single thread (sequentially).