Adjust max-send with contract calls that send STX based on (exact) post conditions

[314159265359879]

With #3525 The available STX are adjusted based on pending sends of STX (going out) and pending fees. To fix #3338

When we add this addition based on post conditions I believe we'll prevent even more cases where users send out more STX then they have and in the process blocking their wallet: Particularly the case described here: #3525 (comment)

We should only adjust the available balance when the postconditions is exact (if done for at least... or more than), example:

https://explorer.testnet.alexlab.co/txid/0xee79c3a62b6dd95967c58a7e68d926b1cb990afce99fe64df80183f71002a8f6?chain=mainnet

[markmhendrickson]

I'm assigning @alter-eggo back to you to take a look. Let's discuss further if it's not clear.

Essentially @314159265359879 is suggesting that for calculating the available balance in the wallet that we show, we should not only subtract the values of pending simple transfer transactions per #3525 but also the tokens that are intended to be transferred out of the user's wallet as the result of pending contract execution transactions.

These contract executions may include post conditions that define the exact amount of tokens they're intended to transfer e.g. "You will transfer exactly 100 ALEX". If such a post condition is present for a transaction in the mempool, we can reduce the available balance displayed and enforced by the amount of that post condition (e.g. 100 ALEX in this case).

I'm not entirely sure the API gives us information about post conditions of pending transactions, so if it doesn't, we can create an issue in the API repo requesting its addition.

[314159265359879]

Related to: #1587 and #3109

@rafaelcr is there an API the wallet can use to calculate for pending transactions outgoing STX from contract calls based on post-conditions "transfer exactly XX STX"?

[rafaelcr]

Hi @314159265359879 sorry for the late response.

Unfortunately I believe there's no way for the API to give that specific information other than the data it currently returns in the mempool tx object, i.e. all the data you currently get from a contract-call mempool tx is all the data we receive from the Stacks node up to that point.

EDIT: I just double checked and post conditions are included in the mempool tx object, can you see if that is sufficient for you?

[markmhendrickson]

@314159265359879 let's file this in the API repo so the Hiro team can track there more easily?

[markmhendrickson]

EDIT: I just double checked and post conditions are included in the mempool tx object, can you see if that is sufficient for you?

@kyranjamie any ideas?

[314159265359879]

@314159265359879 let's file this in the API repo so the Hiro team can track there more easily?

Depends on if more is needed here to implement this on our side. I will let Kyran comment on Rafael's comment "I just double checked and post conditions are included in the mempool tx object, can you see if that is sufficient for you?"

[kyranjamie]

I didn't realise that we did subtract contract call transfer sums from available balance. Suggest this task is more generally framed at improving available balance calculation for Stacks when funds are being transferred via contract-call transactions.

[314159265359879]

@kyranjamie we don't subtract for contract calls yet.

And the more general frame is interesting but not the most important to address. We want the wallet to especially good at calculating the available STX balance.

It used to be relevant to stop the transactions from clogging the wallet (pre stacks 2.5) now it can cause transactions to be processed but fail because miner fee is taken first and then not enough is left to cover the transaction. For example a swap that requires an exact STX input to convert to token Y.

tokens (sip10) otjer than the gas-asset also benefit from such calculation but the benefits will be smaller because their balance isn't, influenced with/ relevant to, every transaction.