Merge branch 'cosmicelevator' into merge-cosmic-into-master

.github/workflows/add_pr_new_projects.yml

@@ -8,7 +8,7 @@ name: "Add IPRs To Project Board"
     types:
       - opened
 env:
-  GH_TOKEN: ${{ secrets.GH_NEW_CARD_TO_PROJECT }}
+  GH_TOKEN: ${{ secrets.PROJECT_MANAGE_ACTION }}
   PROJECT_ID: ${{ secrets.PROTOCOL_DESIGN_PROJECT_ID }}
   PR_ID: ${{ github.event.pull_request.node_id }}
   USER: ${{ github.actor }}

.github/workflows/quality_check.yml

@@ -19,7 +19,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: "Check out"
-        uses: actions/checkout@v3
+        uses: actions/checkout@v3.5.3
 
       - name: "Run Yamllint"
         uses: ibiqlik/action-yamllint@v3.1.1
@@ -31,10 +31,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: "Check out"
-        uses: actions/checkout@v3
+        uses: actions/checkout@v3.5.3
 
       - name: "Run PySpelling"
-        uses: rojopolis/spellcheck-github-actions@0.24.0
+        uses: rojopolis/spellcheck-github-actions@0.33.1
         with:
           task_name: Markdown
 
@@ -43,10 +43,10 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: "Check out"
-        uses: actions/checkout@v3
+        uses: actions/checkout@v3.5.3
 
       - name: "Run Markdownlint"
-        uses: nosborn/github-action-markdown-cli@v3.1.0
+        uses: nosborn/github-action-markdown-cli@v3.3.0
         with:
           files: .
           config_file: .github/workflows/config/markdownlint.json
@@ -57,7 +57,14 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: "Check out"
-        uses: actions/checkout@v3
+        uses: actions/checkout@v3.5.3
+
+      - name: Log in to the GitHub Container Registry
+        uses: docker/login-action@v2
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Log in to the GitHub Container Registry
         uses: docker/login-action@v2
@@ -68,8 +75,12 @@ jobs:
 
       - name: "Run Check AC codes"
         run: |
-          docker run -v $PWD:/workspace ghcr.io/vegaprotocol/approbation:main check-codes --specs="{/workspace/non-protocol-specs/**/*.md,/workspace/protocol/**/*.md}"
+          npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}"
 
       - name: "Run Check file names"
         run: |
-          docker run -v $PWD:/workspace ghcr.io/vegaprotocol/approbation:main check-filenames --specs="{/workspace/non-protocol-specs/**/*.md,/workspace/protocol/**/*.md}"
+          npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}"
+
+      - name: "Run Check Features"
+        run: |
+          npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json"

glossaries/trading-and-protocol-glossary.md

@@ -175,7 +175,9 @@ Parameters:
 
 ### Insurance Pool
 
-A store of capital instantiated with the order book into which fines are contributed.  It is utilised for financially covering [close out trades](#close-out-trades).
+[Market insurance pool](../protocol/0015-INSR-market_insurance_pool_collateral.md#market-insurance-pool): a store of capital instantiated with the order book into which fines are contributed.  It is utilised for financially covering [close out trades](#close-out-trades).
+
+[Global insurance pool](../protocol/0015-INSR-market_insurance_pool_collateral.md#global-insurance-pool): an insurance pool per given asset, not associated with any market. It receives part of remaining funds from insurance pool of the market using the same settlement asset. Funds can be transferred out of the global insurance pool using a governance initiated [transfer](../protocol/0028-GOVE-governance.md).
 
 ## L
 
@@ -185,7 +187,7 @@ The net riskiest composition of a trader's open positions and live orders.  For
 
 ### Liquidity Providers
 
-Liquidity providers commit a bond and place a special Liquidity Commitment that automatically maintains orders on the book for a specific market. In return, liquidity providers earn a [fee](#fees) for ensuring that markets always have open volume. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail.
+Liquidity providers commit a bond which specifies their SLA obligations. In return for meeting these the liquidity providers earn a portion of the trading [fees](#fees) from the market in which they operate. See [the liquidity provision spec](./../protocol/0044-LIME-lp_mechanics.md) for more detail.
 
 ## M
 

makefile

@@ -1,19 +1,19 @@
 # Set default to run all checks if none specified
 .DEFAULT_GOAL := all
 
-all: spellcheck markdownlint names codes references links clean
+all: spellcheck markdownlint names codes references links check-features clean
 
 # Check that all the specifications are named appropriately
 .PHONY: names
 names:
 	@$(MAKE) clone-sources
-	npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}"
+	npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}"
 
 # Count how many Acceptance Criteria each specification has
 .PHONY: codes
 codes:
 	@$(MAKE) clone-sources
-	npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}"
+	npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}"
 
 TEMP=./.build
 .PHONY:clone-sources
@@ -61,5 +61,10 @@ markdownlint:
 spellcheck:
 	@./spellcheck.sh
 
+# Checks for duplicated ACs in the features.json file
+.PHONY: check-features
+check-features:
+	npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json"
+
 clean:
 	rm -rf $(TEMP)

non-protocol-specs/0001-NP-LIQB-liquidity_providing_bots.md

@@ -7,21 +7,21 @@ At the moment bots on Vega run on certain markets to make them look "real".
 For that purpose they:
 
 1. Are given large amounts of collateral via faucets.
-1. Keep track of current spot or futures price on another exchange (at e.g. 30s, 5 min intervals)
+1. Keep track of current futures price on another exchange (at e.g. 30s, 5 min intervals)
 1. Post GTC limit orders randomly on both sides of the order book at random volumes using the above reference price as mid.
 
 This achieves the following: the price on the market looks "real" and there is volume for participants to trade.
 
 The downside is that if the bot is "unlucky" they can run out of even large amount of collateral and their orders / positions are liquidated. To avoid this they need regular collateral top-ups.
 
-From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../protocol/0038-OLIQ-liquidity_provision_order_type.md).
+From Flamenco Tavern onwards any market on Vega will need a committed liquidity provider, see [LP mechanics spec](../protocol/0044-LIME-lp_mechanics.md) to function. See also [LP order type spec](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transactiond).
 
 If a feature is marked as "optional" then the bot can be configured in such a way that it is not providing this functionality but still doing other tasks.
 
 The aim of this spec is bots that:
 
 1. submit a market proposal (optional) or connects to an existing market
