Open z0r0z opened 1 month ago
Might impact the gas savings a little - but you could imagine the Solady libraries having functions like:
function isFunctionXPayable() internal view virtual;
and then in your implementation you do:
// default non-payable implementation
function isFunctionXPayable() internal override {
if (msg.value > 0) revert NotPayable();
}
// Or you want a payable function and do this:
function isFunctionXPayable() internal override {}
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.