feat: add liquidation acs

protocol/0003-MTMK-mark_to_market_settlement.md

@@ -22,6 +22,10 @@
 1. If the mark price hasn't changed:
     1. A trader with no change in open position size has no transfers in or out of their margin account (<a name="0003-MTMK-012" href="#0003-MTMK-012">0003-MTMK-012</a>)
 1. An aggressive order to buy 2 units at 1010 which matches with two passive orders each of size one resting on the book with prices of 1000 and 1010 results in a transfer of 10 flowing from the party with order priced at 1000 to the aggressive party during the next MTM settlement <a name="0003-MTMK-013" href="#0003-MTMK-013">0003-MTMK-013</a>)
+1. If the network party has a non-zero position and the mark-price moves in favour of the network's position gains from mark-to-market settlement should be paid into the market insurance pool. (<a name="0003-MTMK-015" href="#0003-MTMK-015">0003-MTMK-015</a>)
+1. If the network party has a non-zero position and the mark-price moves against the network's position, losses from mark-to-market settlement should be paid from the market insurance pool. (<a name="0003-MTMK-016" href="#0003-MTMK-016">0003-MTMK-016</a>)
+1. If the network does not have enough funds in the market insurance pool to cover its mark-to-market losses, loss-socialisation occurs. (<a name="0003-MTMK-017" href="#0003-MTMK-017">0003-MTMK-017</a>)
+
 
 ## Market with position decimal places > 0 scenario
 

protocol/0012-POSR-position_resolution.md

@@ -27,6 +27,20 @@
 
 - It is possible to check the time of the next liquidation trade attempt in any market via the API. (<a name="0012-POSR-015" href="#0012-POSR-015">0012-POSR-015</a>)
 
+### Network position disposal
+
+- When calculating the available volume, the full remaining size of iceberg orders should be considered. (<a name="0012-POSR-019" href="#0012-POSR-019">0012-POSR-019</a>)
+- When calculating the available volume, volume outside price monitoring bounds should be considered. (<a name="0012-POSR-020" href="#0012-POSR-020">0012-POSR-020</a>)
+- When calculating the available volume, volume outside the liquidity price range should not be considered. (<a name="0012-POSR-021" href="#0012-POSR-021">0012-POSR-021</a>)
+- Given a highly liquid market, if the network’s position is greater than `full disposal size`. The network must attempt to dispose `position * disposal fraction` at the next disposal step. (<a name="0012-POSR-022" href="#0012-POSR-022">0012-POSR-022</a>)
+- Given a highly liquid market, if the network’s position is less than or equal to `full disposal size`. The network must attempt to dispose of its full position at the next disposal step. (<a name="0012-POSR-023" href="#0012-POSR-023">0012-POSR-023</a>)
+- Given a highly liquid market, if the network’s `disposal fraction<1` and `full disposal size`=0, the network must still eventually dispose of its full position. (<a name="0012-POSR-024" href="#0012-POSR-024">0012-POSR-024</a>)
+- The network must never dispose more than `available volume  * max fraction of book side within liquidity bounds consumed` in a single order. (<a name="0012-POSR-025" href="#0012-POSR-025">0012-POSR-025</a>)
+- A network disposal order which generates trades must not affect the mark price. (<a name="0012-POSR-026" href="#0012-POSR-026">0012-POSR-026</a>)
+- A network disposal order can not cross with orders outside the liquidity price range. (<a name="0012-POSR-027" href="#0012-POSR-027">0012-POSR-027</a>)
+- A network disposal order can cross with orders outside price monitoring bounds but must not trigger a price monitoring auction. (<a name="0012-POSR-028" href="#0012-POSR-028">0012-POSR-028</a>)
+- A network disposal order which crosses multiple orders should generate multiple atomic trades. (<a name="0012-POSR-029" href="#0012-POSR-029">0012-POSR-029</a>)
+
 ### Network Profit and Loss
 
 - Given the network starts with no position and does not dispose any of it's position during the scenario: (<a name="0012-POSR-016" href="#0012-POSR-016">0012-POSR-016</a>)
@@ -41,6 +55,18 @@
   - The mark price moves to `90`, the network liquidates a distressed party with a long position of `1` (average entry price now equals `95`). The network should report a position of `2` and a realised and unrealised pnl of `0` and `-10` respectively.
   - The mark price moves to `60`. The network should report a position of `2` and a realised and unrealised pnl of `0` and `-70` respectively.
 
+- Given an empty insurance pool and the liquidation strategy `disposal time step = 5`, `disposal fraction = 0.5`, `full disposal size=0` and `max fraction of book side within liquidity bounds consumed = 0.01` during the below scenario: (<a name="0012-POSR-018" href="#0012-POSR-018">0012-POSR-018</a>)
+  - The mark price moves to 100, the network liquidates a distressed party with a long position of 2. The network should report a position of 2 and a realised and unrealised pnl of 0 and 0 respectively.
+  - Given the order book:
+    | side | price | size |
+    |------|-------|------|
+    | buy  | 90    | 1000 |
+    | sell | 110   | 1000 |
+  - The time updates to the next disposal time, the network reduces its position by 1. The network should report a position of 1 and a realised and unrealised pnl of -10 and 0 respectively.
+  - The time updates to the next disposal time, the network reduces its position by 1. The network should report a position of 1 and a realised and unrealised pnl of -20 and 0 respectively.
+  - Loss socialisation should be applied and the accumulated balance for all accounts should be unchanged.
+
+
 ## Summary
 
 Position resolution is the mechanism which deals with closing out distressed positions on a given market. It is instigated when one or more participant's margin account balance falls below their latest maintenance margin level.

protocol/0053-PERP-product_builtin_perpetual_future.md

@@ -345,3 +345,9 @@ It is possible to create a perpetual futures market which uses an oracle source
 
 It is possible to create a perpetual futures market which uses an oracle source (same as that used for funding) for the mark price determining the mark-to-market cashflows and that uses "time-weighted trade prices in over `network.markPriceUpdateMaximumFrequency` if these have been updated within the last 30s but falls back onto impact volume of notional of 1000 USDT" for the purpose of calculating the TWAP of the market price for funding payments (<a name="0053-PERP-035" href="#0053-PERP-035">0053-PERP-035</a>).
 
+When funding payments are due to the network party they are paid into the market insurance pool (<a name="0053-PERP-036" href="#0053-PERP-036">0053-PERP-036</a>).
+
+When funding payments are due from the network party they are paid from the market insurance pool (<a name="0053-PERP-037" href="#0053-PERP-037">0053-PERP-037</a>).
+
+If a market insurance pool does not have enough funds to cover a funding payment, loss socialisation occurs and the total balances across the network remains constant (<a name="0053-PERP-038" href="#0053-PERP-038">0053-PERP-038</a>).
+

protocol/features.json

@@ -208,8 +208,26 @@
       "0012-POSR-014",
       "0012-POSR-015",
       "0012-POSR-016",
-      "0012-POSR-017"
-
+      "0012-POSR-017",
+      "0012-POSR-017",
+      "0012-POSR-018",
+      "0012-POSR-019",
+      "0012-POSR-020",
+      "0012-POSR-021",
+      "0012-POSR-022",
+      "0012-POSR-023",
+      "0012-POSR-024",
+      "0012-POSR-025",
+      "0012-POSR-026",
+      "0012-POSR-027",
+      "0012-POSR-028",
+      "0012-POSR-029",
+      "0003-MTMK-015",
+      "0003-MTMK-016",
+      "0003-MTMK-017",
+      "0053-PERP-036",
+      "0003-MTMK-037",
+      "0003-MTMK-038"
     ]
   },
   "Passive liquidity": {