The Tip Rule
Every transaction you send through Apex must contain exactly one tip that meets all of these conditions:1
A SystemProgram transfer
The tip is a plain
SystemProgram::Transfer instruction to one of the published Apex tip accounts.2
Top level
The transfer is a top-level instruction of the transaction. A transfer made from inside your program through CPI does not count.
3
Funded by a signer
The account that pays the tip signs the transaction. It does not have to be the fee payer.
4
Tip account in the static keys
The tip account appears in the transaction’s static account keys. Do not load it through an address lookup table.
5
At or above your tier's floor
The standard tier floor is 0.001 SOL (1,000,000 lamports). Your key’s tier may set a different floor.
You Only Pay When You Land
The tip is inside your transaction. If the transaction does not land, the transfer never executes and you pay nothing. A rejected, expired, or dropped transaction costs you no tip.Get the Tip Accounts
Call JSON-RPCgetTipAccounts on any Apex endpoint. It needs no API key.
The Published Accounts
The mainnet tip accounts, all vaults of the tip program9ig7pd4gqe2m16ACGPbPo4HfMGD3ba38poDhXEayx7EF. getTipAccounts is the authoritative list: it is what the endpoint accepts, and it is where a change would appear first. Every address starts with APeX, so a substituted account is easy to spot.
Add the Tip Instruction
Where the Tip Goes
The tip accounts are vaults of OrbitFlare’s on-chain tip program. Only the program can debit them. When the Jito path is the one that lands your transaction, the tip minus the 5,000 lamport base fee is bid to Jito in the same bundle as your transaction. You do not add a separate Jito tip. One Apex tip covers all three paths.
A larger tip therefore means a larger bid in the Jito auction. It costs you the same amount whichever path lands the transaction, because the tip is the transfer you signed.
Tip and Priority Fee Are Different Things
Apex gets your transaction to the leader. The leader’s scheduler still orders transactions by priority fee, which is your compute unit price multiplied by your compute unit limit. Set both on every transaction:- A compute unit limit close to what the transaction really uses. An oversized limit lowers your effective priority per unit and wastes block space.
- A compute unit price that fits the current market for the accounts you touch.
TransactionConfig instead.
See Best practices for guidance on sizing both.