DragonGlass: The Hedera Hashgraph Data API

Sreejith Kaimal
Published in
5 min readNov 21, 2019


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.