About HIPs

    HIPs Home

    Hedera Hashgraph logo

    Discord Chat GitHub forks

    What is a HIP?

    HIP stands for "Hedera Improvement Proposal". These improvement proposals can range from core protocol changes, to the applications, frameworks, and protocols built on top of the Hedera public network and used by the community. The HIP author is responsible for building consensus within the community and documenting dissenting opinions, as well as tracking their HIP through the process outlined below.

    What is Hedera Hashgraph?

    Hedera Hashgraph is the only public network built on top of Dr. Leemon Baird’s Hashgraph consensus algorithm. Hedera goes beyond blockchain to provide the fast, fair, and secure environment needed to enable enterprise adoption of distributed ledger technologies. You can learn more about Hedera by reading the Hedera whitepaper, and for a more detailed understanding of the Hashgraph Consensus Algorithm you can check out the hashgraph algorithm whitepaper.

    Purpose

    The goal of HIPs is to have a place to propose new features, to collect community thoughts and input on a particular issue, and further to document all these subject matters in one place. It’s a great way to document these discussions and proposals here on GitHub, because any revisions made on these text files will be recorded.

    Process

    See HIP-1 for details on the HIP process.

    Qualifications

    Each HIP should only be one single key proposal and/or idea. The idea should be focused and only issue to one subject matter to be successful. A HIP must meet certain minimum criteria: it must be clear and have a complete description of the proposed enhancement, the enhancement must represent a net improvement, the proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

    HIP Types

    There are three kinds of HIP:

    1. A Standards Track HIP describes a new feature or implementation for Hedera. It may also describe an interoperability standard that will be supported outside of the official Hedera node software stack. The Standards Track HIP abstract should include which part of the Hedera ecosystem it addresses. Standards Track HIPs require a specification and a reference implementation:
      1. Core: This includes proposals addressing the Hashgraph algorithm, peer-to-peer networking, etc. These types of features are implemented on Hedera consensus nodes.
      2. Service: Hedera services sit on top of the Core node software and provide the functionalities that are accessed by users. These currently include the File Service, Consensus Service, Token Service, and Smart Contract Service. This type of proposal should be used to add to or improve the service-layer of Hedera. These types of features are implemented on Hedera consensus nodes.
      3. Mirror: A mirror node runs software designed to retrieve all, or some of the records generated by the Hedera consensus nodes and make those records available to users in a way that is meaningful, reliable, and trustworthy.
      4. Application: Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract validators, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust.
    2. An Informational HIP describes a Hedera design issue, or provides general guidelines or information to the Hedera community, but does not propose a new feature. Informational HIPs do not necessarily represent a Hedera community consensus or recommendation, so users and implementers are free to ignore Informational HIPs or follow their direction.
    3. A Process HIP describes a process surrounding Hedera, or proposes a change to a process. Process HIPs are like Standards Track HIPs but apply to areas other than the node and ecosystem software codebases. They may propose an implementation, but not to Hedera's codebase; they often require community consensus; unlike Informational HIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, and changes to the decision-making process. Any meta-HIP is also considered a Process HIP.

    Before Submitting

    1. Evaluate your idea: consider why you’d like to request changes or improvements, and how it benefits the Hedera Hashgraph community.

    2. Thoroughly look through those proposals already submitted to ensure there are no duplicates.

    3. Ask the Hedera Hashgraph community first if your idea is original, or has already been through the HIP process.

    4. Reevaluate your proposal to ensure sure the idea is applicable to the entire community and not just to one particular author, application, project, or protocol.

    Note

    An excellent place to discuss your proposal and get feedback is in the issues section of this repository, or on Hedera's Discord Server; there you can start formalizing the language around your HIP and ensuring it has broad community support.