Avalanche Evergreen L1s offer a suite of blockchain deployments and tooling designed to address company-specific and industry-wide considerations. Evergreen Subnets maintain the benefits of public network development, including interoperability and composability, while enabling particular chain-level features only possible in enterprise blockchains.
.svg)
Enables traditional buy- and sell-side institutions to engage with public blockchain infrastructures in a low risk, low barrier-to-entry way.
Onyx by J.P Morgan and Apollo Global delivered a proof-of-concept (PoC) that marked a pivotal step toward revolutionizing the asset and wealth management industry. It demonstrated the possibility of including tokenized alternative investments (“alts”) alongside liquid assets in discretionary client portfolios and leveraged a variety of protocols and infrastructure partners, including an Avalanche Evergreen L1.
.png)
Intain empowers participants in the multi-trillion dollar structured finance market to issue & trade asset-backed securities on-chain. This structured finance platform facilitates administration of $5.5B in assets, and launched an on-chain marketplace for tokenized asset-backed securities on an Avalanche L1.
Download Reflexivity’s case study on Bringing the Next Cohort of Financial Institutions On-Chain with Avalanche.
The Avalanche Foundation is allocating up to $50M to purchase tokenized assets (often referred to as “real world assets'' or tokenized “off-chain assets”) minted on the Avalanche blockchain.
In this report we offer an overview on the dynamic space of tokenizing OCAs, exploring advantages and obstacles, while delving into innovative projects and protocols in this field.
Avalanche L1s are a dramatic step forward over existing blockchain models that enforce a uniform set of rules across the entire network, meaning a simple NFT launch and a multi-billion dollar loan between institutions are beholden to the same network toolkit and logic.
.svg)
Avalanche L1sare ‘custom blockchains’ that give builders control and scalability within the broader Avalanche Network.
With Avalanche L1 design, individuals and enterprises can control all layers of their platform, including custom virtual machines, gas tokens, compliance requirements, data encryption privacy and permissioning, and more.
Sub-networks, or Subnets, are a dramatic step forward over existing blockchain models that enforce a uniform set of rules across the entire network, meaning a simple NFT launch and a multi-billion dollar loan between institutions are beholden to the same network toolkit and logic.
.svg)
Subnets are ‘custom blockchains’ that give builders control and scalability within the broader Avalanche Network.
With Subnets, individuals and enterprises can control all layers of their platform, including custom virtual machines, gas tokens, compliance requirements, data encryption privacy and permissioning, and more.
Get in touch to launch your use case with Evergreen L1s, or to discuss further.
The technical definition of a Subnetwork, or Subnet, is a subset of Avalanche primary network validators working together to achieve consensus on the state of a blockchain or set of blockchains. Each blockchain is validated by exactly one Subnet; however, a Subnet can validate, or contain, more than one blockchain. A given node may be a member of arbitrarily many Subnets. It manages its own membership and may require that its constituent validators have certain properties. Subnets are independent and don’t share execution thread, storage, or networking with other Subnets or the Avalanche Primary Network, effectively allowing the network to scale up easily while enabling lower latency, higher transactions per second (TPS), and lower transaction costs. They also share the benefits provided by the Avalanche Protocol such as low cost and time to finality through Avalanche Consensus.
Practically, Subnets are application-specific L1 blockchains that collectively constitute the Avalanche network. They can be customized along a wide array of parameters and features to ensure optimization for any given application or use case--including, but not limited to, Institutional, Enterprise, Government, Gaming, Healthcare, and DeFi deployments.
No. L1s have their own state and execution thread, so they do not share the processing, TPS, or networking with the Primary Network. This enables lower latency, higher transactions per second (TPS), and lower transaction costs for the activity on any given L1.
This is a big reason why companies and builders decide to deploy their use cases on Avalanche L1s, especially for those applications that require high-throughput and/or facilitate low value asset asset transfer where high transaction fees make activity prohibitively expensive to execute.
Yes. At this time, Avalanche L1 validators validate both the L1 as well as the Primary Network (containing the X-, P-, and C-Chains). It is up to the node operator to ensure the optimal health of their node(s). However, for regulated Institutions who are looking for a service to validate the Primary Network or who are unable to hold crypto tokens, i.e., AVAX, to do so, the AvaCloud offering provides various services to manage this requirement in tandem with or on behalf of clients. To learn more, please contact avastudios@avalabs.org
For Mainnet deployments, a minimum of 5-8 validators is suggested. An Avalanche L1 with less is not recommended since it could halt more easily if one or more validators go offline. As a general rule, Avalanche L1s should have as many validators as possible.
For Subnet-EVM, transactions are paid for by the native token of the platform, which can be AVAX, a stablecoin, or any other token–whether valuable or valueless (see below for further information). The initial balances can be defined on the chain by inputting them in the genesis.json and used to supply defined addresses with an initial starting balance.
It should be noted that only one token can be used for the network fee, and this cannot be split between multiple tokens on a given Avalanche L1.
An Avalanche L1 Operator is anyone who holds the control keys for the L1. The L1 Operator has Administrator privileges on the pre-compiles (see below for more information) and L1 configuration and is responsible for ensuring the network architecture remains aligned with the intended goals of the L1. An Avalanche L1 Operator can enable other Admin or User privileges for individual addresses on the L1. Additionally, the L1 Operator and Admin(s) can be different entities. This guarantees that the L1 Operator remains in control of their network but enables them to assign Admins to carry out the development functions.
Avalanche L1s can be deployed as EVM compatible; however, they can also be deployed on any other VMs that are available. For example, an Avalanche L1 can be optimized using a VM such as HyperVM, Rust, MOVE, and more. Conceptually, this means that other L1s being built and developed based on non-EVM VMs can be deployed as Avalanche L1s with Avalanche Consensus (i.e., think, Solana or Aptos as a Subnet) while maintaining the ability to seamlessly interoperate with the other blockchains within the Avalanche network.
In addition, Avalanche’s being VM-agnostic means that, while the network will continue to evolve with optimizations to and innovations surrounding the EVM, it can also continue to scale and grow with continued innovation in the broader VM space.
Stateful pre-compiles are similar to programming libraries and can be thought of as widgets or pre-batched templates for executing certain functions. In other words, they are pre-compiled smart contracts that enable developers to add specific customizations or functionalities at the blockchain level (i.e., through state access) to their EVM Avalanche L1 without writing a single line of solidity.
Practically, stateful pre-compiles are readymade blockchain-level customization features that can be implemented in any given Avalanche L1 to meet different companies’ or builders’ requirements or use cases. Some examples include pre-compiles determining who can access and transact on the blockchain, who can deploy smart contracts on the blockchain, what the transaction fees are on the blockchain, and more. See below for more detailed examples.
This pre-compile restricts the users that can submit transactions on the Avalanche L1 through an allowlist. When this is enabled, Avalanche L1 Operators can define the wallet addresses that are able to transact on the L1 (based on any number of whitelisting criteria such as AML/KYC, investor accreditation, jurisdictional considerations, etc.) and can set their roles as either Admins or Users. This allows the Subnet Operator to determine who participates in the blockchain network and how they can participate based on various specifications relevant to the Operators’ use case(s) or application(s). The allowlist can be dynamically updated based on various conditions and/or can be manually amended by the Avalanche L1 Operator.
This pre-compile determines which wallet addresses can deploy smart contracts on the Avalanche L1. The L1 Operator can determine which users have this ability based on whichever criteria is relevant or required (e.g., AML/KYC, jurisdictional considerations, membership of a certain consortium or industry group, etc.). This level of customization ensures that–where needed–compliance and security specifications can be implemented properly when the Avalanche L1 launches. The allowlist can be dynamically updated based on various conditions and/or can be manually amended by the L1 Operator.
In the standard EVM, initial allocation of native (gas) tokens is done by minting them to certain wallet addresses in the genesis. After launch the only way to create new tokens is through block mining rewards. Since Avalanche uses PoS, there is no block mining; therefore, there is no way to mint new tokens, which can be limiting as the amount of tokens will always diminish and eventually run out. To address this issue, the Native Minter pre-compile allows the Avalanche L1 Operator to mint new tokens to specific addresses for their L1 at any point after the L1 launch. Like other Avalanche L1 Controls, Operators can add new wallets to use this and set their role to Admin or User.
Avalanche L1s can be designed with their own custom dynamic gas fees. This offers a multitude of options to generate fees that can be used to help incentivize network growth and other operations, as well as provide a dynamic network congestion control by automatically adjusting the gas price to current network conditions.
While it is possible to allow transactions free of charge on an Avalanche L1, this poses a serious Denial of Service risk. If users can freely and anonymously spam the blockchain with transactions, this may cause legitimate users to run into high congestion and have a poor overall experience when interacting with the L1. For this reason, it is recommended to use non-zero fees in order to provide some spam prevention on your chain.
There are, however, solutions that allow for no transaction costs to Avalanche L1 end users, including gasless relayers, token allocation at onboarding, etc.; the AvaStudios team can help consult on an optimal solution.
In the standard EVM, the configuration of dynamic fees is locked in at genesis and the only way to change this is to perform a network upgrade, which is a very sensitive operation requiring a high level of coordination with validators and other network actors. Since the optimal way to configure dynamic fees is hard to know in advance before launch and optimal fee configuration can change over time, often it would be beneficial to be able to change the fee configuration after post- launch. To make the process easier, the Dynamic Fees Config pre-compile was created to enable this post-launch amendment with a simple on-chain transaction rather than a full network upgrade, vastly simplifying and de-risking the operation.
By default, all fees on the Avalanche network are burned, and the same goes for Avalanche L1s. Through the Reward Config pre-compile, however, the L1 Operator can customize the way accumulated gas fees are distributed as rewards. There are various options available as Avalanche L1 rewards can be sent to a predefined address, burned, or collected by block producers. They can even be sent to a smart contract address where a more complex reward system can be applied. For example, this could be used as an incentive to increase the amount of validators on the L1 by offering rewards for adhering to certain parameters set forth by the Avalanche L1 Operator.
For permissioned (PoA) Avalanche L1s, staking of tokens by validators is not required by the platform, and the mechanism for admitting L1 validators is entirely up to the L1 Operator. Operators can require validators to stake whichever token they desire or they can require some other arrangement (legal contract, for example) that does not involve tokens at all.
For permissionless (elastic) Avalanche L1s, the platform does not prescribe which token must be used for staking and is up to the L1 Operator to determine. It can be the L1 gas token or any other non-liquid token.
Simply put, an Avalanche L1 Operator can provision the L1 to use a different token for gas and staking if desired.
An Avalanche L1 does not require the gas token to be AVAX. A custom gas token can be utilized instead on the network.
Since an Avalanche L1 can define a custom VM, the minting logic for the native token is also customizable. Avalanche L1 Operators have complete control to create per block minting logic or the ability to manipulate the EVM state they’d like by creating a fork of Subnet-EVM. The simplest way to define some form of minting logic is to set the address that the Avalanche L1 will use to receive all of the fees, which allows the L1 Operator to re-distribute the funds as they see fit.
Avalanche Evergreen L1s are out-of-the-box blockchains and tooling for Financial Institutions, specifically designed to account for company-specific and industry-wide considerations. Built-in and further customizable features include EVM compatibility, blockchain-level user permissioning (embedded allow lists based on KYC/KYB or other requirements), a permissioned validator set, and custom gas token. See here and here for examples.
Overall, Avalanche Evergreen L1s reap the benefits of public network development, innovation, and native integrations while enabling embedded, blockchain-level features only possible in enterprise blockchains–all while maintaining interoperability and composability where relevant for a particular application or use case.
Yes, by default an Avalanche Evergreen L1 is a permissioned L1 utilizing specific pre-compiles and architecture to enable customizable controls. From a privacy perspective, this means that blockchain transaction data is made visible only to the specific L1 validators.
For more granular transaction-level privacy, there are several options that can be additionally implemented (e.g., data encryption options, homomorphic encryption, the use of multiple permissioned L1s, etc.); to learn more, please contact avastudios@avalabs.org
In order to launch an Avalanche Evergreen L1 please review the following documentation to launch an L1 locally or on testnet. Ensure the genesis.json includes the pre-compiles for the TX AllowList and the Contract AllowList.
If you are interested in managed services for your deployment, please schedule a meeting with the AvaStudios team here.
To create an Avalanche Evergreen L1 on testnet, it costs 1 fuji AVAX. Initial fees are available here to determine the costs of starting a specific L1.
To create a L1 on mainnet, it will require the following:
Hardware Wallet: To manage the control keys, and security of the L1
Validators: 5 to 8 mainnet validators which will require a minimum of 2,000 AVAX per node
Block Explorer: A UI that allows users to view transactions on the network.
Indexing Service: A way to index, read, write, and broadcast to the blockchain,
Bridge: A solution to transfer assets between different networks and Avalanche L1s. L1 costs are variable and can be architected appropriately for the use case that is desired. For more information about pricing, and service providers please reach out here.
Managed Validator Nodes
AvaCloud takes the headache out of managing your blockchain's validator nodes for testnet and mainnet. Our team can assist with deploying the network, automated software updates, guaranteed backups, security patching, and auto scaling. Additionally, AvaCloud also provides AVAX staking services to fund your Avalanche L1 validators, so you can focus your resources on building your web3 application.
Block Explorer
The AvaCloud Explorer service allows an Avalanche L1 to be accessed on subnets.avax.network. This is a dedicated explorer to track all activity on-chain in real time including advanced network performance metrics and stats for the L1.
Glacier API
The Glacier API provides Web 3 application developers with multi-chain data related to Avalanche's primary network, Avalanche L1s, and Ethereum. With Glacier, you can easily build products that leverage real-time and historical transaction and transfer history, native and token balances, and various types of token metadata.
RPC Nodes
Avalanche RPC nodes provide secure, geographically distributed, and protected API endpoints you can use to interact with the Avalanche X/P/C chains
Dedicated Nodes
Get access to the Avalanche C-Chain archive nodes to query the entire history of the C-Chain mainnet or Avalanche L1.
Other dedicated nodes options are available depending on the need and can be managed by the AvaCloud team.
Avalanche Warp Messaging (AWM)
The AvaCloud team can implement Avalanche Warp Messaging (AWM) to enable native, out-of-the-box token bridging for an Avalanche L1. Avalanche Warp Messaging allows an L1 to communicate any type of message with other Avalanche L1s.
Join our community of industry leaders and subscribe to our monthly Avalanche Snow Report
.svg)