Billing
A default landed submission costs 0.00015 SOL. Balance-funded transactions that do not land are fully refunded; in-transaction payments only execute with the transaction.
The model#
Balances are prepaid in native SOL. There is no card, no invoice and no subscription. You can pay from that balance or include the exact SOL payment in the signed transaction. There is no monthly minimum, no commitment, and nothing to cancel.
Balance-funded sends are fully refunded when they do not land. An in-transaction SOL payment has no separate refund because the transfer only executes when the transaction executes.
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 with prepaid balance | 0.00015 SOL reserved |
| Prepaid transaction lands | 0.00015 SOL settled |
| Prepaid transaction does not land | fully refunded |
| In-transaction SOL payment | executes with the transaction |
| In-transaction payment does not land | no transfer occurs |
| 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 |
Refused submissions and forwarding failures cost nothing. A balance-funded charge is provisional until landing is resolved.
When it does not land#
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.
The dashboard and landing-performance endpoint track this asynchronously from the submitted signature. Durable nonce transactions remain pending until the chain proves they landed or can no longer execute.
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.
Two payment modes#
Balance payment: the complete charge is reserved when the transaction is accepted. If it does not land, the complete charge is automatically refunded. If it lands, the charge settles.
In-transaction SOL payment: include the exact System Program transfer in the transaction you sign. There is no separate refund operation. If the transaction does not execute, the transfer does not execute, so no payment leaves your wallet.
Running out#
An empty balance does not block a transaction containing the exact in-transaction SOL payment. Otherwise the submission is refused with 402 PAYMENT_REQUIRED and costs nothing.
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.