<aside> đź“ś TABLE OF CONTENTS
<aside> đź’Ž OUR COMMUNITY
A SolanaVM transaction is structured according to Ethereum's standards, ensuring compatibility with existing Ethereum processes. Each transaction includes data tailored to facilitate SolanaVM transactions. Following Ethereum's legacy transaction format, gas data is specified by two properties: gas_price and gas_limit. In Ethereum, these parameters determine the fee paid to miners for processing transactions and including them in blocks. However, in SolanaVM, instead of paying miners, this fee is collected in SVM tokens and paid to the entity submitting the transaction on the Solana network, typically a SolanaVM Intermediate Operator.
The cost of executing a SolanaVM transaction is determined by Solana's rules for transaction execution, leading to significantly lower gas fees compared to Ethereum or Ethereum-native Layer 2 solutions. Solana's gas price is determined by fee parameters such as the number of compute units required and the number of signatures contained within the transaction. When transacting on Solana using SolanaVM, the number of signatures is always set to 1, representing the SolanaVM Operator responsible for the transaction.
If a Solana account is created as a result of the transaction, additional fees are incurred to comply with rent exemption requirements. For instance, when a SolanaVM transaction creates a new Solana account to transfer SPL tokens like SVM tokens to new SolanaVM users, the fee includes the lamports needed for rent exemption.
In cases where transactions are parsed iteratively, the SolanaVM Operator incurs fees in SOL tokens for each iteration. For further details on the iterative execution of SolanaVM transactions, please refer to the relevant section in the documentation.
A SolanaVM transaction conforms to Ethereum's standards, providing data that facilitates the payment for transactions within SolanaVM. Reflecting Ethereum's traditional transaction structure, the gas costs are defined by two attributes: gas_price and gas_limit.
In the context of Ethereum, these terms define the user's commitment to the gas expenses for the transaction's processing, traditionally paid to the block-producing miner. However, within SolanaVM, instead of compensating miners, the fee is accepted in SolanaVM tokens to remunerate the entity executing the transaction on the Solana network, often a SolanaVM Intermediate Operator (refer to “SolanaVM: Future Development” for more details).
The execution cost of a SolanaVM transaction is determined following Solana's principles for transaction processing, which is why gas costs within SolanaVM are substantially lower compared to Ethereum or Ethereum-based L2 solutions, as they are pegged to the Solana network's gas pricing model.
Solana's gas price model is influenced by factors such as the computational units needed and the number of signatures included in a transaction. By harnessing SolanaVM for transactions on Solana, the signature count is consistently one—the signature of the SolanaVM Operator managing the transaction.
SolanaVM Operators incur fees in SOL tokens that are categorized as follows:
A service fee to the Solana leader for the execution of the transaction on the Solana blockchain.
A contribution to the SolanaVM treasury.
Should the transaction result in the creation of a new Solana account, the fees also cover the lamports necessary for the account to meet the network's rent exemption requirements. For instance, when a SolanaVM transaction establishes a new Solana account for transferring SPL tokens—like SolanaVM tokens—to a new user.
SolanaVM enables decentralized applications (dApps) to engage with ERC-20 tokens within the Solana ecosystem. There are two types of ERC-20 token variants that can be utilized:
These tokens are created on EVM-compatible blockchains. SolanaVM supports tokens natively minted through SolanaVM, as well as tokens that are wrapped and bridged from other EVM-compatible networks. SolanaVM facilitates the bridging of ERC-20 assets from chains like Ethereum into the SolanaVM environment, enabling their use within dApps on Solana. The bridging function is performed by a third-party EVM solution that operates independently, equipped with its own set of operators. A bridge integration for SolanaVM is already in place for the beta phase launch.
This innovation allows for the use of Solana's native SPL tokens through the familiar ERC-20 interface. For each existing SPL token on Solana, a specific smart contract can be deployed in SolanaVM, creating a pathway for these tokens to be accessible by dApps. To leverage SPL tokens from Solana balances within SolanaVM, the tokens must be transferred into the user’s SolanaVM, which bridges the gap between SolanaVM and the Solana network.