EOS EVM Bridge Contracts v1.0.0-rc1

This release candidate of the EOS EVM Bridge Contracts introduces significant enhancements to the Trustless Bridge, enabling movement of tokens originating on the EVM side with the same level of flexibility previously available only to EOS native tokens.

In addition, this release applies a Business Source License (BSL) to the codebase, establishing a structured framework for responsible open use and commercial clarity.

Read on for details.

Changes

Trustless EVM Token Bridging

PRs

• (69)Allow register customized Bridged ERC20 implementation
• (70)implementation of evm->native bridge
• (74)abort bridgeTransfer if dust exist

The Trustless Bridge has been updated to now transfer ERC-20 originating tokens to the EOS native layer similar to how previous versions allowed EOS native tokens to transport to the EOS EVM layer. The new contract updates allow the system to:

• Register EVM tokens
• Unregister EVM tokens
• Set egress fees of EVM tokens
• Transfer EVM tokens from EVM to native and vice versa

These updates significantly improve the functionality and flexibility of the EVM Bridge Contracts, facilitating more efficient and secure interactions between EVM and native environments.

Business Service License

PRs

• (54)[0.2.1] Change to BSL licensing scheme
• (56)[0.2.1 -> main] Change to BSL licensing scheme; update silkworm submodule

The EOS EVM Bridge Contracts 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 evm-bridge-contracts repository contains instructions on how to build the components.

Upgrading

If a previous version of EOS EVM Bridge Contracts was already deployed, then immediately after upgrading to this version, the init action must be called using the default values for the EVM Contract account name (eosio.evm) and the gas token symbol (EOS with a precision of 4). The two gas limit values are allowed to be any valid value desired.

Until the init action is called, existing functionality may stop functioning. So it is recommended to call the init action immediately after the setcode and setabi actions that upgrade the contract within the same atomic transaction. After the init action is called, future upgrades of the contract should not call the init action again.

Further details on changes since last release

Contributors

• @taokayan
• @yarkinwho
• @elmato
• @arhag
• @wanderingbort

Full list of changes since last release

PRs

• (47)Full support for upgrade
• (48)pass in linked eos address and evm address instead of hardcode
• (52)[0.2 -> main] use spring in cicd
• (53)[0.2 -> main] Bump 0.2.0 version
• (54)[0.2.1] Change to BSL licensing scheme
• (55)[0.2.1] Update silkworm submodule and Spring dependency
• (56)[0.2.1 -> main] Change to BSL licensing scheme; update silkworm submodule
• (57)[0.2.1] Update EVM Contract dependency
• (58)[0.2.1 -> main] Update EVM Contract dependency; Fix Spring version dependency
• (59)add erc20(usdt) test with btc as based token
• (69)Allow register customized Bridged ERC20 implementation
• (70)implementation of evm->native bridge
• (74)abort bridgeTransfer if dust exist

Full Changelog: v0.2.0...v1.0.0-rc1