HOL HCS SDK for Go: what the standards-sdk-go packages actually do
The official HOL SDK for Go, implementing the Hiero Consensus Specifications (https://github.com/hiero-ledger/hiero-consensus-specifications). See official documentation found in https://hol.org/docs/standards
At a glance
- What is it?
- A Go reference implementation of the Hiero Consensus Specifications, shipped as one module with a package per HCS standard. Useful if you already build on Hedera and want the spec encoded for you; the README is thin on production concerns.
- Who is it for?
- Adopt standards-sdk-go if you are writing Go against Hedera and want the HCS memo formats, registry operations and transaction builders already encoded rather than reimplemented from the specifications. Do not adopt it if you need a mature, widely deployed library with a long release history: the module is still on v0.1.x, the last push was on 2026-04-10, and the README documents no rollback path, no compatibility policy and no support window.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 161 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the HOL HCS SDK for Go is for
The Hiero Consensus Specifications describe how data should be written to Hedera Consensus Service topics: registry entries, agent profiles, memos, state hashes, checkpoints and so on. Each specification is a document. Turning a document into working Go means deciding field ordering, memo encoding, topic creation parameters and mirror-node read patterns, and getting any of those wrong produces data that other tooling cannot index. This module is the reference implementation of those decisions in Go.
The intended reader is a Go developer already building on Hedera who needs to produce spec-conformant messages rather than invent a format. The package table in the README maps one package to one specification: pkg/hcs2 for registry topics, pkg/hcs11 for agent profiles, pkg/hcs20 for auditable points, pkg/hcs27 for checkpoints. There is also pkg/registrybroker for a Registry Broker client covering search, adapters, agents, credits, verification and ledger auth, and pkg/inscriber for inscription flows. If your work is outside that set of specifications, this module has nothing for you.
One package per specification, and what that means for imports
The architecture is deliberately flat. There is no single client object that fronts everything; you import the package for the standard you are implementing and call its builders and helpers. The README describes each package in terms of the operations it covers, for example pkg/hcs2 provides "HCS-2 registry topic creation, tx builders, indexed entry operations, memo helpers, mirror reads". That phrasing recurs across the table, which tells you the shape of the API: construct a topic, build a transaction, encode a memo, then read back through a mirror node.
That split has a practical consequence. Because packages are independent, you can pull in only the standards you use, and the dependency weight in go.mod stays roughly the same either way. The module pins github.com/hiero-ledger/hiero-sdk-go/v2 v2.77.1, plus grpc, protobuf, a brotli dependency and a socket.io client. The socket.io and websocket entries line up with the websocket-first inscription utilities and chat or encryption paths described for pkg/inscriber and pkg/registrybroker; if you never touch those packages you are still compiling against them.
The go directive in go.mod reads go 1.25.7. That is a recent toolchain requirement, and it is the first thing to check if your build image is older. There is no build tag or alternative module path offered for older Go versions.
Installing standards-sdk-go and running a first example
The README gives a single install line. Add the module to your project with go get, then import the package for the specification you need. The import path is the module path plus the package directory, so the HCS-11 profile package is imported from github.com/hashgraph-online/standards-sdk-go/pkg/hcs11.
go get github.com/hashgraph-online/standards-sdk-go@latestIf you would rather work from the repository than from the module proxy, the Quick Start section clones the directory and runs the standard Go checks before anything else:
cd standards-sdk-go
go mod tidy
go test ./...
go vet ./...The README also lists a lint step using golangci-lint, with a .golangci.yml at the repository root, so the project's own lint configuration travels with the source.
The fastest way to see real usage is the examples directory. Every entry in the CodeSandbox list has a matching folder under examples/, including examples/hcs2-create-registry, examples/hcs11-build-agent-profile, examples/hcs14-parse-uaid and examples/hcs20-deploy-points. Open the folder for the standard you care about and read the main file; that is where the actual call sequence lives. For a first run, pick the example closest to your task and adapt its arguments rather than starting from an empty file, because the README does not document the builder signatures outside the package reference on pkg.go.dev.
Where the documentation stops and you are on your own
The README is an index, not a guide. It tells you which package covers which specification and points at hol.org/docs/standards for the specifications themselves and hol.org/docs/libraries/standards-sdk/ for SDK documentation, but it does not explain error handling, retry behaviour, or what a failed topic creation returns. None of that is in the repository README.
The bigger gap is operational. There is no section on key management, no guidance on which network or mirror node to point at, and no statement about backwards compatibility between the v0.1.x releases. The release list shows v0.1.18, v0.1.19 and v0.1.20, with the last two published on the same day, 2026-04-10. Rapid patch releases at that cadence are normal for a young module, but they also mean you should pin an exact version in your own go.mod rather than tracking latest, since the README offers no compatibility promise to rely on.
There is also a hard boundary worth stating plainly: this is a specification implementation, not a general Hedera client. Anything the specifications do not cover, such as ordinary token transfers or account queries outside the HCS flows, belongs to hiero-sdk-go, which this module depends on rather than replaces.
Registry Broker and Inscriber: the two packages outside the HCS numbering
Most of the module follows the specification numbering, but pkg/inscriber and pkg/registrybroker do not. The README describes pkg/inscriber as covering the Inscriber auth flow, websocket-first high-level inscription utilities, quote generation, bulk-files support, registry-broker quote and job helpers, and skill inscription helpers. pkg/registrybroker is described as a full client covering search, adapters, agents, credits, verification, ledger auth, and chat with encryption.
These two packages are where the module stops being a pure encoder and starts making network calls to a service. That distinction matters for adoption: the HCS packages are largely deterministic builders you can unit test without a network, while the broker and inscriber packages depend on an external endpoint and an auth flow. The examples list reflects this, with separate folders for registry-broker-delegation, registry-broker-skill-domain-proof and registry-broker-uaid-dns-verification, plus inscriber-auth-client. If your integration is sensitive to third-party availability, treat those packages as a different risk category from pkg/hcs17 or pkg/hcs27, which the README describes around deterministic state hash calculators and Merkle or proof helpers.
A real alternative: hiero-sdk-go on its own
The honest alternative is to skip this module and use github.com/hiero-ledger/hiero-sdk-go/v2 directly, which is exactly what standards-sdk-go builds on. With the base SDK you get accounts, transactions, topics and consensus submission, and you write the memo encoding and registry semantics yourself against the specification documents.
That is more work, but it is not pointless work. If you implement one specification and nothing else, the surface you need to get right may be small enough that a dependency on a v0.1.x module costs more than it saves. You also avoid inheriting the module's pinned versions of grpc, protobuf and the socket.io client, which you may not want in a service that only writes topic messages.
The trade-off runs the other way once you touch more than one or two specifications. Memo formats, indexed versus non-indexed registries, and the difference between HCS-6 dynamic registries and HCS-7 indexed registries with EVM or WASM config are exactly the kind of detail that is easy to get subtly wrong and hard to debug after the data is on a topic. The module encodes those decisions. Whether that is worth a young dependency is a judgement about your own tolerance for churn, not a property of the library.
Licence and the cost of keeping up
The repository is Apache-2.0, with the licence file at the root and a licence badge in the README. Apache-2.0 is a permissive licence that includes an express patent grant, which matters for a library that implements cryptographic and signature verification helpers such as the ones the README lists under pkg/hcs21 and pkg/hcs15. This is not legal advice; if you redistribute the module or build a product on it, have your own counsel review the notice and attribution requirements.
Upgrade cost is the part to plan for. The last push to the default branch was on 2026-04-10, and the most recent releases are v0.1.18, v0.1.19 and v0.1.20, all within five days of each other. A v0.x line with no stated compatibility policy means minor bumps can change signatures. The module also pins hiero-sdk-go v2.77.1 and a Go 1.25.7 toolchain, so an upgrade here can force an upgrade there. Budget for reading the diff of the packages you import, not just the release tag.
Editorial conclusion
Adopt standards-sdk-go if you are writing Go against Hedera and want the HCS memo formats, registry operations and transaction builders already encoded rather than reimplemented from the specifications. Do not adopt it if you need a mature, widely deployed library with a long release history: the module is still on v0.1.x, the last push was on 2026-04-10, and the README documents no rollback path, no compatibility policy and no support window. Before committing, open the example that matches your use case, confirm the package table in the README still lists it, and check that the pinned hiero-sdk-go version in go.mod is one your own dependency graph can accept.
Frequently asked questions
What is the HOL HCS SDK for Go used for?
It is the Go reference implementation of the Hiero Consensus Specifications, with one package per specification for building Hedera Consensus Service topics, transactions, memos and mirror reads, plus Inscriber and Registry Broker clients.
How do I install the standards-sdk-go module?
The README gives a single command, go get github.com/hashgraph-online/standards-sdk-go@latest, and the Quick Start section runs go mod tidy, go test ./... and go vet ./... from the cloned directory.
Where can I find a standards-sdk-go example?
The examples directory mirrors the CodeSandbox list, with one folder per standard such as examples/hcs2-create-registry, examples/hcs11-build-agent-profile and examples/hcs20-deploy-points. The repository README points at examples/README.md as the index.
Community notes