Billing
Each accepted submission costs 0.0002 SOL, deducted from a prepaid SOL balance. Refused submissions are free, duplicates are free, and a submission we fail to forward is charged and then automatically reversed.
The model#
Balances are prepaid in native SOL. There is no card, no invoice and no subscription. You deposit SOL, and each accepted submission deducts a fixed price. There is no monthly minimum, no commitment, and nothing to cancel. If you stop sending, you stop paying, and whatever is left stays on your balance.
You are charged once a submission is accepted and forwarded. Refused submissions are free.
The exact boundary#
This table is the implementation, not a summary of it. Every row is a real branch in the relay.
| Outcome | Charge |
|---|---|
| Accepted and forwarded upstream | 0.0002 SOL |
| Duplicate signature within 90s | free |
| Invalid transaction envelope | free |
| Unknown or invalid API key | free |
| Account disabled | free |
| Insufficient balance | free |
| Forwarding failed upstream | charged, then reversed |
| Accepted but never lands on chain | 0.0002 SOL |
The pattern is simple once you see it: you pay when we do the work of forwarding your bytes, and you do not pay when we refuse them or when we fail.
Accepted but not landed#
Things that stop an otherwise valid transaction from landing include an expired blockhash, an insufficient priority fee during contention, account lock contention, and program errors. None of those are visible to us at forwarding time, and none of them are something we could fix by charging you differently.
If you want to measure this for yourself, keep the signature from each receipt and check it asynchronously with getSignatureStatuses. That gives you a real landing rate for your own traffic, which is a more useful number than anything we could put on a marketing page.
Reversals#
The charge is persisted before we forward, deliberately, so that a crash can never leave a forwarded transaction unbilled or an unaudited submission in flight. If the upstream write or acknowledgement then fails, we write a compensating refund and return 503 UPSTREAM_UNAVAILABLE.
In your transaction register those submissions show a charge and a matching refund, netting to zero. That is working as intended, not a billing bug.
This is not a tip#
The price is a fee for the relay, not a validator tip, and the distinction matters on Solana. We do not add tip instructions to your transaction, we do not adjust your priority fee, and nothing we charge ends up in a tip account attached to your transaction.
If your strategy needs a priority fee or a tip, put it in the transaction yourself before you sign. We will forward it unchanged like everything else.
Running out#
A submission against an empty balance is refused with 402 INSUFFICIENT_BALANCE and costs nothing. Nothing is queued and nothing is silently dropped, so your client finds out immediately and can decide what to do.
The dashboard shows how many sends your balance is worth at your effective price, and warns as it depletes. Top up from deposits, and sending resumes as soon as the deposit finalizes.
One more thing worth knowing: a duplicate inside the 90 second window is free, so a retry loop on a transient error will not charge you twice for the same transaction.