hirosystems / stacks-blockchain-api

API for the Stacks blockchain
https://stacks-blockchain-api.vercel.app
GNU General Public License v3.0
177 stars 114 forks source link

Have an API endpoint for spendable/available balance that takes into account pending outgoing transfers and pending fees #1576

Open 314159265359879 opened 1 year ago

314159265359879 commented 1 year ago

Is your feature request related to a problem? Please describe. Users are unintentionally trying to double spend. I think it would help if we had something like "available balance" that takes into account (especially STX available balance) based on a. all fees of pending transactions, b. pending outgoing transfers of STX, c.. and any other transaction with post conditions of "transfer exactly ... STX"

To prevent issues like this: a. Wallet showing balance available, that is send out and pending. https://github.com/hirosystems/stacks-wallet-web/issues/3389 b. User swapping the same amount of STX 10 times. and https://github.com/hirosystems/stacks-wallet-web/issues/3338 c. Users increasing the fee so the total transaction (499+1.003 fee) exceeds their balance (500) and is no longer mineable.

Describe the solution you'd like Mark and I were wondering if there is anything that can be done to help prevent the listed issues going from the API side.

Describe alternatives you've considered Handling it solely on the dapp and/or wallet side.

rafaelcr commented 1 year ago

The current status of Stacks blocks and mempool prevents us from being able to provide an endpoint like this that would have actionable data, given that for example the mempool data we get is very lossy and could come with a significant delay. Long block times also don't help with this because txs get accumulated and it makes the problem harder (it also creates other side effects like none issues, etc.)

However, I believe we will be able to revisit this once the Nakamoto release is implemented. Improved block times would allow us to be much more precise in the data we serve and we would be able to add an endpoint like this.

We will keep this issue in the backlog for now but we will revisit once Nakamoto support is in development.