switching-to-send-calls
Switching to Send Calls
With Smart Account wallets on the rise, new standards are being adopted by Dapps and Wallets that take advantage of their capabilities. One of these standards is EIP 5792. In short, it introduces a few methods that smart accounts would support, that enable a couple of cool features including:
- Batched Transactions: This allows to batch multiple transactions into a single one that will be executed.
- Using Paymasters: EIP 5792 has a concept of
capabilities
which determine what a wallet can do and also what a dapp wants a wallet to do. This allows the use of Paymasters, which are defined in ERC 7677.
A note on Smart Accounts and EOAs
Not all users will be using Smart Accounts; Some will be using EOAs (Externally
Owned Accounts). These
wallets do not support EIP 5792 and will be incompatible with sendCalls
.
This means that before using sendCalls
, there needs to be a check on whether
the account is compatible or not. Thankfully, this can be achieved using
getCapabilities
.
An example custom hook that leverages Wagmi's hooks for getCapabilities
can be
found
in our lab.
This hook is then used
also in our lab.
Essentially - the Wallet will inform the Dapp if it supports EIP 5792 or not.
Regardless of whether wagmi
or ethers
is used, once capabilities are
fetched, you can then check:
if (supported) {
sendCalls(...)
}
else {
writeContractAsync(...)
}
Or disable the button entirely like in the example above, depending on the intent. This handling does not need to be replicated for all calls within a Dapp, but instead only for the calls where 5792 needs to leveraged. For example, if there is an existing transaction within a Dapp that should be modified to allow sponsoring gas.
Sending transactions
For Dapps that are using writeContractAsync
, switching to sendCalls
involves a minor change in encoding the call. An example of it in use can be
found
here.
Important to note is that the function call data is pre-encoded
on line 12
within the same file. This is the main difference as writeContractAsync
encodes the calls itself.
Getting Receipts or Call Status
Typically, alongside writeContractAsync
or similar calls, there would be a
waitForTransactionReceipt
used to wait for the transaction. Sending calls via
the EIP 5792 standards by design does not return a transaction hash by design.
Instead, sendCalls
will return an identifier for the transaction which can be
queried via getting the calls' status. In Wagmi's case, this is done using
useCallsStatus
.
An example can be found in our lab.