Bundler SDK
Learn more about the Bundler SDK for Account Abstraction on Boba Network
Last updated
Learn more about the Bundler SDK for Account Abstraction on Boba Network
Last updated
This section documents the usage of the Bundler SDK, that is a major component of Account Abstraction.
An UserOperation in simple terms is a pseudo-transaction object that expresses an user's intent.
This package provides 2 APIs for using UserOperations:
Low-level "walletAPI"
High-level Provider
Make sure you understand both of them, to use the one that is suited best for your use case.
An abstract base-class to create UserOperations for a contract wallet.
An implementation of the BaseAccountAPI
, for the SimpleAccount sample of account-abstraction.
constructor()
Usage
Note that SimpleAccountAPI either needs the accountAddress
or the factoryAddress
to be supplied. If the factoryAddress
is supplied, also supply a entryPointWrapperAddress
. To address the lack of support for 'Custom reverts' in v2 of the network, the sdk would route the call through the entryPointWrapperAddress in order to compute the account address that will be deployed.
If accountAddress
is passed, the account is used as a sender when generating the userOp If factoryAddress
is passed, the account will be generated on the fly. The userOp will include initCode and the precomputed address of the account and include it in the userOp.
The low-level approach above can be used as follows:
or with a SimpleAccountFactory-
PaymasterAPI
Add paymasterAndData
to UserOp.
Exemplary paymasterAndData
value:
After adding the PaymasterAPI you can sign your user operation as usual.
PaymasterAPI:getPaymasterAndData(Partial<UserOperationStruct>)
Returns paymasterAndData
of given UserOp. Returns 0x
if empty.
getAccountInitCode()
Return the value to put into the "initCode" field, if the contract is not yet deployed. This value holds the "factory" address, followed by this account's information.
getNonce()
Return current account's nonce.
encodeExecute()
Encode the call from entryPoint through our account to the target contract.
signUserOpHash()
Sign a userOp's hash (userOpHash).
checkAccountPhantom()
Check if the contract is already deployed.
getCounterFactualAddress()
Calculate the account address even before it is deployed.
getInitCode()
Return initCode value to add into the UserOp. (either deployment code, or empty hex if contract already deployed)
getVerificationGasLimit()
Return maximum gas used for verification. NOTE: createUnsignedUserOp will add to this value the cost of creation, if the contract is not yet created.
getPreVerificationGas()
Should cover cost of putting calldata on-chain, and some overhead. Actual overhead depends on the expected bundle size.
getUserOpHash()
Return userOpHash for signing. This value matches entryPoint.getUserOpHash (calculated off-chain, to avoid a view call)
getAccountAddress()
Return the account's address. This value is valid even before deploying the contract.
createUnsignedUserOp()
Create a UserOperation, filling all details (except signature)
if account is not yet created, add initCode to deploy it.
if gas or nonce are missing, read them from the chain (note that we can't fill gaslimit before the account is created)
signUserOp()
Sign the filled userOp.
createSignedUserOp()
Helper method: create and sign a user operation.
getUserOpReceipt()
Get the transaction that has this userOpHash mined, or null if not found.
A simplified mode that doesn't require a different wallet extension. Instead, the current provider's account is used as wallet owner by calling its "Sign Message" operation.
This can only work for wallets that use an EIP-191 ("Ethereum Signed Message") signatures (like our sample SimpleWallet) Also, the UX is not great (the user is asked to sign a hash, and even the wallet address is not mentioned, only the signer)
Wrap an existing provider to tunnel requests through Account Abstraction.
Since- a) using a remote signer with eth_sendTransaction is not supported on Boba, transactions would need to be sent from an ethers.wallet (object), for the deterministic deployment of SimpleAccountFactory. This is not a requirement if the SimpleAccountFactory has already been deployed b) wrapProvider uses the low level API internally, custom reverts were not supported in the v2 of the network and the sdk relies on the entryPointWrapperAddress to compute the account address that will be deployed
wrapProvider must be passed the parameters entryPointWrapperAddress
and wallet
on Boba
The high-level provider api can be used as follows: