Differential D18382
[Cashtab] Select 99% of balance if user cannot afford the whole agora offer Authored by bytesofman on Jul 17 2025, 22:51.
Details
Working on exact fee calculation in D18380. Apart from various complexities, it's also a tough UX problem to manage. When we do get it right, and a user really can max buy -- well, then they have no XEC left for any other actions. So we need to either have a notice for this or prevent it somehow. For now, this is probably the best kind of solution. It's better than the user seeing an error whenever they try to Max buy. And it will never consume the user's entire XEC balance. npm test this diff is deployed at cashtab.io
Diff Detail
Event TimelineComment Actions Hitting Max, which shows 99% of max affordable amount as expected, on a wallet balance of 47.64 XEC, is still getting the insufficient utxos error  Comment Actions
right but this is already happening in prod this diff improves the current situation by stopping this in prod most of the time I don't think it is worth drilling down to try to get all edge cases with this diff -- we are working to get the exact fees sorted elsewhere mb we could switch it to 98% or even 95% and catch these microbalance situations but the real fix is to calculate the fee and consider that, which we are working on in the background Comment Actions
Can't we have a retry loop ? Start with 100%, it that doesn't work lower the amount and so on Comment Actions
🤔 On first seeing this started to make the diff, yes, we can do this, would also solve the problem. I think though it's not great as a "pre-fix fix", i.e. I do want to get to the point where we just know the actual number here. The issue with the retry approach is that I think it's important the user actually buys the quantity presented to them in the approve modal. It's already pretty weird that the approve modal amount (could) differ from the amount they are trying to buy due to agora quanta issues. I think it would be weirder still if they
imo another example of how 64-bit ints could really improve agora. The real fix here is "user wants to buy amount A and buys amount A with no shennannigans." So -- while retrying does fix the issue, I think it creates another issue, and it's also a bandaid solution that would have to be re-engineered later. The solution presented in this diff is also just a bandaid solution but I think it's more flexible and (maybe) less confusing ... though tbh there's a lot of guesswork / judgment there. The real fix is 64-bit ints and proper fee estimation, both of which will take some time. So this diff can eliminate most of the errors, if the errors are still common then we switch from 99 to 98 or 95, can prob work out proper fee estimation before 64 bit ints and then have a workflow for that, then implement 64-bit ints when it's ready, implement ecash-wallet multi-offer-buys to get full exchange-like UX when it's ready, etc. |