D.A.G.G.E.R. Hammer: The Magic Behind a Keypress


In the world of distributed systems and web3 technology, GenesysGo's Directed Acyclic Gossip Graph Enabling Replication, or D.A.G.G.E.R. for short, stands as a unique and robust solution. Its versatility, modularity, and high throughput make it an ideal choice for a plethora of applications, from mobile storage to AI model logging. But what exactly happens behind the scenes when a user interacts with a D.A.G.G.E.R.-powered application?

In this article, we break down the lifecycle of a keypress in our recently launched D.A.G.G.E.R. Hammer Testnet Game and provide a simplified overview of how each keypress becomes a processed D.A.G.G.E.R. transaction. For a deeper dive into the technical details, please refer to the D.A.G.G.E.R. Litepaper. If you want to participate further and run a D.A.G.G.E.R. Wield Node, please visit our Wield Node Docs page for instructions.

The Journey of a Keypress

When a user presses a key on their keyboard while playing the D.A.G.G.E.R. testnet game, a series of complex yet efficient processes are initiated. Each keypress is converted into a transaction that must traverse through the different modules of the D.A.G.G.E.R. protocol. The game's simple interface belies the complexity of the operations happening underneath. The transformation of a little empty square into a green one upon a keypress is not just a game mechanic - it's a testament to the power and efficiency of D.A.G.G.E.R.'s consensus protocol.

Communications Module

The journey begins with the Communications module, acting as the doorman for incoming transactions. It accepts the keypress, which is sent to D.A.G.G.E.R. as an RPC (Remote Procedure Call) from the browser. The Communications module is responsible for forwarding these transactions to the appropriate next stop in their journey, the Processor Module. Additionally, the Communications Module manages network I/O; it communicates with peers in the network and clients who wish to submit/read transactions to/from the network.

Processor Module

Upon receiving the transaction from the Communications module, the Processor module verifies the transaction's payload and signatures. This is akin to a quality check, ensuring the integrity and authenticity of the transaction. The Processor Module has two closely related sub-components, each with dedicated threads: the Verifier and the Forester.


The Verifier verifies the signatures on the transactions. This is another layer of security, ensuring the transactions are tamper-proof and ready to be added to the D.A.G.G.E.R. ledger. The Verifier is a sub-component of the Processor module; it also handles the verification and de-duplication of incoming transactions. It doesn't validate the root hash of the transaction Merkle tree, that task is performed by the Forester.


After verification, the Forester steps in to pack these transactions into Merkle trees. This data structure is crucial for ensuring the secure and efficient handling of transactions. It's like a sophisticated packaging machine, preparing the transactions for the next stage in the journey. The Forester module is technically a sub-component of the Processor Module.

Graph Module

Once the transactions have been verified, they are sent to the Graph Module. This module is like a flight control system at a busy airport, managing the complex schedule of transactions. It inserts the transactions into the Directed Acyclic Gossip Graph (DAG), where they are ordered based on consensus. It's worth noting that the Graph Module also has the responsibility of reading the graph to prepare a sync response, and it is the only module that has read and write access to the DAG.

Controller Module

Finally, after consensus ordering, the transactions are sent to the Controller for execution. This is the final stage of the journey, akin to a finished product leaving the factory. The little empty square in the game turns green, signifying that the transaction has been processed, reached consensus, and executed successfully. The Controller Module also performs reads from and writes to the ledger. Depending on the use case of DAGGER, it may also execute operations like sharding and erasure coding for filesystem applications, or other operations for use cases like oracles, bridges, and VM orchestration.

The Importance of the Test

The D.A.G.G.E.R. testnet game serves as a practical demonstration of D.A.G.G.E.R.'s capabilities. It showcases the protocol's ability to process transactions asynchronously, with an upper bound of nearly 60k TPS across all instances of users pressing keys; the testnet allows us to benchmark real-world performance and optimize various parameters of the D.A.G.G.E.R. network underlay.

Moreover, the testnet game helps illustrate the potential applications of D.A.G.G.E.R. Each keypress could represent a multitude of different transactions, such as an in-game action, a DeFi trade, a mobile hash verification, a vote for consensus, or an AI model logging input/output. This versatility is one of the key strengths of D.A.G.G.E.R., enabling it to cater to a wide array of use cases.


So, the next time you press a key in our D.A.G.G.E.R. Hammer Testnet Game, remember the intricate processes that are set into motion. Each keypress is a testament to the power, efficiency, and versatility of the D.A.G.G.E.R. protocol. And while the game is a simple and fun way to interact with D.A.G.G.E.R., it represents much more - a glimpse into the future of how GenesysGo is approaching distributed systems and blockchain technology.