Sending Turbo Transactions
Last updated
Last updated
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:
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
and Add 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!
Keep in mind that due to its design which is comprised of upstream proving, Turbo transactions usually take longer to complete and it might take several minutes before they get broadcasted on-chain.
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:
This query will return a JSON object containing a herdotusApiTransactionIdentifier
. For instance:
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.
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.
An easy workaround is to inflate the gas price of the signed transaction to absorb any “gas slippage” that might arise between the time the transaction is signed and the time it’s ready to be sent.