Announcing HIP-540: Enhanced Token Key Management on Hedera
HIP-540 aims to introduce more flexibility and security during token creation with the Hedera Token Service. While the Hedera Consensus Service and Hedera File Service allow for the removal of administrative keys by setting them to an empty KeyList (indicating immutability), the Hedera Token Service currently lacks this functionality. HIP-540 proposes enabling admin keys for tokens created with the Hedera Token Service to sign an update transaction that changes or permanently removes any key from the token.
Additionally, HIP-540 allows lower privileged keys, like the Wipe, Freeze, and Pause keys, to update themselves to a usable or unusable key. This functionality lets users remove keys such as supply keys after NFT mints, enhancing security for the treasury and token holders. This added layer of security provides a practical solution for managing token risks in the Hedera ecosystem.
Why is This Needed?
Many token creators initially set keys like Admin, Wipe, Freeze, and Pause on their tokens to manage potential issues during the minting process. For instance, a Wipe key allows creators to destroy and remint tokens if problems arise. However, once the minting process is complete, these keys pose ongoing risks to token owners and create uncertainty among collectors who are unaware of the security implications. An NFT with a Wipe key, for example, means the key owner can erase a holder’s token balance without their consent. Currently, there is no way to remove such keys from a token. They can only be changed when the TokenUpdateTransaction is signed by the admin key.
HIP-540 addresses these issues by allowing token creators to remove or change keys after they have served their initial purpose. This ensures greater security and trust in tokens, allowing creators to eliminate the risks associated with these keys and providing reassurance to new users and collectors in the broader NFT ecosystem.
Implemented Solution
Hedera’s current approach often forces users to choose between an administrative and an admin-less world. Many projects launch with administrative oversight to ensure smooth operations, intending to transition to a more decentralized model over time. Allowing the removal or modification of keys aligns with this approach and provides a solution for correcting initial setup requirements or mistakes.
HIP-540 Solution Overview
Admin Key Management: An admin key can remove itself or other keys.
- Benefit: Removing the admin key prevents administrative control over the token, meaning the admin key can’t remove or update keys. The decision power to change or remove themselves is given to the keys on the token instead of the admin key. This supports our vision of transitioning to an admin-less world.
Key Modification: All keys can change themselves to another valid or unusable key, except the admin key, which should be removed if no longer needed.
- Unusable Key: Refers to an Ed25519 0x0000000000000000000000000000000000000000000000000000000000000000 public key, which is practically impossible to derive a matching private key for.
- Benefit: Ensures that individual keys can change or remove themselves independently of the admin key, providing better token management capabilities.
We will have to add an enum field in the update transaction about whether the system should require signatures from the updated keys. The current policy is to require a new key to sign an update transaction unless it is being changed by the Admin Key. This protects users from accidentally updating to a public key unless they definitely have the matching private key. With this enum field, the user will be able to tell the system to omit the new key from the signing requirements. The default value of the field will maintain the current behavior of requiring new keys to sign unless the update already has a higher-privilege key signature.
Here’s a simple code example illustrating this boolean when updating a key to an unusable key.
const newSupplyKey = "0x0000000000000000000000000000000000000000000000000000000000000000";
let tokenUpdateTx = await new TokenUpdateTransaction()
.setTokenId(tokenId)
.setSupplyKey(newSupplyKey)
// When set to NO_VALIDATION, the TokenUpdateTransaction won't require the new key's signature
.setKeyVerificationMode(NO_VALIDATION)
.freezeWith(client)
.sign(oldSupplyKey)Practical Examples
To better understand the implications and benefits of key immutability, let’s consider the following examples:
Example 1: Mutable Supply Key without an Admin Key
- Scenario: The Supply Key has been set to a usable key, and there’s no Admin Key set.
- Outcome: The Supply Key remains mutable since the Supply Key is not set to an unusable key.
Example 2: Mutable Supply Key with an Admin Key
- Scenario: The Supply Key is set to an unusable key, and there’s an Admin Key set.
- Outcome: The Supply Key remains mutable, as the Admin Key can still alter the Supply Key.
Example 3: Immutable Supply and Admin Keys
- Scenario: The Supply and Admin Keys are set to an unusable key.
- Outcome: The Supply Key becomes immutable as nobody can change the Supply Key.
Please refer to the flow diagram below to help visualize these different scenarios. The yellow line represents Example 1, the green line represents Example 2, and the blue line represents Example 3.
Conclusion
HIP-540 provides a robust solution for enhancing token management on Hedera. Enabling the removal and modification of keys addresses critical security concerns and aligns with the evolving needs of token creators and holders. This proposal ensures that tokens can be securely managed, with the flexibility to adapt to changing requirements while maintaining the integrity of the token ecosystem.
To try out this functionality, please update your SDK to the following versions:
