Kwenta State Log

A living document defining the state of Kwenta

Kwenta State Log

Kwenta Improvement Proposals

1. State Log Purpose and Guidelines

Table of Content

  1. KIP Workflow
  2. How to publish your KIP draft
  3. KIP Template
  4. KIP Editor Responsibilities
  5. CKIPs and KTRs
  6. KIP Completion Incentives

The Kwenta State Log (KSL) is a living document which defines the state of Kwenta. Amendments and additions can be made to the KSL via a Kwenta Improvement Proposal (KIP).

The adminDAO is responsible for overseeing the management of the KSL; this includes collaborating with community members to issue new KIPs as well as identifying when a KIP proposal has been completed and is therefore eligible for completion incentives.

Community members can draft KIPs to propose new features, collect community input on an issue, and document changes to the Kwenta State Log. The KIP author is responsible for communicating what the net improvement of the KIP is, building consensus within the community, and documenting dissenting opinions.

KIP Workflow

Parties involved in the KIP process are: (1) the author, (2) the KIP editors, (3) the Kwenta Council, and (4) the Kwenta community.

Before an author begins, they should conduct informal due diligence on their idea. It is recommended that a KIP contains a single key proposal or new idea. The more focused the KIP is, the more likely it is to be successful. Before bringing a KIP, the author should perform proper due diligence, which includes asking the Kwenta community if the idea in the KIP is original. This process avoids wasting the DAO’s time on an idea that will be summarily rejected as redundant. This due diligence process also helps to make sure that the proposal is applicable to the entire community and not just the author. The appropriate public forum to gauge interest around a KIP is the Kwenta Discord.

Once due diligence has been conducted, the author should write the KIP in the format described below. This format is designed to use community input to refine a KIP from inception to approval. The KIP will move through multiple stages of editing, as follows:

First, the author of a KIP will publish a draft proposal. Once published, the author should make the proposal known by posting it in the “KIP Discussion” thread on discord. The adminDAO will then assign a “KIP Editor” to review the proposal. [The Editor will be a Kwenta contributor who is familiar with the KIP process and can shepard the proposal through the process.] The Editor’s responsibilities are outlined below.

Once a draft KIP has been published, the assigned Editor requests that the status of the KIP be changed to “Proposed”. Once a KIP is Proposed, it is scheduled for voting by the Kwenta Council.

Each status change is requested by the KIP author and reviewed by the KIP editors. Make the request known in the respective KIP discussion thread on Discord. The KIP editors will process these requests as per the conditions below:

  • draft: This KIP is a work-in-progress.
  • proposed: This KIP is scheduled for voting by the Kwenta Council.
  • approved: This KIP has passed community governance and is now being prioritized for development.
  • rejected: This KIP has failed to reach community consensus.
  • implemented: This KIP has been implemented.

The adminDAO determines the status of a KIP.

During implementation the Core Contributors undergo a feasibility period where decisions around implementation may affect the underlying proposal. Minor, non-conflicting adjustments can be made at the Core Contributors discretion however adjustments that require a material change to the outcome of the proposal will be brought to the attention of the Kwenta Council and Author for further decision making.

How to publish your KIP draft

Non-technical track

Use the kip-0 template to construct your proposal. Publish your proposal by opening a new thread in the #new-kips forum in the Kwenta Discord. Make sure you name the thread “KIP: title”, with title being the current draft title of your KIP.

Use Google Docs, Riseup Pad or other secure online solutions to write your KIP draft. Never share document files in Discord.

The adminDAO will schedule a time for you to present your proposal over a voice call with the community once it has been discussed in Discord. The adminDAO will update the status of your proposal in the repository after which it will be voted on by the Kwenta Council.

Technical track

Use the kip-0 template to construct your proposal. Submit a patch including your proposal to the KSL repository (this will accelerate bringing the proposal to the voting phase) and share it with the community for discussion by opening a new thread in the #new-kips forum in the Kwenta Discord. Make sure you name the thread “KIP: title”, with title being the current draft title of your KIP.

The adminDAO will schedule a time for you to present your proposal over a voice call with the community once it has been discussed in Discord. The adminDAO will update the status of your proposal in the repository after which it will be voted on by the Kwenta Council.

KIP Template

Each draft KIP must use the KIP template, which can be found in the repository file kip-0. All KIPs should be written in markdown format. Image files should be included as additional files named kip-x-image-1.png etc. A KIP will not be moved to the voting phase if it fails to follow the proposal structure. A similar template exists for KTRs and CKIPs.

KIP Editor Responsibilities

A KIP editor will be assigned by the adminDAO. This is typically an individual with a thorough understanding of the administrative processes within Kwenta. Editors can be anyone from the community.

For each new KIP that comes in, an editor does the following:

  • Read the KIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status
  • The title should accurately describe the content.
  • Check the KIP and correct language (spelling, grammar, sentence structure, etc.), markup (Radicle flavored Markdown), code style if necessary

If the KIP isn't ready, the editor will send it back to the author for revision, with specific instructions. Once the KIP is ready for the repository, the KIP editor will:

  • Assign a KIP number
  • Merge the corresponding patch or upload KIP to repository
  • Send a message back to the KIP author with the next steps.

Editors don't pass judgment on KIPs and shall not alter the purpose of a KIP. They merely do the administrative & editorial part.

CKIPs and KTRs

Community Kwenta Improvement Proposal

CKIPs are proposals that can overrule the Kwenta Council in case the EC acts malicious and are implemented in the event that Kwenta token holders vote on a CKIP and reach quorum where over 50% of the token holders (this includes the circulating supply and therefore tokens not held by the treasury) agree to pass the proposal. CKIPs follow an identical flow to KIPs but are labeled differently and are voted on directly by token holders. Please use the CKIP template.

Examples of CKIPs:

  • EC acts malicious
  • Community significantly disagrees with a KIP voted into action by EC.

Kwenta Treasury Request

KTRs are proposals directed to the treasuryDAO or adminDAO which dictate how the treasury is used. These proposals follow a similar flow to KIPs but have a different template which includes a summary statement, request outline, information about where the funds should be sent if applicable, and a rationale behind the request. The KTR request template can be found in the radicle repository. The treasuryDAO holds the right to manage the treasury as they see fit however due the semi-anonymous nature of the treasuryDAO KTRs act as a way for the general public to make requests and suggestions to the treasury.

KTR requests once approved are to be added to the KTR requests table for future reference of the KSL by the KIP editors.

KIP Completion Incentives

Authors of KIPs are eligible for KWENTA rewards for having KIPs implemented. Once a KIP reaches the implemented stage, the adminDAO will classify the KIP into one of three rewards brackets. In the event there are multiple authors, the reward will be distributed evenly across the authors (Ex. A KIP with two authors would be split 50/50 unless otherwise specified).

  • Small impact: 500 USD worth of KWENTA. This reward would be given to authors that implement a minor change to the protocol such as a parameter change, a small process change, or a small mechanism change to the product. Note that cosmetic product changes can be processed through the Kwenta product feedback session in the community which includes separate rewards.
  • Medium impact: 1000 USD worth of KWENTA. This reward would be given to authors that implement a moderate change to the protocol such as multiple parameter changes, complex process changes, and new feature proposals.
  • Large impact: 2000 USD worth of KWENTA. This reward would be given to authors that implement a major change to the protocol such as substantial governance framework changes, new complex features, and changes that result in a material benefit to the DAO.
  • Custom package: For larger KIPs that require extensive involvement, the adminDAO may manufacture a custom rewards package that suits the KIP.

All KWENTA rewards will follow the same vesting model as inflationary rewards. CKIPs and KTRs do not apply to this rewards program.