No. Subnets 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 Subnet. 

This is a big reason why companies and builders decide to deploy their use cases on Subnets, 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, Subnet validators validate both the Subnet 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. A Subnet with less is not recommended since it could halt more easily if one or more validators go offline. As a general rule, Subnets 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 Subnet.

A Subnet Operator is anyone who holds the control keys for the Subnet. The Subnet Operator has Administrator privileges on the pre-compiles (see below for more information) and Subnet configuration and is responsible for ensuring the network architecture remains aligned with the intended goals of the Subnet. A Subnet Operator can enable other Admin or User privileges for individual addresses on the Subnet. Additionally, the Subnet Operator and Admin(s) can be different entities. This guarantees that the Subnet Operator remains in control of their network but enables them to assign Admins to carry out the development functions.  

Avalanche Subnets can be deployed as EVM compatible; however, they can also be deployed on any other VMs that are available. For example, a Subnet 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 Subnets 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 Subnet without writing a single line of solidity. 

Practically, stateful pre-compiles are readymade blockchain-level customization features that can be implemented in any given Subnet 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 Subnet through an allowlist. When this is enabled, Subnet Operators can define the wallet addresses that are able to transact on the Subnet (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 Subnet Operator. 

This pre-compile determines which wallet addresses can deploy smart contracts on the Subnet. The Subnet 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 Subnet launches. The allowlist can be dynamically updated based on various conditions and/or can be manually amended by the Subnet 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 Subnet Operator to mint new tokens to specific addresses for their Subnet at any point after the Subnet launch. Like other Subnet Controls, Operators can add new wallets to use this and set their role to Admin or User.

Subnets 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 a Subnet, 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 Subnet. 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 Subnet 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 Subnets. Through the Reward Config pre-compile, however, the Subnet Operator can customize the way accumulated gas fees are distributed as rewards. There are various options available as Subnet 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 Subnet by offering rewards for adhering to certain parameters set forth by the Subnet Operator. 

For permissioned (PoA) Subnets, staking of tokens by validators is not required by the platform, and the mechanism for admitting Subnet validators is entirely up to the Subnet 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) Subnets, the platform does not prescribe which token must be used for staking and is up to the Subnet Operator to determine. It can be the Subnet gas token or any other non-liquid token.
‍
Simply put, a Subnet Operator can provision the Subnet to use a different token for gas and staking if desired.

A Subnet does not require the gas token to be AVAX. A custom gas token can be utilized instead on the network.

Since a Subnet can define a custom VM, the minting logic for the native token is also customizable. Subnet 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 Subnet will use to receive all of the fees, which allows the Subnet Operator to re-distribute the funds as they see fit. 

Avalanche Evergreen Subnets 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, Evergreen Subnets 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 Evergreen Subnet is a permissioned Subnet 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 Subnet 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 Subnets, etc.); to learn more, please contact avastudios@avalabs.org

In order to launch an Evergreen Subnet please review the following documentation to launch a Subnet 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 a Subnet on testnet, it costs 1 fuji AVAX. Initial fees are available here to determine the costs of starting a specific Subnet. 

To create a Subnet on mainnet, it will require the following:

‍Hardware Wallet: To manage the control keys, and security of the Subnet
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 SubnetsSubnets 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 subnet validators, so you can focus your resources on building your web3 application.

Block Explorer 
The AvaCloud Explorer service allows a subnet 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 subnet.

Glacier API 
The Glacier API provides Web 3 application developers with multi-chain data related to Avalanche's primary network, Avalanche subnets, 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 Subnet.

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 a Subnet. Avalanche Warp Messaging allows a Subnet to communicate any type of message with other Subnets. 

There are many Subnets in various stages of production and deployment across various industries and use cases. Please see below for links to some of these examples. 
‍Intain
‍Spruce
‍SK
‍TSM
‍Shrapnel
‍Meld
‍Deloitte
‍Dexalot

Developer Documentation
‍Discord
‍Support Articles
‍AvaCloud
‍GitHub
‍Subnets as a Scaling Solution
‍A Comparison of Heterogeneous Blockchain Networks