-
Notifications
You must be signed in to change notification settings - Fork 0
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
create functions for valuing positions using spot methodology #138
Comments
2 tasks
MazyGio
added a commit
that referenced
this issue
Jul 22, 2024
# Resolved Issues Adds `calculate_value_long` and `calculate_value_short` functions as described in #138 (#138) # Description formula for `value_long`: ``` market_estimate = trading_proceeds - flat_fees_paid - curve_fees_paid trading_proceeds = flat_value + curve_value flat_value = dy * (1 - t) curve_bonds = dy * t curve_value = curve_bonds * p = dy * t * p flat_fees_paid = flat_value * flat_fee = dy * (1 - t) * flat_fee curve_fees_paid = (curve_bonds - curve_value) * curve_fee = dy * t * (1 - p) * curve_fee dy = bond amount p = spotPrice t = termRemaining (positionDuration - (currentTimestamp - openTimestamp)) ``` formula for `value_short`: ``` market_estimate = yield_accrued + trading_proceeds - curve_fees_paid + flat_fees_returned yield_accrued = dy * (c-c0)/c0 trading_proceeds = dy * (1 - p) * t curve_fees_paid = trading_proceeds * curve_fee flat_fees_returned = dy * t * flat_fee dy = bond amount c = vaultSharePrice (current if non-matured, or checkpoint's if matured) c0 = openVaultSharePrice p = spotPrice t = termRemaining (positionDuration - (currentTimestamp - openTimestamp)) ``` # Review Checklists Please check each item **before approving** the pull request. While going through the checklist, it is recommended to leave comments on items that are referenced in the checklist to make sure that they are reviewed. - [ ] **Testing** - [ ] Are there new or updated unit or integration tests? - [ ] Do the tests cover the happy paths? - [ ] Do the tests cover the unhappy paths? - [ ] Are there an adequate number of fuzz tests to ensure that we are covering the full input space? - [ ] If matching Solidity behavior, are there differential fuzz tests that ensure that Rust matches Solidity?
dpaiton
added a commit
that referenced
this issue
Jul 24, 2024
# Resolved Issues #138 delvtech/agent0#1618 # Description This PR adds python bindings for `calculate_market_value_long`, `calculate_market_value_short`, and `calc_scaled_normalized_time_remaining`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Similar to the frontend's use (delvtech/hyperdrive-frontend#1144), we need spot methodology valuation in the rust sdk, which well then be using for ChainSync.
Previous discussion of spot versus closeout methodology is here: delvtech/hyperdrive#1032.
I propose calling these functions
value_long
andvalue_short
which to me makes it clear these don't include market impact of closing your account. Is this clear enough that this isn't the amount of money you'll get when you go to close your position? Would it be clearer if we called them something else?market_value_long
andmarket_value_short
? Looks like frontend is usingcalcShortMarketValue
in delvtech/hyperdrive-frontend#1167. For me the most clear would becalc_long_closeout
andcalc_long_value
.In keeping with the market standard of other trading platforms, would it make more sense not to include fees?
Plan:
calc_close_long
,calc_close_short
)formula for
value_long
:formula for
value_short
:The text was updated successfully, but these errors were encountered: