Skip to content

Latest commit

 

History

History
139 lines (93 loc) · 3.95 KB

kip-0001.md

File metadata and controls

139 lines (93 loc) · 3.95 KB
Raw
KIP Title Author Status Type Category Created
1
KIP process
Stuart Popejoy stuart@kadena.io
Draft
Process
2019-01-25

Abstract

Document the KIP process and ontology.

Specification

KIPs describe an improvement to the Kadena Public ecosystem including Chainweb and Pact.

KIP statuses

Draft ------+-> Final/Active --+-> Replaced
 | ^        |                  |
 | |        +-> Rejected       +-> Obsolete
 | |        |
Deferred    +-> Withdrawn

Draft

A new KIP, in PR or an accepted PR that is still being debated.

Deferred, Rejected, Withdrawn

Statuses that indicate a KIP has stopped, either for being too soon (Deferred), unacceptable (Rejected), or removed by the author (Withdrawn).

Final, Active

Final indicates KIP has successfully completed but not necessarily rolled-out.

Active indicates KIP does not need to be finalized (ie is an ongoing discussion, like this KIP).

Replaced, Obsolete

Indicators that a previously-final KIP has been superseded by a later KIP (Replaced) or no longer applies (Obsolete).

Comparison to BIP, EIP

Status BIP EIP KIP
Draft x x x
Deferred x x x
Proposed x
Rejected x x x
Withdrawn x x
Final x x x
Active x x x
Replaced x x
Obsolete x x
WIP x
Last Call x
Accepted x

KIP Types

Standard

A "standards track" KIP indicating some kind of concrete implementation with a specification.

Process

Describes a process, like this KIP.

Informational

Guidelines, general issues or information for the community.

KIP Categories

"Category" is borrowed from EIPs and corresponds to "Layer" in BIP (see https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki regarding BIP layers).

Category is only for Standard types.

Chainweb (Soft or Hard Fork)

Core change to Chainweb consensus

P2P/Networking

Core change to Chainweb P2P or networking services

API

API/interface layer for interop/clients with Chainweb

Pact

Changes to the Pact smart contract language that particularly impact a protocol

Interfaces

Changes to or new interfaces in Pact to define smart contract interop.

KIP Header

  • kip: KIP-xxxx

  • title: TBD by author

  • author: Author(s) name and email addy.

  • discussion: Optional URL of external discussion.

  • status: See above

  • type: See above

  • category: See above

  • created: create date YYYY-MM-DD

  • requires: KIP number(s)

  • replaces: KIP number(s)

  • superseded-by: KIP number(s)

KIP Sections:

This more or less copies the BIP section layout.

  • Header: see above
  • Abstract: <200 word summary.
  • Specification: The technical specification should describe the syntax and semantics of any new feature.
  • Motivation: should clearly explain why the existing specification is inadequate to address the problem that the KIP solves.
  • 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. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
  • Backwards Compatibility: All KIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The KIP must explain how the author proposes to deal with these incompatibilities.
  • Reference Implementation: Ideally a reference implementation will precede acceptance/final status, but this depends on the nature of the improvement. If appropriate, code can be part of the KIP.

References