Go to https://core.app/stake/ and connect your wallet by clicking on Access Wallet
Go to https://core.app/stake/ and connect your wallet by clicking on Access Wallet
Go to Earn the tab and click on Delegate. Search for Chorus One's nodes as listed here
Using Cross Chain Transfer tab move tokens to the P-chain
Select the end date for your stake and the amount for staking, and click on Confirm
Snowman is a blockchain-optimized consensus protocol–high-throughput, totally ordered, and great for smart contracts. The Snowman is a totally ordered implementation of the Avalanche consensus protocol. Both the Platform Chain (P-Chain) and the Contract Chain (C-Chain) implement the Snowman consensus protocol.
Avalanche is the fastest smart contracts platform in the world. Its revolutionary consensus protocol and novel Subnets enable Web3 developers to easily launch highly-scalable solutions.
Although the team at Ava Labs is working on building Avalanche, the project is open-source, and we hope to work closely with contributors from across the globe to build the underlying infrastructure and decentralized applications on top of the platform.
Contract Chain (C-Chain)
The C stands for contract, and this is the chain that's used for smart contracts and
Defi apps. The key difference with the other chains is that the c-chain uses an Ethereum-style address with 0x at the beginning, which can be added to your MetaMask.
Most Avalanche Defi platforms such as AAVE, Trader Joe, and Benqi work on the C-chain and are compatible with Metamask.
Exchange Chain (X-Chain)
The X-chain is used for sending and receiving funds, however, it is not used for Defi platforms. Also, note that x-chain cannot be used with MetaMask or similar wallets. Your X-chain address is accessed from the Avalanche web wallet, and you get a new address after every deposit (note that your old addresses remain valid too). The format is different from Ethereum-style 0x addresses and begins with an "X-avax".
Avalanche's X-Chain is a DAG. Avalanche's X-Chain's main function is transferring AVAX, it requires DAG technology to enable its ultra-high TPS and rapid finality. It allows anyone exchanging tokens to do so in a lightning-fast way with exceedingly low fees of 0.001 AVAX compared to other layer 1 blockchains.
Platform Chain (P-Chain)
The final chain that Avalanche offers is the p-chain (for the platform). The P-chain's function allows you to stake AVAX and serve as a validator. If you are a validator or delegating to a validator, then your AVAX rewards will be received on this chain. Note that these also differ from Ethereum-style 0x addresses and begin with a "P-avax".
Note that when using these addresses, it is best practice to follow case sensitivity.
Refer to this page - https://support.avax.network/en/collections/3433652-new-to-avalanche-quick-start-guide
We are thrilled to introduce our latest product, Chorus One SDK. This advanced toolkit is set to transform how our customers integrate staking functionalities into their applications. As the leading staking provider with the most extensive network support in the industry, robust security features, and comprehensive transaction management, our SDK (Software Development Kit) is poised to become an essential tool for institutions and developers, enabling them to leverage enterprise-grade staking solutions across all major networks including Ethereum, Solana, TON, Avalanche, Cosmos, NEAR, and Polkadot with unparalleled ease and efficiency.
The Chorus One SDK is an all-in-one toolkit for building staking dApps or implementing programmatic native staking into your product. It supports non-custodial staking on various networks validated by Chorus One. With this SDK, our customers can build, sign, and broadcast transactions, as well as retrieve staking information and rewards for user accounts.
Chorus One has the most extensive network support for staking in the industry. Currently, the Chorus One SDK provides support for the following networks, with plans to expand to even more in the future:
The Chorus One SDK is designed for a diverse audience, including:
By using the Chorus One SDK, our customers can easily integrate programmatic native staking, access detailed staking position data, and minting of osETH LST to offer flexible staking options to their end users.
At Chorus One, we prioritize security, transparency, and user control. Our decision to develop an SDK over a traditional API was driven by the following considerations:
Enhanced Security
Verifiable Trust and Transparency
Open-Source and Auditable
💡 Why does it matter?
Choosing the Chorus One SDK means prioritizing security, transparency, and user empowerment. With local transaction building and signing, and open-source transparency, users can confidently participate in staking activities across supported networks.
Our SDK offers a robust suite of tools for managing staking operations on various networks. Here’s a high-level overview of its functionality:
Comprehensive Transaction Management
Detailed Information Retrieval
Integrated Validator Support
Command Line Interface (CLI)
For more detailed information on how our SDK works and technical guides, explore the following resources:
The launch of Chorus One SDK marks our commitment to simplifying staking. By equipping our customers with all the necessary tools, we enable them to effortlessly integrate and deliver an exceptional staking experience to their end users.
If you’re an institution, wallet provider, asset manager, or developer looking to integrate staking into your product or would like to learn more, reach out to us at staking@chorus.one.
About Chorus One
Chorus One is one of the biggest institutional staking providers globally, operating infrastructure for 60+ Proof-of-Stake networks, including Ethereum, Cosmos, Solana, Avalanche, and Near, amongst others. Since 2018, we have been at the forefront of the PoS industry and now offer easy enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge protocols through Chorus Ventures. We are a team of over 50 passionate individuals spread throughout the globe who believe in the transformative power of blockchain technology.
The Avalanche Foundation has unveiled ACP-77, a transformative proposal set to redefine Subnet creation and operation within the Avalanche blockchain ecosystem. This ambitious initiative aims to lower entry barriers, enhance flexibility, and foster a more decentralized and dynamic network environment. Here, we delve into the intricacies of ACP-77, exploring its current context, proposed changes, benefits, and potential challenges.
-> Please note, ACP-77 proposes renaming 'Subnets' to 'Avalanche L1s (Layer 1s)'. If the proposal passes, they will henceforth be known as Avalanche L1s.
Subnets and their role: In the Avalanche ecosystem, subnets function as independent blockchains that leverage the mainnet for interoperability. However, the existing requirements for Subnet validation have created significant hurdles for developers.
The cost barrier: Currently, validators of Subnets must also validate the Avalanche mainnet, necessitating a minimum stake of 2,000 AVAX. At today's rates, this amounts to a substantial financial commitment, approximately $70,000. This high cost deters many developers that aim to jumpstart their Subnet by running their own validators, stifling innovation and limiting the expansion of the subnet ecosystem.
ACP-77 introduces a series of pivotal changes designed to overhaul the Subnet creation process, making it more accessible and efficient.
1. Decoupling Subnet and Mainnet validation:
2. Enhanced validator set management:
3. P-Chain fee mechanism:
4. Streamlined synchronization:
The proposed changes in ACP-77 bring several significant benefits to the Avalanche network and its developers.
1. Lower costs and increased accessibility:
2. Greater flexibility and autonomy:
3. Incentives for decentralization:
4. Enhanced security and interoperability:
While ACP-77 promises numerous benefits, it also introduces certain challenges that need to be addressed.
1. Economic implications:
2. Implementation complexity:
ACP-77 represents a bold and forward-thinking step in the evolution of the Avalanche network. By lowering financial barriers, enhancing flexibility, and promoting decentralization, this proposal has the potential to unlock unprecedented growth and innovation within the Subnet ecosystem. While challenges remain, the careful implementation of ACP-77 could pave the way for a more accessible, dynamic, and resilient Avalanche network, fostering a new era of blockchain development and collaboration.
About Chorus One
Chorus One is one of the biggest institutional staking providers globally, operating infrastructure for 60+ Proof-of-Stake networks, including Ethereum, Cosmos, Solana, Avalanche, and Near, amongst others. Since 2018, we have been at the forefront of the PoS industry and now offer easy enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge protocols through Chorus Ventures. We are a team of over 50 passionate individuals spread throughout the globe who believe in the transformative power of blockchain technology.
At Chorus One, we have a strong conviction in the potential of a multichain future. We believe that specialized blockchains play a crucial role in discovering and nurturing new use cases, and ultimately driving mainstream adoption. Since joining Chorus One about two years ago, I've been pushing for us to do the same in the Avalanche ecosystem as these two ecosystems have similar visions of what the multichain future can, should, and will look like.
Last year, we entered the Avalanche ecosystem. Our work will only intensify in the coming years with Chorus Ventures, our ventures arm, investing in native Avalanche projects. We also use our expertise in tokenomics and infrastructure to help projects launch their permissionless subnets. We will be presenting this topic both at the online Subnet Summit mid April and the Avalanche Summit II beginning of May.
In my view gaming is key to onboarding the next wave of users and a fundamental step in the road to mass adoption. This article aims to present the exciting future of blockchain gaming and demonstrate how the Avalanche architecture, particularly the multichain subnet architecture, is the ideal substrate for this vision. Through a two-part series, I will illustrate how one can develop an unstoppable game. By unstoppable, I mean a game that not even its creators can censor or stop if one day they move on to other projects. A game in control of its users.
So let's get to it.
To make this exercise as clear as possible I will look at a game I have plenty of experience with having played around 2000h. The game in question is Path of Exile, in my personal opinion the Diablo killer. This game needs no introductions but:
A short video:
Take a look here for some more gameplay videos.
I cannot emphasize enough how deep the economics goes in this game. The reason being that its economics are fundamentally tied to the crafting system for equipment and to the simple fact that you need to craft gear yourself or buy it from someone if you want to reach the endgame. Purely random drops cannot take you there.
Every season a "league patch" is released with new contents and the economy is reset. Characters and loot from previous seasons are still available to play in the "standard" league and the standard league economics are interesting in their own right but as a driver for innovation and to give new players the ability to compete in a more level playing field, these resets are very important.
The goal is thus to envision a version of PoE that is unstoppable and in the hands of gamers. You might ask: why would developers make such a game? To which I answer: the first one to do this becomes a first mover in a technology that soon will be expected from all games. And why will this be expected? Why do gamers want this? Well, this is a game you can continue playing and you can really own it. Like how it was in the dawn of console gaming. Be it real or game money, you can trade assets and no one can censor you. If you recall the anecdote, this was the reason Vitalik started his work in crypto.
In the centralized world, an ARPG like Path of Exile consists of a client/server platform where the server infrastructure is run by the game developer, and where the client freely available or purchased in a marketplace. Next, we will look at the features and responsibilities of the server side as this will be where our decentralization efforts will mostly focus.
The ability of client-side tampering with binary can cause all types of attacks/cheating. This is an arms race but currently, it is tackled via lock-step state validation. More on this later.
Most games need randomness. For anti-cheat reasons, this is taken care of at the server level. In the case of PoE (and ARPG more broadly) this is even more important as loot, damage, map layout, and even AI are parameterized by random inputs.
Of fundamental importance for a healthy in-game economy is that the more powerful items are, the rarer they should be. That is, their drop rate should be lower. This is accomplished by drop-rate lookup tables that are set and maintained by the server. Again due to anti-cheat measures, it is the server that, when appropriate, generates a random drop.
Even in PoE which tends to be dominated by PvE (player versus environment), there are situations where players interact: regions where PvP (player versus player) are allowed and sanctuary environments also called player hubs. These interactions need to be facilitated by the game server.
Special trading windows and functionalities are implemented so that players can exchange goods in a safe way.
Looking at the above set of functionalities that the server must provide, we can identify three different types of backends that the server infrastructure needs to maintain. These are the components we will need to "permissionlessly" decentralize. The following figure gives an idea of how the server-side interacts with these backends and the client (overlap indicates communication).
There is a need for queryable databases, with loot tables clearly being one such need. But many more are present: leaderboards, player info, skill table, effect mechanics, and many more.
A key-value store that can deliver monolithic "chunks of bytes" is also a necessary backend. The game needs to ship itself and its updates with a big proportion being graphical assets. For this dedicated content-delivery networks are employed.
As mentioned before the server infrastructure needs to be able to keep clients in sync across PvE and PvP both for anti-cheat purposes and for facilitation of user interactions.
So why is Avalanche especially suited for this exercise? How will the architecture of such a game change and what technologies do we need to leverage to accomplish our goal of a decentralized, unstoppable ARPG game?
Avalanche has two genius breakthroughs in its design: its consensus being the first and the subnet architecture being the second. The latter is highly dependent on the former. Let's see why.
Avalanche consensus is without a doubt the most advanced consensus out there and is correctly categorized as a third type of byzantine fault tolerant consensus following the discovery of signature accrual and Nakamoto consensus. It is the first meta-stable type of consensus algorithm. This consensus enjoys enviable properties: it scales easily with the number of validators, it is leaderless, and single-slot final. I won't go into much detail but suffices to say it accomplishes all of these by being a consensus algorithm based on a statement about an emergent property of the system. Let me explain what I mean. You can think of the network as having the property of being consistent (all validators agree on the current state). In Avalanche this property is emergent. Like the temperature of a gas, it exists as a property derived by the local interactions of its constituents “particles”. In the case of the gas, particles bouncing of each other exchanging kinetic energy in their small neighborhood gives rise to the macroscopic property of temperature. In Avalanche, validators are the particles and contrary to other consensus mechanisms they interact only “locally”, that is, with a small number of validators that are randomly selected in each round. Somehow - and here there is a strong mathematical theorem behind it - this is enough for the network to have a well-defined sense of state history. Even in the presence of attackers.
It is the property of essentially limitless scaling in the number of validators that allows for the second genius move. You see, Cosmos is the originator of the concept of an app-chain. In this design, it is absolutely necessary that chains can "talk" to each other to really cover all the use cases one is interested in. For this reason, they developed the IBC framework. This is an elegant framework for trustless communication but it incurs a significant requirement to a prospective chain: as a destination chain you need to keep consensus information of any given source chain you want to communicate with in the form of a light client. Wouldn't it be ideal if this information would be globally available to all chains from all chains? This is impossible with a limited set of validators.
So to have an unlimited set of app chains that can trustlessly communicate without having to keep light clients of every other chain they communicate with you need an unbounded set of validators in a global chain that keeps all this information. I hope you see where this is going: this is exactly the subnet design.
In Avalanche the main network that every validator must secure contains three chains. The P-chain (Platform chain), the X-chain (eXchange-chain) and the C-chain (Contract chain). The X-chain - which us currently a DAG but will become a linear chain in the near future - is a chain made for throughput exchanges of assets much like a blazing fast Bitcoin network. The C-chain is what most users are more familiar with and is an EVM based chain. It works just like Ethereum but faster and with instant finality. Great. But the real genius comes from the P-chain. This chain tracks all validation related transactions of the mainnet and all subnets. This is what will enable the unbounded, composable network of app chains. Since all validators have the P-chain at hand, any two subnets can communicate directly provided they want to. In IBC, on the other hand, with its hub-and-spoke design you have the unaddressed issue of path dependence.[^1]
So, we will leverage an Avalanche subnet for our game. Main reasons are the excellent scaling properties of its consensus and the application-specific, isolated nature of the subnet approach. On top of that it supports cross-subnet transactions allowing for valuable assets to move around freely in the ecosystem. Finally but not least, there is also VM2VM message passing that allows the validators in a subnet to easily check the state in other connected VMs be that within the same subnet, in the mainnet, or another subnet running in the same validator (the latter has not even been explored yet).
An Avalanche subnet is essentially the following:
The set of validators is dynamic but can be either permissionless or permissioned. The specification of a blockchain is comprised of a specification of a subnet this blockchain pertains to and the specification of a VM (i.e. virtual machine) that characterizes the valid state transitions in that blockchain.
Ava Labs recently announced HyperSDK a toolkit not much unlinke the CosmosSDK to help developers easily build VMs to power their subnet. From now on, they can focus on the logic of the application and worry much less about synchronization, consensus, state storage and availability and other blockchain-heavy topics. On the other hand, if you want to, you can customize these aspects as the SDK was build with modularity in mind.
See Avalanche platform and Subnets sections in the Avalanche documentation for more information on subnets and visit the HyperSDK repository which is open for contributions.
As mentioned before, our intent is to decentralize the game. For this, we will need to decentralize the server infrastructure, mainly the three points named above: databases, content delivery, and anti-cheat logic. This will be done by defining specialized VMs and the corresponding blockchains for each of those game infrastructures. All of this is packaged in the game server binaries which will be run by the validators in the subnet.
A game client will essentially be submitting transactions to the server network. Clearly, the game client is responsible for client-side rendering which is something we do not need to bother with on the server side. In terms of execution hardware, the game server is much lighter than the client and we will exploit this.
Keep in mind that being a player does not mean you can’t be a validator as well or a delegator to a Chorus One validator ;). This is obvious but worth mentioning as this means that for the first time ever a game can actually be in the hands of the players. With governance, even the game features and roadmap can be decided, paid for, and rolled out completely in a decentralized fashion.
So the big question: what are the blockchains, VMs and technologies used for this purpose? We dive in.
The BlobVM already exists in an advanced prototype stage. It was developed by Ava Labs and is available in open-source. What it does is provide a dedicated, seamlessly integrated (at the subnet level) content addressable storage with customizable parameters regarding permissions for read/write and persistence.
We use BlobVM for storing all art, texture, and models, i.e., all game assets. Even the game client binary can be updated via this method. In a fresh install, an externally downloaded game client connects, and sends a transaction to download all necessary assets. Note that this transaction could be a way to monetize the game but this is optional of course. In other words, this transaction would give you a game license NFT.
Now as mentioned before we want to give power and value to the gamers. Path of Exile is famous for its rich economy and is a formidable laboratory for NFT tokenomics. By giving the gamers the option to mint any found loot item we give this economy real value. There is plenty of opportunity and pitfalls here to fill in another article but it is important to mention that PoE works by having multiple “leagues” which give an opportunity to always “reset” the economy and give chance for new players to “make it”. We think this is an important aspect to keep in the decentralized version of this game. As an example of how we could explore this, we can configure it so that minted NFT only work on the current and previous leagues.
For tracking a gamer’s collection we use AVM, the Avalanche VM, which is a DAG (directed acyclic graph) based on the UTXO model capable of massive throughput. In fact, this is the underlying VM of the mainet’s X-chain. Note that since the announcement of Cortina (the next dot release of the Avalanche validator client) the X-chain will move from being a DAG into a linear chain. Here we have the option of launching out own AVM chain for assets transfer or, use the X-chain directly which would make all of the game’s NFT directly available to the wider Avalanche community (NFT reuse in games is an under-explored area). The AVM supports ANTs or Avalanche Native Tokens that can easily be imported/exported across the majority of supported VMs as it defines a unified API for cross-chain atomic swaps.
PoE is a free-to-play game that monetizes itself via cosmetic-only user-purchasable content. This can be easily supported via the AVM chain as well. Simply: an NFT in the user wallet ”unlocks” these assets to be delivered via the content delivery mechanism. This is essentially a VM2VM communication as is desirable and quite probable that the X-chain will support account lookups via this mechanism.
As mentioned before, as with any modern application, the game needs to store global relational data. For example, loot tables, league-specific information, game metrics, user metrics, NFT market data, etc. The list goes on and on. For this specific use case currently, many web3 projects use The Graph: a sophisticated but complex decentralized solution. A few issues arise with this approach:
Because of these, we propose a new type of VM we dub SQLVM and this will be the topic of our next article. But in a nutshell, you should think of it as a hybrid between a app-specific indexer and a persistent relational data store.
It allows for specific types of transactions that query/write to a globally replicated ACID relational database. Here we automatically benefit from the fact that blockchain transactions are atomic at the consensus level which makes designing the underlying database much simpler. For example, a suitable design can be done for a VM where the runtime state is an instance of any query engine: row-oriented like Postgres, column-oriented like BigTable, or document-based like MongoDB. Keep in mind that even this is overkill as we don't need their replication features. What we need is their query engine and storage solution. Most of these databases have sophisticated query planners than can take the place of fee estimators. The beauty here is that Avalanche will take care of maintaining this database eventually consistent which suffices for our use case. More sophisticated designs are certainly possible. The job of the VM here is to essentially declare the types of transactions (write/reads), the fees and verify the blocks by applying the transactions in the database and updating certain database hashes (will be needed for anti-cheat below). For our game - or any other app chain using this backend - other VMs in the subnet should be able to read the database at will which can easily be done with VM2VM.
Similar to how a non-validating Avalanche node have access to the mainnet state, a game client could be a node of this chain running in non-validation mode so as to keep this database state at all times for easy synchronicity.
Now to the technologically most innovative piece of the puzzle: to run anti-cheat as a ZK verifier. This is such a breakthrough technology that it would be an improvement over existing anti-cheat technology on centralized games.
Anti-cheat works, as mentioned before, as lock-step game simulation. What this means is that the game client is essentially an input system and a rendering engine of a game that is actually run remotely on servers. This Introduces latency which is the reason why game server farms have to be deployed across internet “regions”. ZK changes the game as it allows one to codify all game state transitions in a prover which we can run on the game client (remember the gamers tend to play with machines that are quite powerful) while the server is just a verifier! This has the added benefit that it even liberates the server from having to run in lock-step, to begin with! Essentially we can use eventual consistencyto catch the cheaters. Put differently, we don’t care to verify every little state transition that happened but batches (or recursions) encoding all transitions that happened in a configurable time window: 1 second, 10 seconds, a minute, an hour…
It is obvious what a powerful idea this is: no need to simulate full-blown games on the server. For example, we now can use more sophisticated AIs in the client. The fact that you have to run the game on the server is one of the reasons no modern AI is in use in games. Why not use GPT-4 for creating procedural quests??
We will have more to say about a ZKVM in a future article but I would like to state a few things. Firstly, note that we are not even using the zero-knowledge aspect of this VM and this gives more freedom in the exact construction of the protocol. In precise terms we are interested in SNARKS not necessarily ZK-SNARKS. Nonetheless, we expect that applications that use this zero-knowledge aspect will also exist.
Secondly, we might not be at the stage yet where fast enough provers exist to prove the state transition for a game like PoE. I'm not an expert, but I expect that schemes leveraging the GPUs in the gamer's clients will be just a matter of time.
And finally, we are talking about a very specific VM - that of the game - and not a generic programmable one like the EVM. We need a prover for those exact transitions that happen in game. This is potentially another route for optimization.
We hope to have convinced you that the future of decentralized gaming and player-owned gaming is bright. When Vitalik joined the crypto movement I don't think he thought his dream would come true on another chain, but I think he will be satisfied nonetheless.
But more importantly, we hope the reader is also convinced that this is only possible in a clean, elegant, and reusable way via the subnet architecture. Sophisticated applications like this will only flourish when good reusable VMs are available much like reusable contracts are right now. Multiple VMs demands multiple chains in a subnet architecture. Although technically possible to cram all of these backends into a single block to be serialized/deserialized and verified using a single chain, this would not only hurt code reuse but is also impractical since it is clear that these backends might need different blocktimes.
Of course, there are a lot of unknowns to this as I am not a game developer. I just want this to jump-start the imagination of developers in general (not only game developers) to the reality that the future is app-specific multi-chain subnets. And so that someone develops an unstoppable ARPG like Path of Exile!!
Tune in for some follow-up articles on where we attempt to detail somewhat the SQLVM and ZKVM and come talk to us in the summit. See you there!
Chorus One is one of the biggest institutional staking providers globally, running infrastructure and validating over 40 blockchain networks. Since 2018, we have been at the forefront of the PoS industry and now offer enterprise-grade staking solutions, industry-leading research, and also invest in some of the most cutting-edge projects through Chorus Ventures. We also invest in subnets on Avalanche so if you’re building something interesting, reach out to us at ventures@chorus.one.
Category | Details |
---|---|
Delegation Address | NodeID-LkDLSLrAW1E7Sga1zng17L1AqrtkyWTGg NodeID-4Ubqsj2vfwdGUUYNg1jtYpkYNNLugNBQ9 |
Wallet | https://wallet.avax.network/ |
APR | 9.2% |
Block Explorer | https://explorer.avax.network/ |
Staking Rewards | https://www.stakingrewards.com/earn/avalanche/ |
Unbonding Period | The minimum staking duration is two weeks. |
If you've spent some time reading how Avalanche works, you'd know that staking on Avalanche works a bit differently. First, you need an Avalanche Wallet. Create a new one or access your existing wallet here
Make sure you're on the right URL. Don't fall prey to phishing attacks by sites that look like the official wallet
Fastest Performing and Secure DeFi Wallet | Avalanche Wallet
Once you've accessed your wallet, you need some $AVAX! If you bought your AVAX on an exchange, you'll need to transfer it to the X-chain. Copy your X-chain address and use it to withdraw your AVAX from the exchange.
You should now have some AVAX on the X-chain. But staking works with the P-chain so you need to use the "Cross Chain" feature to move your AVAX from the X to the P-chain. You will need to pay a small amount of AVAX as fees so make sure you don't transfer the entire amount.
Once your AVAX is on the P-chain, it's time to stake! Click EARN on the left-hand side of the menu.
Since you want to delegate your AVAX, click on DELEGATE and then ADD DELEGATOR. Now you want to choose the Node you're delegating to. In order to delegate to the @ChorusOne node, copy one of the following two node-ids
NodeID-4Ubqsj2vfwdGUUYNg1jtYpkYNNLugNBQ9
NodeID-LkDLSLrAW1E7Sga1zng17L1AqrtkyWTGg
Go to Search Node ID and paste it there. Click Select. You're almost there!
Sometimes you might see the message that the Node is oversubscribed. Try using the other nodeID if you see this message. In case, you see this message for all the nodes, feel free to email at support@chorus.one
Select the end date for your stake, the amount for staking and click on Confirm. That's it. Congratulations. Your AVAX will now start earning rewards and you've just made the network more secure. If this AVAX staking guide helped you, share it with a friend!
The minimum staking duration is two weeks. A delegator will receive a higher percentage of rewards if they decide to stake for longer amounts (up to a year), thus incentivizing longer stake lengths.
Avalanche has a thriving, friendly, and engaging community. On top of that, it also has the quickest and most valuable bridge solution to and from Ethereum, with BTC onboarding shortly. Avalanche is fortunate to have a team that consistently produces and executes at the top level. It’s great for validators like us too. There’s no slashing and rewards are dependent only on uptime. Currently, the annual staking rewards are at 9.1%. This makes locking AVAX to stake appealing. The thriving ecosystem is already on display, with liquid-staking now accessible via BenQi (sAVAX, $179M in TVL) and two additional solutions on the way: LAVA and Eden Network + YieldYak. Lido is also building its liquid staking implementation for AVAX. A competitive DeFi landscape is also in operation, including TraderJoe (DEX, $179M in TVL), Platypus (stable swap, $155M in TVL), Aave (lending, $4.64Bn in TVL), and many more. Subnets now allow innovative technologies in both consensus and horizontal scalability architecture to join the network. To make the experience complete they even provide VMs as free open source code ready to be picked up by companies wishing to join the subnet movement.
Avalanche mainnet is made up of two blockchains (C-Chain and P-Chain) and one DAG (X-Chain for ultra-high TPS). These are two types of distributed ledger technologies (DLTs). The P-Chain is responsible not only for dealing with Subnet and all validator information but also to create new subnets and blockchains.
Although the term “subnet” is used interchangeably and synonymously with blockchains, subnets are a bit more complex than that. The technical definition of a subnet is as follows:
A Subnet is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains, according to Avalanche’s FAQ page.
Subnets allow anybody to quickly establish permissioned or permissionless networks with unique implementations that are powerful, dependable, and secure. Developers can use AvalancheGo or AvalancheJS, and Ethereum developers can seamlessly use Solidity to launch dApps as it is fully compatible. Avalanche includes features not seen on other chains, such as the ability to choose which validators secure their Subnet activity, which token is utilized for gas costs, bespoke economic models, and more. Subnets, crucially, stay naturally linked with the larger Avalanche ecosystem, do not compete for network resources with other projects, and are accessible in an infinite supply. With standard rules underlying all apps on a smart contract network, Web3 applications may distinguish on user experience like never before. A similar approach can be found in Cosmos with Saga and their “chainlets” approach and in Ethereum with Skale.
GameFi, a common phrase in the crypto-verse, is a combination of the words “Gaming” and “Finance.” It covers the gamification of the working system in order to generate profit via play-to-earn crypto games. In GameFi games, items are represented by NFTs. Users may boost their earning potential by levelling up and upgrading their characters, as well as participating in tournaments. As an example, players in Axie Infinity (arguably the biggest GameFi game in 2021) earned more than $1000 worth of $SPL a month before it suffered a hack. Many of these blockchain games are communities where players may earn tokens to swap for money. It’s remarkable to watch blockchain games with a few hundred players in 2013 turn into top-grossing games like Axie Infinity with hundreds of thousands of dollars in daily trade volume. And this is just the first generation of games on blockchains.
Adoption has skyrocketed over the past years. With a large number of retail investors as well as big companies like Microsoft, Nike, Meta and many more already involved, the metaverse market is expected to grow significantly. Major investors such as Gala Games and C2 Ventures formed a $100 million venture fund for GameFi. Solana Ventures and others also launched a $150 million fund by the end of 2021. More recently, Framework Ventures has allocated half of the $400M fund to Web3 gaming. As evidence of the blockchain gaming industry’s expansion, the blockchain games and infrastructure business attracted over $4 billion in venture capital financing in 2021 alone. Blockchain gaming has grown by 2,000 percent in a year, according to the conclusions of a joint report by DappRadar and the Blockchain Game Alliance (BGA). Although this was prior to the latest crypto meltdown. The scenario might be extremely different right now. However, the crypto gaming business has already received $2.5 billion in investment this year; if this trend continues, it might reach $10 billion by the end of 2022. The report also states that blockchain games drew $1.22 million in unique active wallets (UAW) in March, representing 52% of industry activity. With all of the various technologies collaborating to build a self-sustaining ecosystem, the blockchain gaming sector is poised to become a significant income source and probably the first real utility for blockchains outside payments.
The key advantage of using AVAX for GameFi is the three-pronged structure, which comprises validators and subnets using the P-Chain. Subnets let projects create their own application-specific blockchains (ASBs) that do not disrupt the rest of the chain. As a result, no single game utilizes the whole network bandwidth. GameFi on Avalanche offers the best chance for blockchain games to thrive in their intended setting. Avalanche is also great for creating NFTs, which makes digital assets like NFTs easily available for P2E games or the metaverse. Users can utilize Avalanche to establish their own localized chains that run independently of other chains, allowing them to sandbox their own knowledge and technology for the benefit of their own efforts. Most developers use their own token for gas on their subnet, however, a subsidised gas fee is also an option. Avalanche allows network developers to utilize whatever virtual machine they want or to create their own. You may use EVM or any other VM you like. Aside from the EVM and AvalancheVM, Avalanche now provides SpacesVM (key/value storage), BlobVM (binary storage), TimestampVM (a minimum viable VM), and others are in the works. Modularity rules the roost. Observing web2 games moving into web3 through subnets is a great place to start.
It is worth noting that Avalanche gaming developers are taking a Play-and-Earn method rather than a Play-to-Earn approach. This emphasizes the necessity for the game is enjoyable and long-lasting.
Overall, blockchain games continue to be one of the most appealing parts of the dApp market. Although demand for blockchain games looks to have peaked, gaming dApps continue to drive most of the industry’s on-chain activities. Notably, subnet games like Crabada and Defi Kingdoms are still drawing players even in a difficult 2022.
VCs and investors are pouring money into Web3 gaming ventures at an all-time high pace. Furthermore, financial firms like Morgan Stanley have assessed the metaverse’s economic potential to be at least an $8 trillion business. The Sandbox’s second Alpha season, Decentraland’s Fashion Week, and the overwhelming demand for NFT Worlds indicate a positive future for GameFi. However, security risks such as the Ronin bridge vulnerability and the difficulties of attaining full interoperability remind everyone interested that widespread adoption is not yet here. Avalanche Foundation believes that subnets like Shrapnel and TimeShuffle are the solution for the next generation of gaming, thus it launched Avalanche Multiverse last March, a $290 million incentive program to accelerate the growth of the new Internet of Subnets.
Avalanche is an open-source platform for deploying decentralised applications in a highly scalable environment. Avalanche takes a ‘network of networks’ approach to scaling and contains from the get-go a smart contracts platform designed for global finance, with near-instant finality. The network infrastructure allows applications to maintain sovereignty on their own “subnet”, while tapping into the Avalanche mainnet for interoperability with other subnets. Ethereum developers can easily build atop Avalanche via the EVM-compatible C-Chain. Through its novel Avalanche Consensus Protocol, Avalanche is able to scale capabilities to a processing capacity of 1,500 TPS (transactions per second) in the C-chain and upwards of 4500 TPS in the X-chain. In summary, Avalanche presents a revolutionary technology both in consensus and horizontal scaling design via subnets.
The main novelty of Avalanche is its approach to scaling, which involves the concept of subnets. A subnet is a set of Avalanche validators and the assignment of one or more blockchains for these validators to validate. There is a mainnet, or Primary Network, which consists of all Avalanche validators and that are assigned the P-chain, X-chain and C-chain to validate. As mentioned before, the C-chain is the smart contracts chain that is EVM-equivalent. The X-chain is an UTXO DAG-based chain specially tailored for high-speed asset transfers. The P-chain is perhaps arguably the most important one as its job is to maintain the coordination of validators and delegators on all subnets.
Other subnets are therefore subsets of the mainet validators that are assigned additional blockchains to validate. The reasoning behind this design decision is brilliant: Instead of having one chain accomplish everything in the Avalanche ecosystem, each “sub” blockchain can specialize for a certain use case.
In the meantime, the platform is expanding and enabling developers to launch their own customizable blockchains. Distributing activity over several chains keeps the Avalanche platform dynamic and flexible, enabling it to meet the blockchain’s trinity of decentralisation, security, and scalability.
Avalanche delivers even more in terms of technology by regularly releasing open-source code in the form of VMs ready to be picked up by projects looking to jump in in the subnet movement. @DeFiKingdoms is an example of a live subnet.
Other projects in Avalanche may soon start to shift to the subnet environment. For instance, liquid staking via BenQi (sAVAX) with three more solutions coming up: Lido on Avalanche, LAVA, and Eden Network + YieldYak. There is also a competitive DeFi landscape which may do the same, with TraderJoe (DEX), Platypus (stable swap), Aave (lending) and many others.
Becoming a validator in Avalanche requires expertise and a bonded stake. It would be troublesome if being a validator on the Avalanche network was free since a bad actor might start a large number of nodes that would be queried often. A node must bond (stake) something valuable in order to become a validator (AVAX). The more AVAX bonds a node has, the more often that node is requested by other nodes. A node’s sampling of the network is not uniformly random. It is rather weighted by stake quantity. Nodes are encouraged to be validators because they get a reward if they are sufficiently accurate and responsive when validating. Chorus One behaves in this way, helping to secure Avalanche. Users can delegate to Chorus One to and share the rewards.
Validating Rights: The weight of validators is determined by the amount of staking tokens bonded as collateral.
Token distribution and inflation of 9.2%.
Reward Rate: Rewards are paid out at expiracy of the validation contract provided the validator uptime as seen by the network is above 80%.
Chorus One Commission: 2%
Staking Limits: The maximum weight of a validator (their own stake + stake delegated to them) is the maximum of 3 million AVAX and 5 times the amount the validator staked. For example, if you staked 2,000 AVAX to become a validator, only 8000 AVAX can be delegated to your node total (not per delegator)
Slashing: No slashing. A validator will receive a staking reward if they are online and respond for more than 80% of their validation period, as measured by a majority of validators, weighted by stake. You should aim for your validator be online and responsive 100% of the time.
Re-Staking: You need to withdraw rewards and re-stake them with some frequency if you want to make use of compounding returns hence, additional delegation is needed for compounding.
Staking Guide: To read a step-by-step guide on how to stake AVAX, click here