HowTo VeChain Blockchain — Part 2

What’s a transaction made of?

(Links to all parts at the bottom)

This part will focus on the different elements of a transaction. With all the options explained.

What is a transaction on VeChain Thor made of?

To illustrate this, we will use the wallet created in Part 1 and send 1 VET to the genesis address 0x0000000000000000000000000000000000000000. But before that, lets take a look at the balance of the wallet — just before sending 1 VET. This wallet cointains 500 VET and 5000.05 VTHO.

VeChain wallet with 500 VET and 5000 VTHO before sending 1 VET.

After the transaction is send, the wallet contains 499 VET and 4979.05 VTHO. So the wallet has “lost” 1 VET and 21 VTHO. VTHO is the 2nd token on the VeChain network and is used to pay the gas costs for a transaction.

VeChain wallet with 499 VET and 4979.05 VTHO

Now lets look at the transaction itself. The easiest way to do so is a blockexplorer. We can either use will use the official explorer from VeChain for Testnet or my own implementation of insight at .

This is the exact link to the transaction above:

This link contains a lot of information about the transaction, but how does a transaction look befor its send to the blockchain?

VeChain transaction on testnet.

Create a transaction for the VeChain blockchain from scratch

body = {
"chainTag": 39,
"blockRef": '0x00634a0c856ec1db',
"expiration": 720,
"clauses": [
"to": '0x0000000000000000000000000000000000000000',
"value": 1000000000000000000,
"data": '0x'
"gasPriceCoef": 0,
"gas": 21000,
"dependsOn": None,
"nonce": 12345678

This code block is the equivalent to the transaction made with Sync earlier. It transfers 1 VET to 0x0000000000000000000000000000000000000000.

There are a lot of variables in this block that need explanation:

ChainTag: The VeChain doc says “Chain tag is the last byte of the genesis block ID”. This value makes a transaction to qualify for mainnet or testnet (or solo or custom network). Since this transaction should be valid for testnet, we need to find the last byte of the genesis block (first block, means block 0) from testnet. The block ID is shown in HEX, so the last byte is “27” in HEX. Converted to decimal, this equals to “39”.

Genesis block on VeChain Testnet

BlockRef: The VeChain transaction model says “BlockRef stores the reference to a particular block whose next block is the earliest block the current transaction can be included”. So this value needs to be determined right befor the transaction is send to the blockchain, because its a time critical value. The BlockRef of the transaction of 1 VET at the beginning of this part is “0x0063482e3d881777” and is simply the first 8 bytes (in HEX) or the first 18 characters (in ASCII) of the last know block (Block 6506542).

BlockRef in a transaction on VeChain blockchain.

To get the current best BlockRef, open the blockexplorer, click on the latest block and copy the first 18 characters of the Block ID (including the leading 0x).

Marked BlockRef for Block 6506542

Expiration: The VeChain transaction model says “Expiration stores a number that can be used, together with BlockRef, to specify when the transaction expires”. This is simply the number (in decimal) of blocks where the transaction is valid. In the transaction of 1 VET at the beginning, the transaction is valid for 18 blocks after block 6.506.542 (6.506.542 + 18 = 6.506.560). If the transaction cannot be written into a block to this point, it will be rejected and will not be written to the blockchain at all.

Clauses: The concept of clauses will be explained in detail in a later part. For this part, the important thing is, that this cointains the actual information that should be written to the blockchain.

"to": '0x0000000000000000000000000000000000000000',
"value": 1000000000000000000,
"data": '0x'

The “to” field is the destination address for the transaction.
The “value” field defines how much VET will be transfered. VET has 18 decimals places (VeChain reference), so every value needs to be multiplied by 1000000000000000000.
The “data” field is optional for a VET transaction. It is meant for contract interaction but you could send data (encoded in HEX) with your VET. To keep this simple, “data” will be empty (0x = no data at all). Adding data to a transaction will increase the gas cost and as a consequence the VTHO cost as well.

GasPriceCoef: The Gasprice coefficient is defined in the VeChain transaction model and is a value between 0 and 255 (in decimal). The higher the value the more VTHO your transaction will cost. This is to incentivise Authority Masternodes to put your transaction into a block first. The calculation is defined here. The 1 VET transaction had a cost of 21000 gas and a GasPriceCoef of 0 ( 21000 + 21000*(0/255) ).
Setting the GasPriceCoef to 128 would incrase the gas costs to 31541 ( 21000 + 21000*(128/255) ) and setting it to 255 would increase the gas costs to 42000 (21000 + 21000*(255/255) ).

Gas: The VeChain transaction model says “maximum amount of gas allowed to pay for the transaction” and there is also a calculation formula. A detailed calculator will be shown in a later part; for a simple VET transaction the calculation is 5000 gas as a base + 16000 gas for a non-contract-creation clause = 21000 gas. If the transaction exceeds this gas, it will be reverted (but still consume the gas, thus VTHO).
At the point of writing, 1000 gas = 1 VTHO (see bi-token design: “Currently, we set Pbase = 1 VTHO /1000 gas.”)

DependsOn: The VeChain transaction model says “ID of the transaction on which the current transaction depends”. This is optional to chain transactions and will be eventually explained later. For now, it will always be “None”.

Nonce: The VeChain transaction model says “Moreover, we can always adjust the Nonce field to result in a new ID. In contrary to Ethereum, VeChainThor users can easily assemble multiple transactions sent from the same account with different IDs, which means that they could be sent off at the same time and would be processed by VeChainThor independently”.
This is a 8-digit (decimal) value, that makes every transaction unique (as long as the nonce changes). This way you could produce 10 of the “same” transactions and put them all into one block.

So much for the theory, in the next part an actual transaction will be written to the testnet.