Priority

Priority lets you pay more to get faster transaction. Higher priority helps you win when competing with other traders or when the Solana network is busy.

Priority levels

Level	Best for	Total priority fee (per tx)
`economy`	lowest cost / testing	0.000001 SOL
`fast`	most users (good default)	~0.000015 SOL
`faster`	competitive buys/sells	~0.00075 SOL
`fastest`	maximum speed	~0.003 SOL

“Total priority fee” here is just an estimate. It will change with Solana network load.

Which one should I pick?

economy: use when you’re testing or cost matters more than speed.
fast: best default for normal trading.
faster: use when you’re racing other buyers/sellers, ideal for token sniping.
fastest: use when you need the best chance to land quickly and you’re okay with paying more.

Sniping / low latency

If you’re sniping and latency matters:

Run your servers in Frankfurt for the lowest latency to our infrastructure.
- This means faster WebSocket data (you see events sooner → faster signals).
- It also means faster transaction build + submission (less time spent on network RT).
- For the lowest possible latency, colocate in the NTT FRA1 datacenter.
Use HTTPS keep-alive (reuse the same connection) to avoid re-connecting and TLS handshake for every request. (The SDK already does this.)
- Send a ping every 60 seconds to keep the connection warm between trades. The server’s keepalive is set to 70 s / 10 000 requests — hitting GET /v1/ping every 60 s stays safely within that window. (The SDK already does this automatically.)

How to use it

REST (build endpoints)

Send priority on buy/sell/swap:

"priority": "fast"

Valid values: economy | fast | faster | fastest

TypeScript SDK (examples)

await sdk.buy({
  mint: "5UUH...",
  solAmount: 0.002,
  slippage: 0.1,
  priority: "fast"
});

Enforce limits

Every build endpoint (/v1/tx/buy, /v1/tx/sell, /v1/tx/swap) returns a priorityCost field showing the actual priority fee for that transaction.

Because priority cost changes with network load, you get the real cost at build time and can decide if it’s too expensive before signing and submitting.

Common approaches:

Absolute cap: Set a maximum SOL amount (e.g., 0.001 SOL). If priorityCost exceeds it, skip submission.
Percentage cap: Set a max fee relative to your trade size (e.g., 1% of input). If priorityCost is too high, skip submission.