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
The Solidity payable modifier essentially puts function calls into their default state without extra security checks for rejecting msg.value. Saving a small amount of gas.
This Solady issue is raised to explore the preference of making most Solady functions payable by default and encouraging end-users to inherit and override with a check (require(msg.value == 0) to enforce Solidity's high-level security behavior.
The potential benefits here go beyond gas savings. Users will also have the choice to integrate payable behaviors into their Solady contracts. For example, a protocol might enforce an ether tax on transferring tokens. Currently this is not something they can do.
The obvious drawback is that there is an immediate footgun in that shoddy UIs and Solady developers who do not add custom security checks might expose users to unexpected function call payments.
So let's explore further.
The text was updated successfully, but these errors were encountered:
Might impact the gas savings a little - but you could imagine the Solady libraries having functions like:
function isFunctionXPayable() internalviewvirtual;
and then in your implementation you do:
// default non-payable implementationfunction isFunctionXPayable() internaloverride {
if (msg.value>0) revertNotPayable();
}
// Or you want a payable function and do this:function isFunctionXPayable() internaloverride {}
The Solidity
payable
modifier essentially puts function calls into their default state without extra security checks for rejectingmsg.value
. Saving a small amount of gas.This Solady issue is raised to explore the preference of making most Solady functions payable by default and encouraging end-users to inherit and override with a check (
require(msg.value == 0
) to enforce Solidity's high-level security behavior.The potential benefits here go beyond gas savings. Users will also have the choice to integrate payable behaviors into their Solady contracts. For example, a protocol might enforce an ether tax on transferring tokens. Currently this is not something they can do.
The obvious drawback is that there is an immediate footgun in that shoddy UIs and Solady developers who do not add custom security checks might expose users to unexpected function call payments.
So let's explore further.
The text was updated successfully, but these errors were encountered: