HIP-1208: Native integration of Hedera Smart Contract Service (HSCS) with Hedera Consensus Service (HCS) topics

[walter-hernandez]

---

hip: 1208
title: Native integration of Hedera Smart Contract Service (HSCS) with Hedera Consensus Service (HCS) topics
author: Walter Hernandez walter.hernandez.18@ucl.ac.uk, Juan Ignacio Ibañez j.ibanez@ucl.ac.uk, Paolo Tasca p.tasca@exp.science, Nikhil Vadgama nikhil.vadgama@exp.science, Jiahua Xu jiahua.xu@ucl.ac.uk
type: Service
category: Service
needs-council-approval: Yes
status: Draft
created: 2025-06-02
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/XX
link-to-pr: #1208

Abstract

This proposal enables direct intraoperability between Hedera Smart Contracts and topics created using the Hedera Consensus Service (HCS). Smart contracts will be able to read and write to HCS topics through native integration. This allows for real-time event processing, decentralized messaging, and cross-application coordination without external intermediaries like Oracles.

Motivation

Developers will be able to leverage HCS topics for secure, verifiable messaging and event tracking directly within smart contract logic, opening up use cases such as decentralized coordination, event-driven automation, and consensus-based contract execution.

Rationale

Allowing smart contracts to interact natively with HCS topics enables applications to maintain tamper-proof records, trigger contract execution based on consensus-driven data, and create verifiable off-chain attestations. For example:

• A smart contract can listen to HCS topics and execute predefined actions based on received messages.
• HCS topics can serve as permissioned registries, where contracts validate participants' eligibility before executing transactions.
• Multiple smart contracts on Hedera and external applications (off-graph) can read and write from the same topics, enabling many-to-many communication patterns. For example:
  • External applications can post messages to HCS topics that smart contracts can react to.
  • Smart contracts can emit events to topics that external applications listen to.
• The Hedera mainnet provides the trusted consensus layer that ensures all participants within the same topics see the same sequence of events.

User stories

• As a developer, I want my smart contract to read data from HCS topics to trigger predefined on-chain actions in a verifiable manner.
• As a developer, I want my smart contract to write data to HCS topics to enable automated event logging and cross-application messaging.
• As an enterprise, I want to use HCS topics as a decentralized messaging layer to coordinate state changes between smart contracts across multiple applications, on-graph and off-graph.

Specification

• External applications can coordinate indirectly by posting and reading from shared HCS topics.
• Smart contracts can serve as trusted validators and event generators for other smart contracts or external applications.
• An HCS topic acts as a consensus-driven message broker by providing persistent, ordered message queues leveraging Hedera’s consensus.
• The topic could function as an interoperability point of connection with the external applications including those on other blockchains.

Backwards Compatibility

The implementation maintains backward compatibility with existing HCS and Smart Contract systems. Applications currently using either system independently can continue to do so without modification. The integration layer adds new capabilities without breaking existing functionality.

Security Implications

To maintain security and prevent unauthorized smart contract interactions with HCS topics:

• Contracts must be explicitly granted permissions to interact with specific HCS topics, ensuring controlled access.
• Contracts will not be able to delete or modify existing HCS topics. This ensures that the integrity of the topics is maintained and that the smart contract cannot interfere with the normal operation of the HCS system.
• The creation of HCS topics will still be done through the existing HCS APIs, and the smart contract will only be able to interact with topics that have been created beforehand.
• Messages between smart contracts and HCS will be cryptographically signed and verified, preventing tampering.
• The proposed architecture will avoid storing private keys within smart contracts to be able to interact with topics, ensuring security best practices.

How to Teach This

Open Issues

References

https://hedera.com/blog/use-cases-for-hcs-based-records-in-play-to-earn-nft-gaming
https://docs.hedera.com/hedera/tutorials/consensus/submit-your-first-message

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[kpachhai]

Thanks for putting together this discussion about a native integration between HSCS and HCS topics. This is a really important area for expanding the capabilities that Hedera offers and the use cases you've mentioned like decentralized coordination, even-driven automation and verifiable attestations are amazing and probably many in the community would agree with this.

