Stop droppingtransactions.
Cleaner submission paths, early transaction visibility, and less raw RPC glue. One API flow replaces a pile of round-trips and retry logic.
Send once, then get early visibility.
The useful speed story on this page is not quote latency. It is landing visibility: submit through one hosted endpoint, then watch `landed` and `processed` events through the transaction stream. Pre-confirmation visibility can arrive in roughly ~200ms when the bundle path is available.
// Submit a signed transaction, then watch early lifecycle updates
import { VenumClient } from '@venumdev/sdk'
// Plain HTTP — server-to-server skips the TLS handshake
const venum = new VenumClient({ baseUrl: 'http://api.venum.dev' })
const { signature } = await venum.send(signedTxBase64)
// waitForTx resolves at the first matching terminal event (~200ms when a bundle path is available)
const landed = await venum.waitForTx(signature, { events: ['landed', 'processed'] })
console.log(`landed: ${landed.signature} slot=${landed.slot}`)From quote to confirmed. One flow.
Every step is designed to reduce the window in which things go wrong: stale quotes, expired blockhashes, slippage misses, and unnecessary submission risk.
Best route, fast
Best route computed locally from streaming pool state. No on-chain simulation needed.
Ready-to-sign tx
Unsigned transaction with optimized compute budget, fresh blockhash, correct priority fee.
Client-side
You sign client-side with your wallet. Venum never touches your private key.
Dedicated path
Submit through a dedicated landing path without stitching raw RPC and custom send logic.
Realtime
Get early landed visibility and fast processed updates without building your own raw RPC tx tracking flow.
Every failure has a root cause.
Venum addresses each one at the infrastructure level, not in your retry loop.
| Problem | Root cause | Venum fix |
|---|---|---|
| TX dropped | Didn't reach the right path in time | Dedicated landing flow with better submission handling |
| Blockhash expired | Too slow between build and submit | Fresh blockhash on every build, fast signing, immediate submission |
| Slippage exceeded | Pool state changed between quote and execution | Quotes from live streaming pool state — minimal stale-data window |
| Sandwiched | Transactions visible to sandwich-aware operators | Protected submission paths reduce exposure |
| Low priority, skipped | Compute unit price too low during congestion | Dynamic tip optimization based on network conditions |
| Compute budget exceeded | Default 200K CU isn't enough for complex swaps | Pre-simulated compute budgets on every transaction |
Everything you would otherwise build yourself.
sendTransaction
- ✕Transactions visible to sandwich-aware operators
- ✕Single endpoint — misses leader if in another region
- ✕Default compute budget — often wrong
- ✕Polling for tx status
- ✕Manual retry logic required
- ✕No MEV protection
Built in
- ✓Protected submission path
- ✓Dedicated transaction landing path
- ✓Pre-simulated compute budget
- ✓Early transaction visibility
- ✓Retry logic built in
- ✓Reduced sandwich exposure by default
Common questions.
Why do Solana transactions drop in the first place?+
A signed transaction has to reach the current leader before it produces a block, with the right priority fee and a valid recent blockhash. Raw `sendTransaction` to a single RPC region misses leaders, ages out blockhashes, and hits congested mempool paths. The classic symptoms — "the wallet popped, but nothing landed" — almost always trace back to one of those three.
What does Venum do that raw sendTransaction does not?+
A dedicated transaction-landing path: regional fan-out so your tx reaches the next leader regardless of where you submit from, retry logic with blockhash refresh, pre-simulated compute budgets, and pre-confirmation visibility (you see your tx state before the cluster fully confirms). The wire format is still a standard signed Solana transaction — only the submission flow improves.
How is this different from a Jito bundle?+
Jito bundles are useful for atomic multi-tx execution and tip-based priority. Venum's landing flow is for single transactions where you want the highest probability of getting included, with retries and visibility, without composing a bundle. You can use both: Venum for normal swaps and sends, Jito when you specifically need bundle semantics.
Do I have to change my signing flow to use it?+
No. You sign the transaction the same way (any wallet, any signing path). The only thing that changes is the submission endpoint — `/v1/send` instead of your current RPC `sendTransaction`. The signed transaction stays standard.
How early can I tell whether the transaction will land?+
You get a lifecycle stream over SSE — sent → seen-by-leader → confirmed → finalized — so the wallet UX can stop spinning earlier and bot logic can branch on real status instead of polling. Status polling via `/v1/tx/:signature` is also available for non-streaming callers.
Is the landing path MEV-protected?+
It uses a protected submission path that reduces sandwich exposure compared to broadcasting via a public RPC mempool. For full MEV protection details and protected-bundle execution, see the MEV Protection page.
Land more transactions.
Cleaner transaction landing without stitching the full path together yourself.
Get a Free API KeyLooking for the endpoints? See the Transaction Sending API — /v1/send, /v1/stream/tx, /v1/tx/:signature.