Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Federico Kunze Küllmer: Evmos – The Ethereum Virtual Machine on Cosmos

Episode Date: March 30, 2022

Leveraging the Cosmos SDK, Evmos is the first IBC-compatible EVM-based blockchain, bringing composability, interoperability, and fast finality to Ethereum. While much of the Cosmos ecosystem has embraced CosmWasm to deploy smart contracts, Evmos brings EVM capabilities to the Interchain and allows developers to write contracts in Solidity, the most widely used language in crypto. While the Evmos launch was halted in early March due to a critical vulnerability and a failed chain upgrade, the project is highly anticipated by the Cosmos community as it promises to bring speed, scale, and interoperability to Ethereum. This week, Sebastien was joined by the co-founder of Evmos, Federico Kunze Küllmer, to chat about the innovation that Evmos is bringing to the EVM ecosystem and the long-term vision for the project.This episode is an excerpt of an extended interview with Federico released on The Interop, a new podcast hosted by Sebastien Couture. To hear the full interview and subscribe to The Interop, check the episode links.Topics covered in this episode:Fede's background and how he got into cryptoThe early days at Tendermint and contributing to Ether MintThe delayed launch of the Evmos upgrade and how that has affected the projectWhat innovation does Evmos bring to the EVM now and in the futureEvmos' interoperability with other chainsBridges and the issue asset fungibilityHow sovereign chains will interact with smart contracts or addresses on EvmosWhat DeFi applications will be launched on EvmosStandout features of the token modelIs fragmentation on the Interchain a good approach?Episode links: Hear the full interview on The Interop podcastEvmosEvmos on TwitterFederico on TwitterSponsors: ParaSwap: ParaSwap aggregates all major DEXs and makes sure you beat the market price at every single swap and with the lowest slippage - paraswap.io/epicenterChorus One: Chorus One runs validators on cutting edge Proof of Stake networks such as Cosmos, Solana, Celo, Polkadot and Oasis. - https://epicenter.rocks/chorusoneThis episode is hosted by Sebastien Couture. Show notes and listening options: epicenter.tv/437

Welcome to Epicenter. The show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebastian Quichu. Today, I'm speaking with Federico Kinsekidke Kulma. He's the co-founder of EFmost, the CEO of the company that is driving that project, Tharsus, and he was previously an engineer over at Tendermint. He's sort of an OG in the cosmos and interchained ecosystem. This interview was recorded on, on a new podcast that I'm launching. It's called the Interop. And it's all about understanding the decentralized economic networks that make up the inner chain, the cosmos ecosystem. And I hope to get a better understanding of the topology of the internet of blockchains and the technologies

that make it possible. This is a podcast for developers and investors. And I hope to have really in-depth technical conversations with the people that I interview similar to the kinds of interviews that we do on Epicenter, but also discuss the long-term prospects for the interchain and Cosmos ecosystem. So part of the interview will be released here on Epicenter and the remaining third of the interview of the last part, which talks about the recent hiccups around the launch of Fmos will be released on the Interop Podcast. And so there will be a link in the show notes of this episode that takes you to the different YouTube channels and podcast apps where you can listen and subscribe to the podcast.

And I hope you'll subscribe because it's going to be a lot of fun. And we'll be diving deep into the cosmos ecosystem and everything that's going on there right now. Before you go to the interview, I'd like to tell you about our sponsors for this week. Paraswap is a multi-chain decks aggregator. This means that through pariswap, you can easily access the liquidity of various decentralized exchanges. The protocol automatically finds the cheapest liquidity for you so that you can trade knowing that you're getting the best price for your trade. Paraswap is also gas-friendly, which helps you keep your transaction costs low.

They also recently added support for avalanche, Polygon, BSC, and Phantom, and you can use pariswap directly in Ledger Live if you use the Ledger wallet. In addition to that, they're becoming a Dow. So if you've got some PSP tokens, that's something you can participate in. The Paraswap Dow just voted for the gas refund program, which will allow periswap stakers to get up to 100% gas refunds on their trades on top of their auto-compounding yield. You can join the Paraswap Discord to learn more at Paraswop.io slash Discord. We're also supported by Corus 1.

If your crypto assets are sitting idling your wallet, you're losing out. Start earning rewards and contribute to network security by staking with Corus 1, a staking provider securing $4 billion in assets in over 25 decentralized networks, including Solana, Cosmos, and Ethereum. If you're an institution or you want to run your own branded notes, Corus 1's white label, notice-a-service offering, leverages their high, available and proven infrastructure, enabling you to participate directly in decentralized networks. Head over to Chorus.1 to start your staking journey today. And Course 1 is also expanding their

team. And if you want to make your career in the exciting feel of crypto and staking, make sure to head over to Chorus.1 and check out their open positions. And with that, here's my interview on the Interop podcast with Federico Kinsekidma. Welcome to the Interop. This is a podcast about understanding the decentralized economic networks which make up the inner chain. And my hope is that my listeners will gain a better understanding of the topology of these networks, the technologies that make it possible, and the opportunities that it provides to investors and developers. I'm Sebastian Quichertz, I'm a podcaster and investor. I'm here today with Fedéko, Kuntzai Kulma, who's the co-founder of EFMOS and the CEO of Tharsus.

Thanks for joining me, Fedé. Hey, Sevasian. Thanks for having me today. I'm really excited to be part of the intro and also this new venture that you're starting. This is a new podcast. It's called The Interop. This episode is going to go out on Epicenter, which is my other podcast, but also go out on the Interop. So it's a bit of a cross-promotion here to get people in the Epicenter universe to also start listening to the Interop because there's so much. happening in the interchain ecosystem right now. And I think there's a lot of interest for it. And we've seen that with all of this new content coming out. And what I want to do with this podcast is bring more technical discussions.

So the kinds of conversations that we have on Epicenter, the very deep technical discussions, but that also go like kind of high level and looking at the ecosystem at like a 10,000 feet level, I want to have those conversations about the inner chain and the Cosmos ecosystem. But yeah, for listeners who aren't familiar with you, I mean, you've been, the tendermint and Cosmos kind of ecosystem for a really long time. You were like an early employee at tendermint. Tell us a bit about like, you know, how your background. I think also Sunny is the person who kind of got you hired at

tendermint or introduced you to the tendering organization back in the day. Like give us a bit of a background here and like how you came into into this world. Yeah. As you mentioned, I was one of the, I would say, like first employees at tendermint. But more importantly, I was also like one of the first entrance from tendermint. So I was part of blockchain and Berkeley as part of my semester abroad that I did on user Berkeley. And well, being a blockchain in Berkeley, Sunny had just dropped out during that semester and he started working at Cosmos, tendermint.

And Sonny saw my work that I was doing with the blockchain Berkeley organization, working with a Fortune 500 companies, developing smart contracts, et cetera. And he introduced me to the tendermint team that was working super hard back then. It was post-ICO. So they were like working super hard on developing all the functionalities of Cosmos. Back in the day, they started working on the Cosmos. They had Peggy and they also had, of course, Etherment, which is their precursor project of VEMOS. And they saw my work and, yeah, I applied for an internship and I started working with them.

And then once I graduated, I moved to a full-time position and relocated to Berlin. Yeah, because you were initially working from the San Francisco office, I think, and then you then moved to the Berlin office where you're now based. What was it like in the early days of working at Tendermint. What was the five there? There was super rushed. There were so many projects going on. There was Peggy, which was a former name of Gravity Bridge as well.

Etherment, Tendermint Core, Cosmos SECK, and Gaya, which initially was only part of the Cosmos SACA, but then it was moved to another codebase so that you can have like separation of concerns and the cosmos could evolve into its own particular codebase with different functionalities, etc. Like the ones we now see with gravity decks, etc. Yeah, so lots of projects, teams working on all these different initiatives, interns working on and everything back in the day.

When I joined full time, I was working on the Boyager wallet. I'm not sure if you remember that. With Jordan and Fabo, they were the first ones to introduce UI for Cosmos with the governance. We implemented also the ledger. the ledger UI to connect directly with the ledger cosmos applications that had just launched. Yeah, it was exciting times back in the days. And when did you start working on putting an EVM on Tendermint? I think you were part of the first kind of team within the Tendermint,

organization to start working on that project? So I didn't work exactly on Etherment back in the days. I was mostly working on either Voyager, Peggy, so Gravity Bridge, and I also worked on the Cosmos SEP. But when, so like initially Etherman, which was his first iteration of EVM on top of the tendermine consensus, tenderment core consensus engine. It was developed first as

an tendermine application, which is the base layer that the cosmos SACA now implements. And then it migrated fully to like a cosmos application, so a cosmos-based chain. And that took a while. And was spearheaded by Jack Sampling,

who coincidentally was hired to PM the Etherman project, and then once more resources were required for the Cosmos Hub, he switched teams and started working on that project. We were also working with Alex Bess. Yeah, Bess was the core contributor for a long time and also started working on Etherment, and then migrated entirely to the Cosmos SACA and the rest of the Tenderman Core. and basically he's been working on the full stack of Kossom's applications for a while.

So, yeah, I worked. Yeah, but so back to your original question. When did I start working? It was in 2020 when I was contracting for chain safe. So after I left Tendermaine, I started freelancing and working for different entities. And one of them was, one of them was, chain safe and I started working on Etherment because they had received that grant from the ICF to work on Etherment. So I want to get straight into Avmos here and I, you know, I heard you say on a community

call, I think it was a couple of weeks ago that what you're doing is difficult. And, you know, I think, you know, it's difficult enough to build to build apps. applications on blockchains. There's all sorts of things that need to be taken into account that perhaps are abstracted away in, you know, web development or like more mature development environments. There's just the fact that it's decentralized. You have to take all these stakeholders into account. There's the fact that, you know, like you have to keep the chain secure with like the validators or miners. And but you guys are adding like an extra complexity onto this, which is, you know, like marrying these two technologies that weren't made, like,

weren't made to work together initially, I think. And I'm coming at this with like, not very technical eye, but like, it seems to me that these technologies are, are not well suited to go together. Can you break down like why building an EVM on tenement consensus and, and then like, integrating IBC into that technology stack is so complex. So the main problem that we see in integrating not only to the call to tendermintz specifically, but to the rest of the cosmos ecosystem is a lot of support for Ethereum tools, Ethereum keys.

So for example, one very particular case that has been super hard for, us to like go through and we had to take we we had to make like really tough decisions in terms of like how can we improve user experience. I was the lack of support for Ethereum keys in the cosmos ecosystem. Because Cosmos only supports one type of key that is the ones that it's shared across the Cosmos hub, etc. So like when you create your address, it's always in that key format, which is a SACP 256K1. Coincidentally, if you also implements that key but has a different derivation for the private key to the address, so the address generated with the same key is different.

That results in just imagine you going to Kepler wallet and opening your tab, and then if you export that private key and then you import it to say Metamask, you have a completely different key, like a different address, so to say. that's one case. And then the other thing, just like, miss things. Like, for example, the address format on Ethereum is hex addresses like 0x, blah, blah, blah. Unknown cosmos, you have like Beck 32. So you need to create compatibility for the user to know or to,

okay, I'm now using a Cosmos address. I should expect to use the Beck 32 format. So like the ones that start with Cosmos or Evmos in our case or Osmosis. So you have like all these formats that are different. That's more like on the UX kind of thing. And then on top of that, you have the problem that in the tendermine consensus, it's BFT, so fast finality. So there's no concept of pending state.

So when you have to wait for the transactions to finalize, sometimes on Ethereum you have like transaction pending on Ether scan, like all this functionality that on Tenderman is is not there because there's never, I don't know, there's never been a use case that needs to support handling pending state because like the state is committed to. the chain. Yeah, it's not probabilistic like in like an Ethereum or proof of proof of work blockchains. So goes to the mempool, the transaction is verified internally and then broadcast it to the rest of the network and then the the transaction is finalized.

But on on Ethereum, do you actually need to have a probabilistic finality? So like a knock a motto consensus where that there needs to be like confirmations. for the transactions in order to be included to the heaviest subtree as well. I'm not exactly sure how Polygon works under the hood, but my understanding is that Polygon is an EVM chain on tendermint, right? What's different about Polygon and EVMOS, aside from the fact that maybe there's IBC on EVMOS? So the main difference is the architecture.

Polygon was created in a way to entirely support the Ethereum ecosystem and to create checkpoints to the Ethereum blockchain. So you can, even though you have fast finality on the tendermic consensus, you can eventually roll back to the previous to the previous blocks if needed be. So the approach here is different. And then I think they're working on a cost of SACA, but they're still implementing checkpointing. The staking approach is different. So it's not very modular. And I think they're working on like an SCK as well, a polygon SCK, so that they can have more chains that are EVM compatible in their ecosystem.

But the modular approach they have is very different from the ones that we can find right now. on cosmos. Because they don't need to run into this issue of like, oh, compatibility between cosmos and Ethereum. And they took the approach of like creating the or drafting the entire architecture version Ethereum. So they don't have to handle any of the cosmos cases. Okay.

Yeah, understood. And when Ethereum starts moving, when the EVM, I mean, like basically Ethereum 2 is going to be fast finality proof of stake. Are there aspects of like the ETH2 EVM or whatever that should look like that make it easier for EFMOs to implement where you don't have to take into account this technical debt that has to do with proof of work? So most of the components from proof of work, we actually are not relevant to us. So, for example, on the JSON RPC, the miner namespace, or setting the coinbase address for the miner, like, all that stuff.

So the valider itself is the one that is using all these functionality itself and it's all handled through the cosmos component of VMOS, which are the cosmos as a K modules. whereas on Ethereum it's all handled through like the internal geth architecture or like in this case yeah the ETH2 architecture so like one big thing is like even though Ethereum might evolve to eth2.0 we still need to ensure that compatibility with some of the existing tooling and so there are two approaches here. Either you reduce compatibility with say Metamask or other EVM explorers, clients, et cetera, tools, or by, for example, just implementing the EVM and you define your own, say, JSON RPC endpoints and whatever, which will cause all these clients to break. Or you start, you need to all the time try to catch up with the latest developments or the latest versions

supported of MENA on Ethereum. So there's a double effort in terms of like supporting all the Cosmos ecosystem tooling, supporting all the Ethereum ecosystem tooling and trying to catch up with whatever the latest state of Ethereum is and implement new functionalities on top of that. So our team, our team, which is fairly small, is able to, quickly adapt and catch up with Ethereum and implement all these new functionality for the EVM, for the EMS-EBM, and also implement new functionality in terms of like token economics, interoperability, et cetera. So we're looking to hire more core engineers and also full-stack

engineers that can help us like merge and marry these two ecosystem into a single user experience that is really smooth for the end user. Yeah, so let's talk about this. So there's lots of things here. I think that need to be unpacked. So the user experience, the ecosystem of applications, the types of features, and you know, you talked about tokenomics and

Evmos had a novel approach to launching the chain, which was the rec drop. It's been covered extensively. And I don't want to go too much in the details here. But, you know, just for, you know, I think most of our listeners will be familiar with the fact that there was an attempt to launch FMOs a couple of weeks ago. That attempt, well, for lack of a better term, it failed. And we'll get into what happened later in the interview. But what is the current state of affairs and how, you know, how does this?

affect, you know, effectively, either the, the enthusiasm around the network launching. And have you seen any evidence that what was like a highly, I think, hyped project with a lot of enthusiasm? Have you seen any evidence that that is going away or is the community, you know, is the community like confident and sort of supporting you in your efforts to relaunch the chain? The upgrade, as you mentioned, didn't go as smooth as we wanted to. There were, like, different bugs, especially because of the lack of support from different, like, Cosmos tools. And there were also, like, some edge cases that we had to handle in terms of IBC, because now besides having, like, all the functionality on Cosmos, the functionality on the EVM, we also need to handle all these edge cases for, for IVC.

And yeah, definitely I think the hype has lowered a little bit. I am confident that once we launch again and we restart the chain, the hype will continue and

