Image for post
Image for post

DragonGlass: The Hedera Hashgraph Data API

Sreejith Kaimal
Nov 21, 2019 · 5 min read

Leveraging DragonGlass to build dApps on Hedera Hashgraph

Hedera Hashgraph launched its public main net on Sep-16th 2019. The network has processed about 20 Million transactions with ease. The good news is that the 10K TPS is just the start and a lot more is yet to come. This public decentralized platform satisfies one of the urgent needs and the most requested requirement that was constraining the building of real life decentralized applications. That need for the last several years has been high throughput and low latency. Hedera Hashgraph was able to meet that need by launching the mainnet.

Hedera’s primary focus is high throughput, high security, governance, no forking and other highly valued needs in the market. While pursuing these high-value needs they have left other developer requirements like data persistence, storage of transactions and retrieval of historical data, and other application specific needs to be developed by the Hedera ecosystem. The Hedera mainnet does not intend to be a long term data store; its focus is mainly managing the current state of the ledger. The vast trail of data produced on the execution of transactions, smart contracts, files etc is expected to be managed by the individual development teams.

If you are an enterprise, dApp developer, or an architect aspiring to build on Hedera Hashgraph, this article describes the challenge and a solution to build Hedera based application using a service like DragonGlass.

A Quick Insight into the Data Generated by the Hedera Platform

Hashgraph uses Google protocol buffers to send and receive transactions over a GRPC service endpoint that are categorized into various different use cases. A quick review of the Hashgraph protobuf definitions specified in the public repo [1] will give you a good insight on the min & max transaction volumes. The protocol buffers are super compressed on the wire. The network has to unmarshall, validate and enrich the transaction data on the fly. Any external system that would want to make sense of this data will have to do the same. Below is the diagram of a transaction object. The grayed-out fields are deprecated, and the marked ones are the required fields.

Image for post
Image for post
Visual of Transaction Request

For example: While a simple crypto transaction with 1 signature and a simple memo can be as small as 170 bytes on the wire, the same transaction when converted into an unstructured text representation can be as big as 2 Kbytes and around 2.5 Kbytes post consensus. This is a simple transaction; a searchable text representation of a smart contract transaction can be as big as 3.6 Kbytes.

Below is a simple table of historical transaction volumes generated. This should give you a good idea as to how much data is generated:

Image for post
Image for post
Size extrapolation of indexed data

You can store this massive data by hosting a datastore that stores the compressed protobuf objects with some basic indexing. However, as we experienced during the early days of building applications, a simple datastore does not satisfy the needs of both the application team and the operational system (reporting, auditing, tax calculation). There is a need to search and access the information both in its raw format and processed text format. There is a need to have real time access as transactions are generated (validated). There is a strong need for historical transactions from the past for reporting, auditing and creating analytics. Then there are applications that need to be proactively notified as events are generated. The list goes on, and very quickly the need for a sophisticated data platform to manage the data becomes evident. For some teams, such as Diamond Standard, these needs became more challenging as the team looked to leverage information from other blockchains.

The real question is does a development team have a business case and a budget to build a real time operational data infrastructure to support their dApp and other related transactions on Hedera?

DragonGlass Platform for Hedera Developers

We designed DragonGlass to serve the needs of dApp development teams. Our goal is to provide developers the ability to build server less applications. Between the Hedera platform and DragonGlass, developers should be able to execute transactions on Hedera and gain instant access to all their data on DragonGlass. We aim at being an operational data store for your dApps (

At the core of its design, DragonGlass is a highly scalable Platform as a Service infrastructure that stores and processes (unmarshalling, indexing, signature verification, etc) data collected from the Hedera platform at a TPS similar to the Mainnet. For end users the platform supports a Google-like search to access accounts, transaction, smart contracts files, … almost everything produced on the Mainnet. For developers, the platform supports a wide range of REST based API’s to access all data (
The below diagram is a schematic data flow & business context diagram for the DragonGlass platform:

Image for post
Image for post
DragonGlass Context for Hedera Hashgraph

The DragonGlass platform allows you to extend the state of the art operational data store via a rich set of integration endpoints. The platform provides a wide range of capabilities:

  1. Customizable Dashboard that works for B2C: Onboard your customers on DragonGlass to enable rich preview of historical transactions on your customer accounts. You can even attach this to your customer profile for a delegated user experience.
  2. Embed Transactional Data: Use the rich API’s to fetch filtered data for specific scenarios, including customized analytical data. Fetch and store data that matter to you most, not the whole thing.
  3. Configure Notification Services: Do you customers need alerting? Be it winning a lottery or a large payment, use this as a way of sending push notifications without the need of constantly asking the network or paying additional fees for fetching records.
  4. dApp Marketplace: If you have a dApp you can list and promote your dApp on DragonGlass. Additionally, a dApp team can have a details page customized to display the contracts, byte code, source etc, usage…

So should a team build its own data infrastructure or use a platform as a service like DragonGlass? We did a quick effort on build versus subscribe analysis:

Image for post
Image for post

To get started building the next generation of dApps, go to to sign up.


1.Hedera protobuf definitions
2.Hedera Users & dApps
3.Hedera developer resource & documentation


Design and Technology Firm creating Custom Blockchain…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store