multi: order fee estimation #958
Conversation
buck54321
force-pushed
the
fee-estimates
branch
from
21a81d7
to
b3bb6ff
Compare
| type PreSwap struct { | ||
| Estimate *SwapEstimate `json:"estimate"` | ||
| } |
There was a problem hiding this comment.
This is one of a few seemingly unnecessary wrapper structs that will soon be used to accommodate the order-time options. I've made some temporary comments in this file to explain their purpose.
Since order-time options are entirely optional, setting up the structs now means that when the options become available, we don't need to break the API.
| func (btc *ExchangeWallet) RedemptionFees() (uint64, error) { | ||
| // estimateSwap prepares an *asset.SwapEstimate. | ||
| func (btc *ExchangeWallet) estimateSwap(lots, lotSize, networkFeeRate uint64, utxos []*compositeUTXO, | ||
| nfo *dex.Asset, trySplit bool) (*asset.SwapEstimate, bool /*split used*/, error) { |
There was a problem hiding this comment.
It doesn't look like the second return is ever utilized. It will be in the future?
There was a problem hiding this comment.
It will be in the future?
Yes. Split transactions will be an order-time option for utxo-based blockchains, so we'll need to know which path estimateSwap took.
client/asset/btc/btc_test.go
Outdated
| // chained_swap_sizes = (lots - 1) * swap_size | ||
| // first_swap_size = swap_size_base + backing_bytes | ||
| // total_bytes = first_swap_size + chained_swap_sizes | ||
| // total_bytes = swap_size_base + backing_bytes + (lots - 1) * swap_size |
There was a problem hiding this comment.
Should the second one here be total_bytes +=?
There was a problem hiding this comment.
These are actually just two different formula for the same thing. I probably just shouldn't have moved this. It made more sense where it was, I think.
| return &asset.PreRedeem{ | ||
| Estimate: &asset.RedeemEstimate{ | ||
| RealisticWorstCase: worst * feeRate, | ||
| RealisticBestCase: best * feeRate, |
There was a problem hiding this comment.
What is the best case useful for?
There was a problem hiding this comment.
All we can really say before matching is that the fees will (realistically) fall in a range between the best and worst case. Best case provides the lower limit. Worst cast provides the upper limit.
There was a problem hiding this comment.
Just to expand on this a little, the worst case is probably the one I would pay attention to the most, but for users who place large orders, they may want to collect statistics over time to better estimate where their risk falls between these two points.
From a UI perspective, this will allow us to offer some additional clarity on fees instead of just showing the worst-case value.
buck54321
force-pushed
the
fee-estimates
branch
from
680a161
to
0756b0b
Compare
An order fee estimate consists of 3 values for the swap and 2 for the redemption. The swap has a max possible fees (MaxFeeRate), and both high and low estimates corresponding to the best and worst case settlement sequences, but at the prevailing network fee rate. Similarly, the redemption estimate has high and low estimates evaluated for the worst and best settlemetn sequences (1 tx per lot vs 1 tx for all).
chappjc
force-pushed
the
fee-estimates
branch
from
0756b0b
to
1eff08b
Compare
An order fee estimate consists of 3 values for the swap and 2 for the redemption. The swap has a max possible fees (
MaxFeeRate), and both high and low estimates corresponding to the best and worst case settlement sequences, but at the prevailing network fee rate.Similarly, the redemption estimate has high and low estimates evaluated for the worst and best settlement sequences (1 tx per lot
vs 1 tx for all).