Pearl Improvement Proposals
Pearl Improvement Proposals (PIPs) describe standards for the Pearl network, including core protocol specifications, networking and interface conventions, application-level standards, and the processes that govern Pearl development. A PIP is a short, focused document that describes a single change, explains its motivation, and specifies it precisely enough to implement.
Browse all proposals, or by category and type from the header. A PIP published here is in scope and well-formed; that does not by itself indicate community consensus or imminent adoption.
Contributing
First review PIP-1,
which defines the process and document format. Then fork the
repository, copy
the template to
PIPS/pip-9999.md, and submit a pull request. The
contributing guide lists the
checks CI runs against every submission.
PIP status terms
- Draft
- Under active editing by its author(s); merged so it has a stable number, but not final.
- Proposed
- Feature-complete and open for broader community review.
- Active
- An ongoing process or guideline (Process and Informational PIPs only).
- Final
- An accepted Standards Track change that has been deployed.
- Withdrawn
- Withdrawn by its author(s).
- Rejected
- Formally rejected; will not be pursued in its current form.
- Replaced
- Obsoleted by a later PIP, named in its
superseded-byfield. - Obsolete
- No longer in use; preserved for historical record.
PIP types
PIPs are separated into a number of types, and each has its own list of PIPs.
Standards Track (2)
Describes any change that affects most or all Pearl implementations, or any change or addition that affects the interoperability of Pearl software. Standards Track PIPs are further broken down into categories:
- Consensus (2) - changes that require a hard or soft fork.
- Networking (0) - peer-to-peer protocols, message formats, and relay rules that do not change consensus.
- Interface (0) - client APIs, RPC schemas, and other interfaces used by external software.
- Applications (0) - application-level standards: address formats, key derivation, signing protocols, URI schemes.
Process (1)
Describes a process surrounding Pearl, or proposes a change to one. Process PIPs apply to areas outside the Pearl protocol itself and may not be ignored.
Informational (0)
Provides general guidelines or background information to the Pearl community, but does not propose a new feature. Implementers are free to ignore Informational PIPs.