status-desktop
status-desktop copied to clipboard
Sending transaction - improvements
This issue depends on #14635
Apart from the things stated below, sending logic should know, based on the route, which transactions should be placed in parallel (immediately) and which of them should wait for execution of previously placed transaction/s.
Currently CreateMultiTransactionFromCommand
function does many things:
- prepares multi-transaction for tracking
- stores it to db
- builds transactions
- signs and sends transactions (in case of non-keycard key pair)
- sends transactions for signing (in case of keycard keypair)
Within this issue it would be good to unify the process in a way:
- a client requests from statusgo to build transactions for the best route that was displayed
- statusgo:
- builds all transactions and sends signal to the client asking for signing transactions or
- builds transactions one by one and sends to the client for signing, in the order which is determined by the router
- the client:
- signs transactions and calls statusgo to send built transactions providing signatures for all of them or
- signs transactions one by one and calls statusgo to send built transaction providing signature for it
- statusgo:
- sends built transactions with received signatures
- sends built transaction with received signature and waits for its execution before asking the client to sign next transaction
- once all transactions from the bundle are sent statusgo notifies client via signal that the multitransaction is sent