CosmWasm is a smart contract engine that improves based on the Cosmos SDK and IBC. It’s the only cross-chain interpretable Virtual Machine besides the EVM. If you think of EVM as a Mainframe computer, the CosmWasm VM is a cluster of computers which can communicate through IBC。 CosmWasm, along with Tendermint, Cosmos SDK, IBC are the the core technology stack within the Cosmos, any chain based on the Cosmos SDK can implement CosmWasm without changing the existing logic. CosmWasm currently supports Rust, and other languages outside of Rust are being worked on today including Golang and vlang. So the main takeaway is that the CosmWasm is a framework that allows developers to make secure and composable cross chain applications, without having to launch an entire layer 1 blockchain; thus, significantly removing the barrier to entry for apps and tokens to launch on Cosmos.

We have seen the number of blockchains running CosmWasm has steadily increased over the last six months to now include more than a dozen mainnets with total values amounting to 4-5billion dollars. Terra of course has been the main beneficiary for the CosmWasm, with the majority of developers having experience in CosmWasm development and majority of assets being CW20 standard (CosmWasm standard), with total TVL being ranked No.1 in Cosmos. However, the recent collapse of UST and Luna, brings catastrophic effects to the system. More and more developers decide to move from Terra to other CosmWasm supported projects, such as Osmosis, Juno, etc.

We have mentioned above that the CosmWasm is the core module of the Cosmos, then what is the module? So CosmWasm itself is an SDK module that any chain can implement if they are built on the Cosmos SDK. A module simply contains the business logic for specific applications. Each module is unique to their specific applications which contains their own business logic. Given there are different types of modules, such as CosmWasm, Governance, Staking etc, with their own unique use cases,  how do they actually compose with each other? They are composed through the SDK core which allows developers to build out their app-specific chains and opt-in the modules as they see fit. Also, the modules are available for all developers within the Cosmos ecosystem. The chain can choose the modules that fits their own business logic and add more modules for the ongoing development, which simplifies the stack and allows the developers to select from a diverse set of composability between modules. This is the core vision for the Cosmos, a framework of sovereign blockchains who can independently build out modules for themselves and deploy them to the Cosmos SDK.

This highlights that the CosmWasm further strengthens the IBC functionality by allowing IBC to be more dynamic and iterative. As mentioned above, all the new functionalities/ development are in the form of new modules, then who are responsible for these modules? The majority of modules are created and maintained by the Cosmos SDK contributors or other Cosmos core contributors. Then it's the job of the Cosmos Hub team at Interchain GmbH to review, test and integrate these modules before releasing  Gaia code updates and communicating the network update with validators. While software release and upgrade includes launching and running public testnets to simulate upgrade proposals with a validator set from the Cosmos Hub and chain state that mimics the live Cosmos Hub. Finally,  CosmosHub validators will need to prepare for the upgrade and upgrade the nodes at the right height or configure Cosmovisors to run the upgrade automatically. Although a lot  of work has been done by Stargate to improve the existing upgrade process, it’s still very difficult. The upgradeability is very manual and requires a lot of time and coordination between the chains. This becomes a bottleneck with scaling IBC given it requires more coordination efforts the more connection a zone has.

So if we think about EVM is a legacy VM, and Solana is a VM is built for vertical scalability, then CosmWasm is a VM is designed for the cross-chain horizontal scalability.  CosmWasm VM plays a very important role in cross-chain VM and strengthens the IBC functionalities.  With the upcoming “Inter-chain Accounts” and “Interchain Security” launch, we will see more and more projects begin to implement the  CosmWasm.

Compared with other VMms, what are the characteristics of CosmWasm? Firstly, it should be the security, CosmWasm thinks the EVM and Solidity has been riddled with attack vectors built into the design. While CosmWasm can prevent the majority of hacks in Solidity such as reentrancy attacks, by design and provides some great experience to migrate contracts rather than the “library contract” model in Solidity; Also, there exist business logic errors in Ethereum. Mistakes in if conditions or loop guards can leak millions. The loss of $90million USD for the Compound is due to  using < rather than <= in an if statement. CosmWasm can make testing at different levels (unit, integration and full stack) to prevent this problem; Thirdly, in terms of performance and costs, the high gas fees of Ethereum is caused by the limits on the  block/gas costs, while CosmWasms vision is similar to ETH2.0. There are some other features including Lock-in and composability. If you decide to build your own sovereign blockchains, when it becomes too large and you can switch easily without having the locked-in issue in Ethereum. You can launch a new CosmWasm zone and iterate on new multi-chain protocols as CosmWasm contracts and allow users to migrate to new chains while still maintaining the first class connection to protocols on the original chain.

How about compared with Cosmos SDK which is one of the top blockchain construction kits. Cosmos SDK was built in native code in Go and allows developers to quickly wire up modules from many resources to produce power, application specific chains. Of course, if you are building a new consensus mechanism, or overhauling the fee handling model or integrating GPU to compute engine, then Cosmos SDK should be a better choice, while most of the applications/projects would benefit from coding from CosmWasm. With the launch of interchain, we will see more and more projects will be deployed on CosmWasm, in the form of contract consumer chain (vs custom consumer chain), the consumers chains will have full security from the Cosmos Hub and have full access to the IBC and Cosmos ecosystem. Rather than having its own validators sets, consumer chains will rely on the validators from the Cosmos Hub to validate their blocks, hence no chains are required. Of course you can migrate to other chains or build your own sovereign chains later on; In terms of composability, we mentioned above the Cosmos SDK works as the core to connect through different modules, then how modules interpret each other ?If there are only a few modules within the chain, it’s not difficult. How about there are multiple modules for different chains? In this case, CosmWasm and the upcoming interchain accounts module would provide the solution. There are some other benefits such as Upgrades and migrations problems, we will leave it for now.

So based on the above statement, we have seen a lot of advantages of CosmWasm, but I would like to particularly point out some uncertainties.

1. Right now, EVM has taken a majority market share of the VM, including Ethereum and other EVM chains. Even within the Cosmos, CosmWasm has to face competition from VM such as EVM of Evmos, and Javascript of Agoric, etc. It will be interesting to see how liquidity/developers flow among the three VMs on Cosmos. So how to build its own ecosystem and developer community, and how to build the corresponding strategy and marketing plans for the future become very important.

2. There might be some technical issues/updates in the short team. Compared with EVM, CosmWasm is not as battle tested as the EVM. For examples, the validators should run on Intel and AMD64, while they have developer support for running CosmWasm on arm64 (e.g., the new MacBook M1), but it has not been heavily tested and may fall out of consensus, so we don’t recommend using that outside of a dev environment.So nodes are recommended using read-only rather than validating on the device. So after the implementation of CosmWasm, Osmosis nodes will need to update.

3. Compared with Solidity of EVM, Rust language has several major features: memory safety, less system bugs other than business logic, memory safety is guaranteed, and memory unsafe errors can be identified even during the compilation process; high concurrency, compiling Assembly means interacts with hardware directly, the performance is relatively high; However, due to the complexity of the languages, the apps that are spread across different contracts become hard to read;  the audits is more complex, and the learning curve and difficulty are very high compared to Solidity, which becomes the bottleneck for the developer.

4. Currently, the documentation for developers is not enough and needs to be updated. Better developers tools (beside CLI tools) need to be created.

So CosmWasm will focus on three parts:

1. provide better onboarding experience for the developers, such as the launch of CosmWasm Academy, brings more training to the developers, in areas like contract development, dapp development and deploying to chain of your choice, also, they will improve on the doc and architecture explanation ; CosmWasm contracts will be also supported by Go!

2. Provide better Tooling, such as the new “ng-contracts”framework for simpler Rust development, for less boilerplate and more composability, the CosmWasmJS, similar to Solidity Web3.JS which simplify the dapp development, they will have demo scripts to deploy contract, easy to test contracts in pure JS and tools to auto-generate TypeScript API ; Also, Localwasm docker images for testing; Similar to Solidity Remix, they will support 3rd party efforts for CosmWasm IDE; They will also develop contract verification services, which reduce for the complexities for tests and audits.

3. In terms of multi-contract vision, they will bring IBC to more App developers; They will built out an IBC swap protocol for Osmosis/Juno, which are the two leading protocols implementing CosmWasm, one for permissioned, and one for permissionless; They will document IBC contract development; They will improve ts-relayers for powerful integration tests in TypeScript; They will also be working with Cosmos Hub team at Interchain GmbH on IBC trainings.

Previously, the Cosmos community submitted a corresponding proposal on whether to add CosmWasm to the Cosmos Hub, and the community had a very big disagreement. Although the proposal was ultimately rejected, we can review together the core points that emerged between the period. Supporters believe that it greatly reduces the threshold for submitting code and adding functions to the Cosmos Hub. At present, new functions within the Cosmos need to be submitted in the form of SDK modules, and these different modules are maintained by different Cosmos core contributors. And once these modules, or consensus, or other changes/updates/launches, the Cosmos Hub team needs to communicate with the core validators, and all validators of the Cosmos Hub need to prepare for the upgrade and take steps to update their Node or configure Cosmovisor to run the upgrade process automatically, which requires a lot of communication and time. When Cosmwasm is implemented on Cosmos Hub through a governance-gated way, it can ensure that anyone can access Cosmos Hub through smart contracts, and there will be no malicious code attacks, and it also reduces the redundancy between Cosmos Hub and other teams. it will only take the time to vote. Once CosmWasm is broadly implemented, we will see more and more designs and applications, including CW20, CW721, DAODAO etc. Some simple functions such as profits sharing, trading can be implemented through Cosmos SDK Golang module, without the full upgrades, which allows for more diverse functionaries to be added on top of the Hub. They always argue the Cosmos Hub is irrelevant among society and it should be the one that takes new features in the first place rather than the last one.

Of course, there are also disadvantages, including the high maintenance cost of Cosmwasm compatibility. In order to be compatible with the latest Cosmos v0.46 version, the version of Cosmwasm also needs to be iterated, and this version is also agreed to be updated and maintained  by Lido and P2P team (the nodes and core contributors of Cosmos) But in the long run, Cosmwasm is maintained by Confio (funded by the Interchain Foundation), and we also see that Cosmwasm are not running on Windows, it is  experimentally supported on ARM, while the main download of Cosmos Gaia Binary is through AMD's Linux and Darwin. But the final impact still needs to be confirmed with the validators.

But why did the Cosmos founding team represented by Jae and Peng start to oppose this proposal, and even start to bribe (cancel some  airdrops for people who vote yes) the community? Jae is the real Hub Minimalist, and he hopes that the Cosmos Hub only focuses on producing blocks, while other staff are outsourced to other more innovative chains, such as Juno, Osmosis, etc. Peng also publicly stated that they are conservative and hope to attract users through a safe and stable Hub, while ensuring the safety of other chains. So you can think of Cosmos Hub as bitcoin, which is slowly evolving and developing, but services the infrastructure for the Cosmos, while more innovations should take place on other chains.

The deployment of Cosmwasm, which they believed would defeat the original idea of the Cosmos Hub,  Jae showed that he hated this proposal very much, and was even ready to exclude the Interchain foundation from the airdrop of his new project Gnoland, although the chairman of the Interchain Foundation is his partner Ethan Buckman . Of course, supporters also include Cosmos core developers Jack Zampolin and Zaki Manian, etc.

As of now, apart from Lido, there is no clear plan for other applications to be deployed on the Cosmos Hub via CosmWasm.  This makes opponents more convinced that this is a game between money and politics. Lido feels more like taking advantage of the potential liquidity of Cosmos (just like using ETH, which currently occupies 28% of the market share of Ethereum 2.0 Staking, and its market cap is as high as 3% of ETH). Through CosmWasm, Lido does not need to build its own application chains, while still can take liquidity advantage of the Cosmos/IBC liquidity. I would say Lido and the fund such as Paradigm behind it support the implementations of CosmWasm, because they are mainly from “Atom stakers” point of view. While its competitor Quicksilver, a liquid staking protocol built on Cosmos SDK, takes a different approach. In the early stage, Quicksilver will connect through the IBC in the form of a customized consumption chain via interchain securitying. They believe the  success for Derivatives is to allow users to choose their own validators when using Derivatives, and to allow users to continue to vote with Staked  Derivatives. Lido's approach is instead different. They believe that users don't want to know these details, and they just delegate to these protocols. So they are two different products with different added value.

However, if any projects want to deploy liquid staking functions (Osmosis believes that Interfluid staking  will disrupt liquid staking model), or others, they can access Cosmwasm externally (Proposal107) but still maintain its sovereignty. For example, Osmosis decided to implements CosmWasm independent, while not necessarily through the Cosmos Hub. This will allow more DeFi innovations to be built on top of it. Adding CosmWasm to Osmosis and combining it with existing native modules (AMM and Superfluid Staking for Superfluid Staking) can significantly improve and expand the existing functionalities available on Osmosis. But the plan is to add "permissioned" CosmWasm, a governance vote must be taken to enable deployment of any new code to the chain. Of course Cosmwasm allows for quick deployment of many utilities and features and we have had some familiar names on the list, Osmosis,  Juno, Secret, Stargaze etc.

Adding CosmWasm to Osmosis and integrating it tightly with the existing native modules (the AMMs and soon superfluid staking) has the potential to dramatically extend the functionality available on Osmosis. While the plan is to add “permissioned” CosmWasm, where a governance vote must take place to enable deploying any new code to the chain. While in the project called Juno Network, the deployment would rather be permissionless. The actual development can be parallelized much more than with the Osmosis Go binary.Apart from Security, the CosmWasm contracts are sandboxed from each other (limiting security concerns about it impacting other modules) and have strict interfaces, freeing them from versioning of other components (like updates to the AMM, new Cosmos SDK version, etc). This allows Osmosis to potentially contract multiple developer teams to build out protocols that extend the AMM but do not touch the core functionality.Scalability in the development team leads to quicker shipping.

Also, as the opt-in module, any chain can choose to even fork the code and implement their own version of CosmWasm. There have been quite a number of contracts being developed for other chains (such as cw-plus repo, Terra’s DeFi and DAO-DAO), which could be copied or easily ported over to Osmosis. This will allow for quick additions of a number of utility features and possibly quicker development of DeFi protocols (not just by horizontal scalability by parallelization but actually quicker delivery by leveraging existing code).

For example, in the field of Defi, due to the recent collapse of the Terra ecosystem, many developers have gradually turned to the Cosmwasm community and other Cosmos projects. The Mars protocol was once the second largest lending protocol in Terra next only to the Anchor protocol, with core functionalities including lending. and leveraged mining. It recently restarted its project, and chose to build its own sovereign chain on Cosmos, and it chose to cooperate with Osmosis in depth. Users on Osmsois will be able to lend and borrow IBC assets, such as

Cosmos (ATOM), Osmosis (OSMO), Axelar (USDC). Also MARS tokens can also have utilities such as governance, profit sharing, staking and others. The Mars smart contract on Osmosis will charge a protocol fee and exchange it for MARS on Osmosis, once a pre-specified threshold is exceeded, the smart contract will trigger another function to send MARS tokens to the distribution module on Mars Hub. This we mentioned in the previous article, the chain-to-chain relay is done via the relayer on the channel through inter-chain account function, and the execution of the transaction depends entirely on the logic of the receiver (here, the distribution module of Mars, a non-IBC transaction), and the existence of CosmWasm further strengthens functionalities of IBC and the interchain-account, which dramatically improves the redundant and cumbersome manual upgrade process in a more dynamically and efficiently way. What I have to mention here is the interfluid staking function of Osmosis. The liquidity provided  for the Osmosis will not only receive benefits for being a LP but can also use the bonded LP position to secure the network and earn the corresponding staking rewards. The bonded LP tokens can obtain liquidity incentives and exchange fees, while OSMO in the bonded LP pair can obtain  income from inflation, transaction fees and so on. But since only OSMOs based on the discount factor will get the corresponding benefits, this is a way of partial safety guarantee only. Superfluid staking is only limited to OSMO and other non-OSMO tokens(such as ATOM-OSMO), while Interfulid staking (not live yet, expected within a year) is a supplement to the existing Superfluid staking where it  allows users from other chains can use their designated bonded LP positions (such as ATOM-JUNO) in the same way to secure the network and obtain rewards accordingly.  Osmosis strongly believes this is a solution that is superior to the various liquid staking protocols and will integrate the functionality on more chains once ready. And CosmWasm of course will help to accelerate and expand existing application functions and scenarios.Of course, in terms of governance, the Cosmwasm/cw-plus repo also implements some innovative voting contracts and delegates rights to the community. There are also some token-staked voting contracts. For example, DAODAO allows users to quickly start DAO with a few clicks without any single line of code. Although it has some similar functions to other DAO tools, it can achieve cross-chain functions, such as voting on Osmosis through accounts on Juno. This will become reality thanks to the Intechain accounts and CosmWasm technology.. Of course, unlike Osmosis, Juno is a  permissionless smart  contract platform developed based on Cosmwasm, so the quality of  applications is not guaranteed. Since the goal of Osmosis is to build a permissioned Defi empire with the AMM business as the core, the new CosmWasm application built on it needs to be approved through governance and works mainly complementary to its core function, such as the yield aggregator, lending protocol etc., Also, Osmosis will keep its chain as light as possible, and don't want it to become congested with thousands of applications that don't necessarily need to be co-located on the same chain.While Juno seems to defeat the purpose of the application specific chain and works as the home for long tail applications that do not fit the specific needs of the app-specific zones.

In terms of IBC scaling, the Confio team has put a lot of work into making IBC aware that smart contracts are a reality. This allows Osmosis to easily and quickly deploy new protocols between two CosmWasm chains. For example, the ETF chain can hold tokens on Osmosis and exchange them, or Osmosis DAO can stake tokens on another chain and obtain rewards. This will also become the reality thanks to  interchain accounts and CosmWasm.

Cosmos chains are able to communicate by sending packets of information over IBC channels and these channels can contain things like token transfers. Similar to how Ethereum uses the ERC-20 token standard, CosmWasm uses their own token standards: CW-20 tokens and CW-721 for NFTs.

It is important to note that these CW-20 tokens are not one and the same as native Cosmos SDK tokens. Rather, they are two different token standards. Given Juno was the first chain to integrate IBC with CosmWasm, these standards are still very new. Also, Terra has been the large beneficiary and trailblazer for CosmWasm with majority of its token are CW-20 assets. A very important development of these tokens recently took place with Osmosis listing NETA, a CW-20 token, on the platform. This is a huge milestone because it shows that CW-20 tokens can safely interact with other chains like Osmosis over IBC, whereas token transfers/listings were previously only used by Cosmos SDK tokens. Such compatibility opens the doors to all Juno tokens and CW-20 tokens more broadly. Hence, you can have any token on Juno flow over IBC to any Cosmos Zone and be useful in the respective ecosystems.

Currently, most relayers that send token transfers only work for Cosmos native assets, not CW-20 tokens. The difference in packet relaying for these token transfers comes down to the channel the CW-20 tokens are sent over, which are different from the channels Cosmos SDK tokens are sent on. To send these assets over, relayers need to have upgraded software to send these assets, which can use the same node and the same relay software that they currently use for normal IBC assets. This means that relayers that want to relay CW-20 assets need to update their config to allow for this new channel. Right now, Juno has supported more than 30 chains for tokens to flow in and out.

So far, we have understood the importance of CosmWasm's as a multiple, specialized smart contract platform, in the era of multi-chain interoperability. We have also been continously emphasizing that not only the vision of Web 3.0, Cosmos also hopes to reshape the existing financial system and use Cosmos technology to serve the existing real economy and  small and medium-sized enterprises. We  firmly believe that CosmWasm will accelerate the realization of this goal. We have seen a lot of innovations happening in space. Since 2017, Regen Network is committed to shaping a green economy, and it innovatively tokenizes carbon; Tgrade Finance supports ESG (environmental and social governance) goals through Proof of Engagement; IXO is Regen Network's typical carbon neutral and renewable Economical case; WYND subsidizes DeFi income to environmental protection funds and manages funds, etc. As always, we would always love to see more and more cases of open governance and regenerative finance bloom on Cosmos in the future.

Ethan Frey ,Co-founder of Confio | Father of CosmWasm

Nansen alpha

CosmWasm is a smart contract engine that improves based on the Cosmos SDK and IBC. It’s the only cross-chain interpretable Virtual Machine besides the EVM. If you think of EVM as a Mainframe computer, the CosmWasm VM is a cluster of computers which can communicate through IBC。 CosmWasm, along with Tendermint, Cosmos SDK, IBC are the the core technology stack within the Cosmos, any chain based on the Cosmos SDK can implement CosmWasm without changing the existing logic. CosmWasm currently supports Rust, and other languages outside of Rust are being worked on today including Golang and vlang. So the main takeaway is that the CosmWasm is a framework that allows developers to make secure and composable cross chain applications, without having to launch an entire layer 1 blockchain; thus, significantly removing the barrier to entry for apps and tokens to launch on Cosmos.

We have seen the number of blockchains running CosmWasm has steadily increased over the last six months to now include more than a dozen mainnets with total values amounting to 4-5billion dollars. Terra of course has been the main beneficiary for the CosmWasm, with the majority of developers having experience in CosmWasm development and majority of assets being CW20 standard (CosmWasm standard), with total TVL being ranked No.1 in Cosmos. However, the recent collapse of UST and Luna, brings catastrophic effects to the system. More and more developers decide to move from Terra to other CosmWasm supported projects, such as Osmosis, Juno, etc.

We have mentioned above that the CosmWasm is the core module of the Cosmos, then what is the module? So CosmWasm itself is an SDK module that any chain can implement if they are built on the Cosmos SDK. A module simply contains the business logic for specific applications. Each module is unique to their specific applications which contains their own business logic. Given there are different types of modules, such as CosmWasm, Governance, Staking etc, with their own unique use cases,  how do they actually compose with each other? They are composed through the SDK core which allows developers to build out their app-specific chains and opt-in the modules as they see fit. Also, the modules are available for all developers within the Cosmos ecosystem. The chain can choose the modules that fits their own business logic and add more modules for the ongoing development, which simplifies the stack and allows the developers to select from a diverse set of composability between modules. This is the core vision for the Cosmos, a framework of sovereign blockchains who can independently build out modules for themselves and deploy them to the Cosmos SDK.

This highlights that the CosmWasm further strengthens the IBC functionality by allowing IBC to be more dynamic and iterative. As mentioned above, all the new functionalities/ development are in the form of new modules, then who are responsible for these modules? The majority of modules are created and maintained by the Cosmos SDK contributors or other Cosmos core contributors. Then it's the job of the Cosmos Hub team at Interchain GmbH to review, test and integrate these modules before releasing  Gaia code updates and communicating the network update with validators. While software release and upgrade includes launching and running public testnets to simulate upgrade proposals with a validator set from the Cosmos Hub and chain state that mimics the live Cosmos Hub. Finally,  CosmosHub validators will need to prepare for the upgrade and upgrade the nodes at the right height or configure Cosmovisors to run the upgrade automatically. Although a lot  of work has been done by Stargate to improve the existing upgrade process, it’s still very difficult. The upgradeability is very manual and requires a lot of time and coordination between the chains. This becomes a bottleneck with scaling IBC given it requires more coordination efforts the more connection a zone has.

So if we think about EVM is a legacy VM, and Solana is a VM is built for vertical scalability, then CosmWasm is a VM is designed for the cross-chain horizontal scalability.  CosmWasm VM plays a very important role in cross-chain VM and strengthens the IBC functionalities.  With the upcoming “Inter-chain Accounts” and “Interchain Security” launch, we will see more and more projects begin to implement the  CosmWasm.

Compared with other VMms, what are the characteristics of CosmWasm? Firstly, it should be the security, CosmWasm thinks the EVM and Solidity has been riddled with attack vectors built into the design. While CosmWasm can prevent the majority of hacks in Solidity such as reentrancy attacks, by design and provides some great experience to migrate contracts rather than the “library contract” model in Solidity; Also, there exist business logic errors in Ethereum. Mistakes in if conditions or loop guards can leak millions. The loss of $90million USD for the Compound is due to  using < rather than <= in an if statement. CosmWasm can make testing at different levels (unit, integration and full stack) to prevent this problem; Thirdly, in terms of performance and costs, the high gas fees of Ethereum is caused by the limits on the  block/gas costs, while CosmWasms vision is similar to ETH2.0. There are some other features including Lock-in and composability. If you decide to build your own sovereign blockchains, when it becomes too large and you can switch easily without having the locked-in issue in Ethereum. You can launch a new CosmWasm zone and iterate on new multi-chain protocols as CosmWasm contracts and allow users to migrate to new chains while still maintaining the first class connection to protocols on the original chain.

How about compared with Cosmos SDK which is one of the top blockchain construction kits. Cosmos SDK was built in native code in Go and allows developers to quickly wire up modules from many resources to produce power, application specific chains. Of course, if you are building a new consensus mechanism, or overhauling the fee handling model or integrating GPU to compute engine, then Cosmos SDK should be a better choice, while most of the applications/projects would benefit from coding from CosmWasm. With the launch of interchain, we will see more and more projects will be deployed on CosmWasm, in the form of contract consumer chain (vs custom consumer chain), the consumers chains will have full security from the Cosmos Hub and have full access to the IBC and Cosmos ecosystem. Rather than having its own validators sets, consumer chains will rely on the validators from the Cosmos Hub to validate their blocks, hence no chains are required. Of course you can migrate to other chains or build your own sovereign chains later on; In terms of composability, we mentioned above the Cosmos SDK works as the core to connect through different modules, then how modules interpret each other ?If there are only a few modules within the chain, it’s not difficult. How about there are multiple modules for different chains? In this case, CosmWasm and the upcoming interchain accounts module would provide the solution. There are some other benefits such as Upgrades and migrations problems, we will leave it for now.

So based on the above statement, we have seen a lot of advantages of CosmWasm, but I would like to particularly point out some uncertainties.

1. Right now, EVM has taken a majority market share of the VM, including Ethereum and other EVM chains. Even within the Cosmos, CosmWasm has to face competition from VM such as EVM of Evmos, and Javascript of Agoric, etc. It will be interesting to see how liquidity/developers flow among the three VMs on Cosmos. So how to build its own ecosystem and developer community, and how to build the corresponding strategy and marketing plans for the future become very important.

2. There might be some technical issues/updates in the short team. Compared with EVM, CosmWasm is not as battle tested as the EVM. For examples, the validators should run on Intel and AMD64, while they have developer support for running CosmWasm on arm64 (e.g., the new MacBook M1), but it has not been heavily tested and may fall out of consensus, so we don’t recommend using that outside of a dev environment.So nodes are recommended using read-only rather than validating on the device. So after the implementation of CosmWasm, Osmosis nodes will need to update.

3. Compared with Solidity of EVM, Rust language has several major features: memory safety, less system bugs other than business logic, memory safety is guaranteed, and memory unsafe errors can be identified even during the compilation process; high concurrency, compiling Assembly means interacts with hardware directly, the performance is relatively high; However, due to the complexity of the languages, the apps that are spread across different contracts become hard to read;  the audits is more complex, and the learning curve and difficulty are very high compared to Solidity, which becomes the bottleneck for the developer.

4. Currently, the documentation for developers is not enough and needs to be updated. Better developers tools (beside CLI tools) need to be created.

So CosmWasm will focus on three parts:

1. provide better onboarding experience for the developers, such as the launch of CosmWasm Academy, brings more training to the developers, in areas like contract development, dapp development and deploying to chain of your choice, also, they will improve on the doc and architecture explanation ; CosmWasm contracts will be also supported by Go!

2. Provide better Tooling, such as the new “ng-contracts”framework for simpler Rust development, for less boilerplate and more composability, the CosmWasmJS, similar to Solidity Web3.JS which simplify the dapp development, they will have demo scripts to deploy contract, easy to test contracts in pure JS and tools to auto-generate TypeScript API ; Also, Localwasm docker images for testing; Similar to Solidity Remix, they will support 3rd party efforts for CosmWasm IDE; They will also develop contract verification services, which reduce for the complexities for tests and audits.

3. In terms of multi-contract vision, they will bring IBC to more App developers; They will built out an IBC swap protocol for Osmosis/Juno, which are the two leading protocols implementing CosmWasm, one for permissioned, and one for permissionless; They will document IBC contract development; They will improve ts-relayers for powerful integration tests in TypeScript; They will also be working with Cosmos Hub team at Interchain GmbH on IBC trainings.

Previously, the Cosmos community submitted a corresponding proposal on whether to add CosmWasm to the Cosmos Hub, and the community had a very big disagreement. Although the proposal was ultimately rejected, we can review together the core points that emerged between the period. Supporters believe that it greatly reduces the threshold for submitting code and adding functions to the Cosmos Hub. At present, new functions within the Cosmos need to be submitted in the form of SDK modules, and these different modules are maintained by different Cosmos core contributors. And once these modules, or consensus, or other changes/updates/launches, the Cosmos Hub team needs to communicate with the core validators, and all validators of the Cosmos Hub need to prepare for the upgrade and take steps to update their Node or configure Cosmovisor to run the upgrade process automatically, which requires a lot of communication and time. When Cosmwasm is implemented on Cosmos Hub through a governance-gated way, it can ensure that anyone can access Cosmos Hub through smart contracts, and there will be no malicious code attacks, and it also reduces the redundancy between Cosmos Hub and other teams. it will only take the time to vote. Once CosmWasm is broadly implemented, we will see more and more designs and applications, including CW20, CW721, DAODAO etc. Some simple functions such as profits sharing, trading can be implemented through Cosmos SDK Golang module, without the full upgrades, which allows for more diverse functionaries to be added on top of the Hub. They always argue the Cosmos Hub is irrelevant among society and it should be the one that takes new features in the first place rather than the last one.

Of course, there are also disadvantages, including the high maintenance cost of Cosmwasm compatibility. In order to be compatible with the latest Cosmos v0.46 version, the version of Cosmwasm also needs to be iterated, and this version is also agreed to be updated and maintained  by Lido and P2P team (the nodes and core contributors of Cosmos) But in the long run, Cosmwasm is maintained by Confio (funded by the Interchain Foundation), and we also see that Cosmwasm are not running on Windows, it is  experimentally supported on ARM, while the main download of Cosmos Gaia Binary is through AMD's Linux and Darwin. But the final impact still needs to be confirmed with the validators.

But why did the Cosmos founding team represented by Jae and Peng start to oppose this proposal, and even start to bribe (cancel some  airdrops for people who vote yes) the community? Jae is the real Hub Minimalist, and he hopes that the Cosmos Hub only focuses on producing blocks, while other staff are outsourced to other more innovative chains, such as Juno, Osmosis, etc. Peng also publicly stated that they are conservative and hope to attract users through a safe and stable Hub, while ensuring the safety of other chains. So you can think of Cosmos Hub as bitcoin, which is slowly evolving and developing, but services the infrastructure for the Cosmos, while more innovations should take place on other chains.

The deployment of Cosmwasm, which they believed would defeat the original idea of the Cosmos Hub,  Jae showed that he hated this proposal very much, and was even ready to exclude the Interchain foundation from the airdrop of his new project Gnoland, although the chairman of the Interchain Foundation is his partner Ethan Buckman . Of course, supporters also include Cosmos core developers Jack Zampolin and Zaki Manian, etc.

As of now, apart from Lido, there is no clear plan for other applications to be deployed on the Cosmos Hub via CosmWasm.  This makes opponents more convinced that this is a game between money and politics. Lido feels more like taking advantage of the potential liquidity of Cosmos (just like using ETH, which currently occupies 28% of the market share of Ethereum 2.0 Staking, and its market cap is as high as 3% of ETH). Through CosmWasm, Lido does not need to build its own application chains, while still can take liquidity advantage of the Cosmos/IBC liquidity. I would say Lido and the fund such as Paradigm behind it support the implementations of CosmWasm, because they are mainly from “Atom stakers” point of view. While its competitor Quicksilver, a liquid staking protocol built on Cosmos SDK, takes a different approach. In the early stage, Quicksilver will connect through the IBC in the form of a customized consumption chain via interchain securitying. They believe the  success for Derivatives is to allow users to choose their own validators when using Derivatives, and to allow users to continue to vote with Staked  Derivatives. Lido's approach is instead different. They believe that users don't want to know these details, and they just delegate to these protocols. So they are two different products with different added value.

However, if any projects want to deploy liquid staking functions (Osmosis believes that Interfluid staking  will disrupt liquid staking model), or others, they can access Cosmwasm externally (Proposal107) but still maintain its sovereignty. For example, Osmosis decided to implements CosmWasm independent, while not necessarily through the Cosmos Hub. This will allow more DeFi innovations to be built on top of it. Adding CosmWasm to Osmosis and combining it with existing native modules (AMM and Superfluid Staking for Superfluid Staking) can significantly improve and expand the existing functionalities available on Osmosis. But the plan is to add "permissioned" CosmWasm, a governance vote must be taken to enable deployment of any new code to the chain. Of course Cosmwasm allows for quick deployment of many utilities and features and we have had some familiar names on the list, Osmosis,  Juno, Secret, Stargaze etc.

Adding CosmWasm to Osmosis and integrating it tightly with the existing native modules (the AMMs and soon superfluid staking) has the potential to dramatically extend the functionality available on Osmosis. While the plan is to add “permissioned” CosmWasm, where a governance vote must take place to enable deploying any new code to the chain. While in the project called Juno Network, the deployment would rather be permissionless. The actual development can be parallelized much more than with the Osmosis Go binary.Apart from Security, the CosmWasm contracts are sandboxed from each other (limiting security concerns about it impacting other modules) and have strict interfaces, freeing them from versioning of other components (like updates to the AMM, new Cosmos SDK version, etc). This allows Osmosis to potentially contract multiple developer teams to build out protocols that extend the AMM but do not touch the core functionality.Scalability in the development team leads to quicker shipping.

Also, as the opt-in module, any chain can choose to even fork the code and implement their own version of CosmWasm. There have been quite a number of contracts being developed for other chains (such as cw-plus repo, Terra’s DeFi and DAO-DAO), which could be copied or easily ported over to Osmosis. This will allow for quick additions of a number of utility features and possibly quicker development of DeFi protocols (not just by horizontal scalability by parallelization but actually quicker delivery by leveraging existing code).

For example, in the field of Defi, due to the recent collapse of the Terra ecosystem, many developers have gradually turned to the Cosmwasm community and other Cosmos projects. The Mars protocol was once the second largest lending protocol in Terra next only to the Anchor protocol, with core functionalities including lending. and leveraged mining. It recently restarted its project, and chose to build its own sovereign chain on Cosmos, and it chose to cooperate with Osmosis in depth. Users on Osmsois will be able to lend and borrow IBC assets, such as

Cosmos (ATOM), Osmosis (OSMO), Axelar (USDC). Also MARS tokens can also have utilities such as governance, profit sharing, staking and others. The Mars smart contract on Osmosis will charge a protocol fee and exchange it for MARS on Osmosis, once a pre-specified threshold is exceeded, the smart contract will trigger another function to send MARS tokens to the distribution module on Mars Hub. This we mentioned in the previous article, the chain-to-chain relay is done via the relayer on the channel through inter-chain account function, and the execution of the transaction depends entirely on the logic of the receiver (here, the distribution module of Mars, a non-IBC transaction), and the existence of CosmWasm further strengthens functionalities of IBC and the interchain-account, which dramatically improves the redundant and cumbersome manual upgrade process in a more dynamically and efficiently way. What I have to mention here is the interfluid staking function of Osmosis. The liquidity provided  for the Osmosis will not only receive benefits for being a LP but can also use the bonded LP position to secure the network and earn the corresponding staking rewards. The bonded LP tokens can obtain liquidity incentives and exchange fees, while OSMO in the bonded LP pair can obtain  income from inflation, transaction fees and so on. But since only OSMOs based on the discount factor will get the corresponding benefits, this is a way of partial safety guarantee only. Superfluid staking is only limited to OSMO and other non-OSMO tokens(such as ATOM-OSMO), while Interfulid staking (not live yet, expected within a year) is a supplement to the existing Superfluid staking where it  allows users from other chains can use their designated bonded LP positions (such as ATOM-JUNO) in the same way to secure the network and obtain rewards accordingly.  Osmosis strongly believes this is a solution that is superior to the various liquid staking protocols and will integrate the functionality on more chains once ready. And CosmWasm of course will help to accelerate and expand existing application functions and scenarios.Of course, in terms of governance, the Cosmwasm/cw-plus repo also implements some innovative voting contracts and delegates rights to the community. There are also some token-staked voting contracts. For example, DAODAO allows users to quickly start DAO with a few clicks without any single line of code. Although it has some similar functions to other DAO tools, it can achieve cross-chain functions, such as voting on Osmosis through accounts on Juno. This will become reality thanks to the Intechain accounts and CosmWasm technology.. Of course, unlike Osmosis, Juno is a  permissionless smart  contract platform developed based on Cosmwasm, so the quality of  applications is not guaranteed. Since the goal of Osmosis is to build a permissioned Defi empire with the AMM business as the core, the new CosmWasm application built on it needs to be approved through governance and works mainly complementary to its core function, such as the yield aggregator, lending protocol etc., Also, Osmosis will keep its chain as light as possible, and don't want it to become congested with thousands of applications that don't necessarily need to be co-located on the same chain.While Juno seems to defeat the purpose of the application specific chain and works as the home for long tail applications that do not fit the specific needs of the app-specific zones.

In terms of IBC scaling, the Confio team has put a lot of work into making IBC aware that smart contracts are a reality. This allows Osmosis to easily and quickly deploy new protocols between two CosmWasm chains. For example, the ETF chain can hold tokens on Osmosis and exchange them, or Osmosis DAO can stake tokens on another chain and obtain rewards. This will also become the reality thanks to  interchain accounts and CosmWasm.

Cosmos chains are able to communicate by sending packets of information over IBC channels and these channels can contain things like token transfers. Similar to how Ethereum uses the ERC-20 token standard, CosmWasm uses their own token standards: CW-20 tokens and CW-721 for NFTs.

It is important to note that these CW-20 tokens are not one and the same as native Cosmos SDK tokens. Rather, they are two different token standards. Given Juno was the first chain to integrate IBC with CosmWasm, these standards are still very new. Also, Terra has been the large beneficiary and trailblazer for CosmWasm with majority of its token are CW-20 assets. A very important development of these tokens recently took place with Osmosis listing NETA, a CW-20 token, on the platform. This is a huge milestone because it shows that CW-20 tokens can safely interact with other chains like Osmosis over IBC, whereas token transfers/listings were previously only used by Cosmos SDK tokens. Such compatibility opens the doors to all Juno tokens and CW-20 tokens more broadly. Hence, you can have any token on Juno flow over IBC to any Cosmos Zone and be useful in the respective ecosystems.

Currently, most relayers that send token transfers only work for Cosmos native assets, not CW-20 tokens. The difference in packet relaying for these token transfers comes down to the channel the CW-20 tokens are sent over, which are different from the channels Cosmos SDK tokens are sent on. To send these assets over, relayers need to have upgraded software to send these assets, which can use the same node and the same relay software that they currently use for normal IBC assets. This means that relayers that want to relay CW-20 assets need to update their config to allow for this new channel. Right now, Juno has supported more than 30 chains for tokens to flow in and out.

So far, we have understood the importance of CosmWasm's as a multiple, specialized smart contract platform, in the era of multi-chain interoperability. We have also been continously emphasizing that not only the vision of Web 3.0, Cosmos also hopes to reshape the existing financial system and use Cosmos technology to serve the existing real economy and  small and medium-sized enterprises. We  firmly believe that CosmWasm will accelerate the realization of this goal. We have seen a lot of innovations happening in space. Since 2017, Regen Network is committed to shaping a green economy, and it innovatively tokenizes carbon; Tgrade Finance supports ESG (environmental and social governance) goals through Proof of Engagement; IXO is Regen Network's typical carbon neutral and renewable Economical case; WYND subsidizes DeFi income to environmental protection funds and manages funds, etc. As always, we would always love to see more and more cases of open governance and regenerative finance bloom on Cosmos in the future.

Ethan Frey ,Co-founder of Confio | Father of CosmWasm

Nansen alpha