You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it has been discussed during UX meetings. It would be more consistent (simpler, in UX terms) to leave the native cryptocurrency balance in the SmartWallet instead of transferring it to the ownerEOA after each execution.
That involves removing the following piece of code:
//If any balance has been added then trasfer it to the owner EOA uint256 balanceToTransfer = address(this).balance; if ( balanceToTransfer > 0) { //can't fail: req.from signed (off-chain) the request, so it must be an EOA... payable(req.from).transfer(balanceToTransfer); }
And also modify the directExecute function so that it uses the SmartWallet's balance (if value needs to be sent to the destination contract) instead of expecting a sufficient msg.value in the transaction
It is the same logic, but the actual numeric value to send is received as a parameter, and it is expected to be available in the SmartWallet's balance. (The current implementation uses msg.value)
The directExecute can remain payable anyway.
The text was updated successfully, but these errors were encountered:
As it has been discussed during UX meetings. It would be more consistent (simpler, in UX terms) to leave the native cryptocurrency balance in the SmartWallet instead of transferring it to the ownerEOA after each execution.
That involves removing the following piece of code:
//If any balance has been added then trasfer it to the owner EOA
uint256 balanceToTransfer = address(this).balance;
if ( balanceToTransfer > 0) {
//can't fail: req.from signed (off-chain) the request, so it must be an EOA...
payable(req.from).transfer(balanceToTransfer);
}
And also modify the
directExecute
function so that it uses the SmartWallet's balance (if value needs to be sent to the destination contract) instead of expecting a sufficientmsg.value
in the transactionFor example:
function directExecute(address to, uint256 value, bytes calldata data) external override payable returns (
bool success, bytes memory ret)
{
_verifyOwner();
(success, ret) = to.call{value: value}(data);
}
It is the same logic, but the actual numeric value to send is received as a parameter, and it is expected to be available in the SmartWallet's balance. (The current implementation uses
msg.value
)The
directExecute
can remainpayable
anyway.The text was updated successfully, but these errors were encountered: