Velas native application model is aiming for high performance by splitting its modifiable state across multiple accounts. While this allows Velas to process transactions in parallel on a single shard, it also introduces complications for ordinary DApps developers. Additionally, many dApps already rely on Solidity and the Ethereum technology stack. These two reasons slow down the adoption of non-EVM ecosystems.
For the developer's convenience, we at Velas introduced a full hybrid of Solana (eBPF) VM and Ethereum VM.
Velas chain supports EVM transaction execution via wrapping it into a regular native transaction with an instruction invoking EVM Program.
To provide full compatibility to EVM dApps and other wallets/tools built on the Ethereum stack, velas node supports Ethereum JSON-RPC API. For that reason, the nodes create virtual EVM blocks that contain all the EVM transactions processed by the network and are available via ETH RPC methods (
eth_getBlockByNumber, and etc)).
For more information about EVM RPC visit evm-rpc page.
Please note, Velas network does not create empty EVM blocks. Instead, it creates blocks on-demand, when there is an EVM transaction(s) processed by the network. Thus, expect EVM blocks to have different time gaps in between (in the case of low network activity). For this reason, do not rely on
block.number as the source of time, use
EVM transaction finality
In classic PoW chains (Bitcoin, Ethereum 1.0) a block (with its transactions) becomes final (aka irreversible) after waiting for some number of blocks created on top of it (block confirmations). In PoS chains, finality is usually achieved by waiting for 2/3 of the stake to vote on a block, either by other block producers building their blocks on top or by various asynchronous voting protocols.
For the developer's convenience, the response of the
eth_getBlockByNumber RPC method (and similar) is extended with a flag
isFinalized to signal that the respective Native block (containing EVM transactions) got finalized.
Transfer native VLX to EVM
In order to transfer VLX from the Native Space to the EVM Space, use
Note: The EVM Space accounts VLX in nano lamports (10^18), so when you transfer for example, 5 lamports, your balance will be reported as 5*10^9
Result after transaction processing:
To make sure that balance was updated, you can request it using rpc:
0x12a05f200 is a hex representation of 5*10^9
Transfer token from EVM back to native
For transferring tokens back to native chain, we have a special precompiled contract, that deployed at address:
With following interface:
native_recipient is 32byte address of Velas Native account.
To swap VLX, one should create a transaction to the address:
value specified in the transaction.
This transaction then can be sent to EVM Bridge, that will wrap it to native transaction.