# Hiero Consensus Specifications: a text first home for the HCS standards > The hiero-consensus-specifications repository holds the normative text of the Hiero Consensus Standards, a numbered series of open specifications for message formats and protocol patterns layered on the Hiero Consensus Service, from file management and topic registries through to AI agent communication, trust scores and privacy compliance. There is no code here, only the documents and the process that governs them. **hiero-ledger/hiero-consensus-specifications** — Canonical specifications for Hiero Consensus Specifications (HCS) — originally written and maintained by Hashgraph Online - Repository: https://github.com/hiero-ledger/hiero-consensus-specifications - Website: https://hol.org/docs/standards - Stars: 565 · Forks: 25 - Language: Unknown - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/hiero-ledger-hiero-consensus-specifications ## A repository of documents, not of software The hiero-consensus-specifications repository is the canonical source for the normative text of the Hiero Consensus Standards, along with the contribution workflow and the governance process used to evolve them. The project description calls them canonical, text-first specifications for Hiero Consensus Standards, originally created and maintained by Hashgraph Online. That framing explains the shape of the repository, which is almost entirely documentation. The top level holds a .github/ directory, a CODEOWNERS file, the Hashgraph Online logo, the LICENSE, a MAINTAINERS file, a MAINTAINERS.md, a SECURITY.md and a docs/ directory. There is no source tree, no build system, no package manifest and no test suite, because the deliverable is the text of the specifications themselves. The abstract describes what the standards are. Hiero Consensus Standards are open, versioned specifications for interoperable data formats and protocol patterns layered on top of the Hiero Consensus Service, and similar consensus or message transports. The patterns they support range from simple file storage and registry management to complex state and discovery workflows for appnets and AI agents. The homepage is the standards section of the Hashgraph Online documentation site, and the reference implementation is named as the Standards SDK, with a link to its overview. That split between specification and implementation is the important architectural fact about the project, and the readme is explicit that the reference implementations exist so that independent implementations can stay aligned. The licence is Apache 2.0, the default branch is main, and the repository is not archived, with the last push on 2026-10-19. ## The motivation is interoperability between independent implementations The motivation section explains why a specification repository exists at all, and the reasoning is about the cost of ambiguity rather than about standards for their own sake. Implementers, described as apps, wallets, agents, indexers and tooling, need a stable, auditable source of truth for message formats, validation rules and lifecycle expectations, so that independent implementations can interoperate reliably. A lightweight, specifications-first repository makes review and versioning easier, reduces ambiguity, and keeps reference implementations aligned. Three design choices follow from that. The repository is text-first, so the normative content is written in a form that can be read, reviewed and versioned without a build step. It is versioned, so a specification has a number and a lifecycle rather than being a living document. And it is auditable, which in practice means the governance process is written down as carefully as the specifications are. The process and governance are defined in a file the readme names directly, docs/standards/hcs-4.md, and that document appears in the specification table as HCS-4, the HCS Standardization Process, which defines the lifecycle, roles, criteria and repository workflow for proposing, reviewing, approving, publishing and maintaining the standards. That is a slightly unusual arrangement. The process for changing the standards is itself one of the standards, numbered in the same series and living in the same directory as the specifications it governs. A contributor reading the index finds the rules for the index. The topic list gives a sense of where the standards are pointing. Alongside consensus, hashgraph and hedera there are ai-standards, trust-scores and hol, and the specification titles themselves are where the direction is clearest. ## Twenty-four numbered specifications, from file chunks to agent trust scores The specification table is the substance of the repository, and it reads as a roadmap of what a consensus transport layer is being asked to support. The early ones are infrastructure. HCS-1 is File Management, covering how to encode, chunk, upload, retrieve and reassemble file data on HCS topics using a JSON schema and topic memo validation. HCS-2 is Topic Registries, defining registries that enable structured data organisation, discovery and retrieval. HCS-3 is Recursion, a method for implementing recursion on HCS to enable more complex data structures and relationships. HCS-4 is the standardization process described above. The middle of the range deals with inscriptions and identity. HCS-5 is Hashinals, a standard way to inscribe them using the Hiero Consensus Service and the Hiero Token Service, inspired by Ordinals. HCS-6 is Dynamic Hashinals, a framework for Hashinals whose content and behaviour can be updated over time. HCS-7 is Smart Hashinals, which enables dynamic NFTs whose metadata updates based on smart contract state using deterministic topic selection and WASM processing. Then come the agent standards, which is where the volume is. HCS-10 is the OpenConvAI standard for AI agent communication on HCS, letting agents register, discover and communicate using registries, topics and standardised operations. HCS-11 is Profile Metadata, managing profiles on Hiero through account memos for individuals and agents alike. HCS-14 is a Universal Agent ID standard for globally unique identifiers for agents across web2 and web3 environments. HCS-16 covers Floras, multi-party AppNet accounts enabling coordination, shared escrow and state consensus across agents, and HCS-18 is the discovery protocol for Floras via an open broadcast mechanism. The rest of the list is scattered but tells its own story. HCS-8 and HCS-9 cover polls and poll metadata. HCS-12 covers HashLinks, actions, blocks and assembly for interactive experiences without smart contracts. HCS-13 is a schema registry, HCS-15 covers Petals, account instances sharing one private key, and HCS-17 defines how state hashes of accounts and formations are calculated for auditable verification. HCS-19 is an ISO/IEC TS 27560 aligned privacy compliance framework for agents, HCS-20 an auditable points standard, HCS-21 an adapter registry, HCS-25 an AI trust score methodology, HCS-26 a decentralized agent skills registry, and HCS-27 transparency log checkpoints publishing Merkle tree roots. ## First contact: the index, then the one standard you need There is nothing to install here, and that is the point. The project ships no package, no build step and no command line, so a first use is a reading session rather than a setup session. The entry point is the readme table, which lists every specification with its number, its title, a link to the document and a one line statement of what it does. The full index sits at docs/standards/index.mdx. Individual standards are markdown files under docs/standards, some of them a single file such as docs/standards/hcs-1.md and some of them a directory with an index.md inside it, which is the case for HCS-8, HCS-9, HCS-10, HCS-12, HCS-14, HCS-20 and HCS-27, while the template is the single file docs/standards/hcs-XX.md. If your goal is to interoperate rather than to contribute, the readme points at the reference implementation, the Hashgraph Online Standards SDK, and the published standards are reachable from the standards section of the Hashgraph Online documentation site at hol.org/docs/standards. If your goal is to propose something, the same readme points at HCS-4. A new implementer should therefore read HCS-1 or HCS-2 first if the goal is file data or registries, since HCS-26 builds on both, and check the governance file before assuming that a document can be edited freely. ## How a specification gets written, and how it gets changed The contribution process section is short and prescriptive, and it is the part a contributor has to follow exactly. The canonical process is HCS-4, the HCS Standardization Process. For a new proposal you open an issue, using the 01 - Proposal label, draft the document under docs/standards/drafts/ with a slug, starting from the template, then request a number assignment and submit a pull request. Updates to existing specifications are a pull request against the relevant docs/standards/hcs-* document, following the HCS-4 change management rules. And normative keywords have to use RFC 2119. The number assignment step is the one worth pausing on. A specification is identified by its number, and the numbers are visibly not contiguous. The table runs from HCS-1 to HCS-21, then jumps to HCS-25, HCS-26 and HCS-27, and there is a gap where HCS-22 through HCS-24 would be. The readme also carries a row for HCS-XX, the template for drafting a new specification that conforms to the HCS-4 requirements. The gaps are the interesting part. A versioned specification set that skips numbers is a set where numbers were reserved, withdrawn or left unfilled, and anyone reading the index can see that some proposals did not become standards. That is an honest artefact of a real governance process rather than a tidied list. The full index lives at docs/standards/index.mdx, and the proposal path in the readme points to the submission and review workflow section of HCS-4. ## Who maintains it, and what the file list says about the priorities The repository carries a governance surface rather than a development one, and the file list is a good guide to that. There is a CODEOWNERS file, which is how a repository assigns review responsibility for particular paths, and a MAINTAINERS file alongside a MAINTAINERS.md, which is the two forms that maintenance information has taken over the years. There is a SECURITY.md, and the licence is Apache 2.0. That combination is a project where the artefacts of a standards process matter more than the artefacts of a build. There is no CI configuration in the visible top level, no test suite, no code to lint, because there is no code. The work here is reading, reviewing and merging prose that has to mean exactly one thing to every implementer who reads it. The original authorship is stated as well. The standards were originally created and maintained by Hashgraph Online, and the repository is now under the hiero-ledger organisation. The branding image at the top of the readme is the Hashgraph Online logo, and the topics include both hashgraph and hedera, which is how the two names connect. The current activity level is high. The last push was on 2026-10-19 and the repository is not archived, and there are no GitHub releases, which is right for a repository whose artefacts are versioned inside the documents rather than published as artefacts. There is also a Hacktoberfest topic, which tells you that the contribution process is expected to be approachable by outside contributors, which fits a repository that wants proposals from people outside the core team. ## Conclusion This repository suits a standards body, a consortium or an implementer who needs a stable, auditable source of truth for HCS message formats, and it suits a contributor who wants to propose a new specification through a documented workflow. It does not suit a developer looking for a library to install, because there is no code and no package, and the reference implementation lives in a separate Standards SDK. Before writing into it, read HCS-4 for the lifecycle and roles, follow the proposal path of an issue, a draft under docs/standards/drafts and a pull request, and use the RFC 2119 normative keywords the process requires. ## FAQ ### What is the hiero-consensus-specifications repository? It is the canonical source for the normative text of the Hiero Consensus Standards, open and versioned specifications for interoperable data formats and protocol patterns layered on the Hiero Consensus Service and similar consensus or message transports, together with the contribution workflow and governance process used to evolve them. ### What do the Hiero Consensus Standards cover? Patterns ranging from simple file storage and registry management to complex state and discovery workflows for appnets and AI agents. The numbered set includes file management, topic registries, recursion, Hashinals and dynamic and smart Hashinals, polls, agent communication and identity, Floras, state hash calculation, an adapter registry and an AI trust score methodology. ### How do I propose a new Hiero Consensus Standard? Open an issue using the 01 - Proposal label, draft the document under docs/standards/drafts with a slug starting from the HCS-XX template, then request a number assignment and submit a pull request. The full process is defined in HCS-4, and normative keywords have to follow RFC 2119. ### Is there a reference implementation in this repository? No. The repository contains only the specifications, the process document and the governance files. The reference implementation is the Hashgraph Online Standards SDK, which is a separate project linked from the readme. ## Sources - [hiero-ledger/hiero-consensus-specifications on GitHub](https://github.com/hiero-ledger/hiero-consensus-specifications) - [Issues](https://github.com/hiero-ledger/hiero-consensus-specifications/issues) - [License: Apache-2.0](https://github.com/hiero-ledger/hiero-consensus-specifications/blob/main/LICENSE) - [Project website](https://hol.org/docs/standards) - [README](https://github.com/hiero-ledger/hiero-consensus-specifications/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hiero-ledger-hiero-consensus-specifications