-
Notifications
You must be signed in to change notification settings - Fork 233
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
Honoring the original unit price in updated offers #22
Comments
Alternatively, to save a field, there could be |
Good catch. This is something that Zathras mentioned during the all-hands earlier this week. Thanks! |
Well, actually I know I originally suggested adding two new fields (for original values) to the
I think @m21's original intentions when building that class were to store the original values in Thus, correct me if I'm wrong, but couldn't we try to steer things back in that original direction, and save ourselves the trouble of expanding the TL:DR; make
So it would become Thoughts? |
Yeah, I was looking at my Python based trading engine, I build some time ago to quickly test trades (the logic isn't the one, which got specified IIRC), and after reading it, it sort of got me: "wait.. what if we calculate the desired amount on the fly? oh wait! isn't there even still_left_for_sale?" ... hehe. This was very likely the original intend, which got twisted somehow. Some of the RPC fields also still show So I agree, and think this could be the way to go. Since you also have a meta DEx branch, this is relevant: I started to split
I'm still not sure, how to structure it, e.g. there is |
Agreed, if you split them out and PR it, as long as it's just splitting and no functional changes we should be able to merge right away, and then I can work from the split files |
See #26. Please let me know, if this is fine. |
This issue is going to be resolved by the currently pending/close-to-be-ready changes. |
When calculating the amounts to trade on the meta DEx, the applied unit price of an order may be rounded to the next tradable unit, constrained by the amounts available, however, the original unit price should be honored in subsequent trades.
Example trade:
From the debug log:
This slightly off unit price is due to the ratio of
9.27272727/92.72727273
.As consequence, the unit price starts to drift, and may be significantly different after one or more trades.
A straight forward fix requires two additional fields for CMPMetaDEx objects,
original_amount_forsale
andoriginal_amount_desired
, which shall be used to calculate the unit price for (subsequent) offers.This likely introduces the requirement of further adjustments to CMPMetaDEx::effectivePrice(), maybe to the core meta DEx logic, and certainly to the persistence of data, in particular CMPMetaDEx::saveOffer().
As far as I can see, no change of CMPTradeList::recordTrade() is necessary, but this hidden, or original unit price should be clearly reflected in all user faced channels (i.e.
gettrade_MP
,getorderbook_MP
, ... ?).The text was updated successfully, but these errors were encountered: