TLDR:Documentation Index
Fetch the complete documentation index at: https://docs.chainstack.com/llms.txt
Use this file to discover all available pages before exploring further.
- Sandwich attacks front-run and back-run your transaction within the same bundle, extracting value at your expense.
- Jito’s
dontfrontfeature prevents this by ensuring your transaction must appear at index 0 in any bundle. - You add a pubkey starting with
jitodontfrontas a read-only account to any instruction, then send through Jito’s block engine. - Chainstack Warp transactions optimize for speed (bloXroute relay). Jito
dontfrontoptimizes for protection. Choose based on your use case.
What is a sandwich attack?
A sandwich attack is when a searcher:- Front-runs your swap by buying the same token before you, pushing the price up
- Your transaction executes at the inflated price
- Back-runs by selling immediately after, profiting from the price difference
How Jito dontfront works
Jito’s block engine processes transaction bundles. The dontfront feature is a simple opt-in:
- Add a pubkey starting with
jitodontfront(e.g.,jitodontfront111111111111111111111111111111) as a read-only account to any instruction in your transaction - Send the transaction through Jito’s block engine endpoint (not a standard RPC)
- The block engine enforces that your transaction must be at index 0 in any bundle that includes it
Get your own node endpoint today
Start for free and get your app to production levels immediately. No credit card required.You can sign up with your GitHub, X, Google, or Microsoft account.Implementation
Prerequisites
Add dontfront protection to a transaction
Chainstack Warp transactions vs Jito dontfront
Chainstack offers two transaction acceleration paths. They serve different purposes:
| Warp transactions | Jito dontfront | |
|---|---|---|
| Goal | Maximum speed — fastest landing | MEV protection — prevent sandwich |
| Mechanism | bloXroute relay for optimized propagation | Jito block engine enforces bundle index 0 |
| Endpoint | Your Chainstack RPC (with Warp enabled) | Jito block engine (mainnet.block-engine.jito.wtf) |
| Front-running protection | No — speed-optimized, protection disabled | Yes — core feature |
| Tip required | No | Yes (minimum 1000 lamports) |
| Best for | Arbitrage, sniping, latency-sensitive trades | Swaps, DeFi interactions where execution price matters |
dontfront when you need to protect your execution price (others are competing against you).
For reads (getAccountInfo, getBlock, etc.), always use your Chainstack Solana endpoint.
Tips
- Jito tip amounts should be minimum 1000 lamports. For
sendTransaction, use a 70/30 split between priority fee and Jito tip. - Pick tip accounts at random to reduce contention across the 8 Jito tip accounts.
- When using
sendBundle,dontfronttransactions must be contiguous at the front of the bundle with overlapping signers. dontfrontis mainnet and testnet only — it does not work on devnet.
Additional resources
- Solana Trader Nodes with Warp transactions — Chainstack’s speed-optimized transaction path
- Priority fees for faster transactions — set optimal priority fees
- How to handle the transaction expiry error — retry logic