but mostly because users will be able to claim their tokens through the dashboard, super easy. And will be able to like stake their tokens natively and there are also a lot of projects already trying to build on deploy in Avamos and also like a few of them are creating a few earth drops so that the community can also like benefit early on and and I think the earlier the users start

to stake and use your tokens for LPing etc. and the quicker the hype will return. I think it has also been really humbling for us for the team, so then we're not here for the hype, but we're also like trying to build as much as possible and try to, I don't know, improve our processes, improve the functionality that we want to bring and ensure that we implement the changes.

And this is one key difference with other EVM. ecosystems, I believe, is that we are not only tackling this from a like core protocol perspective, like the infrastructure that supports the smart context, but we're also trying to push for products that support the protocol. So like the dashboard, we've been closely working with Kepler in order to support Ethereum signing. We are adding, for example, Metamask support for cosmos transactions. so that users can use their Metamass wallet with Cosmos and Ethereum.

So like trying to create this user experience natively, and we need to ensure that this is not only supported on the protocol side, but it's also supported on the product side. And I think the protocol itself was ready. I think what was missing was more QA in terms of like the tooling and the product itself. And how are you doing through all this? How are you holding up through this ordeal?

Yeah, it was hard during the first week, I think. But our team is also very supportive and the community is very supportive. I think a lot of people were super hyped and also the price of the token and whatnot. But for the ones that know us, and we've been working and building for so long, and we were the only team that was able to finally launch this after more than six years already. So, yeah, we went back to build and be able to support these new functionalities that we wanted to add and go back to the drawing board and test every functionality that we wanted.

So, yeah, I've been able to hold up with the support of friends, family, and also the community that is supporting us. But I think once we restart the chain, it's going to be like the best user experience you will see. Yeah, I'm really, uh, we'll talk about like the launch plan and everything towards the end here. But yeah, let's, let's dive into, uh,

you know, some of the things that EMS brings in terms of innovation to the EVM, like currently or like when the chain launches, but then also, yeah, into the future and the roadmap for the chain. Yeah, can you break all that down for us? Yeah, so we now have a bunch of projects that are looking to deploy to EVMOs in the first week or two after restarting, including AVE on other Blue Chief projects.

And we have a lot of new projects that are deploying into the EFMS ecosystem. Because they saw the potential of like the new token, the innovative token model that we created. So there are multiple branches in terms of like the future roadmap that we want to implement. One of them is of course called protocol like what is the chain going to support in the future. Besides just AVM and they do. default interoperability that Cosmos allows you.

And then the other side is like, what are we doing in terms of products in order to support all these use cases? And in terms of the protocol, we've been also like working closer with Celestia for Savimones. And this is something that we're really looking forward to implement and eventually deploy once Celestia is ready, which is a settlement layer for Celestia roll-ups. So it's basically our roll-up on, like supporting EVM roll-ups on top of Avmos EVM. And that's one thing.

The other thing is working on interpretability. And interpretability, not only in the sense of transferring assets, we are already supporting ERC-20 tokens to be transferred in and out from the FMOS chain, but we're also looking forward to enable interchained composability so that chains like Somalia or region network who have specific use cases targeting Defi can directly call smart contracts deployed in Evmos and make sense of that data by unpacking the events and then realizing, okay, like here's the event data that was logged on the EFMO smart contract. What am I going to do with that?

And then, like, they handle, like, specific use cases. Like, for example, on some earlier, they can rebalance OPE positions or work directly with AVE. So this brings a lot of benefits in terms of reduces latency. If you're using gravity bridge or any other bridge existing, any existing bridge currently deployed in the ecosystem, because IVC will drastically increase the latency. and then the transaction fees will be way lower. So I expect a lot of interest in the functionality from other teams in order to support communication directly with smart contracts. And that's one thing.

The other in particular is NFD, NFT interoperability. We're also working closely with the Stargays team in order to transfer NFTs. from the EMS AVM into the Cosmowasam environment that they use. And so, like, making interoperable NFTs is going to be something huge for the rest of the ecosystem and for GameFi. In particular, so that we can support application-specific blockchains or application-specific eBMs that are directly sharing security with EVMs, for example, and be able to directly use this functionality to transfer NFT assets.

And yeah, like that's more or less what we're doing. And in the future, we're also going to be supporting cross-chain NFT like delegate calls from one chain to another. And then, yeah, once we implement that, we'll be able to share composability between EVM chains. So that a chain that is on a smart contract that is deployed on EFMOS can communicate directly with a smart contract that is deployed, for example, on Kronos or other EVM chain that will be deployed in the future. So I really want to dive into this interoperability aspect because I think there's different components of it that maybe, at least I don't fully understand. So if you're used to using sort of interchain or IBC assets, you can move assets from one chain to the other. So if you have assets on, you have like atoms, you can move those atoms over to osmosis, for instance. And then those atoms live there.

And then you can move them back to another. So from the user perspective, it's seamless. And I think like people kind of understand that once they've used this. it. What's that going to look like for EFMOs? So I, the way I'm thinking about is like, okay, so you'll be able to move assets outside of EFMOs, but these are not IBC assets or like ERC 20 tokens or kind of EVM tokens. And then what's the interaction with other EVMs? So what, you know, Ethereum or Polygon? or how does that how does eVMOs create intrafability also with those chains so the emmos interoperability components are yeah they're they're multiple and the main one of course is

ivc in the in the cosmos ecosystem so ivc allows us as you mentioned to transfer native assets from the cosmos from osmosis directly into the evmos but unfortunately the the the native functionality of IVC doesn't allow conversions of those tokens directly to the EMS-A-VM. So you need to create sort of like a mapping between like EURC 20 tokens and Cosmos IBC tokens. So for example, like a Cosmos hub atom or an osmosis token that has been transatlose transfer over via IBC, how do you represent now those tokens within the AVM and how then those tokens are bridge over, which is the second component I want to talk about, how are those

tokens now bridge over through their ERC20 representation to other chains? And that's going to be through Nomad and KNEX and other bridges that are deploying on EVMOs. So we're going to see an influx of all these EURC20 tokens. from all these different chains, Polygon, Avalanche, and Ethereum, of course, Moon River and Moonbeam to the Eamos and Cosmos ecosystem. And then those tokens, those ERC 20 tokens, will be able to be converted to the Cosmos IBC representation

so that they can be transferred over to Cosmosis hub or Asmosis. So it's going to create a lot of liquidity. So we expect EVMOs to become the main point of entry from all the EVM ecosystem, for all these assets to come through these ridges to EFMOs. And then through this functionality that we're allowing these EURC 20 tokens to be converted, those tokens will now be able to be transferred via IVC to the rest of the cosmos ecosystem. Okay. So let's just take an example here. Let's say I have USDC on Ethereum or even Polygon,

any EVM chain that supports USDC. I'll have to move those through a bridge, which will either, so right now you've talked about Nomad and Connects. So those are two separate bridges that will be EVM-E-M-E-M-O-S compatible. Move those assets into EVMOS, And then from there, you can take those USDC assets. There's some sort of conversion that happens that allows you to move them into the native interchain assets that we're all used to moving around. It's like changing the address format more or less.

You're changing the format for how the token is represented on chain. Either it's like an ERC20 token format or it's a Cosmos token format. Okay. And will those be fungible? Like, say you move from Connects or you move them from Nobat, are those going to be fungible once they're in FMOs? Yeah. So there is a direct mapping. So governance approved token pair.

So that the token pair is just a mapping between the cosmos and the ERC 20 asset. So that there's only one canonical representation. for say WEth on Ethereum for USC so that there's like only one token so that this ensures fungibility and then this token will be able to be transferred via IVC to other chains. Okay. And its fungibility also insured, so they're insured via these two bridges. but is it in short, like is a polygon USDC or a polygon wrapped eth equivalent and fungible to a Ethereum wrapped eth once it arrives in EVmos?

Or are those still kind of separate tokens? So the fungibility needs to be, the fungibility between like all these bridges is something that we're currently working with multiple teams. Frax is already working. It's also deploying on EFMOs. And so, yeah, like, as you mentioned, there are going to be, like, multiple bridges. It's the same as with, it's the same as a problem with IVC and fungibility. When you relay the same token via different sort of like IVC routes,

the tokens are not fungible because there are different security guarantees in all these different chains that the token has passed through. so that someone needs to basically assume the risk. And having, I wouldn't say like a canonical bridge because it's not maintained by the team, but there's like a preferred way of routing all these different chains, has different options on security levels, also helps in terms of fungibility. I would expect different also like defy protocols, like curve or I think it's Kinesis, the name of the project that is all. also going to do like stable coin AMM.

So, yeah, to handle all of these fungibility issue. Yeah, I was talking to the Kinesis guys the other day, and it seems like they want to address this fungibility issue, which exists, like, it's independent of utmost, right? This exists already in the Ethereum ecosystem, and there was some debate around, I think it was a couple months ago, where, like, about which bridges should be allowed on osmosis. And, like, Sonny Waden with, like, his opinion, which was, we need to limit, or, like, at least for now, we can't create an experience where there's all, these representations of the same assets, which creates like a user experience that's degraded for end users, like we've seen on Ethereum, wherever you have like 20 different representations

of USD assets, for example, like on the same liquidity pool, or like on the same, like on Uniswap, for instance. So why are there two bridges? Why nomad and connects and why not like a canonical bridge. So Nomad and Connects are able to provide, it's sort of like the same bridge under, like underlying bridge. It's, uh, Connects is using like Nomad infrastructure, but there are different options for, um, in terms of speed of the transfer, in terms of like, um, because it's an optimistic bridge. And there are different like pros and cons of using like an optimistic bridge in terms of latency or like how like if the transaction is optimistic and then you you have these uh a period that you can that you can challenge basically the transfer um so they're they're more or less two sides of the

same coin um in terms of like using the same infrastructure by offering different like options to the user okay and will what about the um sort of interchain accounts and the ability for like an address on cosmos or on osmosis to control addresses and smart contracts on Fmos. What is that going to be possible? And what kinds of things does that allow? Yeah. So interchained accounts is a functionality that we're really interesting to work on.

We wanted to implement it for for main end. but unfortunately the IVC release wasn't ready. So one of the cool things that we want to support is, for example, you have all these funds, all these validers that have tons of atoms, tons of osmoses and other chain and other tokens. But how do you manage the tokens safely in an organization right now on cosmos? You need to create a multisig, like a two out of three, and there's no UI for it. If you've used the Cosms Multisic, you know the pains that I'm explaining to you right now,

because it's really hard. We've been core contributors and core engineers of the Cosms ecosystem for a while now, and even us, we have an internal guide of how to make a chance for, with the Cosmos Multisig, which only is supported on the terminal CLI. Yeah, this is a huge pain point, I think, in Cosmos. It's a huge pain point. And one of the big things that we want to support is for accounts on the

