Introducing HIP-991: Permissionless Revenue-Generating Topic Ids for Topic Operators

5d ago•

bullish:

bearish:

By Oliver Thorn

https://hedera.com/blog/introducing-hip-991-permissionless-revenue-generating-topic-ids-for-topic-operators

HIP-991 extends the functionality of the Hedera Consensus Service, turning it into a powerful revenue engine for developers, AI agents, and businesses. With permissionless revenue-generating topic IDs, the ecosystem now has native economic tools to monetize topics with high degrees of programmability and control.

HIP-991 at a Glance: Transforming Topics into Revenue Streams

HIP-991 — now implemented and ready for testing on Hedera testnet v0.59 — introduces permissionless revenue-generating Topic IDs to the Hedera Consensus Service (HCS). This significant update establishes a fixed fee system for topic message submissions, bringing extended monetization functionalities and programmable control to network topics, topic operators, and end-users as a whole.

This HIP fundamentally changes what’s possible with topic-based decentralized applications:

New Revenue Streams: Topic operators can now generate predictable revenue from each message submission and distribute fees to multiple wallets automatically, enabling sustainable and versatile workflows.
Enhanced Access Control: Developers can implement customizable economic barriers to reduce spam while maintaining permissionless access.
Flexible Payment Options: Fees can be denominated in HBAR or any Hedera Token Service (HTS) fungible token, enabling seamless integration with existing token ecosystems or DAO governance structures.

The introduction of topic fees mirrors the successful custom fee structure already implemented in HTS, providing a familiar and proven model for developers already working in the ecosystem. For users submitting messages to topics, the experience remains straightforward but now includes the option to specify maximum fees they’re willing to pay, providing protection against unexpected charges.

Whether you’re developing a data marketplace, a decentralized compute/AI agent service, a premium content distribution system, or a high-value messaging service, this proposal provides the economic infrastructure needed to create viable business models while simultaneously offering enhanced spam protection and resource allocation capabilities. As we explore the details of this HIP, you’ll discover how these new capabilities can fundamentally reshape your approach to building and monetizing applications on the Hedera network.

Let’s dive in and explore HIP-991 in-depth!

Key Features Introduced

HIP-991 introduces a powerful set of features that fundamentally transforms how HCS topics can be monetized and managed. These capabilities create a flexible economic model that balances revenue generation with access control, all while seamlessly integrating with existing Hedera infrastructure.

Optional Fixed Fees for Message Submissions

HIP-991 enables topic operators to set optional fixed fees that must be paid when submitting messages to a topic. This creates an immediate economic barrier that serves three purposes:

Generates predictable revenue for topic operators
Reduces unwanted message spam
Guarantees payment on successful message submission

Unlike the current one-size-fits-all approach with its minimal $0.0001 fee, topic operators can now set fees appropriate to their specific use case. A high-value financial data feed might warrant a higher submission fee than a general community messaging channel, allowing the market to determine appropriate pricing based on the information’s value.

Multi-Currency Support (HBAR and HTS Tokens)

HIP-991 doesn’t limit fees to HBAR — operators can configure topics to accept any HTS fungible token as payment. This opens up fascinating possibilities:

DAOs can require governance token submissions for proposals and/or votes
AI agents can charge customized HTS tokens or HBAR to execute commands / compute
Communities can create token-gated messaging using their own community token
Topic-specific tokens can be created that give holders messaging rights

This token flexibility creates a seamless experience where users can leverage their existing token holdings for topic interactions.

Fee Schedule Key for Independent Fee Management

Recognizing that fee structures may need to evolve over time, HIP-991 implements a dedicated Fee Schedule Key that operates independently from other administrative functions. This key:

Controls fee updates for the topic
Can be set at creation time and updated later (similar to HTS tokens)
Follows the same security rules as the Submit key

This separation of concerns allows operators to delegate fee management without granting full administrative control over the topic itself, enhancing operational security.

Multi-Wallet Fee Distribution

HIP-991 allows fees to be distributed to multiple wallet addresses. This enables:

Revenue sharing amongst stakeholders
Automated payment splitting for collaborative topics
Diverse distribution models for different business arrangements

This capability is particularly valuable for topics that represent collaborative ventures where multiple parties contribute value and deserve a share of any generated revenue.

Fee Exempt Key List for Authorized Free Access

The Fee Exempt Key List feature provides a balanced approach to access control. Topics can maintain a list of keys that are allowed to send messages without paying fees. When a transaction includes a signature from a key on this list, the fee requirement is waived.

This creates a hybrid model where:

General users pay the designated fee
Authorized entities can submit messages without charges
Topic operators maintain control over who receives free access
Even threshold keys are supported for multi-signature requirements

