From deep discussion on UniFi telegram channel, we have found that the community has different ideas how to deploy major DeFi applications on the Hub, which are AMM(DeX) and ETH Peggy(Peg for Ethereum assets).
One idea involves building DeFi applications on the Hub via CosmWasm smart contract, the other is to build native DeFi modules directly on the Hub. So I hope to write down detailed advantages and disadvantages of each approach, and summarize further diverged roadmaps for each implementation option.
This is the most important preliminary topic to decide from the community because every actionable roadmap for GTM(Go To Market) strategies and characteristics diverges significantly for each approach. It is wise for us to decide the high level implementation option first, and progress upon decided path.
Disclaimer : Below summary is written by me with unperfect knowledge on technical details, so it will be very appreciated if anyone can feedback with reply when any information is wrong or need update.
- Advantages of CosmWasm smart contract DeFi on the Hub
-
CosmWasm framework provides us more flexible upgrade methodologies which allow us to upgrade implemented DeFi contract without chain upgrade(halt the chain, upgrade binary, and relaunch network).
-
Notes on flexible upgrade feature
-
Flexible upgrade methodologies are only applicable when the next version of the contract does not bring significant changes of states in the contract. If it does, I expect it needs a contract migration which results in massive manual asset migration by users from old contract to new contract, just like Uniswap v1 to v2 migration, because states are not compatible between old and new contracts.
-
This liquidity migration takes a lot of time, and the impact is somewhat larger than chain upgrade. It takes quite a lot of time and effort from decentralized group of users, and both version should be alive for significant time to support slow and smooth migration from old to new version.
-
Even if flexible upgrade allows upgrade without chain upgrade, it still needs full audit process and governance process to verify stability of the new version. This is same case as native module, but because contracts are operated via CosmWasm module, it causes relatively deeper security review necessity than native modules
-
The IBC light client case has especially more significant usecase of flexible upgrades than other modules because the IBC light clients are composed of each different connection to heterogenious blockchains like Ethereum, Bitcoin or Polkadot, hence the upgrade frequency becomes higher when we have more heterogenious blockchains connected to our network. Therefore CosmWasm for IBC light client module should be discussed separately because it has much more usecase than DeFi application situation.
-
There exists a possibility that native modules can also provide flexible upgrade feature. One example can be Regen Network upgrade module which provides quite flexible environment for upgrade without chain upgrade.
-
-
-
More flexible way to bring new innovative DeFi solutions via smart contract
-
Open framework of building new applications
-
Flexibility from smart contract framework allows the community to bring lots of innovative DeFi applications because of its generalization of asset handling interfaces.
-
Notes
-
The potential of innovative solutions from smart contract framework is very limited in the Hub case, because the Hub will have very limited number of DeFi applications directly on the Hub. Foreseeable applications only include AMM(DeX), ETH Peggy, BTC Peg, and possibly Staking Derivatives solution(this is very controversial issue though).
-
The genuine potential of smart contract framework will shine in a blockchain with permissionless smart contract deployment, just like Ethereum. So I expect the zone with most potential with CosmWasm will be a permissionless CosmWasm enabled blockchain with shared security support from the Hub.
-
-
-
-
More trustable smart contract language
-
Rust and Wasm
- Compared to a completely newborn language like Solidity, CosmWasm smart contract framework utilizes already well-established languages and frameworks like Rust and Wasm. Therefore the security risk and stability of CosmWasm will be relatively much better than Solidity and EVM case in Ethereum.
-
- Disadvantages of CosmWasm smart contract DeFi on the Hub
-
Security and stability issues
-
Unlike native modules, CosmWasm smart contracts interact with the smart contract, Rust, Wasm, and the CosmWasm module on the Hub. Even if all ingredients are well-audited and tested, it certainly adds relatively more complexities and instability risk to permit additional smart contract on the Hub.
-
Especially, CosmWasm is a new-born framework as now, and the confidence on the framework needs time to accumulate testing and debugging experience in the community.
-
-
Audit
- Adoption of new contract will need audit procedure for the Hub. The difficulty and insurance of audit depends on the structural complexity of over-all mechanism, and it brings additional necessary deeper audit from very specialized inspector than native modules, who has specialty on Cosmos-SDK, CosmWasm module, Rust, Wasm, and CosmWasm smart contract.
-
Community engagement
-
Although Rust is fastly expanding its userbase in blockchain industry, it is still not widely used by vast majority of our community, while Golang and native modules are much more familiar with our community. Activities like reviewing, issuing, contributing for DeFi applications on the Hub will have relatively weak participations from the community in CosmWasm smart contract case, which has a good possibility to result in less security or less active improvements.
-
Already we have good PoC codebases for AMM(DeX), ETH Peggy or BTC Peg as native modules, but we have very little or no PoC smart contracts for these applications. Even though we have some, the ecosystem is not as wide as native Golang modules, so the base ecosystem who can participate actively on DeFi application will be relatively limited.
-