Update 0031-ETHB-ethereum_bridge_spec.md

.github/workflows/add_issue_new_projects.yml

@@ -8,7 +8,7 @@ name: "Add Issues 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 }}
   ISSUE_ID: ${{ github.event.issue.node_id }}
   USER: ${{ github.actor }}

.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/config/markdownlint.json

@@ -1,9 +1,15 @@
-
 {
     "default": true,
     "line-length": false,
     "commands-show-output": false,
     "no-bare-urls": true,
     "no-inline-html": false,
-    "no-hard-tabs": false
+    "no-hard-tabs": false,
+    "MD012": {
+        "maximum": 2
+    },
+    "MD024": {
+        "siblings_only": true
+    },
+    "MD049": false,
 }

.github/workflows/config/markdownlintignore

@@ -1,2 +1 @@
-user-interface/*
 LICENSE.md

.github/workflows/quality_check.yml

@@ -8,7 +8,8 @@ name: "Quality checks"
     branches:
       - master
       - cosmicelevator
-      - palazzomistero
+      - palazzo
+      - colosseo
 
 env:
   GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
@@ -19,7 +20,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/[email protected]
@@ -31,10 +32,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 +44,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,12 +58,30 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: "Check out"
-        uses: actions/checkout@v3
+        uses: actions/[email protected]
+
+      - 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
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
 
       - name: "Run Check AC codes"
         run: |
-          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}"
 
       - name: "Run Check file names"
         run: |
-          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}"
+
+      - name: "Run Check Features"
+        run: |
+          npx github:vegaprotocol/approbation check-features --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md,./protocol/**/*.ipynb}" --features="./protocol/features.json"

0000-TEMP-template-notes.md

@@ -0,0 +1,52 @@
+# 0000-TEMP decision notes
+
+## Context / Problem Statement 1
+
+|   Opened   | Last updated |    Status    |
+|:----------:|:------------:|:------------:|
+| DD/MM/YYYY |  DD/MM/YYYY  | open/resoved |
+
+Describe the context and problem statement...
+
+### Considered Options
+
+* Option 1...
+* Option 2...
+
+### Decision Outcome
+
+Chosen option: Option X, because... (include why paramemters are chosen, any dependancies and / or assumptions this decision is based upon)
+
+### Open risks
+
+* Risk 1 - details any risks or gaps that are not yet resolved
+
+### Limitations
+
+Are there any issues we wanted to address but could not e.g., A core rewrite or CometBFT limtitaion
+
+
+## Context / Problem Statement 2
+
+|   Opened   | Last updated |    Status    |
+|:----------:|:------------:|:------------:|
+| DD/MM/YYYY |  DD/MM/YYYY  | open/resoved |
+
+Describe the context and problem statement...
+
+### Considered Options
+
+* Option 1...
+* Option 2...
+
+### Decision Outcome
+
+Chosen option: Option X, because... (include why paramemters are chosen, any dependancies and / or assumptions this decision is based upon)
+
+### Open risks
+
+* Risk 1 - details any risks or gaps that are not yet resolved
+
+### Limitations
+
+Are there any issues we wanted to address but could not e.g., A core rewrite or CometBFT limtitaion

README.md

@@ -7,7 +7,7 @@ This repository contains specifications and RFCs for future changes to the syste
 In order to ensure that there is a clear view on the specification of the protocol, both at the version in mainnet and the version being developed in testnet, the following branching is used:
 
 - `master` branch details the specification of the protocol in mainnet (from Alpha Mainnet onwards)
-- `cosmicelevator` branch is the milestone grouping of features being developed AFTER Alpha Mainnet
+- `cosmicelevator` branch is the milestone grouping of features being developed AFTER Alpha Mainnet. As features are deployed to mainnet by the validators the relevant spec changes will be merged into the `master` branch.
 - Further milestone branches will be created as development progresses and will be updated in this `README.md`
 
 To find out more see the [The specification lifecycle](WORKFLOW.md#the-specification-lifecycle)

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/0007-NP-SNTP-sweetwater_signed_netparams.md

@@ -3,7 +3,7 @@
 There are parameters within Vega that influence the behaviour of the system:
 
 - some are set in genesis block but fixed once network is running,
-- while others are changeable by on-chain [governance](../protocol/0028-GOVE-governance.md) but initialised to genesis values during network launch. For more info see [network paramters](../protocol/0054-NETP-network_parameters.md)
+- while others are changeable by on-chain [governance](../protocol/0028-GOVE-governance.md) but initialised to genesis values during network launch. For more info see [network parameters](../protocol/0054-NETP-network_parameters.md)
 
 On [Sweetwater (Restricted Mainnet) Release](https://github.com/orgs/vegaprotocol/projects/114) Vega Team wishes to control how certain parameters are initialised while letting validators change others as they see fit.
 As the process of decentralisation progresses Vega Team the number of such parameters will be reduced.
@@ -22,8 +22,8 @@ The values to be specified as a PR against ??? repo.
 
 | Name                                                        | Comment                                                            | Suggested value (optional) |
 |-------------------------------------------------------------|:------------------------------------------------------------------:| :-------------------------:|
-| `min number of validators` (not in sweetwater)              | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) |                            |
-| `validator min balance`                                     | Not in [network paramters](../protocol/0054-NETP-network_parameters.md) | 3000 VEGA                  |
+| `min number of validators` (not in sweetwater)              | Not in [network parameters](../protocol/0054-NETP-network_parameters.md) |                            |
+| `validator min balance`                                     | Not in [network parameters](../protocol/0054-NETP-network_parameters.md) | 3000 VEGA                  |
 | `governance.proposal.updateNetParam.requiredMajority`       | So that what is set in genesis cannot be changed too easily        | 0.5                        |
 | `governance.proposal.updateNetParam.requiredParticipation`  | So that what is set in genesis cannot be changed too easily        | 0.5                        |
 | `validators.epoch.length`                                   | Rewards currently make an assumption on epoch length, best fix it. | 1 day                      |