switch to spot valuation method by default

[wakamex]

change sdk and instances where we calculate a position's value to using market value instead of closeout value. this would impact:

• rust sdk
• frontend
• python

market value is position size * spot price which basically assumes no market impact, or an infinitesimally small trade closeout value is the amount of base you get back from closing your position

previous discussion

Mihai:

our 1 sdk user raised an interesting conundrum: https://github.com/delvtech/hyperdrive-rs/issues/16#issuecomment-2089238855 he can't value a position that can't be closed. he proposed a workaround of valuing it at maturity. but that means p=1 and includes all future interest. is there a better workaround? instead of value at maturity, you could value a hypothetical closing value if more liquidity were added. but is that any better? it doesn't include future interest, but it's working under an assumption that may never occur (added liquidity) thereby under-estimating price impact. PS not that I think about it, that's way better. I'm starting to think that for valuation purposes we may want to use a different methodology: value each position at position size * price I call this market value that's in contrast to the current practice of estimating what you'd get if you closed the position right now. the biggest drawback of this approach is that, sometimes you just can't close a position. I call this closeout value you could argue that closeout value is more accurate since it includes price impact. but estimating price impact the way we do now is also unrealistic, in a different way. our estimate closeout value only holds true for the very next position that closes. why? because after that, the price will be different, and the next person that closes will get a totally different price. we value n positions under a methodology that only holds for the next 1 position. so while this measures price impact, you could argue it gives a false sense of precision, while also vastly under-estimating price impact in case lots of people want to close in the same direction (a big market move, like we saw with MIM).

Matt:

Yeah i agree there, just return the theoretical Assume smol fish in big pond

Mazy:

In this situation, I def wouldn't say/think "I have $29M worth of ETH", I'd see it as $30M But it's also a big disappointment to see it turns into $29M when actually trying to cash out

Mihai:

the smol fish argument would go: if you're careful liquidating that position and don't splash in the pool all at once like the whale you are, you can sell it in small clips (squirts?) and allow the price to move back to equlibrium before selling your next clip, achieving a much better effective price, so you will actually be able to close out much closer to $30.2m than $29.07m! value is merely price condensed to a slow vibration

Mazy:

I guess each valuation method has situations where it's a better fit.

Mihai:

for an integration partner that takes Hyperdrive positions as collateral, the closeout value may be much more useful for them because it's more conservative. they'd still use other safety features like LTV haircuts or TWAPs. knowing price impact of a user's position definitely seems useful. but now that I think about it, that should probably be an optional part of their methodology, instead of baked in. because if the methodology returns None we don't want their protocol to crash.

[DannyDelott]

This is needed in the UI as well: https://github.com/delvtech/hyperdrive-frontend/issues/1144

[wakamex]

Given that https://github.com/delvtech/hyperdrive-frontend/issues/1144 is a priority, and I haven't heard anyone say that we shouldn't make this the default everywhere, I'm going to assume everyone is on-board with this, and we should do it earlier rather than later, to be in line with frontend.

Since frontend is already leading the way, that means rust sdk and python are the ones left to switch over. cc @dpaiton @slundqui