How Coinibi Detects New Tokens in Real-Time

Real-time token detection sounds simple on the surface: watch for new tokens and report them. But implementing it at scale across 60+ blockchains is significantly more complex. This post details the architecture and methodology behind Coinibi's detection system.

The Challenge

Before diving into our solution, it's important to understand the problem. On Ethereum alone, thousands of transactions occur per block. On other chains like Solana, the number is even higher. To detect new tokens in real-time, we need to:

1. Monitor multiple blockchains simultaneously2. Process transactions as they're included in blocks3. Filter for token creation events with minimal latency4. Run analysis on discovered tokens within seconds5. Deliver information to users immediately

Traditional approaches that query blockchain state periodically would miss launches or introduce unacceptable delays. Instead, we use event-driven architecture.

Event Listening Architecture

The core of Coinibi's detection system is listening to blockchain events. Specifically, we monitor DEX factory contracts like Uniswap V3 Factory on Ethereum, Pancakeswap Factory on Binance Smart Chain, and equivalent factories on each supported network.

When a token is created and paired on a DEX, the factory contract emits aPairCreatedevent. This event contains the address of the new token, the paired asset, and other critical information. By subscribing to these events via JSON-RPC websocket connections, we receive notifications in real-time as they occur.

Each chain we support has one or more dedicated event listeners. These listeners maintain open websocket connections to publicly available RPC endpoints and subscribe to factory contract events. When a new event is received, it's immediately forwarded to our processing pipeline.

Multi-Chain RPC Polling

While event listening is our primary detection method, we also maintain backup RPC polling to ensure we don't miss launches due to RPC endpoint failures or other issues. Every 5-15 seconds depending on the chain's block time, we query the latest blocks and scan transaction receipts for factory contract events that might have been missed.

This dual approach — event listening as the primary mechanism and polling as a fallback — ensures we have multiple independent paths to detect launches. If one RPC endpoint goes down, we have others. If event subscriptions temporarily fail, polling catches the missed tokens.

For chains with higher block times and lower transaction volumes, polling is more efficient than event listening. We automatically adjust our polling intervals based on historical block times and detection rates per chain.

Token Metadata Extraction

Once we've detected a token, we immediately fetch its metadata. This includes the token name, symbol, decimals, total supply, and deployment transaction details. We also attempt to retrieve the contract source code from blockchain explorers for verification status.

This metadata extraction happens in parallel across multiple tokens. Rather than processing tokens sequentially, we maintain a pool of workers that fetch metadata for multiple tokens concurrently. This allows us to keep up with bursts of token launches during high-activity periods.

Safety Scoring Pipeline

With metadata in hand, we run our safety scoring pipeline. This pipeline checks eight different heuristics in parallel:

Liquidity Lock Detection: Is liquidity locked for a reasonable period?Contract Verification: Is the contract source code verified on explorers?Mint Authority: Can the deployer mint additional tokens?Ownership Renunciation: Has ownership been renounced?Honeypot Detection: Can tokens be sold after purchase?Top Holder Analysis: What percentage do top 10 holders own?Trading Pattern Analysis: Are there unusual trading volumes or prices?Social Presence: Does the token have documented social media accounts?

Each heuristic is scored on a scale of 0-100. The final safety score is a weighted combination of these individual scores, with heavier weight on the most indicative signals.

Scam Filtering

Based on safety scores and detected patterns, we automatically filter out obvious scams using our Rug Radar. Tokens with honeypot patterns, extreme holder concentration, zero liquidity locks, or other critical red flags are flagged or excluded from the main feed. This filtering happens immediately after scoring completes.

This doesn't mean we ignore flagged tokens — they're still available in the platform for research and analysis. But we don't show them as recommended discoveries to our users.

Delivery to Users

Once detection, metadata extraction, and safety scoring are complete, the token data is stored in our database and pushed to connected users via websocket. The entire process from event detection to user notification typically takes 2-8 seconds, depending on network conditions and current system load.

Users can subscribe to feeds based on their preferences: all tokens, only high-safety tokens, tokens on specific chains, or tokens matching specific criteria like minimum liquidity.

Performance at Scale

Handling thousands of potential tokens per day across 60+ chains requires careful optimization. We use message queues to buffer incoming tokens during traffic spikes, caching to avoid redundant blockchain queries, and distributed workers to parallelize safety scoring and metadata extraction.

Our system is designed to scale horizontally. When detection volume increases, we add more workers to the safety scoring pool. When database load increases, we add read replicas. This architecture allows us to maintain sub-second latency even during peak activity periods.

What's Coming

We're continuously improving the detection system. Upcoming enhancements include machine learning-based scam detection, sentiment analysis of social media mentions, and DEX pool analysis to detect price manipulation patterns. We're also exploring partnerships with blockchain explorers to get even faster access to source code verification data.