Callhub.tech

CallHub.tech (later 0xcalls.ai) lets users share token calls and track their performance. The platform helps anyone become a crypto influencer, regardless of fame or wealth. Each profile shows a user’s track record, encouraging others to follow and copy their calls.

Overview

The project’s approach is straightforward: users access the platform to create a call. A call is issued when a user expects a crypto asset’s price to increase. The system then tracks the asset and marks the call as a win or loss based on performance.

A win is when the token rises above a set threshold (e.g., 5%) in a set time (e.g., 24 hours). A loss is when it falls below a set threshold (e.g., 5%).

Screenshots

Individual token call page showing price action and performance

The challenges

The underlying concept is simple; however, monitoring crypto assets across seven blockchains introduces significant complexity.

Because user token selection is unpredictable, a solution was needed to query live prices for any asset at any time.

Another requirement is the capability to process price changes in real time to update the status of crypto asset calls on our platform.

So we need both a price change feed and an easy way to query the prices of crypto assets from decentralized exchanges across multiple blockchains.

While there are options to query latest and historical prices using third-party providers like dextools, looking at their features and pricing models, it was clear that it would cost us thousands of dollars a month, and none of them offer a good real-time price feed.

The decision was clear: we needed to develop our own solution tailored exactly to our requirements, which means we must track all crypto asset prices across all supported blockchains.

Blockchains are open and public, which provides access to extensive data. However, this data is often unstructured and difficult to query. Ideally, we could request “the price of token X on chain Y at time Z,” but blockchain data isn’t structured that way, so we will need to do it ourselves. Below is a simplified flow for tracking token prices.

Price Tracker Flow Diagram

To track a token’s price, it is necessary to monitor every block, parse transactions and log events, reconstruct and structure the required data, and store it for future queries.

The flow above only considers the happy path and ignores the prices from low-liquidity or bad pools, which are very common on decentralized exchanges.

Building this solution presented a new challenge: we needed to execute numerous JSON-RPC calls to aggregate and structure the price data. After conducting a rough cost estimate for third-party providers such as Alchemy or Infura, it became apparent that we would require approximately $2,000–$3,000 per month solely for RPC calls. For context, the total project budget at the time was less than $4,000 USD.

The solutions

To solve the data-aggregation problem, we relied on the fact that tokens on EVM-based blockchains generally follow the same token standards. Many decentralized exchanges are Uniswap-like protocols (v2, v3, v4), so the core logic is similar across implementations.

We created a data-aggregation layer that tracks Uniswap events (pair creation, liquidity addition/removal, swaps) and structured them to fit our needs. Essentially, we built a graph-like system without using the Graph protocol.

To overcome unreliable RPC providers, we created a web3 proxy layer that received our RPC calls and forwarded them upstream to third-party providers. The proxy was aware of each provider’s rate limits and would rotate and throttle requests when needed. It would also retry failed requests and, on critical paths, query multiple providers simultaneously and compare results to ensure correctness.

Web3 Proxy System Architecture Diagram

As an added bonus, this proxy layer helped us hide our API keys from the frontend. We could also use public providers to increase request capacity and reduce costs.

Another benefit of the proxy is the ability to control caching policies. Requests for the same blockchain at the same block number would hit our internal cache, avoiding upstream calls. This significantly reduced costs; during operation, while tracking thousands of crypto assets, we never exceeded the free-tier limits set by our providers.

Technology Stack

Website + API: SvelteKit / TypeScript / Node.js
Database: MongoDB with Mongoose and Redis for caching and streams.
Data Aggregation Layer: Node.js / TypeScript / custom indexing solution
RPC Proxy: Node.js / TypeScript (using bare node http module)
Telegram Bot: Node.js / TypeScript / Telegram bot api

Justifying the stack

1. SvelteKit

I chose SvelteKit for both the frontend and backend because a single codebase simplifies development and reduces context switching between separate frontend and backend repositories. I have a system of organization and strict rules for working with frameworks; this system makes integrations with apps or other codebases easier and will be the subject of a future blog post.

2. MongoDB

Since most data comes from blockchains, whose structures vary across chains, and because the system is write-heavy, MongoDB was the obvious choice. Its replica setup and built-in change streams added significant value, enabling us to trigger events for user calls and updates.

3. Redis

Redis was used for caching (frequently requested data, sessions, and rate limiting), as well as for streams. It was used between the blockchain adapters and our data aggregation layer consumers, since I am very familiar with Redis, and it never let me down in the past, so why change it?

4. Node.js + TypeScript For Data Layer and RPC Proxy

Web3 Proxy System Architecture Diagram

The sheer volume of real-time data processed from multiple blockchains was challenging. If I had been more familiar with a faster stack, I might have chosen it, but I am most comfortable with Node.js. Profiling showed that most time was spent waiting for I/O, so Node.js was not the bottleneck; the main culprits were ethersjs and Express.js.

At first, I used Ethers and other tools like Express for the proxy server, but I soon realized that memory and processing power were being consumed by hydration steps from EthersJS and Express that were unnecessary for our use case. The convenience was not worth the cost. I decided to remove those layers, switch to the bare http module in Node.js, and process raw JSON-RPC requests myself. This gave a 5–10× performance boost and significantly reduced memory usage.

As for retries, they were only needed for HTTP-level errors. JSON-RPC calls always return HTTP 200 even when the underlying RPC method fails, so non-200 responses typically occurred only when the provider was down, rate-limited, or authentication failed. The other failure case was an invalid JSON request, which was straightforward to catch.

Deployment

The entire stack was deployed on an Ubuntu 22.04 VPS (16 GB RAM, 8 cores) 25 Euro/month.

The sveltekit app was deployed using pm2 setup with multiple instances running to take advantage of CPU cores.
MongoDB Community Edition was also deployed using native packages (no Docker), with replication enabled (Single instance replica to take advantage of the built in change stream).
Redis was deployed using native packages. We used two Redis instances: one for caching and one for streams. Streams required persistence and AOF, while the cache instance did not; this avoided the AOF performance penalty for the cache instance.
The Data aggregation layer was also deployed using pm2 with multiple instances running one for each supported blockchain.
The RPC proxy was also deployed using pm2 with multiple instances running.
Nginx was used as a reverse proxy in front of the sveltekit and the rpc proxy.
a simple backup script was created to backup the database hourly to an external S3 bucket, with a daily , weekly and monthly retention policy.

Security

The system had no smart contracts or on-chain components, so the attack surface was limited to the web application and API.

The project was live and operational from March 2023 to June 2025. During that time, it had thousands of users and tracked hundreds of thousands of crypto assets across multiple blockchains. We added features such as auto-trading based on calls, follower/social features, subscriber-only calls, and a dual mini-game where users could bet on whether a call would be a win or a loss before the 24 hours ended. The owners decided to sunset the project in June 2025 for personal reasons; it is never easy to see a project of yours retired, but such is the cycle of life.