msg.senderwhich is the immediate caller of the smart contract. More often than not, an Ethereum transaction is the direct caller of the smart contract and the
msg.senderis computed as the
fromaddress of the transaction.
fromaddress of the final transaction is not under your direct control. To solve this problem, the community have worked on the concept of a meta-transaction which requires the user to send a signed message to a smart contract before an action is executed.
dataparameters it receives from you, so it will relay your transactions regardless of the meta transaction flow you decide to use.
ecrecoverthat verifies the user's signed message. If the user only needs to interact with your smart contract, then it is a simple solution. However, if the user needs to interact with ERC20 tokens that are not meta-transaction compatible, then you may run into limitations still.
msg.senderof the target contract is the wallet contract address. There are also other benefits to wallet contracts such as batching two or more transactions together. However it does require a setup phase as the user must transfer assets to their wallet contract. You can pick any wallet contract implementation to work with ITX.
eth_sendRawTransaction, the relay request returns a
relayTransactionHashinstead of a single Ethereum transaction hash.
receivedTimereturns the timestamp when ITX has received your relay request.
broadcastsreturns an array of Ethereum transaction objects. Multiple Ethereum transactions can be returned because ITX uses a gas price escalation schedule to gradually increases the fee until your transaction is mined. Every time the gas price is changed, a new Ethereum transaction (with a different Ethereum transaction hash) is broadcast to the network and added to the broadcast list.