Submit Solana transactions
Submit signed Solana transactions with sendTransaction on Corvus Solana RPC, confirm by signature, and handle the TPS rate limit.
You send a signed, serialized transaction to sendTransaction at http://<region>.corvus-labs.io:8899, and you get its signature back.
Acceptance is not confirmation
A signature in the response means the gateway took your bytes, nothing more. The transaction can still fail, expire, or never land at all, and querying the signature is the only way to know.
Cost
sendTransaction costs 0 RPS units. It draws on your TPS allowance instead, and the two don't trade against each other. See Rate limits.
Submission lifecycle
Get a blockhash and simulate
Fetch a blockhash with getLatestBlockhash and hold on to lastValidBlockHeight. simulateTransaction isn't one of the weighted methods; it costs 1 RPS unit and none of your TPS.
Sign once, keep the bytes
Persist the serialized bytes, the signature and lastValidBlockHeight before you send anything.
Send
Keep both the HTTP status and the JSON-RPC body. A 429 here is the gateway turning you away, not your transaction failing.
Confirm by signature
Poll getSignatureStatuses, or subscribe with signatureSubscribe over WebSocket, until the signature reaches the commitment you need, or until lastValidBlockHeight passes, after which the transaction can never land.
Retry by resending the same bytes
Resend the identical signed bytes while the blockhash is still valid, rather than re-signing.
Handling 429s
| Code | Prefix | What it is |
|---|---|---|
-32005 | Transaction rate limit exceeded | Your TPS allowance |
-32005 | Scan request timed out waiting for concurrency slot | Scan concurrency on another request; see Rate limits |
-32001 | RPS limit exceeded | Your read allowance; confirmation polling counts against it |
Transaction throughput and scan concurrency share -32005, so branch on the message prefix rather than the code alone. The full contract is in Gateway & streaming errors.
A send that times out at the transport level tells you nothing about whether the gateway received it. Query the signature before you resend.
Should you use Falcon instead?
Falcon is our service built for landing transactions: it submits over stake-weighted QoS backed by more than 1,000,000 SOL of stake, and in parallel through the Jito and Harmonic bundle engines. sendTransaction has none of that behind it, which makes it the cheaper way to push volume and the slower way to land. If you're competing to land first, pay Falcon's tip and go there.
Solana RPC sendTransaction | Falcon | |
|---|---|---|
| Submission path | Plain forwarding | SWQoS (1M+ SOL staked) plus the Jito and Harmonic bundle engines |
| Transports | JSON-RPC over HTTP | JSON-RPC/HTTP, QUIC, native UDP |
| Regions | 5 metros | 9 metros; see Falcon regions |
| Tip | Not required | Minimum 1,000,000 lamports (0.001 SOL) to a Fa1con1… tip account |
| Auth | IP allowlist or tokenized URL | Falcon API key (UUID) |
| Duplicate handling | — | Signature-keyed suppression, applied only after a submission has been delivered |