This file distinguishes public protocol limits from application/RPC pacing and describes fee consequences of successful, failed, and preflight-rejected transactions. It publishes no account expenditure or fee-payer balance.
TL;DR
- Solana fees require spendable fee-payer SOL, independently of trading collateral.
- Packet size is at most 1232 bytes; the network CU ceiling is 1,400,000.
- Priority fee uses the requested CU limit and CU price, not just actual CU consumed.
- A landed failed transaction can charge a fee; a preflight refusal before forwarding does not land.
- REST/RPC quota and all client pacing remain explicit settings.
1. Fee formula
For a transaction with S signatures, requested compute limit L, and micro-lamport price P, the documented fee components are:
baseFeeLamports = 5000 × S
priorityFeeLamports = ceil(L × P / 1_000_000)
Rates can change; verify current Solana fee rules. A synthetic example with one signature, 200,000 CU, and 2,000 micro-lamports per CU gives 400 priority lamports in addition to the base fee. This is invented arithmetic, not a recorded transaction or recommended setting.
SOL used for network fees is separate from USDC trading collateral and from any native-SOL collateral tracked by Phoenix. An account may have adequate margin but an unusable fee payer. Report stale/unreadable SOL balance as unknown.
2. Packet and compute limits
Solana's serialized transaction ceiling is 1232 bytes. The compute ceiling is 1,400,000 CU per transaction. Choose a compute limit based on simulation and current instruction/account complexity, then measure the final serialized transaction. An unnecessarily high CU limit can increase priority fee.
The toolkit bounds cancellation batches at 30 IDs as a conservative layout-specific guard. The SDK's instruction count allowance is not a network-size guarantee. Additional accounts/instructions alter size, and CU per added cancellation ID was not fully measured. orders.md §5 explains safe splitting.
Public SDK source also defines a book ceiling of 64 resting limit orders per trader, per market, per side. This is unrelated to request throughput.
3. Paid and unpaid refusals
Margin failure, invalid reduce-only state, or packet/program rejection can consume a fee when a transaction lands. A successful transaction with zero posted/fill lots can still carry an order rejection event. Both require result parsing.
RPC simulation/preflight rejection before forwarding does not itself create a landed transaction fee. AlreadyProcessed and uncertain forwarding are exceptions to a simplistic “RPC error means nothing happened” rule: resolve by signature rather than create another transaction.
Recognize repeated structural refusal and stop identical resubmission until new evidence changes the premise. How long to remember a refusal is client policy; no workload-specific timeout is presented as a venue constant.
4. REST/RPC traffic
Numeric public REST ceilings were not established by the checks in this knowledge base. Respect 429/Retry-After and the selected RPC provider's documented quota. Official SDK guidance discusses REST, streams, and RPC as separate data surfaces; this toolkit implements REST reads and experimental RPC signing without claiming the entire upstream streaming API.
Use explicit concurrency/pacing and shared reads where appropriate. Slot on an account-info response belongs to that response; an extra head-slot query cannot make the account bytes fresher. Confirmation delay is variable, so latency samples must not become timing guarantees.
Pitfalls
| What breaks | Why | Correct approach |
|---|---|---|
| All writes fail despite collateral | Fee payer lacks SOL | Read spendable fee-payer balance |
| Batch under SDK ID limit fails | Serialized packet too large | Check 1232-byte boundary |
| “No fill” still costs fees | Transaction landed | Parse and classify rejection |
| Low actual CU assumed cheap | Priority fee uses requested limit | Use correct fee formula |
| Pacing chosen as venue constant | RPC quota differs by endpoint | Explicit workload options |
Open questions / not verified
- Public REST numeric ceilings and provider-specific live RPC quotas.
- CU cost per extra cancel ID and worst-case account complexity.
- A universal confirmation/catch-up deadline cannot be inferred from limited observations.
Sources
Transactions; Fees; WS/API best practices; Rise 0.5.28 scale-order constants in Rise public source. Packet-size checks were performed offline on 2026-09-25; client pacing and batch bounds are implementation choices.
© markpaper authors. Licensed under CC BY 4.0: when publishing or adapting this material, credit “markpaper — Phoenix knowledge base” and link to the original and the license.