feat: simulateUserOp execution

[VGabriel45]

Summary

Added a method "simulateUserOp()" to simulate user operation execution.

Usecase:

• a dapp could use this to warn a user that his user operation will fail before sending it.
• can also be used for testing

Change Type

• [ ] Bug Fix
• [ ] Refactor
• [x] New Feature
• [ ] Breaking Change
• [ ] Documentation Update
• [ ] Performance Improvement
• [ ] Other

Checklist

• [x] My code follows this project's style guidelines
• [x] I've reviewed my own code
• [x] I've added comments for any hard-to-understand areas
• [ ] I've updated the documentation if necessary
• [x] My changes generate no new warnings
• [x] I've added tests that prove my fix is effective or my feature works
• [ ] All unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published

---

PR-Codex overview

This PR adds new functions Hex and BaseError, updates simulateUserOp method, and introduces tests for user operation simulation in BiconomySmartAccountV2.

Detailed summary

• Added Hex and BaseError imports
• Updated simulateUserOp method in BiconomySmartAccountV2
• Added tests for user operation simulation in BiconomySmartAccountV2

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[github-actions[bot]]

size-limit report 📦

Path	Size
core (esm)	52.2 KB (+0.36% 🔺)
core (cjs)	56.7 KB (+0.36% 🔺)
account (tree-shaking)	51.16 KB (+0.43% 🔺)
bundler (tree-shaking)	2.33 KB (0%)
paymaster (tree-shaking)	2.25 KB (-0.22% 🔽)
modules (tree-shaking)	40.05 KB (0%)

[livingrockrises]

this method is meant to catch execution errors? userop.calldata is wrong as per business logic and validation errors as well?

can we write more test cases based off this

[VGabriel45]

this method is meant to catch execution errors? userop.calldata is wrong as per business logic and validation errors as well?

can we write more test cases based off this

entryPoint.simulate.simulateHandleOp will always throw so this is what I'm catching in the try/catch statement

[livingrockrises]

this method is meant to catch execution errors? userop.calldata is wrong as per business logic and validation errors as well? can we write more test cases based off this

entryPoint.simulate.simulateHandleOp will always throw so this is what I'm catching in the try/catch statement

agree, my question was does return info about failed execution or something else too (like AAxx validation problems)

[VGabriel45]

this method is meant to catch execution errors? userop.calldata is wrong as per business logic and validation errors as well?

can we write more test cases based off this

As per the smart contract method code simulateHandleOp is supposed to simulate both validation and execution of the userOp. In the SDK, as long as the isSuccessful end result value is not true, it means that the userOperation has failed either on validation or execution, the end goal of this utility method is to simulate if an user op would be successfull or not.

[livingrockrises]

this method is meant to catch execution errors? userop.calldata is wrong as per business logic and validation errors as well? can we write more test cases based off this

As per the smart contract method code simulateHandleOp is supposed to simulate both validation and execution of the userOp. In the SDK, as long as the isSuccessful end result value is not true, it means that the userOperation has failed either on validation or execution, the end goal of this utility method is to simulate if an user op would be successfull or not.

ok. maybe you can have tests for both execution failure: paymaster is used to pay gas, but userop.calldata is transferring eth value/erc20 that is not there in the account. (which is somewhat already covered I think) validation failure: paymaster is used but paymaster doesn't have any deposit on entrypoint (would fail here with AA31)

my advice is to also check again with Yash @arcticfloyd1984 on this whole method usage how it's utilised on bundler and can be utilised

[joepegler]

Looks useful. Could we use this in a 'dev' mode somehow?

[VGabriel45]

Does this show information from aa-errors?

The simulateHandleOp method is supposed to always fail, in the error message there will be a result true/false if the userOp would be executed or not. Not sure if we can use the aa-errors package for this, lmk if you have any idea.

[VGabriel45]

Looks useful. Could we use this in a 'dev' mode somehow?

Yea, could be used to simulate user ops, we already have the simulationType flag for that, but with that flow the user op will be sent if the simulation is successful, with this PR, we can simulate without sending it right after, it's more useful to client dapps to tell the user ahead what will happen.

[VGabriel45]

eth_estimateUserOperation

This method is supposed to simulate the user operation validation + execution, without sending the user operation after the simulation is done, also, it is calling the entrypoint contract directly without a call to the API. We had someone asking for a way to simulate user ops through the SDK without sending them right after (what is happening in our sendUserOp and sendTransaction when passing simulationType flag as "validation" or "validation_and_execution")

[arcticfloyd1984]

eth_estimateUserOperation

This method is supposed to simulate the user operation validation + execution, without sending the user operation after the simulation is done, also, it is calling the entrypoint contract directly without a call to the API. We had someone asking for a way to simulate user ops through the SDK without sending them right after (what is happening in our sendUserOp and sendTransaction when passing simulationType flag as "validation" or "validation_and_execution")

Two things:

• You can still expose a method to call eth_esitmateUserOperationGas without sending it on chain, but I get it will be slower.
• You can use the gas estimation package methods internally to do this. It is a much better way to estimate, especially the execution step. simulateHandleOp does not tell you if your callData execution passed or not. The gas estimation SDK is written in a way to capture that using state overrides. The only limitation is it will fully work with the networks supporting state overrides in their eth_call, for the rest of the networks I have exposed the exact same simulateHandleOp method already which gets used in the main estimateUserOperationGas by passing a flag. It is already used in production by the bundler and paymaster for months now so it is very well tested.