taskId
that identifies our request. taskId
can then be used to query Gelato Status API in order to retrieve more information.ForwardRequest
is designed to handle payments of type 1, 2 and 3, in cases where all meta-transaction related logic (or other kinds of replay protection mechanisms such as hash based commitments) is already implemented inside target
smart contract. The sponsor
is still required to EIP-712 sign this request, in order to ensure the integrity of payments. Optionally, nonce
may or may not be enforced, by setting enforceSponsorNonce
. Some dApps may not need to rely on a nonce for ForwardRequest
if they already implement strong forms of replay protection.ForwardRequest
object using the following method:request
to Gelato Relay API. sponsorSignature
is the EIP-712 signature from sponsor
. Upon Promise resolution, we get a unique taskId
that identifies our request. taskId
can then be used to query Gelato Status API in order to retrieve more information.MetaTxRequest
is designed to handle payments of type 1, 2 and 3, in cases where the target
contract does not have any meta-transaction nor replay protection logic. In this case, the appropriate Gelato Relay's smart contract already verifies user
and sponsor
signatures. user
is the EOA address that wants to interact with the dApp, while sponsor
is the account that pays fees.MetaTxRequest
object using the following SDK's method:request
to Gelato Relay API. userSignature
is the EIP-712 signature from dApp's user. If sponsorSignature
is not passed, we assume sponsor
is also the user
, so that we set it equal to sponsorSignature
. Upon Promise resolution, we get a unique taskId
that identifies our request. taskId
can then be used to query Gelato Status API in order to retrieve more information.taskId
in order to query Gelato Status API as follows:getStatus
returns undefined
in case any error has occurred, otherwise it returns an object of type TransactionStatus
defined as follows:maxFee
denotes the maximum fee denominated in feeToken
a sponsor
is willing to pay, and is one of the required parameters in both ForwardRequest
and MetaTxRequest
. sponsorSignature
and smart contract logic, Gelato Executors will be strongly discouraged to over-charge transaction sponsors. Moreover, maxFee
also serves as a buffer to protect against gas price volatility spikes, meaning that transactions will still get mined on time and reliably under said adversarial circumstances. maxFee
. In the future, staked Gelato Executors will have a strong incentive to play by the fair rules described in this paragraph even if there is no way for the smart contract to enforce this rule (for instance, payments of Type 1 which use an Off-chain accounting system), as doing otherwise will result in their fee revenues not being paid by the Gelato DAO, and possibly have some or all of their GEL stake slashed.maxFee
values: