DeFi yield farmer reviewing staking dashboard at a WeWork standing desk, multiple screens with charts, coffee and notebook, casual afternoon work session.
Protocols

Subnet and L1 Configuration Standards

Tracks proposals that define the standard configuration parameters for a Subnet, such as validator requirements, uptime slashing rules, and primary network staking asset specifications. Subnet architects need this to design compliant and secure validator sets.
introduction
VALIDATOR SET AND ECONOMIC SECURITY DESIGN

What Are Subnet and L1 Configuration Standards?

Formal standards that define the operational parameters, validator requirements, and economic rules for Avalanche Subnets and L1s.

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.

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.

OPERATIONAL IMPACT MATRIX

Subnet Configuration Standards at a Glance

How proposed changes to subnet validator requirements, slashing rules, and staking parameters affect different operational roles.

AreaWhat changesWho is affectedAction

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

technical-context
SUBNET ARCHITECTURE

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.

IMPACT BY ACTOR

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
AFFECTED COMPONENTS

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

SUBNET AND L1 CONFIGURATION STANDARDS

Risk and Compatibility Matrix

Evaluates the operational, economic, and security impacts of proposed changes to Subnet configuration parameters on validators, stakers, and Subnet architects.

AreaWhat changesWho is affectedAction

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.

VALIDATOR SET AND ECONOMIC SECURITY REVIEW

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.

Chains We Build On

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 logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

SUBNET AND L1 CONFIGURATION STANDARDS

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 SubnetID or BlockchainID targeting: 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.

Trusted by Industry Leaders

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

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
“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.”
L
Lee Erswell
CEO, Telos Foundation
how to get started

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.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.