Create multis user update

.github/workflows/config/markdownlinkcheckignore.json

@@ -0,0 +1,12 @@
+{
+  "ignorePatterns": [
+    {
+      "_comment": "Finds /protocol AC codes e.g. #0001-MKTF-001",
+      "pattern": "^#[0-9]{4}-[A-Z]{4}-[0-9]{3}"
+    },
+    {
+      "_comment": "Finds /non-protocol-specs AC codes e.g. #0001-NP-LIQB-001",
+      "pattern": "^#[0-9]{4}-[A-Z]{2}-[A-Z]{4}-[0-9]{3}"
+    }
+  ]
+}

.github/workflows/config/markdownlint.json

@@ -5,5 +5,5 @@
     "commands-show-output": false,
     "no-bare-urls": true,
     "no-inline-html": false,
-    "no-hard-tabs": false,
-}
+    "no-hard-tabs": false
+}

.github/workflows/config/markdownlintignore

@@ -1,3 +1,2 @@
-glossaries/*
-non-protocol-specs/*
-user-interface/*
+user-interface/*
+LICENSE.md

.github/workflows/quality_check.yml

@@ -51,3 +51,18 @@ jobs:
           files: .
           config_file: .github/workflows/config/markdownlint.json
           ignore_path: .github/workflows/config/markdownlintignore
+
+  checkcodes:
+    name: "Approbation"
+    runs-on: ubuntu-latest
+    steps:
+      - name: "Check out"
+        uses: actions/checkout@v3
+
+      - name: "Run Check AC codes"
+        run: |
+          npx github:vegaprotocol/approbation check-codes --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}"
+
+      - name: "Run Check file names"
+        run: |
+          npx github:vegaprotocol/approbation check-filenames --specs="{./non-protocol-specs/**/*.md,./protocol/**/*.md}"

.gitignore

@@ -3,3 +3,9 @@
 .ipynb_checkpoints/
 .obsidian/
 .vscode/
+
+# Used by makefile to clone repos for approbation checks
+.build/
+
+# Used by ./spellcheck.sh
+dictionary.dic

glossaries/distributed-ledger-glossary.md

@@ -2,7 +2,7 @@
 
 ## ABI
 
-Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#EVM) will execute.
+Application Binary Interface - A JSON representation list of a smart contract's functions and arguments. It is used by wallets or clients to produce a transaction that interacts with a contract that exists on the the Ethereum chain - mapping function calls and parameters in to a bytecode form that the [EVM](#evm) will execute.
 
 ## Algorithm
 
@@ -12,7 +12,7 @@ A generally understood set of rules and calculations for solving a particular pr
 
 The process of verifying that an actor (person or machine) is who they claim they are.
 
-## Authorization
+## Authorisation
 
 The process of verifying that an actor (person or machine) is allowed to take an action.
 
@@ -47,7 +47,7 @@ Short for [Distributed Ledger Technology](https://en.wikipedia.org/wiki/Distribu
 
 ## Erasure Coding
 
-... TODO but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding).
+... `TODO` but see [here](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding).
 
 ## Eventual consistency
 
@@ -77,7 +77,7 @@ A rule for determining which fork is correct when faced with multiple possibly-v
 
 The [Greedy Heaviest-Observed Subtree](https://eprint.iacr.org/2013/881.pdf), a fork choice rule.
 
-## Hashchain
+## Hash chain
 
 ...
 
@@ -95,7 +95,7 @@ The amount of time before a system can achieve both consensus and finality; it's
 
 ## Longest Chain
 
-The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determinas a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finallity, i.e., every block can (theoretically) be undone.
+The longest chain approach is one way to solve consensus. It consists of a mechanism that (not necessarily uniquely) determines a leader that can propose the next block in the blockchain. If a node sees a longer chain than the one it knows, it uses that one as its new chain. Longest chain protocols do not offer finality, i.e., every block can (theoretically) be undone.
 
 ## MainNet
 
@@ -137,7 +137,7 @@ There are entire protocols ([Band](https://bandprotocol.com/), [Chainlink](https
 
 ## Reliable Broadcast
 
-A reliable broadcast assures that all receiving of a broadcasr nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675),
+A reliable broadcast assures that all receiving of a broadcast nodes receive the same set of messages, and that a message sent by an honest sender is received. ... see [here](https://www.semanticscholar.org/paper/Asynchronous-consensus-and-broadcast-protocols-Bracha-Toueg/130ce1bcd496a7b9192f5f53dd8d7ef626e40675),
 [here](https://www.shoup.net/papers/ckps.pdf) or [here](https://arxiv.org/pdf/1510.06882.pdf).
 
 ## State Channels
@@ -162,7 +162,7 @@ The amount of data that can be processed by a system in a given unit of time, e.
 
 ## Validators
 
-From the [Tendermint documentation](https://docs.tendermint.com/master/nodes/validators.html):
-> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key.
+From the [Tendermint documentation](https://docs.tendermint.com/v0.34/tendermint-core/validators.html):
 
-> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralized system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process.
+> Validators are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key.
+> Some Proof-of-Stake consensus algorithms aim to create a "completely" decentralised system where all stakeholders (even those who are not always available online) participate in the committing of blocks. [Tendermint](#tendermint) has a different approach to block creation. Validators are expected to be online, and the set of validators is permissioned/curated by some external process.

glossaries/staking-and-governance.md

@@ -6,21 +6,22 @@ This is a general term that may have specific meaning in different contexts. Veg
 
 ## Delegation
 
-This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of
-1) [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges.
-2) [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators.
+This is the process of assigning Vega tokens to validators on Vega chain. It is a two step process consisting of:
+
+1. [Association](#associate) which happens on the Ethereum blockchain by interaction with the Staking and Delegation bridges.
+1. [Nomination](#nominate) which happens on the Vega blockchain, assigning voting power to validators.
 
 ## Associate
 
-This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#Governance) and [Nominate](#Nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators).
+This allows a user with Vega Tokens on Ethereum to associate their tokens with a vega key so that the Vega key can participate in [Governance](#governance) and [Nominate](#nominate) their Stake to a [validator](distributed-ledger-glossary.md#validators).
 This is done by interaction with the Staking and Delegation bridge contracts (the vesting contract implements this functionality for Vega held by the vesting contract).
 
 ## Dissociate
 
 To opposite of association. Tokens can be dissociated via Ethereum staking and delegation bridge.
 Vega tokens are thus no longer associated to a Vega key (on either the Staking bridge or the Vesting contract, depending on how they were [Associated](#associate)). This means that in the future they can be associated to a different (or same) Vega key.
-This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#Epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch.
-Users are recommended to first [De-nominate](#De-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from.
+This action happens on Ethereum. The staking and delegation smart contract and does not know when an [Epoch](#epoch) ends meaning the relevant Vega key will not be due any rewards from that epoch.
+Users are recommended to first [De-nominate](#de-nominate) sufficient amount using their Vega key and interacting with the Vega chain. This way, when the Epoch ends they can dissociate without loosing any due rewards. Moreover they get to choose which validator they are removing their nomination from.
 
 ## Governance
 
@@ -44,4 +45,4 @@ A window of time, In which tokens that are staked on a are due a reward. If toke
 
 ## Self Staking
 
-That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#Nominate).
+That act of putting Vega tokens on a Validator node that you are running, as apposed to having tokens staked on a node via [Nomination](#nominate).