ITX meta-transactions

In many (if not most) situations, you will need to authenticate your actions with a smart contract. This is necessary if you wish to transfer an ERC-20 token or to vote in a DAO. Most smart contracts authenticate the caller using msg.sender which 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.sender is computed as the from address of the transaction.
This is problematic for third party relayers like ITX as the default Ethereum authentication mechanism (i.e., the built-in transaction signature) is now used by ITX to pay the transaction gas and the from address 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.
Meta transaction compatibility with ITX
You can use ITX as a building block to implement any meta transaction flow. Your choice of on-chain authentication architecture will determine the to and data fields in your ITX transaction, but it will not impact how you interact with ITX.
At this point ITX is fully agnostic of the to and data parameters it receives from you, so it will relay your transactions regardless of the meta transaction flow you decide to use.
Emerging meta transaction flows can be broken into two solutions:
Modify target contract. The smart contract verifies a signed message from the user before executing the command.
Wallet contracts. The user has a wallet contract that has possession of their assets. All user actions are sent via the wallet contract.
There are several solutions for modifying the target contract such as EIP-2612's permit(), EIP-3009's transferWithAuthorisation() or EIP-2771's Forwarder contract..
Generally speaking, the standards focus on how to replace msg.sender with an ecrecover that 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.
The wallet contract approach verifies the user's signature before executing their desired action. It is compatible with most smart contracts as the immediate caller of a target contract is the wallet contract and not the Ethereum transaction. Thus, the msg.sender of 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.
We hope Infura Transactions will help you build more powerful and accessible products. However, it is alpha software and we would appreciate any thoughts about it (good or bad).
relay_sendTransaction
Example request
# You can also use wget
curl -X POST https://rinkeby.infura.io/v3/{apiKey}#relay_sendTransaction \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json'
POST /{apiKey}#relay_sendTransaction
Sends a transaction relay request. Unlike eth_sendRawTransaction, the relay request returns a relayTransactionHash instead of a single Ethereum transaction hash.
Parameters
Name
In
Type
Required
Description
apiKey
path
string
true
none
body
body
relay_sendTransactionBody
false
none
Body parameter
{
  "id": "0",
  "jsonrpc": "2.0",
  "method": "relay_sendTransaction",
  "params": [
    {
      "to": "0x0000000000000000000000000000000000000000",
      "data": "0x123456",
      "gas": "100000",
      "schedule": "fast"
    },
    "<relay txn signature here>"
  ]
}
Responses
Status
Meaning
Description
Schema
200
​OK​
Success
Inline
429
​Too Many Requests​
Rate Limit Exceeded
RateLimitedResponse
Example 200 response
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "relayTransactionHash": "0xff6c3dcf0d4ccc58ab1b0caf2a69812508749cf82eb9b09391cdf7cfbb7cf81e"
  }
}
relay_getTransactionStatus
Example request
# You can also use wget
curl -X POST https://rinkeby.infura.io/v3/{apiKey}#relay_getTransactionStatus \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json'
POST /{apiKey}#relay_getTransactionStatus
Retrieves the status of a relayed transaction.
receivedTime returns the timestamp when ITX has received your relay request.
broadcasts returns 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.
Parameters
Name
In
Type
Required
Description
apiKey
path
string
true
none
body
body
relay_getTransactionStatusBody
false
none
Body parameter
{
  "id": "0",
  "jsonrpc": "2.0",
  "method": "relay_getTransactionStatus",
  "params": [
    "0xff6c3dcf0d4ccc58ab1b0caf2a69812508749cf82eb9b09391cdf7cfbb7cf81e"
  ]
}
Responses
Status
Meaning
Description
Schema
200
​OK​
Success
Inline
429
​Too Many Requests​
Rate Limit Exceeded
RateLimitedResponse
Example 200 response
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "receivedTime": "2021-04-20T10:42:00.000Z",
    "broadcasts": [
      {
        "ethTxHash": "0x45e57078ee06b671959f123be68f862e18ada7d555382321778bb19bec9deaf0",
        "broadcastTime": "2021-04-20T10:42:02.000Z",
        "gasPrice": "7290000007",
        "confirmations": 0
      }
    ]
  }
}
relay_getBalance
Example request
# You can also use wget
curl -X POST https://rinkeby.infura.io/v3/{apiKey}#relay_getBalance \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json'
POST /{apiKey}#relay_getBalance
Retrieves the ITX balance (gas tank) of a signing address that has previously deposited ether with the ITX contract.
Parameters
Name
In
Type
Required
Description
apiKey
path
string
true
none
body
body
relay_getBalanceBody
false
none
Body parameter
{
  "id": "0",
  "jsonrpc": "2.0",
  "method": "relay_getBalance",
  "params": [
    "0xc783df8a850f42e7F7e57013759C285caa701eB6"
  ]
}
Responses
Status
Meaning
Description
Schema
200
​OK​
Success
Inline
429
​Too Many Requests​
Rate Limit Exceeded
RateLimitedResponse
Example 200 response
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "balance": "89154701859431608"
  }
}

Name	In	Type	Required	Description
apiKey	path	string	true	none
body	body	relay_sendTransactionBody	false	none

Status	Meaning	Description	Schema
200	OK	Success	Inline
429	Too Many Requests	Rate Limit Exceeded	RateLimitedResponse

Name	In	Type	Required	Description
apiKey	path	string	true	none
body	body	relay_getTransactionStatusBody	false	none

Status	Meaning	Description	Schema
200	OK	Success	Inline
429	Too Many Requests	Rate Limit Exceeded	RateLimitedResponse

Name	In	Type	Required	Description
apiKey	path	string	true	none
body	body	relay_getBalanceBody	false	none

Status	Meaning	Description	Schema
200	OK	Success	Inline
429	Too Many Requests	Rate Limit Exceeded	RateLimitedResponse

Last modified 9mo ago

ITX meta-transactions

`relay_sendTransaction`

Example request

Parameters

Body parameter

Responses

Example 200 response

`relay_getTransactionStatus`

Example request

Parameters

Body parameter

Responses

Example 200 response

`relay_getBalance`

Example request

Parameters

Body parameter

Responses

Example 200 response