Parallel Landing

Submitting a Solana transaction is a probability problem. Network congestion, leader schedule, validator behaviour, and dozens of other factors mean that any single submission path has some chance of taking a while or failing entirely. Most tools accept this by submitting once and praying. Dequan does not.

​

The race

The moment your transaction is signed, Dequan fires it across three completely separate submission methods simultaneously:

1. Direct-to-validator — Dequan tracks pump.fun’s on-chain program in real time, ingesting instruction changes as they are published, so the transaction is built against the freshest possible state and submitted directly into the validator pipeline.
2. Raptor (via Geyser gRPC) — SolanaTracker’s Raptor service, which uses Solana’s Geyser gRPC stream for low-latency block propagation.
3. Jito — Jito’s block-engine submission path, which bundles transactions for priority inclusion by Jito-connected validators.

These are not three routes to the same destination. They are three distinct submission mechanisms with different propagation paths, different congestion profiles, and different validator coverage. The first to achieve block inclusion wins. The other two are rejected by the network’s own deduplication — the same signed transaction cannot be included more than once. You don’t choose a path. You don’t toggle it on. The race happens automatically on every Dequan trade. The result, in normal conditions: confirmations land in well under one second. During congestion: trades that would revert or sit pending on a single-path tool still land on Dequan because at least one of the parallel paths usually finds inclusion.

​

Why this works

The three submission methods are deliberately diverse — direct-to-validator, Raptor/Geyser, and Jito each have different latencies, different congestion characteristics, and different validator relationships. When one path is under backpressure, the others are not. When the network is calm, any of them works fine. When the network is hostile, the race across all three is dramatically more reliable than any single path’s worst case. In practice this means the tail latency — the slow trades, the ones that ruin your day — is much lower on Dequan than on a tool with a single submission lane.

​

The user-visible behaviour

You don’t see the race. You see:

1. You press Buy.
2. The wallet signs (or Lightning Wallet signs server-side if you have it enabled).
3. Within roughly half a second, you have a signature back.
4. Within another short window, the buy is confirmed and a ‘B’ marker appears on the candle chart inside the drawer.

That’s it. The complexity is invisible. Either the transaction lands or it doesn’t, and the odds of “it lands” are dramatically improved by running multiple lanes.

​

What about duplicates?

A Solana transaction has a unique signature, and the network deduplicates by signature. Submitting the same signed transaction across multiple paths cannot result in a duplicate fill — at most one copy can ever be included. The race is therefore safe, not chaotic.

​

What about failed transactions?

If every lane fails to land, Dequan surfaces a clear failure to you immediately, including which paths were attempted and what each said. You can retry instantly with a single tap. When this happens, it is almost always a legitimate failure — slippage was actually exceeded, the pool was actually drained, the route became actually invalid. In those cases no submission path could have helped, and you want to know fast rather than wait silently for a confirmation that isn’t coming.

​

What you can verify

The Timings panel records, for every trade, which submission path landed it. Over a session you’ll see the win distribution across paths — and on bad-network days you’ll see the diversity earning its keep. This is the kind of internal observability most tools never expose. Dequan exposes it because we want you to understand the value, not just be told about it.

​

What this isn’t

It is not a single magic RPC provider. It is three named, production-grade submission methods — direct-to-validator, Raptor, and Jito — running in parallel on every trade. Engineering discipline applied to the submission step, adapted for the realities of trading on Solana. Traditional submit-and-pray fails materially more often during meme volatility. Dequan’s three-way race fails materially less. That difference compounds over hundreds of trades into a real edge.