Biconomy SDK
Search…
⌃K

Gasless Transactions

Possessing chain native tokens is critical to users who wish to interact with a dApp on any chain. For example, anyone who wants to send an Ethereum transaction needs to have Ether to pay for its gas fees. This forces new users to purchase these crypto tokens before they can start using a dApp. This is a major hurdle in user onboarding which can be mitigated by enabling gas sponsorship within your dApp.
In the Biconomy SDK, gasless transactions happen in a non-custodial manner via Account Abstraction. In this mechanism, there is a Paymaster contract which acts like a 'gas-tank'. All you need to do is deposit funds into the Paymaster & whitelist your dApp contracts to enable gas abstraction within your dApp.
If you wish to skip the explanation of how gasless transactions work via BiconomySDK, you can directly navigate to:

Flow Explained

In this case, dApp is sponsoring the transaction gas fee using gasless transaction using the concept of paymasters as mentioned in EIP-4337 (Account Abstraction).
EIP-4337 proposal introduces a higher-layer pseudo-transaction object called a UserOperation. Users send UserOperation objects into a separate mempool. A special class of actor called bundlers (either miners, or users that can send transactions to miners through a bundle marketplace) package up a set of these objects into a transaction making a handleOps call to a special contract, and that transaction then gets included in a block.
  • UserOperation - a structure that describes a transaction to be sent on behalf of a user.
    • Like a transaction, it contains “sender”, “to”, “calldata”, “maxFeePerGas”, “maxPriorityFee”, “signature”, “nonce”
    • unlike transaction, it contains several other fields
    • also, the “nonce” and “signature” fields usage is not defined by the protocol, but by each account implementation
  • Sender - the account contract sending a user operation.
  • EntryPoint - a singleton contract to execute bundles of UserOperations.
Users send UserOperation objects to a dedicated class of actors called bundlers (in this case, Biconomy's relayers act as bundlers). These bundlers pick UserOperation and create bundle transactions. A bundle transaction packages up multiple UserOperation objects into a single handleOps call to a pre-published global entry point contract.
Paymasters are specialised contracts that can be used to sponsor gas fees for other users. For enabling gasless you can use the pre-deployed BiconomyVerifyingPaymaster. It is already staked so you will only have to deposit the required amount for gas sponsorship. This amount can be withdrawn at any point by you.
Here how the transaction flow looks like:
  • The user initiates a transaction and provides his signature via Biconomy SDK.
  • The signature is sent to a Relayer(Bundler), which then sends the transaction on-chain via an Entry Point contract which does signature verification and uses paymaster to recover the gas fee from dApp’s deposit (Paymaster is essentially dApp’s on-chain Gas Tank)
The paymaster scheme allows a contract to passively pay on users’ behalf under arbitrary conditions. You can specify these conditions - calls to certain or all methods of a contract can be whitelisted on the dashboard.
You can start by Registering your dApp on the Dashboard. Here you will also be able to fund the gas tank & whitelist contracts. Then you can Enable Gasless Transactions via BiconomySDK.
If you wish to enable gasless transactions within your dApp for only EOAs & in a custodial way, please check out our guide to Enable Gasless via Meta-Transactions.