Add EVM to Osmosis

Proposal Discussion
1

This proposal outlines a Protocol Revenue sharing agreement, which entails adding the support of EVM Smart contracts and a native EVM Wallet experience on the Osmosis protocol by integrating evmOS. In return, a proportion of taker fees generated by trading from EVM wallets on Osmosis will be shared with evmOS.

Osmosis has been pioneering the decentralized crypto exchange experience within the interchain for over three years. Currently, it supports only Cosmos native wallets such as Keplr and Leap. Attempts to integrate EVM wallets like Metamask Snaps have not yielded a satisfactory user experience.

To attract more users and enhance the user experience, Osmosis could support EVM wallets natively, deploy EVM-compatible bridges, and establish a partnership to integrate evmOS into the Osmosis chain.

About evmOS

evmOS is a plug-and-play solution developed by the Evmos core protocol team that adds EVM compatibility and customizability to non-EVM chains. Integrating evmOS will empower Osmosis with:

  • Full access to evmOS modules and updates
  • Full access to product partnerships
  • Continuous upgrades, access to product and engineering support

evmOS has already attracted significant interest from teams in and out of Cosmos as a solution for bringing the EVM to their chain. Find below recent announcements of evmOS partnerships, showcasing a wide variety of strong teams that have or will add EVM functionality using evmOS:

Proposal

This proposal signals the addition of evmOS as a module on the Osmosis blockchain, with integration led by the evmOS team. This integration will enable the onboarding of new EVM users and will be funded by a protocol revenue share system that is shared with the evmOS team.

Integrating evmOS will enable new EVM wallet users to join the Osmosis protocol, increasing liquidity volume and generating additional taker fees for Osmosis. A portion of this added value will be allocated to further developing the evmOS protocol and incentivizing the prioritization of Osmosis on their roadmap.

The existing Osmosis experience and its users will remain unaffected, with Cosmos wallets like Keplr and Leap continuing to function as usual. However, new users will gain access to Osmosis, unlocking the untapped potential of EVM users. For instance, MetaMask, which serves over 30 million monthly active users and connects to nearly every web3 dApp, currently cannot be easily connected to Osmosis, while Cosmos wallets like Keplr serve a much lower amount of users (1 million monthly transacting users).

Additionally, this will make integrations with third-party protocols much more seamless. For example, numerous bridge protocols with which Osmosis may wish to integrate to support bridging of new assets do not yet support CosmWasm. Having an EVM layer upon which to deploy will allow these interoperability protocols to deploy without significant code changes. For this reason, supporting the EVM on Osmosis will help streamline the development roadmap.

Specifically, adding evmOS will enable the following features on Osmosis:

  • EVM Wallet Integration: Users can use EVM wallets like MetaMask or Rabby to interact with Osmosis natively, similar to any other EVM experience. Users will sign Cosmos transactions with the EVM wallet widget. Native MetaMask use with the Osmosis chain requires enabling communication with JSON-RPC and the corresponding EVM backend, provided by evmOS.

  • Solidity Smart Contract Deployment: EVM Solidity smart contracts can be deployed and executed on Osmosis. The protocol can choose between permissionless deployment, permissioned to whitelisted addresses, or restricted access. At launch, contract deployment will be permissioned to mirror the existing CosmWasm deployment standard. This can be changed via a governance proposal on Osmosis. Integrating evmOS makes the chain EVM-compatible, allowing any bytecode runnable on Ethereum to be run on Osmosis, supporting EVM smart contracts from other EVMs.

  • Token Display and Transfer: Osmosis native tokens, IBC tokens, and ERC-20s can be displayed and transferred within the EVM wallet widget, such as MetaMask. This seamless integration with Cosmos-native assets like OSMO and other IBC coins is enabled by the Single Token Representation v2 (STRv2), an adaptation of the evmOS x/erc20 module combined with the newly introduced EVM Extensions.

  • Alternative Gas Token: A different default gas token can be set for EVM transactions. For example, Osmosis can choose to only accept USDC for EVM transactions instead of OSMO.

Beyond these features, evmOS offers a security advisory program, continuous dependency upgrades (e.g. Cosmos SDK, IBC, geth), technical support, and exclusive product partnerships.

Revenue Sharing

The Osmosis protocol charges a small taker fee on all trades, with a default rate of 0.1%. This proposes that a percentage of the taker fee from EVM wallet transactions on Osmosis will be allocated to the evmOS development team. This allocation will not affect taker fees from existing Cosmos wallet interactions, but will only apply to new EVM users, who are not currently present on Osmosis.

The proposed revenue share amount is similar to other revenue share agreements on Osmosis, such as the Skip Protocol protorev module revshare agreement. We propose that Osmosis allocates 20% of the taker fees from EVM wallet transactions to the evmOS team in year one, 10% in year two, and 5% thereafter. This structure ensures that the evmOS team is incentivized to drive net-new EVM transaction volume through Osmosis, resulting in larger taker fee revenue overall.

The agreement, revenue sharing, and concurrent upgrades will last for a minimum of three years, after which time it will need to be renewed by Osmosis governance and the evmOS team. After the 3 year period, the latest codebase can continue to be used. However, a renewed agreement will be required for further upgrades. For instance, if evmOS reaches version v25 after three years and the agreement is not renewed, the Osmosis protocol can continue using version v25 but will not have access to newer versions, such as v26. If the agreement is not renewed, revenue-sharing will also terminate.

Implementation

The evmOS team will integrate core protocol changes into the Osmosis codebase, with Osmosis as the code owner responsible for reviewing and merging the code. Upon integration, the Osmosis protocol will have immediate access to evmOS. Typical timelines are as follows, though they may vary based on requirements and resources:

  • Integration into the new chain: 4 weeks
  • Launch and go-to-market: 4 weeks
  • Agreement duration: 3 years, with updates to the stack during that time

Appendix

The evmOS team

The evmOS team comprises industry veterans with extensive experience in Cosmos and EVM. Their core engineers meticulously scope, build, audit, and rigorously test new features on the Evmos chain before deployment on any partner chains.

As product managers, they follow a comprehensive roadmap of features validated by evmOS partners and their users. They champion application-specific EVM chains, ensuring that evmOS allows partner chains to fully customize their stack to integrate business logic and deliver exceptional user experiences.

Committed to the long term, they ensure that evmOS adheres to the latest industry standards, such as Cosmos SDK releases. They support seamless integration into various stacks and offer access to a network of trusted partners, including RPCs, Validators, indexers, archives, and block explorers.

Key dates:

  • 2024: Evmos and evmOS technologies powered projects reach $10B+
  • 2022: $27 million seed funding round led by Polychain Capital
  • 2021: Cosmos Hub funds Evmos to develop the EVM on Cosmos
  • 2016: Proof of Concept of the first EVM in Cosmos
7 Likes
2

This proposal is a clear yes, imo.

Benefits

Osmosis will get a native metamask integration (which will finally give us the metamask user experience that we all hoped snaps would be), plus make it much easier for other protocols to deploy on Osmosis.

The latter of these actually really increases the surface area / decreases the cost for protocols that we can seek out and ask to deploy forks on Osmosis. For most protocols on EVM networks (whether interop, dā€™apps, or infra), rewriting their entire codebase in Wasm to deploy on Osmosis simply isnā€™t practical, or is too cost-prohibitive (making it harder for entities like the OGP to incentivize them to move here). This would minimize those costs and make Osmosis BD a lot more productive.

We also get the support of a strong team that will be actively incentivized to encourage apps to deploy on Osmosis and metamask users to trade in Osmosis pools. As their revenues go up, so do taker fee revenues for OSMO stakers. This kind of incentive-alignment has already been shown to work on Osmosis, the most prominent example of which being Skip Protocol and their contributions to the Osmosis stack.

Revenue Sharing

As with past revenue-sharing proposals like Skipā€™s protorev proposal and the recent nomic revshare proposal, the amount that Osmosis pays for this integration is directly proportional to usage of the EVM layer. If the EVM isnā€™t used at all, Osmosis users donā€™t pay anything, and donā€™t lose any existing revenue.

If, on the other hand, having access to metamask and other EVM wallets brings significant swap volume to Osmosis, OSMO stakers will benefit from increased taker fees that we would not have otherwise received.

Itā€™s too early to tell how the Nomic revenue sharing will play out, but I think most would agree that the Skip revenue sharing proposal has brought a ton of value to Osmosis, resulting in over 2m OSMO (0.2% of the max supply) being burned.

