fix: balance transfer & deployed txn #14
Conversation
| // Note: you may need to static call getSenderAddress() not call() as per | ||
| // the spec. Leaving as-is for now. | ||
| // let call = call_builder.call_raw().await; |
There was a problem hiding this comment.
are you saying this is not correct and shouldn't work?
There was a problem hiding this comment.
Yeah the entry point says to do a staticcall when calling getSenderAddress. Here it's currently doing a regular call I think.
Not sure exactly the difference but it seems to work as-is for now for simple account so I'm leaving it as-is. But something to be aware of if there are issues in the future
| // TODO test/fix: if invalid call data (e.g. sending balance that you don't | ||
| // have), the account will still be deployed but the transfer won't happen. | ||
| // Why can't we detect this? |
There was a problem hiding this comment.
We should know the balance of the smart account. If the smart account has not been deployed then the balance would be 0, if it has been deployed we can get the balance of the contract before sending the user operation I believe.
There was a problem hiding this comment.
Yeah we can get the balance, my point was that the UserOperation went through even though the transaction was invalid. Not what I was expecting. I would've expected the whole thing to revert
Adds test coverage for transferring native token balance from the smart account to another account. It does this transfer twice, the first time as part of the account deployment, and the second against the deployed account.
This fixes some issues in the process:
undefinedfactoryandfactoryDatawhen working against a deployed accountCREATE2implementation asgetSenderAddress()only works when the account isn't yet deployed