The Hedera mainnet recently added its newest service, the Hedera Token Service. With this major milestone, we wanted to share how new features and functionality, like HTS, comes into being and how the Hedera roadmap is developed behind the scenes.
As a decentralized network, Hedera aims to be as transparent and inclusive as possible. The Hedera roadmap achieves this through contribution, input, and prioritization from a diverse group of stakeholders. These stakeholders consist primarily of open-source developers, companies building on Hedera, and the Hedera Governing Council.
Hedera Roadmap Process
Our goal is that community priorities continuously drive the Hedera roadmap. The numerous uses of distributed ledger technology result in many requirements, suggested improvements, and innovations that we wouldn't successfully capture working in isolation.
To achieve this, we use the following 6-step process for new additions to the Hedera mainnet.
The proposal step provides a wide net with an accessible submission process for community members. Hedera leverages Hedera Improvement Proposal (HIP) process so any community member can add a proposal. Each HIP is available in a transparent and open GitHub repo where other community members and Hedera staff can review, question, and improve upon the submission.
Hedera Governing Council also contributes proposals and requirements for the Hedera roadmap. The goal is for these proposals to be publicly available and validated as well. A great example of a Council driven improvement was the Hedera Consensus Service, with a public white paper co-authored with a Council member from IBM.
The Hedera team will next start to solicit input on proposals to validate their design and value proposition. This validation consists of the Hedera Product team reaching out to the developer community, Council members, and standards bodies. Feedback from these parties helps to make them more applicable for a larger pool of use cases. For instance, for the Hedera Token Service, the validation step drove requirements to include a KYC flag.
The validation process also helps to identify who would be willing to be potential contributors. The Hedera ecosystem includes many companies and independent developers who can help build and contribute to Hedera. A great example of this is LimeChain, who helped make the Hedera Token Service.
After a proposal is validated by community and Council members, it progresses into the definition phase. Here, it shifts from an idea to a documented design and set of requirements. Depending on the feature, this could be a combination of architecture diagrams, a HAPI document, or user stories.
Collectively these critically help us assess the resources, time, and impact of implementing a given proposal. There will often be multiple rounds of definition and feedback from many users who participated in the initial submission.
Once the proposal's technical scope is defined, the Hedera Product team prioritizes it in the roadmap by determining if it falls in a short or long-term priority coupled with the availability of resources. Once the priority is clear with resources established, the revised Hedera roadmap is shown to the Hedera Governing Council.
The Council then reviews the proposal definitions, use cases, and effort involved. The Council members can also provide feedback at the time. This ultimately results in a consolidated and approved roadmap, which becomes the official Hedera roadmap, as seen on Hedera.com/roadmap.
Now, with our updated roadmap in hand, is where the rubber meets the road! Each proposal will often be developed by a different organization, depending on who made the proposal and each organization's area of expertise. Our goal is to solicit input from as many diverse parties as possible while ensuring stable integration with the rest of Hedera software and ecosystem participants.
Move your HIPs
As we continue to improve upon the process outlined above, we encourage everyone to bring their own ideas to the Hedera ecosystem.
As a community, we have prioritized the following initiatives based on objectives for the network and industry trends:
- Tokenization. With Hedera Token Service we defined a new mechanism for tokens to be issued natively to the Hedera mainnet. HTS enables performant, customized, and easily integrated tokens. How do we make them and the ecosystem better?
- Decentralization. Hedera continues to support new features and capabilities supporting ease of node operation and network management. This objective drives features that continue to improve the decentralization of Hedera from a technology and governance perspective.
- Accessibility. The Hedera community has always come from a diverse set of technology, industry, and geographic backgrounds. As such, we continue to prioritize proposals that improve the accessibility of Hedera in different programming languages, use cases, and more.
While we welcome any Hedera Improvement Proposals, we are particularly interested in these three categories. If you see areas we can improve across our network, services, or documentation, let us know. We invite you to join us in the process.