Infura transactions (ITX)

Search…
Infura Transactions (ITX) is currently undergoing changes and is only supported for existing customers.
ITX is supported on Ethereum networks (Mainnet and testnets) and Polygon Mainnet. The Polygon Mumbai testnet is not supported.
Infura Transactions (ITX) is a simplified way to send Ethereum transactions. ITX handles all edge cases for transaction delivery and takes care of getting transactions mined while removing the need for developers to deal with the complexities around gas management.
There are three high-level steps you need to take when integrating ITX in your project:
1.On-chain deposit. You generate a private key and deposit some ETH with Infura’s on-chain deposit contract. This action credits your ITX gas tank with the corresponding amount of ETH (after 10 block confirmations). Make sure to credit the ITX gas tank with the native network token used by the gas fees (for example, MATIC tokens for Polygon). You will use your private key any time you authorize spending from your ITX gas tank (i.e. when relaying a transaction).
2.Send a relay request. You send a transaction relay request to your usual Infura endpoint using the relay_sendTransaction RPC call. ITX will first check if you have sufficient balance, then lock a portion of your funds and relay the transaction on your behalf to the Ethereum network.
3.Transaction mined & balance deducted. ITX will periodically increase the gas price and republish your transaction according to a predefined escalation schedule, in an attempt to minimize both confirmation time and final gas price paid. As soon as the transaction is mined and becomes part of the blockchain, the cost of the transaction which includes the network fee (gas price * gas used) + the ITX fee, will be subtracted from your gas tank balance. You can check your new balance using the relay_getBalance RPC call.
Authentication
ITX is fully compatible with all authentication mechanisms used by our Ethereum client interface. 
Gas price escalation schedules
ITX uses a dynamic gas price escalation algorithm that works in your advantage by minimizing the gas price you'll be paying to the network while still attempting to meet a predefined confirmation time window for your transactions.
ITX will initially broadcast your transaction with a lower gas price, then gradually increase the gas price according to a schedule and republish your transaction each time the gas price is increased. You can choose an escalation schedule for your transaction when sending a relay request. Currently two schedules are supported:
fast targets getting your transaction mined in ~6 blocks (1:30 min)
slow targets getting your transaction mined in ~200 blocks (1 hour)
These values should not be interpreted as delivery time guarantees, but you can rely on them as target values for the median confirmation time of each escalation schedule.
Relay fee structure
When relaying a transaction, ITX will first check if you have sufficient gas tank balance, then lock a portion of your funds and relay the transaction on your behalf to the Ethereum network. As soon as the transaction is mined and becomes part of the blockchain, the total Infura transaction cost will be subtracted from your gas tank balance.
Total Infura transaction cost = Network transaction fee + ITX commission
Network transaction fee = gas used * gas price
ITX commission = gas used * a flat gwei amount
Network
ITX commission
Mainnet
5% of the gas price, capped at 10 gwei
Ropsten
gas used * 1 gwei
Rinkeby
gas used * 1 gwei
Kovan
gas used * 1 gwei
Goerli
gas used * 1 gwei
Polygon Mainnet
gas used * 20 gwei
You can check your ITX gas tank balance at any time to monitor your spending.
Limitations
The from address of the final transaction will always be set to an internal ITX wallet address (chosen by the ITX system), whereas the final to and data fields are chosen by you and defined in the original relay request (as parameters in your relay_sendTransaction call).
While this approach makes it possible for ITX wallets to pay the gas for executing the transaction, you need to pay close attention to the use of msg.sender in the contracts you're interacting with. For every managed transaction, the contracts will see the method call as originating from one of the ITX wallets. The best practice for working around this challenge is to encode a meta transaction in the data field of your initial request.
​
Features - Previous
Project sharing
Develop with ITX
Last modified 1mo ago
Copy link
On this page
Authentication
Gas price escalation schedules
Relay fee structure
Limitations