Revenue sharing also buys Osmosis ongoing update and security support for the EVM with minimal resources being needed on the Osmosis dev team (freeing them up to work on other roadmap items).

Alternatives

The alternative to revenue sharing would be to award the Altiplanic team with a grant in exchange for the license. OGP did discuss this with their team, but both sides felt that this would be a strictly worse option because:

  • Less Incentive Alignment: This has the potential to be a strong long-term relationship, with Altiplanic supporting on BD and technical work to bring EVM applications to Osmosis. The incentives arenā€™t as strong from a flat fee payment.

  • Difficulty In Measuring ROI: The cost of a grant would be pretty expensive, and making an agreement for that large of an amount without being fairly sure that it would generate significant returns would be a risky bet with community funding. This revshare model, on the other hand, reduces the risk to the communityā€™s treasury to 0 while retaining the upside potential.

All-in-all, I think this revshare model is an elegant and reasonable solution to getting the EVM on Osmosis, and Iā€™ll be voting yes!

3 Likes
3

Oh my fucking gosh. YES.

Excuse my French.

3 Likes
4

Iā€™ve struggled with evmos UX. Will this downgrade the UX on osmosis? Also how will this impact performance on chain? I recalled that evmos had some issues with uptime performance and I would hope this would not impact osmosis negatively with that as well

5

Good questions, and these were my reservations as well, but I would imagine that Osmosis would have near full control over the UX, not so much EVMOS

1 Like
6

how about the security implications of this integration?

Is it going to be Solidity ā†” Cosmwasm contract interoperability?

What would you say to someone who argues that integrating different smart contract languages increases the surface area for potential security threats, and therefore poses a significant security risk?

7

Adding to the questions asked by @whitemarlin and @omniwired I am curious how the transactions are distinguished.

How can a transaction from a non-Cosmos wallet and a wallet enabled via evmOS be recognized?
Is there a potential risk that other non-Cosmos wallets being connected to Osmosis without evmOS will be put in the same bucket? Or is there an unique marker?

The idea sounds cool and I fully understand the line of reasoning from @RoboMcGobo with respect why a revenue share is more interesting than a flat-fee. With a revenue share the incentive is to generate a lot of usage and transactions, driving revenue. With a flat-fee that drive is completely missing.
However, I do think we should make sure that the clearly outline when a transaction is seen as belonging to evmOS and when not. I do not want to mark more transactions applicable for this revenue share than truly done via evmOS (also to drive adoption instead of finding ways how to include as much transactions which do not belong to the tool. And yes, this is worst-case thinking, but I like to prevent stuff instead of correct it ^^).

2 Likes
8

Do you mean the early evmos days, where a token could be on the cosmos side of things, or the evm side, end you had to check the dashboard to look it up?

I am hoping/asuming that the mentioned single token representation does not only apply to ibc bridged tokens, but also to the aforementioned the cosmos/evm naming issue. I feel the evm extensions may have solved the UX a bit.

9

I have a little bit of context on this from my conversations with their team. Itā€™s not fully decided as far as implementation goes, but both the Osmosis and Evmos side agree that itā€™s possible to do because EVM wallet transactions use a different signature algorithm.

So a solution will probably involve some sort of agent that tracks this by identifying which transactions use that given signature algorithm.

Thatā€™s my very rough, high-level understanding of this!

10

I donā€™t see it.
what benefit does this have from what the current state is?
metamask integration is one thing, but this is way bigger than that. (for example injective has eth key signing, and didnā€™t need a EVM to accomplish it).

The prop mentions 4-5 RWA dApps might be brought over. There is no indication that any of them will move to this OSMO if this prop goes ahead.

I donā€™t see any part of this proposal addressing how we will attract evm-based dApps onto osmo, (as opposed to the 10+ evm compatible chains they can launch on today)

so without a killer app that requires this, it seems like bloat and added complexity, for no real benefit to the osmo user.

I donā€™t see how osmo + evmos will be a multiplier here, or how long the rev-sharing of all these new dApps (are there any) will payback the dev time required for it.

show me a sales pipeline with dApps signed up on this, and it might be worth it.

now it just seems like ā€˜cool ā€¦ we can put 2 building blocks together, wonā€™t that be funā€™

11

Maybe Iā€™m not understanding this point. But a lot of EVM based dApps are deployed in different environments and the incentive for this is that they get to tap into a new market/audience, in this case Cosmos via Osmosis. Osmosis would be particularly attractive as itā€™s pretty much the DeFi Hub for Cosmos and has tons of activity and is established as the interchain gateway.

Osmosis could also implement targeted incentive programs to attract dApp developers, such as offering grants, subsidies, or reduced fees for projects that choose to build on Osmosis.

Imo discussing how to attract dApps and users should only come after thereā€™s consensus on moving forward with this functionality.

1 Like
12

all we are going to attract is 2nd rate clones.

unless you have the size of BASE to attract them. at with those numbers, choice of VM isnā€™t important

13

Hmmmm idk about this. Iā€™ve talked to several L2 founders and had the same questions you had prior to their launches.

Looking back, a lot of them have gone on to do well with app deployments. Many of them didnā€™t even need to offer incentives, the mere fact that devs can tap into a new market was incentive in and of itself. The concern for devs typically is ā€œhow easy is it for us to do this?ā€ and if itā€™s not hard, they do it.

Osmosis is super well positioned to attract EVM devs than any other project in Cosmos in my personal opinion. My concern is actually more on the side of the performance of these dApps - will Osmosis be able to handle more activity, than how to attract the dApps.

1 Like
14

There are a few specific protocols that Osmosis actively wants to bring over that cannot / will not launch on Osmosis without an EVM layer (see: interop protocols as referenced in the original proposal).

Encouraging other EVM applications to deploy on Osmosis is also a nice goal, and I do think Osmosis is well-positioned to attract quality talent because it has something that nearly all other EVM chains in the ecosystem lack (liquidity), but itā€™s inaccurate to say that attracting random EVM devs to the ecosystem is the sole goal of this integration.

3 Likes
15

Looking at value addition, EVM is definitely a net plus if added properly on Osmosis.
But not if it comes with a great price for node operators :

  • will it break the validatorsā€™ uptime, like it happened on other networks that deployed the EVM module?
  • will it break state-sync, like it did on the Evmos network, where itā€™s been broken down for years?

Also, how is the evmOS team planning to make ICS-20 standard work on EVM, as, if Iā€™m remembering correctly, it didnā€™t work so well on Evmos?

1 Like
16

(Iā€™m not familiar with EVM/IBC interaction)
but couldnā€™t we deploy these on sister chain which has a ecosystem, and just use ibc/hooks or axelarā€™s gmp in these cases?

I just see this as a ā€˜additiveā€™ deal, instead of a multiplicative one

17

@whitemarlin The existing UX wonā€™t be affected by the addition of the EVM.

The only thing that changes is that with this proposal additionally EVM users can natively interact with the Osmosis protocol.

Concerning tokens, the Single Token Representation allows both Cosmos and EVM clients and tooling to interact with the same token. There is just one token balance that can be used from both the Cosmos and EVM interfaces.

18

Thanks for the support @RoboMcGobo. I especially think the revenue split is a fair proposal, since the share only applies to new users actually interacting with the protocol, so that both the Osmosis DAO and evmOS are mutually incentivized.

1 Like
19

I can confirm @RoboMcGobo response here.

20

Great questions @its5am. It would be helpful to understand which networks you are referring to.

We should clearly differentiate between the Evmos chain and evmOS:

  • The Evmos chain is a mainnet L1, that has been live for over 3 years and has to handle many legacy state and protocol changes of the stack.
  • New evmOS chains benefit from protocol optimizations that have been implemented throughout those years.

Specifically the state-sync issue on the Evmos chain is related to the massive data-base size that occurred due to the configuration of low gas prices and the permissionless contract deployments. For example, since then we added the possibility to permission smart contract deployments to whitelisted addresses only. As part of this proposal Iā€™d recommend to start with permissioned contract deployments too :+1:.

Concerning your question on ICS-20 standards, it would also be helpful if you could elaborate on ā€œit didnā€™t work so well on Evmosā€. You might be thinking of the first version of Single Token Representation, where the protocol kept track of Cosmos and ERC20 token balances. This is a legacy design, which has been improved in Single Token Representation v2, allowing any token to be represented as both Cosmos or ERC20 token and at the same time be compatible with ICS-20 transfers.

2 Likes