Notable changes

New function isValidSignatureUnsafe

This view function was introduced in SmartAccount.sol contract to validate an EIP-1271 signature by calling the function of the same name, isValidSignatureUnsafe, in a trusted module. In a successful validation, the return value will be EIP1271_MAGIC_VALUE, while a failed validation will return bytes4(0xffffffff). This is in accordance with the standard EIP-1271.

In turn, this new isValidSignatureUnsafe function was implemented in EcdsaOwnershipRegistryModule and PasskeyRegistryModule modules' contracts. This function, unlike the implementation of the isValidSignature, does not add a prefix "\x19Ethereum Signed Message:\n52" to the hash of the data to be validated by _verifySignature to check that this data was signed by the signature of the expected signer. Also, the new isValidSignatureForAddressUnsafe function was introduced in EcdsaOwnershipRegistryModule, which allows to verify signatures like the isValidSignatureUnsafe but for any smart account address. The modules BatchedSessionRouterModule and SessionKeyManager do not support the isValidSignatureUnsafe function and will revert when called with any arguments.

Minor differences

BaseSmartAccount.sol

1. The internal function _validateNonce has been removed.

2. An argument uint192 key has been added to the nonce function. This argument is passed to entryPoint().getNonce(address(this), key);. Previously, a constant 0 was passed instead of key.

SmartAccount.sol

1. The contract no longer inherits from the IERC165 interface.

2. The functions executeCall and executeBatchCall have been renamed to execute and executeBatch, respectively.

3. The function validationModule has been optimized for gas efficiency using assembly code. Additionally, the call to the internal _validateNonce has been removed.

4. Functions executeCall_s1m and executeBatchCall_4by have been renamed to execute_ncC and executeBatch_y6U.

ModuleManager.sol

1. The execTransactionFromModule and execBatchTransactionFromModule functions have become payable.

2. A new argument txGas has been added to the execTransactionFromModuleReturnData function. The previous version of this function without txGas now calls execTransactionFromModuleReturnData with a zero txGas amount.

3. The contract uses a linked list of allowed modules. The first module is always the auth module, which is necessary for validating user operations and to not brick the contract. All other modules are linked to it. The _disableModule() function prevents the removal of the first auth module.

4. The execBatchTransactionFromModule function, instead of calling the execute function from the Executor.sol library, calls the internal _executeFromModule. This function, in turn, calls _execute from Executor.sol and emits events in case of successful and unsuccessful execution.

SmartAccountFactory.sol

1. The contract is inherited from the Stakeable.sol contract.

2. The Proxy contract has been renamed to BiconomyMSAProxy. The contract itself remains unchanged.

3. In the deployAccount function, the check if (initializer.length > 0) has been deleted.

EcdsaOwnershipRegistryModule.sol

1. The internal _verifySignature function has been updated to check if the signature was made over dataHash.toEthSignedMessageHash().

2. The new internal _transferOwnership function has been added.

3. The new view function getOwner has been added, which returns the owner address for smartAccount.

4. New renounceOwnership function has been added, which set zero owner address for msg.sender.

BatchedSessionRouterModule.sol

1. Added uint256 private constant MODULE_SIGNATURE_OFFSET = 96;.

2. Instead of using a two-step process for decoding data from the signature, the validateUserOp function directly decodes data from userOp.signature[MODULE_SIGNATURE_OFFSET:].

3. The validateUserOp function was updated by verification that the sessionKeyManager module is an enabled module.

4. The function isValidSignatureUnsafe is not supported.

SessionKeyManagerModule.sol

1. The function isValidSignatureUnsafe is not supported.

2. Instead of using a two-step process for decoding data from the signature, the validateUserOp function directly decodes data from userOp.signature[MODULE_SIGNATURE_OFFSET:].

PasskeyRegistryModule.sol

1. A new view function named getOwner has been added, which returns smartAccountPasskey[smartAccount].

2. The _verifySignature function has been updated to get the new address smartAccount argument. Previously, this function used the msg.sender address.

3. In the isValidSignature function, the msg.sender is now passed to the isValidSignatureForAddress function, which in turn calls the updated _verifySignature.