KIPs
Kaia Improvement Proposals (KIPs) describe standards for the Kaia platform, including core protocol specifications, client APIs, and contract standards.
Contributing
- Review KIP-1.
- Fork the repository by clicking "Fork" in the top right.
- Add your KIP to the forked repository. There is a template KIP here.
- Submit a Pull Request to Kaia's KIPs repository.
KIP status terms
- Idea - An idea that is pre-draft. This is not tracked within the KIP Repository.
- Draft - a KIP that is undergoing rapid iteration and changes.
- Last Call - a KIP that is done with its initial iteration and ready for review by a wide audience for two weeks.
- Accepted - a KIP that has been in ‘Last Call’ for at least 2 weeks, any technical changes that were requested have been addressed by the author, and finally get approved by the Kaia core developers.
- Final - a KIP that has been released as a standard specification. If a Core KIP is in ‘Final’, its implementation has been included in at least one Kaia client.
KIP Types
KIPs are separated into a number of types, and each has its own list of KIPs.
Standard Track (18)
Describes any change that affects most or all Kaia implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Kaia. Furthermore Standard KIPs can be broken down into the following categories.
Core (10)
Improvements requiring a consensus fork as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, it may be an algorithm for testnets as well).
Networking (0)
Includes improvements around devp2p and Light Kaia Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.
Storage (0)
Includes improvements related to Storage.
Interface (2)
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before a KIP is submitted to the KIPs repository.
KCT (3)
Application-level standards and conventions, including contract standards such as token standards (KIP-7), name registries, URI schemes, library/package formats, and account abstraction.
SDK (1)
Includes improvements related to SDKs.
Application (2)
Includes improvements related to Applications.
Meta (1)
Describes a process surrounding Kaia or proposes a change to (or an event in) a process. Process KIPs are like Standards Track KIPs but apply to areas other than the Kaia protocol itself. They may propose an implementation, but not to Kaia's codebase; they often require community consensus; unlike Informational KIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Kaia development. Any meta-KIP is also considered a Process KIP.
Informational (0)
Describes a Kaia design issue, or provides general guidelines or information to the Kaia community, but does not propose a new feature. Informational KIPs do not necessarily represent Kaia community consensus or a recommendation, so users and implementers are free to ignore Informational KIPs or follow their advice.
Kaia KIPs Last Call Review
All KIPs which are in the two-week "last call" status, please help review these and provide your feedback!
N/A