-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi: order fee estimation #958
Conversation
21a81d7
to
b3bb6ff
Compare
type PreSwap struct { | ||
Estimate *SwapEstimate `json:"estimate"` | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like the second return is ever utilized. It will be in the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the second one here be total_bytes +=
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the best case useful for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. Just some minor nits and probably just a little confusion on my part about how PreRedeem
is called from MaxBuy
and MaxSell
, also if PreRedeem
is going to use lotsize at some point because it's only using lots now.
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).
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).