Pulsonic Trading Bot

Key Achievements

As a solo developer, I developed a production-grade decentralized exchange (DEX) trading stack without reliance on third-party aggregators or tools. Designed and implemented a proprietary price discovery and trade routing engine, delivering rapid trade execution and optimal rates for users.
Maintained high throughput under real market conditions, processing over two million trades and exceeding $100 million in trading volume without incidents, including during periods of heightened activity from meme tokens and highly anticipated launches.
Achieved 99.9% uptime utilizing three self-hosted virtual private servers VPS and one dedicated GETH node, without the use of Kubernetes, managed services, or complex orchestration solutions.
Implemented reliable failover through application-level awareness, enabling services to detect MongoDB replica set states and autonomously reassign responsibilities.
Enabled same-block and mempool-aware trade execution and sniping capabilities.
Optimized infrastructure costs, achieving a 75% reduction compared to third-party services, while maintaining complete control over both infrastructure and data.

Overview

Pulsonic trading bot is a Telegram bot that gives users a fast and safe trading experience. It was created to help users get a better trading experience while staying private and safe.

Even experienced traders struggle to trade on decentralized exchanges. Especially when trading new or high-risk tokens on decentralized exchanges.

Here is an example of a user doing a trade on Uniswap or other decentralized exchanges

Loads the website
Connect his wallet (popup from browser extension + confirmation)
Select the token he wants to pay with (usually Ethereum )
Select the token he wants to buy; it’s not even listed, so he has to enter the token address.
Because the token is new or highly volatile, the decentralized exchange will display a dialog warning that the token is risky, along with other prompts prompting the user to accept.
Once the user accepts, they input the amount.
They confirm and see the trade preview.
Confirming the preview pops up their browser wallet integration to sign the transaction.
User confirms the signature.
The browser ui waits for the transaction and shows success once it’s done.

This process takes at least a minute for expert users, while beginners are likely to abandon the transaction upon encountering the warning.

Furthermore, these challenges represent only the initial difficulties users face. Traders must manually track their trades and execution prices, as most purchased tokens are not automatically displayed in browser extensions. There is no integrated PNL tracking, making it difficult for users to assess their profit or loss. The selling process is even more cumbersome, requiring an additional approval step before executing a sell trade.

These cumulative challenges significantly hinder the daily operations of DE-FI traders. As a result, trading bots such as Banana Gun and similar tools often process higher volumes than the decentralized exchanges themselves.

The Pulsonic project was initiated to address these issues and enhance the trading experience, providing users with a competitive advantage.

Usage guide

Features

Secure custodial crypto wallet per user.
Trade tokens on all decentralized exchanges on the Pulse Chain.
Portfolio and positions tracking with real-time PNL.
Support for meme launchpads on pulse chain pump.tires.
Token launch sniping supporting both pump.tires and decentralized exchanges.
Users can share their positions PNL in nice images.
Limit orders support.
A referral system that pays users a commission on trading fees generated by their invited friends.

The challenges

Although the project has many features that seem complex, most of them were straightforward; the core challenge was the core functionality (trading on decentralized exchanges).

Trade routing and price discovery

In contrast to centralized exchanges, which provide most of the necessary utilities, trading on decentralized exchanges required me to develop most of these utilities independently.

To execute a trade, whether it is a spot trade executed by the user or a limit order triggered by the system, I need to know the asset price and where to trade it on the Pulse blockchain.

Drawing on my prior experience with blockchain trading data from the callhub.In a tech project, I was familiar with the expected processes while anticipating potential new challenges.

One significant challenge involved developing an optimal trade routing system. For example, if a user trades asset A for asset B, the system must secure the most favorable deal based on available on-chain liquidity.

A naive solution would be something like the diagram below.

Naive trade routing diagram

A major issue with this approach emerges when querying liquidity providers for quotes, as no direct query mechanism exists. Querying the blockchain via contract calls is time-consuming, particularly for multi-hop trades. This latency was unacceptable for the bot, whose primary feature is rapid trade execution at optimal rates.

High availability and reliability

This bot will be used by serious traders; they will have time-critical trades, limit orders, and snipes. A downtime of even a few minutes could result in losses for those traders and cause them to lose trust in the bot.

The bot must be up 24/7, with a redundant system ready to take over in the event of failures. This required significant work at the infrastructure level and implementation at the app level.

Solutions

Solutions for trade routing and price discovery

It was clear I couldn’t query the blockchain every time a user or subsystem triggered a trade, so I had to structure the blockchain data in my own database to ensure our price discovery had very low latency.

For this, I created the following:

A system that listens for new blocks on the pulse chain, reads all EVM events and extracts the trading and assets data, and stores it in our database.
A system that listens to new pending transactions allows us to frontrun any pending trades that affect our trading routes. It also allows us to do same-block snipes on newly listed assets.
A trade routing simulator that simulates trades against our database, taking into account price impact, platform-specific fees, and returns the best trading route for the trade.

Solutions for High availability and reliability

Failover system diagram with all services running

To achieve this high-availability system, we implemented the following:

A three-server setup, one primary, one secondary, and one arbiter. Each server was rented from a different provider and was ensured to be in a different physical location (Limburg, Amsterdam, and Helsinki).
I divided the bot system into multiple services that can run and scale independently.
During normal operations those services were divided between the primary and secondary, each service was bound to a specific server, by listening to the mongodb replica-set changes, each service will know if its bound server is down and starts on the other server, we designed most services to have multiple instances without issues, except for the telegram bot listener service, which can have only one instance (See Telegram Bot API FAQ), this one used a lock system on mongodb to make sure only one instance is running at a time.
I used MongoDB and set up a 3-node replica set (primary,secondary, and arbiter).

So I kind of relied on the mongodb replication system to make it easy for my services to know when to switch servers, I will post an article about the setup bot at the application layer and the servers setup, but in short I installed mongodb on all three servers, I used wireguard to create a private network between the three servers and configured mongodb to use and bind on the private network (I never open public network access to my databases if I can avoid and always advise against it), I then configured the replica set to be primary, secondary, and arbiter.

Technology stacks and languages

Typescript

TypeScript on the backend provides type safety, enabling early detection of potential bugs and enhancing long-term project maintainability.

Node.js

While other alternatives exist, and might seem better performance wise, in my experience, in real time scenarios those performance claims are negligible, I value stability more than anything else, nodejs has been around for many years and is battle tested and stable, in my 12+ years working with nodejs, I have never had a single issue that was nodejs related, I can’t say the same for bun or deno.

Telegraph

I used telegraph as the main framework for the bot. Telegraph provided convenient features out of the box. but looking back, if I were to make this decision again, I would stick with telegram-node-bot-api, which is a lower-level library but would give me more flexibility and more control over the bot.

Ethers

Ethers were used for many blockchain interactions, where the convenient dev experience did not affect the performance. But in critical paths, I used raw RPC calls, so I don’t pay the hydration cost of ethers.

Go-Ethereum (Geth)

To enable the sniping feature, we needed to listen for pending transactions. Most public RPC providers do not offer this feature; paid providers do, but when comparing costs, it was an easy decision to self-host our own blockchain node.

Column 1	Column 2	Column 3
Feature / Criteria	Third-party services	Self-hosted node
Pros	No setup or maintenance required	-Full control over the node and its configuration - No rate limits- Cheaper at scale `(dedicated hardware ~$200/month: Ryzen 9, 128 GB ECC RAM, 16 TB NVMe storage, 4×4 TB)`
Cons	Expensive at scale (our usage would cost ≥ $1000/month) - Rate limits are too low	Requires setup and maintenance (not a major issue since savings outweigh man-hours)

Mongodb

I chose MongoDB for its higher write throughput and easier replication setup. After 1+ years of using it in this system, I don’t have any complaints; all queries are fast, and replication was a breeze to set up and maintain.

Redis+Sentinel

Redis was used for caching and as a store for BullMQ job queues. I used Sentinel to set up a similar replication setup to MongoDB.

BullMQ

BullMQ was utilized to queue and process jobs, significantly enhancing system scalability.

BullMQ also facilitated scaling the Telegram bot, which must operate as a single instance. I developed a system as illustrated in the diagram below.

BullMQ usage diagram

Deployment and maintenance

Infrastructure

The bot was deployed on three VPS servers in addition to a dedicated server for hosting the Geth node.

Primary server

Provider: OVHcloud (No affiliation)
Location: Limburg, Germany
Specs: 8 vCPU, 24 GB RAM, 200 GB NVMe Storage
Cost: ~$12.75/month

Secondary server

Provider: SpectraIP (No affiliation)
Location: Amsterdam, Netherlands
Specs: 6 vCPU, 16 GB RAM, 240 GB NVMe Storage
Cost: ~$15/month

Arbiter server

Provider: Hetzner (No affiliation)
Location: Helsinki, Finland
Specs: 2 vCPU, 4 GB RAM, 40 GB NVMe Storage
Cost: ~$4/month

Geth node server

Provider: Hetzner (No affiliation)
Location: Helsinki, Finland
Specs: AMD Ryzen 9 7950X3D, 128 GB ECC DDR5 RAM, 16 TB NVMe Storage
Cost: ~$200/month

Total monthly cost: **~$231.75/month**

Monitoring

Server management dashboard

Although the codebase was written as a monolith, the system was divided into 13 sub-services, each of which could scale horizontally, except for the Telegram bot listener service. This allowed us later to set the right number of instances for each service based on monitoring; no auto-scaling was necessary during the 1.5 years of operations as of January 2026.

CI/CD

Instead of GitHub Actions, I employed a straightforward script on each server to pull the latest code, build, and restart services. This script included a rapid rollback mechanism and retained all previous builds.

Backups

A simple backup script was created to back up MongoDB and Redis data hourly, with daily/weekly retention policies. Backups were stored in a private S3 bucket on DigitalOcean (no affiliation).

Status

Trades dashboard stats

Lessons Learned

Direct blockchain indexing is essential for robust DEX trading operations. On-demand RPC calls are not sufficiently fast or reliable. High execution quality requires direct ownership and management of market data.
Simple failover mechanisms are more effective than complex orchestration solutions. MongoDB replica sets, combined with service-level self-awareness, provide greater transparency and easier debugging.
Access to pending transactions constitutes a significant competitive advantage. Although many bots offer similar features, access to the mempool distinguishes professional-grade tools from less sophisticated alternatives.
System performance is primarily determined by data locality rather than programming language selection. Minimizing unnecessary abstractions, such as object-relational mapping hydration, software development kit overhead, and excessive JSON parsing, had a great impact on performance, and should always be pursued before changing runtimes or changing stack.

What I would do differently

Managing the private keys for users is a very sensitive task, one mistake can lead to huge losses for users, in this project, since providing private keys to the users when wallets are created was a requirement, I generated private keys for wallets and saved them in the database, I used a dual key encryption, where all systems only have access to the public key (encrypts only), while only the transaction signer service has access to the private key (decrypts only), the signer service decrypts the private key signs the transactions and then dereferences the decrypted private key from memory immediately after signing, while this system is not perfect, it provided encryption at rest and proper isolation between services.

If I were to do this project again, I would opt for an MPC wallet implementation, where the private key is never fully reconstructed and the signing is distributed between multiple parties, that would provide much better security.