chore: fix CI errors

protocol/0032-PRIM-price_monitoring.md

@@ -4,7 +4,7 @@
 
 The dynamics of market price movements are such that prices don't always represent the participants' true average view of the price, but are instead artefacts of the market microstructure: sometimes low liquidity and/or a large quantity of order volume can cause the price to diverge from the true market price. It is impossible to tell at any point in time if this has happened or not.
 
-As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent. 
+As a result, we assume that relatively small moves are "real" and that larger moves might not be. Price monitoring exists to determine the real price in the latter case. Distinguishing between small and large moves can be highly subjective and market-dependent.
 We are going to rely on the risk model to formalise this process. Risk model can be used to obtain the probability distribution of prices at a future point in time given the current price. A price monitoring trigger can be constructed using a fixed horizon and probability level.
 To give an example: get the price distribution in an hour as implied by the risk model given the current mid price, if after the hour has passed and the actual mid price is beyond what the model implied (either too low or too high) with some chosen probability level (say 99%), then we'd characterise such market move as large.  In general we may want to use a few such triggers per market (i.e. different horizon and probability level pairs). The framework should be able to trigger a price protection auction period with any valid trading mode.
 We're also going to allow specifying triggers directly as the maximum valid moves with respect to the reference price. In that case the `maxUpMoveFactor`, `maxDownMoveFactor` can be specified for a given horizon, such that a price is considered valid as long as it's in the range `[reference_price(horizon) * maxDownMoveFactor, [reference)price(horizon) * maxUpMoveFactor]`, where `[reference_price(horizon)` is the reference price corresponding to the specified horizon - obtained in exactly the same way as in the case of a model-based trigger.
