Avalanche Community Proposals

EIP-7702 was activated on the Ethereum mainnet in May 2025 as part of the Pectra upgrade, and introduced a new "set code transaction" type that allows Externally Owned Accounts (EOAs) to set the code in their account. This enabled several UX improvements, including batching multiple operations into a single atomic transaction, sponsoring transactions on behalf of another account, and privilege de-escalation for EOAs.

This ACP proposes adding a similar transaction type and functionality to Avalanche EVM implementations in order to have them support the same style of UX available on Ethereum. Modifications to the handling of account nonce and balances are required in order for it to be safe when used in conjunction with the streaming asynchronous execution (SAE) mechanism proposed in ACP-194.

This proposal introduces a precompiled contract that performs signature verifications for the secp256r1 elliptic curve on Avalanche's C-Chain. The precompile will be implemented at address 0x0000000000000000000000000000000000000100 and will enable native verification of P-256 signatures, significantly improving gas efficiency for biometric authentication systems, WebAuthn, and modern device-based signing mechanisms.

Streaming Asynchronous Execution (SAE) decouples consensus and execution by introducing a queue upon which consensus is performed. A concurrent execution stream is responsible for clearing the queue and reporting a delayed state root for recording by later rounds of consensus. Validation of transactions to be pushed to the queue is lightweight but guarantees eventual execution.

This ACP introduces a new P-Chain transaction type called CreateL1Tx that simplifies the creation of Avalanche L1s. It consolidates three existing transaction types (CreateSubnetTx, CreateChainTx, and ConvertSubnetToL1Tx) into a single atomic operation. This streamlines the L1 creation process, removes the need for the intermediary Subnet creation step, and eliminates the management of temporary SubnetAuth credentials.

Proposes a standard P-Chain epoching scheme such that any VM that implements it uses a P-Chain block height known prior to the generation of its next block. This would enable VMs to optimize validator set retrievals, which currently must be done during block execution. This standard does not introduce epochs to the P-Chain's VM directly. Instead, it provides a standard that may be implemented by layers that inject P-Chain state into VMs, such as the ProposerVM.

Proposes that the C-Chain and Subnet-EVM chains adopt a dynamic fee mechanism similar to the one introduced on the P-Chain as part of ACP-103, with modifications to allow for block proposers (i.e. validators) to dynamically adjust the target gas consumption per unit time.

Proposes that the ProposerVM passes inner VMs the P-Chain block height of the current block being built rather than the P-Chain block height of the parent block. Inner VMs use this P-Chain height for verifying aggregated signatures of Avalanche Interchain Messages (ICM). This will allow for a more reliable way to determine which validators should participate in signing the message, and remove unnecessary waiting periods.

Enable new EVM opcodes and opcode changes in accordance with the following EIPs on the Avalanche C-Chain and Subnet-EVM chains:

• EIP-4844: BLOBHASH opcode
• EIP-7516: BLOBBASEFEE opcode
• EIP-1153: Transient storage
• EIP-5656: MCOPY opcode
• EIP-6780: SELFDESTRUCT only in same transaction

Note blob transactions from EIP-4844 are excluded and blocks containing them will still be considered invalid.

Reduce the minimum base fee on the Avalanche C-Chain from 25 nAVAX to 1 nAVAX.

Proposes a standard AppRequest payload format type for requesting Warp signatures for the provided bytes, such that signatures may be requested in a VM-agnostic manner. To make this concrete, this standard type should be defined in AvalancheGo such that VMs can import it at the source code level. This will simplify signature aggregator implementations by allowing them to depend only on AvalancheGo for message construction, rather than individual VM codecs.

Avalanche offers developers flexibility through subnets and EVM-compatible smart contracts. However, the platform's deterministic block execution limits the use of traditional random number generators within these contracts.

To address this, a mechanism is proposed to generate verifiable, non-cryptographic random number seeds on the Avalanche platform. This method ensures uniformity while allowing developers to build more versatile applications.

Defines a standard smart contract interface and abstract implementation for importing EVM events from any blockchain within Avalanche using Avalanche Warp Messaging.

Introduce a dynamic fee mechanism to the P-Chain. Preview a future transition to a multidimensional fee mechanism.

Define a standard Validator Manager Solidity smart contract to be deployed on any Avalanche EVM chain.

This ACP relies on concepts introduced in ACP-77 (Reinventing Subnets). It depends on it to be marked as Implementable.

The current ACP template features a plain-text code block containing "RFC 822 style headers" as Preamble (see What belongs in a successful ACP?). This header includes multiple links to discussions, authors, and other ACPs.

This ACP proposes to replace the Preamble code block with a Markdown table format (similar to what is used in Ethereum EIPs).

Introduce a dynamic and multidimensional fees scheme for the P-chain and X-chain.

Dynamic fees helps to preserve the stability of the chain as it provides a feedback mechanism that increases the cost of resources when the network operates above its target utilization.

Multidimensional fees ensures that high demand for orthogonal resources does not drive up the price of underutilized resources. For example, networks provide and consume orthogonal resources including, but not limited to, bandwidth, chain state, read/write throughput, and CPU. By independently metering each resource, they can be granularly priced and stay closer to optimal resource utilization.

Overhaul Subnet creation and management to unlock increased flexibility for Subnet creators by:

• Separating Subnet validators from Primary Network validators (Primary Network Partial Sync, Removal of 2000 $AVAX requirement)
• Moving ownership of Subnet validator set management from P-Chain to Subnets (ERC-20/ERC-721/Arbitrary Staking, Staking Reward Management)
• Introducing a continuous P-Chain fee mechanism for Subnet validators (Continuous Subnet Staking)

This ACP supersedes ACP-13 and borrows some of its language.

Introduces support for a proof of a block’s acceptance in consensus.

Disable AddValidatorTx and AddDelegatorTx to push all new stakers to use AddPermissionlessValidatorTx and AddPermissionlessDelegatorTx. AddPermissionlessValidatorTx requires validators to register a BLS key. Wide adoption of registered BLS keys accelerates the timeline for future P-Chain upgrades. Additionally, this reduces the number of ways to participate in Primary Network validation from two to one.

Remove user-specified StartTime for stakers. Start the staking period for a staker as soon as their staking transaction is accepted. This greatly reduces the computational load on the P-chain, increasing the efficiency of all Avalanche Network validators.

Allow the current owner of a Subnet to transfer ownership to a new owner.

Integrate Avalanche Warp Messaging into the C-Chain and Subnet-EVM in order to bring Cross-Subnet Communication to the EVM on Avalanche.

Support a way for a Virtual Machine (VM) to signal application-defined error conditions to another VM.

This ACP proposes the adoption of the following EIPs on the Avalanche C-Chain network:

• EIP-3651: Warm COINBASE
• EIP-3855: PUSH0 instruction
• EIP-3860: Limit and meter initcode
• EIP-6049: Deprecate SELFDESTRUCT

Support native transfers on P-chain. This enables users to transfer P-chain assets without leaving the P-chain or using a transaction type that's not meant for native transfers.

Support Ed25519 TLS certificates for p2p communications on the Avalanche network. Permit usage of Ed25519 public keys for Avalanche Network Client (ANC) NodeIDs. Support Ed25519 signatures in the ProposerVM.

Introduce a new type of staker, Subnet-Only Validators (SOVs), that can validate an Avalanche Subnet and participate in Avalanche Warp Messaging (AWM) without syncing or becoming a Validator on the Primary Network. Require SOVs to pay a refundable fee of 500 $AVAX on the P-Chain to register as a Subnet Validator instead of staking at least 2000 $AVAX, the minimum requirement to become a Primary Network Validator. Preview a future transition to Pay-As-You-Go Subnet Validation and $AVAX-Augmented Subnet Security.

_This ACP does not modify/deprecate the existing Subnet Validation semantics for Primary Network Validators._