About HIPs

    HIPs Home

    Hiero logo

    Hedera Discord Chat LFDT Discord Chat GitHub forks

    What is a HIP?

    HIP stands for “Hiero Improvement Proposal.” These proposals can range from core protocol changes to applications, frameworks, or protocols built on top of Hiero’s open-source ledger code. The HIP author is responsible for building consensus within the community, documenting dissenting opinions, and tracking their HIP through the process outlined below.

    What is the Hashgraph Algorithm?

    The hashgraph consensus algorithm was created by Dr. Leemon Baird. Originally, Hedera was a public network built on top of this algorithm; later, Hedera donated its codebase to the open-source Linux Foundation project now known as Hiero. You can learn more by reading the hashgraph algorithm whitepaper.

    Purpose

    The goal of HIPs is to have a transparent, collaborative place to propose new features, collect community input on a particular issue, and document proposals and reasoning in one place. Publishing these proposals on GitHub means every revision is recorded in version history.

    Process

    See HIP-1 for details on the current HIP process.

    Qualifications

    Each HIP should outline a single key proposal or idea, kept focused to a single subject for clarity. A HIP must meet certain minimum criteria: it must be clearly written, describe the proposed enhancement completely, represent a net improvement, and (if applicable) include a solid reference implementation that does not unduly complicate the network.

    HIP Types

    There are three kinds of HIP:

    1. Standards Track — describes a new feature or interoperability standard for the Hiero ecosystem. It requires both a specification and a reference implementation:
      1. Core: Proposals addressing the hashgraph algorithm, peer-to-peer networking, etc. These features are implemented in the Hiero consensus nodes.
      2. Service: These run on top of the core node software and provide functionalities (e.g., file, messaging, token, or contract services). Proposals here refine or add to Hiero’s service layer.
      3. Mirror: A mirror node runs software designed to retrieve all, or some, of the records generated by the consensus nodes and makes them available in a meaningful way.
      4. Application: Application standards may be used to standardize additional ecosystem software (e.g., external contract nodes, multi-sig oracles, enterprise plugins). An example might be a stablecoin or NFT contract that relies on the Hiero consensus for trust.
    2. Informational — describes a design issue or general guidelines, but does not propose a new feature. These do not necessarily represent consensus recommendations and can be followed or ignored.
    3. Process — describes or proposes changes to processes for the Hiero community. These often require community consensus and are not purely recommendations. Any meta-HIP is 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 broader Hiero community.

    2. Check existing proposals to ensure there are no duplicates.

    3. Discuss the idea with the Hiero community (for example, on Hedera’s Discord or LFDT's Discord) to confirm whether it’s original or if it’s been addressed before.

    4. Reevaluate your proposal to make sure it is generally applicable and not limited to a single project or narrow use case.

    Note

    An excellent place to discuss your proposal and get feedback is in the issues section of this repository or on Hedera’s Discord or on LFDT's Discord. There, you can gather community input and refine the language around your HIP to ensure broad support.