Skip to main content
Version: pre-release (v0.79)

Before you start

Resources: Developing

This section is part of a series on the topic of Development.

Docs:

Other resources:

This page describes what you need to know before you start developing with Vega: How authentication and transactions work, and the versioning process.

Decentralised network​

The Vega protocol software provides the backbone to form a network specifically built to support proposing and creating markets for trading financial products. Markets can be proposed and voted on through governance by tokenholders.

There are several different servers you'll need to interact while working with a network. Data will generally be received from one service and transactions will be sent to another using data nodes. See the data flow section on the architecture page for more info.

Viewing the code​

Explore the code by visiting the Vega Protocol GitHub organisation, and more specifically the Vega repo for core, data node and API code.

Authentication​

The software is built such that when you request data from a public, validator-run data node, such as through a query, you don't need to authenticate nor do you need an API token.

However, specific data node operators may require you to authenticate, and if this is the case you will need to refer to the provider's documentation for details of how to do so.

If you want to send transactions to a network running the Vega software, you need a Vega wallet to sign the transaction using your Vega keys.

However, if you want to integrate the official Vega wallet implementation with your web application or script, you'll need to use the connection layer built into the wallet API, and a wallet API authentication token.

Go deeper

Wallet API guides: See the wallet API documentation for more on authentication tokens.

Sending transactions to the chain​

When sending transactions, you'll need a Vega wallet with at least one keypair. You'll need to have your Vega public key (also known as a party ID) to hand, as well as the relevant transaction data, in order to submit your transaction.

If you have a client that you want use to send a transaction using the Vega wallet API, it will construct the transaction in JSON and pass it to the wallet. The wallet performs a client-side proof-of-work calculation, signs the transaction and forwards it to a node on the network before it is added to a block. It is also possible to have the wallet sign a transaction without sending it, if needed. Alternatively, you can build the signer into your client, though you'll need to account for the PoW calculations.

Go deeper

Transaction hashes​

Once a transaction has been successfully submitted to the chain, you receive the transaction's hash from the wallet. A transaction hash is a unique identifier for the transaction, and can be used to find that transaction and check its status on a block explorer. Note that a transaction can only be seen by the block explorer once it's been processed by the network and been propagated to the node on the block explorer backend.

Depending on transaction type, most will be given a deterministic ID, which can be derived by calculating the SHA-3-256 hash of the signature in the transaction, and is specific to the object the transaction creates once it's processed.

You can use that object-specific ID with the relevant endpoint to then get richer, more detailed information about it.

The following IDs are derived deterministically:

  • Chain event
  • Asset transfer
  • Order submission
  • Order amendment
  • Order cancellation
  • Withdrawal
  • Governance proposal
  • Liquidity provision
  • Liquidity provision amendment
  • Batch market order

For example, a submitted order will receive an order ID once the transaction to submit the order has been accepted into a block. You can use the REST endpoint to get order by ID.

Versioning​

Network software versions

You can switch between documentation of the networks' software versions in the top menu bar on every page.

Once the latest code is prepared for a release, it's deployed to a testnet, where the latest features and updates can be trialled. When and if the validator node operators agree that a new version contains changes that should be accepted into mainnet, and is sufficiently stable, they will deploy the code on their nodes and vote on chain to signal readiness to upgrade.

Find out what version a data node is running with the data node info endpoint.

Breaking APIs changes go through a deprecation cycle, and are announced in the summary for each release.

The documentation on this site covers the core software version running on the Vega Fairground testnet, as well as the release-ready version of the software. Check which version's documentation you're viewing (and switch between them) by referring to the top navigation bar on each page.

See the releases page for a summary of each software release and links to the full changelog on GitHub.

Next steps​

To learn more about developing with Vega software, read through the following topics.

  • Using the APIs: All the API frameworks and smart contracts in one place, plus tips on connecting.
  • Architecture: Explore the architecture of the Vega protocol.
  • Building blocks: The basic building blocks you should know about.
  • Tutorials: Each tutorial includes info about the protocol that you need to use the guide, as well as instructions on how to interact with scripts, API calls, or other code.