---
name: avax-l1s
description: Design or operate a sovereign Avalanche L1 while separating its security and economics from C-Chain.
---

# Avalanche L1s

Source review: 2026-09-06. Recheck network-dependent facts before use.

1. Specify why a separate chain is needed: custom execution, membership, gas economics or workload isolation. Compare that operational burden with deploying on C-Chain. Finish with an architecture decision, not an assumption that every app needs a chain.
2. Identify the validator model and lifecycle. Under ACP-77's converted L1 model, validators pay a continuous P-Chain fee rather than universally needing to stake 2,000 AVAX and validate the entire Primary Network. Legacy Subnets and Primary Network validators are separate cases. Verify the actual conversion and configuration.
3. Document the L1's validator set, admission rules, validator-manager contract, administrative powers and fee-balance maintenance. Quote current parameters from the relevant chain and software release; avoid presenting illustrative monthly costs as fixed prices.
4. For an EVM L1 record genesis, chain ID, native gas token, VM release, precompiles, access restrictions and upgrade configuration. Do not assume that C-Chain compiler support or deployed protocols automatically exist there.
5. Exercise validator registration, fee depletion alerts, node recovery and the intended upgrade path in the selected test environment. Add [Interchain](../interchain/SKILL.md) only for the connections the design needs.

**Evidence to return:** chain configuration, validator/security model, operating-cost assumptions, administrative controls and measured test results. An Avalanche L1 is not automatically an Ethereum-style rollup or a consumer of C-Chain's validator security.

## Primary sources

- [ACP-77: reinventing Subnets](https://build.avax.network/docs/acps/77-reinventing-subnets)
- [Avalanche L1 architecture](https://docs.avax.network/docs/avalanche-l1s)

## Make the L1 decision concrete

Read [Why](../why/SKILL.md) and [Architecture](../architecture/SKILL.md). A C-Chain application needing existing Aave/LFJ liquidity does not gain those deployments merely by launching an L1. A product requiring custom admission/gas/VM rules may justify one, but must own validator membership, upgrade/admin policy, node/RPC operations and bridge/relayer dependencies.

Deliver a configuration/authority matrix: VM/version and genesis; native asset and fees; validator manager; admission/removal and uptime policy; precompile privileges; upgrade mechanism; explorer/indexer; source/destination blockchain IDs. Distinguish ACP77's validator model from legacy Subnet assumptions using current primary sources.

Test the chosen VM with actual configured privileges and the intended validator/messaging stack. The bundle's C-Chain state forks and local EVM app do not validate a sovereign L1's consensus, precompiles or ICM delivery. Mark those environment tests unrun until executed. Include node replacement, validator-set changes, RPC loss, upgrade recovery and user exits in operational acceptance.