Blockchain Transactions & Signing

How blockchain transactions work and how they're signed

Interacting with Aver

When you interact with Aver (for example, placing or canceling an order), you are sending a transaction to the blockchain which contains the information necessary to describe your order or desired action.

Each transaction contains one-or-more instructions, each of which correspond to a pre-written smart contract (or 'program') routine on the blockchain (e.g. place_order, cancel_order are distinct instructions with corresponding program routines).

A transaction can contain one-or-more instructions. For example, the first trade made on Aver might involve several steps, which can be optimized to be executed within the same transaction:

• Create a user-platform level account to record interactions

• Create a user-market level account to record positions and orders in this market

• Place the order

The number of instructions that can be included will depend on a number of factors such as:

• The accounts involved in the instructions; and

• The complexity/expense of the processing to be performed

Starting out, it is advised to leverage the approach implicit in the Aver SDKs, though this may be a point of optimization for some integrators - for example, optimizing bulk placement or cancellation of orders.

To interact with Aver, you do not need to build any blockchain programs or smart-contracts. You simply need to assemble client-side logic to assemble, sign and send an instruction (or set of instructions) to the Solana blockchain via RPC nodes.

For example, when you place an order, you send an instruction corresponding to the pre-written place order routine including all of the information required to place the order (market public key, your public key, price, amount etc.)

This may seem like a lot of information to gather and assemble, but don't worry - the values are either derivable or can be easily sourced from the Aver API.

The SDK is well equipped to build and send these instructions, requiring only the type of inputs that similar web2 interactions would require (i.e. specifying the side, quantity and price of an order).

The Solana blockchain network attempts to execute the program as per these instructions, and provides a response indicating whether the transaction has been successfully executed or not. The result of a successful execution is that the blockchain state has been updated (for example, a new order has been placed on the orderbook and a participant's positions updated to reflect).

All transactions on Solana are atomic - meaning if even one instruction within a transaction succeeds/fails, all other instructions within the same transaction also succeed/fail.

Signing a transaction

When sending a transaction, you will often need to sign it. A signature is proof that the wallet which has permission to allow certain actions has approved it.

For example, if you were trying to deduct funds from a wallet to fund a trade, it would be necessary to validate that the wallet owning these funds has authorized this transaction.

When placing orders, tokens will need to be removed from corresponding accounts, which requires a signature. Similarly, cancelling an order or otherwise taking actions which could impact on the wallet owner's positions, balances or exposures would all required evidence of the wallet owner's authorization.

This may sound like a lot of steps, but it is synonymous to API keys or a username-password authorization on a Web2 exchange.

A signature is generated client-side for a specific transaction using your private key. The network can verify whether a signature truly came from this wallet, but it is not possible for the validator (or anyone else) to generate this signature or solve for the private key without having access to the keypair.

You can read more information here.