sponsoredCallERC2771
Sponsored transactions with ERC2771 authentication support
Last updated
Sponsored transactions with ERC2771 authentication support
Last updated
If you are using @gelatonetwork/relay-sdk
v3 or contracts from the package @gelatonetwork/relay-context
v2 please follow this to migrate to the new versions.
After reading this page:
You'll know how to use the sponsoredCallERC2771
SDK method. This will give your user's a gasless UX requiring a user signature. This uses the payment method, allowing you to sponsor some/all of your user's gas costs.
You'll learn about how to into your contract for _msgSender()
support.
You'll see some code which will help you send a relay request within minutes.
Please proceed to our page and read it thoroughly before advancing with your implementation. It is crucial to understand all potential security risks and measures to mitigate them.
sponsoredCallERC2771
method utilizes authentication both via sponsor API key and a user's signature (e.g. from MetaMask) to sponsor your user's gasless transaction securely. The payment method is .
provider
: a valid provider connected to RPC.
sponsorApiKey
: an API key used to authenticate your sponsorship.
options?
: RelayRequestOptions
is an optional request object
As of today, we support two distinct ways of sending sponsoredCallERC2771
requests:
Sequentially: This approach ensures that each request is ordered and validated against the nonce
stored on-chain. You have two options in this method:
Fetch the current nonce
value from the smart contract yourself and include it with your request.
Allow the relay-sdk to fetch the nonce
value for you when handling your relay request.
Concurrently: This method enables you to send multiple transactions simultaneously. Replay protection is achieved using a hash-based salt
mechanism. Again, you have two options:
Provide your own salt
value.
Allow the relay-sdk to generate a unique salt
value for you when processing your relay request.
By default sponsoredCallERC2771
requests are using the sequential method.
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.
isConcurrent
: false (default), optional, represents that the users' requests are validated based on a nonce, which enforces them to be processed sequentially.
userNonce
: 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-chain.
isConcurrent
: 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 once.
userSalt
: 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 timestamp.
request
: this is the used to send a request.
taskId
: your unique relay task ID which can be used for .
See .
For your testing, Gelato has deployed a simple contract which implements logic to increment a counter with support.
CounterERC2771.sol
: deployed at address 0x00172f67db60E5fA346e599cdE675f0ca213b47b
on .
CounterERC2771.sol
's counter is special because it implements 's _msgSender
authentication to allow for secure whitelisting based on the identity of the original off-chain relay request originator, which has been verified using a user signature.
Furthermore, to set your trusted forwarder, you need the address for GelatoRelay1BalanceERC2771.sol
that you can find .
This is an example using Gelato's CounterERC2771.sol
which is deployed on .