---
name: avax-why
description: Choose Avalanche C-Chain, an L1, or no chain by testing the application's actual trust and execution needs.
---

# Choose the right Avalanche surface

1. State what requires shared execution: transferable ownership, enforceable settlement, composability or verification across mutually distrustful parties. Separate that from search, media, private records and ordinary account administration. Finish with an onchain/offchain boundary; a token or an agent does not by itself require a new blockchain.
2. Compare C-Chain with an explicitly identified sovereign L1 using the matrix below. Treat access to existing liquidity, wallets and contracts as a deployment-specific dependency, not something every Avalanche chain inherits. Record the chosen chain and the rejected alternative's decisive constraint.
3. Verify the selected chain's current validator, VM, upgrade and gas configuration through [Networks](../networks/SKILL.md), [L1s](../l1s/SKILL.md) and [Upgrades](../upgrades/SKILL.md). Separate EVM chain ID, Avalanche blockchain ID and network ID. Finish with one coherent network configuration.
4. Inventory operational dependencies: RPC, indexer, frontend hosting, admin keys, oracle, relayer and data availability. For each identify who can deny service, change rules or recover funds. Read [Architecture](../architecture/SKILL.md) when that changes product claims.
5. Prove one critical integration before choosing a chain on advertised throughput or fees. For a C-Chain swap use a recipe linked from [DeFi](../defi/SKILL.md) and record a fresh quote plus local-fork balance deltas. For an L1, test the actual VM/precompile/ICM path. Finish with measured behavior, not ecosystem-wide benchmark claims.

| Requirement | Initial choice | Verify before committing |
| --- | --- | --- |
| Existing Avalanche lending/swaps and ordinary EVM contracts | C-Chain | Exact market deployment, liquidity, wallet and RPC support |
| Custom gas asset, execution rules or validator membership | Named L1 | Validator economics, governance, VM compatibility, operations and bridging |
| Private collaboration without public settlement | Conventional service may suffice | Access control, portability and whether a chain adds any needed guarantee |
| Cross-chain application | Explicit source/destination design | Source validator trust, message authentication, relaying and destination execution |

## Two decisions to emulate

A USDC interface using Aave V4 and LFJ starts on C-Chain because the demonstrated deployments and liquidity are there; launching a separate L1 would add contract, liquidity and bridge work. A game requiring custom transaction admission may justify its own L1, but its validator set and access rules must be described honestly rather than presented as C-Chain security.

For an agent service, separate identity, paid requests and spending authority. An ERC-8004 identity does not establish competence or grant a wallet budget; x402 payment does not authorize arbitrary recurring charges. Continue with [Standards](../standards/SKILL.md).

**Deliver:** a short decision record containing selected chain, required guarantees, rejected alternatives, dependencies and the proof still missing.

Sources: [Avalanche architecture](https://build.avax.network/docs/avalanche-l1s), [ACP-77 validator model](https://build.avax.network/docs/acps/77-reinventing-subnets), [Builder Hub](https://build.avax.network/).