-
Notifications
You must be signed in to change notification settings - Fork 1
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
Inconsistency when using calculate_open_short
and calculate_max_short
together
#185
Comments
We're currently not passing a conservative_price argument to
|
This was referenced Sep 27, 2024
Tasks :
|
dpaiton
added a commit
that referenced
this issue
Oct 4, 2024
# Resolved Issues This gives us a good starting point towards resolving #185 # Description [approx_short.pdf](https://github.com/user-attachments/files/17171509/approx_short.pdf) <img width="485" alt="image" src="https://github.com/user-attachments/assets/adc50db1-b809-4e1d-b47a-416bd578efd9"> <img width="485" alt="image" src="https://github.com/user-attachments/assets/666a55ea-0857-42d7-9f1e-b80509eddcca">
dpaiton
added a commit
that referenced
this issue
Oct 4, 2024
# Resolved Issues working towards #185 Also makes more progress towards #21 # Description This provides an alternative function to `calculate_max_short` that includes a tolerance parameter and guarantees* convergence with sufficient number of iterations. I changed the signature & behavior from `calculate_max_short` in these ways: - Most importantly, we now ask for the absolute max short (aka pool's max regardless of budget) as an input argument. This is to make clear to the user that there are two required iterative processes to get this answer: first one is to find the absolute max short, second is to find a max short relative to a budget. - This function should also not be used with an unlimited budget to find the max short. Use `calculate_absolute_max_short` for that. If you provide a budget that is larger than the max possible, then this function will throw an error. - The result is guaranteed to be less than or equal to your budget; it will not overshoot the target base amount even if the result is within tolerance and solvent. *I tested a lot of options, but I don't have any formal guarantees on convergence. The most extreme values I tried was `1e5` tolerance with `1M` steps. These two knobs can be tuned as needed for trading off compute speed against tolerance. # Remaining tasks for future PRs - The new test is pretty janky because of the need to put several checks around calculating the absolute max bond amount. That function needs to be investigated next. - I still need to make the wasm & python bindings. This should be done after I fix up absolute max bond amount. - I created this as a new function because I want to give it a chance to exist on its own and be tested before we deprecate the existing `calculate_max_short` function. Once we have battle tested it, we will want to do a cleanup. - The method for calculating the conservative price is still not guaranteed to be safe.
sentilesdal
pushed a commit
that referenced
this issue
Jan 22, 2025
# Resolved Issues #185 # Description This PR adds a test to verify the conversion between base and bonds via open short functions is consistent. The test follows the recommendation in the cited issues. The test currently FAILS, so it is ignored and a follow-up PR will implement fixes so that it passes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
The sdk's
calculate_max_short
method takes abudget
and returns a bond amount.The
calculate_open_short
takes a bond amount and returns the trader deposit (ie:budget
).We expect that the outputs of one would reflect the inputs of the other, however the steps below show that this is not the case.
Steps to reproduce
calculate_max_short
with a max uint256 budget to get the pool's max short (in bonds).calculate_open_short
to get the actualtraderDeposit
needed.traderDeposit
back intocalculate_max_short
as the budget.Expected
The bond amount returned from
calculate_max_short
should be the same as the bond amount we gave tocalculate_open_short
.Actual
Feeding the
traderDeposit
back intocalculate_max_short
results in significantly fewer bonds shorted.Usecase:
In the Open Short form, users can input either an amount to pay (budget) or the number of bonds to short.
Depending on which one they type into, either
calculate_max_short
orcalculate_open_short
will be called to update the form.The text was updated successfully, but these errors were encountered: