Sei v2: EVM and Wasm interoperability

Sei v2: EVM and Wasm interoperability

A short FAQ has been included at the end of this post to clarify common questions.

The upcoming proposal for the Sei v2 upgrade will introduce a variety of new features, such as the first high performance parallelized EVM. This will result in a chain that combines the best parts of both Solana and Ethereum; improving the user experience and unlocking a brand new design space for developers, with 100x improvements in throughput when compared with current offerings in the Ethereum ecosystem.

Right now, Sei supports both CosmWasm smart contracts, and associated “CW” tokens. As part of the Sei v2 upgrade, Sei would be upgraded to support two execution environments at once: both CosmWasm and the EVM, simultaneously. This means all token standards available on Ethereum blockchains will now also exist on Sei, for example ERC-20 and ERC-721.

💡
Both CosmWasm and EVM will inherit all the benefits of Sei's optimized architecture, such as the fastest time to finality of any blockchain and the ability to handle thousands of TPS.

You can try out the first test implementations to demonstrate interoperability, that have been deployed on Sei v2 devnet here:

  • Mint a CW-721 NFT using Metamask via Webump
  • Mint a CW-721 NFT using Metamask via Sei Whales
  • Swap a CW-20 token (ORCA) on an EVM DEX via Dragonswap
  • Liquid Stake your Sei using a Metamask wallet via Silo

Devnet Faucets can be found here and here.

This blog post will dive into how interoperability between the EVM and CosmWasm will work on Sei v2.

tldr: you can use existing Sei applications, and interact with any token on Sei with any Ethereum wallet, provided developers perform a short upgrade to their applications/tokens using the proposed instructions below.

The Problem

Including two execution environments has the potential to introduce complexity to the ecosystem and user experience on Sei. There are a number of considerations to make when launching a chain with multiple execution environments:

  • Fragmentation of liquidity: any given tokens should be accessible on both the EVM and CosmWasm side, without needing a “wrapped” asset to be created. 
  • DEXes and marketplaces should be able to list both CosmWasm and EVM tokens.
  • Fragmentation of wallets: it should be possible to use any application on Sei, regardless of execution environment, with the same wallets.
  • Security assumptions: the solutions to these problems should not introduce any additional risk to users on Sei.
  • Users should not have to export their private key to a new wallet.

This blog will dive in and explain from a user and developer perspective how these problems were solved, and how interoperability on Sei works.

The Solution

Sei Labs has introduced features to bridge the gap between EVM and Wasm, allowing for smooth and easy interactions between both environments.

NFTs and Token Interoperability

Every token currently on Sei, whether an NFT (CW-721), or a “token” (CW-20), can become compatible with EVM wallets and applications using a pointer contract.

These contracts facilitate the creation of "pointer" tokens that establish links between tokens across both EVM and CosmWasm. This enables tokens to be used seamlessly in both environments, without the need for "wrapped" assets (burn/mint, or escrow/mint solutions).

This results in the exact same token balance being controlled on both EVM and CosmWasm, at the same time. But how?

How does this work?

To understand how pointer contracts work, it’s important to introduce the concept of "accounts" and understand how a crypto wallet works.

Many users have the misconception that a token "lives in your wallet", based on the real world analogy of a physical wallet. In fact, on all blockchains this is not the case.

Token balances are associated with an "account" on Sei, which is independent of any specific wallet software or even smart contract language. Wallets simply allow you to read this balance and sign transactions to make updates to this balance, through a simple interface, using your private key. In other words - tokens "live" on the blockchain, not "in your wallet".

Pointer contracts take advantage of this fact, to create a new "0x" token that is linked to the original "Sei" token.

An analogy for this is to see wallets like a monitor for your personal computer. They show you your underlying account balances and provide a simple interface to allow you to sign transactions on Sei, using your private key. In this way, it's possible to add a "second monitor" with a duplicated view. Now, you can see and control the same tokens on Sei, regardless of the wallet you use.

Analogy for Token Interoperability: Duplicated Monitor Views
💡
Pointer contracts do not store their own state or create any token - the destination contact or bank module remains the sole source of truth for token data.

A more detailed breakdown is included in the Appendix below.

Pointer contracts also unlock the ability to utilise CW-20, CW-721, and native tokens in EVM apps, and vice versa.

However, one thing that pointer contacts cannot do, is enable users to interact with an existing Sei app with an EVM wallet. This requires a second new feature, called a "precompile".

Precompiled Contracts

It's important that regardless of execution environment, users should be able to interact with smart contracts with their wallet of choice. For example, listing an NFT on Pallet, or providing liquidity on Astroport should be possible with an EVM wallet.

In order to achieve this, Sei Labs has implemented various "precompile" smart contracts, which allow native Sei functionality from the EVM side. These are smart contracts embedded directly within the Sei blockchain. They provide a gateway for users and developers to access native Sei functionalities through the EVM RPC interface.

You can think of these like a native "google translate" for certain types of functions.

Analogy for Precompiles: Translate Service

The following is a list of precompiled contracts available on Sei:

For developers looking for instructions to utilize these precompiles, refer to the Example Usage section.

In effect, any existing application on Sei can implement these contracts and update their UI to support Ethereum wallets. 

Advanced: User Accounts on Sei

Every user "account" on Sei, has a unique public key. In Sei V2, this public key translates into two different types of addresses:

  • EVM Address: This address starts with 0x and is used for Ethereum-based activities.
  • SEI Address: This address starts with Sei and is used for Sei-native activities.

Although these addresses appear different, they actually share the same underlying account. This means whatever action you take with one token address will also affect the other.


Therefore, it is possible to create an EVM address and associate it with your Sei address, in order to control the same tokens in both wallets. This link is established automatically after the first EVM transaction is processed for a particular private key. In order to associate your EVM and Sei addresses, you should initiate a transaction from your EVM address. For example, you can send tokens to yourself.

If you deposit funds into your EVM address, you can access and use those same funds with your Sei address, and vice versa. They are linked together as one account, ensuring seamless integration between the EVM and Sei ecosystems.


Some Sei wallet teams, such as Compass wallet, are updating their build to support both Sei and an associated evm wallet address from the same interface, to reduce user error.

Conclusion

Including two execution environments has the potential to introduce complexity to the ecosystem and user experience on Sei. However, through precompiles and pointer contracts:

  • Any given tokens are accessible on both the EVM and CosmWasm side, without needing a “wrapped” asset to be created. 
  • DEXes and marketplaces are able to list both CosmWasm and Ethereum tokens, regardless of which environment they are deployed on.
  • It is possible to use any application on Sei, regardless of execution environment, with a users wallet of choice.

Appendix

FAQ

  1. I want to use an existing application on Sei using an EVM wallet. How can I do this?
    1. As a user, there will be no change in your experience. DApp devs will update their frontend to support EVM wallets such as Metamask.
  2. I am trading tokens on an existing DEX on Sei. Can I also trade this token on an EVM DEX on Sei?
    1. Yes, pools / markets for both ERC and CW tokens can be created on either EVM or CosmWasm.
  3. Are there risks to consider with regards to pointer contracts?
    1. As with any contract on any blockchain, users should always verify that they are interacting with a legitimate contract that truly “points” to the correct underlying token. The name and/or ticker associated with a contract does not guarantee it is genuinely pointing to the original token/NFT. Project teams should share this information publicly when deploying a pointer contract.
  4. Will it be possible to withdraw Sei from a CEX to an EVM "0x" address?
    1. Yes

Pointer Contracts Deep Dive

EVM Native Wallets allow users to transfer and see balances of ERC-20 coins and ERC-721 NFTs. However, they are unable to directly interact with CW based contracts since:

  • EVM contracts live within the EVM Boundary
  • EVM contracts do not implement the CW-20/CW-721 token standard.

Likewise, CosmWasm clients cannot directly recognise or interact with EVM based tokens or NFTs.

Pointer contracts allow CosmWasm based clients to interact with pointer contracts to access EVM based tokens and NFTs. Likewise, EVM based clients can interact with CosmWasm based tokens and NFTs on Sei via pointer contracts.

A pointer contract acts a little like a "translator" for its corresponding contract.

In these examples, the pointer contracts point to different types of underlying tokens. However, they both implement the ERC-20 token standard. This allows EVM based wallets to interact with them.

When the pointer contract is called, they:

  • Translate the message sent to it into it's CW-20 equivalent.
  • Forward the message to the correct destination.

Pointer contracts do not store their own state or create any token - the destination contact or bank module remains the sole source of truth for token data.