Learn how to use CallwithSyncFee ERC-2771
@gelatonetwork/relay-sdk
v3 or contracts from the package @gelatonetwork/relay-context
v2, please follow this migration guide to migrate to the new versions.callWithSyncFeeERC2771
SDK method, using the syncFee payment methodcallWithSyncFeeERC2771
method uses the syncFee payment method with ERC-2771 support.
callWithSyncFeeERC2771
relay method, the target contract assumes responsibility for transferring the fee to Gelato’s fee collector during transaction execution. For this, the target contract needs to know:
GelatoRelayContextERC2771
contract in your target contract, you have the ability to transfer the fee through one of two straightforward methods: _transferRelayFee()
or _transferRelayFeeCapped(uint256 maxFee)
. In either case, the inherited contract takes care of decoding the fee, feeToken, and feeCollector behind the scenes.
GelatoRelayFeeCollectorERC2771
contract. With this approach, Gelato decodes only the feeCollector. You must provide the fee and feeToken on-chain, either by hardcoding them (which is not recommended) or embedding them within the payload to be executed. The suggested way to handle this is to calculate the fee with Gelato’s Fee Oracle.
This modular design ensures a smooth integration with Gelato’s fee handling mechanisms, providing a flexible and user-friendly approach to managing transaction fees within your dApps.
_transferRelayFeeCapped(uint256 maxFee)
in the GelatoRelayContextERC2771
contract provides a convenient way to set the maxFee easily.
If you are utilizing the GelatoRelayFeeCollectorERC2771
contract, the recommended way to pass the maxFee is by calculating the fee with Gelato’s Fee Oracle, which is accessible in the Relay SDK. The getEstimatedFee()
method is provided to facilitate this calculation.
request
: The body of the request intended for sendingsignerOrProvider
: a valid provider connected to RPC or a signeroptions
: an object for specifying optional parametersapiKey
: an optional API key that links your request to your Gelato Relay account. As this call pertains to the syncFee payment method, transaction costs won’t be deducted from your Gas Tank account. By using the API key, you can benefit from increased rate limits of your Gelato Relay accounttaskId
: a unique task ID which can be used for tracking your requestcallWithSyncFeeERC2771WithSignature
method to send the request to Gelato.
request
: The body of the request intended for sendingsignerOrProvider
: a valid provider connected to RPC or a signertype
: CallWithSyncFee for a sequential flow or ConcurrentCallWithSyncFee for a concurrent flowstruct
: EIP-712 message datasignature
: EIP-712 signaturecallWithSyncFeeERC2771WithSignature
method.
request
: The body of the request intended for sendingtype
: CallWithSyncFee for a sequential flow or ConcurrentCallWithSyncFee for a concurrent flowsignerOrProvider
(optional): A provider needed in a sequential flow to obtain the nonce from the smart contract. If you’re providing the nonce within your request or if you’re using the concurrent flow, this parameter isn’t necessarystruct
: EIP-712 message datatypedData
: EIP-712 typed datastruct
: EIP-712 message data returned from the signing methodssyncFeeParams
: the feetoken and isRelayContext paramssignature
: EIP-712 signature returned after signing the requestoptions
: an object for specifying optional parametersapiKey
: an optional API key that links your request to your Gelato Relay account. As this call pertains to the syncFee payment method, transaction costs won’t be deducted from your Gas Tank account. By using the API key, you can benefit from increased rate limits of your Gelato Relay accounttaskId
: a unique task ID which can be used for tracking your requestgasLimit
: the gas limit of the relay call. This effectively sets an upper price limit for the relay call.
If you are using your own custom gas limit, please add a 150k gas buffer on top of the expected gas usage for the transaction. This is for the Gelato Relay execution overhead, and adding this buffer reduces your chance of the task cancelling before it is executed on-chain.
If your contract has any hardcoded requirements about gas usage, please always explicitly pass the gasLimit to the SDK/API, as Gelato will not know what hardcoded gas expectations your contract has. Otherwise, your relay requests might not be executable.
retries
: the number of retries that Gelato should attempt before discarding this relay call. This can be useful if the state of the target contract is not fully known and such reverts can not be definitively avoided.
callWithSyncFeeERC2771
requests:
callWithSyncFeeERC2771
requests are using the sequential method.
:::note
Concurrent ERC2771 support has been introduced in the relay-sdk version 5.1.0. Please make sure that your package is up-to-date to start using it.
:::
chainId
: the chain ID of the chain where the target smart contract is deployed
target
: the address of the target smart contract
data
: encoded payload data (usually a function selector plus the required arguments) used to call the required target address
user
: the address of the user’s EOA
userDeadline
: optional, the amount of time in seconds that a user is willing for the relay call to be active in the relay backend before it is dismissed
This way the user knows that if the transaction is not sent within a certain timeframe, it will expire. Without this, an adversary could pick up the transaction in the mempool and send it later. This could transfer money, or change state at a point in time which would be highly undesirable to the user.
feeToken
: the address of the token that is to be used for payment. Please visit SyncFee Payment Tokens for the full list of supported payment tokens per network
isRelayContext
: an optional boolean (default: true) denoting what data you would prefer appended to the end of the calldata
If set to true (default), Gelato Relay will append the feeCollector address, the feeToken address, and the uint256 fee to the calldata. In this case your target contract should inherit from the GelatoRelayContextERC2771
contract.
If set to false, Gelato Relay will only append the feeCollector address to the calldata. In this case your target contract should inherit from the GelatoRelayFeeCollectorERC2771
contract.
isConcurrent
: false (default), optional, represents that the users’ requests are validated based on a nonce, which enforces them to be processed sequentiallyuserNonce
: optional, this nonce, akin to Ethereum nonces, is stored in a local mapping on the relay contracts. It serves to enforce the nonce ordering of relay calls if the user requires sequential processing. If this parameter is omitted, the relay-sdk will automatically query the current value on-chainisConcurrent
: true, indicates that the users’ requests are validated based on a unique salt, allowing them to be processed concurrently. Replay protection is still ensured by permitting each salt value to be used only onceuserSalt
: optional, this is a bytes32 hash that is used for replay protection. If the salt is not provided then relay-sdk would generate a unique value based on a random seed and a timestampcallWithSyncFeeERC2771
on Sepolia, the trustedForwarder associated is 0xb539068872230f20456CF38EC52EF2f91AF4AE49
. We will initialize GelatoRelay with the following config: