Gas abstraction

How to best handle transactions sponsoring

Gas abstraction is crucial to provide users a seamless interaction with your application. Ideally, end-users should not have to care about paying gas or having gas tokens in their wallet.

Abstracting account deployment

By default, Ready will automatically deploy and pay for the deployment of accounts generated through the Invisible SDK.

However, you should have a fallback in case the Ready service is down and unable to pay for accounts deployment.

Calling the requestConnection method will return ConnectResponse

approvalTransactionHash?: string
approvalRequestsCalls?: Call[]
deploymentPayload?: any

• If deploymentPayload is undefined, that means that the wallet account is deployed

• If not, you'll need to deploy it using deployAndExecuteWithPaymaster

• As a second fallback, you can notify the user in the UI that the account needs to be funded

Abstracting ERC-20 approvals

The Invisible SDK lets you bundle ERC-20 approvals together with the approval of a session. These particular approvals are also sponsored by Ready. In some cases, you might need users to sign additional ERC-20 approvals later in their journey (not part of the session approval). These ERC-20 approvals are not sponsored by Ready.

Again, make sure to have a fallback in case our relayer service is unavailable.

Abstracting other types of transactions

We recommend that you totally abstract gas for users and hence sponsor all other types of transactions (onchain recordings, swaps, transfers etc...) using the AVNU paymaster.

You can also airdrop/sell your own token to users and let them pay gas fees with it.