HCS Specifications Join Hiero: A Durable, Neutral Home for Production-Grade Standards
Hashgraph Online has contributed the Hiero Consensus Specifications (HCS) into the Hiero project under Linux Foundation Decentralized Trust. The canonical repository is now maintained under the Hiero GitHub organization:
https://github.com/hiero-ledger/hiero-consensus-specifications
For builders and partners, this change consolidates specifications that are already implemented across the ecosystem into the same vendor-neutral home as the open source distributed ledger technology used to build the Hedera network. This provides clearer stewardship, a single canonical reference point, and a shared governance model for application- and coordination-layer standards.
This post outlines what the Hiero Consensus Specifications cover, how they are used today across identity, registries, AI agents, and engagement systems, and where the roadmap is heading next.
What the Hiero Consensus Specifications are
The Hiero Consensus Specifications are open, versioned, text-first specifications that define interoperable message formats and protocol patterns for systems built on consensus-based messaging.
They focus on application-layer interoperability. Rather than prescribing business logic or product architecture, the specifications define shared conventions for how data is published, discovered, referenced, and interpreted across independent implementations.
In practice, this reduces fragmentation. Builders do not need to reverse-engineer proprietary formats or maintain brittle integrations. Instead, they can rely on shared definitions that multiple tools interpret consistently.
What is included in the repository
The Hiero-hosted repository provides the canonical specification text for a growing catalog of more than 20 specifications. These range from foundational primitives to higher-level coordination patterns already used in production environments.
Key examples include:
HCS-1: File Management
A standard approach for encoding, chunking, publishing, retrieving, and reassembling files through consensus topics.
HCS-1 is widely used when teams need content-addressed data availability with verifiable ordering. Common use cases include identity schemas, credential definitions, metadata artifacts, and registry payloads that must be independently retrievable and auditable.
HCS-2: Registries
A standard for publishing, updating, and discovering registries over consensus messaging.
HCS-2 defines how structured registries can be represented and maintained in a consistent, append-only manner. This enables independent applications to discover shared resources such as agents, services, datasets, identity artifacts, or protocol endpoints without relying on centralized databases or proprietary indexing layers.
Registries built using HCS-2 form a foundational layer for discovery across the ecosystem. They are commonly paired with other specifications such as HCS-1 for file-backed entries and HCS-10 for agent-related registries.
HCS-10: OpenConvAI
A framework for AI agents to register, discover, and communicate using standardized operations over consensus-based messaging.
HCS-10 defines shared expectations around how agents announce capabilities, exchange messages, and coordinate actions in a way that other systems can observe and interpret without bespoke integrations.
HCS-11: Profile Metadata
A method for managing identity and profile metadata for individuals and AI agents.
HCS-11 provides a consistent representation of identity attributes that can be referenced across registries, communication protocols, and execution environments.
HCS-20: Auditable Points
A standard for managing and auditing points using consensus topics, with applications in engagement systems and traceable incentive design.
HCS-20 enables transparent issuance and verification of points across independent applications, reducing reliance on opaque or siloed accounting systems.
Together, these specifications allow builders to focus on application logic while relying on shared infrastructure conventions for discovery, identity, coordination, and auditability.
Why registries matter at the infrastructure layer
Registries are a critical but often under-specified part of distributed systems.
Without shared registry standards, each application defines its own way to list agents, services, or resources. Discovery becomes fragmented, indexing logic diverges, and interoperability suffers.
HCS-2 addresses this by standardizing how registries are published and consumed using consensus messaging. Because registry updates are ordered, immutable, and independently verifiable, multiple tools can rely on the same registry data without trusting a single operator.
This registry layer underpins higher-level use cases such as:
- Agent discovery and coordination
- Cross-platform service catalogs
- Identity and credential resolution
- Protocol and capability registries
By including HCS-2 alongside file management, identity metadata, and agent communication standards, the Hiero Consensus Specifications define a coherent stack rather than isolated primitives.
A clear signal for Web2 partners: HCS-14 and Universal Agent IDs
An important aspect of the HCS roadmap is its applicability beyond Web3-native environments.
HCS-14 introduces a Universal Agent ID designed to give AI agents a single, portable identifier that works across Web2 APIs, Web3 networks, and hybrid environments. The specification is designed to keep identity stable even as endpoints, transports, and execution environments change.
HCS-14 can incorporate existing decentralized identifiers where they already exist, or generate deterministic identifiers where they do not. Importantly for enterprise and Web2 integrations, Universal Agent IDs do not require on-chain transactions. They can be generated entirely offline from canonical agent data or existing identifiers.
This allows organizations to adopt consistent identity and discovery conventions without changing their underlying infrastructure or deployment model.
Next up: universal agentic trust scores
Building on universal agent identity and registry-based discovery, the next area of work will focus on universal agentic trust scores.
The goal is to define a shared, interoperable way to represent and exchange trust signals for agents across registries and transports, including hybrid Web2 and Web3 environments. Rather than trust being locked inside platform-specific scoring systems, trust signals can become portable, explainable inputs that downstream systems can evaluate consistently.
As with the rest of the HCS specification set, this work will be developed in public using the same open contribution model.
Real-world adoption today
The Hiero Consensus Specifications are already used in production across identity, agent coordination, and engagement systems.
Identity infrastructure and verifiable credentials
DSR Corporation’s Hiero AnonCreds Method leverages the HCS-1 specification to store immutable files on Hedera Consensus Service, treating published AnonCreds objects as HCS-1 files. This provides a consistent way to reference identity artifacts across independent tools.
“DSR Corporation actively leverages the HCS-1 specification within the Hiero Identity Ecosystem to deliver decentralized identity solutions with real-time transparency and auditability,” said Alexander Shcherbakov, Head of Decentralized Systems Department at DSR Corporation. “As a member of the Hiero community, we see strong momentum around extending these specifications to support decentralized identity for agentic AI and are proud to contribute to an ecosystem moving from specifications to real-world impact.”
AI agent interoperability and discovery
HCS-2, HCS-10, and HCS-11 are used together to support agent registries, profile metadata, and standardized communication patterns. As agents proliferate across products and organizations, shared conventions for discovery and interaction are becoming baseline infrastructure.
Auditable points for engagement and training loops
HCS-20 supports transparent engagement systems used today by organizations such as Bonzo Finance and Hashgraph Online. Looking ahead, auditable primitives may also support AI training and evaluation workflows where traceability is increasingly important.
To date, systems built on HCS standards have supported more than 33 million consensus transactions, alongside 2,000+ weekly SDK downloads and 300,000+ daily CDN views for files, reflecting sustained adoption across the ecosystem.
Get involved
The Hiero Consensus Specifications are open and contribution-driven.
Builders, enterprises, and researchers can participate by:
- Reading and starring the repository: https://github.com/hiero-ledger/hiero-consensus-specifications
- Submitting pull requests for clarifications, examples, enhancements, or new draft proposals
- Opening issues to propose additions, identify gaps, or share implementation feedback
One of the most impactful ways to contribute is to take a single specification and help make it easier to implement through clearer definitions, stronger examples, and real-world validation.
Recent Hiero Posts
-
Understanding Fairness in Distributed Ledger Technology
4 min read• February 10, 2026
An explanation of fairness in distributed ledger technology, why it matters for certain use cases, and how Hiero enables fairness through its underlying consensus design.
-
Hiero Links For The Week of February 2nd
February 5, 2026
An overview of the updates that happened in Hiero during the week of February 2nd.
-
Hiero Links Of January
February 3, 2026
An overview of the updates that happened in Hiero during the month of January.
-
Announcing Support of Swift 6 in The Hiero Swift SDK
February 2, 2026
The Hiero Swift SDK now officially supports Swift 6.0, 6.1, and 6.2 with full CI testing and compatibility guarantees.