HOL Standards SDK: reference implementations for HCS standards on Hedera

What the HOL Standards SDK actually implements

Hashgraph Consensus Standards are specifications for storing and exchanging data on Hedera, covering things like file storage, registry indexing, recursive file loading, agent communication and decentralized identity. The specifications describe behaviour; they do not ship code. The HOL Standards SDK is HOL's reference implementation of those specifications in TypeScript.

The README lists eight standards in a Supported Standards table: HCS-1 (File Storage), HCS-2 (Registry and Indexing Standard), HCS-3 (Recursive File Loading), HCS-7 (Smart Hashinals), HCS-10 (Trustless Peer-to-Peer Communication for Agents and AI), HCS-11 (Decentralized Profile and Identity Standard), HCS-20 (Auditable Points) and HCS-27 (Transparency Logs). The repository also contains demo directories for HCS-12, HCS-14 through HCS-18, HCS-21, HCS-5 and HCS-6, which suggests the demo coverage runs wider than the table. The table is the authoritative claim; treat the extra demo folders as evidence of ongoing work rather than as a compatibility promise.

The intended audience is narrow and specific. You are building a TypeScript application on Hedera, you need one of those standards, and you would rather call a maintained module than transcribe a specification into your own codebase. If you are not on Hedera, most of this SDK has nothing to offer you.

Two packages, two footprints: @hol-org/standards-sdk and @hol-org/rb-client

The README describes two parallel distributions under the HOL scope. @hol-org/standards-sdk is the full SDK. @hol-org/rb-client is the registry broker client alone, described as having a smaller footprint. A legacy scope, @hashgraphonline/standards-sdk, still exists and is referenced throughout the code examples in the README, while the Quick Start installs the HOL scope. That mismatch is worth noticing: the install command and the import statements in the same document point at different package names. Both are published, but if you copy an example verbatim you may end up with two copies of the library in your dependency tree.

The rb-client design is the more interesting decision. The README states that the client ships with zero network transports bundled, and that optional peer dependencies are installed only when you need the related feature: axios plus x402-axios and x402 for X402 credit purchases and payments, viem for EVM-based ledger authentication, and @hashgraph/sdk for Hedera ledger authentication. Core agent search and chat flows require only a fetch implementation.

That is a deliberate trade against convenience. You get a small dependency graph, but you own the assembly step. A Node runtime without fetch, or a bundler configuration that does not resolve optional peers, will fail at the point of use rather than at install time.

Installing the SDK and running a first registry broker call

The Quick Start gives the install command directly. The HOL scope is the current one; the legacy scope is listed as a comment.

npm install @hol-org/standards-sdk
# Legacy scope:
# npm install @hashgraphonline/standards-sdk

For the registry broker client alone, the README gives a second install command. Use this one if you only need discovery and chat against the broker and want to avoid pulling in the full SDK.

npm install @hol-org/rb-client

The README's client examples import from the legacy scope. The RegistryBrokerClient takes either an apiKey or a baseUrl. The baseUrl form points at the broker API, shown in the examples as https://hol.org/registry/api/v1.

import { RegistryBrokerClient } from '@hashgraphonline/standards-sdk';

const client = new RegistryBrokerClient({
  baseUrl: 'https://hol.org/registry/api/v1',
});

const status = await client.getSkillStatus({
  name: 'registry-broker',
  version: '1.0.0',
});

console.log(status.trustTier);
console.log(status.nextSteps);
console.log(status.preview?.statusUrl ?? null);

According to the README, getSkillStatus resolves lifecycle status for a skill name and version and surfaces preview evidence when a repository has only completed validate-first checks. The three logged fields are trustTier, nextSteps, and an optional preview statusUrl. The README also gives a runnable demo for this flow: pnpm -C standards-sdk run demo:registry-broker-skill-status with --skill-name, --skill-version and --base-url arguments.

Running the repository's own demos requires a different path. The README lists four steps: clone the repository, run npm install, copy .env.example to .env, and fill in Hedera credentials. The .env.example file shows the keys involved, including HEDERA_ACCOUNT_ID, HEDERA_PRIVATE_KEY, HEDERA_NETWORK, HOLDER_ID and REGISTRY_URL. Note that this puts a private key in a plaintext file on disk. The README also states that the CLI can auto-persist agent state into .env if a demo is interrupted, which means the file is written to as well as read. Treat that file as a secret, and do not commit it.

With credentials in place, the README gives two demo entry points: npm run demo:registry-broker and npm run demo:hcs-10. A bundled interactive CLI is available through pnpm run cli, which lists the demos, maps the required environment variables, and links to the docs.

Skill verification and UAID DNS proof: what the broker client checks

