Libra Improvement Proposals (LIPs) offer the Libra developer community a way to participate in advancing the features and functioning of the Libra payment network (LPN), either by proposing a change or engaging in discussion about a proposal.

Soon after a full Libra specification is posted to libra.org as the root standard LIP, proposals that address the core Libra Blockchain protocol, the Move development platform, smart contracts and systems for smart-contract verification, operating standards, APIs, and off-chain mechanisms can be addressed with a LIP. The LIP itself is the design document that describes the proposed change or new feature. As a text file maintained in a versioned repository, it serves as the historical record of decisions made during the approval process.

The LIP program operates under the governance of the Libra Association, with technical decisions supervised by the Association’s Technical Steering Committee (TSC). Day-to-day technical decisions are made using a framework inspired by standards bodies (such as the W3C and IETF) and open source projects (such as Python, the Linux Foundation, and Apache) to coordinate the work of open source contributors.

This process is based on the family of approaches derived from Python’s PEP process. It is supported by a team of Maintainers who are assigned individually to serve as the LIP Manager on an active LIP and who work to build consensus among Libra community members about technical decisions. Additionally, LIP matters are routinely discussed by the Lead Maintainer with the TSC.

#LIP types

There are three types of LIP:

• Standard LIPs describe any change or addition that affects LPN, such as a change to the Libra Blockchain protocol, a change to transaction processing, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using LPN.

• Process LIPs describe the governance procedures and tools of the Libra project, such as the LIP procedure itself, GitHub plug-ins, and other development tools and guidelines.

• Informational LIPs describe a Libra project design issue, or provide general guidelines or information to the Libra community, but do not propose a material change or addition to LPN. Informational LIPs do not necessarily represent Libra community consensus or a recommendation, so users and implementers are free to ignore Informational LIPs or follow their advice.

#The LIP process

Parties involved in the process are the LIP author(s) and a designated LIP Manager. The Lead Maintainer shall act as the primary LIP Manager and can appoint at any time a delegate Manager to specific LIPs.

The formal LIP process will typically (and advisably) begin after the champion of the proposal has already discussed and socialized it with the Libra community (see below for what goes into a LIP). It is comprised of the following steps:

• Idea – Authors will socialize their idea with the developer community and Maintainers, possibly by writing a GitHub Issue and getting feedback. If possible (and relevant), authors should include in discussions an implementation to support their proposal.

  Once the discussion reaches a mature point, the formal LIP process starts with a pull-request to the libra/lips folder. The status field of the document should be “Draft” at this point. A LIP Manager will review/comment/approve/deny the pull-request.

  • Draft – If agreeable, LIP Manager will assign the LIP a number (generally the issue or PR number related to the LIP, and ask to rename or move to a folder/file with that number) and approve the pull request. The LIP Manager will not unreasonably deny a LIP.
  • Draft – Reasons for denying Draft status include misalignment with Libra mission or Association policy, being too unfocused, too broad, duplication of effort, being technically unjustified, not providing proper motivation, or not addressing backwards compatibility. The Authors can work to refine and resubmit their LIP Idea for review again.

• Draft – After the draft is merged, additional changes may be submitted via pull requests. When a LIP appears to be completed and stable, Authors may ask to change the status to Last Call.

  • Last Call – If agreeable, the LIP Manager will approve the Last Call status and set a reasonable amount of time (usually 2-4 weeks) for a final review. Additional time can be granted by the LIP Manager if requested.
  • Last Call – A request for Last Call will be denied if material changes are still needed for the draft. LIPs should only be promoted to Last Call once.

• Last Call - This LIP will be listed prominently on the Libra public Discourse under the LIP category. The final status change by the LIP Manager will be either Accepted or Rejected.

  • Accepted – A successful Last Call without any material changes or unaddressed technical complaints will become Accepted. This status signals that material changes are unlikely and Libra Maintainers should support driving this LIP for inclusion.
  • Rejected – The Maintainers can decide to mark this LIP as Rejected at their discretion, e.g., a major, but uncorrectable, flaw was found in the LIP.

• Accepted - A LIP in the Accepted state means the TSC has determined it is ready for active implementation

  • Final – LIP is deployed to mainnet. When the implementation is complete and deployed to mainnet the status will be changed to “Final”.
  • Draft – If new information becomes available an Accepted LIP can be moved back into Draft status for necessary changes.
  • Deprecated – The LIP Manager or Maintainers may mark a LIP Deprecated if it is superseded by a later proposal or otherwise becomes irrelevant.

• Final – The Final state of a LIP means the necessary implementations of the LIP are complete and deployed to the codebase. This LIP represents the current state-of-the-art. A Final LIP should only be updated to correct errata.

A LIP may refer to related/dependent LIPs. Every LIP will be assigned a status tag as it evolves. At every stage there can be multiple revisions/reviews until the next stage.

#What goes into a LIP

The following is a summary of what each LIP should include. For an example LIP, see LIP 0. There is also a template to help you get started.

• Preamble - RFC 822 style headers containing metadata about the LIP, including the LIP number, a short descriptive title (limited to a maximum of 44 characters), and the author details.

• Simple Summary - Provide a simplified and layman-accessible explanation of the LIP.

• Abstract - a short (~200 word) description of the technical issue being addressed.

• Motivation (*optional) - The motivation is critical for LIPs that want to change the Libra protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the LIP solves. LIP submissions without sufficient motivation may be rejected outright.

• Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations of the Libra protocol or any other Libra platforms that may emerge.

• Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g., how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.

• Backwards Compatibility - All LIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The LIP must explain how the author proposes to deal with these incompatibilities. LIP submissions without a sufficient backwards compatibility treatise may be rejected outright.

• Test Cases - Test cases for an implementation are mandatory for LIPs that are affecting consensus changes. Other LIPs can choose to include links to test cases if applicable.

• Implementations - The implementations must be completed before any LIP is given status “Final,” but it need not be completed before the LIP is merged as draft. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.

• Copyright Waiver – All LIPs must be in the public domain. Please use the copyright notice featured at the bottom of this page.