What is an Avalanche Community Proposal (ACP)?

An Avalanche Community Proposal is a concise document that introduces a change or best practice for adoption on the Avalanche Network. ACPs should provide clear technical specifications of any proposals and a compelling rationale for their adoption.

ACPs are an open framework for proposing improvements and gathering consensus around changes to the Avalanche Network. ACPs can be proposed by anyone and will be merged into this repository as long as they are well-formatted and coherent. Once an overwhelming majority of the Avalanche Network/Community have signaled their support for an ACP, it may be scheduled for activation on the Avalanche Network by Avalanche Network Clients (ANCs). It is ultimately up to members of the Avalanche Network/Community to adopt ACPs they support by running a compatible ANC, such as AvalancheGo.

ACP Tracks

There are three kinds of ACP:

• A Standards Track ACP describes a change to the design or function of the Avalanche Network, such as a change to the P2P networking protocol, P-Chain design, Subnet architecture, or any change/addition that affects the interoperability of Avalanche Network Clients (ANCs).
• A Best Practices Track ACP describes a design pattern or common interface that should be used across the Avalanche Network to make it easier to integrate with Avalanche or for Subnets to interoperate with each other. This would include things like proposing a smart contract interface, not proposing a change to how smart contracts are executed.
• A Meta Track ACP describes a change to the ACP process or suggests a new way for the Avalanche Community to collaborate.
• A Subnet Track ACP describes a change to a particular Subnet. This would include things like configuration changes or coordinated Subnet upgrades.

ACP Statuses

There are four statuses of an ACP:

• A Proposed ACP has been merged into the main branch of the ACP repository. It is actively being discussed by the Avalanche Community and may be modified based on feedback.
• An Implementable ACP is considered "ready for implementation" by the author(s) and will no longer change meaningfully from its current form (which would require a new ACP).
• An Activated ACP has been activated on the Avalanche Network via a coordinated upgrade by the Avalanche Community. Once an ACP is Activated, it is locked.
• A Stale ACP has been abandoned by its author(s) because it is not supported by the Avalanche Community or has been replaced with another ACP.

ACP Workflow

Step 0: Think of a Novel Improvement to Avalanche

The ACP process begins with a new idea for Avalanche. Each potential ACP must have an author(s): someone who writes the ACP using the style and format described below, shepherds the associated GitHub Discussion, and attempts to build consensus around the idea. Note that ideas and any resulting ACP is public. Authors should not post any ideas or anything in an ACP that the Author wants to keep confidential or to keep ownership rights in (such as intellectual property rights).

Step 1: Post Your Idea to GitHub Discussions

The author(s) should first attempt to ascertain whether there is support for their idea by posting in the "Ideas" category of GitHub Discussions. Vetting an idea publicly before going as far as writing an ACP is meant to save both the potential author(s) and the wider Avalanche Community time. Asking the Avalanche Community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author(s). Small enhancements or patches often don't need standardization between multiple projects; these don't need an ACP and should be injected into the relevant development workflow with a patch submission to the applicable ANC issue tracker.

Step 2: Propose an ACP via Pull Request

Once the author(s) feels confident that an idea has a decent chance of acceptance, an ACP should be drafted and submitted as a pull request (PR). This draft must be written in ACP style as described below. It is highly recommended that a single ACP contain a single key proposal or new idea. The more focused the ACP, the more successful it tends to be. If in doubt, split your ACP into several well-focused ones. The PR number of the ACP will become its assigned number.

Step 3: Build Consensus on GitHub Discussions and Provide an Implementation (if Applicable)

ACPs will be merged by ACP maintainers if the proposal is generally well-formatted and coherent. ACP editors will attempt to merge anything worthy of discussion, regardless of feasibility or complexity, that is not a duplicate or incomplete. After an ACP is merged, an official GitHub Discussion will be opened for the ACP and linked to the proposal for community discussion. It is recommended for author(s) or supportive Avalanche Community members to post an accompanying non-technical overview of their ACP for general consumption in this GitHub Discussion. The ACP should be reviewed and broadly supported before a reference implementation is started, again to avoid wasting the author(s) and the Avalanche Community's time, unless a reference implementation will aid people in studying the ACP.

Step 4: Mark ACP as Implementable via Pull Request

Once an ACP is considered complete by the author(s), it should be marked as Implementable. At this point, all open questions should be addressed and an associated reference implementation should be provided (if applicable). As mentioned earlier, the Avalanche Foundation meets periodically to recommend the ratification of specific ACPs but it is ultimately up to members of the Avalanche Network/Community to adopt ACPs they support by running a compatible Avalanche Network Client (ANC), such as AvalancheGo.

[Optional] Step 5: Mark ACP as Stale via Pull Request

An ACP can be superseded by a different ACP, rendering the original obsolete. If this occurs, the original ACP will be marked as Stale. ACPs may also be marked as Stale if the author(s) abandon work on it for a prolonged period of time (12+ months). ACPs may be reopened and moved back to Proposed if the author(s) restart work.

What belongs in a successful ACP?

Each ACP must have the following parts:

• Preamble: RFC 822 style headers containing metadata about the ACP, including the ACP number, a short descriptive title, the author(s), and optionally the contact info for each author, etc.
• Abstract: Concise (~200 word) description of the ACP
• Motivation: Rationale for adopting the ACP and the specific issue/challenge/opportunity it addresses
• Specification: Complete description of the semantics of any change should allow any ANC/Avalanche Community member to implement the ACP
• Security Considerations: Security implications of the proposed ACP

Each ACP can have the following parts:

• Open Questions: Questions that should be resolved before implementation

Each Standards Track ACP must have the following parts:

• Backwards Compatibility: List of backwards incompatible changes required to implement the ACP and their impact on the Avalanche Community
• Reference Implementation: Code, documentation, and telemetry (from a local network) of the ACP change

Each Best Practices Track ACP can have the following parts:

• Backwards Compatibility: List of backwards incompatible changes required to implement the ACP and their impact on the Avalanche Community
• Reference Implementation: Code, documentation, and telemetry (from a local network) of the ACP change

ACP Formats and Templates

Each ACP is allocated a unique subdirectory in the ACPs directory. The name of this subdirectory must be of the form N-T where N is the ACP number and T is the ACP title with any spaces replaced by hyphens. ACPs must be written in markdown format and stored at ACPs/N-T/README.md. Please see the ACP template for an example of the correct layout.

Auxiliary Files

ACPs may include auxiliary files such as diagrams or code snippets. Such files should be stored in the ACP's subdirectory (ACPs/N-T/*). There is no required naming convention for auxiliary files.

Waived Copyright

ACP authors must waive any copyright claims before an ACP will be merged into the repository. This can be done by including the following text in an ACP:

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

Proposals

You can view the status of each ACP on the ACP Tracker.

Number	Title	Author(s)	Type
13	Subnet-Only Validators (SOVs)	Patrick O'Grady ([email protected])	Standards
20	Ed25519 p2p	Dhruba Basu (https://github.com/dhrubabasu)	Standards
23	P-Chain Native Transfers	Dhruba Basu (https://github.com/dhrubabasu)	Standards
24	Activate Shanghai EIPs on C-Chain	Darioush Jalali (https://github.com/darioush)	Standards
25	Virtual Machine Application Errors	Joshua Kim (https://github.com/joshua-kim)	Standards
30	Integrate Avalanche Warp Messaging into the EVM	Aaron Buchwald ([email protected])	Standards
31	Enable Subnet Ownership Transfer	Dhruba Basu (https://github.com/dhrubabasu)	Standards
41	Remove Pending Stakers	Dhruba Basu (https://github.com/dhrubabasu)	Standards
62	Disable AddValidatorTx and AddDelegatorTx	Jacob Everly (https://twitter.com/JacobEv3rly), Dhruba Basu (https://github.com/dhrubabasu)	Standards
75	Acceptance Proofs	Joshua Kim (https://github.com/joshua-kim)	Standards
77	Reinventing Subnets	Dhruba Basu (https://github.com/dhrubabasu)	Standards
83	Dynamic Multidimensional Fees for P-Chain and X-Chain	Alberto Benegiamo	Standards
84	Table Preamble for ACPs	Gauthier Leonard (https://github.com/Nuttymoon)	Meta

Contributing

Before contributing to ACPs, please read the ACP Terms of Contribution.