Sending Transactions on Solana
Optimize your transactions to minimize confirmation latency and maximize delivery rates.
Last updated
Was this helpful?
Optimize your transactions to minimize confirmation latency and maximize delivery rates.
Last updated
Was this helpful?
Helius' staked connections guarantee 100% transaction delivery with minimal confirmation times.
We recommend the following best practices to help you land transactions:
Use available with .
Use commitment "processed" or "confirmed" to fetch the
Add and
Optimize (CU) usage
Set maxRetries
to 0 and
Send with skipPreflight
set to true (optional)
We recommend the following optimizations for latency-sensitive traders. You must already be applying the best practices for sending transactions mentioned above.
Send transactions from Eastern US or Western Europe.
Choose Frankfurt or Pittsburg if you want to co-locate with Helius transaction-sending servers.
Avoid sending regions far away from the validator network (e.g. LATAM or South Africa).
Warm the Helius regional caches to minimize tail latency.
Send a call every second using the same endpoint & API key you use for sending transactions.
Only one warming thread is required per region. Any more will have zero benefit.
Shared Staked Endpoint (default)
Requirements:
Priority fees meet or exceed the recommended
value provided by the Priority Fee API
Set maxRetries
to 0
Endpoint: https://mainnet.helius-rpc.com/?api-key=xxx
Cost: 1 credit per request
Tips:
Check if you're getting staked connections by logging the X-Helius-ConnectionType
response header. The value will be regular
or staked
.
Dedicated Staked Endpoint
Recommended for top traders or teams who want guaranteed access to staked connections, even during market congestion
Transactions will be sent over staked connections via an optimized network (Asia, Europe, and North America), minimizing latency and confirmation times.
Endpoint: https://staked.helius-rpc.com?api-key=xxx
Cost: 50 credits per request.
At the most basic level, users must supply their keypair and the instructions they wish to execute, and we handle the rest.
We:
Fetch the latest blockhash
Build the initial transaction
Simulate the initial transaction to fetch the compute units consumed
Set the compute unit limit to the compute units consumed in the previous step, with some margin
Set the priority fee (microlamports per compute unit) as the Helius recommended fee
Adds a small safety buffer fee in case the recommended value changes in the next few seconds
Build and send the optimized transaction
Return the transaction signature if successful
This method is designed to be the easiest way to build, send, and land a transaction on Solana.
Note that by using the Helius recommended fee, transactions sent by Helius users on one of our standard paid plans will be routed through our staked connections, guaranteeing nearly 100% transaction delivery.
The following example transfers SOL to an account of your choice. It leverages sendSmartTransaction
to send an optimized transaction that does not skip preflight checks
The following example transfers 0.01 SOL to an account of your choice. It leverages send_smart_transaction
to send an optimized transaction that skips preflight checks and retries twice, if necessary:
First, prepare and build the initial transaction. This includes creating a new transaction with a set of instructions, adding the recent blockhash, and assigning a fee payer. For versioned transactions, create a TransactionMessage
and compile it with lookup tables if any are present. Then, create a new versioned transaction and sign it — this is necessary for the next step when we simulate the transaction, as the transaction must be signed.
For example, if we wanted to prepare a versioned transaction:
It's recommended to use a test transaction with the desired instructions first, plus an instruction that sets the compute limit to 1.4m CUs. This is done to ensure the transaction simulation succeeds.
For example:
It is also recommended to add a bit of margin to ensure the transaction executes without any issues.
We can do so by setting the following:
Then, create an instruction that sets the compute unit limit to this value and add it to your array of instructions:
This is relatively straightforward.
Your code should look something like bs58.encode(txt.serialize());
Then, create an instruction that sets the compute unit price to this value, and add that instruction to your previous instructions:
This step is almost a repeat of the first step. However, the array of initial instructions has been altered to add two instructions to set the compute unit limit and price optimally.
Now, send the transaction.
It doesn't matter if you send with or without preflight checks or change any other send options — the transaction will be routed through our staked connections.
While staked connections will forward a transaction directly to the leader, it is still possible for the transaction to be dropped in the Banking Stage. It is recommended that users employ their own rebroadcasting logic rather than rely on the RPC to retry the transaction for them.
sendSmartTransaction
Handles Polling and RebroadcastingThe sendSmartTransaction
method has a timeout period of 60 seconds. Since a blockhash is valid for 150 slots, and assuming perfect 400ms slots, we can reasonably assume a transaction's blockhash will be invalid after one minute.
The method sends the transaction and polls its transaction signature using this timeout period:
txtSig
is set to the signature of the transaction that was just sent. The method then uses the pollTransactionConfirmation()
method to poll the transaction's confirmation status. This method checks a transaction's status every five seconds for a maximum of three times.
If the transaction is not confirmed during this time, an error is returned:
We continue sending the transaction, polling its confirmation status, and retrying it until a minute has elapsed. If the transaction has not been confirmed at this time, an error is thrown.
The benefits will only be noticeable to experienced traders. We recommend the section instead for app developers.
Staked Connections help you land transactions faster with an increased land rate. Helius provides two methods to access staked connections with any (not available on Dedicated Nodes).
Usage metrics display staked endpoint calls as sendTransactionWithStake
to avoid collisions with regular .
Both the Helius and SDKs can send smart transactions. This new method builds and sends an optimized transaction while handling its confirmation status. Users can configure the , such as whether the transaction should skip preflight checks.
Get the Helius recommended priority fee via our
The sendSmartTransaction
method is available in our for . To update to a more recent version of the SDK, run npm update helius-sdk
.
The send_smart_transaction
method is available in our for . To update to a more recent version of the SDK, run cargo update helius
.
We recommend sending smart transactions with one of our SDKs but the same functionality can be achieved without using one. Both the and are open-source, so the underlying code for the send smart transaction functionality can be viewed anytime.
To optimize the transaction's compute unit (CU) usage, we can use the RPC method to simulate the transaction. Simulating the transaction will return the amount of CUs used, so we can use this value to set our compute limit accordingly.
First, to serialize the transaction, both Transaction
and VersionedTransaction
types have a .serialize()
method. Then use the to encode the transaction.
First, use the to get the priority fee estimate. We want to pass in our transaction and get the Helius recommended fee via the recommended
parameter:
The RPC method has a maxRetries
parameter that can be set to override the RPC's default retry logic, giving developers more control over the retry process. It is a common pattern to fetch the current blockhash via , store the lastValidBlockHeight
, and retry the transaction until the blockhash expires. It is crucial to only re-sign a transaction when the blockhash is no longer valid, or else it is possible for both transactions to be accepted by the network.
Once a transaction is sent, it is important to poll its confirmation status to see whether the network has processed and confirmed it before retrying. Use the RPC method to check a list of transactions' confirmation status.
The also has a on its to fetch the current status of multiple signatures.