Two verification flows appear in the README, and both rest on DNS TXT records as the proof mechanism.

The first is version-scoped skill verification. requestSkillVerification takes a name, a version and a tier, where the README shows basic or express. createSkillDomainProofChallenge takes a name, version and domain, and returns a challenge object whose txtRecordValue carries a token prefixed with hol-skill-verification=. The README strips that prefix with a regular expression before passing the remainder to verifySkillDomainProof as challengeToken. The implication is that you publish the TXT record yourself, under the domain you claim, and the broker confirms it.

The second flow is HCS-14 DNS TXT profile verification for an agent UAID. verifyUaidDnsTxt takes a uaid string plus a persist flag, and getVerificationDnsStatus takes the same UAID with refresh and persist options. The example UAID has the shape uaid:aid:...;uid=...;proto=a2a;nativeId=agent.hol.org, so the nativeId is the domain being proven.

Both flows are domain control proofs. They show that whoever ran the call can write DNS records for a domain. They do not attest to the quality of the skill, the honesty of the agent, or the safety of calling it. The README does not claim otherwise, but the method names (verifySkillDomainProof, trustTier) invite a stronger reading than the mechanism supports. If your application treats a verified tier as a safety signal, that is your inference, not the SDK's guarantee.

Where the SDK is the wrong tool, and what to use instead

The clearest boundary is the ledger. HCS standards are Hedera constructs, and the SDK's demos require Hedera credentials to do anything meaningful. If your agents run on EVM chains, on plain HTTP infrastructure, or across several ledgers at once, the HCS-specific modules do not apply. The registry broker client is the one part that could be used without Hedera, since core search and chat flows need only fetch, but the verification flows still assume a broker deployment and DNS control.

A second boundary is the standard set itself. Eight standards are listed as supported, and the numbering is not contiguous (HCS-1, 2, 3, 7, 10, 11, 20, 27). If your project depends on an HCS standard outside that list, the SDK will not cover it, and the README does not describe a plugin mechanism for adding one.

For agent-to-agent messaging generally, the practical alternative is to build on a transport-agnostic protocol directly rather than through an HCS binding. The SDK's own package keywords mention a2a, mcp and model-context-protocol alongside hcs-10, which indicates the project sees HCS-10 as one binding among several. If you need MCP or A2A on infrastructure you already operate, a dedicated implementation of that protocol gives you a smaller surface and no ledger dependency. The trade is that you lose the on-ledger registry and the verification flows, which is exactly what the SDK contributes.

A third case: if you only need file storage or a registry index and nothing else, installing the full SDK pulls in the whole standards set. The README's split into @hol-org/rb-client exists for the opposite reason, but there is no equivalent narrow package documented for a single HCS standard.

Maintenance, licensing and the cost of tracking releases

The repository is not archived, and the last push was on 2026-09-02. The release list shows v0.1.186 and v0.1.185 both dated 2026-09-02, and v0.1.184 dated 2026-05-08. Two releases on one day, after a gap of roughly four months, is the pattern to plan around: quiet stretches punctuated by bursts. The version numbers are still in the 0.1.x line, so semver gives you no guarantee of API stability across minor bumps.

That has a concrete cost. Pin the version in your lockfile and read the release notes before moving, because the README's own examples already show drift: the Quick Start installs @hol-org/standards-sdk while the code samples import from @hashgraphonline/standards-sdk, and the repository package.json carries a canary version string. Documentation and published artifacts are not guaranteed to move together.

The licence is Apache-2.0, stated in the repository metadata and in the LICENSE file at the top level. Apache-2.0 is permissive and includes an explicit patent grant, which matters for a library that implements specifications. It also requires that you preserve notices and state changes you make to the files. That is a general description of the licence, not legal advice; if you are redistributing the SDK inside a product, have counsel read the actual LICENSE file rather than this paragraph.

Editorial conclusion

Adopt the HOL Standards SDK if you are building on Hedera and need HCS-1, HCS-2, HCS-10 or HCS-11 semantics without writing them from the specifications yourself, and if you are comfortable running demos that require a funded Hedera account and a private key in a .env file. Do not adopt it for generic agent-to-agent messaging on non-Hedera infrastructure, and do not take the RegistryBrokerClient's verification methods as a substitute for your own trust model. Before committing, verify three things: that the HCS standard numbers you need appear in the Supported Standards table, that the npm scope you install (@hol-org/standards-sdk versus the legacy @hashgraphonline/standards-sdk) matches the imports in the documentation you are following, and that the package version pinned in your lockfile corresponds to the release notes you read.

Frequently asked questions

Official sources

1. hashgraph-online/standards-sdk on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases