Create calculate_targeted_short
#21
Assignees
Labels
enhancement
New feature or request
Comments
6 tasks
This was referenced May 1, 2024
dpaiton
added a commit
that referenced
this issue
Jun 4, 2024
# Resolved Issues Partially addresses #29 and #21 # Description These are steps towards implementing a parity implementation of open short as well as targeted short. - Add a function to calc short proceeds & round up, which is used in the Open Short flow. - Modifies calculate short proceeds down to look more like the up version. Since these functions are implemented on State, we preferentially use State member variables (e.g. `vault_share_price`) instead of passing arguments. The short proceeds is given by: $$ P_{\text{short}}(\Delta y) = \tfrac{\Delta y \cdot c_{1}}{c_{0} \cdot c} + \tfrac{\Delta y}{c} \cdot \phi_{f} - \Delta z(\Delta y) $$
This was referenced Jul 8, 2024
Draft
This was referenced Jul 16, 2024
dpaiton
added a commit
that referenced
this issue
Jul 22, 2024
# Resolved Issues working towards #171 and #21 # Description - The code for calculating pool deltas & state after opening a long did not correctly account for the gov fee's impact on the share reserves. I fixed this and added a test to demonstrate the failure - I added a similar test on the short side, which almost passes with equality (seems there is a rounding error) - I renamed some functions, cleaned up some comments, fixed some typos
dpaiton
added a commit
that referenced
this issue
Jul 22, 2024
…ing_exposure` (#180) # Resolved Issues working towards #21 # Description In #167 I wrote a test for `long_trade_needed_given_reserves` and `reserves_given_rate_ignoring_exposure`, which we will need to translate to the short variety for the targeted short flow. For the tests to pass I had to set fees, zeta, and exposure to zero. This was because the test itself used other components that required this, although the function of interest (`long_trade_needed_given_reserves`) does not have the same requirements. In this PR I rewrote the test to be simpler and more direct, and found that the function was not passing with any sort of reasonable tolerance. I figured out the bug (we were not accounting for fees correctly) and fixed it. Part of the fix for `long_trade_needed_given_reserves` included adding a sanity check on reserve levels, which revealed a bug in `reserves_given_rate_ignoring_exposure`, which was returning invalid reserve amounts due to non-zero exposure or zeta. Adding zeta to the equation fixed that problem, so all tests are passing again. I had to increase the tolerance for the targeted long test. I'm not entirely sure why, but I think it's still reasonable so I will not investigate it further at this time.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should add a function to the Rust SDK that calculates the short amount that brings the pool to a targeted effective rate (including fees). Traders could use this to calculate the optimal trade to make given their expected future variable rate.
The text was updated successfully, but these errors were encountered: