An L1, or subnetwork, is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. Each blockchain is validated by exactly one L1, however, an L1 can validate more than one blockchain. A node may be a member of arbitrarily many L1s. It manages its own membership and it may require that its constituent validators have certain properties. L1s are independent and don’t share execution thread, storage, or networking with other L1s or the 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.

To create the L1, it costs 1 AVAX. Initial fees are available here on the following page so you can determine the costs of starting your specific L1.

No. L1 have their own state and execution thread. So it does not share the processing, TPS, or networking with the Primary Network. Thus enabling lower latency, higher transactions per second (TPS), and lower transaction costs.

Yes, it is up to your team to decide. To achieve full privacy (as in, nobody can see the contents of the transactions being made), you will need to deploy a VM that enables such operations.

Currently, staking is only available on the Primary Network. Any staking/rewards mechanism on the L1 must be handled by the L1 itself. L1 Validation Rewards is on the roadmap.

You can use EVM or any other VM of your choosing. Currently, besides the EVM and AvalancheVM, we also have SpacesVm (key/value storage), BlobVM (binary storage), TimestampVM (a minimum viable VM), and others that are in development.

L1s require validators, and each validator must have a minimum of 2000 AVAX. In addition, more L1s will create network effects on the Avalanche ecosystem. Also if other L1s use AVAX as their native token, that will also drive the value of the AVAX token.

Users can learn more about Avalanche L1s on the Avalanche Explorer.

This is currently under development. In the meantime, you can build your own bridge or use a 3rd party solution to communicate with C-chain and other L1s. You can find a tutorial here.

No, but an L1 can have multiple blockchains within it.

The answer is usually yes. Custom Virtual Machines are non-opinionated. This brings great flexibility to L1. There are a few interfaces and structures that a VM needs to implement for consensus requirements. Other than these, a Virtual Machine can be fully customized to provide any custom business logic.

L1s can use either Avalanche or Snowman, which is the implementation of the Avalanche consensus protocol for linear chains. However, AvalancheGo only supports implementing custom chain-based VMs. So unless your L1 is using the AVM, it is going to be using Snowman.

L1s are independent of one another, therefore they do not share or follow the execution logic, fee regime, state, networking, and security requirements of the other L1s or the Primary network.

A minimum of 5 validators is suggested. You can run a L1 with less (even one), but that is not recommended since your L1 will halt easily if one or more validators go offline. As a general rule, you should have as many validators as possible.

It depends if you have the resources to create your own validators. If not, you can incentivize existing validators to validate your L1.

Yes, validators will validate both the L1 and the Primary Network (X, P, and C-Chain). It is up to the node operator to ensure the optimal health of the node. Note: Validators can also validate more than one L1 on top of the Primary Network.

This allows operators to be early adopters in new projects by validating them, thus reaping potential tokens and rewards from the L1 itself but also the growth of that L1 ecosystem. It also keeps a flow of new L1s and projects coming to the network in which you can participate from the ground up. Also, L1s need to incentivize the validators to join, so validators are expected to have direct benefits for providing their service to the L1.

Yes, you can have your own specific requirements such as hardware or geographical, etc.

Yes, your L1 can be designed to do so.

For the Subnet-EVM, transactions are paid for by the native token of the platform. You can define initial balances on your chain by setting its genesis to give whatever addresses you want an initial starting balance.

Only 1 token can be used for the network fee, and this cannot be split between multiple tokens.

Yes, you can choose to use any token as your native token.

Yes, for example, a L1 can require token A to be used to stake to be a validator on the L1, which will also be paid out to validators for validating the L1. While token B can be used as gas for transactions on the L1. Note that validators are always paid in the staking token.

Banff 5 (AvalancheGo v1.9.5) included Avalanche® Warp Messaging, which allows for cross-chain L1 transactions. To learn more about Avalanche® Warp Messaging, please check out this Medium article.

While it is possible to allow transactions free of charge on your L1, this poses a serious Denial of Service risk. If users can freely and anonymously spam your chain with transactions it may cause legitimate users to run into high congestion and have a bad overall experience when interacting with your L1. For this reason, we recommend that you use non-zero fees in order to provide some spam prevention on your chain. If you use Subnet-EVM, there is already a dynamic fee algorithm so that the fees will be increased/decreased during periods of high/low network activity. If you feel strongly that you do not want users to pay for fees, it will require a well-thought-out alternative to prevent DoS attacks on your chain. While many have been proposed by various partners, we have found all of these proposed solutions have serious potential DoS vectors.

Since you can define your own VM, you can define whatever minting logic you want! You have complete control to create per block minting logic or otherwise to manipulate the EVM state however you see fit by creating a fork of Subnet-EVM. The simplest way to define some form of minting logic will be to set the Coinbase address that the Subnet-EVM will use such that all of the fees will be sent directly to that address allowing you to re-distribute these funds as you see fit.

You can define any minting logic that you want, you just have to dive into the Subnet-EVM to make the necessary modifications. If you have any ideas, we are happy to discuss and potentially even add first-class support for it within the Subnet-EVM repo if it’s something that many others might find useful as well. You can also make your L1 native token a variable cap token, and then you are able to mint the token whenever you want and how much you want.