Skip to main content

Astroport Improvement Proposal Framework

Overview​

AIP0 defines the Astroport Improvement Proposals (AIPs) Framework for all subsequent AIPs to utilize. This AIP is foundational and provides the necessary templates, processes, and guidelines for working within the framework as well as defining the key roles required for the operation of the AIPs Process.

For Astroport to evolve into a fully decentralized and self-sustainable protocol, a formalized process of decision-making is required. In a permissionless protocol, everyone should be able to propose changes and improvements.

The AIP Framework serves to empower each Assembly participant by giving them a standardized way of interacting with the wider community and defining the protocol’s future shape.

For a detailed description of AIP0, you can check out the Astroport forum.

AIP Templates​

General AIP Template​

  • The General AIP Template should be used for AIPs whenever a more specific template is not more appropriate.
  • The General AIP Template is located at General-AIP-Template.md.

Technical AIP Template​

  • The Technical AIP Template should be used for AIPs whenever an AIP proposes changes to the smart contract code within the Astroport Protocol.
  • The Technical AIP Template is located at Technical-AIP-Template.md.

The AIP Lifecycle​

AIP Lifecycle Breakdown​

  1. Conception: An AIP Author posts an ARC proposal on the Astroport forum under the Astroport Requests for Comments category. From this point on, AIP Editors will be available to assist the AIP Author.

  2. Approved by AIP Editor(s): An AIP Editor verifies that the posted ARC proposal:

  • Follows the appropriate format of the AIP Template for its type.
  • Is either an original AIP or a replacement for an older AIP.
  • Has been submitted to the AIPs GitHub repository with a Pull Request by either the AIP Author or an AIP Editor.

If the verification is successful, the AIP Editor:

  • Approves the AIP and assigns it a formal AIP number.
  • Merges in the PR.
  1. Astroport Request for Comments (ARC): A period of reviewing by the community and attendant redrafting begins. The minimum duration of this period is determined by two variables:
  • Feedback Period: 7 days.
  • Frozen Period: 2 days (note that UI AIPs do not have a Frozen Period but only a Feedback one)

  1. Fulfilled Feedback Period Requirements: After the AIP has fulfilled the ARC phase, it is ready for on-chain submission.

  2. On-Chain Submission: At this point, the AIP Author has two options: submit an on-chain AIP vote referencing the associated ARC and then notify the Astroport community on the forum or request help from an AIP Editor to submit the on-chain vote.

  3. Accepted/Rejected: The AIP is voted on. If it passes, it is officially accepted and is given the Accepted status. If not, the AIP is rejected.

On-Chain Submission​

In order to submit an AIP on-chain, the AIP submitter must call the submit_proposal function from the Astral Assembly contract and specify the following parameters:

  • sender: The address of the proposal submitter
  • deposit_amount: The amount of xASTRO that must be locked in the Astral Assembly contract until the proposal expires, is rejected or is approved by Assembly voters. In case the proposal is rejected, the deposited xASTRO will be confiscated
  • title: The title of the AIP. It must start with "AIP-" and the number of the AIP which was assigned by an AIP Editor. The AIP title must be maximum 64 characters long
  • description: A condensed description of the AIP, taken from the submitted (and associated) ARC on the community forum. The description: Must be maximum 1024 characters long
  • link: A link to the associated ARC posted on the community forum. The link must be maximum 128 characters long
  • messages: The AIP payload that defines which contracts and parameters the AIP is meant to change

Resubmission​

An AIP can be resubmitted for an on-chain vote up to 3 times without having to go through phases 1-4 again if it failed to pass due to legitimate external reasons (e.g., potential low governance participation that did not meet the minimum on-chain quorum).

A rejected AIP can be resubmitted.

Other AIP Statuses​

  • Withdrawn: Assigned when an AIP Author withdraws their AIP proposal.

An AIP may be withdrawn at any point before it enters an on-chain vote. Note that a withdrawn proposal can be taken over from the original Author with a simple transition facilitated by an AIP Editor and the respective parties. If the original AIP Author abandons their efforts or becomes unreachable, an AIP Editor may proceed with the transfer of authorship.

  • Deferred: Assigned when a proposal has been deemed as not ready or not a priority but can be re-proposed at a later date. This status can be assigned during ARC or by a rejecting forum poll or Signal Request.

  • Obsolete: Assigned when:

    • An AIP has been superseded or deprecated.
    • An AIP has been deferred for over six months.
    • An AIP Author has abandoned the proposal and no person has communicated willingness to take over the responsibility of an AIP Author.