Storage Proofs
HomeDashboard
  • Getting Started
    • Introduction
    • Use Cases
    • Quick Start Guide
    • Key Concepts
  • Storage Proofs
    • Overview
    • Workflow
      • Workflow Examples
    • Accessing Block Hash
  • Solutions
    • Storage Proof API
      • Authentication
      • Payload Examples
    • Turbo
      • Workflow
      • RPC Endpoint
      • Turbo Compute
  • Architecture
    • Overview
    • Smart Contracts
    • Cross-Chain Storage Proofs
      • Native Messaging Systems
      • OP Stack Chains
  • Guides
    • Using Storage Proof API
    • Integrating Storage Proofs
    • Building a Storage Proof Powered Bridge
    • Writing Turbo Smart Contracts
    • Sending Turbo Transactions
  • References
    • Contract Addresses
    • Supported Networks
    • Glossary
  • Media Links
    • Twitter
    • Telegram
Powered by GitBook
On this page
  • 1. Add a custom network to your provider
  • 2. Wait for Confirmation
  • 3. Gas considerations (for Turbo app developers)
  1. Guides

Sending Turbo Transactions

PreviousWriting Turbo Smart ContractsNextContract Addresses

Last updated 10 months ago

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)

  1. Open your browser wallet, go to Networks and Add a Custom Network.

  2. 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 .

  1. 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.

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:

  1. After sending a Turbo transaction, you'll receive a transaction hash from the RPC.

For example:

GET https://eth-sepolia-turbo.api.herodotus.cloud/herodotus-req-id?txHash=0x42a415fb9afe239ca755ffe8bf2c53971391140e3a7b321f247f03e1a6dff139
  1. This query will return a JSON object containing a herdotusApiTransactionIdentifier. For instance:

{
  "herdotusApiTransactionIdentifier": "01HYDSWQTY2GXCZ8SVVNWKC0N3"
}
  1. 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.

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.

Use this hash to make a GET query in the following format:

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://TURBO_RPC_URL/herodotus-req-id?txHash=YOUR_TRANSACTION_HASH
https://dashboard.herodotus.dev/explorer/query/01HYDSWQTY2GXCZ8SVVNWKC0N3
here