Hiero HIP Process - Proposal and Discussion

[Reccetech]

This discussion covers improvements to the HIero HIP (Hiero Improvement Proposal) process.

Background:
The HIP process has recently moved from the Hashgraph repo to Hiero. As part of the move to Hiero we have added a step where the Hiero TSC approves HIPs. With these changes this proposal explores some improvements to the HIP flow, and explores questions specific to HIPs within Hiero.

Problem Statement:
In the current HIP process as shown in the below diagram there is the expectation that the HIP presented to the TSC for approval in Step 2 contains the complete technical specification. However, in practice creating a full and accurate technical specification takes time, and is often only finalized as we go through the development process and testing. The end result that we are seeing is that often when the HIP is finalized, and then we get time in front of the TSC, much of the actual engineering work has already been completed. A great example of this would be the recently approved HIP-1056 (Blockstreams) where by the time we got TSC approval much of the core engineering work was already done. Obviously in an ideal world we would be bringing HIPs to the TSC before Engineering work had started.

Proposed Solution:
Per the below diagram it’s important to note that within the Hiero HIP process we actually have two places where approvals occur; Step 3 with the TSC approval, and then Step 7 where maintainers will review and approve a PR.
So our proposal. as seen in the below diagram, is that in Step 2 HIP authors provide all of the major components of the HIP template. The major delta from the process today is that the Step 2 HIP will provide a vetted High Level Design, but not a complete lower level detailed design/specification.
After the TSC has provided approval then the HIP authors will work out the detailed design, add it to the HIP, and begin engineering work ending in a PR to the relevant HIero repo. At that time in Step 7 the maintainers of the repo while reviewing the code will use the full Step 4 HIP in their review looking for adherence to the written design/specification. This change makes more sense when you consider that creating a detailed design takes a great deal of effort and time. So it would be painful if that time was invested just for the TSC to reject the HIP in Step 3.

Looking at the above process we can also try to address some questions about the HIP process raised in recent TSC meetings.

What is the role of the TSC HIP Approval?
In my mind the goals of the TSC HIP Approval in Stage 3 is confirming:

• The HIP aligns to the technical direction and goals of Hiero
• The HIP has does not threaten Hiero security models
• The feature/capability of the HIP are appropriate for the component it’s being proposed for. i.e. maybe a feature being proposed for consensus nodes really should be an Application HIP
• That the HIP document contains enough information and detail that will allow the community to understand and comment on the proposal.

The TSC approval in Step 3 then acts as a checkbox for Maintainers to approve PRs related to the HIP in Step 7. Visa Versa if a Hiero contributor proposes a major improvement directly in a PR - then the maintainers should see there is no approved HIP associated with the work, and can ask the contributor to provide a HIP for TSC approval before they can approve the PR.

What new features/capabilities need a HIP?
I feel that this is one of those questions akin to asking how long is a piece of string.
My suggestion is that we base this question on precedence. We have lots of examples of HIPs at hips.hedera.com covering a wide range of improvements that can be used as reference on what should be a HIP. If contributors still have confusion they are welcome to come to the TSC or to Hashgraph employees with questions to see if a specific proposal should be a HIP. Finally we always have the guardrail of Step 7, wherein if a PR has significant improvements that the maintainers feel need a HIP, then they can request a HIP be written and approved by TSC before they will approve the PR.

What is the role of the Application HIP?
Currently within the Hiero HIP process we have different types of HIPs. Under the Standards Track we have Core, Service, Mirror, and Application HIPs. As well we have Informational and Process HIPs. Currently work on SDKs falls within Application HIPs, and there is an active discussion if Application HIPs are still needed for major SDK improvements.
To answer this question I think we should examine the purpose of the HIP process. In my mind they are:

1. Provide a template and framework for contributors to describe a significant change or improvement to Hiero Networks. Having a template is key because it forces a HIP author to think about and cover the high level and low level elements needed for stakeholders to fully understand the proposal.
2. Provide a framework for the Hiero community to see in one place the proposals, raise questions, and provide input.
3. Provides a framework and process for governing Hiero authorities such as the TSC or Community groups to sign off on the proposal.
4. Provides a shorthand to talk about added features (i.e. HIP-991 was added to release 59. Please look at HIP-991 to learn more).

So if we believe that all 4 elements above are important then to me it makes sense we just leverage the HIP process instead of trying to invent something with a different name - but essentially does the same thing.

How do we increase the throughput of TSC HIP Approvals?
In the short time that the TSC has existed we have had trouble getting timely approvals on HIPs. This is of course in large part because the TSC/Hiero are new organizations and we have lots to talk about - but I think there will always be lots to talk about 🙂
I would like to suggest some improvements to help the TSC more efficiently approve HIPs. One problem we have faced is that often when a HIP is brought to the TSC the membership is seeing the HIP for the first time, so there are lots of questions, and it’s hard to get to a vote. Second, we have HIPs like HIP-1064 where there are lots of questions, and sometimes we don’t have the right people in the meeting to answer those questions.
So what I would like to propose is that we break HIP approvals into two meetings. In the first meeting that we’ll try to time box to around 10min - the HIP presenter can quickly introduce the HIP, and then provide the links. In the week that follows the TSC can read the HIP and leave questions in Github which the team can work to answer. Then in the 2nd meeting the HIP presenter can return and hopefully the TSC leadership understands the HIP, has had their questions answered, so the discussion can focus on whether it should be approved or denied ending with a vote.

Feedback and comments welcomed.

[may-hashpack]

• Regarding the process, I think it may be worth putting in a note between Step 1 and 2, or a footnote, guiding potential HIP authors to participate in Hiero Community calls to champion their HIP. This gives them a forum to receive feedback and maximize the success of their submission, and helps TSC and maintainers understand the context behind the HIPs that are submitted.

• Adding in Diane's comment from the TSC meeting on May 20, 2025, perhaps in the process, between (or as part of) step 2 and 3, adding in that two (or one) TSC members be auto-assigned to be responsible for a new HIP submission. As discussed, this will provide a clear feedback loop for contributors and give 'hope' that the HIP won't simply be lost.

It may or may not be worth stipulating some sort of soft policy on response times, though I'm sure that response time will vary greatly depending on the complexity of the HIP.

• Another comment made in the TSC meeting around the TSC's responsibility to filter out HIPs that are not relevant to the L1. This line:
  The HIP aligns to the technical direction and goals of Hiero

Sort of implicitly covers that intent, but perhaps could be made more explicit by saying The HIP aligns to the technical direction, scope and goals of Hiero, allowing for rejection of HIPs that may be in line with Hiero's goals but are not low level enough to warrant being a HIP in the repo's.

[hendrikebbers]

Great overview @Reccetech :)

Question: Will step 2 "Write and Submit HIP that provides high level outline of proposal with technical validation" contain the public API of the HIP (like the protobuf)?

Under the Standards Track we have Core, Service, Mirror, and Application HIPs. As well we have Informational and Process HIPs

Question: What will be the right place to discuss the groups and especially the names. I believe that "Application" as name is missleading especially for new community members.

[Reccetech]

1. Not all HIPs contain protobuf changes. However looking at a HIP that does - lets take HIP 991. I would suggest that in Step 2 the HIP Specification would include everything except the "New and Modified Protobuf Messages" section and the "REST API changes" section. Those low level details would be added in Step 4.
2. I think "Application" is about as good as any word to describe things built on top of the network. However, if anyone has a better name for this category of HIPs then please suggest, the TSC can take a vote, and we can modify HIP-1, hips.hedera.com etc.

[hendrikebbers]

Will take a look at HIP 991. THX for that concrete example