ICE, SNOW, and ICON’s Polkadot Strategy
At the end of 2021, as many were awaiting the announcement of the block height for the highly-anticipated $ICY snapshot, the ICON Foundation dropped even more good news on ICON holders by unveiling yet another blockchain, SNOW, and its native token, $ICZ.
This was welcome news for all — another blockchain and another airdropped token will always be popular— but many are still attempting to digest what exactly this means for the future of ICON, ICE, and now SNOW.
In this article I attempt to lay out what I believe ICON’s approach to be, especially as it relates to their integration with Polkadot.
An overview of Polkadot
First, let’s take some time to get a firm understanding of just what Polkadot is and how exactly it works.
The idea for Polkadot came from Dr. Gavin Wood, one of Ethereum’s better-known and well-respected Co-Founders. Wood used his knowledge and experience building Ethereum to identify some key problems with blockchain technology and architecture at the time (he originally conceived of Polkadot around 2016).
Most notable among these problems were the issues of interoperability, scalability, and security. When you consider these issues as paramount, you begin to understand why Polkadot was built the way it was.
The best overview of the Polkadot architecture I have seen comes from the Polkadot Litepaper:
Let’s run through these components really quick:
The Relay Chain is essentially the backbone of the entire Polkadot ecosystem. The Relay Chain is secured by validators (similarly to how ICON’s P-Reps operate), who are nominated by $DOT holders. The security of the Relay Chain provides umbrella security for the parachains that are connected to it. Here’s a brief description of this advantage, from Polkadot’s Medium:
As validators seal the blocks of all chains they can be seen as providing a ‘pool of security’. New chains can therefore tap into the security already provided rather than provide their own. This allows for experimentation without decrease the security of existing chains.
In other words, parachains are able to spend time and energy focusing on other aspects of their chain without having to worry about securing it. That part is done by the Relay Chain.
The Relay Chain is also responsible for coordinating the communication between all the parachains. In other words, it’s powering the interoperability within the Polkadot ecosystem.
Finally, we have bridges that connect certain parachains to the world outside of the Polkadot ecosystem. This is fairly self-explanatory, but we’ll go into a bit more detail on this later, as it obviously pertains to ICON’s ecosystem.
From a big picture standpoint, a clear advantage of this is it allows each parachain to focus and specialize in something specific, rather than trying to provide every possible type of DApp or decentralized service. Here’s a quote from the Polkadot Litepaper as to why this is important:
Will there eventually be one blockchain to rule them all? We don’t think so.
All blockchains make different tradeoffs to support specific features and use cases, and as chain specialization increases, the need to transact between them will only increase over time.
Polkadot is a sharded blockchain, meaning it connects several chains together in a single network, allowing them to process transactions in parallel and exchange data between chains with security guarantees.
Thanks to Polkadot’s unique heterogeneous sharding model, each chain in the network can be optimized for a specific use case rather than being forced to adapt to a one-size-fits-all model.
More chains and more specialization means more possibilities for innovation.
A good analogy here is the real world economy. Various nations specialize in certain economic activities, such as agriculture or manufacturing, and then trade with one another. Compared to each country attempting to do everything on their own, the specialization approach ensures everyone is ultimately better off and allows for far more economic growth and activity.
Similarly, parachains running on Polkadot are able to do the same: specialize and then “trade” (in a manner of speaking) utilizing the relay chain. And when you again factor in the notion that they don’t need to spend time or resources on their own security, you can gain even more specialization.
For example, one of Polkadot’s parachains, Astar, is “is a multi-chain decentralized application layer on Polkadot. Astar incorporates Ethereum Virtual Machine, WebAssembly, and Layer2 solutions. The platform supports various decentralized applications like DeFi, NFTs and DAOs.” Remember, the Relay Chain itself doesn’t support smart contracts — it’s just infrastructure. Astar’s speciality is serving as a parachain that supports smart contract functionalities.
Acala, meanwhile, specializes in DeFi and aims to become the DeFi “hub” of the Polkadot ecosystem: “Acala is an Ethereum-compatible platform for financial applications to use smart contracts or built-in protocols with out-of-the-box cross-chain capabilities and robust security. It offers a suite of financial applications with micro gas fees that can be paid in any token.”
Moonbeam, meanwhile, is designed as a fully Ethereum-compatible environment on Polkadot. While there are other parachains that are EVMs, Moonbeam specializes in extending that functionality in order to become optimized for Solidity developers who are used to an Ethereum-based environment. In other words, if you’re an Ethereum-based project looking to enter the Polkadot space, you’ll likely end up doing so via Moonbeam.
Hopefully you now have a decent overview of how Polkadot works and what makes it fairly innovative within the blockchain space. So let’s take a look at Kusama.
The Canary Network
Kusama is what has been referred to as the “Canary Network” (in reference to the canaries that coal miners would keep in the mines to detect when dangerous fumes were present). Here’s a description of Kusama from Gavin Wood’s announcement blog post:
Kusama is an early, unaudited and unrefined release of Polkadot. Kusama will serve as a proving ground, allowing teams and developers to build and deploy a parachain or try out Polkadot’s governance, staking, nomination and validation functionality in a real environment.
Kusama is meant to be Polkadot’s canary network, warning us of issues to keep things safe for the developers downchain. Without a network like Kusama, there is no reasonable way to fully understand the potential dangers that lie ahead. We are building bleeding-edge, experimental technology, which means there are no promises about what Kusama will do or how it will work — expect a lot of chaos (and a little fun).
Now, this sounds a lot like a testnet, right? But it’s ultimately more than that.
A testnet in the traditional sense is typically a way for developers to make sure their code works as intended. The assets on testnets are not intended to have economic value, because, well, they’re solely for testing. That’s why you can hop onto one of the ICON testnets, go to an ICX Faucet, click a button, and get a stack of free testnet $ICX.
Kusama is more than a testnet. It’s a live, production blockchain, and it’s assets are intended to have actual value, because the experimentation that exists on Kusama is meant to test economic conditions and behaviors.
Pretend you’re building a DeFi application. On the testnet, if you ask people to test it, they’ll just behave totally irrationally (relative to how they’d behave on main net), because there’s no value in the asset. They’d be willing to take on far more risk or do far more aggressive moves, because who cares, right? The tokens are worthless.
However, in an environment like Kusama, and with assets that have value, people will behave more in line like how they would with a final release product. Because the tokens they own can be redeemed for actual money, they’re far more likely to act rationally. This allows you to experiment with your DeFi product in a way that would deliver results far more similar to what would happen in real life, relative to a testnet.
I think a fair analogy is that Polkadot is like the Major Leagues, and Kusama is like the Minor Leagues. While the games and statistics in the minor leagues still “count”, they’re all ultimately designed in order to make the Major League team stronger. Sure, there are people who do care if that minor league team wins its league championship, but it’s nowhere as near significant as the performance of the Major League team.
Structurally, Kusama is basically a mirror of Polkadot. And this means that, just as Kusama is the canary network for Polkadot, the projects that plan to integrate into Polkadot initially build on Kusama.
For example, Moonriver is the Kusama “version” of Moonbeam. Karura is the Kusama version of Acala, and Shiden is the Kusama version of Astar.
Now, I mentioned that Kusama is meant to have economic value. To illustrate that point, I’d just mention that the Kusama native token, $KSM, is currently ranked as the #62 token by marketcap on CoinGecko (and at one point hit $5 billion). Moonriver’s token, meanwhile, is at a half billion dollar marketcap as of this writing.
And just as the ICE network hopes to become a Polkadot parachain one day, SNOW would be the Kusama “version” of ICE. But more on that later.
ICE & Polkadot
Putting aside the benefits that being part of the Polkadot ecosystem brings (which I’ll go into in a bit), I’d just like to remind you of the inherent benefits that ICE has, even without the Polkadot integration.
If you haven’t yet read my piece from the Fall entitled “The Promise of ICE”, I encourage you to do so. As a reminder, here’s what I wrote:
Ultimately, this is where ICE will ideally find itself in the near future — an EVM compatible chain that’s easy to build on and draw Ethereum (and other EVM chain) users onto. Beyond that, with the benefit of BTP, it should be even easier for these users and developers to move to ICE.
I also mention that ICE has other advantages beyond it’s EVM compatability: a built in user base from ICON, the fact it’s built on Substrate, and an existing incentive funding mechanism via CPS.
So, even putting aside the Polkadot integration, ICE has a lot to stand on.
But by seeking a parachain slot, the ICE team is hoping to significantly increase the value proposition of the ICE chain:
As an EVM-compatible chain, ICE provides an environment for deploying Solidity smart contracts, but this in itself is not enough of a differentiator to drive ICE and ICON adoption. There are plenty of EVM-compatible chains out there, so what makes ICE different?
ICE is the only EVM-compatible parachain that is also optimized for ICON’s BTP. This means in addition to a baseline BTP integration, ICE will also receive additional optimizations to maximize performance and reliability. With a heavily-optimized BTP integration, our goal is to secure a Polkadot parachain slot and position ICE as a flagship chain within the Polkadot ecosystem that showcases industry-leading cross-chain applications — all powered by ICON’s BTP.
As the primary connection between the ICON and Polkadot ecosystems, ICE will also provide developers with unmatched access to both the ICON BTP and Polkadot interchain networks, as well as their respective communities. This means a developer building on ICE automatically gets access to Polkadot parachains like Moonbeam, Acala, and Astar, as well as optimized connections to BTP-integrated chains like Binance Smart Chain, NEAR Protocol, Harmony, and more.
Let’s pretend for a moment you’re a developer looking for a chain to build on. ICE would offer the following advantages:
- EVM compatibility, with smart contracts written in Solidity
- Direct access to/within the Polkadot ecosystem, allowing for DApp interopability across Polkadot’s many parachains (and access to Polkadot’s entire userbase)
- Direct access to/within the BTP ecosystem, initially including Binance Smart Chain, NEAR Protocol, Harmony and others.
And of course, existing and potential future users of ICE would see the same advantages and the downstream advantages that come as a result.
Now, I know I mentioned earlier that there are bridges on other parachains that allow Polkadot to connect outside its own ecosystem. Of course, BTP would be one of those bridges.
So you might be thinking, well, if there are other EVM chains with bridges on Polkadot, what sets ICE apart?
And this is where I would once again emphasize the unique nature of BTP’s design. Remember, BTP is truly a trustless bridge, that doesn’t rely on the good behavior of validators or game theory. It functions at the smart contract level, making it unique within the interoperability ecosystem.
Also keep in mind why ICE was even conceived of — the ICON team wanted the ICON chain to be optimized for BTP:
The current ICON network will continue to optimize for BTP, and begin focusing specifically on interoperability and low-latency cross-chain apps. The core focus becomes increasing integrations of other networks and driving volumes through BTP. Therefore, the narrative of the ICON network shifts from “build DApps on our network, and we also have BTP” to “Use BTP as your interoperability solution because it is the most secure and decentralized on the market”. We believe we are in a great position to drive this activity, providing the necessary incentives to drive growth.
In the same way that Polkadot allows its parachains to specialize, the existence of ICE allows the ICON network and team to focus almost entirely on a fast, reliable, and secure BTP.
The Role of SNOW
As I mentioned earlier, SNOW is the Kusama “version” of ICE:
As we highlighted earlier, our goal with ICE is to secure a Polkadot parachain slot. In the Polkadot ecosystem, many projects launch on Kusama (Polkadot’s canary network) before competing for a Polkadot parachain slot. For example, Moonriver on Kusama is the canary network to Moonbeam on Polkadot. ICE will employ a similar strategy by first launching the SNOW canary network on Kusama before targeting an ICE launch on Polkadot later on.
As a cutting-edge development environment with real-world value, SNOW will provide developers with access to the latest code releases as well as an experimental environment to conduct application tests that are not possible on a traditional testnet with valueless tokens.
This is why we’ll get the SNOW blockchain first — because it’s the playground to try things out before ultimately deploying them to Polkadot (via ICE).
It’s also likely why we’re getting 100% of the SNOW distribution at once, as opposed to the ICE vesting model. Theoretically, this allows for a higher level of experimentation since a significant amount of liquidity will exist immediately within the SNOW ecosystem.
While you may again be tempted to consider SNOW just a “lesser” version of ICE, I’d like to point out what the chains running on Kusama have been able to produce thus far.
Moonriver — the Kusama version of Moonbeam — has built up a DeFi ecosystem with more than $250m of TVL, including the deployment of SushiSwap. A vast majority of these DeFi DApps were ported from Ethereum, illustrating Moonriver (and Moonbeam’s) focus on EVM compatibility cited earlier in the article.
Meanwhile, Karura (the Kusama version of Acala), has $73m in TVL, including the Karura Dollar (kUSD):
The Karura Dollar (kUSD), is a decentralized, multi-collateralized stablecoin backed by cross-chain assets. Stable by design, and pegged to the U.S dollar, kUSD is now on its way to being the de facto stablecoin of Karura and Kusama.
Karura also launched Karura swap, which was the first decentralized AMM on Kusama. The fact that Kurara is the first place where DeFi DApps native to Kusama launched illustrates that Kurara is aiming to be the “DeFi Hub” for Kusama and Polkadot.
Hopefully by now you can see why Kusama is no mere “testnet”. Moonbeam and Kurara were able to build out complete blockchains that already compete among the top blockchains for DeFi supremacy. But still, why not simply deploy straight to Polkadot rather than spending time building on the “lesser” chain?
The Web2-style, move-fast-and-break-things approach to software development doesn’t work in the cryptocurrency space. Kusama helps us substantially de-risk changes and updates by running code under real economic conditions and creating a place where innovation and ideas can be worked out before they are brought to Polkadot mainnet.
A regular testnet allows you to answer the question “Does this code work?” Kusama allows you to answer the questions: “Do users interact with my DApp like I expected them to? Does my DApp work like I thought it would?”
Remember, Polkadot is meant to be the “big leagues”, and potentially aims to have institutional-level, enterprise integrations in the future. From that standpoint, you can understand why they’ve spent so much energy building out a playground for DApps before they’re called up to the Majors. Polkadot’s team wants its primary chain to be as polished as possible. No bugs. No hacks. No shoddy DApps that aren’t ready for primetime. (at least to the extent that’s all possible)
We should anticipate SNOW being the initial deployment chain for the various projects that will be built on ICE. And that’s why it will launch prior to ICE. It will allow both the developers and the users to experiment with and refine their applications before deployment to ICE (and Polkadot). From that standpoint, there will likely be DeFi and other protocols that allow users to earn yield or profit — thus, giving value to the SNOW token.
Hopefully, by now, you have a better understanding of how ICE and SNOW will fit in with the Polkadot ecosystem, and how ICON’s BTP will make both more alluring to users and developers alike.
To be sure, a number of details still need to be worked out — how, for example, does ICE plan to win a parachain auction? — but I anticipate we’ll get many more details over the coming months.
In the meantime, with the snapshot having occurred, it’s time to get excited about the opportunities that the ICY and ICZ tokens will provide on their respective blockchains.