Deep diveHedera Token Service (HTS)

Hedera token keys: what each one controls and who should hold it

Hedera token keys are the optional administrative powers you attach to a token when you create it: admin, KYC, freeze, wipe, supply, fee schedule, pause and metadata. Each one authorizes a specific class of transaction, and a key you never set cannot be added later. Choosing which keys to set, and who controls them, defines how the token can be governed for its entire life.

Reviewed 10 October 2026 8 min read

On this page

Why key design comes before any other token decision
The eight HTS keys and the power each one grants
Leaving a key out: immutability as a deliberate feature
Matching each key to an owner in the operating model
Simple keys, key lists or threshold keys for each power
Associations: the holder-side half of token control
A hypothetical hotel group designs keys for a member-night credit
Key mistakes that surface only after launch
Questions and answers
Sources

Why key design comes before any other token decision

On Hedera Token Service, the controls that a smart contract would normally implement in code are properties of the token itself. Whether supply can grow, whether an account can be frozen, whether a balance can be removed after a court order: each of these depends on whether a particular key was set when the token was created, and on who can produce a valid signature for it¹.

That makes key design a governance decision rather than a configuration detail. The durable question is who may change the token after launch, under which approvals, and what happens if one of those people leaves or a signing server is compromised.

The eight HTS keys and the power each one grants

Every key below is optional at creation⁷. The descriptions follow the Hedera documentation and the token-creation protobuf definitions¹².

Admin key: Authorizes updates to the token's properties, such as name, symbol, treasury, expiry and the other keys. Without it, non-key properties cannot be changed and the token is effectively immutable.
KYC key: Grants or revokes KYC status for an account on this token, so only approved accounts can transact. If it is never set, KYC status can never be granted or revoked.
Freeze key: Freezes or unfreezes a specific account's ability to send or receive the token. Paired with the freeze-default flag, new holders start frozen until explicitly released.
Wipe key: Removes a quantity of the token from a specific holder's account, typically to correct an allocation or reverse an entitlement. Without it, wiping is impossible.
Supply key: Authorizes minting and burning, which change total supply. Minted units are delivered to the treasury account. Without it, supply is fixed at whatever was created.
Fee schedule key: Authorizes changes to the token's custom fees, such as fixed, fractional or royalty fees paid to collector accounts on transfer.
Pause key: Pauses or unpauses the whole token. While paused, the token cannot take part in any transaction, for any holder.
Metadata key: Authorizes changes to the token's metadata field and, for NFT collections, to the metadata of minted serials, without needing the admin key.

Leaving a key out: immutability as a deliberate feature

Omitting a key is a promise to holders. A token created without a supply key has a supply that nobody can inflate. A token without a wipe key cannot have balances taken away by the issuer. For a community or collectible token, publishing that configuration can be more persuasive than any terms of service, because anyone can check it on a network explorer.

The cost is that the promise also binds you. Hedera's documentation states that a key not set at creation cannot be added through a later update⁷⁴. If a regulator, a partner or your own risk team later requires the ability to freeze an account, the only route is to issue a new token and migrate holders to it, which means new associations, new balances and communication with every holder.

Removal now works in the other direction too. HIP-540 lets the admin key change or permanently remove the other keys, and lets each lower-privilege key replace itself or set itself to an unusable value without the admin key³. Some issuers launch with full controls during an initial operating period and then remove supply or wipe powers once the program has settled. The protobuf comments spell out the side effects: remove the pause key while paused and the token stays paused for good, remove the freeze key while accounts are frozen and they stay frozen².

Matching each key to an owner in the operating model

A starting allocation for a regulated or commercially sensitive token. Adjust it to your own segregation-of-duties rules.

Key	Typical owner	Approval before signing	Set it at all?
Admin	Governance group, not day-to-day operations	Change board or equivalent, with a recorded decision	Yes, unless immutability is the point
Supply	Treasury	Matched to an internal issuance or redemption record	Only if supply must change after launch
KYC	Compliance operations, often via an onboarding service	Successful identity check in the onboarding system	When holders must be approved individually
Freeze	Compliance or financial crime team	Case reference and named approver	When you may need to stop one holder
Wipe	Compliance with legal sign-off	Documented legal or contractual basis	Rarely; holders treat it as a strong issuer power
Pause	Incident commander or security lead	Incident declared under the runbook	Yes for most enterprise tokens
Fee schedule	Product or finance owner	Pricing decision communicated to holders	Only if custom fees exist or may be added
Metadata	Product operations	Content change request	When metadata must evolve after minting

The admin key can rewrite every other row, so its approval path should be the slowest and most visible in the table.

Simple keys, key lists or threshold keys for each power

Any HTS key can be a single key, a key list where every member must sign, or a threshold key where a set number of members must sign. Structures can be nested⁵.

If
A power is used often by an automated service, such as granting KYC after onboarding.
Then
Use a single key held in an HSM or cloud KMS, scoped to that one service, with logging on every signature.
Requiring several human signatures for routine, rule-based actions slows operations without adding much protection.
If
A power can create or destroy value, such as supply or wipe.
Then
Use a threshold key, for example two of three, across people in different teams.
A single compromised laptop or server should never be enough to mint units or remove a holder's balance.
If
A decision must carry two organizations' consent, such as a consortium token.
Then
Nest a threshold key per organization inside a key list, so each party's internal quorum must approve.
The network enforces the agreement directly, rather than relying on one member to follow a side letter.
If
A power exists only for emergencies, such as pause.
Then
Use a low threshold, such as one of several named responders, and alert widely whenever it is used.
In an incident speed matters more than consensus, and unpausing reverses the action.

Associations: the holder-side half of token control

Keys govern the issuer's powers. Holders have a control of their own: an account generally has to associate with a token before it can hold it, which Hedera describes as a defense against spam transfers¹. Accounts can also set a number of automatic association slots, where a value of zero requires manual association, a positive number allows that many automatic associations, and minus one allows unlimited associations; accounts created through auto account creation default to unlimited⁶.

Association interacts with your key design. If the token has a KYC key, an associated account still cannot transact until KYC is granted. If freeze-default is on, every new association starts frozen and needs an unfreeze transaction². Map both steps into the onboarding flow, or users will see a token in their wallet that they cannot move.

A hypothetical hotel group designs keys for a member-night credit

Key mistakes that surface only after launch

The admin key is held by the same server that signs routine transfers.

Early signalOne secret in the deployment configuration can sign both a transfer and a token update.

MitigationSeparate admin signing from operational signing, and keep admin material offline or behind a threshold.

A power is left out to simplify launch and is needed later.

Early signalCompliance asks for account freezing and the token has no freeze key.

MitigationReview the key set with compliance and legal before creation, because a missing key means a new token and a migration.

A key is removed at the wrong moment.

Early signalA cleanup ticket removes the freeze or pause key while accounts are frozen or the token is paused.

MitigationAdd a pre-check to the runbook: confirm no frozen accounts and no paused state before any key removal.

Questions and answers

What happens if we lose the private key for an HTS token key?

The power that key controls is lost unless something else can replace it. If the token has an admin key, the admin key can set a new value for the lost key under HIP-540. If the lost key was the admin key itself, or the token has no admin key, that power cannot be recovered. This is why high-value keys should be threshold keys with members held in separate places.

Can we add a freeze or KYC key to an HTS token after it has been created?

No. Hedera's documentation states that keys not set at creation cannot be added by a later update, even with the admin key. You can change or remove keys that exist, but adding a new power means creating a new token and migrating holders to it, so settle the key set with compliance before launch.

How can holders and auditors check which keys a Hedera token has?

Token information, including which keys are set and their public key structures, is available through a mirror node query or a network explorer. An auditor can compare the published configuration with your governance documents, and review the history of mint, wipe, freeze and update transactions to confirm each matched an internal approval record.

Sources

Hedera Token Service (HTS): native tokenization — Hedera documentation · checked 10 October 2026
token_create.proto: TokenCreateTransactionBody field definitions — Hedera protobufs (GitHub) · checked 10 October 2026
HIP-540: Change or remove existing keys from a token — Hiero Improvement Proposals · checked 10 October 2026
Update a token — Hedera documentation · checked 10 October 2026
Keys and signatures — Hedera documentation · checked 10 October 2026
Account properties: automatic token associations — Hedera documentation · checked 10 October 2026
Create a token — Hedera documentation · checked 10 October 2026

Have your token's key design reviewed before creation

Send the token's purpose, the powers you think you need and your team structure. We will return a proposed key set, owner per key and threshold design, with the trade-offs of each omission.

Request a key design review