@@ -47,6 +47,7 @@ Likewise, pre-processing transactions will be needed as part of the [fees spec](
 #### Market
 
 ##### Model-based triggers
+
 - `priceMonitoringParameters` - an array of more price monitoring parameters with the following fields:
   - `horizon` - price projection horizon expressed as a year fraction over which price is to be projected by the risk model and compared to the actual market moves during that period. Must be positive.
   - `probability` - probability level used in price monitoring. Must be in the [0.9,1) range.
@@ -153,4 +154,5 @@ to the risk model and obtains the range of valid up/down price moves per each of
 - For all available mark-price calculation methodologies: the mark price update candidate gets rejected if it violates the price monitoring engine bounds. (<a name="0032-PRIM-040" href="#0032-PRIM-040">0032-PRIM-040</a>)
 - Model-free triggers can be added to the market at creation time along with regular triggers. (<a name="0032-PRIM-041" href="#0032-PRIM-041">0032-PRIM-041</a>)
 - Model-free triggers can be added to the market during market update along with regular triggers. (<a name="0032-PRIM-042" href="#0032-PRIM-042">0032-PRIM-042</a>)
-- Adding a model-free trigger with `maxUpMoveFactor = 1.1` and `maxDownMoveFactor = 0.95` results in bonds with max valid price of `110` and min valid price of `95` when a reference price is `100`. When time passes so that the reference price becomes `90` then the resulting max valid price is `99` and min valid price is `85.5`. Violating any of these bounds results in an auction. (<a name="0032-PRIM-043" href="#0032-PRIM-043">0032-PRIM-043</a>)
+- Adding a model-free trigger with `maxUpMoveFactor = 1.1` and `maxDownMoveFactor = 0.95` results in bonds with max valid price of `110` and min valid price of `95` when a reference price is `100`. When time passes so that the reference price becomes `90` then the resulting max valid price is `99` and min valid price is `85.5`. Violating any of these bounds results in an auction. (<a name="0032-PRIM-043" href="#0032-PRIM-043">0032-PRIM-043</a>
+)

protocol/0042-LIQF-setting_fees_and_rewarding_lps.md

@@ -472,27 +472,29 @@ Example 1, generated with [supplementary worksheet](https://docs.google.com/spre
 ### Explicit instantaneous liquidity scoring function
 
 When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows:
+
 - buy-side:
-   - reference: BEST_BID
-   - points: [(0,0.25),(1,0)]
-   - interpolation strategy: FLAT
+  - reference: BEST_BID
+  - points: [(0,0.25),(1,0)]
+  - interpolation strategy: FLAT
 
 - sell-side:
-   - reference: BEST_ASK
-   - points: [(0,0.35),(1,0)]
-   - interpolation strategy: FLAT
+  - reference: BEST_ASK
+  - points: [(0,0.35),(1,0)]
+  - interpolation strategy: FLAT
 
 then all the buy orders deployed at `BEST_BID` get an instantaneous liquidity score of `0.25`, all sell orders deployed at `BEST_ASK` get a score of `0.35` and all other orders get a score of `0`. Updating the risk model has no effect on those scores. (<a name="0042-LIQF-095" href="#0042-LIQF-095">0042-LIQF-095</a>)
 
 When market is setup with [explicit instantaneous liquidity scoring function](./0091-ILSF-instantaneous_liquidity_scoring_funcion.md) as follows:
+
 - buy-side:
-   - reference: MID
-   - points: [(0,0.4),(200,0.2)]
-   - interpolation strategy: FLAT
+  - reference: MID
+  - points: [(0,0.4),(200,0.2)]
+  - interpolation strategy: FLAT
 
 - sell-side:
-   - reference: MID
-   - points: [(0,0.5),(300,0.3)]
-   - interpolation strategy: FLAT
+  - reference: MID
+  - points: [(0,0.5),(300,0.3)]
+  - interpolation strategy: FLAT
 
 the decimal places for the asset are, the decimal places for the market are and tick size is. Then buy orders pegged to MID with an offset of `100` get a score of `0.3`, orders with offset of `200` get a score of `0.2` and orders with and offset of `300` also get a score of `0.2`. Sell orders pegged to MID with an offset of `150` get a score of `0.4`, orders with an offset of `300` get a score of `0.3` and orders with an offset of `400` also get a score of `0.3`. Updating the risk model has no effect on those scores. (<a name="0042-LIQF-096" href="#0042-LIQF-096">0042-LIQF-096</a>)

protocol/0091-ILSF-instantaneous_liquidity_scoring_funcion.md

@@ -6,16 +6,17 @@ While by default the market uses probability of trading to calculate the [liquid
 
 ## Specifying the function
 
-The function gets specified sparately for each side of the book as:
+The function gets specified separately for each side of the book as:
 
 * `reference`: reference point to which offset from each `point` is to be applied. It can be `MID` or `BEST BID` / `BEST ASK` depending on the side of the book for which the function is specified.
-* `points`: collection of `(offset, value)` tuples prodiving a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)).
-* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `FLAT` resulting in a piecewise-constant function (starting from a lowest offest the value specified for it is assumed to prevail until the next offset is reached) or `LINEAR` resulting in a linear interpolation between points.
+* `points`: collection of `(offset, value)` tuples providing a discrete representation of the function. Tuple `(10,0.4)` means that the value of the instantaneous liquidity function for a price level of reference point with an offset of `10` is `0.4` (specified in the same way as for [pegged orders](./0037-OPEG-pegged_orders.md)).
+* `interpolation strategy`: prescribes a way in which price levels not covered by `points` should be calculated. Should be either `FLAT` resulting in a piecewise-constant function (starting from a lowest offset the value specified for it is assumed to prevail until the next offset is reached) or `LINEAR` resulting in a linear interpolation between points.
 
-Flat extrapolation is always carried out, that is when price level greater than point with a highset offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified.
+Flat extrapolation is always carried out, that is when price level greater than point with a highest offset or smaller than that with a lowest offset needs to be scored we use the nearest values that's been specified.
 
 Validation:
+
 * same as pegged orders for `reference` and `offset`,
 * at least two `points` must be specified.
 
-When liquidity scoring function is not specified [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) should be used for [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) calculation by default. It should also be possible to change it back to a `nil` value later on in market's life to stop using the function prescibed before and return to the default behaviour.
+When liquidity scoring function is not specified [probability of trading](./0034-PROB-prob_weighted_liquidity_measure.ipynb) should be used for [liquidity score](./0042-LIQF-setting_fees_and_rewarding_lps.md#calculating-the-instantaneous-liquidity-score) calculation by default. It should also be possible to change it back to a `nil` value later on in market's life to stop using the function prescribed before and return to the default behaviour.

wordlist.txt

@@ -220,6 +220,7 @@ permissioned
 permissionless
 PERP
 perps
+piecewise
 PME
 PnL
 PoS