🟩 Before you raise Solana priority fees again, check what you are actually paying for

A higher CU price is only half of the fee equation. The other half is the compute-unit limit you request.

At the network level:

total network fee = base fee + priority fee
base fee = signatures × 5,000 lamports
priority fee = ceil(CU price × CU limit / 1,000,000)

For a transaction with 1 signature, a CU price of 50,000 micro-lamports, and a requested CU limit of 300,000 CUs, the priority fee is:

ceil(50,000 × 300,000 / 1,000,000) = 15,000 lamports

After adding the 5,000 lamport base fee, the total network fee is 20,000 lamports, or 0.00002 SOL.

The practical detail is that priority fee is calculated from the requested CU limit, not from the compute the transaction actually consumes.

If simulation shows that a transaction usually needs around 180,000 CUs, but the app requests 600,000 by default, the priority fee is still charged on 600,000. Some margin is useful, but an oversized margin becomes repeated overpayment.

For production flows, fee tuning usually means simulating first, setting a realistic CU limit with a controlled buffer, estimating CU price dynamically, and checking whether higher spend actually improves landing.

👉 Read our full guide

=========================
HighTower | Supanode | Get a 48h trial

🟩 Choosing a low-latency Solana RPC provider?

Do not start with the homepage number

The better starting point is where your workload runs and what it actually does.

A provider page can show regions, uptime, and latency, but your backend may be in a different cloud region, using heavier RPC methods, sending bursts of requests, tracking confirmations, or relying on fresh streams.

A useful benchmark should come from the same VPS or cloud region as the app, use the methods the app actually calls, and measure p50, p95, and p99 under realistic concurrency.

It should also include burst traffic, because 429s, stream delay, slot freshness, and confirmation tracking issues often stay invisible in clean single-request tests.

➡️ Read the full guide

=========================
HighTower | Supanode | Get a 48h trial

💵 Build, simulate, sign, submit, and confirm a custom Jupiter swap

Jupiter /build returns instruction groups instead of a finished transaction. That gives you room for custom logic, while the rest of the transaction lifecycle moves into your application.
From there:

→ add custom instructions without breaking the route’s account-state assumptions
→ simulate the complete transaction and set its CU limit from measured usage
→ check onchain status before retrying the same signed transaction or rebuilding and re-signing

👉 The full TypeScript flow, including tx.jup.ag vs your own RPC

=========================
HighTower | Supanode | Get a 24h trial