-1. serve as a liquidity provider for the market by submitting the [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) (optional).
+1. serve as a liquidity provider for the market by submitting the [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) (optional).
 1. participate in an opening auction (optional)
 1. create markets that look real with more-or-less correct price by placing limit orders that "steer" the price up-or-down as appropriate (optional)
 1. manage their position in such a way so as to not require ever growing amount of collateral. This will mean changing the "shape" in the liquidity provision order and also being strategic about placing limit orders to steer the price. The bot can have an optional position limit.
@@ -53,7 +53,7 @@ The bot needs to be able to query Vega to know the risk model and parameters for
 
 This is only relevant if the option to submit a market proposal is enabled.
 
-The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it. They will also need to submit [liquidity shapes](../protocol/0038-OLIQ-liquidity_provision_order_type.md) but that will be treated below.
+The bot will read the required market proposal from a file (configuration option), decide if it has minimum LP stake in the right asset, check it's got enough vote tokens and then submit the proposal and vote for it.
 To decide that it will ask Vega for `assetBalance`, `quantum` for asset and `min_LP_stake_quantum_multiple` and proceed if `assetBalance x stakeFraction > min_LP_stake_quantum_multiple x quantum`
 
 It will then check whether it has enough collateral for maintaining the commitment but that will be described below as it applies below too.
@@ -212,8 +212,8 @@ Don't use any of the pseudocode above!
 
 ### Acceptance criteria
 
-1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md). (<a name="0001-NP-LIQB-001" href="#0001-NP-LIQB-001">0001-NP-LIQB-001</a>)
-1. Bot can connect to an existing market, submit an [LP order type](../protocol/0038-OLIQ-liquidity_provision_order_type.md) and then manage it's position as described above. (<a name="0001-NP-LIQB-002" href="#0001-NP-LIQB-002">0001-NP-LIQB-002</a>)
+1. Bot can submit a market proposal (optional), commit liquidity and then manage it's position as described above, see also [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction). (<a name="0001-NP-LIQB-001" href="#0001-NP-LIQB-001">0001-NP-LIQB-001</a>)
+1. Bot can connect to an existing market, submit an [LP order type](../0044-LIME-lp_mechanics.md#commit-liquidity-network-transaction) and then manage it's position as described above. (<a name="0001-NP-LIQB-002" href="#0001-NP-LIQB-002">0001-NP-LIQB-002</a>)
 1. Bot can participate in an opening auction placing orders around target price (set via parameters, see above).(<a name="0001-NP-LIQB-003" href="#0001-NP-LIQB-003">0001-NP-LIQB-003</a>)
 1. Can read a price target from external source and and places limit orders that "steer" the price up-or-down as appropriate and have the right `targetLNVol` using one of the methods above (note that this has to take into account other identical bots trying to do the same on the same market).(<a name="0001-NP-LIQB-004" href="#0001-NP-LIQB-004">0001-NP-LIQB-004</a>)
 1. Bot manages its position in such a way that it stays close to zero and starts placing market orders if configured maxima are breached.(<a name="0001-NP-LIQB-005" href="#0001-NP-LIQB-005">0001-NP-LIQB-005</a>)

non-protocol-specs/0012-NP-LIPE-liquidation-price-estimate.md

@@ -6,7 +6,7 @@ Provide an estimate of the price range at which the liquidation of a specified p
 
 ## Overview
 
-Provide a range of liquidation price, where the lower bound assumes no slippage in the [margin level calculation](../protocol/0019-MCAL-margin_calculator.md) and the upper bound assumes that the slippage cap is applied.
+Provide an estimated liquidation price range, where the lower bound assumes no slippage in the [margin level calculation](../protocol/0019-MCAL-margin_calculator.md) and the upper bound assumes that the slippage cap is applied.
 
 This amounts to carrying out the same computation twice, once with both linear and quadratic slippage factor set to `0` and once with the actual values used by the market for which the specified position is being considered.
 
@@ -27,13 +27,13 @@ where $V$ is the open volume (negative for a short position) and $S^\text{curren
 We assume margin is calculated as per continuous trading formula (as there are no closeouts in auctions) and that the slippage cap always applies, therefore we get:
 
 $$
-\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}),
+\text{collateral available} + V(S^{\text{liquidation}}-S^\text{current}) = S^{\text{liquidation}} (V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}) + V \cdot \text{constant},
 $$
 
