Question 1

What is VTHO?

Accepted Answer

VTHO (VeThor) is VeChainThor’s fuel token: accounts use it to pay for the computing resources consumed when sending transfers or executing smart contracts. It is not a substitute version of VET, but the transaction-cost side of the dual-token model. VTHO is a built-in VIP-180 fungible token with 18 decimal places. Its genesis-block supply was zero, and it is produced later under protocol rules. VTHO should therefore be understood by separating newly issued tokens, tokens burned as transaction fees, and fees actually paid by transaction participants.

Question 2

What is the difference between VTHO and VET?

Accepted Answer

VET and VTHO have different roles: VET is the other core asset in VeChainThor’s dual-token model, while VTHO is fuel for on-chain transfers and contract execution. A transaction consumes VTHO; holding VET does not itself waive transaction fees. They are also linked through network incentives. After Hayabusa, locked/staked VET is the basis on which the protocol calculates VTHO issuance and participation rewards, but VET is not VTHO that can directly settle Gas. Holding VET without participating in staking and delegation under the current mechanism does not automatically earn VTHO issuance rewards.

Question 3

How are VTHO transaction fees calculated?

Accepted Answer

VTHO transaction fees depend on the Gas actually used and the applicable per-Gas price. VeChainThor currently supports both legacy and dynamic-fee transactions, so one pricing rule cannot describe both. Gas measures computational resources; a transaction can contain multiple clauses, so total Gas also reflects each clause’s type, data, and virtual-machine execution cost. E_con = p × G E_con is VTHO consumed, G is actual Gas used, and p is the applicable per-Gas price. For type 0x51 dynamic-fee transactions, p consists of the block’s baseFee and the actual priority fee. The user sets maxFeePerGas and maxPriorityFeePerGas; base fee must be paid, while the actual priority fee is the lower of maxPriorityFeePerGas and maxFeePerGas minus base fee. Unused headroom is returned. Legacy transactions instead use a fixed-fee model: the sender sets price through gasPrice/GasPriceCoef-related fields, and optional transaction-level proof of work affects additional rewards for the block producer. Fee-market terms such as baseFee, maxFeePerGas, and maxPriorityFeePerGas are therefore not shared calculation parameters for every VTHO transaction.

Question 4

What happens after paying a VTHO transaction fee?

Accepted Answer

For dynamic-fee transactions, VTHO paid consists of a base fee and a priority fee. The protocol determines the base fee dynamically by block; it is the minimum required for a valid transaction and is permanently burned. The priority fee is an additional amount paid to encourage validator inclusion and goes to the validator of that transaction’s block. Thus, dynamic-fee payments do not all go to one party: base fees reduce existing VTHO, while priority fees are validator income. The base fee varies with the block fee market, and the priority fee is limited by both the user’s total-fee cap and priority-fee cap. Legacy transactions use a different fixed-fee model and do not follow these base-fee burn and priority-fee allocation rules.

Question 5

Why does VTHO supply change?

Accepted Answer

VTHO has no fixed maximum supply. Its supply changes through issuance minus burning: the protocol creates new VTHO by block, while the base fee of dynamic-fee transactions burns existing VTHO. Priority fees merely move from the payer to the block validator and neither add nor burn supply. After Hayabusa, annual issuance depends on VET collectively locked/staked by validators and delegators, rather than passive production at a fixed rate for every VET holder. The official documentation gives: VTHO_gen = 1200 × 64 × √VET_staked VTHO_gen is annual generation; VET_staked is total VET staked by validators and delegators when blocks are produced; 1200 and 64 are protocol scaling constants. The square-root relation means more total stake raises issuance, but each additional unit adds less incremental issuance. More transaction use can increase dynamic-fee base-fee burning; it does not mean the protocol automatically issues more VTHO.

Question 6

Which major upgrades changed VTHO’s mechanism?

Accepted Answer

VTHO’s rules underwent two connected major changes. Galactica introduced the dynamic-fee structure: base fees of dynamic-fee transactions are burned and priority fees go to block validators, separating network-use fees into burning and validator income. It does not replace still-supported legacy fixed-fee transactions. Hayabusa then moved VeChainThor from PoA to DPoS and rewrote VTHO reward sources and eligibility. Before it, holding VET could generate VTHO under the old rules; afterwards, issuance depends on network-wide staked VET and block rewards flow to validators and delegators. The first change altered how dynamic-transaction fees form and are allocated; the second changed who receives newly issued VTHO and through what participation.

Question 7

How can VET be used to participate in VTHO rewards?

Accepted Answer

Under the post-Hayabusa mechanism, protocol VTHO rewards require staking participation rather than simply keeping VET in an address. Delegators can stake VET in StarGate, receive an NFT representing that stake, and, after a maturation period, delegate to a validator. Validators operate block-production infrastructure and must stake 25 million VET. Protocol block rewards are shared by validators and delegators: official material states 70% for delegators and 30% for validators. A delegator’s actual reward also depends on stake size, frequency of blocks produced by the chosen validator, that validator’s stake composition, and network-wide total stake. This rewards participation in network security, not a fixed interest rate on all VET holdings.

Question 8

Must I hold VTHO myself to use VeChainThor?

Accepted Answer

Whether users must provide VTHO themselves depends on who is designated as the transaction’s Gas payer. In an ordinary self-paid transaction, the paying account needs sufficient VTHO; if its balance is insufficient, execution fails rather than executing only partially. VeChainThor also supports contract fee sponsorship. A contract administrator can configure users allowed to call the contract without direct payment, a credit plan, and a sponsor. The user may not be charged directly, but VTHO is still consumed and paid by the current sponsor. If that sponsor lacks energy, the administrator may select another sponsor candidate, or the user may need to pay. “Gas-free” therefore describes a payment arrangement contingent on a specific contract and sponsor balance, not the absence of VTHO consumption.

VeThor (VTHO) Price