We are excited to announce to ggAVAX holders that ggAVAX has officially been integrated into Deltaprime!

This collaboration gives ggAVAX holders a plethora of defi strategies to access and will help further expand Avalanche and Subnets.

A Milestone Integration: ggAVAX and DeltaPrime

This integration is more than just a technical collaboration; it symbolizes a seamless blend of two innovative forces in the DeFi space. Here’s what this means for ggAVAX holders:

• Improved risk management: With the integration, ggAVAX holders can now modify their exposure, borrowing up to 5x their ggAVAX. This opens up new avenues for investment strategies and risk management (think for example borrowing AVAX, trading that for ggAVAX).
• Collateral Flexibility: ggAVAX can now be used as collateral for a multitude of new DeFi activities. This includes participating in longing/shorting of DeFi assets, liquidity pools, and exploring diverse farming strategies.
• Improved support: Every ggAVAX holder actively supports GoGoPool as well as Avalanche as a whole. With this integration you can increase your support from $100 to $500, without having to deposit any additional money.

The Avalanche Effect: Why This Partnership Matters

Unleashing Trapped Liquidity:

One of the primary benefits of this integration with Deltaprime is the unlocking of trapped liquidity within the Avalanche ecosystem. AVAX that would otherwise get trapped in overcollateralized lending pools, can now be borrowed and swapped for ggAVAX instead, strengthening the Avalanche chain.

Additionally, by enabling more efficient and diverse uses of ggAVAX, the collaboration ensures that liquidity is not just present but actively contributing to the broader ecosystem’s growth.

Expanding Avalanche and Subnets

The utility and leverage options provided by this partnership incentivize users to hold and utilize ggAVAX. This is crucial for maintaining the decentralization and security of Avalanche as an integral aspect of GoGoPool’s contribution to this partnership is our innovative approach to launching validators on Avalanche.

Traditionally, launching a validator required significant technical know-how and a substantial financial commitment. However, with GoGoPool’s mechanism, launching a validator becomes less complex and more affordable. By depositing ~1,111 AVAX, in one-click individuals can be matched with the necessary additional AVAX, signup for their hosting, and have their validator launched and managed. This simplifies the process dramatically, removing the barriers of coding expertise and complex multi-site navigation.

Introducing DeltaPrime: A DeFi Powerhouse

DeltaPrime has established itself as a leader in the Avalanche ecosystem, providing trustless, undercollateralized loans and maximizing fund utility. Its partnerships with top DeFi protocols like Trader Joe, GMX, and Yield Yak have positioned it as a hub for a wide array of DeFi strategies.

• Expanding DeFi Horizons: DeltaPrime’s platform allows users to explore borrowing, lending, and liquidity pooling with greater ease and effectiveness.
• Strategic Collaborations: The collaborations with various DeFi protocols ensure that DeltaPrime users have access to the best and most diverse financial strategies in the decentralized space.
• Risk management: DeltaPrime shows that leverage does not necessarily lead to an increase in risk. With many of her users hedging their assets within the platform, they increase generated fees and incentives, while reducing exposure to the price of the asset.

Conclusion

The GoGoPool and DeltaPrime partnership is more than just a collaboration between two entities; it’s a forward leap for the Avalanche ecosystem. By enhancing liquidity utility, simplifying validator operations, and offering diverse financial strategies, this partnership paves the way for a more inclusive and efficient DeFi environment.

Stake your AVAX here to get started:

https://app.gogopool.com/liquid-staking/

Already have ggAVAX? Get started with DeltaPrime here:

https://app.deltaprime.io/#/prime-account/zaps

We are excited to release the first version of Pandasia — a platform to help Subnets grow by airdropping to registered Avalanche Validators. Avalanche is now home to the easiest way for developers to airdrop tokens to those who are most heavily committed to the success of their chain, validators.

To help test the smart contracts and create an initial list of registered node operators, the first testers will get a small GGP token airdrop. If you are a validator node operator, please register today at pandasia.io. Minipool operators are already pre registered and can claim their tokens now.

Using Pandasia users can seamlessly connect their C-chain and P-chain addresses, allowing for validators to become verified and qualify for Subnet airdrops. By airdropping rewards to verified validator nodes, we encourage validators to actively participate in their Subnet, helping build a stronger community.

Pandasia V1 Test

The GGP token is crucial to the continued expansion of Avalanche and Subnets. It allows for node operators to launch Avalanche validators through GoGoPool, called Minipools, at half cost.

Minipools are also considered to be the highest ROI way to run an AVAX validator and are automatically registered for airdrops from Subnets via Pandasia. If you’re a validator, just hit “connect wallet” and navigate to the “Claims” page. It’s that easy.

If you’re still validating Avalanche the traditional way keep reading for a walkthrough on how to register and claim your airdrop.

How to Register:

1. Navigate to https://www.pandasia.io/ and tap the “Register” button on the homepage.
2. Visit https://wallet.avax.network/ and select the “Advanced” tab.
3. Copy the p-chain address you receive validator rewards on and paste it in the address field under the “Sign Message” column
4. Copy your c-chain address and paste it in the message box and click “Sign Message”
5. Copy your signature string
6. Navigate to the back to Pandasia and submit your signature in the “Paste Signature to Complete Verification” field.

Claiming an Airdrop:

1. Go to the “Claims” page.
2. Select the “Claim” button for the airdrop you’re interested in.
3. For more details, click “View Guidelines” on the airdrop card.

How to Subnet Developers Can Contact Us:

If you’re a Subnet developer and you’d like to utilize Pandasia to distribute your token amongst Avalanche validators please either dm the official @GoGoPool_ account or @stvngts directly.

How Does it Work?

Multisiglabs has developed a groundbreaking method for linking C-chain and P-chain addresses; something that was not possible, until now. By signing a specific message format in your wallet, we ensure the security and integrity of this process. This technology is backed by a Go program that integrates P-chain data into a SQLite DB, identifying addresses used as validator reward addresses. This innovative approach solidifies the foundation of Pandasia, ensuring reliability and trust.

Here’s how it works:

1. Message Signing: When a user signs a message in their wallet, they’re not just signing the text they input. Instead, the wallet formats this input as part of a larger, predefined message. For instance, if a user is asked to sign their C-chain address, the wallet actually constructs a more complex message that includes this address along with additional, specific text.
2. Secure Message Construction: The actual message signed includes the user’s C-chain address within a structured format that begins with ‘Avalanche Signed Message:\n’. This format ensures that the message is unique and secure.
3. Hashing and Verification: The wallet then creates a sha256 hash of this message, which is what gets signed. This hashed message is crucial for security and verification purposes.
4. Off-Chain Validation: Since the C-chain cannot directly query the P-chain for information, Pandasia employs an off-chain solution. A Go program is used to compile P-chain data into a SQLite database, identifying addresses that have been used as validator rewards addresses.
5. Merkle Tree Integration: This data is then used to create a comprehensive Merkle Tree, with the merkle root posted to the Pandasia contract. Users can obtain a merkle proof for their address and submit it to the contract, which then verifies the address and proof against the merkle root.

This technical approach enables Pandasia to securely and efficiently link Avalanche’s C-chain and P-chain addresses, paving the way for a more integrated and decentralized blockchain experience.

Join the Revolution

Pandasia is more than just a platform; it’s the future of decentralized validation on Avalanche. Be part of this groundbreaking journey. Register, claim your airdrop, and be a part of the thriving Avalanche community.

Avalanche is now home to the easiest way to launch a validator node in web3 — with a single transaction. Now, users only need to hold ~1111 AVAX in their wallet and make a single transaction to launch a validator node through the GoGoPool protocol — resulting in a minipool, the highest ROI way to run an AVAX validator node.

Go to http://bit.ly/one-click-minipool… and launch an Avalanche validator node as a Minipool — the highest ROI way to run a validator.

To celebrate the One Click Launcher’s release our partner ooNodz is offering a 25% discount on hosting until 12/11.

You can also qualify for your share of over $400K in monthly $GGP incentives by signing up before 12/9.

Now launching a validator is a matter of a simple, one-click process, eliminating the need for coding expertise or navigating through multiple sites. We are addressing the often complex and technical challenge of launching a validator head-on.

For more details about the One Click Launcher and how you can get started keep reading below.

Problem

Launching a validator on Avalanche is complex and technical, requiring coding knowledge and navigation across multiple sites.

Solution

GoGoPool introduces a one-click solution for launching Avalanche validators, streamlining the process significantly.

Key Features

Simple Launch: Validators can be launched with just one click

Lower Entry Cost: Launching your validator through the One Click Launcher requires 1111 AVAX total instead of the traditional 2000 AVAX + hosting fee

No Hosting Setup: Your NodeID is generated on GoGoPool, powered by ooNodz

Increased Rewards: Users can earn more without needing to set up anything — just deposit AVAX, and earn an extra AVAX commission + GGP rewards

Advanced Options: Options for one-click or manual setup

Ease of Use: No complex setup or management is required

Underlying Technology — Smart contract-based infrastructure via Oonodz, with $GGP market buying handled for users — Secure staking through GoGoPool protocol which utilizes advanced multisignature technology

How to Use:

1. Fund your wallet with 1111 AVAX
2. Visit https://app.gogopool.com/create-minipool/… and use the One-Click Setup button
3. Select your country or residency and validation length, then hit the “Create My Minipool” button
4. Join the community of Avalanche validators in our Discord: https://discord.gg/VjqjSr8waC

Vision

GoGoPool aims to simplify launching nodes for any Subnet, making blockchain technology more accessible and introducing NodeFi — a concept for maximizing risk-adjusted yield from validator nodes. This service is positioned to make validating on Avalanche and Subnets much more accessible and rewarding, attracting a broader audience to blockchain and decentralized technologies.

We are excited to announce that we will be holding a content contest for all of the talented Avalanche community members out there! We recently held our landmark keynote First Step and want to see content summarizing what happened — be it videos, articles, or threads. The goal is to talk about these announcements:

• One Click Launcher
• Pandasia
• GoGoForum + Grants
• Multisig Labs Brand Reveal
• ooNodz Network 25% discount on hosting
• SwissBorg Partnership

Here is our First Step summary post for a little bit of inspiration: https://twitter.com/GoGoPool_/status/1731764664579621012…

Here’s a link to the First Step livestream: https://twitter.com/GoGoPool_/status/1731704906724290795…

Contest Prize: 10 AVAX

Type of content: Threads, videos, articles

Contest Duration: 12/5–12/12 **Last submissions by 12pm EST on 12/12**

How to Enter:

1. Like + repost this tweet
2. Post your content on Twitter + tag GoGoPool
3. Submit application with link to content

To Apply: https://docs.google.com/forms/d/e/1FAIpQLSfhVQcXrbgxMMxCr6OmXbupuJ05K-nYEcChcbv4kwZlxdM3cA/viewform?usp=sf_link…

Selection Criteria: Content will be judged based off how well information presented during First Step is described and the creativity of the content(creative graphics, writing style, etc.)

We’re looking forward to seeing what you create!

Our goal is to make subnets easy. For cloud based development, we have GoGoPro (Coming Soon!). If you want to develop locally, we have GoGoTools. With GoGoTools, you can:

• Make your “Time to RPC” 10x faster
• Easily create many isolated environments to test different versions of binaries
• Deploy and test your Smart Contracts entirely locally

Installation

You can download the latest binary from the GitHub Releases or you can build from source. Once you have the binary, move it to your PATH and rename it to ggt.

To properly use GoGoTools, you should have Foundry and jq installed as well. Foundry is a new Solidity toolchain written in Rust, and can be installed on Unix based systems with the following commands:

curl -L <https://foundry.paradigm.xyz> | bash
foundryup

You can install jq using your preferred package manager. For example:

brew install jq

or on Ubuntu and Debian

sudo apt update && sudo apt install jq -y

Once all that is done, you can start using GoGoTools!

Note for MacOS Users

When you download the binary, it may pop up an error warning you about executing the binary that’s not signed. Simply go to your security settings and allow GoGoTools, and it should work afterwards without issue.

Getting Started

Create a new directory called mysubnet

mkdir mysubnet
cd mysubnet

Now we can initialize a new subnet!

ggt utils init v1.10.1 v0.5.1
ggt node prepare MyNode --ava-bin=avalanchego-v1.10.1 --vm-name=subnetevm --vm-bin=subnet-evm-v0.5.1

This should have added some new files to your directory. We will go over what they do at a later date, for now just remember that they are needed for your subnet to work properly.

To start up your node, open a new terminal window in the same directory and run the following

ggt node run MyNode

Now that your node is running, we can create a new subnet on the node.

Creating a Subnet

Now we can initialize your subnet! To initialize, run the following commands in another terminal:

ggt wallet create-chain MyNode MyChain subnetevm

This will initialize and create a new wallet. To get the RPC URL of the new subnet as well as the local C Chain, we can run the following command:

ggt node info | jq -r '.rpcs'

You can use this RPC URL in Metamask, Hardhat, Truffle, or any other development tool just like any other Eth-based network. To properly use cast, which is Foundry’s tool for calling commands on chain, we need to add the environment variable ETH_RPC_URL to the current session. Execute the following:

export ETH_RPC_URL=`ggt node info | jq -r '.rpcs.MyChain'`

Now we can call cast directly:

cast chain-id

Or via ggt cast

ggt cast balances | jq

Multiple Nodes

Each node you create exists in its own directory. You can create many different nodes with different settings and configs as you experiment. You can start a particular node by saying

ggt node run <directoryname>

Precompiles

When we created our subnet, ggt created a directory called MyNode which contains all of the various configuration files, database files, and logs for avalanchego. If you want to play around with the built-in precompiles that SubnetEVM ships with, find the subnetevm-genesis.json file inside the MyNode/configs directory. Look for this section

"contractDeployerAllowListConfig": {
  "adminAddresses": ["0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC"],
  "enabledAddresses": null,
  "blockTimestamp": 0
},

Now add an array of address to the enabledAddresses key, and lets restart our node with this genesis. To do this, run

ggt node reset MyNode

This will delete the data directory for the node, so its starts fresh. Then run

ggt node run MyNode
# In another terminal, run
ggt wallet create-chain MyNode MyChain subnetevm

This will start the node, and create a new subnetEVM blockchain with your new genesis, which should only allow specific addresses to deploy contracts.

NOTE: The addresses in the adminAddresses and enabledAddresses keys CANNOT overlap, you must have different addresses for each key.

More info about the SubnetEVM precompiles is here.

Cast

We also have some convenience features for using cast to interact with your EVM. Some examples are:

ggt cast balances | jq
ggt cast send-eth owner alice 1ether | jq
ggt cast send owner NativeMinter "mintNativeCoin(address,uint256)" alice 1ether | jq
ggt cast call owner TxAllowList "readAllowList(address)" bob
ggt cast send owner TxAllowList "setEnabled(address)" bob | jq
ggt cast call owner FeeConfigManager "getFeeConfigLastChangedAt()"
ggt cast call owner FeeConfigManager "getFeeConfig()" | xargs cast --abi-decode "getFeeConfig()(uint256,uint256,uint256,uint256,uint256,uint256,uint256,uint256)"

The names used (alice, bob) are defined in the accounts.json file that was created when you ran ggt utils init.

Explorer

To launch your browser to a blockchain explorer pointed at your running node, run

ggt node explorer MyChain

This will connect to the default node RPC (http://localhost:9650) and query the node info for the RPC for your custom blockchain you created, and then open an explorer pointed at that RPC.

Mnemonics

You can generate a BIP-39 mnemonic with

ggt utils mnemonic

To see all the keys and addresses for a mnemonic, run

ggt utils mnemonic-keys "test test test test test test test test test test test junk"

This will show the first 10 keys in both C-Chain (Ethereum) format as well as P-Chain (Avalanche) format

0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 m/44'/60'/0'/0/0
0x70997970C51812dc3A010C7d01b50e0d17dc79C8 59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d m/44'/60'/0'/0/1
0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC 5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a m/44'/60'/0'/0/2
0x90F79bf6EB2c4f870365E785982E1f101E93b906 7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6 m/44'/60'/0'/0/3
0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a m/44'/60'/0'/0/4
0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc 8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba m/44'/60'/0'/0/5
0x976EA74026E726554dB657fA54763abd0C3a0aa9 92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e m/44'/60'/0'/0/6
0x14dC79964da2C08b23698B3D3cc7Ca32193d9955 4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356 m/44'/60'/0'/0/7
0x23618e81E3f5cdF7f54C3d65f7FBc0aBf5B21E8f dbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97 m/44'/60'/0'/0/8
0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6 m/44'/60'/0'/0/9
P-avax1yljhuvjkmtu0y5ls6kf4exsdd8gea9mp8jd32r PrivateKey-Fapb8hTUMABpZc9zWurmPR7why34LQNshss5RZHgCAgiY5n83 m/44'/9000'/0'/0/0
P-avax18wvaf02nxrfpxhz5fwrj5yjydhhrlef6jslzqg PrivateKey-2DFyMtm5iENeShhPsXenSsQepoVwUMNbSG9DHRxsQEwSwM3e48 m/44'/9000'/0'/0/1
P-avax1kk4tuwm7ley05828x75p8pvdcw5j3wlveyr6rf PrivateKey-2B9ukB5wfRqS8vnJRWQohAEaZNQtV6NksrCb1B3wdozw2AKz9o m/44'/9000'/0'/0/2
P-avax1au4csswhjcjd3d9dzxj532puc4s6fm5twqrhmg PrivateKey-FaWRW4Fwpy8dgPq1WmshzmMVqD7Lg89pfPngMnY9aoi7cotbu m/44'/9000'/0'/0/3
P-avax1s8kxj6agyaf4qwdu9y37aklgq3c0kjnj69nhhg PrivateKey-2oo4uTtBJfU64mB2G8E1ggJGbcL1XTq1siaR2EY4KCJSkv7T8t m/44'/9000'/0'/0/4
P-avax12r4ys4ssmj56q0z36w080u4z8546apr3fxm6qc PrivateKey-R79TRuBkoJympQD33nsP3kdmBCr7QWLH7zUtgfhjc3uaA7icc m/44'/9000'/0'/0/5
P-avax1sdn9w8tsfets3lmfz23war6gqd270en38962rn PrivateKey-2mWtmQ2iQxEdGwjhbXH7jwETk2n7xDeZbGRNrM8pJyoosWfeV5 m/44'/9000'/0'/0/6
P-avax1hvdsp7z6z9dqwvasu2dk6xjf5u6kuyrst7vpjl PrivateKey-2fP2rzMCgN6LvKzKWnLYzeBtT41G47Cs5bC7FAWKJgwsrnZt3Z m/44'/9000'/0'/0/7
P-avax1935pmegr7aayegy8llaeznn9axap44evnh36lp PrivateKey-KyVd5iu1CJ32QrynkwhqFLBjeTyxWkkjN4zWgMoVvE8VyDi2V m/44'/9000'/0'/0/8
P-avax1yj4kunsv2z5dmwkmm56l65hwaer2s6g5gagppg PrivateKey-H6bSJB5xj2FbMuV9xoZRaKnTqEpbmRtUWBiTfD7FhNFiWLLza m/44'/9000'/0'/0/9

Conclusion

By leveraging GoGoTools, you can significantly increase your developer velocity while working on subnets. By leveraging GoGoTools, developers can significantly reduce their “Time to RPC,” create isolated testing environments, and deploy and test Smart Contracts locally. The intuitive installation and setup process makes it easier than ever to harness the power of GoGoTools for your projects. With seamless integration into existing development tools such as Metamask, Hardhat, and Truffle, GoGoTools is set to become an indispensable tool in the Avalanche Subnet and Solidity development ecosystem. Don’t miss out on this powerful suite that streamlines your subnet management and optimizes your workflow. Try GoGoTools today and experience the difference for yourself!

Hello Avalanche!

The GoGoPool crew is thrilled to announce that we are attending the much-awaited Avalanche Summit 2023. Our team will be on the scene for all three jam-packed days of the conference, hosted in the beautiful city of Barcelona, Spain, from May 3–5.

We are proud to sponsor a booth where attendees can meet select team members, learn more about the protocol, and gain insight into how we make subnets easy.

Don’t miss the chance to hear GoGoPool’s founder, Steven Gates, as he speaks on a distinguished panel discussing “Good Subnetting: Intel from Early Subnet Pioneers.” The conversation will include a group of subnetting pioneers who will delve into the advantages of the innovative Avalanche technology and its impact on our industry. The panel is scheduled at the conference venue on May 3 at 3:30 pm.

Additionally, we are delighted to announce that we will host a workshop session on May 4 at the conference venue, beginning at 3:10 pm. We invite you to join us to meet our team and learn about our advanced Subnet and liquid staking solutions. Moreover, we’ll present an exclusive demo of our new developer tool, GoGoPro, simplifying the subnetting process. You won’t want to miss this event, so mark your calendars for an enriching experience!

GoGoPool is pleased to share our passion for revolutionizing the world of Subnets and the blockchain industry. This conference is the perfect platform for us to connect with other experts and enthusiasts and share our vision for the future.

Please stay connected with us throughout the conference by joining our Telegram group @ggp_team and our Discord channel.

We look forward to seeing you there!

-The GoGoPool Team

The WordPress moment for Web3 is arriving, and Avalanche Subnets are now at the frontier. Tooling like AWM, precompiles, and HyperSDK enable Subnets to launch with greater frequency, and support from the Avalanche Foundation makes building a Subnet exciting!

New business models are emerging, forming the backbone of the Subnet Economy. As our ecosystem grows, however, three problems are becoming apparent:

1. Subnet projects are often priced out

Validators of a Subnet must also be a validator for the Avalanche Primary Network. The minimum staking amount for the Avalanche Primary Network is 2,000 AVAX for a single validator node and 10,000 AVAX for a 5-node subnet. It can be cost-prohibitive for a Subnet to start building on top of Avalanche, as they need to bear the cost of running validators for their own network in addition to sourcing the AVAX required to validate the Primary Network. Additionally, many Subnet operators want to source node operators from the community — meaning the community needs to front this cost. Projects need cheaper access to hardware in a permissionless and non-custodial way.

2. Subnets need an Ecosystem with tooling to ship faster

Currently, launching a subnet is complex and time-consuming, requiring a great deal of manual effort. But with the right tooling and support, Subnets can be launched faster and more securely. A proper Subnet Ecosystem will make it easier for developers to customize their Subnets and make them more accessible to users while allowing ecosystem developers to develop their own business models. This will lead to a wider variety of use cases in the Subnet Economy and overall better user experiences.

3. Subnets and Community lack ways of growing together

Right now, there is no easy way for the community to access the Subnet Economy or to get involved with builders. Growth is siloed. Most Subnet operators must operate with limited information and minimal community feedback. This is because the Subnet community is currently fragmented and has a lack of access to these Subnet teams — slowing down the launch velocity of projects. A direct onramp needs to be created between the community and Subnet projects, accelerating the growth of both the Community and Subnets and allowing each party to work together.

How GoGoPool solves these problems:

GoGoPool is a permissionless staking protocol built for Avalanche Subnets. At launch, GoGoPool reduces the AVAX requirement to launch a new validator node by about 50% via liquid staking.

When using GoGoPool to liquid-stake AVAX, users receive the ggAVAX token, a new staking token that represents their staked AVAX plus any rewards it has accrued in real-time. Users can sell, hold, or spend ggAVAX and can use ggAVAX in DeFi in the same they use AVAX. You use ggAVAX to grow the Subnet Ecosystem while liquid staking.

To launch a new validator node through GoGoPool, users supply their own hardware and register minipools by staking only 1000 AVAX (instead of the normal 2000) and stake 10% of that value via the GGP token. Because node operators stake AVAX and GGP, they earn rewards in both AVAX and GGP. New minipools are placed in a queue to get matched from the ggAVAX deposit pool. Once matched, minipools are launched as full AVAX validator nodes.

The GoGoPool protocol is designed to maximize safety and freedom for node operators and liquid stakers while maximizing Subnet use cases. Minipools are noncustodial — node operators retain full ownership of their validator node and may use it to validate Subnets. By keeping the protocol permissionless while maximizing the reward-to-risk ratio for DeFi users, network participants are given a direct path to getting involved with Subnet projects launching through our community and the GoGoPool DAO.

GoGoPool’s mission is to accelerate the Subnet Economy. With minipools, teams will be able to source validator nodes easier. Liquid staking simultaneously provides the community a way to grow Subnets (and soon, we think, grow WITH Subnets). The GoGoPool DAO is tasked with shepherding our ecosystem to help more Subnets ship faster through open-source tooling and services.

We believe the ggAVAX and GGP tokens will be important base primitives in Avalanche that will align the community’s incentives towards a common goal: for Subnets to create the WordPress moment for Web3.

GoGoPool is the first core addition to the Subnet ecosystem. We have many more building blocks for the Subnet Ecosystem on the horizon — all aimed at making Subnets as easy as possible to design, build, and manage. Click here for a sneak peek at our second tool!

What happens next?

Over the next few weeks, we will

1. Release more blog posts explaining the GoGoPool protocol: its intended users, mechanics, tokenomics, and our vision for the future.
2. Host a series of Town Halls for the community to talk directly with the GGP founders, investors, and team about a variety of topics.
3. Announce mainnet and testnet launch timelines, with details about the starting DAO members.
4. Open-source smart contracts and audit results.

The Introducing GoGoPool Townhall with AvaLaunch will be held this Friday 3/10 at 4pm EST in our Discord. You can set a reminder here: https://discord.gg/fnwy3P37

Meanwhile, follow along on Twitter and Discord! If you’d like to help build GoGoPool and the Subnet Ecosystem by being a node operator or through liquid staking, send me a Telegram message @ggp_steven.

We are looking forward to working with you all!

~ Steven Gates, Founder/CEO of GoGoPool

The rapid growth of blockchain technology is shaking the world, but for those in the crypto sector, blockchain technology was already integral to the industry’s frontier (interoperability and multi-chain). Avalanche’s skyrocketing subnet ecosystem is paving the way for a new series of interconnected, diverse networks.

What are Subnets and their potential?

A Subnet is a sovereign network, meaning it defines its own rules regarding execution logic, virtual machine, tokenomics, gas fee regime, and level of security1. A subnet can also define its membership, meaning it can be as public or private as it needs to be; this includes validators securing the network.

Moreover, blockchains do not restrict subnets. A single Subnet can house multiple blockchains, becoming an L1 or L2 network2.

As sovereign networks, they don’t share execution threads, storage, or networking with other Subnets, including the Primary Network.

All of these things considered, the potential for subnets is huge! They are a highly flexible network infrastructure with the potential to be customized to fit the needs and requirements of a specific application, project, or organization. Subnets open the door for virtually any organization– from DeFi to TradFi to gaming projects– to build a sovereign network. Each Subnet, including the Avalanche Primary Network, would be completely independent. In other words, as long as they incentivize validators to secure their network, they cannot be shut down. However, as such, each Subnet would be responsible for securing its network.

As each Subnet is an independent network, it enables them to scale up effortlessly while enabling lower latency, higher transactions per second (TPS), and lower transaction costs3.

Use-Case Examples

At GoGoPool, we believe that Subnets hold immense potential to drive transformative solutions for institutions and projects.

Gaming projects may create a separate network to address congestion issues and high gas fees. This subnet will provide a smooth transaction experience for game users. Additionally, the project has the flexibility to tailor the network to its specific needs. For example, it can use a preferred programming language, virtual machine, or tokenomics and incorporate these elements into the design of the subnet.

Similarly, subnets can offer advantages for financial institutions4. Due to their versatility, institutions can configure subnets in a way that meets regulatory requirements. For instance, a financial institution can create a private subnet that only permits access to selective individuals or organizations or accredited investors. The institution can also set specific criteria for validators who want to secure the network, such as geographical location, KYC (Know Your Customer) verification, or holding a minimum amount of the network’s native token. These conditions can further enhance the security and compliance of the subnet.

Another option for institutions is to build a public Subnet. A public Subnet is open to all users as with a Layer-1 network like Ethereum or BNB Chain. Because its publicly viewable blockchain offers transparency on anything in its network, creating a strong sense of trust and regulatory compliance.

Some real-world examples of this already exist. On January 31, 2023, Intain, a structural blockchain-enabled financial platform, launched IntainMARKET on its subnet for tokenized asset-backed securities5. Intain specifically chose to build MARKETS on a Subnet because they allow institutionally-focused firms to create permissioned networks that comply with particular regulatory frameworks and other considerations6. Additionally, MARKETS aims to drastically improve investor experience, deliver real-time transparency into every single loan backing their investment, and collect returns on a more timely basis.

Projects involved in the DeFi sector can also benefit significantly from utilizing a Subnet. For example, a project on a Subnet can develop unique governance/gas tokens, and it does not need to use AVAX. Moreover, it can establish a consensus mechanism (even going so far as to have either a proof-of-work or proof-of-stake consensus), specific security measures, or devise a method for incentivizing validators to set up a secure node on its network. DeFi projects anticipating a high volume of transactions, such as thousands of transactions per second, can benefit from the absence of competition for resources and processing time.

Avalanche Warp Message: Subnet-Subnet Communication

Subnets faced limitations due to the absence of proper native communication tools. In the past, subnet projects that wanted to connect with other subnets or the C-Chain had to either develop their own bridging infrastructure or collaborate with a cross-chain bridge as a third-party entity.

These solutions, while practical, have their limits. Building a bridge is expensive, time-consuming, and can delay projects releasing their products and services. Relying on a bridge as a third party also comes with risks. In 2022, it became apparent that bridges could be exposed to persistent attacks and hacks, putting both funds and initial liquidity for the project’s token and revenue from trade fees at risk7. Furthermore, cross-chain bridges may not be suitable for subnet projects with unique, non-EVM architecture. Some projects, such as Swimmer Network, even resorted to using multiple cross-chain bridges to address this challenges.

The result has been a growing Subnet ecosystem whose communication could be more cohesive, clear, and efficient with a high UX.

However, this is all now expected to change with the launch of Avalanche Warp Message (AWM). As Avalanche’s native Subnet-Subnet communication infrastructure, it is the fifth — and final — Banff upgrade, which allows two blockchains running on different Subnets to send and verify arbitrary messages to and from each other9. A significant component of AWM is that there are no additional third-party intermediaries between Subnet-to-Subnet communication.

So, how do Subnets communicate with one another?

Firstly, take into account that AWM is not a token bridge or an oracle. Rather, It is a standard infrastructure that enables developers to build a token or oracle subnet on top of it.

That said, two major components make AWM possible– the P-Chain and the BLS Multi-Signature scheme.

The P-Chain is the core of AWM, keeping track of all stake records and BLS keys from registered validators in real-time. This enables Subnets to identify validators from other Subnets and verify messages they receive10.

A single BLS Signature is a method of verifying the authenticity of a signature using cryptography11. A BLS Multi-Signature aggregates multiple BLS signatures into one transaction by using an aggregated public key, making verification easy without the need for the original public keys12.

The idea is that a Subnet can know the validators of another Subnet to authenticate the message that came directly from that Subnet. Subnets can access or examine another Subnet’s database without incurring extra costs per connection. The validator on the targeted database can be asked to verify information such as the stake weight of a Subnet, its participants, registered BLS keys, etc. The Subnet can quickly and efficiently verify a BLS multi-signature by checking if it was signed by a required percentage of stake, which is the amount of the subnet’s native token staked by a validator.

Whew! That was a mouth full! So, what does all of this mean? By adjusting the percentage of stake, AWM allows developers to customize the security threshold of sending/receiving messages from other Subnets, meaning that some Subnets may have a higher threshold guarantee than validators from different Subnets must meet before receiving messages.

Secondly, AWM is VM agnostic, or compatible with any virtual machine. Projects building on a Subnet now have the freedom to build their own virtual machine without fear of sacrificing interoperability.

Finally, by having a standard infrastructure, cross-chain bridges can be built or integrated with it, allowing for a more efficiently interconnected ecosystem with a smoother flow of data and tokens.

Given all of these features, it should be no surprise that we have seen an explosion of Subnet activity. Currently, there are 32 active Subnets13, with around 85 Subnets on the Fuji Testnet14. Many of these were already active even before the launch of AWM! So the cards are on the table; Subnets are rapidly becoming the go-to network for many projects, organizations and institutions for the customization, sovereignty and flexibility that it offers. There is no telling how many more Subnet networks we will see become active in the future.

Stay tuned this week on Twitter and Medium to learn more about how GoGoPool plans to contribute to the future of the subnet economy! Don’t forget about to come to the GoGoPool Townhall on 3/10 at 4pm EST!

Set a reminder for the townhall here:
https://discord.gg/fnwy3P37?event=1082380739800211546

Join the Hunting Party! A one-week competitive game where four teams hunt for resources, make hilarious memes and battle it out for a chance to win big prizes ($3,000 MV!). You can track your progress and team standings 24/7 on the leaderboard.

Results

Looking for the results of the raffle? Check them out here!

How to Sign Up

1. To claim your spot, click the official sign-up link below
2. Click ‘Claim Your Spot’
3. Connect your MetaMask (If your MM is not detected, disable the Core Extension and refresh)
4. Connect your Twitter to boost your raffle chances and download your memes
5. Hover over the team asset packs to discover your team
6. Gameplay begins Sunday, 2/26, at 11:59 pm EST

Official Sign-up Link

Sign-up here: https://huntingparty.smolapa.com/landing

How to Play

1. Players can shoot up to 100 arrows per hour and can only hold a maximum of 100 arrows.
2. Point-and-click to shoot at woodland critters.
3. If you successfully hit a critter, it will drop a resource that can be viewed on the leaderboard.
4. There are many different critters to target, each with unique resource drop rates unknown to competitors.
5. Teams can work together to create a balanced hunting plan and increase their chances of success during the results period, but it’s not required!

How to Win Prizes

There are 5 ways teams and individuals can win prizes in Hunting Party:

1. Raffle

Earn tickets for completing one of the following tasks

• Sign Up= 1 ticket
• 300 Arrows Fired = 1 ticket
• Loudest Team= 10 tickets
• Highest Scoring Team= 10 tickets

Prizes:

• 3x Golden OOPA Token
• 1x Workshop Smol Estate (29 AVAX FP)
• 1x Smol APA (66 AVAX FP)
• 1x Ripperz
• 1x Ferdy ID

2. Highest Scoring Team

To become the “highest scoring team,” create a balanced hunting plan and stay consistent with your shots to gain as many resources as possible before the results party.

Prizes:

• OOPA Mint Whitelist for Entire Team
• Raffle Boost +10 tickets for Entire Team

3. Loudest Team

To earn the title of “Loudest team,” use our event hashtag on Twitter. Individual Twitter scores are calculated based on the engagement of their tweets. The sum of individual scores for each team will determine which team is the “Loudest.”

• #teamOOPA
• #teamRIPPERZ
• #teamGOGO
• #teamFERDY

Prizes:

• Raffle Boost +10 tickets for Entire Team

4. Highest Scoring Individual

To become the highest-producing hunter in the event, set clear goals, track progress, and adjust as needed to maximize results

Prizes:

• 50% AVAX pool
• $250 GC
• 1x Golden OOPA Token

5. Most Accurate Individual

To be eligible for the accuracy prize, you must fire a minimum of 1500 arrows. Accuracy= Hits/Shots.

Prizes:

• 50% AVAX pool
• $250 GC
• 1x Golden OOPA Token

FAQs

Questions? Connect with any of our sponsors on Twitter:

• GoGoPool
• OOPA
• Ripperz
• Ferdy Fish

On December 22, 2022, Avalanche reached an important milestone. After much anticipation, it finally introduced Avalanche Warp Message (AWM), a native communication protocol that allows Subnets to communicate. Experts are projecting that this new release will increase the competitiveness of becoming the number one interoperable blockchain.

Yet, just what is the mechanism behind AWM? What does AWM do, and how does it compare with the interoperability mechanism between Polkadot’s Parachains and Cosmos’ Zones?

This article will attempt to answer these questions by conducting a comparative analysis of the interoperability system between these emerging blockchain ecosystems: Avalanche’s Subnets, Polkadot’s Parachains, and Cosmos’ Zones. We will dive deep into each of their mechanics to examine how they function and assess their unique traits and limitations.

Parachains

Overview

Polkadot is a heterogeneous, Layer-0 network that connects multiple specialized blockchains into one unified network1. It achieves scalability through a sharding infrastructure, whereby blockchains are partitioned so that each validator node no longer has to process the entire network’s transactional load, and each validator only maintains information to its specific partition or shard. Technically speaking, this allows multiple blockchains to run parallel, called Parachains, that connect to a central chain called the Relay Chain.

(Source: https://wiki.polkadot.network/docs/getting-started)

Parachains are Layer-1 application-specific data structures that are globally coherent and validated by the validators of the Relay Chain2.

(Source:https://wiki.polkadot.network/docs/learn-parachains)

Polkadot is a shared or pooled security ecosystem where all Parachains connect and derive their security from the Relay Chain. The main takeaway is that all projects building on a Parachain would benefit from the economic security provided by the Relay Chain3. Since the Relay Chain acts as the de facto consensus mechanism for the Polkadot ecosystem, Parachains do not have to worry about maintaining their own nodes and consensus mechanism. Hence, all time and resources can instead be directed at building the project’s leading products and services.

Interoperability

Polkadot’s interoperability is very complex, but it can be divided between its Cross-Consensus Message (XCM) format, the Cross-Consensus Virtual Machine (XCVM), and Bridging Methods.

Cross-Consensus Message (XCM)

Parachains can communicate through Polkadot’s Cross-Consensus Messaging format or XCM. It is a generic format and aims to be the standard communication format for developers to define the data and origins between Parachains and different consensus mechanisms that their chains can send and receive from4.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

XCM is not a protocol and does not send messages between Parachains. Alternatively, it is a format for how message transfers should be performed. Also, it is crucial to note that XCMP is not the same as XCM, which stands for Cross-Consensus Message Passing5. Whereas XCM is what gets delivered, XCMP is a delivery mechanism. XCM can be used between Parachains, smart contracts, pallets, bridges, and sharded enclaves6.

Polkadot has not one but three cross-chain protocols that utilize XCM messages between chains: UMP, DMP, and XCMP7.

• UMP (Upward Message Passing) allows Parachains to send messages to the Relay Chain.
• DMP (Downward Message Passing) allows the Relay Chain to pass messages down to one of their Parachains.
• XCMP (Cross-Consensus Message Passing) allows Parachains to send messages between themselves.

Simply, XCM can be used to express a message’s meaning over any of these three communication channels.

XCMv3 is a significant upgrade and is expected to be deployed very soon. Once initiated, Parachians will benefit from additional functionalities, including support for bridging ( e.g., external networks), improved fee payments for operations, NFTs, and APIs for querying and invoking pallets on other chains8.

Cross-Consensus Virtual Machine (XCVM)

If XCM is what gets delivered, the Cross-Consensus Virtual Machine (XCVM) is a domain-specific virtual machine that provides a set of instructions by which XCM messages are composed9.

Put simply, a “message” in XCM is a program that runs on the XCVM. It is one or other XCM instructions. It includes several registers, as well as access to the overall state of the consensus system which is hosting it.

Interestingly, the XCM executor that follows the XCVM specification can be customized by developers or even ignored altogether and create their own construct that follows the XCVM specification10.

Bridges

Bridges are ways for two economically sovereign and technologically diverse chains to communicate with each other, and they can vary from centralized and trusted to decentralized and trustless protocols. While Polkadot tends to favor the latter, there is nothing impeding developers from building the former.

For a bridge to be compatible and function within the entire Polkadot ecosystem while still connecting to other blockchains (e.g., Ethereum), it will need to integrate the XCM message format.

This integration is a bridge with one of the following methods11.

1. Bridge Pallets

Bridge pallets are used for sending/receiving messages between Substrate-based chains12. A prime example is between Polkadot and Kusama, but this can extend to Parachains that use the Substrate programming language. Under this method, tokens can be natively transferred between them.

2. Smart Contracts

When sending/receiving tokens between a Substrate-based chain and a non-Substrate-based chain, for example, an Ethereum Virtual Machine (EVM) based chain, smart contracts will need to be deployed13.

3. Higher-order Protocols

This third method is for chains that do not support smart contracts, such as Bitcoin. Specifically, the XCLAIM protocol can be used to swap, but it would require the swappable asset to be backed by a collateral higher in value than the said asset14.

Advantages and Disadvantages

To summarize, Polkadot’s interoperability system is composed of three parts:

1. Cross-consensus Message (XCM) format — a delivery format that allows the creation of communication protocols between Parachains (XCMP) and the Relay Chain (UMP & DMP).
2. Cross-consensus Virtual Machine (XCVM) — a VM that provides specific instructions on how XCM messages are composed
3. Three bridging methods — protocols that transfer data and cryptos between various chains (either between Parachains or external blockchain ecosystems such as Ethereum, Avalanche, and others)

The XCM format has four distinct communication properties15:

1. Asynchronous: XCM messages in no way assume that the sender will be blocking on its completion.
2. Absolute: XCM messages are guaranteed to be delivered and interpreted accurately, in order, and in a timely fashion.
3. Asymmetric: XCM messages out of the box do not have results that let the sender know that the message was received. Any results must be separately communicated to the sender with an additional message.
4. Agnostic: XCM makes no assumptions about the nature of the consensus systems between which the messages are being passed.

This enables certain real use-cases16:

• Request for specific operations such as governance voting.
• Enables single use-case chains.
• The option to include payment of fees (gas fees) on a target network for requested operation (more below).
• Provide methods for three asset transfer models:
• Remote Transfers: Control an account on a remote chain, allowing the local chain to have an address on the remote chain for receiving funds and to eventually transfer those funds it controls into other accounts in that same remote chain.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

• Asset Teleportation: Teleporting an asset happens by destroying it on the original chain and creating a clone on the destination chain (ie, Burn and Mint).

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

• Reserve Asset Transfer: There may be two chains that want to nominate a third chain, where it can safely store a native asset that can be used as a reserve for that asset. Then, a derivative form of the asset on each of those chains would be fully backed (by the third chain), allowing the derivative asset to be exchanged for the underlying asset on the reserve chain backing it.

(Source:https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves)

Given what we now know, what does all of this mean?

Firstly, given that the aim for XCM is for it to be customizable and utilized throughout the Polkadot ecosystem by design, XCM is an intentionally robust, abstract and general format. Developers can integrate it with minimal barriers to allow their Parachain to communicate and send/receive tokens with other Parachains. As previously mentioned, even the execution of the XCM format can be customized or built on an entirely new one, making it much more robust.

XCM is not just used for sending messages between chains. It can also be used for transacting with a chain whose transaction format you don’t necessarily know well in advance. This enhances the flow of communication within the Polkadot ecosystem.

Concerning the actual flow of communication, Polkadot’s interoperability system offers a variety of options for developers. While XCM provides a format for how messages and transfers of data are composed and received, the three Asset Transfer Methods and Bridging Methods described above provide a rich combination of communication options. Developers on a Parachain can combine either method as they see fit. For example, a Substrate-based Parachain can use the Bridge Pallet method to communicate and transfer crypto assets natively with another Substrate-based blockchain while using the Smart Contract Bridge Method to transfer tokens with non-Substrate-based blockchains in the form of wrapped versions. Moreover, it can integrate either of the three asset transfer methods into the two bridging methods.

To further demonstrate their robustness, while the Smart Contract Bridge method was designed for communication between a Substrate based and non-Substrate based blockchain, it is very well possible for developers to use the said bridge method to connect between Substrate-based blockchains, so long as both chains support smart contracts. The same can be said for the Reserve-based Transfer method. Although designed for the transfer of wrapped tokens, Parachains can utilize a third chain to hold in reserve the native token asset while its wrapped version is held or traded between users in different parachain ecosystems.

However, at present, only between Substrate based-Parachains can the transfer of token assets be done natively. Wrapped tokens are still being used between Substrate based and non-Substrate back blockchains.

Fortunately, attempts to address this are being made. The Moonbeam Network is one such example with a unique response. Although built on a Parachain, it has an Ethereum Virtual Machine (EVM). As such, users can interact with other EVM-compatible blockchains (via bridges) and Ethereum tools, and popular wallets such as Metamask. This is possible due to having an Ethereum-style address (H160 format) which is matched with a private key that is used to sign transactions on the Ethereum side17. Additionally, this address is mapped into a storage slot inside the Substrate Balance pallet to a Substrate-style address (H256 format). This means that users not only have an EVM wallet address but a Substrate address as well!

However, there is a catch. Because a user’s private keys are only attached to their EVM wallet address, they are not connected to their 256 Substrate address18. Thus, they are unable to sign transactions on the Substrate side. They would need a Substrate-style private key in order to sign transactions and participate on the Substrate side of the chain. Although possible, this divides a user’s account into two incompatible sections, which only fragments a user’s experience.

Moonbeam’s answer to this is their Unified Account feature. By standardizing this account to conform with the Ethereum H160 address and Substrate H356 address standards, users would only need a single H160 address and its single corresponding private keys to sign transactions and participate in dApps on both the Ethereum and Substrate chains.

This was made possible because Moonbeam developers created compatibility between a substrate-based token standard and an ERC-20 token standard; the XC-20 token standard. This standard is not a wrapped token per se, but are Substrate-native tokens that are made to look like and act as ERC-20 tokens on Moonbeam. This way, a user would not need to have two separate accounts, but can just add the Moonbeam network on their Metamask wallet for example, just like any EVM compatible blockchain, transfer any tokens such as DOT from the Polkadot network to Moonbeam via the XCM format as an XC-20 token, and can interact with any dApp on Moonbeam. Essentially, Moonbeam’s Unified Account bypasses the need for a bridge between Parachains.

Yet despite all of these advantages, Polkadot’s interoperability system does have its limits. Firstly, the XCM format was not designed for every system that supports XCM to be able to interpret any possible XCM message19. Some messages will not have reasonable interpretations under certain systems. Others might be reasonable, but are still intentionally unsupported by the interpreter either due to resource constraints or because the same content can be expressed differently. Hence, it is inevitable that it only supports certain possible messages. Furthermore, heavily resource-constrained systems (like smart contracts) may support only a very limited version of it.

Secondly, because of its abstract nature, XCM does not automatically include a gas fee structure. Should a payment fee structure be needed, developers will need to build and integrate it into the XCM format. This is not a serious hindrance, but it is an inconvenient step that needs to be overcome.

Thirdly, Polkadot’s interoperability is still under development. Apart from the aforementioned XCMv3 upgrade that is yet to be deployed, there are features/tools that Polkadot’s interoperability still does not support. For instance, in a somewhat recent debate thread on Polkadot’s Forum, it was mentioned (several times) for the network to be able to support BLS signatures20.

A BLS Signature is a cryptographic signature scheme that was created by Boneh, Lynn and Shacham that allows a user to verify if a signature is authentic21. The idea behind a BLS Multi-Signature scheme is that it aggregates many BLS signatures to a common message, or transaction. As such, it permits a diverse array of signature aggregation options far beyond any other known signature scheme, including Polkadot’s GRANDPA signature scheme.

To be fair, the network does have plans to incorporate this scheme in the future22.

Fourthly, interoperability within Polkadot is tied to the success and security of the Relay Chain. Since it has a shared security infrastructure, this means that much (but not all) of the activity going on, including the transfer of tokens/messages between Parachains relies on the Relay Chain for validating and securing transactions and messages. While this can allow Parachains to leverage the security of the Relay Chain, were it ever to shut down or suffer an exploit/hack, it could cause the whole ecosystem to cease activities, making this a potential single point of failure.

Finally, Polkadot’s interoperability is limited to the ecosystem’s inability to expand any further. At present, both Polkadot and its sister chain Kusama are only able to support 200 Parachains each. This limits the ecosystem’s interoperability to only around those Parachains. This is in stark contrast to Avalanche that can support an unlimited amount of Subnets, making interoperability between them have no limits.

Nevertheless, Polkadot has made great improvements to its interoperability system in the last year. Their final 2022 Roundup Blog outlines all of their achievements23. So long as they continue to further improve, Polkadot is well on its way to becoming one of the most interconnected ecosystems.

Zones

Overview

Cosmos is a heterogeneous network of independent parallel blockchains, each able to be powered by the classical Byzantine Fault Tolerance (BFT) consensus algorithm like Tendermint (now branded to Ignite). This structure allows the network to interoperate with each other and scale. The Cosmos network is divided between two classes of blockchains; Hubs and Zones.

(Source:https://tutorials.cosmos.network/academy/1-what-is-cosmos/2-cosmos-ecosystem.html)

A Hub is a blockchain whose purpose is to connect Zones while limiting the number of connections and preventing double-spend attacks among them1. The Cosmos Hub is the primary example. It was the first blockchain to be launched and is the intermediary between all other Zones that connect to it2. The Cosmos Hub provides crucial services to the blockchains connected to it, including the largest interchain token exchange, shared security through interchain security, bridges to Ethereum (ETH) and Bitcoin (BTC), and secure custodianship of digital assets. The Cosmos Hub’s primary token is the ATOM3.

Zones are application-specific blockchains (more on them later on) in the Cosmos Network. By connecting to Hubs via the Inter-Blockchain Communication Protocol (IBC), they can communicate with each other and initiate the transfer of tokens and data4.

Interoperability

To understand Cosmos’ interoperability we need to examine its three components: the Inter-Blockchain Protocol Communication (IBC), the Cosmos Software Development Kit (SDK) and its Zones.

Inter-Blockchain Communication Protocol (IBC)

The Inter-Blockchain Communication protocol (IBC) is a permissionless, interoperable protocol that handles authentication and the transportation of data between blockchains5. The IBC is flexible, in that it can be used in a wide variety of blockchains and state machines. As such, it plays a crucial role for application-specific blockchains as it provides them with a common protocol and framework for implementing standardized inter-blockchain communication6.

The principle behind IBC is straightword. Below is an example of how IBC works7:

An account on chain A wants to transfer tokens, let us say 10 ATOM tokens, to chain B.

Chain B receives the headers of chain A, and vice versa. This allows each chain to track the validator set of the other.

When the IBC transfer is initiated, the ATOMs are locked up (bonded) on chain A.

(Source:https://v1.cosmos.network/intro)

A proof that the 10 ATOM are bonded is relayed from chain A to chain B.

(Source:https://v1.cosmos.network/intro)

The proof is verified on chain B against chain A’s header and, if it is valid, then 10 ATOM-vouchers are created on chain B.

(Source:https://v1.cosmos.network/intro)

These ATOM-vouchers are not native to chain B, meaning they are wrapped/synthetic tokens. The real ATOM tokens are locked up on chain A.

Should the user decide to transfer those 10 wrapped ATOM tokens back to the source chain; chain A, then the wrapped tokens will be burned and after verifying, chain A will unlock the 10 ATOM tokens on it, releasing them to the user.

Up to this point, the Cosmos architecture has shown the connection between Tendermint based blockchains. However, Cosmos is not limited to just that. Either by customizing IBC or through Peg Zones, Cosmos can establish connections with other blockchains, such Bitcoin or Ethereum8.

IBC is itself composed of two properties: the transport layer and the application layer. The transport layer (TAO) is what provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The application layer is on top of the transport layer and defines exactly how data packets should be packaged and interpreted by the sending and receiving chains9. The application layer is where applications or dApps can be built.

It should be noted that IBC does not allow blockchains to directly pass messages to each other. In order to communicate, blockchains commit to a precisely defined path reserved for a specific message type and a specific counterparty10. Relayers monitor for updates on these paths and relay messages by submitting the data stored under the path along with proof of that data to the counterparty chain.

(Source:https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html)

When it comes to security, IBC was designed around three main principles11. The first is the placement of trust on the chain’s ability to be secured by its nodes, not on the bridge itself. The second is the implementation of fault isolation mechanisms, so as to limit any damage done should these chains be subject to malicious behavior. The third is its utilization of light clients.

Light clients are blockchain clients that download only the headers of the blocks. Instead of utilizing full-nodes, by verifying the result of its queries against these headers, light clients give users a lightweight alternative with good security guarantees12. More importantly, they are able to track and efficiently verify the relevant state of the counterparty blockchain, check commitment proofs for the sending and receiving of packets on the source and destination chains respectively. In this way, IBC does not depend on any third party to verify the validity of cross-chain transactions.

Cosmos Software Development Kit (SDK)

The Cosmos SDK is a modular or generalized framework that eases the process of building secure blockchain applications on top of the Tendermint Byzantine-Fault Tolerance (BFT) consensus algorithm13. The application layer, which is situated above the networking and consensus layers, was created using the Cosmos SDK. It can be used to build blockchains regardless of its consensus algorithm.

The goal of the Cosmos SDK is for developers to create application-specific blockchains or Appchains without having to build everything from scratch. To accomplish this, the SDK has ready made specific modules or subsets that developers can easily just import into their application. You can think of them as certain LEGO pieces, such a door or wall made of red pieces that developers can use. Developers can also create their own modules14. An Appchain built using the Cosmos SDK is usually an aggregation of modules.

Additionally, the Cosmos SDK has built-in capability-based security measures, safeguarding the security between modules by limiting the scope of potential malicious interactions.

What the Cosmos SDK essentially brings to the ecosystem is customization without sacrificing interoperability.

Zones & Application-Specific Blockchains (Appchains)

As previously mentioned, Zones are independent application-specific blockchains (Appchains), built and customized by its developers to meet certain requirements and needs. A Zone contains one Appchain, but it can house multiple dApps. Hence both names can be used interchangeably. In this subsection, we will call them Zones.

What makes a Zone an Appchain is due to having two key components: its ability to be customized in however way developers want their application to be, all while maintaining its sovereignty.

Developers have a range of tools and resources to build their Appchains, but when it comes to interoperability with a chain with a non-Tendermint consensus mechanism, all that is needed is to adopt the IBC to connect with a Tendermint-based one.

Yet, the real joy is that none of these tools and adaptation methods will hinder a Zone’s sovereignty. When building a dApp over a general-purpose virtual machine blockchain such as Ethereum, stakeholders have limited control and say over their application, which makes them vulnerable to the governing decisions from the underlying blockchain. Stakeholders also have to accept the architecture of the underlying blockchain by default15.

Appchains are designed to address these issues. They can allow developers to choose a proven programming language , or just their own, or they can use their own custom cryptography while relying on well-audited crypto libraries16. When using an SDK module, developers and users also do not have to worry about potential bugs or exploitable mechanisms in the underlying blockchain since these are mere pieces for a larger project, which mitigates risks. Additionally, application-specific blockchains can choose to be interoperable (public) or remain isolated blockchains (private).

Another crucial advantage is the reduction in network traffic as transactions on Zones are only validated by its own validator nodes in parallel with other Zones, independent of the Cosmos Hub. This not only allows the network to scale, but makes it cost efficient and is less prone to congestion during high traffic transaction time.

Advantages and Disadvantages

To summarize, Cosmos’ interoperability system is comprised of three parts:

1. Inter-Blockchain Communication Protocol (IBC) — A permissionless, interoperable protocol that handles authentication and the transportation of data between blockchains.
2. Cosmos Software Development Kit (SDK) — A generalized framework tool that allows developers to build customized blockchains without having to build everything from scratch.
3. Zones & Appchains: Zones or Appchains are one and the same thing. They are single-purposed, customized blockchains with a relatively better performance whose creators and stakeholders have full sovereignty over. Zones can be interoperable or isolated, public or private blockchains.

Taking all of this together, the Cosmos ecosystem is a decentralized, yet interconnected, application-specific set of blockchains. Each Appchain or Zone not only has its own unique components and architecture, but they are also sovereign ecosystems in their own right.

Unlike Polkadot, Cosmos does not have a shared security system. Each blockchain is required to set up its own validator set and trust assumptions. Now with the launch of Interchain Security, it is now possible and more efficient for these blockchains to leverage the security of the Cosmos Hub by setting up its validators to secure their own network, if they so choose17. This way, projects with less capital and resources will not have to spin up their own validator set and Cosmos’ Hub validators and delegators can earn additional rewards in the form of that chain’s native governance token. This helps reinforce the security of the Cosmos ecosystem.

For interoperability, Cosmos offers developers a standard set of tools, consensus mechanism structure and infrastructure on which to build on. These standard components are critical in providing a standard method from which blockchains can communicate with each other. This facilitates the flow of data and transfer of tokens between chains, making it not only more secure, but cost efficient and far less time consuming.

However, this is not only what Cosmos’ interoperability can offer. Similar to Polkadot’s Remote Transfer system, Cosmos has Interchain Accounts (ICAs). These allow users to control an account on a host chain from a controller chain by sending IBC packets18.

What we have in the end are blockchains that can be as interoperable and public, or as isolated and private as they need to be.

Yet despite all of these advantages, Cosmos’ interoperability does have its disadvantages. First and foremost, the tokens being transferred between Zones are not native, but a wrapped version of the original token. This means if users want the original back, they would need to bridge back to the original chain where the token natively resides. Another issue that can arise is inequivalent value. Although the wrapped token is supposed to represent the original token in both value and price, due to high market volatility, there is the risk of the price of the wrapped token depegging, albeit often temporarily. This is in stark contrast to both Parachains and Subnets that allow tokens to be natively transferred between chains, thereby mitigating price volatility or even manipulation risk for such tokens.

Secondly, by default the Cosmos SDK is tied to the Tendermints proof-of-stake consensus mechanism. Transactions are passed to the application layer through the Application Blockchain Interface (ABCI)19. However, ABCI also divides the work of processing transactions between the two components20. While enabling the creation of unique blockchains, this also makes the application layer dependent on Tendermint, restricting developers to use other, more advanced forms of consensus mechanisms when using the Cosmos SDK. To be fair, there are attempts at being able to replace Tendermint with other consensus, such as with the Narwhal and Bullshark consensus algorithms21. However these consensus are not only relatively new and untested, but are a form of BFT consensus mechanisms, not all that different from Tendermint.

In conclusion, there is no denying that Cosmos is well suited to being a leader in the drive to achieve interoperability. It has a standard, yet flexible method for communication and cross-chain transfers, coupled with a software development kit to build customized blockchain networks. Although its interoperability system does face certain restrictions, there is no denying this network’s potential.

Subnets

Overview

Avalanche is another Layer-1/0, open-source, smart-contract capable platform for launching decentralized applications and enterprise blockchain deployments in one interoperable, highly scalable ecosystem1.

A distinct difference between Avalanche and other decentralized networks is the consensus protocol. The Avalanche protocol employs a novel approach to consensus called Snowman to achieve its strong safety guarantees, quick finality, and high-throughput without compromising decentralization2.

Additionally, with Avalanche, users can create an unlimited number of customized and interoperable blockchains called Subnets.

Subnets are sovereign networks with their own defined rules, tokenomics, consensus mechanism and membership3. Their networks are secured via a dynamic group of validators functioning to achieve consensus on the state of one or more blockchains. Within a Subnet, Avalanche allows anyone to create their own custom-made application specific blockchain, supporting multiple custom virtual machines such as EVM and WebAssembly (WASM) and written in popular computer programming languages like Go rather than just Solidity. This virtual machine can then be deployed on a custom blockchain network, a Subnet, where complex rulesets can be configured.

(Source:https://docs.avax.network/Subnets)

The inherent nature of Subnets creates the potential for a powerful technical tool within web3. This model allows for reductions in network traffic as transactions on Subnet blockchains are only validated by the validator nodes within that Subnet. This also decreases the resources validators need, as they do not validate transactions on other chains besides the Primary Network and the specific Subnets they are interested in. Subnets can also hold specific properties, allowing for considerable customizability, including making them private or requiring validators to be in a specific jurisdiction, just to name a few.

Interoperability

Unlike Polkadot and Cosmos, Subnet’s interoperability is based on only two components: Cross-chain Bridges and the recent Avalanche Warp Message (AWM) Communication Protocol.

Bridges

As Subnets are their own sovereign network, and they are responsible for establishing their own connections to other Subnets and the C-chain. This means Subnet projects are responsible for building their own bridge infrastructure or utilizing a 3rd party bridging solution.

However, Avalanche does provide some assistance by providing a tutorial demo on how to build a cross-chain EVM-EVM bridge4. Yet, this is only a demo for only EVM compatibility and is not intended for actual production use.

Up until recently, building or using a typical cross-chain bridge was the way to go. Projects have the option to use three types of mechanisms5:

• Lock and mint — A user locks tokens in a smart contract on chain A, then a wrapped version of that locked token is minted on the destination chain. In the reverse direction, the wrapped token on the destination chain is burned to unlock the original coins on the source chain.
• Burn and mint — A user burns tokens on the source chain, then the same native tokens are re-issued (minted) on the destination chain.
• Lock and unlock — A user locks tokens on the chain A, then unlocks the same native tokens from a liquidity pool on the destination chain. These types of cross-chain bridges usually attract liquidity on both sides of the bridge through economic incentives such as liquidity mining or revenue sharing.

In addition, Subnet projects have the option to either build their own automated-market maker (AMM) or leverage an existing DEX with an already built liquidity pool.

Projects that are connected with other blockchains, but vary in terms of token type and architecture may even have to use more than one bridge. The Swimmer Network for example uses its own native bridge for its NFTs, but has partnered up and is leveraging LayerZero’s and cBridge’s bridging services for its utility tokens6.

Speaking of LayerZero, this communication protocol has taken strides in expanding its service to the Subnet ecosystem7. As mentioned, it has already partnered with Swimmer Network and is looking for further integration.

Although projects building on a Subnet have multiple options to connect to other blockchains, having a native interoperable system for Subnet-Subnet communication has proven elusive. That is, until the arrival of the Avalanche Warp Message (AWM) Protocol.

Avalanche Warp Message (AWM) Protocol

Subnet-to-Subnet communication within Avalanche is a relatively latecomer when compared to other networks who already built an internal interoperable system. However, this has not hindered the growth of the Subnet ecosystem, which currently has six launched Subnet networks8, with dozens more being developed and tested on the Fuji Testnet9.

Then on December 22, 2022, Ava Labs announced the release of the first native Subnet-to-Subnet communication protocol called Avalanche Warp Message10. It is the fifth — and final — Banff upgrade and it allows two blockchains running on different Subnets to send/verify arbitrary messages to/from each other. A major component of AWM is that there are no additional or third party intermediaries between Subnet-to-Subnet communication, like those with cross-chain bridges that act as a third party intermediary.

Before we can discuss how AWM works, we need to first examine two components that play a crucial role in its function; Avalanche’s P-Chain and BLS Multi-Signature.

P-Chain

(Source: https://docs.avax.network/overview/getting-started/avalanche-platform#platform-chain-p-chain)

The Platform Chain or P-Chain is a metadata blockchain on Avalanche where coordination between validators takes place, enables the creation of Subnets and keeps track of them11. Crucially, it is also where the network’s Snowman consensus protocol is processed.

When it comes to messaging, the P-Chain is the heartbeat of AWM. Given its architecture, at any point in time it has records of all the stakes of all the Subnets and all BLS keys registered by any validator12. As such, a Subnet can know the validators of another Subnet in order to be able to authenticate the message that came directly from that Subnet. With no additional per-connection overhead, any Subnet can reach out or look at another Subnet’s database, ask the validator on that database to ‘ask’ or verify information such as the stake weight of a Subnet, who is participating in it, what BLS keys are registered with it, etc. That Subnet can then quickly and efficiently verify a BLS multi-signature that was signed by a certain percentage of stake (more on this later).

In a Twitter Space with Avalanche, the reason why they chose this approach was that, considering that Subnets allow a diverse array of customized virtual machines (VM) to be implemented, an ‘any-to-any’ messaging system became necessary13. Hence, it became critical that the ability for tracking and verifying messages from Subnets and their ability to transfer and validate information was decoupled in order to develop a high throughput messaging protocol.

BLS Multi-Signature

A BLS Signature is a cryptographic signature scheme that allows a user to verify if a signature is authentic14.

The idea behind a BLS Multi-Signature scheme is that it aggregates many BLS signatures into one transaction. To achieve this, one would need to shrink the size of a block by reducing the size of the signature and then compress multiple individual signatures into a single, shorter one, thereby giving more space for more transactions to be included in that block15. This is done by the system supporting a public key aggregation, where the verification algorithm only uses a short aggregated public key16. The original public keys are not needed for verifying the multi-signature. All of this makes the verification for the short multi-signatures not only very easy to use, but also scalable.

This was only one reason why Avalanche chose to integrate BLS multi-signature scheme into AWM. A second reason why it was chosen over other signature schemes such as the Threshold Signature Schemes (TSS) was because the BLS Multi-Signature scheme allows for validity to be determined by the stake weights from validators that participate in a Subnet17. If a Subnet chooses to process another Subnet’s message, it looks up both the BLS Public Keys and the stake weight from the P-Chain of validators from the original Subnet.

“Stake” refers to the Subnet’s own native token and not the amount of AVAX validators have staked on the P-Chain. “Weight” is the weight or how much of a Subnet’s native token has been staked by its validators.

A third benefit is attributable signing. This essentially allows a Subnet to require a specific set of participants to verify the validity of a message18. Other schemes such as TSS do not possess such a feature.

How Does it Work?

Thus far, AWM sounds complicated. However, the process is fairly simple and can be broken down into just 5 simple steps19.

(source: https://typefully.com/_patrickogrady/bo39clG)

Step 1

Any Avalanche validator that wishes to generate BLS signatures must first register their BLS Public Key and BLS Proof-of-Possession on the P-Chain when starting their staking period. This BLS key is recorded on the P-Chain database so that any VM can quickly query its value.

Next, validators must either create or join an already existing Subnet or Elastic Subnet. AWM can work on both types of Subnets.

Step 2

The VM running on the Subnet can at any time trigger the generation of a BLS signature over an arbitrary payload. It is up to the VM to determine both the fee on the blockchain for triggering a generation and for determining what to put in this payload.

Step 3

Once each validator has generated a BLS signature over the payload, any other Subnet wishing to broadcast the message to another Subnet can collect the validator signatures, form a BLS Multi-Signature and process it.

Bear in mind that AWM communications are not recorded on the Primary Network. The only way for someone to view communication between Subnets is to join either Subnet network with their own validator node.

Step 4

Should a Subnet choose to process another Subnet’s message, as stated previously, it will need to look up both the BLS Public Keys and stake weight of the original Subnet from the P-Chain. As there is no “per connection” overhead in order to maintain communication between Subnets, this is very practical.

Step 5

Each Subnet defines its own AWM security level. As such, it is up to each Subnet network to determine if it wants to accept messages from another Subnet and, if so, determine the threshold of a validator’s weight of stake in order for the message that it had signed to be considered valid and/or safe. For example, Subnet A accepts messages from Subnet B that are signed by at least 70% of stake but does not accept messages from Subnet C.

For a Subnet to broadcast data to any Subnet willing to listen, it sends an “Anycast Message”. This enables an “oracle” Subnet to emit a periodic heartbeat that can be utilized by any other Subnet without the need to send a direct message to every other Subnet.

It is up to the Subnet and their users to determine how they want to ferry data from source to destination and what sort of guarantees they want to provide around the transferring of data.

What results from this are resources being communally utilized, fostering strong cooperation between Subnets, thereby establishing strong, literal communications and bonds within the Subnet ecosystem.

At heart, AWM is a rather primitive way for Subnet networks to communicate with each other. However, this also makes it very flexible for developers to use it how they see fit. They get to determine what messages look like and how their VM will interact with those messages. You can even overlay messaging formats from other teams on top of AWM if they work with your VM.

At this point, one might begin to think that, with AWM, cross-chain bridges are no longer necessary. It is important to note that AWM is only a messaging protocol. That means it is solely responsible for validating and sending/receiving arbitrary message data (transfer info., contract data, price, etc.)20. It is not involved in the security of the message itself. That responsibility falls down to each Subnet to refine their own AWM security level. Secondly, it does not involve itself in the actual transfer of crypto, NFTs or any digital asset between Subnets. For this to happen, a cross-chain bridge would be needed because it either provides liquidity between single or paired tokens or routes the transaction to another protocol that provides liquidity between chains, such as two DEXs21.

Therefore, the AWM protocol does not necessarily replace cross-chain bridges, as much as complement it. Bridges are needed for the user-friendly interface and liquidity for the cross-chain transfer of tokens. The AWM is needed for its simplistic, and thus more secure, messaging system22. Thus the entire goal is to make the actual implementation of the bridge as simple and as easy to use as possible. Therefore, it is being recommended that bridges should be deployed using AWM to maintain full security.

Advantages and Disadvantages

To summarize, Avalanche’s Subnet interoperability system is composed by two parts:

1. Cross-chain Bridges — It is an infrastructure that enables data and tokens to be transferred from one blockchain network to another. Bridges have three types of mechanisms:

• Lock and mint
• Burn and mint
• Lock and unlock

2. Avalanche Warp Message (AWM) Protocol — It is Avalanche’s native Subnet-Subnet communication protocol. It is made up of two key parts:

• Platform Chain (P-Chain) — Avalanche’s metadata blockchain on Avalanche where validators can coordinate, Subnets are created and tracked and where the network’s Snowman consensus protocol is processed.
• BLS Multi-Signature — A cryptographic signature scheme that compiles multiple validator signatures into one transaction and allows other validators to verify if that signature is authentic.

For Subnets, building or relying on a 3rd party cross-chain bridge for interoperability is an immediate, albeit short-term and solely local solution. Firstly, not only is it expensive for a project, especially a start-up one, to build its own bridge infrastructure, it would divert much needed funds away from developing the project’s main product/service. Secondly, the subnet project would be solely responsible for the security of its bridge. Although partnering up with an already established bridge is more cost efficient, this is only possible if the project’s VM and architecture is compatible with the bridge, thereby making it dependent on a 3rd party for security. Given how unreliable bridges have demonstrated to be in 2022 alone, this can put a Subnet network at risk of loss in liquidity and user funds23.

Moreover, bridges have only managed to make EVM-compatible Subnets interoperable with Avalanche’s C-Chain or other EVM blockchain ecosystems such as Harmony. This renders Subnets with their own customized non-Ethereum VMs incompatible and thus isolated or were compelled to divert funds away to build their own bridge infrastructure. What we get as a result is an inefficient, costly, and largely disconnected Subnet ecosystem with incompatible bridges.

This is why cross-chain bridges on their own are a limited solution. What is needed is a basic communication protocol that can be agnostic and compatible regardless of the VM being used, or the architecture of a network. This is what AWM provides for bridges and for the Subnet ecosystem as a whole. Moreover, it can be easily implemented and customized on a bridge, whether that be a 3rd party or a project’s own natively built bridge.

As stated previously, AWM and cross-chain bridges can complement each other. AWM provides the communication infrastructure or gateway from which data and messaging can take place between Subnets with diverse VMs. A bridge in turn provides the liquidity needed for the actual transfer of tokens to take place, not to mention it can provide its own security mechanism, which can further strengthen the ecosystem’s interoperability.

But the AWM and bridges are not the only ones that can add security value. Subnets will also be responsible for coming up with their own AWM security level, via determining the threshold of a validator’s weight of stake. So then combining all of this together, the AWM-bridge union can potentially provide Subnet-Subnet interoperability with three layers of security.

When it comes to supported tokens, since bridges usually support both native and wrapped versions, that means that Subnets should be able to also support both types.

Having said this, AWM does have a few limitations. Firstly, AMW only supports the Goland and Rust VM SDK. It is currently unavailable for EVM-Subnets, although it is expected that it will support it in the coming weeks. This unavailability extends to the C-Chain as well. Secondly, having only just come out and despite rigorous testing, its practical usage is somewhat vague with any potential security issues/vulnerability being unknown.

Subnets vs Zones vs Parachains

Now that we have examined all three ecosystem’s interoperability systems, how does the interoperability of Subnets compare with those of Zones and Parachains?

Let us start with security. As mentioned, the Cosmos Hub uses the Tendermint consensus mechanism for its security. However, other Hubs and Zones in the ecosystem do not depend on it for their own security. Every Zone and Hub has their own validator set and different trust assumptions. This thereby not only mitigates any security issues that could affect the whole ecosystem, but also doesn’t limit its expansion. To strengthen this, Cosmos will be launching its Interchain Security, where projects on their own Appchain have the option to leverage Cosmos’ own security Hub by leasing its validators to validate and secure their own network. This way, projects with less capital and resources will not have to spin up their own validator set and Cosmos’ Hub validators and delegators can earn additional rewards in the form of that chain’s native governance token.

Alternatively, for Polkadot, shared Security is mandatory. Polkadot uses a shared state infrastructure between the Relay Chain and all of the connected parachains. Every Parachain makes the same trust assumptions, and as such the Relay Chain validates state transition and enables seamless interoperability between them. In return, projects wanting to build on top of a Parachain have to purchase DOT, and win an auction for one of the available parachain slots.

However, Parachains don’t just rely on the Relay Chain for their security. Parachains must also implement censorship resistance measures and utilize some type of consensus mechanism (PoW/PoS) for each Parachain. Hence, they cannot simply rely on the security of the Relay Chain. While these requirements enhance the security of the protocol, they can also be technically and financially expensive, requiring expertise and capital to implement correctly. This can therefore be quite prohibitive to smaller, less well-funded organizations, individuals, or entrepreneurs. Despite this, this does not make Parachains’ security fully independent.

Subnets on the other hand can validate a single or many blockchains within a single validator set. To secure their network on a Subnet, projects must be able to incentivize Avalanche’s validators through a reward system (e.g. robust tokenomics, gas fees paid to validators, help validators validate more blocks by delegating AVAX to them). Moreover, only validators who staked AVAX on Avalanche’s Primary Network can participate in securing a subnet’s network, ensuring the simultaneous shared safety of the whole network as well as individual subnets in which the validator participates. However, that being said, a Subnet’s security is not dependent on the Primary Network’s security. Subnets are completely sovereign networks, with their own consensus mechanism and validating transactions outside of the Primary Network. This is great because it means subnets do not have to depend on Avalanche’s own consensus for security. It gives sovereign security to each Subnet. This is on par with Cosmos’ Zones, but projects on Parachains do not have that option and rely on the Relay Chain to enforce validities. Additionally, although Cosmos is building their Interchain Security, it only pre-released its version 1 which is not yet available for full adoption.

When it comes to ‘implementation ease’ there are a few distinctions. For starters, Polkadot’s Parachain-Parachain communication involves several components to coordinate, namely between the XCM, XCMP, XCVM and the type of bridge method (Pallet, smart contracts & Higher-order protocols), with the possibility of the Relay Chain being involved (UMP/DMP). By contrast, Avalanche’s subnet-subnet communication only involves the coordination between the AWM, a cross-chain bridge and the P-Chain, whilst still offering much of the same security, benefits and features.

From this perspective, Avalanche’s interoperability system is simpler to implement given that it involves less components to integrate and coordinate. The AWM itself only requires just an array of bytes, an index of who participated in the BLS Multi-Signature, and the BLS Multi-Signature to get it set up. This is crucial because there are no limits to how many Subnet networks can be launched, in contrast to Polkadot who can only support a maximum of 200 Parachains.

The case is somewhat similar when comparing it with Cosmos’s Zones. When it comes to the guarantee of security, both IBC and AWM are very much similar24. However, because there is no ‘P-Chain’ on Cosmos, validators have to spend more time verifying and updating headers of other validators. With AWM, it sets up a ‘global ledger’ for everyone, so instead of verifying headers of every chain, you can just keep track of them on the P-Chain, thus keeping up to date on all the validator sets and using that information to then communicate. Basically, the P-Chain on Avalanche just makes the communication process more efficient.

The AWM’s other distinct advantage is that it does not discriminate between native and wrapped tokens. By comparison, Cosmos’ IBC is only able to send out to the destination chain wrapped/synthetic versions of the original tokens. With XCM, only between Substrate-based Parachains can the transfer of token assets be done natively. Wrapped tokens need to be used between Substrate-based and non-Substrate back blockchains. However, the decision whether or not to be able to send tokens native or as wrapped seems to fall within the cross-chain bridge and a subnet’s capacity and willingness.

Now despite this, given that Polkadot’s and Cosmos’ XCM and IBC respectively have been out for some time, they are well ahead in development and integration. IBC for example, after some prior development, can be adopted by chains that were not built with the Cosmos SDK, nor even use Tendermint as their consensus mechanism25. As previously mentioned, the AWM protocol does not even support subnet-C-Chain communication, let alone whether it can be adopted by other non-subnet blockchains.

Another difference lies in the area of strict guarantees. AWM implementation is on a lower level compared to IBC. Meaning that IBC enforces stricter guarantees with regards to how messages between chains are processed. With AWM it is less strict and as mentioned before, it is up to each Subnet to introduce different rules on how strict they want to be with messages. In other words, there is a certain enforced level of strict guarantee of cross-chain communication that all Zones, by default, have to abide by when using IBC. However, such a standard is non-existent with AWM, but distributed to each Subnet to enforce its own level of guarantee security.

Depending on one’s perspective, AWM can be seen as more flexible. On the other hand, IBC provides an already built-in security guarantee standard. This means less time and work is needed when integrating IBC than with AWM. Developers on a Subnet will not only need to calculate their network’s own security threshold, but must ensure the security threshold is sufficient. However, this also provides subnet developers, much like with XCM, the flexibility to implement stricter security guarantees than what IBC can provide. But again on the other hand, having different security levels can potentially impede interoperability between Subnets, as this can isolate certain Subnets who for one reason or another, have cross-chain communication security threshold that is not up to par for other Subnets to accept.

Another area of potential disadvantage for Subnets lies in Zones and Parachains having the ability to have an account on a remote chain, allowing the original chain to have an address on the remote chain for receiving funds and to eventually transfer those funds it controls into other accounts in that same remote chain. It is not yet known whether AWM can also provide this same service.

Overall, while there are differences, each of the three interoperability systems has unique features and advantages. It all comes down to a project’s needs, requirements and priorities. Nevertheless, from what has been gathered in this analysis, the only true advantage Polkadot’s and Cosmos’ interoperability had over Avalanche was that the latter had no communication protocol for its Subnets to communicate. However, the AWM communication protocol launch has almost closed that disadvantage. Yes, the XCM and IBC systems are more mature and further developed than AWM, but Avalanche has consistently proven, especially during its Banff upgrades, not only its resilience but its ability to produce top-quality products and services for its growing ecosystem. The proof can be seen in the growth the Subnet ecosystem had experienced prior to the launch of AWM. Now with a native communication protocol at the helm, Parachains and Zones will have their work cut out for them.

Work Cited for Parachains

1. https://medium.com/avalanche-hub/comparison-between-avalanche-cosmos-and-polkadot-a2a98f46c03b
2. https://wiki.polkadot.network/docs/learn-parachains
3. https://wiki.polkadot.network/docs/learn-xcm
4. https://github.com/paritytech/xcm-format
5. https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves
6. https://polkadot.network/blog/polkadot-roadmap-roundup/
7. https://github.com/paritytech/xcm-format
8. https://wiki.polkadot.network/docs/learn-xcm
9. https://wiki.polkadot.network/docs/learn-bridges
10. https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves
11. https://wiki.polkadot.network/docs/learn-bridges
12. https://eprint.iacr.org/2018/643.pdf
13. https://wiki.polkadot.network/docs/learn-xcm
14. https://github.com/paritytech/xcm-format
15. https://docs.moonbeam.network/learn/features/unified-accounts/
16. https://polkadot.network/blog/xcm-the-cross-consensus-message-format/#-reserves
17. https://forum.polkadot.network/t/decentralized-dot-eth-bridges-a-comparison-thread/777/5
18. https://link.springer.com/article/10.1007/s00145-004-0314-9
19. https://wiki.polkadot.network/docs/learn-cryptography#are-bls-signatures-used-in-polkadot
20. https://polkadot.network/blog/polkadot-2022-roundup/

Work Cited for Zones

1. https://v1.cosmos.network/intro
2. https://www.kraken.com/en-gb/learn/what-is-cosmos-atom
3. https://cosmos.network/learn/faq/what-is-the-cosmos-hub
4. https://v1.cosmos.network/intro
5. https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html
6. https://v1.cosmos.network/intro
7. https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html
8. https://v1.cosmos.network/intro
9. https://tutorials.cosmos.network/academy/2-cosmos-concepts/5-modules.html
10. https://docs.cosmos.network/main/intro/why-app-specific
11. https://informal.systems/blog/interchain-security-pre-release
12. https://tutorials.cosmos.network/academy/3-ibc/6-ica.html
13. https://tutorials.cosmos.network/academy/2-cosmos-concepts/1-architecture.html#application-blockchain-interface-abci
14. https://docs.cosmos.network/main/intro/sdk-app-architecture#abci
15. https://www.paradigm.xyz/2022/07/experiment-narwhal-bullshark-cosmos-stack

Work Cited for Subnets

1. https://docs.avax.network/intro
2. https://docs.avax.network/Subnets
3. https://docs.avax.network/Subnets/deploying-cross-chain-evm-bridge
4. https://blog.chain.link/cross-chain-bridge/
5. https://docs.swimmer.network/user-docs/bridging-details
6. https://www.youtube.com/watch?v=0xdp2CWEzZk
7. https://avascan.info/blockchains
8. https://testnet.avascan.info/blockchains
9. https://medium.com/avalancheavax/avalanche-warp-messaging-awm-launches-with-the-first-native-Subnet-to-Subnet-message-on-avalanche-c0ceec32144a
10. https://docs.avax.network/overview/getting-started/avalanche-platform#platform-chain-p-chain
11. https://twitter.com/i/spaces/1djxXlkVWEoxZ
12. https://link.springer.com/article/10.1007/s00145-004-0314-9
13. https://www.unitychain.io/blog/scalability-magic-bls-signatures
14. https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html
15. https://medium.com/avalancheavax/avalanche-warp-messaging-awm-launches-with-the-first-native-Subnet-to-Subnet-message-on-avalanche-c0ceec32144a
16. https://twitter.com/_patrickogrady/status/1606395090582114304
17. https://twitter.com/_patrickogrady/status/1605989133091905536
18. https://www.youtube.com/watch?v=LUAFkRxMA8E
19. https://blog.chain.link/cross-chain-bridge/
20. https://www.youtube.com/watch?v=LUAFkRxMA8E
21. https://worldcoin.org/articles/crypto-bridge-hacks
22. https://www.youtube.com/watch?v=LUAFkRxMA8E
23. https://tutorials.cosmos.network/academy/3-ibc/1-what-is-ibc.html#internet-of-blockchains

Other notes:

https://www.youtube.com/watch?v=LUAFkRxMA8E

Space about IBC and AWM — by landslide

https://twitter.com/CosmosAVAX/status/1611451678708097024