Powered by account abstraction, Biconomy Smart Accounts work seamlessly with any Paymaster & Bundler.
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
Base64 :
Provides a set of functions to operate with Base64 strings. _Available since v4.5._
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
ECDSA :
Elliptic Curve Digital Signature Algorithm (ECDSA) operations. These functions can be used to verify that a message was signed by the holder of the private keys of a given address.
MerkleProof :
These functions deal with verification of Merkle Tree proofs. The tree and the proofs can be generated using our https://github.com/OpenZeppelin/merkle-tree[JavaScript library]. You will find a quickstart guide in the readme. WARNING: You should avoid using leaf values that are 64 bytes long prior to hashing, or use a hash function other than keccak256 for hashing leaves. This is because the concatenation of a sorted pair of internal nodes in the merkle tree could be reinterpreted as a leaf value. OpenZeppelin's JavaScript library generates merkle trees that are safe against this attack out of the box.
Math :
Standard math utilities missing in the Solidity language.
SignedMath :
Standard signed math utilities missing in the Solidity language.
Strings :
String operations.
FallbackManager :
Fallback calls are handled by a `handler` contract that is stored at FALLBACK_HANDLER_STORAGE_SLOT fallback calls are not delegated to the `handler` so they can not directly change Smart Account storage
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
SmartAccountNoAuth :
This contract is the base for the Smart Account functionality. - It provides the functionality to execute both gnosis-style txns and AA (EIP-4337) userOps - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with smodules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
constructor :
Constructor that sets the owner of the contract and the entry point contract. _modules[SENTINEL_MODULES] = SENTINEL_MODULES protects implementation from initialization
disableModule(address,address) :
Removes a module from the allowlist.
domainSeparator() :
Returns the domain separator for this contract, as defined in the EIP-712 standard.
enableModule(address) :
Adds a module to the allowlist.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Allows a Module to execute a wallet transaction without any further confirmations and returns data
execute(address,uint256,bytes) :
Interface function with the standard name for execute_ncC
executeBatch(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatch_y6U
executeBatch_y6U(address[],uint256[],bytes[]) :
Execute a sequence of transactions
execute_ncC(address,uint256,bytes) :
Execute a transaction (called directly from owner, or by entryPoint)
getDeposit() :
Check current account deposit in the entryPoint
getImplementation() :
Returns the address of the implementation contract associated with this contract.
getModulesPaginated(address,uint256) :
Returns array of modules. Useful for a widget
getNonce(uint256) :
returns a value from the nonces 2d mapping
init(address,address,bytes) :
Initialize the Smart Account with required states
isModuleEnabled(address) :
Returns if a module is enabled
isValidSignature(bytes32,bytes) :
If owner is a smart-contract (other smart contract wallet or module, that controls signature verifications - like multisig), forward isValidSignature request to it. In case of multisig, _signature can be several concatenated signatures If owner is EOA, perform a regular ecrecover.
nonce(uint192) :
This method returns the next sequential nonce.
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
setupAndEnableModule(address,bytes) :
Setups module for this Smart Account and enables it.
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
SmartAccountFactory :
It deploys Smart Accounts as proxies pointing to `basicImplementation` that is immutable. This allows keeping the same address for the same Smart Account owner on various chains via CREATE2
accountCreationCode() :
Allows to retrieve the creation code used for the Proxy deployment.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
IERC721TokenReceiver :
Note: the ERC-165 identifier for this interface is 0x150b7a02.
onERC721Received(address,address,uint256,bytes) :
The ERC721 smart contract calls this function on the recipient after a `transfer`. This function MAY throw to revert and reject the transfer. Return of other than the magic value MUST result in the transaction being reverted. Note: the contract address is always the message sender.
Math :
Standard math utilities missing in the Solidity language.
Strings :
String operations.
EcdsaOwnershipRegistryModule :
Compatible with Biconomy Modular Interface v 0.1 - It allows to validate user operations signed by EOA private key. - EIP-1271 compatible (ensures Smart Account can validate signed messages). - One owner per Smart Account. - Does not support outdated eth_sign flow for cheaper validations (see https://support.metamask.io/hc/en-us/articles/14764161421467-What-is-eth-sign-and-why-is-it-a-risk-) !!!!!!! Only EOA owners supported, no Smart Account Owners For Smart Contract Owners check SmartContractOwnership module instead
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
Biconomy’s Multichain Validator module enables use cases which require several actions to be authorized for several chains with just one signature required from user. - Leverages Merkle Trees to efficiently manage large datasets - Inherits from the ECDSA Ownership Registry Module - Compatible with Biconomy Modular Interface v 0.1 - Does not introduce any additional security trade-offs compared to the vanilla ERC-4337 flow.
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
Validates User Operation. leaf = validUntil + validAfter + userOpHash If the leaf is the part of the Tree with a root provided, userOp considered to be authorized by user
PasskeyRegistryModule :
Compatible with Biconomy Modular Interface v 0.2 - It allows to validate user operations signed by passkeys. - One owner per Smart Account. For Smart Contract Owners check SmartContractOwnership module instead
initForSmartAccount(uint256,uint256,string) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
Validates userOps for ERC20 transfers and approvals using a session key signature. - Recommended to use with standard ERC20 tokens only - Can be used with any method of any contract which implement method(address, uint256) interface
validates if the _op (UserOperation) matches the SessionKey permissions and that _op has been signed by this SessionKey Please mind the decimals of your exact token when setting maxAmount
SmartContractOwnershipRegistryModule :
Compatible with Biconomy Modular Interface v 0.1 - It allows to validate user operations signed by other smart contracts via EIP-1271. - EIP-1271 compatible (ensures Smart Account can validate signed messages). - One owner per Smart Account.No EOA owners supported For EOA Owners check EcdsaOwnership module instead
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account.no need to check for address(0) as it is not a Smart Contract Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
The paymaster trusts an external signer to sign the transaction. The calling user must pass the UserOp to that external signer first, which performs whatever off-chain verification before signing the UserOp.
deposit() :
Override the default implementation.
depositFor(address) :
Deposit funds for a given paymasterId to cover transaction fees.
getBalance(address) :
get the current deposit for paymasterId (Dapp Depositor address)
Called by off-chain service for signing, and on-chain in validatePaymasterUserOp for validation.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
setSigner(address) :
Set a new verifying signer address. Can only be called by the owner of the contract.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
withdrawTo(address,uint256) :
Withdraws specified gas tokens from paymaster's balance to a given address.
Proxy :
Implementation address is stored in the slot defined by the Proxy's address
SmartAccount :
This contract is the base for the Smart Account functionality. - It is modular by nature. UserOp and txns validation happens in Authorization Modules. - It provides the functionality to execute AA (EIP-4337) userOps. Gnosis style txns removed to a module. - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with modules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
constructor :
Constructor that sets the entry point contract. _modules[SENTINEL_MODULES] = SENTINEL_MODULES protects implementation from initialization
disableModule(address,address) :
Removes a module from the allowlist.
enableModule(address) :
Adds a module to the allowlist.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Allows a Module to execute a wallet transaction without any further confirmations and returns data
execute(address,uint256,bytes) :
Interface function with the standard name for execute_ncC
executeBatch(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatch_y6U
executeBatch_y6U(address[],uint256[],bytes[]) :
Execute a sequence of transactions
execute_ncC(address,uint256,bytes) :
Execute a transaction (called by entryPoint)
getDeposit() :
Check current account deposit in the entryPoint
getImplementation() :
Returns the address of the implementation contract associated with this contract.
getModulesPaginated(address,uint256) :
Returns array of modules. Useful for a widget
init(address,address,bytes) :
Initialize the Smart Account with required states
isModuleEnabled(address) :
Returns if a module is enabled
isValidSignature(bytes32,bytes) :
Forwards the validation to the module specified in the signature
nonce(uint192) :
This method returns the next sequential nonce.
setFallbackHandler(address) :
Sets the fallback handler.
setupAndEnableModule(address,bytes) :
Setups module for this Smart Account and enables it.
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
FallbackManagerV1 :
Fallback calls are handled by a `handler` contract that is stored at FALLBACK_HANDLER_STORAGE_SLOT fallback calls are not delegated to the `handler` so they can not directly change Smart Account storage
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
Proxy :
Implementation address is stored in the slot defined by the Proxy's address
SmartAccountFactoryV1 :
It deploys Smart Accounts as proxies pointing to `basicImplementation` that is immutable. This allows keeping the same address for the same Smart Account owner on various chains via CREATE2
accountCreationCode() :
Allows to retrieve the creation code used for the Proxy deployment.
SmartAccountV1 :
This contract is the base for the Smart Account functionality. - It provides the functionality to execute both gnosis-style txns and AA (EIP-4337) userOps - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with modules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
checkSignatures(bytes32,bytes) :
Checks whether the signature provided is valid for the provided data, hash. Will revert otherwise.
constructor :
Constructor that sets the owner of the contract and the entry point contract.
disableModule(address,address) :
Removes a module from the allowlist.
domainSeparator() :
Returns the domain separator for this contract, as defined in the EIP-712 standard.
Returns the bytes that are hashed to be signed by owner.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Gnosis style transaction with optional repay in native tokens OR ERC20Allows to execute a transaction confirmed by required signature/s and then pays the account that submitted the transaction.Function name optimized to have hash started with zeros to make this function calls cheaper
executeBatchCall(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatchCall_4by
If owner is a smart-contract (other smart contract wallet or module, that controls signature verifications - like multisig), forward isValidSignature request to it. In case of multisig, _signature can be several concatenated signatures If owner is EOA, perform a regular ecrecover.
nonce() :
This method returns the next sequential nonce.
pullTokens(address,address,uint256) :
Utility method to be able to transfer ERC20 tokens out of Smart Account
requiredTxGas(address,uint256,bytes,uint8) :
Allows to estimate a transaction. This method is only meant for estimation purpose, therefore the call will always revert and encode the result in the revert data. Since the `estimateGas` function includes refunds, call this method to get an estimated of the costs that are deducted from the wallet with `execTransaction`
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
setOwner(address) :
Allows to change the owner of the smart account by current owner or self-call (modules)
transfer(address,uint256) :
Utility method to be able to transfer native tokens out of Smart Account
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
VulnerableERC20SessionValidationModule :
Validates userOps for ERC20 transfers and approvals using a session key signature. - Recommended to use with standard ERC20 tokens only - Can be used with any method of any contract which implement method(address, uint256) interface
Biconomy Smart Account: Leading Implementation of Account Abstraction 🌐
Biconomy Smart Account is a smart contract wallet focused on implementing Account Abstraction. It builds on the core concepts of Gnosis and Argent safes and is compliant with ERC-4337 and ERC-6900.
📜 Smart Contracts
BaseSmartAccount.sol: An abstract contract implementing the EIP4337 IWallet interface.
Proxy.sol: A lightweight proxy upgradeable through the UUPS pattern.
SmartAccountFactory.sol: This factory contract manages the deployment of Smart Account (Account Abstraction).
SmartAccount.sol: The primary implementation contract for a Smart Account (Account Abstraction).
EntryPoint.sol: Implements the EIP4337 Entry Point contract.
StakeManager.sol: A stake manager for wallet and paymaster deposits/stakes.
Executor.sol: A helper contract facilitating calls and delegate calls to dapp contracts.
FallbackManager.sol: Manages a fallback handler for delegate calls.
ModuleManager.sol: Adopts the Gnosis Safe module manager pattern.
DefaultCallbackHandler.sol: Handles hooks to respond to token receipts.
MultiSend.sol & MultiSendCallOnly.sol: Facilitates batching multiple transactions into one.
VerifyingSingletonPaymaster.sol: A paymaster that uses an external service for transaction validation.
PaymasterHelpers.sol: A library essential for decoding paymaster data and context.
🛠️ Prerequisites
Node.js
Yarn or npm
Hardhat
🚀 How to Run the Project
Before diving in, place a mnemonic in a .secret file at the root.
Remember: Never commit this file or share it publicly.
Setup
Setup: Clone the repository and install dependencies.
git clone https://github.com/bcnmy/scw-contracts.git
cd scw-contracts
npm install
Configuration: Create a .secret file at the root to store your mnemonic.
Note: Never commit this file.
shell echo "your mnemonic here" > .secret
🛠️ Development Commands
Below are the commands you can use for various tasks:
🧪 Testing
Run regular tests:
npx hardhat test
For Bundler Integration Tests, first install realpath:
brew install coreutils
Then, run the Bundler Integration Tests:
yarn bundler-test
📦 Compilation & Deployment
Compile contracts:
npx hardhat compile
Clean the environment:
npx hardhat clean
Start a local Ethereum node:
npx hardhat node
Deploy contracts:
npx hardhat run scripts/deploy.ts
TS_NODE_FILES=true npx ts-node scripts/deploy.ts
📈 Analysis & Reporting
Display available accounts:
npx hardhat accounts
Get help on Hardhat commands:
npx hardhat help
Test with gas report:
REPORT_GAS=true npx hardhat test
Generate code coverage report:
npx hardhat coverage
🧹 Code Quality & Formatting
Lint JavaScript and TypeScript files:
npx eslint '**/*.{js,ts}'
Automatically fix linting issues:
npx eslint '**/*.{js,ts}' --fix
Check formatting for JSON, Solidity, and Markdown files:
npx prettier '**/*.{json,sol,md}' --check
Automatically format files:
npx prettier '**/*.{json,sol,md}' --write
Lint Solidity contracts:
npx solhint 'contracts/**/*.sol'
Automatically fix issues in Solidity contracts:
npx solhint 'contracts/**/*.sol' --fix
This format separates the description from the command, making it clearer and more readable.
🔍 Etherscan Verification
To verify on Etherscan, deploy a contract to an Ethereum network supported by Etherscan, like Ropsten. Set up your .env file, deploy your contract, and then verify:
Boost your tests and scripts' speed by setting the TS_NODE_TRANSPILE_ONLY environment variable to 1 in Hardhat's environment. More details are available in the documentation.
🤝 Contributing
Biconomy Smart Account is an open-source project. Contributions are welcome. If you're interested in contributing, please check our contribution guidelines and feel free to submit pull requests or raise issues.
📜 License
This project is licensed under the MIT License. See the LICENSE.md file for details.
Powered by account abstraction, Biconomy Smart Accounts work seamlessly with any Paymaster & Bundler.
Ownable :
Contract module which provides a basic access control mechanism, where there is an account (an owner) that can be granted exclusive access to specific functions. By default, the owner account will be the one that deploys the contract. This can later be changed with {transferOwnership}. This module is used through inheritance. It will make available the modifier `onlyOwner`, which can be applied to your functions to restrict their use to the owner.
constructor :
Initializes the contract setting the deployer as the initial owner.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
ERC20 :
Implementation of the {IERC20} interface. This implementation is agnostic to the way tokens are created. This means that a supply mechanism has to be added in a derived contract using {_mint}. For a generic mechanism see {ERC20PresetMinterPauser}. TIP: For a detailed writeup see our guide https://forum.openzeppelin.com/t/how-to-implement-erc20-supply-mechanisms/226[How to implement supply mechanisms]. The default value of {decimals} is 18. To change this, you should override this function so it returns a different value. We have followed general OpenZeppelin Contracts guidelines: functions revert instead returning `false` on failure. This behavior is nonetheless conventional and does not conflict with the expectations of ERC20 applications. Additionally, an {Approval} event is emitted on calls to {transferFrom}. This allows applications to reconstruct the allowance for all accounts just by listening to said events. Other implementations of the EIP may not emit these events, as it isn't required by the specification. Finally, the non-standard {decreaseAllowance} and {increaseAllowance} functions have been added to mitigate the well-known issues around setting allowances. See {IERC20-approve}.
allowance(address,address) :
See {IERC20-allowance}.
approve(address,uint256) :
See {IERC20-approve}. NOTE: If `amount` is the maximum `uint256`, the allowance is not updated on `transferFrom`. This is semantically equivalent to an infinite approval. Requirements: - `spender` cannot be the zero address.
balanceOf(address) :
See {IERC20-balanceOf}.
constructor :
Sets the values for {name} and {symbol}. All two of these values are immutable: they can only be set once during construction.
decimals() :
Returns the number of decimals used to get its user representation. For example, if `decimals` equals `2`, a balance of `505` tokens should be displayed to a user as `5.05` (`505 / 10 ** 2`). Tokens usually opt for a value of 18, imitating the relationship between Ether and Wei. This is the default value returned by this function, unless it's overridden. NOTE: This information is only used for _display_ purposes: it in no way affects any of the arithmetic of the contract, including {IERC20-balanceOf} and {IERC20-transfer}.
decreaseAllowance(address,uint256) :
Atomically decreases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address. - `spender` must have allowance for the caller of at least `subtractedValue`.
increaseAllowance(address,uint256) :
Atomically increases the allowance granted to `spender` by the caller. This is an alternative to {approve} that can be used as a mitigation for problems described in {IERC20-approve}. Emits an {Approval} event indicating the updated allowance. Requirements: - `spender` cannot be the zero address.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token, usually a shorter version of the name.
totalSupply() :
See {IERC20-totalSupply}.
transfer(address,uint256) :
See {IERC20-transfer}. Requirements: - `to` cannot be the zero address. - the caller must have a balance of at least `amount`.
transferFrom(address,address,uint256) :
See {IERC20-transferFrom}. Emits an {Approval} event indicating the updated allowance. This is not required by the EIP. See the note at the beginning of {ERC20}. NOTE: Does not update the allowance if the current allowance is the maximum `uint256`. Requirements: - `from` and `to` cannot be the zero address. - `from` must have a balance of at least `amount`. - the caller must have allowance for ``from``'s tokens of at least `amount`.
IERC20Metadata :
Interface for the optional metadata functions from the ERC20 standard. _Available since v4.1._
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
decimals() :
Returns the decimals places of the token.
name() :
Returns the name of the token.
symbol() :
Returns the symbol of the token.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
IERC20 :
Interface of the ERC20 standard as defined in the EIP.
Approval(address,address,uint256) :
Emitted when the allowance of a `spender` for an `owner` is set by a call to {approve}. `value` is the new allowance.
Transfer(address,address,uint256) :
Emitted when `value` tokens are moved from one account (`from`) to another (`to`). Note that `value` may be zero.
allowance(address,address) :
Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through {transferFrom}. This is zero by default. This value changes when {approve} or {transferFrom} are called.
approve(address,uint256) :
Sets `amount` as the allowance of `spender` over the caller's tokens. Returns a boolean value indicating whether the operation succeeded. IMPORTANT: Beware that changing an allowance with this method brings the risk that someone may use both the old and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards: https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729 Emits an {Approval} event.
balanceOf(address) :
Returns the amount of tokens owned by `account`.
totalSupply() :
Returns the amount of tokens in existence.
transfer(address,uint256) :
Moves `amount` tokens from the caller's account to `to`. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
transferFrom(address,address,uint256) :
Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance. Returns a boolean value indicating whether the operation succeeded. Emits a {Transfer} event.
Base64 :
Provides a set of functions to operate with Base64 strings. _Available since v4.5._
Context :
Provides information about the current execution context, including the sender of the transaction and its data. While these are generally available via msg.sender and msg.data, they should not be accessed in such a direct manner, since when dealing with meta-transactions the account sending and paying for execution may not be the actual sender (as far as an application is concerned). This contract is only required for intermediate, library-like contracts.
ECDSA :
Elliptic Curve Digital Signature Algorithm (ECDSA) operations. These functions can be used to verify that a message was signed by the holder of the private keys of a given address.
MerkleProof :
These functions deal with verification of Merkle Tree proofs. The tree and the proofs can be generated using our https://github.com/OpenZeppelin/merkle-tree[JavaScript library]. You will find a quickstart guide in the readme. WARNING: You should avoid using leaf values that are 64 bytes long prior to hashing, or use a hash function other than keccak256 for hashing leaves. This is because the concatenation of a sorted pair of internal nodes in the merkle tree could be reinterpreted as a leaf value. OpenZeppelin's JavaScript library generates merkle trees that are safe against this attack out of the box.
Math :
Standard math utilities missing in the Solidity language.
SignedMath :
Standard signed math utilities missing in the Solidity language.
Strings :
String operations.
FallbackManager :
Fallback calls are handled by a `handler` contract that is stored at FALLBACK_HANDLER_STORAGE_SLOT fallback calls are not delegated to the `handler` so they can not directly change Smart Account storage
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
ReentrancyGuard :
Contract module that helps prevent reentrant calls to a function. Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier available, which can be applied to functions to make sure there are no nested (reentrant) calls to them. Note that because there is a single `nonReentrant` guard, functions marked as `nonReentrant` may not call one another. This can be worked around by making those functions `private`, and then adding `external` `nonReentrant` entry points to them. TIP: If you would like to learn more about reentrancy and alternative ways to protect against it, check out our blog post https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].
SmartAccountNoAuth :
This contract is the base for the Smart Account functionality. - It provides the functionality to execute both gnosis-style txns and AA (EIP-4337) userOps - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with smodules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
constructor :
Constructor that sets the owner of the contract and the entry point contract. _modules[SENTINEL_MODULES] = SENTINEL_MODULES protects implementation from initialization
disableModule(address,address) :
Removes a module from the allowlist.
domainSeparator() :
Returns the domain separator for this contract, as defined in the EIP-712 standard.
enableModule(address) :
Adds a module to the allowlist.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Allows a Module to execute a wallet transaction without any further confirmations and returns data
execute(address,uint256,bytes) :
Interface function with the standard name for execute_ncC
executeBatch(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatch_y6U
executeBatch_y6U(address[],uint256[],bytes[]) :
Execute a sequence of transactions
execute_ncC(address,uint256,bytes) :
Execute a transaction (called directly from owner, or by entryPoint)
getDeposit() :
Check current account deposit in the entryPoint
getImplementation() :
Returns the address of the implementation contract associated with this contract.
getModulesPaginated(address,uint256) :
Returns array of modules. Useful for a widget
getNonce(uint256) :
returns a value from the nonces 2d mapping
init(address,address,bytes) :
Initialize the Smart Account with required states
isModuleEnabled(address) :
Returns if a module is enabled
isValidSignature(bytes32,bytes) :
If owner is a smart-contract (other smart contract wallet or module, that controls signature verifications - like multisig), forward isValidSignature request to it. In case of multisig, _signature can be several concatenated signatures If owner is EOA, perform a regular ecrecover.
nonce(uint192) :
This method returns the next sequential nonce.
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
setupAndEnableModule(address,bytes) :
Setups module for this Smart Account and enables it.
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
SmartAccountFactory :
It deploys Smart Accounts as proxies pointing to `basicImplementation` that is immutable. This allows keeping the same address for the same Smart Account owner on various chains via CREATE2
accountCreationCode() :
Allows to retrieve the creation code used for the Proxy deployment.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
IERC165 :
Interface of the ERC165 standard, as defined in the https://eips.ethereum.org/EIPS/eip-165[EIP]. Implementers can declare support of contract interfaces, which can then be queried by others ({ERC165Checker}). For an implementation, see {ERC165}.
supportsInterface(bytes4) :
Returns true if this contract implements the interface defined by `interfaceId`. See the corresponding https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section] to learn more about how these ids are created. This function call must use less than 30 000 gas.
IERC721TokenReceiver :
Note: the ERC-165 identifier for this interface is 0x150b7a02.
onERC721Received(address,address,uint256,bytes) :
The ERC721 smart contract calls this function on the recipient after a `transfer`. This function MAY throw to revert and reject the transfer. Return of other than the magic value MUST result in the transaction being reverted. Note: the contract address is always the message sender.
Math :
Standard math utilities missing in the Solidity language.
Strings :
String operations.
EcdsaOwnershipRegistryModule :
Compatible with Biconomy Modular Interface v 0.1 - It allows to validate user operations signed by EOA private key. - EIP-1271 compatible (ensures Smart Account can validate signed messages). - One owner per Smart Account. - Does not support outdated eth_sign flow for cheaper validations (see https://support.metamask.io/hc/en-us/articles/14764161421467-What-is-eth-sign-and-why-is-it-a-risk-) !!!!!!! Only EOA owners supported, no Smart Account Owners For Smart Contract Owners check SmartContractOwnership module instead
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
Biconomy’s Multichain Validator module enables use cases which require several actions to be authorized for several chains with just one signature required from user. - Leverages Merkle Trees to efficiently manage large datasets - Inherits from the ECDSA Ownership Registry Module - Compatible with Biconomy Modular Interface v 0.1 - Does not introduce any additional security trade-offs compared to the vanilla ERC-4337 flow.
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
Validates User Operation. leaf = validUntil + validAfter + userOpHash If the leaf is the part of the Tree with a root provided, userOp considered to be authorized by user
PasskeyRegistryModule :
Compatible with Biconomy Modular Interface v 0.2 - It allows to validate user operations signed by passkeys. - One owner per Smart Account. For Smart Contract Owners check SmartContractOwnership module instead
initForSmartAccount(uint256,uint256,string) :
Initializes the module for a Smart Account. Should be used at a time of first enabling the module for a Smart Account.
Validates userOps for ERC20 transfers and approvals using a session key signature. - Recommended to use with standard ERC20 tokens only - Can be used with any method of any contract which implement method(address, uint256) interface
validates if the _op (UserOperation) matches the SessionKey permissions and that _op has been signed by this SessionKey Please mind the decimals of your exact token when setting maxAmount
SmartContractOwnershipRegistryModule :
Compatible with Biconomy Modular Interface v 0.1 - It allows to validate user operations signed by other smart contracts via EIP-1271. - EIP-1271 compatible (ensures Smart Account can validate signed messages). - One owner per Smart Account.No EOA owners supported For EOA Owners check EcdsaOwnership module instead
getOwner(address) :
Returns the owner of the Smart Account. Reverts for Smart Accounts without owners.
initForSmartAccount(address) :
Initializes the module for a Smart Account.no need to check for address(0) as it is not a Smart Contract Should be used at a time of first enabling the module for a Smart Account.
isValidSignature(bytes32,bytes) :
Validates a signature for a message. To be called from a Smart Account.
The paymaster trusts an external signer to sign the transaction. The calling user must pass the UserOp to that external signer first, which performs whatever off-chain verification before signing the UserOp.
deposit() :
Override the default implementation.
depositFor(address) :
Deposit funds for a given paymasterId to cover transaction fees.
getBalance(address) :
get the current deposit for paymasterId (Dapp Depositor address)
Called by off-chain service for signing, and on-chain in validatePaymasterUserOp for validation.
owner() :
Returns the address of the current owner.
renounceOwnership() :
Leaves the contract without owner. It will not be possible to call `onlyOwner` functions. Can only be called by the current owner. NOTE: Renouncing ownership will leave the contract without an owner, thereby disabling any functionality that is only available to the owner.
setSigner(address) :
Set a new verifying signer address. Can only be called by the owner of the contract.
transferOwnership(address) :
Transfers ownership of the contract to a new account (`newOwner`). Can only be called by the current owner.
withdrawTo(address,uint256) :
Withdraws specified gas tokens from paymaster's balance to a given address.
Proxy :
Implementation address is stored in the slot defined by the Proxy's address
SmartAccount :
This contract is the base for the Smart Account functionality. - It is modular by nature. UserOp and txns validation happens in Authorization Modules. - It provides the functionality to execute AA (EIP-4337) userOps. Gnosis style txns removed to a module. - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with modules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
constructor :
Constructor that sets the entry point contract. _modules[SENTINEL_MODULES] = SENTINEL_MODULES protects implementation from initialization
disableModule(address,address) :
Removes a module from the allowlist.
enableModule(address) :
Adds a module to the allowlist.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Allows a Module to execute a wallet transaction without any further confirmations and returns data
execute(address,uint256,bytes) :
Interface function with the standard name for execute_ncC
executeBatch(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatch_y6U
executeBatch_y6U(address[],uint256[],bytes[]) :
Execute a sequence of transactions
execute_ncC(address,uint256,bytes) :
Execute a transaction (called by entryPoint)
getDeposit() :
Check current account deposit in the entryPoint
getImplementation() :
Returns the address of the implementation contract associated with this contract.
getModulesPaginated(address,uint256) :
Returns array of modules. Useful for a widget
init(address,address,bytes) :
Initialize the Smart Account with required states
isModuleEnabled(address) :
Returns if a module is enabled
isValidSignature(bytes32,bytes) :
Forwards the validation to the module specified in the signature
nonce(uint192) :
This method returns the next sequential nonce.
setFallbackHandler(address) :
Sets the fallback handler.
setupAndEnableModule(address,bytes) :
Setups module for this Smart Account and enables it.
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
FallbackManagerV1 :
Fallback calls are handled by a `handler` contract that is stored at FALLBACK_HANDLER_STORAGE_SLOT fallback calls are not delegated to the `handler` so they can not directly change Smart Account storage
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
Proxy :
Implementation address is stored in the slot defined by the Proxy's address
SmartAccountFactoryV1 :
It deploys Smart Accounts as proxies pointing to `basicImplementation` that is immutable. This allows keeping the same address for the same Smart Account owner on various chains via CREATE2
accountCreationCode() :
Allows to retrieve the creation code used for the Proxy deployment.
SmartAccountV1 :
This contract is the base for the Smart Account functionality. - It provides the functionality to execute both gnosis-style txns and AA (EIP-4337) userOps - It allows to receive and manage assets. - It is responsible for managing the modules and fallbacks. - The Smart Account can be extended with modules, such as Social Recovery, Session Key and others.
addDeposit() :
Deposit more funds for this account in the entryPoint
checkSignatures(bytes32,bytes) :
Checks whether the signature provided is valid for the provided data, hash. Will revert otherwise.
constructor :
Constructor that sets the owner of the contract and the entry point contract.
disableModule(address,address) :
Removes a module from the allowlist.
domainSeparator() :
Returns the domain separator for this contract, as defined in the EIP-712 standard.
Returns the bytes that are hashed to be signed by owner.
entryPoint() :
Returns the current entry point used by this account.This function should be implemented by the subclass to return the current entry point used by this account.
Gnosis style transaction with optional repay in native tokens OR ERC20Allows to execute a transaction confirmed by required signature/s and then pays the account that submitted the transaction.Function name optimized to have hash started with zeros to make this function calls cheaper
executeBatchCall(address[],uint256[],bytes[]) :
Interface function with the standard name for executeBatchCall_4by
If owner is a smart-contract (other smart contract wallet or module, that controls signature verifications - like multisig), forward isValidSignature request to it. In case of multisig, _signature can be several concatenated signatures If owner is EOA, perform a regular ecrecover.
nonce() :
This method returns the next sequential nonce.
pullTokens(address,address,uint256) :
Utility method to be able to transfer ERC20 tokens out of Smart Account
requiredTxGas(address,uint256,bytes,uint8) :
Allows to estimate a transaction. This method is only meant for estimation purpose, therefore the call will always revert and encode the result in the revert data. Since the `estimateGas` function includes refunds, call this method to get an estimated of the costs that are deducted from the wallet with `execTransaction`
setFallbackHandler(address) :
Allows to add a contract to handle fallback calls. Only fallback calls without value and with data will be forwarded
setOwner(address) :
Allows to change the owner of the smart account by current owner or self-call (modules)
transfer(address,uint256) :
Utility method to be able to transfer native tokens out of Smart Account
withdrawDepositTo(address,uint256) :
Withdraw value from the account's deposit
VulnerableERC20SessionValidationModule :
Validates userOps for ERC20 transfers and approvals using a session key signature. - Recommended to use with standard ERC20 tokens only - Can be used with any method of any contract which implement method(address, uint256) interface
Biconomy Smart Accounts
