Generate own step payout function #2352

luckysori · 2024-04-02T14:20:16Z

Note to reviewers: the second patch was an attempt at fixing #2288 which was later replaced by rewriting the payout curve generation logic. I would recommend to review this PR in one go (not patch by patch).

Fixes #2288.
Fixes #1834.

Before this PR, we generated a polynomial payout function which would then be transformed by rust-dlc into a step function. This approach was problematic because we could not trust rust-dlc to not mess with the intervals excessively.

Specifically, any changes to the liquidation intervals could cause problems because they represent the collateral reserves, which are used to indicate available balances and are circumstantially needed to complete features such as position resizing.

Now we take full control of the payout function generation, directly generating a step function that can be consumed by rust-dlc without rounding. The payout is calculated by taking the PNL at the half-way point of the interval.

It is important to emphasise that we must opt out of rounding by using a RoundingIntervals with a single element of the form:

RoundingInterval {
    begin_interval: 0,
    rounding_mod: 1,
}

Overall, I think the code is considerably simpler and there are fewer edge cases to handle.

One important thing to consider is that we can now directly control the number of payouts we generate, which has an effect on the number of CETs that will be created. This is currently set by the constant PAYOUT_CURVE_DISCRETIZATION_INTERVALS, but in the future we could make it dynamic.

Additionally, at the moment the majority of the intervals are of equal length in terms of price. Eventually we might want to generate more, smaller intervals around the starting price, and make the less likely intervals bigger as we approach the liquidation zones.

Other notable changes

Since we had to replace a snapshot, we've introduced a dev-dependency to insta¹, a library that makes it easy to write and maintain snapshot tests. There is a companion tool, cargo-insta², which can help with this process.

luckysori · 2024-04-05T04:54:30Z

Running the payout_curve example shows that the hard-coded function has not changed after this PR. On the left is before this PR; on the right, after the PR.

`NumericalDescriptor::get_range_payouts` should be called with the _total_ collateral, including position margin and the collateral reserves.

We were allowing the short liquidation payout to go under the short party's collateral reserve, which was obviously wrong. The payout curve is still a bit rough around the edges (literally). This is because we have to make relatively big payout jumps to connect the liquidation intervals with the adjacent intervals. I'm not sure there is a good solution for this other than going back to the ItchySats payout curve.

This is the (probably) last thing that prevents us from being able to rely on the payout curve liquidation intervals for things like the available balance and, relatedly, position resizing.

Before this patch, we generated a polynomial payout function which would then be transformed by `rust-dlc` into a step function. This approach was problematic because we could not trust `rust-dlc` to not mess with the intervals excessively. Specifically, any changes to the liquidation intervals could cause problems because they represent the collateral reserves, which are used to indicate available balances and are circumstantially needed to complete features such as position resizing. Now we take full control of the payout function generation, directly generating a step function that can be consumed by `rust-dlc` _without_ rounding. The payout is calculated by taking the PNL at the half-way point of the interval. It is important to emphasise that we must opt out of rounding by using a `RoundingIntervals` with a single element of the form: ```rust RoundingInterval { begin_interval: 0, rounding_mod: 1, } ``` Overall, I think the code is considerably simpler and there are fewer edge cases to handle. One important thing to consider is that we can now directly control the number of payouts we generate, which has an effect on the number of CETs that will be created. This is currently set by the constant `PAYOUT_CURVE_DISCRETIZATION_INTERVALS`, but in the future we could make it dynamic. Additionally, at the moment the majority of the intervals are of equal length in terms of price. Eventually we might want to generate more, smaller intervals around the starting price, and make the less likely intervals bigger as we approach the liquidation zones. Other notable changes --------------------- Since we had to replace a snapshot, we've introduced a dev-dependency to `insta`[^1], a library that makes it easy to write and maintain snapshot tests. There is a companion tool, `cargo-insta`[^2], which can help with this process. [^1]: https://github.com/mitsuhiko/insta. [^2]: https://github.com/mitsuhiko/insta/tree/master/cargo-insta.

holzeis

LGTM

bonomat

Please excuse the late review.

It's been a while that I've been working on this, so please be kind if this is a stupid question for a Sunday night , and I also know that this was built on my initial version. But help me out please:
In this example from payout_curve_csv, the offerer goes long with a leverage of 2 and the and the acceptor short with leverage 2.
If the price goes up, he wins everything from ~60k (short liquidation price).
but shouldn't he be losing everything from ~20k?

bonomat · 2024-04-06T11:46:32Z

coordinator/src/payout_curve.rs

@@ -298,6 +237,140 @@ mod tests {
        }
    }

+    #[test]
+    fn payout_function_respects_collateral_reserve() {


Would you mind adding some comments in here please? It's hard to follow what is happening.

@luckysori reminder to do this tomorrow.

Done here: #2368.

bonomat · 2024-04-07T09:48:14Z

coordinator/src/payout_curve.rs

+        let initial_price = dec!(28_251);
+        let quantity = 500.0;
+        let leverage_coordinator = 2.0;
+        let coordinator_margin = calculate_margin(initial_price, quantity, leverage_coordinator);


It might be worth using hardcoded values all the way

Hmmm, I think these should not be hard-coded because they are derived from other parameters.

bonomat · 2024-04-07T09:48:30Z

coordinator/src/payout_curve.rs

+
+        let coordinator_direction = Direction::Short;
+
+        let coordinator_collateral_reserve = 2_120_386;


Do you have a formula of how to get to this value?

This one is just completely arbitrary based on an example that failed when running tests. It's not computed, the fee reserve can be arbitrary.

luckysori · 2024-04-07T10:37:15Z

Please excuse the late review.

It's been a while that I've been working on this, so please be kind if this is a stupid question for a Sunday night , and I also know that this was built on my initial version. But help me out please:

In this example from payout_curve_csv, the offerer goes long with a leverage of 2 and the and the acceptor short with leverage 2.

If the price goes up, he wins everything from ~60k (short liquidation price).

but shouldn't he be losing everything from ~20k?

Fair question! The example configures the offer party with a fee reserve of 300k sats.

https://github.com/get10101/10101/blob/main/crates/payout_curve/examples/payout_curve_csv.rs#L54-L56

So the offer party's minimum payout is set by that amount.

bonomat · 2024-04-07T23:31:10Z

Please excuse the late review.
It's been a while that I've been working on this, so please be kind if this is a stupid question for a Sunday night , and I also know that this was built on my initial version. But help me out please:
In this example from payout_curve_csv, the offerer goes long with a leverage of 2 and the and the acceptor short with leverage 2.
If the price goes up, he wins everything from ~60k (short liquidation price).
but shouldn't he be losing everything from ~20k?

Fair question! The example configures the offer party with a fee reserve of 300k sats.

main/crates/payout_curve/examples/payout_curve_csv.rs#L54-L56

So the offer party's minimum payout is set by that amount.

aahhh... that makes sense. Thanks for the explanation :D

bonomat · 2024-04-07T23:31:29Z

Awesome work btw. :)

luckysori requested review from bonomat and holzeis April 2, 2024 14:20

luckysori self-assigned this Apr 2, 2024

luckysori force-pushed the fix/issue-2288 branch 3 times, most recently from cfce164 to cd8a54f Compare April 3, 2024 08:23

luckysori enabled auto-merge April 3, 2024 08:34

luckysori force-pushed the fix/issue-2288 branch 2 times, most recently from 95117e7 to 2665f22 Compare April 4, 2024 03:42

luckysori changed the title ~~Ensure that liquidation payouts are sane~~ Generate own step payout function Apr 5, 2024

luckysori force-pushed the fix/issue-2288 branch from a09789b to d73e17f Compare April 5, 2024 04:36

luckysori force-pushed the fix/issue-2288 branch from d73e17f to 5e6dd19 Compare April 5, 2024 04:57

luckysori mentioned this pull request Apr 5, 2024

Reintroduce position resizing #2359

Merged

luckysori added 4 commits April 5, 2024 23:02

fix(payout_curve): Fix payout_price_range_is_below_max_price test

0a9e881

`NumericalDescriptor::get_range_payouts` should be called with the _total_ collateral, including position margin and the collateral reserves.

chore(coordinator): Reproduce payout curve limitation

88bcf77

This is the (probably) last thing that prevents us from being able to rely on the payout curve liquidation intervals for things like the available balance and, relatedly, position resizing.

luckysori force-pushed the fix/issue-2288 branch from 5e6dd19 to 10e0cee Compare April 5, 2024 12:02

luckysori added this pull request to the merge queue Apr 7, 2024

holzeis approved these changes Apr 7, 2024

View reviewed changes

Merged via the queue into main with commit 54a67c8 Apr 7, 2024
21 checks passed

luckysori deleted the fix/issue-2288 branch April 7, 2024 08:53

bonomat reviewed Apr 7, 2024

View reviewed changes

luckysori mentioned this pull request Apr 7, 2024

Clarify payout function test #2368

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generate own step payout function #2352

Generate own step payout function #2352

luckysori commented Apr 2, 2024 •

edited

Loading

luckysori commented Apr 5, 2024 •

edited

Loading

holzeis left a comment

bonomat left a comment

bonomat Apr 6, 2024

luckysori Apr 7, 2024

luckysori Apr 7, 2024

bonomat Apr 7, 2024

luckysori Apr 7, 2024

bonomat Apr 7, 2024

luckysori Apr 7, 2024

luckysori commented Apr 7, 2024

bonomat commented Apr 7, 2024

bonomat commented Apr 7, 2024


		let coordinator_direction = Direction::Short;

		let coordinator_collateral_reserve = 2_120_386;

Generate own step payout function #2352

Generate own step payout function #2352

Conversation

luckysori commented Apr 2, 2024 • edited Loading

Other notable changes

Footnotes

luckysori commented Apr 5, 2024 • edited Loading

holzeis left a comment

Choose a reason for hiding this comment

bonomat left a comment

Choose a reason for hiding this comment

bonomat Apr 6, 2024

Choose a reason for hiding this comment

luckysori Apr 7, 2024

Choose a reason for hiding this comment

luckysori Apr 7, 2024

Choose a reason for hiding this comment

bonomat Apr 7, 2024

Choose a reason for hiding this comment

luckysori Apr 7, 2024

Choose a reason for hiding this comment

bonomat Apr 7, 2024

Choose a reason for hiding this comment

luckysori Apr 7, 2024

Choose a reason for hiding this comment

luckysori commented Apr 7, 2024

bonomat commented Apr 7, 2024

bonomat commented Apr 7, 2024

luckysori commented Apr 2, 2024 •

edited

Loading

luckysori commented Apr 5, 2024 •

edited

Loading