Sending Turbo Transactions
Sending transactions that interact with Turbo-enabled smart contracts differs from sending regular Ethereum transactions and requires some additional steps to ensure proper execution. Here's a detailed guide on how to send Turbo transactions:
1. Add a custom network to your provider
The first and most crucial step in sending a Turbo transaction is to use a Turbo-enabled RPC Endpoint.
Unlike regular Ethereum transactions that can be sent through any compatible RPC, Turbo transactions must be processed through a special RPC that understands and can handle Turbo-specific operations, that is simulating transactions and proving required data when necessary.
Actions Steps (for browser)
Open your browser wallet, go to
Networks
andAdd a Custom Network
.Fill in the input form based on the corresponding Turbo-enabled RPC you are trying to interact with for a given chain. View the list of supported networks here.

That’s all, you can now send Turbo transactions like you already do elsewhere!
2. Wait for Confirmation
To retrieve the status of a Turbo transaction, you can use the transaction hash returned by the Turbo RPC to query the status. Here's how it works:
After sending a Turbo transaction, you'll receive a transaction hash from the RPC.
Use this hash to make a GET query in the following format:
https://TURBO_RPC_URL/herodotus-req-id?txHash=YOUR_TRANSACTION_HASH
For example:
GET https://eth-sepolia-turbo.api.herodotus.cloud/herodotus-req-id?txHash=0x42a415fb9afe239ca755ffe8bf2c53971391140e3a7b321f247f03e1a6dff139
This query will return a JSON object containing a
herdotusApiTransactionIdentifier
. For instance:
{
"herdotusApiTransactionIdentifier": "01HYDSWQTY2GXCZ8SVVNWKC0N3"
}
You can then use this identifier to view detailed transaction information on the Herodotus Dashboard. Simply append the identifier to the following URL:
https://dashboard.herodotus.dev/explorer/query/YOUR_IDENTIFIER
. For example https://dashboard.herodotus.dev/explorer/query/01HYDSWQTY2GXCZ8SVVNWKC0N3

The dashboard UI will automatically update itself throughout the lifecycle of the Turbo transaction and will eventually display the user transaction sent on-chain.
3. Gas considerations (for Turbo app developers)
When the Turbo-enabled RPC receives a Turbo transaction using the eth_sendRawTransaction
method (i.e., a smart contract call under which at least one Storage Proof's underlying data is being accessed), the transaction itself has already been signed by the sender and its gas parameters (gasLimit
, maxPriorityFeePerGas
, maxFeePerGas
etc) are immutable.
Before being able to broadcast the origin transaction to the network, often times some proving is required (e.g., proving block headers, accounts properties, storage slots...) and some time elapses before the proofs are settled and verified on-chain (i.e., the proving time).
By the time the origin transaction is ready to be sent to the network (i.e., when all requested data has been proven), some time passed and the network gas might have changed, potentially drastically, especially during gas spikes. Broadcasting the transaction further is such situation can lead to a stuck or dropped transaction by the sequencer as the gas parameters initially signed may not reflect the current ones.
We are internally working on features leveraging account abstraction to mitigate this problem.
Last updated