Fast Send
Solana transaction submission

POST a signed Solana transaction. Venum fans it out across multi-channel landing infrastructure — RPC, Jito, direct-to-leader, specialized senders — and gives you back a signature you can track with SSE or polling. One hosted endpoint, optimised for landing rate.

Get Free API KeySend API DocsTX Stream Docs
1
Send endpoint
2
Tracking options
Any
Signed transaction
SSE
Realtime updates

Typical Flow

1
Send any signed transaction
Use `/v1/send` when you already have a signed transaction and want one hosted submission surface instead of wiring your own send flow.
2
Track early lifecycle updates
Use `/v1/stream/tx` for realtime transaction lifecycle updates when your app or bot needs fast post-submit visibility.
3
Fall back to status polling
Use `/v1/tx/:signature` when SSE is unavailable or when you want a simple status check after submission.

Core Endpoints

POST /v1/send
Submit any signed transaction
GET /v1/stream/tx
Realtime transaction lifecycle updates
GET /v1/tx/:signature
Fallback status polling
◆ One flag away

Reduce exposure to MEV

The standard /v1/send path fans your transaction out across multiple landing channels for high-availability. When the dominant concern is keeping your transaction off RPC operators' watch — i.e. closing the most common front-run / sandwich vector — add the X-Senders: tpu header and the submission goes straight to the slot leader instead.

Private send overview →

Need atomic multi-tx execution? /v1/bundle sends 1–5 signed transactions as an all-or-nothing Jito bundle — see the bundle endpoint docs.

FAQ

Common questions.

What does /v1/send do that my RPC's sendTransaction doesn't?+

It runs your signed transaction through a dedicated landing path with regional fan-out, retry on blockhash expiry, and pre-confirmation visibility — instead of broadcasting to a single RPC region and waiting on polling. The wire format you submit is identical: a base64 signed Solana transaction.

Do I sign the transaction before calling /v1/send?+

Yes. Venum never sees private keys. Build the transaction yourself or via `/v1/swap/build`, sign with your wallet, then POST the signed bytes to `/v1/send`. The signing flow doesn't change.

How do I track a transaction after submission?+

Two options: `/v1/stream/tx?signature=…` opens an SSE stream that emits sent → seen → confirmed → finalized as the cluster progresses, and `/v1/tx/:signature` returns a snapshot if you prefer polling. Use the stream for realtime UI; use polling for batch jobs and webhooks.

What happens if a transaction expires before landing?+

The lifecycle stream surfaces the expiration explicitly so your code can rebuild and resubmit with a fresh blockhash. Internal retries cover transient-network expiries; permanent expiry (your blockhash aged out) is reported back so your client can react.

Are there rate limits on /v1/send?+

Yes — per-minute request caps follow the tier you're on (Free / Starter / Pro). Submission limits are documented per tier; Enterprise quote available if you need sustained capacity above Pro.

Can I use /v1/send for transactions I built somewhere else (not /v1/swap/build)?+

Yes. Any signed Solana transaction is valid input — built with raw `@solana/web3.js`, the Anchor IDL, a wallet adapter, or a different builder API. The send endpoint doesn't care where the transaction came from.

Need Hosted Send + Track?

Start with `/v1/send`, then layer in realtime tracking with `/v1/stream/tx` as your flow grows.

Get Free API Key

Want to know why these endpoints land transactions more reliably than raw sendTransaction? Read about Solana transaction landing.