Releases: VaultaFoundation/evm-contract
EVM Contract v2.1.0
Introduction
Note
The functionality in this release is purpose-built for the EOS → A token migration in the Vaulta EVM deployment. It is not intended for use by other EVM instances or unrelated token migrations.
Vaulta EVM Contract v2.1.0 introduces the ability to update the Vaulta EVM deployment's gas token and perform a token swap as part of the migration.
Read on for more details.
New Features
Token Swap Support (EOS → A)
PRs
- (852)[main] implement tokenswap
New actions (swapgastoken and migratebal) and logic updates to withdraw, handle_account_transfer, and evm_contract::transfer have been introduced to enable the migration from EOS to A as the gas token in Vaulta EVM deployment.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 2.x.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (826)[2.0 -> main] Fix CI/CD cmake version
- (827)[2.0 -> main] Update silkworm 2.0.0-rc1
- (828)[2.0 -> main] Bump 2.0.0-rc1 version
- (840)[2.0->main] update readme
- (842)[2.0->main] Merge the patch for allowing some other account to pay the gas for call action
- (843)[2.0 -> main] print error in hex, configurable gas payer
- (846)[2.0 -> main] forward fixes to main: Print out solidity error message
- (848)[2.0 -> main] update silkworm to 2.0
- (852)[main] implement tokenswap
- (863)[2.0->main] forward 2.0 to main (version dump)
- (875)[2.0->main] fix callback
- (878)[2.0->main] forward verbump from 2.0 to main
- (851)[2.0 -> main] Bump 2.0.0-rc2 version
- (882)[2.0 -> main] Relax strict inequality check on max_gas_cost
- (884)[2.0 -> main] Fix incorrect accounting of gas_fee_income in v3
- (886)[2.0 -> main] Fix r and s check in is_valid_signature
- (883) fix test with spring 2.0
- (892)[2.0->2.1] forward ver bump 2.0.0
- (896)[2.1] version bump 2.1.0
Full Changelog: v2.0.0...v2.1.0
EVM Contract v2.0.0
Introduction
Vaulta EVM Contract v2.0.0 builds upon the previously introduced Gas Fee Algorithm architecture with key enhancements that improve fairness and updateability of transaction fees and introduces support for a separate account to pay gas for the call action.
Read on for more details.
New Features
Gas Fee Algorithm V3
PRs
- (847)[2.0] update silkworm to 2.0
Dual-Component Gas Fee Model
The Gas V3 algorithm introduces a dual-component gas fee model, separating transaction costs into:
- Computational Gas: Charges associated with CPU usage for executing operations.
- Storage Gas: Charges related to RAM usage for storing data.
Each component has its own pricing:
overhead_price: Cost per unit of computational gasstorage_price: Cost per unit of storage gas
To maintain compatibility with existing tools and interfaces, the system calculates a unified gas_price as the maximum of overhead_price and storage_price. The total gas_used is the sum of computational and storage gas, adjusted for any applicable discounts or refunds.
Gas Discount and Refund Mechanism
This release also introduces a transaction-level gas discount and refund mechanism that adjusts for scenarios where overcharging occurs in the new dual-component model.
- If the
inclusion_priceexceeds zero, miners receiveinclusion_price * computational_gasas their fee. Theinclusion_price * storage_gasportion is not collected in the final fee because the storage gas is discounted to effectively refund that excess fee back to the sender. - Depending on which of
overhead_priceorstorage_priceis greater, either discounts are applied to storage gas used or an explicit refund of gas usage occurs at the end of the transaction to prevent overcharging.
Safer Pricing Adjustments for Resource Cost Variability
Vaulta’s resource layer, specifically RAM, is subject to market-based pricing volatility. This release improves the handling for updates to gas pricing without breaking deployed application functionality.
The operation updtgasparam changes the gas usage for storage-manipulating operations and opcodes (such as SSTORE) and should only be used in select scenarios where RAM price changes drastically. Instead, setgasprices, can now be used to reflect RAM cost changes dynamically by updating storage_price with minimal disruption.
Allow separate account to pay gas for call action
PRs
- (835)[2.0] support calls with gas paid by other account.
A separate account can now pay the gas fees for a given user's call action. This feature supports advanced use cases such as gas obfuscation and sponsored transactions.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 1.x.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (720)[1.0 -> main] Bump 1.0.0-rc1 version
- (721)[1.0 -> main] Add basic test for non-EOS gas token
- (722)[1.0 -> main] Make gas_limit dynamic in handle_evm_transfer
- (723)[1.0 -> main] Bump 1.0.0-rc2 version
- (730)[1.0 -> main] Restrict rlp formats when decoding transaction
- (731)[1.0 -> main] Update silkworm 1.0.1
- (732)[1.0 -> main] Bump 1.0.0-rc3 version
- (736)[1.0 -> main] Check ingress fee precision
- (740)[1.0] Update silkworm 1.0.2
- (741) Revert "[1.0] Update silkworm 1.0.2"
- (743)[1.0 -> main] Update silkworm 1.0.2
- (747)[1.0 -> main] Bump 1.0.0-rc4 version
- (755)[1.0->main] Use upload-artifact v4 script in CI
- (756)[1.0 -> main] dynamic chainid
- (750) Add support for storage and overhead price
- (758)[1.0 -> main] Kayan 1.0 spring main
- (759) Fix configchange trace generation
- (764)[1.0 -> main] Bump 1.0.0 version
- (767)
cmake_minimum_required()beforeproject()to avoid cmake warning - (766) Add simple stack limit tests.
- (768)[1.0->main] merge changes removing the 1gwei gas price limit
- (771)[1.0.1 -> main] Change to BSL licensing scheme
- (775) Update for Spring main 1.1.0
- (773) fix cicd, update local_testnet_deployment_plan.md
- (782)[1.0->main] configurable ingress gas limit
- (779) Add gas parameters scaling tests
- (785)[1.0->main] forward ingress gas limit test
- (760) Return constant reference in value_promoter
- (789) Update silkworm (last gas v3)
- (791)[1.0 -> main] Enable EIP2 enforcement by default
- (792) Update silkworm with default EIP2 enforcing when evm_version >= 3
- (783) Fix gas price used in evm_contract::call_
- (794)[1.0 -> main] Bump 1.0.1 version
- (804)[1.0 -> main] Fix tests broken by spring 1.1
- (805)[1.0->main] Support multiple bridge transfers in one tx
- (806)[1.0->main] Add statistics
- (803) Refactor gas price handling
- (808)[1.1 -> main] Bump 1.1.0-rc1 version
- (817)[1.1 -> main] Bump 1.1.0 version
- (824)[1.0] Fix CI/CD cmake version
- (825)[1.0 -> 2.0] Fix CI/CD cmake version
- (822)[2.0] Update silkworm 2.0.0-rc1
- (821)[2.0] Bump 2.0.0-rc1 version
- (839)[2.0] Update README.md
- (835)[2.0] support calls with gas paid by other account.
- (841)[2.0] print inline evm tx error in hex
- (847)[2.0] update silkworm to 2.0
- (850)[2.0] Bump 2.0.0-rc2 version
- (856)[1.2] backport gas payer feature from release/2.0
- (858)[1.2 -> 2.0] forward 1.2 to 2.0
- (861)[1.2] bump version 1.2.0
- (862)[1.2->2.0] forward 1.2 to 2.0 (version bump)
- (867)[1.1] fix callback
- (872)[1.1] version bump 1.1.1
- (873)[1.1 -> 1.2] fix callback
- (874)[1.2->2.0] forward callback fix
- (876)[1.1->1.2] forward verbump
- (877)[1.2->2.0] forward verbump
- (879)[1.2] Relax strict inequality check on max_gas_cost
- ([880](https://githu...
EVM Contract v1.2.0
Introduction
Vaulta EVM Contract v1.2.0 introduces support for a separate account to pay gas for the call action, forwards a critical security bug fix, and an additional bug fix.
Read on for more details.
New Features
Allow separate account to pay gas for call action
PRs
- (856)[1.2] backport gas payer feature from release/2.0
A separate account can now pay the gas fees for a given user's call action. This feature supports advanced use cases such as gas obfuscation and sponsored transactions.
Bug fixes
Flawed authorization check
It was discovered that it was possible to circumvent authorization in certain actions due to how callbacks were structured. This issue could lead to denial of service and unauthorized arbitrary transactions to be executed.
Relax strict inequality check on max_gas_cost
It was discovered that the logic checking against max_gas_cost was too strict and could lead to valid transactions being rejected where the actual gas fee equals the maximum allowed value.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 1.x.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v1.1.0...v1.2.0
EVM Contract v1.1.1
Introduction
The latest patch release of Vaulta EVM introduces a fix to a critical security bug related to a flawed authorization check.
Read on for more details.
Bug fixes
Flawed authorization check
It was discovered that it was possible to circumvent authorization in certain actions due to how callbacks were structured. This issue could lead to denial of service and unauthorized arbitrary transactions to be executed.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 1.1.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
Full Changelog: v1.1.0...v1.1.1
Vaulta EVM Contract v2.0.0-rc2
Introduction
Vaulta EVM Contract v2.0.0-rc2 introduces support for a separate account to pay gas for the call action. This release also includes branding updates in alignment with the transition from EOS to Vaulta.
Read on for more details.
New Features
Note
This release candidate includes a new feature, which is an exception to our usual protocol — RCs are typically reserved for resolving defects and do not introduce new functionality.
Allow separate account to pay gas for call action
PRs
- (835)[2.0] support calls with gas paid by other account.
A separate account can now pay the gas fees for a given user's call action. This feature supports advanced use cases such as gas obfuscation and sponsored transactions.
Other updates
Vaulta branding
PRs
- (839)[2.0] Update README.md
References to EOS have been removed or replaced with Vaulta across documentation and code to reflect the network's rebranding.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 1.x.x version or v2.0.0-rc1 by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v2.0.0-rc1...v2.0.0-rc2
Vaulta EVM Contract v2.0.0-rc1
Introduction
Vaulta EVM Contract v2.0.0-rc1 builds upon the previously introduced Gas Fee Algorithm architecture with key enhancements that improve fairness and updateability of transaction fees.
Read on for more details.
New Features
Gas Fee Algorithm V3
PRs
- (822) [2.0] Update silkworm 2.0.0-rc1
Dual-Component Gas Fee Model
The Gas V3 algorithm introduces a dual-component gas fee model, separating transaction costs into:
- Computational Gas: Charges associated with CPU usage for executing operations.
- Storage Gas: Charges related to RAM usage for storing data.
Each component has its own pricing:
overhead_price: Cost per unit of computational gasstorage_price: Cost per unit of storage gas
To maintain compatibility with existing tools and interfaces, the system calculates a unified gas_price as the maximum of overhead_price and storage_price. The total gas_used is the sum of computational and storage gas, adjusted for any applicable discounts or refunds.
Gas Discount and Refund Mechanism
This release also introduces a transaction-level gas discount and refund mechanism that adjusts for scenarios where overcharging occurs in the new dual-component model.
- If the
inclusion_priceexceeds zero, miners receiveinclusion_price * computational_gasas their fee. Theinclusion_price * storage_gasportion is not collected in the final fee because the storage gas is discounted to effectively refund that excess fee back to the sender. - Depending on which of
overhead_priceorstorage_priceis greater, either discounts are applied to storage gas used or an explicit refund of gas usage occurs at the end of the transaction to prevent overcharging.
Safer Pricing Adjustments for Resource Cost Variability
Vaulta’s resource layer, specifically RAM, is subject to market-based pricing volatility. This release improves the handling for updates to gas pricing without breaking deployed application functionality.
The operation updtgasparam changes the gas usage for storage-manipulating operations and opcodes (such as SSTORE) and should only be used in select scenarios where RAM price changes drastically. Instead, setgasprices, can now be used to reflect RAM cost changes dynamically by updating storage_price with minimal disruption.
Building, compatibility, and upgrading
Building
The README in the evm-contract repository contains instructions on how to build Vaulta EVM Contract.
Compatibility and upgrading
Vaulta EVM Contract can be upgraded from the prior 1.x.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (720) [1.0 -> main] Bump 1.0.0-rc1 version
- (721) [1.0 -> main] Add basic test for non-EOS gas token
- (722) [1.0 -> main] Make gas_limit dynamic in handle_evm_transfer
- (723) [1.0 -> main] Bump 1.0.0-rc2 version
- (730) [1.0 -> main] Restrict rlp formats when decoding transaction
- (731) [1.0 -> main] Update silkworm 1.0.1
- (732) [1.0 -> main] Bump 1.0.0-rc3 version
- (736) [1.0 -> main] Check ingress fee precision
- (740) [1.0] Update silkworm 1.0.2
- (741) Revert "[1.0] Update silkworm 1.0.2"
- (743) [1.0 -> main] Update silkworm 1.0.2
- (747) [1.0 -> main] Bump 1.0.0-rc4 version
- (755) [1.0->main] Use upload-artifact v4 script in CI
- (756) [1.0 -> main] dynamic chainid
- (750) Add support for storage and overhead price
- (758) [1.0 -> main] Kayan 1.0 spring main
- (759) Fix configchange trace generation
- (764) [1.0 -> main] Bump 1.0.0 version
- (767)
cmake_minimum_required()beforeproject()to avoid cmake warning - (766) Add simple stack limit tests
- (768) [1.0->main] merge changes removing the 1gwei gas price limit
- (771) [1.0.1 -> main] Change to BSL licensing scheme
- (775) Update for Spring main 1.1.0
- (773) fix cicd, update local_testnet_deployment_plan.md
- (782) [1.0->main] configurable ingress gas limit
- (779) Add gas parameters scaling tests
- (785) [1.0->main] forward ingress gas limit test
- (760) Return constant reference in value_promoter
- (789) Update silkworm (last gas v3)
- (791) [1.0 -> main] Enable EIP2 enforcement by default
- (792) Update silkworm with default EIP2 enforcing when evm_version >= 3
- (783) Fix gas price used in evm_contract::call_
- (794) [1.0 -> main] Bump 1.0.1 version
- (804) [1.0 -> main] Fix tests broken by spring 1.1
- (805) [1.0->main] Support multiple bridge transfers in one tx
- (806) [1.0->main] Add statistics
- (803) Refactor gas price handling
- (808) [1.1 -> main] Bump 1.1.0-rc1 version
- (817) [1.1 -> main] Bump 1.1.0 version
- (824) [1.0] Fix CI/CD cmake version
- (825) [1.0 -> 2.0] Fix CI/CD cmake version
- (822) [2.0] Update silkworm 2.0.0-rc1
- (821) [2.0] Bump 2.0.0-rc1 version
Full Changelog: v1.1.0...v2.0.0-rc1
EOS EVM Contract v1.1.0
Introduction
The latest release of EOS EVM introduces support for new fee statistics tracking and enhancements to bridging functionality that enables multiple transfers to take place in a single transaction.
Read on for more details.
Updates
Gas and bridge fee tracking
A new statistics table has been introduced to help track gas and bridge fees generated on EOS EVM.
Allow multiple bridge transfers in one transaction
The Trustless Bridge now supports more than one bridge transfer per transaction with appropriate use of memo.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 1.x.x version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v1.0.1...v1.1.0
EOS EVM Contract v1.0.1
Introduction
The latest patch release of EOS EVM Contract introduces updates to the ingress gas limit, gas price limit, EIP-2 enforcement default settings, and the application of a Business Service License (BSL) for the EOS EVM Contract codebase.
Read on for more details.
Updates
Configurable ingress gas limit
Previously, transactions generated by the contract for ingress transfers were using a hard coded (21k) gas limit amount. This value is now configurable because the previous 21k limit is insufficient after gas parameter updates.
Remove hardcoded limit when setting gas price
Previously, the gas price could not be set below 1 Gwei. The price can now be updated to as low as 1 Wei.
EIP-2 enforcement enabled by default
EIP-2 enforcement is now enabled by default.
Business Service License
PRs
The EOS EVM Contract codebase has transitioned to a Business Service License (BSL), which introduces a structured licensing framework that promotes responsible and open use of the code. The BSL allows for commercial use while encouraging contributors and users to adhere to the terms outlined in the license. This change supports continued innovation within the EOS ecosystem and ensures that all users have a consistent and fair understanding of usage rights. More information can be found in the repo’s license file.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 1.0.0 version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (765)[1.0] Remove 1gwei limit when setting gas price
- (769)[1.0.1] Change to BSL licensing scheme
- (770)[1.0.1] Update silkworm submodule to include BSL license
- (777)configurable ingress gas limit
- (780)[1.0] add testcase for ingress gas limit
- (790)[1.0] Enable EIP2 enforcement by default
- (793)[1.0] Bump 1.0.1 version
Full Changelog: v1.0.0...v1.0.1
EOS EVM Contract v1.0.0
Introduction
The latest release of EOS EVM introduces support for Shanghai and London Hard Fork and their comprised features, a new gas fee algorithm to more accurately price transactions for underlying resource costs involved, and configuration settings to adjust the base token of the network.
Read on for more details.
New features
London Fork Compatibility
EIP-1559: Transaction Fee Reform
PRs
A critical component of the London Hard Fork is EIP-1559, which introduces a new transaction fee mechanism. This update changes how gas fees are handled on the EOS EVM network with new components including a base fee and priority fee combined to calculate the overall cost of a transaction based on units of gas used.
Base fee
The base fee, implemented as the base_fee_per_gas, is the minimum fee required for a transaction to be included in a block. This fee is burned in the Ethereum implementation, but is instead credited to the contract for EOS EVM. The base_fee_per_gas is now part of the block header information and is returned in both eth_getBlockByNumber and eth_getBlockByHash API calls.
Priority fee
The priority fee, implemented as the inclusion_price, is a fee historically designed so that users can pay to miners to incentivize them to prioritize their transactions over others. In EOS EVM, the priority fee does not prioritize transactions. Instead, it is a fee set by the miner to cover their costs for processing the transaction and pushing it into the network. This fee goes directly to the miner and is not burned.
The priority fee or inclusion_price can be calculated as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas).
Max fee
Users may now specify a maximum fee they are willing to pay for the sum of base and priority fees. If the max fee is higher than the sum of the base fee and the priority fee, the difference is refunded to the user. This ensures users don't overpay beyond what is necessary to get their transactions processed.
Overall transaction fee
The overall cost of a transaction fee utilizes a price per gas unit implemented as the effective_gas_price, which can be calculated as
inclusion_price + base_fee_per_gas. The overall cost of any given transaction is then calculated as the product ofeffective_gas_price * gas_used.
Fee distribution
The fees associated with transactions are now distributed to where the contract receives base_fee_per_gas*gas_used and the miner receives inclusion_price*gas_used.
Feature activation for wallet users
The flag for the EIP-1559 network support is cached, so users will have to refresh their network selection by changing the active network to another network and go back to eos-evm in order for many common wallets like Metamask to start sending EIP-1559 transactions.
Shanghai Fork Compatibility
PUSH0 Opcode Support
Support has been added for the PUSH0 opcode as introduced in the Shanghai Hard Fork. This opcode pushes a zero onto the stack, optimizing certain types of smart contract code and potentially reducing gas costs for operations that frequently use zero values.
Gas Fee Algorithm Enhancements
PRs
A new gas fee algorithm has been introduced to alleviate challenges with a prior one-size-fits-all gas fee structure. Because the previous method used to calculate gas fees did not account for the varying computational resources required by transactions, many transactions were priced higher than their resource costs for the safety of the network.
To accomplish this, five new parameters are now tracked including:
- Additional gas consumed when creating a new non-contract account due to a message-call transaction that sends positive value to an empty account. This value defaults to 0 and is denoted as
G_txnewaccount. - Additional gas consumed when creating a new non-contract account due to the
CALLorSELFDESTRUCTopcodes. This value defaults to to 25000 and is denoted asG_newaccount. - Static gas consumed in the
CREATEandCREATE2opcodes and also acts as the additional gas consumed in a contract-creating transaction. This value defaults to 32000 and is denotedG_txcreate. - Factor that multiplies the deployed code size within
CREATEandCREATE2opcodes, as well as contract-creating transactions, to determine the code deposit cost. This value defaults to 200 and is denoted asG_codedeposit. - Gas consumed when an
SSTOREopcode causes the storage value to go from zero to non-zero. This value defaults to 20000 and is denoted asG_sset.
These five new parameters can be calculated as follows:
G_txnewaccount=account_bytes * gas_per_byteG_newaccount=account_bytes * gas_per_byteG_txcreate=contract_fixed_bytes * gas_per_byteG_codedeposit=gas_per_byteG_sset= 2900 +storage_slot_bytes * gas_per_byte
Each of these five parameters are accounted for an stored when establishing an updated gas cost.
Configurable Base Token
EOS EVM now has the ability to be deployed with a different base token for fees and a different chain id as a configuration setting. This enables other EVM instances to exist that utilize other ecosystem tokens, such as BTC for exSat.
General Hard Fork Solution
EOS EVM now officially supports multiple versions and the ability to perform a hard forks when required for future versions such as London Hard Fork detailed above.
This release implements a linear versioning system for EOS EVM hard forks, mapping each EOSEVM version to a corresponding EVMC revision:
| EOSEVM Version | EVMC Revision |
|---|---|
| 0 | ISTANBUL |
| 1 | SHANGHAI |
Note: for this release, EOS EVM is moving directly from Instanbul to Shanghai, including all support for London Hard Fork within that version.
Bug fixes
Allow transfer of non-EOS tokens out of contract account
PRs
Previously, only EOS was capable of being moved out of the contract account in order to be utilized for operational costs. Recent updates now allow other token types to be transferred out of the account.
Building, compatibility, and upgrading
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
- (665)[0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- (676) [0.6->main] Allow transfer non-EOS tokens out
- (665) [0.6 -> main] Bump 0.6.0 version
- (667) fix unittest compile error, explicitly set inline action size to 4kB
- (675) [0.6] Allow transfer non-EOS tokens out.
- ([676](http...
EOS EVM Contract v1.0.0-rc4
Introduction
The latest release candidate of EOS EVM Contract includes updates to resolve an issue discovered with disproportionally high gas fees and insufficient returns for certain types of transactions related to the new gas fee algorithm.
Read on for more details.
Updates
Make an exception for privileged accounts when calculating gas
It was discovered that privileged accounts were being treated as if they were new, not previously created accounts when calculating gas fees. An update has been made to make an exception for these accounts for all operations.
Change max gas refund in ExecutionProcessor to 100% with a limit in the minimum gas used of 21k
In certain scenarios, where disproportionately high gas fees were charged, inadequate refunds were returned due to the max refund setting of 20% as part of the protocol. This value has been updated to a max of 100% to improve overall user experience as the next generation of the gas fee algorithm is developed.
Building
The README in the eos-evm repository contains instructions on how to build EOS EVM Contract.
Compatibility and upgrading
EOS EVM Contract can be upgraded from the prior 0.6.0 version by simply deploying the WASM and ABI.
Further details on changes since last release
Contributors
Special thanks to the contributors that submitted patches for this release:
Full list of changes since last release
PRs
Full Changelog: v1.0.0-rc3...v1.0.0-rc4