This is an informative piece, written to help our users understand all things Jupiter & Solana.
We all want to land our transactions as cheaply and quickly as possible, AND not get rekt by slippage.
Jupiter pushes this frontier forward for our users, with Transaction Broadcasting modes, allowing users to choose and decide how they want to land transactions on Jupiter Exchange.
Let’s talk about Transaction Broadcasting on JupiterExchange.
Today, Jupiter offers 2 ways of landing your transactions.
- Regular RPC, either Helius or Triton, and using Jupiter Validator’s SWQoS to forward your transaction quickly to the leader validator.
- Jito-Only mode, sending your transaction directly to a Jito-client leader validator, with a tip, to be included.
Of course, you can also fire a transaction via both pathways.
RPC
If you use a regular RPC, your transaction will be fired through a variety of RPCs, such as Helius and Triton, and also go through the Jupiter Validator, eventually arriving at the Leader Validator.
Jupiter Validator allows us to fire more transactions to the leader-validator, proportional to the amount of SOL staked, this is why more SOL staked to JupSOL helps us land transactions.
The Leader Validator sees the incoming transactions, and then prioritises those with the highest priority fees, before building the block. The Leader Validator’s role is to pack a block of 48M Compute Units (CU), and thus cares about the Priority Fees per CU, and not the priority fee of an overall TX.
Jupiter aims to reduce the CU of their transactions to reduce the priority fees paid by users and improve the landing rate of transactions.
As transactions here go through multiple RPCs, and validators (including the leader), it is prone to being sandwiched by searchers who try to see incoming transactions and manipulate the state before and after the transaction (buy → user swap → sell).
Jito
Alternatively, users can send their transactions to Jito’s Block Engine, which directs their transactions to the current and next few leader validators, assuming they are running the Jito client.
When sending transactions via Jito-Tip, the priority fee for the TX is set to the minimum 0.000005 SOL fee.
These transactions are submitted in a bundle of at least 2 transactions but up to 6. Each bundle always contains a “tip” transaction, which transfers a small SOL amount to the leader validator.
The leader validator has to accept the entire bundle or deny it. Thus, in order to collect the tip, the leader includes the bundle into the block, thus confirming your transaction (as well as the tip).
As of the time of writing, Jito Bundles compete with each other on a pure Tip basis, regardless of CU.
If any transaction in the bundle fails, the entire bundle reverts. The benefit of Jito-only mode is that your transactions are immune to sandwiching, where another malicious actor manipulates the pool before you swap through it.
The tradeoff here is that Jito’s Client is on 80% of stake. This means that there is a rough 80% probability that the current leader validator is not a Jito-client operator, and can’t accept jito-transactions.
A backlog of transactions will also be created, and your transaction has to compete with the others in the form of tips to be added into the block.
Setting the Right Fees
Either on Jito Tip or RPC-only, Jupiter intelligently sets the fees for you.
Users are able to control how much fees to use via a simple “Fast, Turbo, Ultra” selector on the website. Behind the scenes, we amplify the transaction fees accordingly to percentile.
For RPC Mode, when returning your Swap Route (which AMMs and Markets your TX goes through), we also calculate the priority fees required to interact with these markets.
This is because priority fees are “local” dependent on Solana, where interacting with a hot market might require more priority fees.
For Jito, Tips are global, regardless of what markets or accounts your swap is interacting with. We query and maintain a cache of Jito’s tips in real-time, and send transactions according to the percentile and your settings accordingly.
Mixed Mode
There is also the option of firing a transaction with BOTH the jito-tip, and the priority fee.
This means that the TX contains both priority fees, and is sent via the block-engine AND regular RPCs to the leader validator.
This is a faster and better way to land transactions, ensuring it lands via Jito or RPC, whichever is first. It also improves your odds of landing, as your TX may get dropped by the leader validator via RPCs but land via Jito Tips.
However, there is also a tradeoff.
You pay double the transaction fees when landing with Jito, and you don’t pay the jito-tip when landing via RPCs.
Thus, we call our max caps “Each Max Cap” representing that the max-cap is per-tx landing mode (RPC/Jito), and not for both.
What does this mean for me?
We mainly wrote this piece as an informative piece, hope this helps you understand how priority fees and landing transactions on Solana work.
Biggest takeaways:
- Use Jito-only [or MEV Protect] if you want to avoid getting sandwiched
- Use Mixed Mode, for highest landing transaction speed
- Set a Max Cap for TX fees and never worry about it again.
Let us know what you want to read about!