KIP-0 KeeperDAO Governance

KIP0: KeeperDAO Governance

kip: 0
title: KeeperDAO Governance
author: hazard <>
status: draft
tags: none
created: 2021-09-02
replaced-by: none
replaces: none



KIP-0 defines a simple format for writing KeeperDAO improvement proposals (KIPs), and illustrates how a KIP goes from idea to reality, through consensus. Finally, it defines governance helpers called Sophons that coordinate the governance process.


Proposals, and the process they go through in order to reach consensus, are two of the most basic elements of DAO governance. As a DAO, one of our primary missions is to enable as many people as possible to join, contribute, and add value, and that begins with setting up a basic set of expectations for how governance operates.


Adopt the specified guidelines below, defining the KeeperDAO governance.


KeeperDAO improvement proposals

What is a KIP?

A KIP is a proposal that an author or group of authors would like to be evaluated by the members of KeeperDAO. The members of KeeperDAO shall work with the author of a KIP to review and refine its content, before using an agreed-upon consensus procedure to collectively determine whether to adopt or decline the final proposal.

Minimum style requirements

A KIP should be written in plain language, formatted as Markdown. It should clearly and completely describe the proposal, its motivations, and why the author believes it improves the status quo. Where applicable, it should also describe a set of steps to enact the proposal. Authors and editors should work together to ensure that the KIP meets at least the following minimum style requirements:

  • Consistency: Does it contradict itself or any other non-historical KIP?
  • Accuracy: Are its data, arguments, and understanding of systems complete, accurate, and up-to-date?
  • Feasibility: Does it propose or require things that are impossible ot impractical to accomplish?
  • Verifiability: Can anyone verify for themselves that an implemention did occur in the way described by the KIP?


KIPs form an archival series, meaning that each KIP has a unique archival serial number, and is not able to have its essential content changed once it has become finalized. At the top of every KIP is a header which contains metadata that editors can use to help organize the governance record.

  • kip The proposal number, for example, 0.
  • use (Optional) The name of the proposal template being used.
  • author A list of author names (or usernames if anonymous), along with e-mail addresses or another way to contact them.
  • status Proposals have a status, one of the following set: draft, review, last-call, final
  • tags Comma-separated list of tags from the set accepted, rejected, implemented, withdrawn, historical.
  • created Date that the proposal was created. Should be in ISO 8601 format (YYYY-MM-DD).
  • replaced-by (Optional) KIP that replaces the KIP.
  • replaces (Optional) Comma-separated list of KIPs that the KIP replaces.

These fields and their values may be changed in the governance repository without the need for a new consensus, as long as the change is recorded in the repository and carried out by those delegated to do so.

Governance lifecycle

  1. Author posts KIP draft on forum

    1. When a new KIP appears on the forum, a notification and summary shall be posted to a relevant channel.
  2. Crowd Consensus

    1. The author shall allow sufficient time for, and make a best effort to reach, rough consensus with the community about the content of the draft proposal.
    2. When the author determines that rough consensus has been reached, the author shall communicate their intention to submit the proposal to the governance record for review.
    3. The author shall make a best effort to allow sufficient time for all interested parties to post final comments on the draft before formal submission.
  3. Merge to Git repository

    1. The author shall open a pull request to the governance repository, aided by a Sophon if necessary.
    2. A Sophon shall add the header fields to the KIP, and mark its status as draft, before merging it.
  4. Sophon Consensus

    1. Sophons shall maintain a public queue of the merged KIPs to be reviewed. This queue shall be ordered chronologically according to the date of the git merge.
    2. Sophons must make a best effort to review each KIP in order, and acheive rough consensus.
    3. When a KIP enters review, a Sophon shall change the KIP status from draft to review.
      1. During review, Sophons shall make a best effort to conduct their deliberations in public and record minutes, as well as be available for public feedback.
      2. If Sophons cannot reach rough consensus, the proposal will return to draft status.
      3. Otherwise, the Sophons will assign the KIP a voting period and change its status from review to last-call.
  5. Last call period

    1. Sophons and the KIP author shall make efforts to notify interested parties, allow sufficient time to facilitate discussion, and uncover any remaining objection or correction to the proposal before objection voting begins.
  6. Objection Voting

    1. Objection voting shall run for a minimum of 7 days, except for matters which present a clear, imminent danger to users, protocols, or the DAO.
    2. The vote shall have two options, ‘Present’ and ‘Object’, and shall include a prominent message explaining the difference between apparent consensus and majority voting.
    3. Best effort shall be made to notify interested parties about the objection vote once it is live.
  7. Ratification

    1. If enough tokens select the ‘Object’ option at the close of the vote, the KIP does not have tokenholder consensus, and it returns to draft status. If there is a non-zero quorum requirement, and not enough tokens have selected the ‘No objection’ option, then the proposal is returned to draft status. Otherwise, the proposal is assigned final status.
    2. The result of the vote shall be communicated via Discord and Twitter.


