Account Abstraction FAQ

How can I get push notifications for mined userOperations?

Follow the guide on using custom webhooks to get real time alerts and receipts for mined userOperations.

What is a dummy signature and why do I need it for certain endpoints?

Our APIs are compatible with any type of smart account. This means regardless of the smart account you're using, our endpoints will work with it. However, different smart accounts have unique ways of signing transactions, known as signature patterns. A dummy signature is essentially a template or example signature that aligns with the signature pattern of your specific account type.

For certain API endpoints, particularly those involved in gas estimation, a dummy signature is required in the request. This is because these endpoints need to simulate or estimate the transaction without actually executing it, and the dummy signature helps in this process. For more information, consult the docs for your specific account implementation. The following endpoints require a dummy signature for gas estimation:

• eth_estimateUserOperationGas
• alchemy_simulateUserOperationAssetChanges
• alchemy_requestGasAndPaymasterAndData

If your account type is either LightAccount or SimpleAccount, you can use the provided dummy signature:

0xfffffffffffffffffffffffffffffff0000000000000000000000000000000007aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1c

How do I upgrade from Simple Account to Light Account?

Simple Account's support upgradeToAndCall implemented by openzeppelin’s UUPSUpgradeable contract. This allows you to upgrade from Simple Account to LightAccount without changing the smart contract account address. Using upgradeToAndCallwill update the underlying implementation contract on the account while the account address and assets will stay the same.

You can call [[upgradeToAndCall](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/ae1bafcb48fe220257d76bfd93a237db3ebaf3df/contracts/proxy/utils/UUPSUpgradeable.sol#L86)] on the Simple Account with these params:

• newImplementation: Latest LightAccount implementation address (found here - make sure to use the implementation address, not the factory address)
  • For example LightAccount v1.1.0 - 0xae8c656ad28F2B59a196AB61815C16A0AE1c3cba
• data: encoded version of the initialize function with anOwner parameter set to the owner/signer on the account, usually the same owner as what the account used as Simple Account.
  • In solidity/foundry you can use abi.encodeCall and in viem you can use [encodeFunctionData](https://github.com/alchemyplatform/light-account/blob/main/Deployments.md#lightaccount)

⚠️ It is very important that the initialize step is encoded correctly to ensure the account does not get in to a risky state where someone else could call initialize on it and reassign and a signer. You can call owner() on the account after upgrade to make sure it is assigned correctly.

This can be called on the existing smart contract account by sending a user operation that calls execute (or executeBatch) and have that call upgradeToAndCall (the same way you would make the account send calls to other addresses).