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
Support all ABI "stateMutability" fields in contract interface definitions
Motivation
The ABI standard currently has 4 possibilities for "State Mutability", a field that is supposed to describe the degree of statefulness/mutability of a contract method. The four options are:
pure (Does not view or modify state, or accept Ether. Called using STATICCALL.)
view (Does not modify state or accept Ether, but can view state. Called using STATICCALL.)
nonpayable (Does not accept Ether, but can modify and/or view state. Called using CALL.)
pure (Requires sending Ether, and can optional modify and/or view state. Called using CALL.)
Currently, when you import a JSON or Vyper interface from a file, these attributes are able to be specified, but they do not perform additional checks (such as requiring @payable or value=... for payable) when using implements or making a call. This VIP would change how interfaces are specified to closely mimic how defining contract ABIs are performed.
Simple Summary
Support all ABI "stateMutability" fields in contract interface definitions
Motivation
The ABI standard currently has 4 possibilities for "State Mutability", a field that is supposed to describe the degree of statefulness/mutability of a contract method. The four options are:
pure
(Does not view or modify state, or accept Ether. Called usingSTATICCALL
.)view
(Does not modify state or accept Ether, but can view state. Called usingSTATICCALL
.)nonpayable
(Does not accept Ether, but can modify and/or view state. Called usingCALL
.)pure
(Requires sending Ether, and can optional modify and/or view state. Called usingCALL
.)Currently, when you import a JSON or Vyper interface from a file, these attributes are able to be specified, but they do not perform additional checks (such as requiring
@payable
orvalue=...
forpayable
) when usingimplements
or making a call. This VIP would change how interfaces are specified to closely mimic how defining contract ABIs are performed.Specification
How this would look is like the following:
The current keywords,
constant
andmodifying
would be changed according to:constant
->view
(orpure
), andmodifying
->nonpayable
(orpayable
)Backwards Compatibility
Backwards incompatibility because of name change, and update to ABI output
Dependencies
Depends on #2040 and #2041 (for consistency)
References
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: