Signing transactions on Vega
How are transactions signed on Vega?
In order to submit signed transactions to a Vega node, you need to connect to a Vega Wallet server, which handles your key pairs for you and signs transactions using a specified key pair.
Alongside a self-hosted, local wallet for testnet demonstration purposes, Vega offers a centralised wallet server. The URL for this is https://wallet.testnet.vega.xyz/api/v1. (If you’re using the self-hosted, local wallet, you can get the URL by running your wallet.) To verify if the Vega hosted wallet service is online use https://wallet.testnet.vega.xyz/api/v1/status.
To check connectivity, use its status endpoint.
On mainnet, everyone will need to run their own private wallet server: Your private keys, under your control, your responsibility. Each wallet file stored on disk is encrypted with that wallet’s passphrase. Security and backups will be the responsibility of each individual.
Since neither Vega nodes nor the Vega team have access to anyone’s private keys, they are not able to backup or restore lost keys, and not able to modify signed transactions.
What happens to a transaction when it is submitted to a node?
When transactions (e.g.
AmendOrder) are submitted to a node,
they are first shared among all other nodes. Invalid transactions are
discarded, and valid transactions are sequenced deterministically. Nodes propose
a block, then reach agreement by voting. Once the block is agreed, the
transactions are finally on the blockchain.
What is the difference between a transaction ID and a transaction reference?
When a transaction is submitted, it is assigned a reference before it is included in a block, i.e. when it is pre-consensus. The reference can be used to check on the progress of a transaction.
A valid transaction has an ID assigned as it is included in a block, i.e. when it is post-consensus.
What is the difference between a pre-consensus transaction and a post-consensus one?
A pre-consensus transaction, having not yet been included in a block, has not yet “happened”. Conversely, a post-consensus transaction has been included in a block, and has “happened”.
For example, a pre-consensus
SubmitOrder has not yet been executed, so it
hasn’t yet been added to the order book, it hasn’t yet been filled-or-killed,