The list can contain up to 10 keys and can be updated with a ConsensusUpdateTopicTransaction signed by the topic’s Admin Key, providing ongoing flexibility in access control management.

This combination of features creates the perfect balance between public accessibility and controlled authorization, all while generating predictable revenue streams for topic operators.

The Mechanics of Revenue-Generating Topics

Understanding the foundational workflows enabled by HIP-991 is essential for developers looking to leverage these new capabilities. Let’s break down the mechanics of how these permissionless revenue-generating topic IDs function on Hedera.

Setting Fees During Topic Creation

When creating a new topic, developers can now specify custom fees using the custom_fees property in the ConsensusCreateTopicTransactionBody. This works similarly to custom fee creation for tokens in HTS. The process follows these steps:

Define one or more fixed fees (up to 10 entries allowed)
Specify whether each fee is in HBAR or an HTS fungible token
Set the fee amount for each message submission
Designate the fee collector account(s) that will receive the payments
Optionally set a Fee Schedule Key to manage future fee updates

Fee Payment Flow

When a user submits a message to a topic with custom fees, the following process occurs:

The user submits a TopicMessageSubmitTransaction to the network
The network validates the transaction and checks if fees are required
If the submitter’s key is in the Fee Exempt Key List, no fee is charged
Otherwise, the network checks if the user has sufficient balance for the fee
The fee is transferred from the sender’s account to the designated fee collector account(s)
The message is recorded on the topic if all conditions are met

The transaction fails if the user doesn’t have sufficient funds to cover the fee, but the network fee is still charged regardless. This ensures that users can’t spam the network with failed transactions without cost.

User Protection with Max Custom Fee Limits

To protect users from unexpected or excessive fees, HIP-991 introduces a max_custom_fee field in the TransactionBody. This allows users to specify the maximum fee they’re willing to pay. If the fee exceeds this limit, the transaction will fail with an appropriate error. This safeguard prevents situations where a topic operator might increase fees unexpectedly between when a transaction is created and when it’s processed.

Updating Fees with the Fee Schedule Key

Topic operators can adjust fees over time using the Fee Schedule Key:

The operator creates a ConsensusUpdateTopicTransaction
The transaction includes the updated custom_fees property
The transaction must be signed by the Fee Schedule Key
Once processed, the updated fees apply to all future message submissions

This mechanism allows for dynamic pricing based on market conditions, network usage, or evolving business models. If a topic was created without a Fee Schedule Key, fees cannot be added or modified later, providing certainty for users.

Fee Exemptions for Authorized Participants

The Fee Exempt Key List can be updated through a ConsensusUpdateTopicTransaction signed by the topic’s Admin Key. This list can contain up to 10 keys and supports various key types:

Single ED25519/ECDSA keys
Threshold keys requiring multiple signatures
Key lists for flexible authorization options

When a transaction is signed by a key on this list, the custom fee is waived entirely, though standard network fees still apply. This creates a two-tier system where trusted participants can interact freely while public submissions generate revenue.

Practical Steps for Developers

Now that we understand the technical foundations of HIP-991, let’s take a look at a practical implementation for developers looking to create and manage topics with custom fees. This section provides a concrete example using the Hedera JavaScript SDK setting and updating custom fees on the Hedera testnet, and outlines best practices for effective fee management.

Code Example

require("dotenv").config();
const {
  Client,
  PrivateKey,
  AccountCreateTransaction,
  Hbar,
  TopicCreateTransaction,
  TopicMessageSubmitTransaction,
  TopicUpdateTransaction
} = require("@hashgraph/sdk");

async function main() {
  // --- Set up main testnet client using your main wallet credentials ---
  const operatorId = process.env.MAIN_ACCOUNT_ID;
  const operatorPrivateKey = process.env.MAIN_PRIVATE_KEY;
  const operatorPublicKey = process.env.MAIN_PUBLIC_KEY;
  if (!operatorId || !operatorPrivateKey || !operatorPublicKey) {
    throw new Error("Please set MAIN_ACCOUNT_ID, MAIN_PRIVATE_KEY and MAIN_PUBLIC_KEY in your .env file.");
  }
  const client = Client.forTestnet();
  client.setOperator(operatorId, operatorPrivateKey);
  console.log(`Main client initialized with operator: ${operatorId}`);

  // --- Create two new accounts with ECDSA keys and an initial balance of 10 HBAR each ---
  console.log("\nGenerating two new ECDSA key pairs...");
  const newKey1 = PrivateKey.generateECDSA();
  const newKey2 = PrivateKey.generateECDSA();
  console.log(`Account 1 public key: ${newKey1.publicKey.toStringRaw()}`);
  console.log(`Account 2 public key: ${newKey2.publicKey.toStringRaw()}`);

  console.log("\nCreating new account 1 with 10 HBAR initial balance...");
  const createTx1 = await new AccountCreateTransaction()
    .setKey(newKey1.publicKey)
    .setInitialBalance(new Hbar(10))
    .execute(client);
  const receipt1 = await createTx1.getReceipt(client);
  const accountId1 = receipt1.accountId;
  console.log(`Account 1 created with ID: ${accountId1}`);

  console.log("\nCreating new account 2 with 10 HBAR initial balance...");
  const createTx2 = await new AccountCreateTransaction()
    .setKey(newKey2.publicKey)
    .setInitialBalance(new Hbar(10))
    .execute(client);
  const receipt2 = await createTx2.getReceipt(client);
  const accountId2 = receipt2.accountId;
  console.log(`Account 2 created with ID: ${accountId2}`);

  // --- Create HIP-991 topic ---
  // The topic is created with:
  //  • the first wallet’s public key (newKey1) in the fee‐exempt list,
  //  • a custom fee of 5 HBAR,
  //  • and a “custom fee key” (here, set as the admin key) equal to the main wallet’s public key.
  console.log("\nCreating HIP‑991 topic with custom fee parameters...");
  const topicCreateTx = new TopicCreateTransaction()
    .setTopicMemo("HIP‑991 Demo Topic")
    // Set the admin key to the main wallet public key so that only the main wallet can update fees.
    .setAdminKey(operatorPublicKey)
    // Hypothetical HIP‑991 method: attach custom fee parameters
    .setCustomFee({
      fee: new Hbar(5),
      feeExemptPublicKeys: [newKey1.publicKey.toStringRaw()]
    });
  const topicResponse = await topicCreateTx.execute(client);
  const topicReceipt = await topicResponse.getReceipt(client);
  const topicId = topicReceipt.topicId;
  console.log(`HIP‑991 topic created with ID: ${topicId}`);

  // --- Submit a message from the first wallet (should be fee-exempt) ---
  console.log("\nAccount 1 submitting a message (should be fee‑exempt)...");
  // Create a separate client for Account 1 using its key
  const client1 = Client.forTestnet();
  client1.setOperator(accountId1.toString(), newKey1);
  const msgTx1 = await new TopicMessageSubmitTransaction()
    .setTopicId(topicId)
    .setMessage("Message from Account 1, fee‑exempt")
    .execute(client1);
  const msgReceipt1 = await msgTx1.getReceipt(client1);
  console.log(`Account 1 message submitted, status: ${msgReceipt1.status}`);

  // --- Submit a message from the second wallet with max_custom_fee = 6 HBAR ---
  console.log("\nAccount 2 submitting a message with max custom fee of 6 HBAR...");
  const client2 = Client.forTestnet();
  client2.setOperator(accountId2.toString(), newKey2);
  const msgTx2 = await new TopicMessageSubmitTransaction()
    .setTopicId(topicId)
    .setMessage("Message from Account 2 with max custom fee 6 HBAR")
    // Hypothetical method for HIP‑991: set max custom fee on message submission
    .setMaxCustomFee(new Hbar(6))
    .execute(client2);
  const msgReceipt2 = await msgTx2.getReceipt(client2);
  console.log(`Account 2 message submitted, status: ${msgReceipt2.status}`);

  // --- Update the topic’s custom fee from 5 HBAR to 7 HBAR using the main wallet ---
  console.log("\nMain wallet updating the topic custom fee to 7 HBAR...");
  const topicUpdateTx = new TopicUpdateTransaction()
    .setTopicId(topicId)
    // Hypothetical method for updating HIP‑991 fee parameters:
    .setCustomFee({
      fee: new Hbar(7),
      feeExemptPublicKeys: [newKey1.publicKey.toStringRaw()]
    })
    .freezeWith(client);
  // Sign with the main wallet’s private key (the admin key)
  const signedTopicUpdateTx = await topicUpdateTx.sign(operatorPrivateKey);
  const topicUpdateResponse = await signedTopicUpdateTx.execute(client);
  const topicUpdateReceipt = await topicUpdateResponse.getReceipt(client);
  console.log(`Topic custom fee updated, status: ${topicUpdateReceipt.status}`);

  // --- Have Account 2 try to submit another message after fee update ---
  console.log("\nAccount 2 attempting to submit a message after fee update (with max custom fee still 6 HBAR)...");
  try {
    const msgTx3 = await new TopicMessageSubmitTransaction()
      .setTopicId(topicId)
      .setMessage("Message from Account 2 after fee update")
      .setMaxCustomFee(new Hbar(6)) // This is lower than the updated fee of 7 HBAR
      .execute(client2);
    const msgReceipt3 = await msgTx3.getReceipt(client2);
    console.log(`Account 2 message submitted after fee update, status: ${msgReceipt3.status}`);
  } catch (error) {
    console.error("Expected error when submitting message from Account 2 after fee update:", error);
  }

  console.log("\nApplication completed.");
}

Best Practices for Fee Management

When implementing custom fees for your topics, consider these best practices:

Set Appropriate Fee Levels

Match your fees to the value of your content while considering your audience’s willingness to pay. Start with conservative pricing and adjust based on user adoption and feedback to find the optimal balance between revenue and participation.

Communicate Fee Changes

Always notify users before implementing fee changes and provide clear reasoning. Consider grace periods for increases to maintain goodwill and prevent disruption.

Implement Security Measures

Protect Fee Schedule Keys using HSMs and consider threshold keys requiring multiple approvals. Establish formal governance processes to prevent unauthorized modifications and ensure proper review of fee adjustments.

Optimize User Experience

Display fee information clearly throughout your application and provide estimates before transaction submission. Implement standing fee authorizations for trusted topics to streamline the user experience while maintaining transparency.

Monitor and Analyze Fee Performance

Track key metrics on revenue, user retention, and submission volumes to understand your fee structure’s impact. Use this data to make informed adjustments and consider tiered pricing models for different user segments.

By following these implementation guidelines, you can leverage HIP-991’s capabilities to create sustainable, revenue-generating topic services while maintaining a positive user experience.

The Broader Impact of Topic Monetization

The introduction of HIP-991 brings substantial benefits to the broader Hedera ecosystem, extending well beyond just the topic operators who implement custom fees. This proposal strengthens the network’s economic foundation, enables new business cases, and creates value across multiple stakeholder groups.

Enhanced Token Utility

HIP-991 significantly increases the utility of both HBAR and HTS fungible tokens within the ecosystem. By enabling these tokens to serve as payment mechanisms for accessing topic-based services, the proposal creates new demand drivers for token acquisition and usage. For HBAR, this means expanded utility beyond network fees and staking. For HTS tokens, this creates an entirely new utility dimension where community tokens can now serve as access credentials for messaging and data services, strengthening their value proposition and potential adoption.

Enabling AI & New Business Models

The ability to directly monetize topics unlocks business models that were previously impractical without complex off-chain solutions. AI can execute tasks when a new message appears, knowing it’s already been paid for that computational expense. Data marketplaces can now sell information feeds with native payment handling. Subscription services can offer tiered access using different fee structures. Content creators can distribute premium materials with automated compensation. Most importantly, developers can focus on creating value rather than building payment infrastructure, dramatically reducing time-to-market for revenue-generating applications on Hedera.

Strengthening the HCS Value Proposition

The Hedera Consensus Service already offers powerful capabilities for decentralized message ordering and timestamping. HIP-991 enhances this value proposition by adding native economic layers that make HCS more attractive for AI agents and commercial applications. As businesses evaluate blockchain platforms for their messaging and data needs, the ability to implement streamlined monetization becomes a significant competitive advantage for Hedera, potentially driving greater adoption of the network’s consensus services.

Reducing Spam and Improving Quality

Beyond direct economic benefits, HIP-991 helps improve the quality of content on the network. By creating economic barriers to message submission, custom fees naturally discourage low-value spam messages while encouraging thoughtful participation. Topic operators can tune fee levels to achieve the optimal balance between accessibility and quality control, resulting in higher signal-to-noise ratios in topic content. This improved content quality further enhances the value proposition of Hedera-based applications, attracting more users to the ecosystem.

The combined impact of these benefits positions HIP-991 as one of the most significant enhancements to the Hedera ecosystem to date. By strengthening the fundamental economic layer of HCS, this proposal creates cascading positive effects that will likely accelerate adoption and innovation across the network.

The Road Ahead

HIP-991 represents a transformative advancement for the Hedera ecosystem by finally bridging the gap between technical infrastructure and commercial viability for topic-based applications. By enabling native monetization within the protocol, this improvement unlocks new business models, enhances token utility, and creates economic alignment between topic operators and users — all while maintaining the security and performance strengths that Hedera is known for.

As you explore implementation opportunities, we encourage developers and businesses to experiment with these new capabilities in testnet environments before deploying to mainnet. The community welcomes feedback on your experiences, challenges, and success stories through the Hedera Discord channel or GitHub repository. Your insights will help shape future enhancements and best practices around this powerful new feature set.

Stay tuned for more as we continue to set new standards of performance and functionality within web3. Hello Future.