This is the workshop held during the Avalanche Summit on March 22nd, 2022.
Hello everyone. I’m really happy and excited to be here today: I feel we’re all together at the verge of the latest trends in technology. Avalanche is poised to be the winner-takes-it-all in the crypto economy. We’re here to stay. Some of you may know me, some may not, but they most likely know the project I work on, Avascan.
2022 is the year of subnets for Avalanche and, in my opinion, the ecosystem will grow insanely. We at Avascan are ready. It all starts with understanding what a subnet is, and how it relates with Avalanche.
As you can see in this image, and as you surely know, there’s Mainnet, which everyone’s using, and Testnet, also called Fuji, used by developers to test their applications. They’re called Networks. Inside every network, many Subnets can exist: the first and most important one is the Primary Network, previously called Default Subnet. Each subnet is basically a committee, composed of validators that validate the transactions of the blockchains in that subnet. Each validator can validate one or more subnets, but it must validate the Primary Network by default. So, the Primary Network is the biggest and most decentralized subnet, and it validates three chains: P-Chain, X-Chain and C-Chain. If you came to Avalanche during DeFi season (namely, Avalanche Rush), you most probably only interacted with C-Chain, while if you bought AVAX from ICO or used it from the beginning, you most likely have interacted with all 3 chains at some point.
The Subnets Economy
Subnet Economy: an economic system in which value moves from one jurisdiction (i.e. subnet) to another, with high interoperability, in the same distributed network.
Each blockchain, then, is the combination of 3 modules that can vary greatly: for one, a blockchain needs to be validated by a Subnet, but a subnet can have one validator or a thousand.
Second is the Genesis Block, which is the coinbase at launch and some minting parameters.
Then, there’s the Virtual Machine, the operative code of the blockchain, powered by a consensus engine (currently only Snowman++ and Avalanche). There are many VMs currently running on Avalanche: platformvm, avm, evm, timestampvm, and that’s only just the beginning. VMs are heterogeneous.
This is a challenge for explorers like us. Showing correctly what’s an “address”, for example, is very hard when each VM could have its own implementation of “address”.
The key word here is Heterogeneity. Networks contain subnets that can have different rules, which validate blockchains that have many differences from one another.
These are a few of the thousands of emails that we received in the past 12 months on our feedback email address.
It generally involves a user sending a token from a centralized exchange to his wallet, and then finding out that the token he’s sent it’s actually the wrong one. This is the aim of our work: to simplify the complexity to new-comers. It all starts with understanding what an address is on Avalanche: for starters, even the term address is ambiguous. With address, we’re trying to define a concept that actually means different things based on the context. Like I said, since Avalanche is agnostic by design, a developer can deploy a blockchain with a Virtual Machine with its own transaction model. For example, platform VM, the VM behind P-Chain, has a UTXO model in a chain of blocks. Avalanche VM, the VM behind X-Chain, has a UTXO model in a DAG (Direct Acyclic Graph), while EVM, the VM behind C-Chain, has an accounting model.
In the UTXO model an address can also be called an “owner”,
while in the accounting model it can be called an “account”. While we can generally refer to them as addresses, they’re in fact different in nature.
The map you see right now is a simplified version of our research work in understanding how addresses work and how they relate to each other. I will not dive into the specifics of each one of these entities because that’s not the focus of this talk, but we can briefly pass on the most relevant ones: for example, an address on P-Chain (that is, an owner), can belong to the Genesis Set, which is what we call the subset of addresses that was included in the genesis block, hence received AVAX at mainnet launch, either vested and unlocked. But an address can also represent the treasury of a DApp, or a Centralized Exchange Wallet. On C-Chain (EVM), addresses (specifically known as Accounts) can be smart contracts, and the difference is that smart contracts can run custom code, while addresses (I mean, accounts) do not. There are a lot of different types of smart contracts, mostly based on development standards in the crypto community: one is the NFT Collection, based on the ERC-721 standard, that represents a set of NFTs; another one is the Router contract, that ensures DEX swaps happen in the most efficient way; and so on. And of course, the most important one is the Token, based on the ERC-20 standard. Note that even the complete version of this map is not complete: it’s just what we can say for sure that’s recurring in DApps or entities that operate on the blockchain. We hope this could be just the beginning of a major, ecosystem-wide effort to make a sense of all of this for the next generation of users coming into the industry. The concept of token is the check-point of our brief journey. From here, we will dive into the different natures of a token, and how you can distinguish them. I’ll go into detail using a sample token to make things easier to understand.
Let’s take AVAX. We all know it, and it fits really well in most of the concepts. We’ll follow AVAX’s path as we virtually move it across subnets, to learn how it changes and what it is when it comes back to its native place.
AVAX is minted on P-Chain, in the Primary Network. That means you only need to trust that its deployer, Ava Labs, has done a good job in building it in the right way. Here, you only need to trust the protocol itself and the team, community or individual that has developed it. There’s a direct connection between you and who actually developed the token.
Let’s take AVAX and transfer it, with the help of the Avalanche wallet, on X-Chain. Most of the users that bought AVAX in ICO got it on P-Chain, and then transferred it on X-Chain to spend it or move it to an exchange to sell it. This is a pretty standard procedure.
Now, let’s take AVAX and transfer it from X-Chain to C-Chain, the busiest blockchain on Avalanche.
When we transfer AVAX to C-Chain, it’s a slightly different token because it’s not on X-Chain anymore. For example, Binance accepts AVAX deposits both from X-Chain and C-Chain. But it can change even more by wrapping it. Before interacting with smart contracts, AVAX must be wrapped in a special contract to fit it in the ERC-20 standard.
This wrapped token is called Wrapped AVAX. A wrapped token is manipulated by a smart contract to adapt it to another standard. There’s software involved that changes the structure of the token, and it also changes its symbol! And, since AVAX is liquid on centralized exchanges and WAVAX is liquid on decentralized exchanges, it could even have a little difference in price!
Now let’s say a new subnet, called BarNet is offering huge incentives to move the tokens in its FooChain, in terms of reward boost or free tokens (this will be happening with the Avalanche Multiverse Incentive Program). You will want to move your WAVAX there, and you can do it with a bridge.
A popular EVM bridge is ChainBridge: it can connect EVM chains across different subnets, or across different networks. Bridges can be inter-network (such as the Avalanche bridge) or intra-network (such as bridges connecting different subnets). The two methods are different in nature, because with the first method you’re going outside the network, while with the second one you’re still inside Avalanche. When a token lands on a new subnet, transactions will be validated by a subset of validators, so take that into account. As for changes to its structure, we don’t know cross-subnet DEXs yet, so the token price and liquidity may change from the one in the Primary Network.
Here’s a table to recap all of this.
So, we had AVAX on P-Chain. Then we transferred it on X-Chain, and on C-Chain, and there’s no change in symbol, price or even liquidity. Since the token is one the same subnet, the trust model doesn’t change.
And then on C-Chain we wrapped it into WAVAX. The symbol changes,liquidity is changing because it’s provided on different markets, and price may therefore change slightly.
Then we bridged WAVAX onto another chain, on a different subnet, and that changes a lot: the symbol should change to distinguish it, price and liquidity will change because it’s traded on different markets, and the trust model changes greatly: you now need to trust the bridge manager and the subnet validators. A lot, huh? But to make things even more difficult, let’s take another example really quickly, that should not happen, and please don’t let this happen.
So let’s take WOLFIE, the Avalanche meme.
Let’s imagine we use a sample WOLFIE Native Token that we deployed on X-Chain.
We would then transfer it to C-Chain so that users can swap it on, say, Trader Joe.
But then, let’s say we make an agreement with a DEX on another chain called DexChain in the DexNet subnet to boost farm rewards for WOLFIE holders: users would need to bridge their WOLFIE there.
When the farm rewards end, we make a deal with another subnet team, HodlChain, in the HodlNet, and boost incentives based on which chain you’re coming from: if you come from DexChain, you have 10x boost, while if you come from C-Chain, you only have 2x boost. Users are incentivized to bridge from DexChain, not from C-Chain. We could know which chain users are coming from because each version of the token could have a different letter appended to it.
Then let’s say Trader Joe offers a 20x boost on farm rewards, but only to those coming from HodlChain. WOLFIE would now go back to C-Chain, but it has a very different nature, and likely a different symbol as well. Liquidity is fragmented, and price may be slightly to largely different, based on liquidity and volumes of the different subnets.
We hope this journey has made clear that there’s high fragmentation o here, and to solve this, we’re working on a solution on our own.
What We Do At Avascan
Our Mission: become the first interface to all-things Avalanche for users, analysts and developers
This research is a direct consequence of our process that starts back in the avalanchego or coreth node, where we analyze all the data we can get from Avalanche blockchains, and we try to squeeze as much data as possible. Once we study this data and learn how to get them from the network, we need to save them as data structures in our databases. We ask ourselves: “_Since this is the data we have, what can we do with it? How are these different data structures related? Is this data influencing other structures that we already have?_” And so on.
When we solve this, we can start designing new features and pages. This is hard. We don’t want to think about what others are doing, nor do we want to overthink it too much: we design and implement continuously in our staging environment, iterating different designs and evolving over time. When we think the page or feature is simple enough to be shown, we release it. We also iterate after the release. This process can take from weeks to several months, and it’s our core work. And this process has also been tweaked over time, as we grew from 7 staff members in August 2021 to 15 now, and aiming for about 30 by end of year. We want to become the first interface to all-things Avalanche for users, analysts and developers.
The Avascan Way
How do we do this? We started with X-Chain when Avalanche launched. As a DAG with a UTXO transaction model, we needed to represent transactions and tokens using a mix of views from bitcoin and DAG (like IOTA) explorers. Transactions are the core concept, and they’re organized in vertices. But there’s also a special type of transaction: the import/export, that directly connects with P-Chain or C-Chain.
With C-Chain, the busiest blockchain on Avalanche to date, we really needed to understand how it would add up to the overall architecture and manage the heterogeneity of the different types of account addresses.That’s why we released a version that was very similar to the one in X-Chain, though with some adjustments that take into account the different transaction model: FROM and TO, instead of INPUTS/OUTPUTS. This is important for us because we want users to have an integrated experience when they can browse through chains following import and export transactions. Once we had both X-Chain and C-Chain indexing running, Ava Labs released a new update to the avalanchego node to allow transferring tokens deployed on X-Chain to C-Chain. That was the first time we seriously thought about tokens at a different level. Heterogeneous VMs can encode tokens. VMs can be powered by different consensus protocols, based on different data structures (ie. chains of blocks, DAGs…). Blockchains are validated by subnets, and subnets are like jurisdictions that can have different rules, similar to different countries. So we thought: “_Why don’t we aggregate tokens from different chains?_”.
And that’s why we’re building the Market Cap page, now in beta. We will evolve this page to show tokens aggregated by subnets, but we already do it for the Primary Network! P-Chain is the platform chain, the last chain to complete the indexing of the Primary Network, and it has specific types of transactions, that are like operations: they have effects on the entire network. For example, when a subnet adds a new validator, that operation is executed on P-Chain. There needs to be an integrated view that lets users understand what’s the relation between every piece of the puzzle.
I can announce that we’re almost ready to release P-Chain indexing Phase 1, with Transactions and Blocks List, as well as a v1 of its Owner Details page. Here’s a sneak peek. When we began working on P-Chain, we wanted users to understand different chains, and to switch between them seamlessly.
That’s why we decided to evolve the actual Address Details page to be modular and fit different definitions of address.
The page will be contextual: if an address is actually a token contract, we will display specific data about it, along with details about other chains if it’s briged on other chains or even subnets. We will aggregate the different liquidities and show the price based on a formula that takes into account its different natures across the network.
Supporting The Subnets Economy
Our future as a multi-subnet explorer perfectly fits with our mission to become the first interface for Avalanche users. We are already discussing with the first few subnet deployers to release a first version of their subnet integration. We expect many more to come in the coming weeks. 2022 could also be the year of our own token, SCAN. Here’s a hint: I believe SCAN could be widely used by subnet teams: if you’re one, you can get in touch. But if you’re investors and want to get first in line in the SCAN fundraising to support our growth, you can join the Wolves of AVAX investor collective. If you’re a whale or are going to fundraise I’ll be happy to introduce you to it.
This workshop has been a fantastic occasion for Avascan to showcase our research work and a peek at our future plans.