-where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. Solving for $S^{\text{liquidation}}$ we get:
+where $\text{risk factor}$ is the long risk factor when $V>0$ and the short risk factor otherwise. The $\text{constant}$ is an optional arbitrary constant scaling with open volume added to the maintenance margin, e.g. the funding payment portion of the margin for [perpetual futures](../protocol/0053-PERP-product_builtin_perpetual_future.md#5-margin-considerations). Solving for $S^{\text{liquidation}}$ we get:
 
 $$
-S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V}
+S^{\text{liquidation}} = \frac{\text{collateral available}-V \cdot S^\text{current} - V \cdot \text{constant}}{V \cdot \text{linear slippage factor}+V^2 \cdot \text{quadratic slippage factor}+V \cdot \text{risk factor}-V}
 $$
 
 if the denominator in the above expression evaluates to $0$ the liquidation price is undefined and we return an error, otherwise we return the result floored at $0$ (as the negative price is not attainable for any of the currently supported products).

protocol/0001-MKTF-market_framework.md

@@ -157,7 +157,8 @@ struct InstrumentMetadata {
 }
 
 enum Product {
-  // maturity should be some sort of DateTime, settlement_asset is however we refer to crypto-assets (collateral) on Vega
+  // Oracle will include both info on how trading terminates and settlement data 
+  // settlement_asset is asset id
   Future { oracle: Oracle, settlement_asset: String },
   // EuropeanOption {},
   // SmartProduct {},
@@ -216,9 +217,30 @@ Market {
 }
 ```
 
+## Successor market
+
+If a market proposal, see [governance](./0028-GOVE-governance.md), designates an existing market as a *parent market* then it must have the same *product*, *settlement asset(s)* and *margin asset(s)*.
+It may propose new risk model and parameters, price monitoring parameters, position and market decimal places.
+It must provide oracle definitions, both for trading terminated and for settlement data.
+Each market can have exactly one market as a *successor* market.
+
+1. if there already is a market (possibly pending i.e. in opening auction, see [lifecycle spec](./0043-MKTL-market_lifecycle.md)) naming a parent market which is referenced in the proposal then the proposal is rejected.
+1. if there are two proposals naming the same parent market then whichever one gets into the pending state first (i.e. passes governance vote) becomes the successor of the named parent; the other proposal is cancelled with reason "parent market not available".
+
+
 ## Acceptance criteria
 
 - Details of a market's instrument must be available for each market through the API (<a name="0001-MKTF-001" href="#0001-MKTF-001">0001-MKTF-001</a>)
 - Details of a market's product must be available for each market through the API (<a name="0001-MKTF-002" href="#0001-MKTF-002">0001-MKTF-002</a>)
 - Details of a market's tradable instrument must be available for each market through the API (<a name="0001-MKTF-003" href="#0001-MKTF-003">0001-MKTF-003</a>)
 - Market framework can report position decimal places <a name="0001-MKTF-004" href="#0001-MKTF-004">0001-MKTF-004</a>
+- It is possible to designate a market as perpetual; this is visible via APIs in market data.
+  - GRPC <a name="0001-MKTF-005" href="#0001-MKTF-005">0001-MKTF-005</a>
+  - REST <a name="0001-MKTF-011" href="#0001-MKTF-011">0001-MKTF-011</a>
+  - GraphQL <a name="0001-MKTF-012" href="#0001-MKTF-012">0001-MKTF-012</a>
+- A market may have a "parent" market; the parent market is visible via APIs in the form of the `marketID` of the parent market. <a name="0001-MKTF-006" href="#0001-MKTF-006">0001-MKTF-006</a>
+- A market may have a "successor" market; the parent market is visible via APIs in the form of the `marketID` (or `proposalID`) of the successor market. <a name="0001-MKTF-007" href="#0001-MKTF-007">0001-MKTF-007</a>
+- A parent and successor markets must have the same:
+  - product <a name="0001-MKTF-008" href="#0001-MKTF-008">0001-MKTF-008</a>
+  - settlement asset(s) <a name="0001-MKTF-009" href="#0001-MKTF-009">0001-MKTF-009</a>
+  - margin asset(s). <a name="0001-MKTF-010" href="#0001-MKTF-010">0001-MKTF-010</a>