Currently we have different types of apis which focuses on creating a particular types of transactions.
for eg
spend_from_wallet api which is used to general purpose transaction.
create_funding_txes -> which creates funding txs for starting coinswap
create_fidelity -> creates fidelity bond by first creating , broadcasting the fidelity tx and makes further updates.
create_senders_contract_tx -> creates contract tx which spends utxos generated by funding txes.
and many more...
But all these api's do same work at some level -> i.e they all contain reductant code for creating a transaction , selecting required utxos etc.
This redundancy can be minimised by following proposed structural design:
fn create_signed_tx(fee:Amount, amount:SendAmount, destinations:Destination, coins_to_spend)-> Result<Transaction, WalletError>{
// private function
// A general tx generating api which will create any type of transactions , sign it and return tx instance.
// implementation -> same as `spend_from_wallet` api.
return transaction
}
pub create_fedility{
// do some work related to fedility.
// select required utxos for making fidelity bonds.
let selected_utxos= self.coin_select(..);
// create tx instance and sign it.
let signed_tx= create_signed_tx(...);
// do some work related to fidelity.
}
// .... Similarly we can create other specific transaction api which will be wrappers .
Enhancements:
Remove reductant code which focuses on creating transaction struct and selecting required utxos.
Currently we have different types of apis which focuses on creating a particular types of transactions. for eg
spend_from_wallet
api which is used to general purpose transaction.create_funding_txes
-> which creates funding txs for starting coinswapcreate_fidelity
-> creates fidelity bond by first creating , broadcasting the fidelity tx and makes further updates.create_senders_contract_tx
-> creates contract tx which spends utxos generated by funding txes. and many more...But all these api's do same work at some level -> i.e they all contain reductant code for creating a transaction , selecting required utxos etc. This redundancy can be minimised by following proposed structural design:
Enhancements: