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 4 types, and each has its own list of KIPs.
Core (17)
A Core KIP describes any change that affects Kaia protocol implementations, such as a change to the network protocol, an improvement in block or transaction validity rules, an improvement in storage-layer mechanism, an improvement in interface around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs, any change in Kaia’s tokenomics-related settings and financial parameters, or any change in GC block reward mechanism, etc. Core KIP would be seen requiring a consensus fork as well as changes that are not necessarily consensus critical but may be relevant to any core-related development. Core KIPs consist of two parts, a design document and implementation.
Ecosystem (2)
An Ecosystem KIP describes any change falling under the broad category of ecosystem features, tools or environment used in Kaia development, such as a change on application layer related to proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Kaia, or a change in SDK layer related to application-level standards and conventions, such as name registries, URI schemes, library/package formats, and wallet formats, or an introduction of new ecosystem tool that could be integrated to the Kaia chain with implementation know-hows, or an introduction of contract standards that would introduce ecosystem features, etc.
Tokenization (4)
A Tokenization KIP describes any change or introduction related to Kaia compatible tokens, such as an introduction of purpose-driven fungible token or non-fungible token and its minting policies in general.
Meta (2)
A Meta KIP describes a process surrounding Kaia or proposes a change to (or an event in) a process. Meta KIPs apply to areas other than the KIPs listed above. Examples include procedures, guidelines, and changes to the decision-making process. Any Meta KIP is also considered a Process KIP.
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