Sophons are individuals empowered by the DAO to review, analyze, and publish non-binding recommendations on KIPs. They should “speak for the protocol,” rather than their own interests, and be knowledgeable about the subjects being considered.

Their role is to ensure that every KIP has been given adequate attention before it is put in front of tokenholders for a vote, and that tokenholders are provided with the opinion of qualified stakeholders in case they cannot judge for themselves.

Sophon onboarding process

This section defines a process for onboarding one or more Sophons.

Use the template located at

Sophon offboarding process

This section defines a process for offboarding one or more Sophons.

Use the template located at


I support this proposal

1 Like

I support this structure

I support this proposal

What exactly does this mean? Can you elaborate? Changing a KIP shouldn’t be difficult as long as it is in a draft or pre-draft status. Once accepted/rejected, a KIP should be immutable.

Ah, this was intended to be after the draft had been finalized, i.e. changes after ratification.

Immutability is the ideal, but there could always be things that need to be changed in a backwards-compatible way. The idea would be to provide a process where these changes are made (and voted on), so they’re still part of the governance process, but the original KIP keeps its number.

This would only be for backwards-compatible things like

  • Correcting spelling, formatting, or grammar mistakes (these should be caught during review but mistakes happen)
  • Updating links
  • Additional sections or subsections [without altering the old]
  • Maybe non-textual amendments?

This is an open question though. It’s certainly also possible to say:

  • All KIPs are immutable after ratification
  • Later KIPs that want to modify previous KIPs should simply refer to the KIP being modified in their header (that way you can do book-keeping).
  • Review stuff harder

Benefits of altering the original are:

  • Familiar KIP numbers
  • Easier to iterate without feeling like it’s your last chance and it has to be perfect, increasing velocity perhaps

FWIW, the United States and for what I know most governments get around this by having two separate bodies of documentation – the bills and statues that actually get passed, which work a lot like immutable KIPs would, just a stream of numbered proposals that get ratified. Then they have a “Code”, which is a big living document that compiles all the relevant statutes into an easier-to-reference categorized document.

I think this gets the best of both worlds, so maybe we work on a “Code” (maybe a Wiki or something) down the line, and we do immutable KIPs until we need that. Also a thought. Lots of thoughts!

1 Like

Ah ok. Would it make sense to maybe define in this KIP what updates the sophons can do without community input (e.g., fixing typos, updating links, minor stuff) and what updates require to actually downgrade the status of the KIP to (pre-)draft and go through all steps of the governance process? E.g., changing the governance process itself, allocating resources to certain projects, anything code-related.

Yeah my thought is that Sophons can’t do any updates without community approval. But maybe they should be allowed to do spelling mistakes and errata as PRs just for the sake of velocity?

1 Like

Yeah, I’m not sure. I certainly understand why the sophons should not be able to modify anything without community approval. But it also seems a bit of an overkill to ask the community every time we want to fix a typo. :slight_smile: I don’t feel strongly about either option, just suggesting stuff.

Okay everybody, I removed a lot to slim it down and give us the chance to discover what we really need in the future. I spent (way too much) time making and re-making various ways to do this, and it seems like simple is best to start. Once we know more about what we need and what our work patterns are, and we can build off of that, rather than trying to hit a bullseye on the first shot. That’s my thinking right now at least.


Support the proposal.

As we discussed in our governance community call, this has been re-opened for comment and roundtable discussion before we review and vote.