DEV Community: Hedera Team

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

Hedera Team — Wed, 26 Mar 2025 12:28:04 +0000

By Oliver Thorn

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.

Resources
HIP-991 Documentation: https://hips.hedera.com/hip/hip-991

That’s A Wrap on HederaCon 2025

Hedera Team — Mon, 24 Mar 2025 15:37:04 +0000

The inaugural HederaCon 2025–Hedera’s first user conference since 2018–proved that great things happen when the community comes together. On February 25th, more than 600 community members, developers, founders, and industry leaders gathered in Denver for a jam-packed day of industry insights, technical deep dives, and an exploration of the big ideas shaping the digital economy.

Two Tracks, One Vision

HederaCon featured two distinct content tracks: The Mainstage Sessions tackled big-picture discussions on the industry’s most pressing topics, while the Technical Stage provided deep dives into Hedera’s technology, developer tools, and real-world applications.

Whether you were in the audience, watching the livestream, or catching up later, all sessions are available to watch on YouTube—ensuring no one misses out on the HederaCon action and insights.

Inside the Mainstage Sessions

The conference opened with Opening Remarks from Hedera co-founders Dr. Leemon Baird and Mance Harmon, reflecting on Hedera’s journey and its mission bringing trust to different ‘worlds’. They emphasized the community’s role, stating, “Hedera the ledger itself, the platform, is just the plumbing. The real magic is what you build on it”. This inspiring session set the tone for a day of insights and Hedera’s continued role as the trust layer of the digital economy.
In “Cross-Border and More: What's Fueling the Growth of Crypto Payments?” panelists examined the rapid rise of crypto payments, highlighting key drivers behind cross-border settlements, merchant adoption, and real-world use cases.
Speakers: Ahmed Zifzaf (Worldpay), Sushil Prabhu (Dropp), Alisa DiCaprio (Swift)
Moderator: Rob Allen (Australian Payments Plus).
“Why the RWA Megatrend Isn't Stopping Anytime Soon” saw experts examine the growth of real-world assets (RWA) and its impact on global markets in an era where tokenization is reshaping the financial landscape.
Speakers: Edward Nwokedi (RedSwan), Eli Cohen (Centrifuge), Chase Merlin (Brale)
Moderator: Rob Massey (Deloitte)
“How Interoperability Will Unlock the Future” brought together leaders from various different blockchain ecosystems to look at the critical role of seamless blockchain communication and standards, as well as its impact on the industry’s future.
Speakers: David Hawig (Web3 Foundation), Simon Baksys (LayerZero), Maghnus Mareneck (Interchain Labs), James Friel (Axelar)
Moderator: Eric Piscini (Hashgraph)
“AI, Meet DLT: Scaling Responsibly” unpacked one of the hottest topics in the space: how distributed ledger technology (DLT) enables ethical AI development and ensures secure data provenance.
Speakers: Greg Whalen (Prove AI), Jim Nasr (Acoer), Rebecca Liao (Saga), Jonathan Dotan (EQTY Lab)
Moderator: Shyam Nagarajan (Hedera)
“Hello, Future? Reflecting on the Hedera Journey So Far” offered a thoughtful look at Hedera’s milestones, its evolution over the years, and the path forward for the Hedera ecosystem.
Speakers: Miguel Carpena (ioBuilders), Brandon Davenport (Hgraph.io), Greg Scullard (Hashgraph)
Moderator: Brandon Hargreaves (HbarBull)
“Why Wallets Need a Refresh” dove into the key changes needed to streamline the user experience and share how these industry trailblazers are leading the charge in transforming the wallet landscape.
Speakers: May Chan (Hashpack), Jess Houlgrave (Reown), Michael Lewellen (Blockaid)
Moderator: Brandon Davenport (Hgraph.io)
“DLT Pioneers in Conversation: Charles Hoskinson & Dr. Leemon Baird” was a pivotal fireside chat bringing together two blockchain visionaries to discuss the evolution of the DLT space, key industry-wide initiatives such as the DeRec Alliance, and how the industry can collaborate to move forward. i
Speakers: Charles Hoskinson (Cardano), Dr. Leemon Baird (Hashgraph)
Moderator: Ryan Solomon (Genfinity)
“Enabling the Next Wave of NFT Innovation” dug into the technological and infrastructure challenges shaping the future of NFTs.
Speakers: Michael Kantor (KiloScribe), Manu Cabrera (Kabilla), May Chan (Hashpack)
Moderator: Ty Smith (Hashgraph)
“Fireside With Dapper Labs' Roham Gharegozlou” featured a conversation between Roham Gharegozlou and Devin Saxon (Hashgraph), exploring what makes digital collectibles so compelling and how intellectual property remains a frontier for on-chain innovation.
“Fireside With Calaxy's Spencer Dinwiddie” delved into the NBA star’s journey into blockchain, why the team chose to build on Hedera, and how Calaxy is driving innovation in the creator economy space.
“From Combat to Creators: Consumer Use Cases Taking DLT Mainstream” took attendees to the front lines to discover which consumer messages are advancing Web3 adoption and which are missing the mark.
Speakers: Solo Ceesay (Calaxy), Robert Bryan (Karate Combat)
Moderator: David Wachsman (Wachsman)

“The Great Reset: Why US Crypto Policy Is Suddenly Different” featured timely discussions on the shifting regulatory landscape in the U.S. and its impact on crypto adoption.
Speakers: Teresa Goody Guillen (BakerHostetler), Caitlin Long (Custodia Bank), Marta Belcher (Filecoin Foundation)
Moderator: Nilmini Rubin (Hedera)
“Fireside With Linux Foundation's Daniela Barbosa” saw Shyam Nagarajan (Hedera) sit down with Linux Foundation’s Daniel Barbosa to discuss Hedera’s pioneering contribution of its codebase to the Linux Foundation Decentralized Trust under ‘Project Hiero.’
“Swap, Lend, and More: A Look at DeFi on Hedera” featured a panel of builders discussing the factors behind DeFi’s recent growth and what’s on the horizon.
Speakers: Brady Gentile (Bonzo Finance), Thodoris Karakostas (Chainlink Labs), Victor Holotescu (Buidler Labs)
Moderator: Charles Adkins (Hedera Foundation)
“Neuron on the Intersection of DePIN and AI” showcased CEO and Co-Founder James Dunthorne (Neuron) as he explored how Neuron’s aviation technology sets a new standard for safety in the air, and how it leverages the Hedera network for DePin and AI in its use case.
“Wen ETF? Fireside With Canary Capital's Steven McClurg” had Steven McClurg sit down with Gregg Bell (HBAR Foundation) to explore the current ETF landscape, what's next for crypto ETFs, and how global market shifts are shaping the future of this emerging asset class.
“On-Chain Stars: Projects on Hedera and Integrations to Watch” was a deep dive with Hashgraph’s Greg Scullard and Michael Garber at what’s next for the Hedera ecosystem.
The “Closing Keynote” by the HBAR Foundation’s Charles Adkins was a forward-looking keynote discussing the Foundation’s strategic roadmap and a look at what’s ahead in areas such as AI, DeFi and tokenization.
Speaker: Charles Adkins (HBAR Foundation)

Exploring the Technical Track

After introducing developers and builders to the technical stage, Ed Marquez led the audience into the “Hedera 2025 – What’s Next” roadmap session which outlined upcoming advancements in the Hedera technology stack.
Speakers: Richard Bair (Hashgraph), Ed Marquez (Hashgraph)
“Journey of a Transaction: Navigating the Hedera Network” offered a hands-on look at how transactions flow through the Hedera network.
Speakers: Richard Bair (Hashgraph), Jasper Potts (Hashgraph)
“The Road to EVM Equivalence” explored Hedera’s work towards full Ethereum Virtual Machine (EVM) compatibility.
Speaker: Nana Essilfie-Conduah (Hashgraph)
“Lessons Learned Implementing dApps on Hedera: 3 Testing Tips” helped attendees gain actionable insights for building reliable, high-performance dApps on Hedera.
Speaker: Alberto Molina (iOBuilders)
“Smart Contracts in Any Language: How to Onboard the Next Million Developers” was a discussion on making smart contracts more accessible through multi-language support.
Speaker: Grigore Rosu (Pi Squared)

“Pushing the Boundaries of HCS Through On-Graph Content” introduced developers to key Hedera Consensus Service (HCS) standards that facilitate efficient file data management, recursion within the service, and dynamic NFTs.
Speaker: Michael Kantor (KiloScribe)
“Unlocking Programmability on Hedera: The Next Evolution of Payment Infrastructure” focused on how Actalink is revolutionizing programmability on Hedera, enabling developers and enterprises to build next-gen financial infrastructure for payments. Speaker: Sumit Kishore (Actalink)
“Block Streams & Block Nodes: Insights and Implementations” equipped attendees with the knowledge to leverage the technical underpinnings of block streams and block nodes for advanced applications on the Hedera network.
Speakers: Richard Bair (Hashgraph) and Jasper Potts (Hashgraph)
“Hiero: A Vendor-Neutral Home for the Technology of Hedera and Future DLT Standards” gave the audience insights into Hedera’s open governance processes and the best practices that enable us to maintain vendor neutrality.
Speakers: Hart Montgomery (LF Decentralized Trust) and Hendrik Ebbers (Hashgraph)
“Tokenization Unleashed: Exploring HTS, EVM, and Hybrid Models on Hedera” took a deep dive into the future of tokenized assets on Hedera.
Speaker: Ty Smith (Hashgraph)

After a day packed with learning and networking, attendees capped off the experience at The Ħ-Bar after-party, hosted by Hedera and Developer DAO at the iconic Meow Wolf, an immersive art collective known for its interactive installations that blend storytelling and visual art. Attendees immersed themselves in a one-of-a-kind atmosphere, complete with cocktails, snacks, and DJ sets that set the vibe.

HederaCon 2025 was more than just a conference—it was a launchpad for the next wave of innovation in the Hedera ecosystem. Whether you joined in person or are catching up now, the ideas shared will shape what’s next.

Thanks for being a part of this journey as we build the trust layer of the digital economy. Hello future!

How Is Tokenization Changing The Way We Invest?

Hedera Team — Fri, 07 Mar 2025 10:52:14 +0000

Tokenization is a revolutionary way of bridging the gap between real-world assets and the digital economy. In a nutshell, tokenization is about taking something tangible - something like a piece of property - and creating for it a tokenized digital counterpart which can live on the blockchain in perpetuity. This innovation enables such assets to be traded, divided, and managed in ways that were previously not possible.

But why tokenize in the first place? And how does that actually work?

Let's dive into two tokenization approaches, namely NFTs, or non-fungible tokens, and fungible tokens, by exploring the pros, cons and some possible applications of each type and how they fit into the ecosystem of our Real-Estate Investment Trust (REIT) in Web3, which we have introduced in our previous blog post.

The NFT Approach: Unique Assets, Unique Tokens

Consider for a moment that you own a high-rise building with 100 unique apartments; each has a different size, layout, and view, and no two are alike. That is where NFTs excel. On the blockchain, an NFT is one-of-a-kind and therefore a digital asset uniquely qualified to represent a one-of-a-kind property.

In that case, each apartment could be represented by a unique NFT. If you own the NFT for Apartment 12B, that token not only proves your ownership but also becomes entangled with all rights and income due from that exact apartment. Critical metadata on such an NFT may include highly relevant information related to location, floor plan, and even legal documents, making ownership transparent and traceable.

That is how NFTs bring a really interesting level of individuality to real estate tokenization. You are not just owning "part of something"; you are owning a certain asset, with all its quirks and value tied directly to your digital token.

Yet, NFTs are not without their challenges. If there isn't a ready buyer, it becomes difficult to sell a high-value NFT, which might represent an entire apartment. They may also be costly - investing in an NFT of a single apartment may be beyond the capacity of many small investors. Of course, whilst NFT marketplaces or P2P transactions will remove intermediaries such as agents who would charge transaction fees, this NFT version of the apartment would not provide extensive benefits when compared with the current off-chain model.

Another alternative is fractionalized NFTs, where an NFT is split into its fungible units and thus owned by numerous investors. Instead of owning the whole apartment, you could buy a fraction, making high-value assets more accessible and liquid.

Fractional Ownership Made Easy: The Fungible Token Approach

But now, let's change this example. What if, instead of tokenizing each individual apartment one by one, we tokenize the building as a whole? In this case, we would not use NFTs but rather fungible tokens. Fungible tokens are interchangeable and divisible, just like shares in a company. They do not represent any particular part of the building but rather represent the proportional ownership of the whole. Technically, fractionalization can also apply to any real-estate NFT, whether it’s one entire building or just a single apartment. A developer might tokenize a whole building as a single NFT, then split that NFT into small, tradable fractions for investors. Meanwhile, an owner of a single apartment could take the exact same approach, issue one NFT for their unit, then fractionalize that NFT so multiple people can co-invest. The difference is mostly about scale and investment goals: a boutique apartment token is more niche, while an entire building or real-estate fund appeals to a wider base of investors.

Say we tokenize the building into a million fungible tokens. Each token would represent a small fraction of the building, and owning 1,000 tokens entitles one to 0.1% of the rental income and provides exposure to potential appreciation in building value. This would become an attractive proposition for a wide array of investors, including the purpose of ease of trading ownership on decentralized exchanges.

Fungible tokens are excellent in terms of accessibility. They lower the barrier to entry by letting people purchase small, uniform “shares” in a property, which are much easier to trade. The advent of Decentralized Exchanges allows one to trade their fungible tokens against pooled liquidity rather than depending on an order book to match sellers with buyers - thus it’s possible to instantly swap tokens at the current market rate. They don’t grant you ownership of a particular apartment; they just represent a share of the entire property. Also, if additional tokens are created beyond the original supply - due to a lack of checks and robust governance controls - then every existing token becomes worth slightly less of the underlying property. This “dilution” can reduce the value of your holdings.

How Buildings 'R' Us uses both approaches

At Buildings 'R' Us, we use both NFTs and fungible tokens, depending on the type of asset and investment structure. For unique properties, such as a single apartment or a boutique building, NFTs are a natural fit. They offer clarity, transparency, and direct ownership, perfect for investors seeking a tangible connection to their asset.

Fungible tokens are more suitable for larger buildings or diversified property funds; they will make fractional ownership accessible to all investment personas and budgets, and the market more liquid, which is an added advantage that real estate investors usually need. This approach will be combined in a way that will permit targeting different investor profiles for a more versatile ecosystem.

Tokenization Is Just the Beginning

However, tokenization is not all about digital representations of assets but about opening completely new avenues regarding their usage and management. The essence of our REIT ecosystem better unfolds in this direction.

For instance, real estate tokens could be contributed to decentralized exchange liquidity pools. Holders of the tokens could gain fees by providing liquidity, thus offering smoother and more dynamic trading conditions. This makes tokenized assets more versatile and valuable.

The holders can also collateralize their tokens to receive loans. Need cash, but don’t want to sell your stake in a property? Use your tokens as collateral for access to capital. It is this flexibility that enables one to grow their portfolio while still retaining their assets. However, any lending platform will typically require a prudent loan-to-value (LTV) limit, e.g. only allowing you to borrow 50–60% of the property’s current market value. This ensures sudden market changes don’t leave either borrowers or lenders overly exposed. Even tokenized real estate can experience price shifts, and responsible LTV ratios help manage those risks while still giving you access to cash.

And then there's auto-compounding, taking things one step further: rental income and other yields of tokenized properties can be reinvested automatically for maximum returns. With auto-compounding, your investment grows - literally - day and night without any further input.

Beyond rental income, auto-compounders can also reinvest LP (liquidity provider) trading fees or yields from other DeFi strategies. For example, if part of your real-estate tokens are staked in a decentralized exchange pool, you might earn additional trading fees or farming rewards. An auto-compounder can seamlessly reinvest those proceeds too, potentially accelerating growth even further over time.

Real-World Realities: KYC and Connecting Tokens to the Deed

One of the most frequent questions people ask about real estate tokenization is, “Does owning a digital representation of a property actually mean I own the property it represents?” The short answer is yes - but that ownership sits atop a legal structure (like an LLC or trust) which in turn holds the property deed. The tokens you hold represent an actual stake in that entity. This keeps your ownership claim enforceable if, for example, the property ever needs to be sold or refinanced.

Likewise, tokenizing a building doesn’t turn property management into a virtual-only task. Someone still has to manage the day-to-day: collecting rent, paying for maintenance, and renewing leases. That might be a traditional property manager who reports back to token holders, or it could be a DAO making major decisions and hiring local professionals. You’ll see us expand on governance as well as income and expense management in later posts, but rest assured: tokenization doesn’t replace real-world obligations - it just makes them more transparent and efficient.

In many jurisdictions, owning tokenized real estate means verifying your identity (KYC) and abiding by local investment rules. This can affect how many tokens you can hold, or might even restrict purchases from certain locations. While it’s not as frictionless as typical DeFi tokens, it’s the price of ensuring your digital ownership can stand up to legal scrutiny. Fortunately, there are standards like the TREX Standard (ERC‑3643), which we can use to embed these KYC requirements directly into the token itself. This effectively helps us to govern who can buy, sell, or hold tokens, while ensuring that ownership meets local legal standards without leaving the blockchain environment. This approach merges the best of both worlds: decentralized asset management coupled with built-in investor protection.

Wrapping up

Tokenization is not just a buzzword; tokenization enables the democratization of property ownership and makes the investment process seamless and more accessible. The combination of blockchain's clarity with the stability of real estate tokenization opens an opportunity for seasoned investors and new entrants in equal measure.

In our envisioned REIT, this is done by combining the specificity of NFTs, the flexibility of fungible tokens, and the power of DeFi tools like liquidity pools and auto-compounding. Together, these innovations create a smarter, more dynamic way to invest in real estate.

Why tokenize? It's a paradigm shift in the way we think about ownership - providing investors with options, returns, and ultimately tools for growing wealth in unprecedented ways.

In the next blog in this series, we'll dive into expense and revenue management strategies, governance, and price discovery mechanisms (like LBPs and AMMs), uncovering how to answer the question “What’s this building worth to begin with?” For this series, we will gradually introduce the REIT into web3 codebase, as well as experts in the field of real estate investment, real world assets and DeFi. Follow along to discover more.

Additional Reading

Previous Blog Post: How Would We Build a REIT Today Using Web3 Technologies?
Tokeny/T-REX Standard (ERC-3643): An Official Standard for Permissioned Tokens

Announcing the Winners of ETH Denver 2025 Hedera Bounties

Hedera Team — Thu, 06 Mar 2025 13:04:06 +0000

By Ed Marquez

Hedera proudly sponsored the BUIDLWeek hackathon at ETHDenver 2025, bringing together developers to explore blockchain along with other technologies. Hedera hosted challenges for developers in three tracks: Explorers, EVM Builders, and AI & Agents. These challenges offered a total of US$50,000 in prizes.

Winning teams tackled real-world and creative challenges, showing the power of blockchain using the Hedera network.

Hedera AI & Agents Bounty (US$25,000 total):

1st Place (US$15,000): InfoFi (https://devfolio.co/submissions/infofi-45c4)

2nd Place (US$6,000): Index Token – DAO Governance (https://devfolio.co/submissions/hedera-agent-index-token-utilizing-dao-governance-3465)

3rd Place (US$3,000): Pixie AI (https://devfolio.co/submissions/pixie-ai-6544)

4th Place (US$1,000): WWAN Protocol (https://devfolio.co/submissions/wwan-protocol-a16f)

Hedera EVM Builder Bounty (US$20,000 total):

1st Place (US$10,000): ChargeHive (https://devfolio.co/submissions/chargehive-c25b)

2nd Place (US$6,000): Robolingo (https://devfolio.co/submissions/robolingo-8ffb)

3rd Place (US$3,000): TrustDAI – Trusted Decentralized AI (https://devfolio.co/submissions/trustdai-da7a)

4th Place (US$1,000): HedgeWave (https://devfolio.co/submissions/hedgewave-d63e)

Hedera Explorers Bounty: Imagine, Create, Hello Future (US$5,000 total; US$1,000 each):

DreamFi (https://devfolio.co/submissions/dreamfi-abfd)

Thyr (https://devfolio.co/submissions/thyr-d090)

Ava The MultiChain DeFAI Agent (https://devfolio.co/submissions/ava-the-multichain-defai-agent-b640)

NFTs With Benefits (https://devfolio.co/submissions/nfts-with-benefits-b83e)

Stitch AI (https://devfolio.co/submissions/stitch-ai-b362)

A huge congratulations to the winners, and a big thank you to everyone who participated! Your creativity, dedication, and passion made this hackathon fun and special. Every project embodied the bold, innovative spirit of the Hedera developer community, pushing the boundaries of decentralized tech and AI. We can’t wait to see what you build next!

How Would We Build a REIT Today Using Web3 Technologies?

Hedera Team — Mon, 03 Mar 2025 09:45:08 +0000

By Nadine Loepfe

The real estate market has always played - and will always play - a major role in the investment economy, but it’s traditionally been difficult to access. High capital requirements, long transaction cycles, and a general lack of liquidity have always kept real estate investments out of reach for many. But imagine if you could invest in property without requiring large amounts of investment capital, in just a few clicks, no matter where you are in the world?

That’s the potential that Web3 and blockchain technologies bring to the table. Tokenization - the process of creating digital representation of real-world assets - holds the key to making real estate investment more accessible, efficient, and transparent for everyone.

Let’s explore how a modern Real Estate Investment Trust (REIT) could be built today using Web3 technologies. It’s more than just theory; this model could fundamentally reshape how we think about property ownership and investment, democratizing access to one of the world’s most lucrative markets.

Real-World Assets (RWAs): A brief Introduction

First, it should be explained what exactly is meant by the term ‘“real world asset’”; Real world assets are assets - both tangible and intangible - that hold inherent value in the real world in some form. Tangible examples include real estate, infrastructure, and commodities; intangible examples include bonds, stocks, and intellectual property.

If one talks about tokenizing real estate as a real-world asset - as we will expand upon in this article - it refers to creating a digital representation of a property on a distributed ledger which can then be traded, tracked, fractionalized, and more.

Why Tokenize Real Estate?

The real estate investment market is full of inefficiencies. Participation in the market is increasingly inaccessible due to high capital requirements, the asset itself is traditionally considered highly illiquid, and the transactions involved - not to mention the legacy systems that facilitate them - can be slow, expensive, and complex. Through tokenization, these long-standing and systemic issues with the market can be addressed.

First, we have lower entry costs. One does not need to be a millionaire to invest in real estate - as is the case in most real estate markets today. Such tokenization allows owning and enjoying the equity of a fraction of a property, allowing a larger number of investors to participate.

Then, there's increased liquidity. Whereas traditionally - due a huge number of factors - selling out a real estate investment could take months or even years, tokenized assets can be traded on digital exchanges and platforms seamlessly and in a relatively short period, making the process far more dynamic, and the market far more liquid.

And finally, there's global reach. Tokenized real estate allows investors to transcend regional markets. With tokenized properties listed on decentralized exchanges and marketplace platforms, you can reach properties anywhere in other countries and thereby create a diversified portfolio without the traditional geographic constraints of a REIT.

Tokenization and the potential benefits it brings enables us to envision the future of real estate investment; a digital, democratized, and decentralized system built upon distributed infrastructure that creates equity for the economically marginalized and unprecedented efficiency in a market that has been plagued by inefficiencies for decades, if not, centuries.

At the forefront of the emerging revolution is Hedera - bringing enterprise-grade governance, speed, cost efficiency, regulatory compliance, sustainability, and proven use cases that cement itself as a leader not only in the tokenization of real estate, but the tokenization of everything.

So How Would We Build a REIT on Web3 Today?

Now that we understand the basics of RWA, let’s dive into how we would use Web3 technologies to build a decentralized REIT.

ERC Standards and Tokenization

We begin our discussion by providing implementation related to the Web3 token standards - ERC-20 and ERC-3643 - to tokenize real estate. ERC-20 enables the functionality of fractional ownership, which means the ability to split up ownership of a property into tradable shares as explained earlier. Another active area of tokenizing real estate involves taking steps towards compliance with industry regulations.

We can extend ERC-3643 to implement laws related to KYC (Know-Your-Customer) requirements, ensuring that participants are verified investors. This is in high demand for keeping fraud cases at a minimum and, not insignificantly, for meeting a lot of the legal requirements that come into play when high-value assets are involved. Moreover, this geo-blocking can go all the way to blocking certain properties in respect of a user's location to ensure that local and international laws are being followed. This level of control sustains security for the system while at the same time ensuring that compliance is adhered to, therefore allowing for flexibility that is expected to come with decentralized ownership and trade.

Finally, ERC-721 can be used for individual, non-fungible attributes of real estate, such as particular property units, with fractional ownership still made possible.

Governance via DAOs

Next, we introduce distributed governance through DAOs: Decentralised Autonomous Organisations. DAOs give investors a vote on the operation of the fund on everything from property management to new acquisitions and distributions. This model is decentralized, hence ensuring transparency and giving investors greater control over their assets.

Also relevant is the concept of Blockchain Organised Restricted Governance, BORGs in short. A BORG adds a further level of flexibility that can enable different parts of the real estate portfolio to have their own specific form of governance. Some assets can require more centralized control while others are fully decentralized, depending on regulations or investor preferences. By using both DAOs and BORGs, we give investors more power over decisions, making real estate management more transparent and flexible.

Managing Treasury and Revenue

Smarter management of inflow funds is a key component in any REIT. Our Web3 REIT will utilize a treasury and smart contract-mediated distribution of revenue created by the properties to token holders. We can easily ensure appropriate reserves for unexpected expenses and distribute excess profits to investors simultaneously through what's called a “high/low water” system.

Pricing and Liquidity: Solving two Key Challenges

Among the biggest problems that one faces while dealing with real estate investment are pricing and liquidity. In a tokenized REIT, one may have what is called Decentralized Exchanges for price discovery, which include Liquidity Pools (LPs) and Automated Market Makers (AMMs). Investors contribute liquidity, and the AMM adjusts prices based on market demand, offering a more dynamic and transparent pricing model.

Initially, we’ll offer a one-sided marketplace where investors can buy into properties. Over time, this can evolve into a two-sided market, allowing easier buying and selling of property tokens.

Tokenizing a Building: A Step-by-Step Guide

How do we apply these concepts to a single building on a high level? Here’s a simple walkthrough:

First, we’ll model the building: It is tokenized into regulated ERC-20 tokens for fractional ownership. Here each token represents a share in the building. Additionally, we can use a NFT (ERC-721) for the name, address, and visual depiction of the building.

Then funds are raised through a token sale or auction, giving investors a way to determine the building’s initial price.

Then, as the building generates revenue (rent or otherwise), the funds flow into the treasury, where they’re distributed proportionally to token holders.

A Glimpse of What’s Next

Does this sound interesting? This is just the beginning. By integrating more advanced DeFi (decentralized finance) mechanisms, we can create a “fund of buildings”, and combine some of the composability that this technology offers to allow more flexibility.

In further posts, we will discuss each one of those advanced topics in greater detail. We'll cover tokenomics, list some of the active vaults and auto-compounders for managing the funds, and talk about a few challenges like price discovery and regulatory compliance. By examining each of these subjects, we will continue demonstrating exactly how Web3 technologies are impacting real estate investment.

Follow along to learn more!

These are the Winners of the #HelloFuture Hackathon 2.0

Hedera Team — Fri, 28 Feb 2025 10:41:52 +0000

By Ed Marquez

The Hello Future Hackathon 2.0 has come to a close! Between November 11th and December 18th, 2024, hackers from all around the world participated in this event to build incredible projects on Hedera in the areas of AI & Data-Driven Insights, Tokenized Assets, DeFi, Sustainability, Decentralized Identify, and more. Here are the results and the winning teams taking home a prize pool with a total value of $300,000 USD!

🏆 Overall Winners

🥇1st Place: Ecosphere Prime

Creating a decentralized hyperlocal climate intelligence oracle using Web3 technology that will improve the accuracy and accessibility of climate data. IoT sensors form climate nodes, collecting data that is validated and stored on Hedera.

Prize: $35,000 USD

🥈2nd Place: Hashgraph Online

A new open source standard with a LaunchPage builder and smart contracts to help define a new kind of asset class and capabilities for NFTs that are entirely unique to Hedera.

Prize: $25,000 USD

🥉3rd Place: HealthToken.AI

A comprehensive platform for managing consent, data capture, and incentivization in healthcare. At its heart, we have built a tokenization engine to abstract and ease creation and usage of Hedera based tokenization for multiple use cases in healthcare.

Prize: $15,000 USD

🛤️ Track Winners

🧠 AI-Driven Insights and Data Integrity

🥇ACOER Team: BioPharma Tracker is a cutting-edge solution designed to enhance traceability, security, and efficiency within the biopharmaceutical supply chain.
🥈OsmiumLabs: HiD (Hedera Identity) is a decentralized identity platform leveraging Hedera’s eco-friendly DLT to deliver secure, verifiable, and privacy-preserving digital credentials.
🥉HBANK: Hbank is a comprehensive platform designed to empower investors by simplifying the management of Hedera Native Assets.

🏢 Tokenized Assets and Digital Securities

🥇Hedera for Robotics: The first B2B Middleware-as-a-Service, helping industries to design and build custom hubs that connect their Web2-based industrial robotic automation to Hedera and interact with on-chain components seamlessly.
🥈HealthToken.AI: (Also the 3rd Place Overall Winner)
🥉Haras Project: Simplifies equine management, creating secure, transparent records for horse lineage, medical history, and ownership. It reduces fraud, improves trust, and streamlines processes for owners, vets, and auction houses.

🌐 DeFi & AMMs

🥇Hashgraph Online: (Also the 2nd Place Overall Winner)
🥈EtaBridge: Liquidity bridge based on LayerZero protocol.
🥉Arze: An innovative payroll automation platform leveraging Hedera DLT to streamline salary processing for companies of all sizes. Our primary purpose is to tokenize and deliver fast, secure, and transparent salary payments directly to employees' wallets.

🔎 Decentralized Identity and Verifiable Credentials

🥇Decentralized Minds: Medera is an innovative healthcare platform built on Hedera to streamline clinic, pharmacy, and patient interactions. Our primary goal is to enhance trust, efficiency, and security in healthcare services through decentralized identity (SSI) and Hedera.
🥈The Mouth: An advanced decentralized marketing tool that allows projects and brands to reward their community for interacting with their content. This creates an opportunity for community members to monetize their attention and engagement.
🥉BitFlippers: The Decentralised Attendance System aims to revolutionize classroom management by utilizing Hedera's technology for secure, transparent attendance tracking.

🌲Sustainable and Green Finance

🥇Ecosphere Prime: (Also the 1st Place Overall Winner)
🥈GreenDAO: An innovative Software-as-a-Service (SaaS) platform designed to empower communities with trust through the utilization of a decentralized autonomous organization (DAO) framework.
🥉Digitized VM0048 REDD Methodology: Improves upon a digitized version of VM0048 REDD methodology by leveraging Hedera's Guardian Service, which enables quantification and monitoring of emissions reductions from Verra REDD projects.

🧑🏻‍💻 Hashgraph Trailblazers (Advanced)

🥇Hashgraph Online: (Also the 2nd Place Overall Winner)
🥈Hedera for Robotics: (Also the 1st Place Winner for Tokenized Assets and Digital Securities)
🥉The Mouth: (Also the 2nd Place Winner for Decentralized Identity and Verifiable Credentials)

🦸🏽 Hashgraph Legends (Returning)

🥇HashPress Pioneers: Making blockchain more accessible to everyday users by building two WordPress plugins.
🥈Savera: A complete platform for payments, savings, and cards, designed for the Hedera ecosystem, to offer a complete and simple experience to users. Now with a Venmo-like on-chain chat.
🥉HederaP2P 2.0: Welcomes you to a preview of Internet 2.0 and the “Power of the Cloud Without Servers”.

🧗‍♀️ Hashgraph Explorers (Beginner)

🎖️ The Terrific Tokenizer

🎖️DeVault

🎖️Fusion Innovators

🎖️The Digivators

🎖️Noobsoft Gamers

🎖️Team Hedemy

🎖️LEE YEN FEI

🎖️FlexD

🎖️HashLand

🎖️GeoHashGraph

Closing Celebration on February 14th 🎉

Congratulations to all the winners and participants! Your hard work, innovation, and dedication have made this hackathon truly special.

Join us for our virtual Closing Celebration on February 14th! Hear insights and learnings from the overall winning teams, get updates on post-hackathon support, and catch exciting announcements about upcoming events and hackathons like HederaCon, ETH Denver, and more.

Beyond Hedera: How Hiero Sets a New Standard for Decentralized Open-Source Development

Hedera Team — Thu, 27 Feb 2025 12:16:11 +0000

Introduction

In September, 2024 Hedera announced that it is donating its entire codebase, including all Hedera services, development accelerators, and SDKs to the Linux Foundation Decentralized Trust (LF Decentralized Trust) as project “Hiero.” With this groundbreaking move, Hedera became the first Layer 1 public distributed ledger to donate its code to an independent entity, fully embracing a vendor-neutral governance model. The Hedera public ledger now operates as an instance of the Hiero codebase, paving the way for a new era of decentralization.

By transferring the source code to LF Decentralized Trust, Hedera guarantees that the code remains open and independent, free from reliance on a single entity for maintenance. This move also integrates the project into a broader ecosystem of developers at LFDT, encouraging cross-industry collaboration and innovation.

This blog explores the technical and strategic implications of Hedera’s source code donation, including shifts in governance, contribution models, and the broader impact on the Hedera ecosystem.

Why Did Hedera Contribute its Code to the Linux Foundation Decentralized Trust?

The LF Decentralized Trust (LFDT) is the leading force in open-source standards and decentralized technology innovation. As the premier open-source foundation for decentralized infrastructure, LFDT provides a vendor-neutral, collaborative environment where organizations and developers shape the future of distributed ledger technology (DLT), blockchain, and trust systems

By setting industry standards and driving the evolution of decentralized technologies, LFDT accelerates adoption across industries while ensuring interoperability, transparency, and security. Hedera’s contribution to LFDT aligns with its vision of fostering a global, community-driven ecosystem where decentralized networks thrive under open governance and cutting-edge development.

Vendor-Neutral Governance
Hedera will continue to manage and maintain its own instance of the codebase, but the Hiero codebase itself is now governed by the Linux Foundation Decentralized Trust (LFDT). This shift ensures that no single entity—including the select set of entities that participate in Hedera’s decentralised governing council—has exclusive control over future development.

By adopting a vendor-neutral governance model, Hiero opens the door for contributors from diverse industries and communities to participate. This inclusive approach fosters collaboration, innovation, and long-term sustainability, allowing all stakeholders to shape the project’s evolution on equal footing.

Transparent and Open Contribution Model
Hiero will adopt the Linux Foundation’s transparent contribution model, so anyone—whether an independent developer or a major enterprise—can contribute to the codebase and be present at the TSC meetings. See section on Project Hiero Technical Steering Committee (TSC). This inclusivity ensures that diverse input and innovations will form the foundation for increased contributions from various developers, researchers, and organizations interested in decentralized trust systems.

The Linux Foundation’s Collaborative, Global Ecosystem
In 2024, the Linux Foundation achieved significant milestones, reflecting its ongoing commitment to open-source innovation and has reported that over 71,000 developers collaborated globally across more than 1,300 projects, driving advancements in areas such as artificial intelligence, cloud computing, and edge computing.

By joining LF Decentralized Trust, Hiero will tap into a global network of developers and enterprises already engaged with Linux Foundation projects. This open environment fosters faster problem-solving, encourages creative solutions, and eliminates the bottlenecks created by isolated development.

Furthermore, the Linux Foundation’s standardized practices and interoperable tools promote scalability and reuse of technology blocks, ensuring that advances in one project can readily contribute to improvements in another. By breaking down these barriers, Hiero can innovate more freely and efficiently, rapidly integrating advancements across the ecosystem, while also accelerating development and the potential for technological breakthroughs.

Enterprise Support and Credibility
Hiero inherits the Linux Foundation’s credibility, which is supported by the foundation’s globally respected standards and backing from major enterprises. This support will help Hiero attract enterprises and institutions and encourage them to participate in its development and trust the project’s integrity.

Resource Accessibility
The Linux Foundation’s robust infrastructure will make it easier for developers to contribute to Hiero. Tools, documentation, and testing environments will be readily available, reducing the friction for onboarding new developers. By lowering the barriers to entry, Hiero should attract a larger pool of contributors, especially those who may not have otherwise considered participating in a blockchain project.

Setting a New Standard: LF Decentralized Trust as a Model for Decentralized Open-Source Development

Hiero’s integration into the LF Decentralized Trust sets a precedent for other decentralized protocols in the crypto world that are grappling with governance issues, siloed operational structures, and a lack of industry standards. Through LF Decentralized Trust vendor-neutral governance, Hiero ensures that project development is guided collectively.

LF Decentralized Trust’s focus on interoperability and standardized practices sets a regulatory-ready framework, offering other crypto protocols a clear route to achieve scalability, compliance, and industry credibility. Hiero’s journey showcases how aligning with the LF Decentralized Trust can empower decentralized projects to overcome common obstacles, paving the way for sustainable, community-driven growth within a cohesive and innovative ecosystem.

How Will Hiero’s Codebase Be Maintained?

Projects under the LF Decentralized Trust are expected to promote the establishment of a Technical Steering Committee (TSC) according to specific governance guidelines. The TSC plays a vital role in overseeing each project's technical aspects, including setting the project’s technical direction, managing contributions, and ensuring code quality.

The Linux Foundation emphasizes that open-source projects should adhere to governance structures like TSCs to ensure transparency, collaboration, and technical excellence.

Project Hiero Technical Steering Committee (TSC)
The TSC is the governing body that oversees all of Project Hiero’s technical aspects. It ensures the project's integrity and alignment with its open-source community. The TSC facilitates collaboration among contributors, committers, and maintainers, helping to ensure the project's quality, security, and evolution.

Open Governance and Meetings
The TSC operates transparently, with all meetings open to the public. These meetings will be conducted and recorded on Zoom. Anyone is welcome to attend. This openness ensures that the community can actively engage with the TSC’s discussions, provide insights or feedback, and reinforce the project's open-source ethos. Furthermore, the meeting minutes will be available to everyone in this GitHub repository.

The composition of the TSC is documented in the Hiero-ledger/tsc repository, allowing anyone to see the individuals who are responsible for leading Project Hiero.

Election of TSC Members
The TSC will consists of nine (9) members who are selected from various groups within the community:

Dr. Leemon Baird holds a permanent seat as the inventor of the hashgraph algorithm.
Hedera Hashgraph, LLC will hold a transitional seat during the project’s initial three years.
Maintainers from the project and its sub-projects collectively elect three members.
Contributors who have been active in the past year elect one representative.
An End User, defined as someone primarily using the project’s software, is elected by a process defined by the TSC.

During the project’s early startup period, the initial TCS members elect additional seats, helping to ensure a balance of interests and technical expertise. The current members of the TSC include Dr. Leemon Baird, Richard Bair, Hendrik Ebbers, Stoyan Panayotov, Alex Popowycz, and George Spasov.

Responsibilities of the TSC
The TSC’s responsibilities encompass a broad range of governance and operational tasks that guide the development of Project Hiero. These include:

Technical oversight: Ensuring the health and security of the project by reviewing and approving system or project proposals.
Project organization: The TSC may create, promote, or deprecate sub-projects as necessary, ensuring a flexible and scalable project structure.
Workflow management: Establishing and enforcing procedures for submissions, reviews, and archiving projects or contributions.
Representation: The TSC appoints representatives to collaborate with other open-source communities or standards bodies.
Community building: The TSC’s responsibilities include establishing norms, managing release cycles, and implementing security policies to ensure the project’s long-term success.

TSC Voting and Decision-Making
Although the TSC operates primarily on a consensus basis, formal votes are sometimes necessary to move the project forward if consensus cannot be reached. In these cases, each active TSC voting member casts one vote. A quorum for TSC meetings is defined as two-thirds of the voting members. If the votes don’t resolve the issue, any member can escalate the issue to the Series Manager for assistance.

This structured yet flexible governance ensures that the project remains adaptable, transparent, and community-driven. The TSC provides the necessary technical leadership to guide Project Hiero forward.

The New Contribution Model

The Hiero Improvement Proposal process replaces the original Hedera Improvement Proposal (HIP) process, though the mechanics remain largely the same. Anyone in the community can submit proposals for features, bug fixes, or optimizations. These submissions undergo a rigorous review process involving contributors, committers, and maintainers.

The Process Remains the Same
Anyone in the community can create, discuss, and submit a proposal for review. When Hedera previously owned the codebase, the Technical Committee (a subcommittee of the Hedera governing council) was responsible for reviewing and approving the HIPs. Moving forward, the TSC will oversee the approval process and create a roadmap based on the proposals. Contributions and collaboration from the entire community, including Hedera, are welcome. Hedera’s Technical Committee will accept HIPs for implementation on the Hedera instance which will now be separate from the Hiero instance.

There are various contributor roles, each with specific responsibilities.

Contributor:

Responsibilities: Any individual who submits code, documentation, or other improvements to the project. Contributors typically don’t have direct commit access to the project’s repositories.
Access: Submit changes through pull requests or patches, which are reviewed by higher-level roles.
Involvement: Contributors can propose new features, fix bugs, or enhance documentation that improves the project, without decision-making authority.

Committer:

Responsibilities: Review contributions and merge accepted changes to the project’s repository, ensuring quality and standard compliance.
Access: Committers have direct write access to the repositories and review pull requests.
Involvement: Trusted contributors who consistently improve the project and follow its guidelines, serving as gatekeepers for integrated code.

Maintainer:

Responsibilities: Oversee the project’s health and direction, make high-level governance decisions, and contribute to strategic development.
Access: Have the highest level of authority, including the power to approve major changes, assign tasks, manage releases, and resolve disputes.
Involvement: Guide project evolution, set priorities, and ensure alignment with broader ecosystem goals, overseeing contributors and committers.

Flow of a Proposal Through These Roles
Here’s how a proposal flows through the different roles at LFDT:

Proposal Submission by a Contributor - A contributor proposes a feature, bug fix, or improvement by opening a pull request or issue, including necessary documentation, code changes, or ideas.
Review by a Committer - A committer reviews the proposal with the purpose of checking code quality, documentation, project standards, and alignment with goals. The committer may request changes, improvements, or clarifications before approval.
Oversight by a Maintainer - Maintainers review significant proposals, especially those affecting the project’s direction, and may provide input before final approval. For major changes, maintainers need to give explicit approval.

Hedera's Autonomy
Hedera TechComm is a **subcommittee of the Hedera Governing Council **responsible for overseeing the technical roadmap, reviewing proposals, and ensuring the development of the Hedera network aligns with its strategic goals.

Before Hedera donated its codebase to the Linux Foundation Decentralized Trust (LFDT) as Project Hiero, TechComm played a key role in evaluating and approving HIPs, which introduced new features, optimizations, or protocol changes to the network.

With the transition to Hiero, the governance of the core codebase now falls under the Hiero Technical Steering Committee (TSC). However, Hedera TechComm remains active—it still reviews and approves HIPs that impact the Hedera network specifically, ensuring that updates to its instance of the Hiero codebase meet the network’s operational and security standards.

Key Responsibilities of Hedera TechComm:

Reviewing and approving Hiero Improvement Proposals for implementation to the Hedera instance of the Hiero codebase.
Maintaining Hedera’s instance of the Hiero codebase.
Ensuring network security, stability, and scalability.
Overseeing testing and deployment of approved changes to Hedera’s network (testnet, previewnet, and mainnet).
Collaborating with the Hiero TSC to align development efforts while maintaining autonomy over Hedera’s implementation.

Essentially, Hedera TechComm continues to govern Hedera's version of the Hiero codebase, ensuring it evolves in alignment with the network’s needs while benefiting from contributions made to Hiero under LFDT governance.

Forking and Compatibility
In rare cases, Hiero may implement code that doesn't work with Hedera, requiring a separate version (fork) of the codebase. However, this is unlikely, as Hiero's main goal is to support the growth of the Hedera network and ecosystem.

Build and Release Process
The TSC will have its own build, testing, and release processes, but Hedera will continue to maintain its independent systems for testing and deployment. Hedera will manage deployments to its testnet, previewnet, and mainnet, ensuring each build meets Hedera’s requirements. As a community member, Hedera participates in the TSC along with others.

Developer Contributions

First-Time Code Contributors
For those who are new to contributing to Hiero or any open-source project, Hedera designated certain issues with the label “good first issue,” which are specifically reserved for first-time contributors. Hedera understands that creating the first pull request can feel daunting, so these labeled issues are intentionally less complex, making them ideal for new developers and those who are exploring open source for the first time.

Developer Certificate of Origin
To have contributions considered and to adhere to the Linux Foundation’s standards, each code commit must include a Developer Certificate of Origin (DCO). This certifies that the contributor has the legal right to submit the code—either as the original author or with permission from the original author—and grants the project permission to use the contribution under the project's license. Refer to the CONTRIBUTIONS.md file in the project’s repository for detailed contribution guidelines. The committer must also have GPG keys set up on their account.

GPG Keys
Each contributor must also have a GPG key associated with their GitHub account. A GPG key is a cryptographic key pair that is used to sign and verify digital communications, ensuring authenticity and data integrity. At the Linux Foundation, GPG keys are necessary for verifying contributors' identities, protecting code integrity, and fostering trust in open-source projects by preventing unauthorized changes.

Contributors can maintain anonymity by using pseudonyms or alternate email addresses, but they must associate their GPG key with their GitHub account. This ensures that contributions are securely signed and verified without revealing personal information.

Conclusion

The migration of Hedera’s codebase to the LF Decentralized Trust Hiero project represents a forward-thinking step toward open, collaborative development in decentralized technology. By adopting the LF Decentralized Trust vendor-neutral, transparent governance, Hiero empowers contributors from all backgrounds to drive the project forward, fostering a thriving ecosystem around hashgraph technology. This move sets a new standard for decentralized open-source development and aligns with the growing need for interoperable, community-driven solutions in the blockchain and DLT spaces. As contributors, organizations, and developers continue to shape Hiero, we’re witnessing the dawn of a more inclusive, impactful open-source future. Join us as we build it together.

ioBuilders Helps Transform Digital Assets on Hedera through Asset Tokenization Studio

Hedera Team — Wed, 26 Feb 2025 12:32:55 +0000

By: Alberto Molina, Mario Francia, Miguel Gomez & Marcos Serradilla.

Hedera's Asset Tokenization Studio is a newly launched open-source solution designed to streamline the process of converting real world assets, such as equities and bonds, into digital tokens. Built on the Hedera Hashgraph network, Asset Tokenization Studio leverages Hedera's unique technological advantages - low latency, and advanced security - enabling fast, secure, and efficient tokenization of assets. Its customizable templates and built-in compliance features simplify the creation, management, and trading of tokenized assets on a decentralized ledger, making it easier for organizations to enhance liquidity, transparency, and regulatory adherence. By utilizing Hedera's predictable transaction costs and governance by global organizations, Asset Tokenization Studio ensures a scalable and trusted platform for enterprises seeking to modernize asset management through secure and compliant tokenization solutions.

Functionalities

Hedera's Asset Tokenization Studio allows for the deployment and management of equities and bonds out of the box, with the flexibility to be extended to include any other type of real-world asset.

The ERC1400 asset standard serves as the foundation, with additional functionality built on top of it. Some features are common across all asset types, while others are specific to particular asset categories.

Common functionality

Access Control: Roles are defined for every management operation (outlined below), ensuring that only accounts with the appropriate roles can execute these operations.

Cap: The number of assets that can be minted is limited to a maximum amount.

Control List: A blacklist or whitelist can be activated for specific assets, preventing certain accounts from transferring or receiving those assets.

Controller: Authorized accounts can enforce transfers and redemptions from token holders. This feature is inherited from the ERC1400 standard.

Documentation: Links to off-chain documents (e.g., PDFs, images) can be added to an asset. This functionality is also inherited from the ERC1400 standard.

Partitions: Assets can be divided into partitions. Tokens within the same partition are fungible with each other, but tokens in different partitions are not. While this feature can be useful in specific scenarios, assets can also be deployed with a single partition for simplicity. This is inherited from the ERC1400 standard.

Lock: Users' assets can be locked for a specified period, during which they remain in the user's balance but cannot be transferred or redeemed.

Pause: The asset can be paused, disabling all operations until it is unpaused. This feature is intended for use in emergency situations, such as a hacking attempt.

Snapshots: Token holder balances can be captured at any point in time and stored on the blockchain, allowing other smart contracts to access balances from a specific moment in the past.

Equities functionality

Dividends: Dividends can be scheduled for a future date. The system requires a record date, execution date, and the dividend amount per unit of the asset. The record date triggers an automatic on-chain snapshot of all token holders' balances at that time. Both the execution date and the dividend amount are stored on-chain, allowing external systems to use this information, along with the snapshot, to execute the actual dividend payments.

Voting Rights: Voting rights function similarly to dividends. A record date and arbitrary data are provided. The record date triggers an automatic on-chain snapshot, which captures the token holders' balances. These balances can be used by external systems (on-chain or off-chain) as voting power in election processes. The arbitrary data field allows for storing any information related to the voting process for transparency.

Bonds functionality
Coupons: Bond coupons are similar to equity dividends, with a record date, execution date, and a coupon rate, which represents the annual interest rate (percentage). A unique feature of bond coupons is the ability to automatically set future coupon dates at the time of the bond's initial deployment. If a coupon frequency and a first coupon record date are provided, the system will automatically calculate all subsequent coupon record dates.

Technical overview

Solution's Architecture
The overall architecture of the solution is divided into three components:

Smart Contracts: Deployed on Hedera, these contracts enforce the functionalities mentioned above, manage balances, and handle other on-chain operations.
TypeScript SDK: This SDK allows any user-facing application to seamlessly interact with the smart contracts.
React Front End (DApp): Built using the SDK, this user-friendly interface provides an intuitive and efficient way for users to deploy and manage Real-World Assets (RWAs).

Smart Contracts
The most compelling aspect is the robust set of smart contracts designed to support the solution and enforce management and compliance restrictions directly on-chain.

Architecture
The solution implements a tiered architecture, divided into three distinct layers as follows:

Layer 1: This foundational layer contains all the common functionality for assets (described earlier). It extends the ERC1400 standard by adding modular components, each representing a specific feature, such as access control, cap limits, control lists, and more. However, this layer alone cannot be used to deploy any assets, as it lacks the necessary functionality for real-world assets (RWAs), such as dividend management for equities.

Layer 2: At this level, actual generic assets are defined. Currently, only equities and bonds have been implemented. This layer inherits all functionality from Layer 1 and introduces additional features tailored to each asset type (as described earlier). Nevertheless, these generic assets are not fully ready for real-world deployment, as they do not yet account for jurisdiction-specific regulations and requirements, which are often necessary for compliance.

Layer 3: The third and highest layer allows for the customization of Layer 2 generic assets to meet the regulatory requirements of specific jurisdictions. This customization reuses all the generic functionality provided by the lower layers. For instance, U.S. regulations like Reg S and Reg D have been incorporated, with regulatory definitions stored on-chain. Some of these rules, such as Reg D's "release hold period," can even be enforced directly on-chain.

Each layer can be extended further:

Layer 1 can be expanded to introduce additional common functionality.

Layer 2 can be extended to add new generic asset types or enhance existing ones.

Layer 3 can be modified to support new jurisdictions or extend jurisdiction-specific functionality.

Additional layers can also be implemented on top of Layer 3 if needed to meet further requirements.

Factory pattern
Assets are deployed through a pre-deployed factory smart contract, although anyone has the option to deploy their own factory and use it.

When someone wants to deploy a new equity or bond, they can invoke the corresponding deployment method on the factory. This action will deploy a new smart contract on-chain that represents the asset. The newly deployed contract is actually a “resolver proxy” (explained in

detail below). This means that while all asset-related data (e.g., balances, roles, etc.) is stored in the contract's local storage, the actual business logic resides elsewhere.

The pre-deployed factory is actually a transparent proxy managed by a proxy admin, enabling the owner to update its functionality or fix bugs as needed. It's important to note that while the factory is responsible for deploying new assets, it has no control over the assets once they are deployed.

Diamond-Resolver pattern
To avoid code duplication on the DLT, bypass the 24KB size limitation of smart contracts, and ensure code upgradeability, the “diamond resolver” pattern is employed.

This pattern is very similar to the traditional diamond pattern, where a proxy delegates incoming calls to different implementation contracts, known as facets, based on the function selector of the incoming call. However, it introduces a key enhancement that makes it particularly suited for the Real-World Asset (RWA) use case, where potentially millions of assets may be deployed on-chain: unlike regular diamond proxies, the diamond loupe and diamond cut functionality are centralized in a single resolver smart contract. When a proxy receives an incoming call, it contacts the resolver to determine which facet it should delegate the call to.

This approach allows for seamless business logic updates across multiple assets. Instead of updating each individual proxy, admins only need to update the resolver. All proxies that reference the resolver will automatically reflect the updated business logic.

While the full details of the diamond-resolver pattern are beyond the scope of this article, it’s worth noting that if an asset’s admins prefer to stick with a specific version of the business logic rather than follow the latest updates in the resolver, they can configure the resolver-proxy to lock to a particular version.

The resolver contract, like the factory contract, is a pre-deployed smart contract (though users have the option to deploy their own resolver if needed). It operates as a transparent proxy managed by a proxy admin, allowing the owner to update its functionality or fix bugs as required. The management of facet addresses is restricted to authorized accounts to ensure security and control.

Unlike the factory, the resolver plays a crucial role in the ongoing operation of deployed assets, as it dynamically determines how they function. This makes its management critical to the proper functioning of the entire solution.

Storage structure
Most modules require persistent storage for variables within the resolver proxy's storage. To prevent conflicts and the associated security and functionality risks, it is essential to properly isolate each module’s variables from those of other modules.

The solution to this challenge is the use of “unstructured storage”, which operates as follows:

Each module is assigned a unique starting storage slot, similar to an offset, which is determined by hashing the module’s unique Fully Qualified Domain Name (FQDN). The module’s first variable is stored at this calculated slot, and subsequent variables are stored sequentially in ascending order from there.

Conclusion
The Asset Tokenization Studio is a highly flexible and transparent solution for deploying real-world assets (RWAs) on-chain. Its layered architecture, spanning from common functionalities to jurisdiction-specific customizations, provides a robust foundation that can be expanded and upgraded as needed. This structure allows for the seamless integration of new asset types or regulatory frameworks, making it adaptable to a wide range of use cases. Moreover, the built-in control lists and compliance mechanisms ensure that the Asset Tokenization Studio remains fully adaptable to evolving regulations, offering organizations the ability to maintain control over assets while ensuring compliance. As a result, the Asset Tokenization Studio is an ideal technical solution for enterprises looking to modernize asset management in a secure, scalable, and regulation-friendly environment.

Throttling in Hedera: Ensuring Stability and Fairness

Hedera Team — Mon, 10 Feb 2025 17:39:30 +0000

By Mica Cerone & Mark Blackman

Hedera is dedicated to maintaining network stability while ensuring fair and permissionless availability for all users. One way that Hedera achieves this is by using throttles, which regulate the rate at which operations (transactions and queries) are processed, both across the network and locally at individual nodes.

This blog offers a comprehensive technical overview of Hedera's throttles, explaining their purpose, functionality, and configuration.

Why Have Throttles?
Throttles regulate the rate of processing operations to ensure network stability and availability. They safeguard the network from being overwhelmed by excessive traffic or targeted by Denial of Service (DoS) attacks.

Hedera’s throttles serve to:

Prevent overloading of the network or individual nodes.
Ensure fair resource usage across all users and operations.
Maintain predictable transaction processing availability and performance.
Control the growth of the state size, ensuring long-term scalability and cost efficiency for the network.

Hedera’s throttles are configured via a throttles.json file within the Hedera Services repo. An example of a Hedera mainnet throttle can be found here. Throughout this blog, we’ll reference the syntax of this JSON file to illustrate how throttles are defined and applied.

Leaky Bucket

Hedera's throttling system is conceptually modeled after a bucket with a leak at the bottom. The total volume of the bucket represents its maximum capacity; as water (representing operations) drains through the leak, more capacity becomes available for new operations. If the bucket is full, operations are throttled by the bucket.

More specifically, a bucket is a logical container that groups specific operations and enforces a limit on the rate at which those operations can be processed—known as a rate limit. The rate limit defines the average number of operations per second) that the bucket can sustain over time. This steady-state rate reflects how consistently the bucket "drains," dictating how frequently new operations can be accepted.

In the throttles.json file, rate limits can be expressed as:

opsPerSec: Specifies the transactions per second as a whole number.
milliOpsPerSec: Specifies a finer-grained rate by dividing the value by 1,000.

When an operation is rejected by a throttle, the system will respond with a status code of BUSY.

Example Configuration
Here’s a bucket configuration example, simplified for understanding:
{ "name": "XYZ", "opsPerSec": 10, "milliOpsPerSec": 0, "operations": [ "FileGetContents", "FileGetInfo", "ContractGetInfo" ] }

From this configuration:

The bucket name is XYZ.
The rate limit is set to 10 operations per second (no finer rate is specified since milliOpsPerSec is 0).
The bucket applies to three Hedera operations: FileGetContents, FileGetInfo, and ContractGetInfo.

The XYZ bucket can support any combination of these FileGetContents, FileGetInfo, and ContractGetInfo operations, but only at a sustained rate of 10 operations per second.

Network vs. Node Throttles

It’s important to understand that a bucket’s rate limit is applied at both the network and node levels. The values specified in throttles.json represent the network-wide rate limit for each bucket.

For example, in the XYZ bucket configuration:

The network-wide rate limit supports 10 operations per second for FileGetContents, FileGetInfo, and ContractGetInfo.

At the node level, the throttle is calculated by dividing the network-wide rate limit by the total number of active nodes in the network. For instance, if there are 5 nodes in the network:

This ensures that each node can independently process these operations at a sustained rate of 2 operations per second.

Network and node throttles serve distinct but complementary purposes in Hedera's system:

Network Throttles:
- Manage the total transaction capacity across all nodes to ensure system-wide stability and prevent overloading
Node Throttles:
- Divide the network's capacity equitably among nodes, ensuring no single node monopolizes system capacity

Throttle Groups

Buckets in Hedera’s throttling system can contain one or more throttle groups, allowing a bucket to enforce multiple rate limits across different sets of operations. This flexibility ensures that specific types of operations are throttled independently, even when they share the capacity of a bucket.

Throttle groups allow fine-tuned rate limits across different transaction types within a bucket. Also, by separating operations into groups, resources can be distributed more effectively to meet network needs.

Here’s an example of a bucket with multiple throttle groups:
{ "name": "ABC", "throttleGroups": [ { "opsPerSec": 0, "milliOpsPerSec": 2000, "operations": [ "CryptoCreate", "NodeCreate" ] }, { "opsPerSec": 0, "milliOpsPerSec": 5000, "operations": [ "ConsensusCreateTopic" ] }, { "opsPerSec": 0, "milliOpsPerSec": 100000, "operations": [ "TokenCreate", "TokenAirdrop" ] } ] }

Understanding the Configuration

Bucket Name: ABC.
Throttle Groups:
- Group 1:
  - Operations: CryptoCreate, NodeCreate
  - Rate Limit: 2 operations per second (2000 milliOpsPerSec ÷ 1000 = 2 opsPerSec).
- Group 2:
  - Operations: ConsensusCreateTopic
  - Rate Limit: 5 operations per second (5000 milliOpsPerSec ÷ 1000 = 5 opsPerSec).
- Group 3:
  - Operations: TokenCreate, TokenAirdrop
  - Rate Limit: 100 operations per second (100000 milliOpsPerSec ÷ 1000 = 100 opsPerSec).

Each throttle group has its own independent rate limit but shares the overall capacity of the bucket. When operations enter the system and are associated with a specific throttle group, the operation is applied to the bucket’s capacity at the rate limit defined in the throttle group.
Example Usage of Bucket ABC
If the ABC bucket is initially empty, it can service any combination of operations within the defined rate limits. Here are a few examples of valid combinations of operations:

2 CryptoCreate (Group 1).
1 NodeCreate and 1 CryptoCreate (Group 1).
5 ConsensusCreateTopic (Group 2).
50 TokenCreate and 1 CryptoCreate (Groups 3 and 1).
100 TokenAirdrop (Group 3).

Multi-bucket Configuration

While throttle groups offer fine-grained control over resource allocation, relying on a single bucket introduces the risk that one specific operation could monopolize system resources. This could lead to unfair usage and reduced availability for other operations. By implementing a multi-bucket configuration, you can ensure a fair distribution of resources and maintain availability for various operations.

In a multi-bucket setup, an incoming operation is applied to one or more bucket(s) that include it in a throttle group. The operation is accepted only if all associated buckets have sufficient capacity. If any of the buckets are full, the transaction is rejected.

This approach allows for more sophisticated throttling, ensuring no single operation can overwhelm the system.

Burst Period

As mentioned earlier, the rate limit represents the average number of operations per second, reflecting the steady-state capacity of the network. However, network usage is rarely consistent and often fluctuates due to periods of high or low activity.

The burst period feature allows nodes to temporarily exceed their steady-state rate limit for a defined period. This means multiple seconds’ worth of throttle capacity can be utilized in a single second. The system continuously tracks usage to ensure that, even with burst periods, the average number of operations per second remains aligned with the configured rate limit over time.

The burst period is particularly valuable for throttles with very low rate limits, especially when the per-node capacity is less than one transaction per second. By configuring a burst period, nodes can execute these low-frequency operations during the designated burst window, ensuring they are processed periodically while still adhering to the long-term average rate limit.

Here’s an example of a burst period configuration:
{ "burstPeriod": 0, "burstPeriodMs": 15000, "name": "123", "throttleGroups": [ { "opsPerSec": 0, "milliOpsPerSec": 2000, "operations": [ "CryptoCreate", "NodeCreate" ] } ] }

For this configuration, we see:

Bucket Name: 123
Throttle Group: Contains operations for CryptoCreate and NodeCreate.
Rate Limit: The throttle group has a rate limit of 2 operations per second (2000 ÷ 1000).
Burst Period: Configured for 15 seconds (15000 ÷ 1000). This value can be defined in seconds (burstPeriod) or milliseconds (burstPeriodMs).

If this configuration is applied to a 10-node network, here’s the impact that the burst period would have at the node level:

The per-node rate limit would be 0.2 operations per second (2 operations per second ÷ 10 nodes).
During the burst period, each node could accumulate throttle capacity for up to 15 seconds at the steady-state rate.
This allows a node to process a burst of 3 operations during the burst period (15 seconds × 0.2 operations per second = 3 operations).

EVM Throttles

For EVM-related operations, an additional throttle mechanism is used. Rather than throttling by operations per second, EVM throttles are expressed in gas per second. This better reflects the consumption of resources performed to execute the operation. Specifically, ContractCall, ContractCallLocal, and ContractCreate operations are subject to these throttles.

EVM related operations include two separate throttles:

Frontend Throttle: Regulates the maximum gas per second for incoming gRPC transactions at the node level. The transaction is rejected with a status code of BUSY.
Consensus Throttle: Enforces the maximum gas per second during the execution of transactions at the Hedera consensus level. It is analogous to Ethereum’s Block Gas Limit. The transaction is rejected with a status code of CONSENSUS_GAS_EXHAUSTED. EVM throttles are not configured through throttles.json; instead, they are configured using two global dynamic properties configured from Hedera file 0.0.121:

contracts.frontendThrottleMaxGasLimit: Defines the frontend throttle limit for maximum gas per second.
contracts.consensusThrottleMaxGasLimit: Specifies the consensus throttle limit for maximum gas per second.

Please note: Contract-related transactions can still be subject to the standard opsPerSec buckets where contract-related operations are listed. These buckets operate independently and may reject transactions based on the configured operations-per-second limits.

Conclusion

Hedera’s throttling system is vital to its network infrastructure, ensuring stability, fairness, and efficient resource utilization across diverse operations. As the network grows and evolves, we anticipate that system throttling will continue to adapt to better safeguard critical resources while maintaining full availability and optimal performance for users.

Optimizing Cost Control: Introducing the Tiered HBAR Rate Limiter for Hedera JSON-RPC Relay

Hedera Team — Wed, 05 Feb 2025 11:27:04 +0000

By Mica Cerone

Introduction
As the Hedera ecosystem continues to grow, operators of the Hedera JSON-RPC Relay face new challenges, particularly in managing the costs associated with user transactions—especially in public environments. Imagine this: you have allocated a daily, monthly, or yearly HBAR budget and want to ensure it isn’t exceeded. Everything is running smoothly until certain users start submitting abnormally high-cost transactions. These transactions quickly deplete your HBAR resources, leaving less for other users and leading to an unfair distribution of the budget.

To address this challenge, we have re-engineered our previous HBAR rate limiter. The earlier version simply tracked a single total limit over a specified period. In contrast, the new design introduces a customizable Tiered HBAR Rate Limiter, integrated into the relay, allowing for more granular control and flexibility in managing rate limits. This new feature empowers operators to take control of their spending by categorizing users into tiers with defined spending limits.

In this blog post, we’ll explore how this tiered approach works, why it matters, and how operators can use it to protect their financial resources while supporting the Hedera ecosystem.

Understanding the Economic Model
Before diving into the functionality of the HBAR rate limiter, let’s establish some context regarding the relay’s economic model and how it compares to similar systems, such as Ethereum.

The Role of the Hedera JSON-RPC Relay

The Hedera JSON-RPC Relay serves as a critical bridge, connecting EVM-based applications to the Hedera network. By translating Ethereum Virtual Machine (EVM) JSON-RPC calls into Hedera-compatible requests, the relay enables dApp developers to leverage Hedera’s benefits seamlessly without modifying their existing codebases. These codebases are often built using third-party tools developed for the Ethereum network, such as Ethers.js and Web3.js.

EVM Equivalence and Gas Costs
To maintain EVM equivalence, gas costs charged to users reflect the computational work required, similar to Ethereum. However, in addition to executing transactions within the EVM, certain operations require additional Hedera File Service (HFS) transactions to process large requests.

Who Pays for These HFS Transaction Fees?
Currently, the relay operator bears the costs of these additional HFS transactions. In most cases, these costs are negligible. However, some users may repeatedly deploy large contracts (requiring multiple file transactions on Hedera) or submit high transaction volumes. Without a proper rate-limiting mechanism, these activities can lead to costs that exceed an operator’s initial estimates, quickly becoming unsustainable.

Introducing the Tiered HBAR Rate Limiter
To address these cost management challenges, we developed the Tiered HBAR Rate Limiter. By assigning different spending limits to users based on their tier, we enable sustainable and predictable cost management while still supporting the network’s growth.

How Does the Tiered System Work?
The tiered system assigns users (or groups of users) to specific HBAR spending plans tailored to their behavior and contribution to the network. Think of it like Netflix subscriptions—spending plans can be assigned individually or to groups, similar to personal and family subscription categories.

Basic Tier: General Users
By default, every new user who sends a request to our relay is automatically assigned a unique spending plan under the BASIC tier (Tier 3).

Extended Tier: Supported Projects
Users who exceed the usual activity levels but contribute significantly to the network may qualify for an EXTENDED tier (Tier 2) spending plan.

Privileged Tier: Trusted Partners
The PRIVILEGED tier (Tier 1) is reserved for strategic or critical partnerships, providing users with a significantly higher spending limit.

Configuring the Rate Limiter
Operators can fine-tune the rate limiter to match their specific needs. The relay’s documentation provides a comprehensive guide to configuration options.

Explore the detailed configuration guide in this GitHub repository.

Benefits of the Enhanced HBAR Rate Limiter

Cost Control: Operators can define and enforce spending limits for different user groups, ensuring expenses remain manageable.
Flexibility: High-value users or strategic projects can receive additional resources while maintaining overall budget discipline.
User Management: With monitoring tools, operators can easily track activity, adjust user tiers, and allocate resources efficiently.
Transparency: By clearly communicating spending tiers, operators set user expectations and encourage responsible usage.

Conclusion
The newly redesigned HBAR rate limiter is a powerful tool for JSON-RPC Relay operators to control costs and manage user activity effectively. By assigning tiered spending limits to different user groups, operators can support the growth of the Hedera ecosystem while safeguarding their financial resources and ensuring fair allocation.

Call to Action
If you're a relay operator, we encourage you to explore the new rate limiter features and consider how they can benefit your operations. For users, understanding these tiers can help align your activity with operator policies and optimize your interaction with the Hedera network.

Check out this GitHub repository for a detailed configuration guide.

Davos 2025: A Watershed Moment for Hedera and the Future of Tech

Hedera Team — Fri, 31 Jan 2025 09:33:59 +0000

By Monique Morrow

As the snowy peaks of Davos receded in behind me on the train back to Zürich, I found myself reflecting on a truly invigorating week at the World Economic Forum Annual Meeting 2025. This year's gathering felt different, a palpable shift in the global conversation towards tangible solutions and a renewed sense of urgency in leveraging technology for the greater good.

For Hedera, Davos 2025 was a watershed moment. We weren't just present at the table, we were actively shaping the dialogue around key themes that are core to our mission, showcasing our commitment to global collaboration through our sponsorship of USA House, collaborating closely with The Hashgraph Association; to drive real-world impact, and engaging with key policymakers through our government affairs and policy team led by Nilmini Rubin.

Hedera hosted several events like:

Building Trust: The Foundation for Responsible AI

A roundtable lunch session where panelists explored ethical AI development, governance frameworks, privacy, and security, as well as the evolving crypto regulatory landscape. Panelists also examined how blockchain’s decentralized data structures can create new paradigms for data security, identity verification, and AI model training. Speakers included Josh Harris (EVP of Palantir), Michelle Zatlyn (COO of Cloudflare), Teresa Guillen Goody (Partner at BakerHostetler and Former Attorney at the SEC - U.S. Securities Exchange Commission), Eric Piscini (CEO of Hashgraph), moderated by Jeremy Kahn (AI Editor at Fortune).

Re-imagining Financial Markets with Real-World Asset Tokenization

In the future, nearly every real-world asset will be digitally represented on a distributed ledger, enabling these assets to be tokenized, shared and transferred across the globe seamlessly without intermediaries. This session brought together an all female panel of thought leaders, innovators, and industry experts to explore how tokenization is re-imagining financial markets by breaking down siloes and modernizing legacy systems. Speakers included Sandy Carter (COO of Unstoppable Domains), Betsabe Botaitis (CFO of Hedera), Lisa Loud (Executive Director of Secret Foundation), and Megan Nilsson (Host Crypto Megan Podcast and Co-Owner of ATH Vodka).

The Future of AI: Advancing Decentralized Technologies

A panel and networking reception where panelists explored the evolution of AI and how its rapid adoption brings pressing challenges in the areas of trust, transparency, and accountability. These industry leaders also explored how the intersection of hardware, decentralized technologies, and AI is setting a new standard for secure operations. Speakers included Bryan Rich (Senior Managing Director, Global AI for Health, Public Sector, Defense at Accenture), Jonathan Dotan (Founder of EQTY Lab), Shyam Nagarajan (COO at Hedera and Former Partner at IBM for Responsible AI), moderated by Dr. Leemon Baird (Co-Founder of Hedera and Hashgraph).

Sustainability: The climate crisis took center stage, and Hedera's role in enabling verifiable carbon markets and transparent ESG reporting resonated deeply. Numerous discussions highlighted the need for trusted data and auditable processes, areas where our distributed ledger technology offers unique advantages.

USA House: Hedera's sponsorship of USA House provided a unique opportunity to engage with global leaders in government, business, and civil society. This prominent platform allowed us to foster dialogue, build relationships, and demonstrate our commitment to supporting American innovation and leadership on the world stage. We hosted meetings with influential figures like Kimbal Musk, sparking conversations about the intersection of technology, sustainability, and social impact.

Tokenization: From real-world assets to fractional ownership, the potential of tokenization was a recurring theme.

AI-DLT Convergence: A fascinating trend emerged around the convergence of AI and DLT. Leaders recognized the potential of combining AI's analytical power with DLT's security and transparency to create innovative solutions in areas like supply chain management, healthcare, and fraud prevention. Hedera's high-throughput platform and robust security features make it an ideal foundation for these emerging technologies.

The Hashgraph Association Impact: The Hashgraph Association played a crucial role in amplifying Hedera's presence at Davos. Their active engagement in discussions around interoperability, education, and developer support highlighted the growing Hedera ecosystem and its potential to drive real-world adoption.

Beyond these specific highlights, I was struck by the growing recognition of the need for trust and transparency in the digital age. Hedera's commitment to governance, security, and sustainability resonated with leaders across sectors who are seeking reliable and responsible technology partners.

Davos 2025 reinforced my belief that Hedera is playing a pivotal role in shaping the future of technology. We are not just building a platform, we are building a trusted foundation for a more equitable, sustainable, and empowered world.

Key takeaways for Hedera:

Increased awareness and recognition: Davos provided a powerful platform to showcase Hedera's capabilities and contributions to a global audience.

Valuable partnerships: We engaged with leaders across sectors, forging new connections and exploring potential collaborations that can drive adoption and impact.

Reinforced market position: The discussions at Davos validated Hedera's focus on key areas like sustainability, tokenization, and the convergence of AI and DLT, solidifying our position as a leader in the DLT space.

Ecosystem Growth: The Hashgraph Association's efforts in fostering a vibrant and growing community around Hedera were evident at Davos, demonstrating the collective strength of our ecosystem.

Policy Influence: Our government affairs team effectively communicated Hedera's vision and values to key decision-makers, paving the way for greater collaboration and regulatory clarity in the future.

Finally, it was nice to see Hedera Council Member, Shuchi Rana at WEF Davos who articulated very well why ServiceNow is a member of Hedera.

“Hello Future! Hello Hedera!”

Introducing the Hedera Developer Playground

Hedera Team — Tue, 28 Jan 2025 10:53:20 +0000

By Ed Marquez & Manu Cabrera

A browser-based tool for building & experimenting on Hedera in seconds.

The new Hedera Developer Playground makes it easier than ever to start developing with Web3 technology. This browser-based tool enables developers to write, execute, and share code snippets and flows directly in their web browser, utilizing the Hedera testnet. No wrestling with local setups – the Playground eliminates that barrier entirely, accelerating your Hedera development journey so you can focus on the fun part, coding and programming.

What is the Hedera Developer Playground?

The Playground is an open-source project built in collaboration with Kabila, a project in the Hedera ecosystem with expertise in Web2, Web3, and Hedera technologies. This tool provides a user-friendly environment for developers of all experience levels, from seasoned Hedera veterans to Web2 developers eager to explore Web3.

The Playground eliminates the hurdle of time-consuming local setups, allowing you to dive straight into coding with familiar languages like Java and JavaScript. With this new tool, you can:

Access the various Hedera services (Hedera Consensus Service, Hedera Token Service, Smart Contracts),
Use a wide array of transactions and queries,
Create individual code snippets for specific actions or combine them into more complex flows for advanced functionality,
Share your code.

The open-source nature of the Playground also facilitates transparency and encourages contributions from the developer community.

Who is it for?

Web2 Developers: Smooth your transition to Web3 development using the languages you already know, like Java and JavaScript. No prior blockchain, smart contract, or Solidity knowledge is required, making the Playground the perfect gateway.

Existing Hedera and Web3 Developers: Prototype and test complex flows in a matter of seconds or minutes, not hours. The Playground speeds up your exploration and iteration, enabling you to try out your best ideas with just a few clicks.

Why it Matters: The Benefits

The Hedera Developer Playground is a game-changer for developers getting started and building on Hedera. That is because the tool enables:

Faster Onboarding: Developers can start experimenting with Hedera immediately, without the need for local setup and configuration. This significantly reduces the learning curve and time to value.
Getting More Done, Faster: Prototype and test ideas quickly. Forget about lengthy development cycles – the Playground enables efficient experimentation and iteration.
Simplified Exploration: Explore the existing and new Hedera functionalities with just a web browser.

Take Action and Start Today!

If you are ready to try your best ideas and build on Hedera, here are the steps:

Visit the Hedera Developer Playground: portal.hedera.com/playground
Choose your preferred language: Java or JavaScript (more languages planned in the future).
Start writing and executing code snippets or building flows. a. If you want to execute code (interact with the Hedera testnet), you will be prompted to create a Hedera Portal testnet account.

The Hedera Developer Playground is a fantastic tool for developers of different backgrounds to explore and build on the Hedera network. Going forward, the tool will continue to improve by adding support for new features and more workflows to enable all developers to learn and explore Hedera and Web3. With its intuitive interface, open-source nature, and emphasis on rapid experimentation, the Playground is a powerful productivity booster for the Hedera developer community.

Try out the Hedera Developer Playground today and share your feedback on our Discord!