I myself have also been actively working on a HIP focused on enabling smart contracts to interact with HCS, specifically the "write" aspect. My proposal is around a "Deferred HCS Message Submission Precompile". The idea is that a smart contract would call a precompile to stage an HCS message which is then submitted to the specified HCS topic by the Hedera network itself, but only AFTER the smart contract transaction successfully achieves consensus. I went with this approach to ensure the smart contract's execution remains fully deterministic while still being reliable when it comes to getting messages onto HCS.

I am very interested in this proposal and I had some questions I was hoping you could answer:

1. Smart Contract Writing to HCS Topics: The diagram shows "Smart Contract 1" -> "Emits events" -> "Topic". Could you elaborate a bit more on the technical aspect for how this could be done? For instance, my approach uses a precompile with deferred execution. Are you thinking along similar lines or do you have a different model in mind for how a SC can deterministically and securely initiate messages to the HCS topic and how other things like HCS transaction fees would be handled?
2. Smart Contract Reading from HCS Topics:
   a. The ability for "Smart Contract 2" to react to "Event data" from an HCS topic is a very powerful concept in my opinion and I am concerned around the challenges surrounding this topic especially around EVM determinism. Could you share more details on how a SC would deterministically "read data" or "listen" to an HCS topic as part of its on-chain execution? More specifically, how would the proposal address scenarios where the state of an HCS topic might change between the time a transaction is simulated and when it's finally executed by consensus nodes?
   b. Does this imply that HCS messages would somehow directly trigger an execution of Smart Contract 2? or when Smart Contract 2 is called by a regular hedera transaction, would it then execute logic to query specific data from the HCS topic? If it's fetching/querying, how would the contract deterministically identify which message(s) to read (eg. by sequence number provided in the transaction or another method)? Curious to hear your thoughts
3. Permissions and Security: If a smart contract is "writing" to an HCS topic that has a submitKey, what were you thinking when it comes for the smart contract to satisfy this permission?

Looks like we're both interested in this topic(with my current focus being a detailed mechanism for deterministic writes - I have a detailed document outlining this), I think there could be some synergy here. Perhaps, we could collaborate somehow to bring a more comprehensive and robust SC-HCS integration solution to Hedera!!

Thanks again for this discussion! I think this is an amazing concept and definitely the community would appreciate.

[walter-hernandez]

Thank you for your thoughtful questions and for sharing your work on the Deferred HCS Message Submission Precompile! I amm excited to see others working on similar ideas. Let me address each of your questions:

1. Your deferred execution approach is excellent! Something along what you proposed would work for submission of messages. This is some pseudo-code to illustrate the idea (be mindful that it may not be fully functional Solidity code and is for illustrative purposes only):

// Precompile address (e.g., 0x167 for HCS operations)
address constant HCS_PRECOMPILE = 0x0000000000000000000000000000000000000167;

contract MyContract {
    function publishEvent(string memory data) external {
        // Stage the message for deferred submission
        (bool success,) = HCS_PRECOMPILE.call(
            abi.encodeWithSignature(
                "submitMessage(bytes32,bytes)",
                topicId,
                bytes(data)
            )
        );
        // Check if the call was successful
        require(success, "HCS submission failed");
    }
}

This would allow to stage the messages during contract execution with actual submission happening after consensus (like you proposed). For the fees for the emission and reading of events in the smart contract, these are possible approches that we could consider:

• The user interacting with a function in the smart contract that triggers the reading or emission of an event is responsible for paying the gas fees associated with that transaction. This means that when a smart contract function is called and it emits an event or reads an event from a topic, the gas cost for that transaction, which includes the event emission/reading, is paid by the caller of the function (https://docs.hedera.com/hedera/core-concepts/smart-contracts/gas-and-fees).
• The smart contract holding a balance of HBARs would cover the gas costs for emitting/reading events, allowing users to interact with the contract without needing to pay for gas fees directly. An sponsor or the contract itself would need to fund this balance.
• Similar to #2, but using the delegate account model for sponsoring transactions, where a delegated account pays the gas fees for the event emissions/reads (https://docs.hedera.com/hedera/sdks-and-apis/sdks/accounts-and-hbar/approve-an-allowance).

2. Yes, the smart contract reading of the event is indeed the trickiest part when considering the execution time between the reading of an event and when the latest event is avilable in a topic. Hopping to not get a bit off topic, but this issue is similar in DeFi with price slippage in AMM-based DEXs where the time-lag between the submission of a trade and the actual execution is affected by the time-lag between blocks confirmation (we researched about this topic: https://arxiv.org/abs/2312.13749). Like in DeFi, an option is to accept the time-lag (which should be minimal in Hedera ~3 seconds) between the reading of the event and the actual execution of a function in the smart contract that pulls the event data. This means that the smart contract would read the latest event data at the time of execution, which may not be the most recent event if it was emitted just before the function call. Of course, this approach would require some consideration.

• Another option is what you suggested about the smart contract using specific sequence numbers or timestamps provided by as a transaction parameter:

// Precompile address (e.g., 0x167 for HCS operations)
address constant HCS_PRECOMPILE = 0x0000000000000000000000000000000000000167;

// External caller specifies which message to process
function handleTopicEvent(bytes32 topicId, uint64 sequenceNumber) external {
    // Contract pulls specific message
    (bytes memory eventData,,) = HCS_PRECOMPILE.getMessageBySequence(topicId, sequenceNumber);
    
    // Process it
    if (isValidEvent(eventData)) {
        executeAction(eventData);
    }
}

• A third option that could reduce the exposure to the time-lag issue is to use a callback mechanism where Smart Contract 2 can register a callback function that is triggered when a new event is emitted. This would require the precompile to support such a mechanism, allowing the contract to be notified immediately when a new event is available and for the contract logic related to this event to be executed right away.

3. For the access of smart contracts into topics, we could consider expand the functionality of private topics to allow specific smart contracts to read from or write to them based on predefined permissions (https://docs.hedera.com/hedera/tutorials/consensus/submit-message-to-private-topic). Currently, private topics are designed for use by accounts using a Submit Key to submit signed messages. We could explore the possibility of defining a set of smart contracts using their contract IDs as authorized readers or writers of private topics, allowing them to interact with these topics in a controlled manner. This would be passing the contract ID as an additional parameter in the TopicCreateTransaction() and TopicUpdateTransaction() methods. Now, within the smart contract, there could be a function to validate the message comes from the right topic before processing, akin to functions in solidity to validate if the sender of a transaction is the owner of the contract before executing certain functions (e.g., require(msg.sender == owner)). For the topic, it could be something like require(topicId) == expectedTopicId before proceeding with the logic in a function. If we follow the precompile approach, this validation could be included in it.

And definitely, we can collaborate on getting a robust HIP proposal! Please, share your thoughts on these ideas, and we can refine them further until we have a proposal that we believe is feasible and beneficial for the Hedera ecosystem

[mgarbs]

Great proposal! I have some questions for the overall specification:

Who pays for HCS topic operations when triggered by smart contracts? The contract deployer, the transaction sender, or is there a new fee model?

What happens if a message is written to a topic that wasn't intended for the contract? Would you restrict the specific contract to being the only entity that can write messages to the topic it creates?

Are there any privacy implications when contract internal state becomes visible through HCS topics?

The proposal doesn't address what happens when HCS operations fail. How do smart contracts handle these potential failures?

The proposal doesn't have the actual API definitions. What specific functions will be available to smart contracts? How will developers interact with this functionality?

Thank you! :)

[walter-hernandez]

@mgarbs I am glad to hear that you like the proposal! I think I may have responded to your questions in the responses to @kpachhai : #1207 (reply in thread) , but please, let me know if there may be something missing or if there is a need for more clarity or to elaborate more in any of the responses

[walter-hernandez]

I realized that I did not respond about HCS failing. If the HCS fails, the smart contract could implement a fallback mechanism similar when a transaction fails fallback() in Solidity, but for the HCS integration. This could involve logging an error event or reverting the transaction with a specific error message indicating the failure of the HCS operation. The smart contract could also maintain a retry mechanism to attempt the operation again after a certain period or under specific conditions, but this would depend on the specific requirements and design of the contract, but for simplicity, we could just log an error event and revert the transaction.