Aaryamann Challani

Engineer and amateur cook writing about privacy, cryptography, and distributed systems

← Back to posts

Introduction

I had some extra time on my hands the past week, and decided to participate in Gitcoin's GR10 Hackathon. As I scrolled through the bounties available, this one stood out the most to me. It was right up my alley considering the experience that I have. It also allowed me to work with certain technologies I haven't used before (Example- ViteJS)

The Deliverable

As mentioned in the problem statement, I had to build an on-chain trading monitor that Dodo could use internally/with end users. They also said that it should be in the form of an SDK, which would be open sourced for anyone to use.

Knowing that each companies infrastructure setup is different, I contacted one of the team leads over at Dodo. After a quick call and multiple exchanges over Discord, I was prepared to tackle the project and make sure it cohesively fit into their systems.

Components of the Deliverable

I split the deliverable into 4 components, namely -

  1. The Websocket Engine:

    • This component purely facilitates client side event listening, in a way that most users connect to crypto exchanges, like Binance, Coinbase etc
  2. The Monitor SDK

    • This SDK is totally extendable and consists of 4 modules, namely, Sources, Sinks, Middleware and Registries
    • Sources are the sources of data, usually it's the evm-based chain. It could also be the mempool for those who wish to execute transactions based on the state of the mempool
    • Sinks are the destination for the data. This could be - a Messaging Queue(Kafka, KubeMQ, etc), Email, Slack, Discord, etc.
    • Middleware are the pieces of code that fit between the sources and sinks, managing the event flow and transforming data as needed.
    • Registries store the on-chain event to real-life implication events. The sources use this to handle user input and convert it to an event it can listen to, onchain

    Note that the middleware can use multiple sources and sinks, and as long as they all implement the interfaces designed.

  3. The ETH Engine

    • It is highly probable that users will listen to the same events on the same addresses, but with different trigger values(or tolerances).
    • To reduce network load on the node as well as the process, the eth engine smartly manages subscriptions and ensures that there is only one subscription for a given topic.
  4. UI

    • Basic Boilerplate for the other DEXes to fork and modify to their need

Demo

I've yet to work on a full-fledged video demo showcasing the extent of the SDK, but here's a little GIF!

Conclusion

It was fun to work on this project, it gave me a deeper understanding of typescript's type system as well as sharing types between frontend and backend. Submission date is on July 7th, and results will be announced on July 17th.