Skip to content
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

Closed
DannyDelott opened this issue Aug 6, 2024 · 2 comments · Fixed by #208
Closed
Assignees

Comments

@DannyDelott
Copy link
Contributor

Background

The sdk's calculate_max_short method takes a budget 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

  1. Call calculate_max_short with a max uint256 budget to get the pool's max short (in bonds).
  2. Feed this bond amount into calculate_open_short to get the actual traderDeposit needed.
  3. Feed the traderDeposit back into calculate_max_short as the budget.

Expected

The bond amount returned from calculate_max_short should be the same as the bond amount we gave to calculate_open_short.

Actual

Feeding the traderDeposit back into calculate_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 or calculate_open_short will be called to update the form.

image

@DannyDelott
Copy link
Contributor Author

We're currently not passing a conservative_price argument to calcMaxShort, there is prior art on how to calculate this here that we should try:

@dpaiton
Copy link
Contributor

dpaiton commented Oct 2, 2024

Tasks :

dpaiton added a commit that referenced this issue Oct 4, 2024
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.
@dpaiton dpaiton linked a pull request Dec 20, 2024 that will close this issue
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants