Radar of squeezes in the Solana network

Data Parsing, Web Programming — incorrectly specified categories?

22 USD

Project translated automatically. Log in or register, to view the original

I need to create a squeeze parser (delta drops in the moment) for the Solana network, so that it connects to multiple WebSocket nodes simultaneously and merges the transaction stream without duplicates. The software should operate in ultra-fast mode, without using external APIs like DEX Screener — only raw parsing of transactions and instructions. Squeeze detection should occur instantly based on impact (the effect of the trade on liquidity) without waiting for price or history. It is important to ensure maximum transaction coverage (≈90%+) and minimal latency (<150 ms) through queue optimization and processing. The priority is speed and data completeness, not accuracy or complex logic.
Ability to set filters
Minimum drop of -X
Liquidity Pool Volume of -X
Is there a token on Coinmarketcap Y/N

There is a paid private node

Proposals 8 Discussions 1

Mixail Lutsckiy

12 0

Budget: 27000 UAH Deadline: 18 days

Good day.
I have reviewed the task. This is not about a regular parser, but about a low-latency event radar in Solana: connecting to multiple nodes, merging streams without duplicates, raw parsing of transactions and instructions, and quick impact detection without relying on external aggregators.
I can take this on in Python as a separate ingestion/processing pipeline:
connecting to multiple streams,
normalization and deduplication of transactions,
extracting necessary swap/liquidity events,
calculating impact in real-time,
filtering by specified thresholds,
outputting signals in the required format.
I would like to highlight an important technical point: requirements such as high coverage and very low latency need to be fixed through a specific architecture in the first phase, rather than promising "in general" terms. In this project, it is critically important to immediately determine:
which specific sources of the stream we are using,
which DEX/types of instructions we cover in the first version,
how we calculate squeeze/impact,
and what format of the result is needed at the output.
I would suggest doing this in stages:
MVP core with ingest, deduplication, raw parsing, and basic detection;
refining filters and rules;
measuring latency/coverage on your infrastructure;
further optimization for real load.
On my part, I can provide a neat implementation with a proper code structure, logging, metrics, and the possibility of further expansion. If you already have a paid private node, this significantly simplifies the start.
Before starting, it is advisable to clarify 4 things:
which specific protocols/pools we support in the first version;
what we formally consider squeeze;
where exactly we send the result;
whether deployment in your environment is included, or I provide the ready code and launch instructions.

I am ready to discuss the MVP within technically clear boundaries without inflated promises.

Attached work:

Pocket Signal Bot V0.1.0

Viktor N.

24 1

Budget: 1000 UAH Deadline: 1 day

Hello. If you need a speed of less than 150 ms and coverage of about 90%+, then regular Solana WebSocket subscriptions are not enough - it is better to rely on Yellowstone Geyser as the main stream, and use WebSocket nodes to achieve coverage and redundancy. Solana explicitly states that Geyser, Yellowstone provides a real-time stream with a delay of less than 100 ms, while WebSocket subscriptions usually provide about 200–500 ms. Also, blockSubscribe in Solana is marked as unstable and works only if the validator is started with rpc-pubsub-enable-block-subscription.