Cosmosis to be able to manage on assets on, for example, on Onusis multisig. So you can have the same assets and, You can just use a diagnosis multi-sick for everything and manage your cosmos, coins, your, your osmosis, your E.RC-20s, and yeah, like, have most tokens as well. So it's going to be like improving the user experience is something that we really care about. And using all these interoperability functionalities to also benefit the rest of the

cosmos ecosystem, I think it's going to be like a key component here. Yeah, I mean, that being able to use a product like NOSIS Multisig on, on Cosmos would be just like amazing. I think, you know, they've really nailed the multi-sig UX and feature set. And I mean, I'm also kind of surprised that no one's built this already on, on Cosmos. Maybe it'll come. I mean, like, you got the guys working on Dowdow and there's like some, you know, multi-sig there, but it's kind of clunky still, and the U.S. isn't great, and you can't add addresses. The potential is there, but it's not a production product.

Yeah, I think you can in the contracts, but the contracts support those calls, but you still have to do, like, a, you know, command line thing to get that to work. Yeah. So what will be the defy component? What kind of defy applications will be launched on FMOS? You mentioned AVE earlier. But are there native projects that are anticipated to launch there? And I think broadly, what will be the defy experience on FMOS and how will it be different from what we're used to in Ethereum?

And maybe how is it different from osmosis? What does it bring to the table? For the team, it's more or less the same, but now it enables them to, so for all of these chains to access the token directly via IVC, and for the token to be transferred via IBC, which also provides more liquidity to the project. Additionally, you have the token model that allows users and users for all these protocols to spend 50% of the transaction fee. And those 50% transaction fee goes to the validers and 50% of the transaction fee goes to the developer team. So the contract owners. And so like that is able to fund additional sources, like provide additional funding for the team. That's more like why is it better?

It's able, it has lower transaction fees. It has additional liquidity. sources, so from all these EVM chains and also from the Cosmos ecosystem. And with the new interchained composability component, as I mentioned before, other chains will be directly able to interact with these smart contracts via IVC. And also the smart contracts on EVMOs will be able to call the other smart contracts that are supported on the EVM, on the FMOS EVM, on other chains, for example. So you don't need, you not need to fragment composability at all.

Okay, got it. That's the one thing I remember hearing about, but I forgot it, is that transaction fees can go in a defy application on FMOS, transaction fees can go to the liquidity provider, but they could also go to, sorry, not transaction, but the swap fees can also go to the validator. Yeah. So the key thing here is normally on Ethereum, and this is also a key difference with the rest of the EBM ecosystem is on Ethereum and other EVM ecosystem, if you're paying the

transaction fee, that transaction fee is going directly to the block proposer, either the minor or the valider. Here, instead, the main difference is that 50% goes to the. the developer and then 50% goes to the blog proposal. To the developer, right, to the developer of the contract, of the contract, yeah. Yes. What this create effectively is a decentralized marketplace and decentralized app store where the users that are instructing with a, with a defy application,

are paying 50% of the transaction fee to the developer and 50% of the transaction fee to the block propulsor. And it's not that they are paying an extra 50%. It's just that the fee that they're already paying, same as Ethereum or other EVM chains, is now being split between the two organizations or the developer and the block propulture. This ensures like alignment with their protocol itself,

so that the validers still get the rewards that they are generated through the validation of the protocol and proof of stake, plus they gave 50% of the transaction fees. But now you're also incentivizing all these developers to come deploy their applications to EVMS. And this creates larger, it's like chicken and egg problem. Like how do you bring in more users if there are no applications? And through this, you're also incentivizing new developers to come in and deploy through these what we call a Doppstore model.

So this is a really novel I think functionality in blockchain generally. I don't think that there's any other chain that does this where the smart contract developer is also remunerated for transaction fees.

Do you think this is something that other chains will adopt? Is this something that you could see kind of spreading in the EVM ecosystem as well? Yeah, I think there are a lot of, I mean, so if you think about the way of funding a team right now, the teams either raise funding for the company, like traditional sources of

funding, go to VC, go to like early angel investors, and they provide like, yeah, they dilute themselves in order to attract new investors. And then you also have like the token model where they launch a new token and they distribute that and the team holds a large percentage of the token. But if you think about it, it hasn't been like a sustainable,

long sustainable funding mechanism that is directly correlated with the usage of the application. So the more users interact with the application here on EVMOs, the more transaction fees the developer will get. So it's a long sustainable and it's in parallel to these two other funding models that I mentioned before, but it's a more like it's a healthier one in the long term because it's a it allows to generate continuous revenue to the developer team. Yeah, it totally changes the economics, I think, for the developer team.

And when a developer launches a contract, are these parameters that you can set, say, okay, I want to take like 50% or I can take less or like if I don't want to have any other transactions, like, you know, different contracts might have different ideas about how these fees should be repetition between the minors or the validators and the contracts or the teams. Is this like by default or is it something that you can set up? Yeah. So it's set by default or like this is something that we need to we need to still analyze with the core team. But for now, the current specification that we have, it's set in by default. But what you can do, as a developer is if you don't want to actually earn these rewards, you can set the address

that you want to, instead of you, the developer team receiving 50% of the transaction fees, you could redirect those tokens to the community pool if you want, or to the validers itself. So you can get the valider address and then reward the valider or if you want to allocate those tokens to like the entire pool of validers. You can also distribute them to the entire pool of validers. So there are different options here. And you can even, you can even like set another contract developer address or fund another contract through these mechanisms. Yeah, or you could fund some charity or something like that.

And that's totally up to the developer and they can change the address whenever they want. Does that, I mean, do you think that, so let's say we have developer, because then you, it seems like you get in this situation where developers are competing also for their transactions to get processed. So like if a developer is awarding more of the transaction fees to the validators, so awarding less transaction fees for themselves, then there may be an incentive for the, those transactions to go through first. Is that something that is taken into account here, or is that not really coming to play? So at the moment, the tenderment mempool only supports first in, first out queue. So you send a transaction with, say, 100 tokens in fees,

and then you send a transaction with a thousand tokens in fees. The one that was processed before is actually executed before. Unless you run some like fork of tendermint where you modify the memple internals completely, it's not currently supported. But I think the next major tenderman version is supporting like prioritize queue. And we'll definitely need to take that into account. but the current model doesn't support it straight ahead. But yeah, this is something, well, depending when these functionality is released,

we'll need to take into account. So if we deploy this functionality first, we don't need to account for this particular case. But once we want to upgrade to the latest tendermint version, we'll have to consider this for sure. Okay, yeah. And what other kinds of innovative things is EVMOS, are integrated in EFMOs that don't exist in other EBM chains or what other innovative things that are you implementing in the token model?

So the other innovative thing that we took from existing DFI applications is the concept of usage rewards. So if you read the RectDrop token model, you can see that we erdrop tokens to users on Ethereum based on the gas that they've spent, which is called the gas drop model. The more you spend on gas on different contracts, the more tokens you get inirdrop. And so we wanted to implement this on the protocol level for users that interact natively. with different contracts. So what we're doing is taking the LP incentive model that asmosis has, so like incentivizing the liquidity pools, we're implementing this but for smart contracts.

So the more gas you spend on smart contracts, the more usage rewards you'll get. So you're incentivizing certain contracts. So for example, bridging could be incentivized or AMM swaps could be, or like, I don't know, like an NFT marketplace could be incentivized. And this is all voted through governance. So the community votes for which are going to be the contracts that are going to be incentivized. Yeah, you define a number of weeks that you want these incentives to run.

And then you, yeah, you're basically incentivizing all the users that interact with this contract. So it's going to be like a growth hack mechanism because now, if you have this contract that is incentivized and also the developers are getting transaction fees, the users are getting tokens just for using the application, but they're paying with the transaction fees, right? And then half of those transaction field will go directly to the developer team, which will attract more developers, more contracts and incentivize, and more users interact with the protocol itself. So it's creating a positive reinforcement cycle in which you are attracting more. more developers and more users over time.

So, you know, are you confident that EFMOS will also act as a growth hacking mechanism for the interchained IBC ecosystem? Because, like, you know, as a developer, it makes sense to go deploy your contract there. there's going to be a number of blue chip a number of blue chip Ethereum DAPs that are going to deploy there and like AVE is one of them the liquidity it'll be

pretty seamless to move liquidity in and out of EFMOS. Yeah, Kepler is supported natively with Ethereum signing Metamoth is supported natively with traditional Ethereum signing plus custom-assigning transactions through EIP-7-12,

which is a meta-transaction standard. So now with Meta-MAS, you can sign IVC. So you don't need to add any new functionality to the existing project or to your existing client. You just need to support EIP-712 if you are using like a UI, for example. Yeah, I think it's going to be huge for the ecosystem because attracting new developers and new developers, and new projects in general and new users that are native from the Ethereum ecosystem,

it's also going to attract more tokens, more use cases for the interchained ecosystem. Yeah, I was part of the core IBC team and were close with other teams in the ecosystem. So all these functionality that is going to be deployed on EVMOS is going to be available to the entire Cosmos ecosystem through IBC. And this is something that we're not going to try to, for example, like capture all these value only for the EFMO's chain, but we want all these equity to come into the cosmos ecosystem, all these different use cases to come into the cosmos ecosystem,

all this new functionality from the Ethereum tool used from these Ethereum tooling that already works and is already supported by multiple teams is going to be available for like the one that I explained with a multisig is going to be available for the rest of the our cosmos ecosystem through interchain accounts for example yeah and all of the Dow tooling and all I mean all all the yeah I mean it's just like solidity in the EVM have such an advance I think like any other other blockchain in terms of tooling

yeah I think this makes so much sense. And something I tweeted about just before the call and that we're really excited to work on is creating like a product for new products to make it super easy to deploy contracts to EVMOs, but also air-dropping new tokens to EVMOS takers, to Gus Gossler contracts. So the same that we implemented for the gas drop on the reg drop mech and the red drop will be available for users to just like select those parameters, filter the content, like select some filters, like leave out some centralized exchanges, select a few validers they want, set up minimum amount, set up a minimum amount of gas they want, select IVC transactions, governance participation. and then you get a CSV file or like an spreadsheet with all the information of all the addresses

that is publicly verified because you will also get the amount of the list of queries that you can also run manually in order to verify this and then you'll be able to urge off the tokens directly to those addresses by using it directly on the on the EVM. Okay, this is this is this, This is huge. So, I mean, you're, essentially, you've got to build all of this data scraping infrastructure to do this, right?

I mean, this is a centralized tool that you're describing. It's not a, it's not an on-chain tool. Yeah, it's essentially, it's basically, it's basically the mechanism that we implemented already for the red drop, but turning it into a product, not only for ourselves, because we already implemented the, the, the retro mechanism and we also already selected the contracts, the users from that had staked on osmosis and cosmos have, etc. But we're also supporting this mechanism for new projects I wanted to apply to EFMOs to be able to use this tool without any, like, without just spending months and month into like selecting the contracts and stuff.

You just need to select the contract address. You just need to select like, oh, what's a minimum amount of gas that I want? And then you can run these query, big query, of course. And then you get all these addresses and you get the amount of tokens that you want because you also be inputting the, you also provide as an input to the amount of tokens that you want. And then you, yeah, you just get the addresses. Okay. That's interesting.

I mean, that's a, that's a product that you could, you could probably, you know, charge for like a separate as a, even like a separate product. So, you know, I, I want to, I want to zoom out a little bit and talk a little, talk about the interchain smart contract, uh, landscape, if you will. You know, there is like, Cosmwasum has a decent, decent size foothole, I think, in the Cosmos ecosystem with like Juno being, you know, one of the main chains where people can deploy as Cosm while. contracts. Other chains are also implementing cosmwasum. Yeah, Terra,

Osmosis. Yeah, Terra, Osmosis Club, I think, is probably also going to do it at some point. Or key chain. You know, then we have a Goric that a lot of people are, you know, very excited about. And now, EVMOS. I don't know. I mean, my feeling is that this fragmentation, it could go either way. The fragmentation could be good for the ecosystem because it creates a lot of different types of applications and use cases. But I think that alignment

also helps accelerate development because everyone is kind of focused in on one thing. And my thinking around this is as the ecosystem gets bigger and lots of new people come into the ecosystem, Is this bizarre approach that Cosmos has always kind of stood by going to work in creating a competitive ecosystem where people can actually, like an ecosystem that can compete with, you know, the likes of Solana and, you know, Ethereum and some of the other big layer ones? I think a lot of these chainsholds specialize in different use cases. you have of course a base layer infrastructure

like the like the FMOs, the Junos, et cetera, but you will also see like application-specific chains that have BMs that are specifically targeting a use case like osmosis cosmos environment

is probably not going to support say, I don't know, random governance smart contracts or or whatever, like NFTs necessarily, that's going to be probably stargaze, but an osmosis is going to have

causal environment for only D5. So it's kind of like, even though they have like the same application, underlying application, they're kind of like narrowing down on the use case according to what they're already implementing on their chain. That being said, I think there's there's also going to be alignment between all these different protocols through IBC.

Even the ones that not necessarily have the same runtime or same VM like Cosmov and Evmos that implements the EVM. So once we implement the functionality for smart contracts on EVMOs to call smart contracts on Juno or any Cosmox chain, like the collaboration we're currently working with Stargis for NFTs. It's going to be huge because then you'll have the same standard for calling smart contracts on both chains. And that's going to be creating a huge alignment where the chains now don't actually need to compete necessarily, but they can also access benefits from the other counterparty chains that they're connected to. So it won't matter what the underlying runtime is accounts on the interchrain are going to be able to control contracts regardless of what the runtime is, is what you're saying? Yeah, there will be able, like contracts on the EVM will be able to call contracts on CosmoWASM and vice versa.

I think assets like CW20, which is the costum, was more representation of tokens, are going to be compatible with ERC20s on the EVM. And both of them are also going to be compatible with the Cosmos token format. So like creating standardization and creating like interoperability components between all these different runtimes and EVMs. It's also going to help solve many use cases and it's going to be able to provide more functionalities. And something that we haven't even talked about is like interchain farming. So farming on the interchain is something that I'm particularly very, particularly very, very interested in.

And it's a model that I call interchained workflows. where you set up a workflow for one contract to be called in one chain, which calls another contract on another chain or in trucks with osmosis or whatever. You create the LP pools, and then you're creating the same hype that you had on Ethereum in 2020 with D5 farming. But you'll now expand that to the interchain because of the interoperability. That is going to be huge. that is going to be huge

and in order for us to support these use cases we need to provide interoperability between these different VMs different VMs and this is something like our team is personally really excited to work with

and happy to work with any other team and that's why we don't see like for example Juno or any other Cosmo Watson chain as like competitors or anything like if we are able to reach assets and rich contracts through IBC

is going to create so much, so many opportunities for all the end users. Yeah, I mean, I fully, I fully, I'm fully on board with the idea that interrobability just creates more value everywhere, which is why I'm, I'm so bullish on, on cosmos and the interchain and what IBC brings in terms of, you know, all these ecosystems being able to,

to interoperate. And we haven't talked about like Pocodot also, like the ability for, you know, poca dot assets to move in and out of the inner chain. Yeah, I think like interoperability is, is, uh, is the way that we're going. Yeah. And on evermos will be a point of entry for all these pocketed out from, from us in the, um, pocketedot ecosystem and also from Kusama. I'd like to kind of close this part of the conversation for now and move to, you know, what happened in the days leading up to the launch and after the launch. We talked about this earlier that the launch has been now pushed back. And so for those of you listening on Epicenter, there will be a link in the show notes

where you can get the rest of this conversation. So you'll have to come to the Interop Podcast, wherever you want to listen to it, whether on Spotify or on your podcast player or on YouTube, and you'll be able to listen to the rest of this interview. And I hope while you're there, you also subscribe so that you can get all of the episodes as they're released.

Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the a show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with

us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.