Subnet and L1 Configuration Standards are a class of Avalanche Community Proposals (ACPs) that define the canonical set of parameters for creating and operating a Subnet on the Avalanche Primary Network. These standards specify the technical and economic requirements for a Subnet's validator set, including the minimum staking amount, the staking token (which can be the native AVAX token or a custom asset), uptime requirements, and slashing conditions for malicious or faulty validators. For Subnet architects, these standards are the blueprint for designing a compliant and secure validator set that can be recognized and validated by the P-Chain.

Subnet and L1 Configuration Standards
What Are Subnet and L1 Configuration Standards?
Formal standards that define the operational parameters, validator requirements, and economic rules for Avalanche Subnets and L1s.
The operational impact of these standards is significant for both Subnet operators and the validators securing them. A proposal that alters the minimum stake or the accepted staking asset directly affects the capital requirements for validators and the economic security model of the Subnet. Changes to uptime slashing rules, for example, require validators to update their monitoring and alerting infrastructure to avoid penalties. The introduction of Elastic Subnets through the Etna upgrade is a direct consequence of evolving configuration standards, enabling permissionless validator participation where anyone can stake to secure the network, a departure from the earlier permissioned model.
For teams building custom L1s, understanding the lifecycle of these configuration standards is critical. A proposal that is under debate may signal a future where a Subnet's security model must adapt, while an accepted and implemented standard defines the current operational reality. Builders must track these standards to ensure their Subnet's design remains compatible with the Primary Network's expectations and to plan for necessary upgrades to their validator coordination software, staking interfaces, and economic incentive models.
Subnet Configuration Standards at a Glance
How proposed changes to subnet validator requirements, slashing rules, and staking parameters affect different operational roles.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Validator eligibility | Minimum stake amount, hardware requirements, or geographic distribution rules may be introduced or modified | Subnet validators, staking pool operators | Audit current validator set against proposed requirements; model capital and infrastructure costs |
Uptime and slashing | New or adjusted slashing conditions for validator downtime, double-signing, or equivocation | Validators, delegators, liquid staking protocols | Review slashing severity and unbonding periods; update risk disclosures for delegators |
Staking asset specification | Rules defining which asset can be used for staking on a subnet (e.g., native token vs. AVAX) | Subnet architects, exchanges, wallet teams | Verify asset custody and staking transaction support; assess liquidity impact of asset choice |
Delegation mechanics | Changes to minimum delegation, reward distribution frequency, or delegation caps | Delegators, staking UI providers, explorers | Update staking interfaces and reward calculators; communicate changes to delegation user base |
Validator set management | Process for adding, removing, or rotating validators in a permissioned or elastic subnet | Subnet operators, governance multisig signers | Test validator churn procedures; ensure monitoring detects unauthorized validator changes |
Economic security model | New parameters linking stake weight to subnet security guarantees or cross-chain messaging | Bridge operators, cross-chain application developers | Re-evaluate trust assumptions for cross-chain messages; model cost-of-corruption scenarios |
Governance control scope | Clarification of which parameters a subnet can govern autonomously vs. those inherited from the P-Chain | Subnet governance architects, DAO tooling teams | Map governance surface to on-chain parameters; verify governance contract compatibility with new standards |
The Configuration Surface of a Subnet
The set of configurable parameters that define a Subnet's economic security, validator behavior, and operational rules.
In Avalanche, a Subnet's configuration surface is the collection of parameters that a Subnet architect defines at creation and manages over its lifecycle. These settings are not merely cosmetic; they directly encode the economic and security assumptions of the L1. The standard configuration includes the choice of the primary network's staking asset (typically AVAX, but potentially a custom token), the minimum staking amount and duration for validators, the uptime requirements, and the slashing conditions for byzantine or inactive nodes. These parameters collectively determine the cost of a 51% attack, the reliability of the validator set, and the degree of alignment with the broader Avalanche ecosystem.
Operationally, the configuration surface dictates the hardware and capital requirements for validators. A Subnet with a high minimum stake and a long lock-up period creates a high barrier to entry, favoring institutional operators, while a low-stake, permissionless model enabled by the Etna upgrade allows for a more fluid validator set. The uptime slashing rules are critical for application-layer reliability; overly aggressive slashing can deter participation, while lenient rules may lead to a degraded quality of service for cross-chain messaging protocols like Warp Messaging. Subnet architects must balance these parameters to achieve a target level of economic security without making the cost of validation prohibitive.
For teams integrating with a Subnet—such as exchanges, bridges, or wallet providers—the configuration surface is a primary risk assessment document. The choice of staking asset affects custody requirements, while the slashing and uptime parameters inform the operational risk of accepting the Subnet's state as final. A thorough review of these standards is essential before integrating, as a misconfigured Subnet can expose downstream applications to liveness failures or re-organization risks. Chainscore Labs can perform a protocol impact assessment on a Subnet's configuration, modeling the economic security under various market conditions and reviewing the implementation for deviations from standard ACPs.
Who Is Affected by These Standards?
Subnet Architects
Subnet architects are the primary audience for configuration standards. These proposals define the exact parameters you must specify when designing a Subnet's security model, including minimum validator stake amounts, uptime requirements, and slashing conditions.
Key actions:
- Map your Subnet's economic security requirements against the standard parameter ranges before finalizing genesis configuration.
- Validate that your chosen uptime and slashing rules are compatible with the validator profiles you intend to attract.
- If using a custom VM, ensure it correctly interprets the P-Chain's validator set and slashing outputs.
- Monitor ACPs that expand or modify the configuration surface—new parameters may require a Subnet upgrade to adopt.
Misconfiguring these standards can lead to validator churn, unexpected slashing, or a validator set that fails to meet your security assumptions.
Implementation Impact by System
Subnet and L1 configuration standards directly alter the operational and economic requirements for validators, stakers, and the core protocol. The following systems require immediate assessment.
Validator Node Operations
New configuration standards can mandate changes to minimum staking amounts, uptime requirements, or hardware specifications. Node operators must audit their current setup against accepted ACPs to ensure they are not slashed or ejected from the validator set. A readiness review should cover automated key management, monitoring for new slashing conditions, and testing failover procedures under the updated ruleset.
Staking and Delegation Workflows
Changes to staking parameters—such as minimum delegation amounts, lock-up periods, or reward curves—break existing UI assumptions and custodian logic. Wallets and staking interfaces must update their transaction construction to handle new P-Chain constraints. Teams should verify that multi-sig and institutional custody workflows remain compatible with the updated staking primitives to prevent locked funds.
Subnet Economic Security Model
Elastic validation and permissionless validator standards redefine the economic security of a Subnet. Architects must re-evaluate the cost-of-corruption by modeling the new staking asset requirements and slashing conditions. A security review should simulate validator collusion scenarios under the updated configuration to ensure the Subnet's trust assumptions remain aligned with the value it secures.
Primary Network Staking Contracts
Standards that alter the staking asset specification on the P-Chain require a deep audit of smart contract dependencies. Any contract that programmatically stakes or unstakes must be updated to handle new transaction types or asset identifiers. Failure to upgrade these contracts before a standard activates can result in permanent loss of control over staked funds.
Exchange and Custody Integration
Exchanges and custodians supporting AVAX staking must implement new transaction parsing logic for modified staking workflows. A failure to recognize new output types or address formats can halt deposits and withdrawals. Integration teams should run a full regression test against the Fuji testnet activation to validate balance reconciliation, fee estimation, and transaction construction before a Mainnet activation.
Governance and Upgrade Coordination
Subnet sovereignty standards grant operators independent control over their chain's parameters. Governance architects must design a process for proposing and enacting configuration changes without fragmenting the validator set. This requires building on-chain voting mechanisms or multi-sig admin controls that can safely execute parameter updates while maintaining consensus among geographically distributed validators.
Risk and Compatibility Matrix
Evaluates the operational, economic, and security impacts of proposed changes to Subnet configuration parameters on validators, stakers, and Subnet architects.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Validator Requirements | Minimum stake amount, hardware specs, or uptime requirements for Subnet validators are modified. | Subnet validators, Subnet operators, institutional stakers | Audit validator fleet against new minimums; plan for hardware upgrades or stake top-ups to avoid forced exits. |
Uptime Slashing Rules | Introduction or adjustment of penalties for validators failing to meet liveness thresholds. | Subnet validators, delegation services, staking pools | Review monitoring and alerting systems; model economic risk of slashing under new parameters; update delegation risk disclosures. |
Primary Network Staking Asset | Specification of which asset (e.g., AVAX, a Subnet's native token) is used for staking on the P-Chain to secure the Subnet. | Subnet architects, exchanges, custody providers | Verify asset support in custody and staking infrastructure; assess liquidity and volatility risks of the chosen staking asset for validator economic security. |
Delegation Rules | Changes to minimum delegation amounts, fees, or the ability to delegate to Subnet validators. | Delegators, wallet teams, staking interface providers | Update wallet UIs and staking dashboards; communicate new delegation parameters to users to prevent transaction failures. |
Validator Set Management | Alteration of the mechanism for adding or removing validators, including churn limits or activation delays. | Subnet operators, infrastructure providers, RPC services | Rehearse validator addition and removal procedures; update operational playbooks for validator lifecycle management. |
Economic Security Model | A shift in the staking asset or slashing parameters that changes the cost-of-corruption for a Subnet. | Subnet architects, security auditors, DeFi protocols building on the Subnet | Re-evaluate the Subnet's economic security assumptions; communicate changes to protocols dependent on the Subnet's security for cross-chain messaging or asset bridging. |
Cross-Subnet Interoperability | Configuration standards that affect how a Subnet's validator set is proven to other chains via Warp Messaging. | Bridge operators, Teleporter relayers, cross-chain application developers | Verify BLS signature aggregation and validator set proof generation remain compatible; test cross-chain message relay after configuration changes are activated. |
Subnet Architect's Configuration Checklist
A practical checklist for Subnet architects to validate their configuration against current P-Chain standards before launch. Each item identifies a critical design decision, explains why it matters for security and operations, and specifies the signal that confirms readiness.
What to check: Confirm whether your Subnet uses a permissioned validator set or the permissionless elastic validation model defined by the Etna upgrade standards.
Why it matters: The choice determines your security model, validator onboarding process, and staking mechanics. Permissioned Subnets rely on a trusted set of validators you control, while elastic Subnets allow any validator to join by staking the required asset. Misconfiguring this can lead to unexpected validator participation or liveness failures.
Readiness signal: Your genesis configuration explicitly sets the validatorSetType and, if elastic, defines the stakingAssetID, minimumStake, and delegationFee parameters. You have tested validator addition and removal on a testnet.
Canonical Resources
Primary sources for tracking Avalanche Subnet and L1 configuration standards, validator requirements, implementation behavior, and operational readiness.
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos

Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
Frequently Asked Questions
Common questions from Subnet architects and validator operators about the lifecycle, impact, and operational requirements of configuration standards.
Configuration standards typically define parameters for validator eligibility, staking assets, and uptime requirements. To determine applicability:
- Check the proposal scope: ACPs that modify P-Chain logic often apply to all Subnets by default, while others target specific Subnet types (e.g., permissionless or elastic).
- Review the
SubnetIDorBlockchainIDtargeting: Some standards are opt-in at the Subnet level. If your Subnet governance must explicitly activate a feature, the standard does not apply until you do. - Monitor validator set behavior: If a standard changes minimum stake duration or delegation rules, it will affect how you recruit and manage validators.
Teams should not assume a standard is irrelevant simply because their Subnet is sovereign. Changes to the Primary Network's validator management often cascade to Subnet security models.
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


