Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VIP: automatic detection of payable functions #4331

Open
AlbertoCentonze opened this issue Oct 25, 2024 · 1 comment
Open

VIP: automatic detection of payable functions #4331

AlbertoCentonze opened this issue Oct 25, 2024 · 1 comment
Labels
needs triage needs triage

Comments

@AlbertoCentonze
Copy link
Contributor

AlbertoCentonze commented Oct 25, 2024

Simple Summary

This VIP proposes to completely remove the @payable and @nonpayable decorators from the language syntax.

Motivation

  • We live in a world where native currency transfers are less and less used compared to ERC20s.
  • People ended up saving gas by using the @payable decorator just to remove the runtime check that a @nonpayable modifier implies.
  • The compiler is smart enough to know when a function is payable.
  • This change reduces the cognitive overhead of using native currency transfers for developers.

Specification

  • @payable and @nonpayable should be disallowed in the syntax.
  • When a function accesses msg.value the abi of the function should be payable, otherwise it's always non-payable.
  • The runtime check to make sure that a function is non-payable is turned into a no-op.

Backwards Compatibility

This is a breaking change that requires changes in existing codebases. This VIP can be implemented without waiting for a major release by turning the @nonpayable modifier into a no-op, which is already the case for @payable and showing a deprecation warning.

Copyright

Copyright and related rights waived via CC0

@AlbertoCentonze AlbertoCentonze added the needs triage needs triage label Oct 25, 2024
@pcaversaccio
Copy link
Collaborator

I personally don't think it's a general blocker, but I want to highlight that in the EIP-721 standard we have the following specifications:

function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;

In probably 99% of the implementations, these functions do not access msg.value but would require to be payable at the ABI level. The current proposal would lead to an inconsistent ABI for EIP-721 token implementations. We could add maybe a kwarg to the function parameters, is_payable = True to enforce it:

@external
def safeTransferFrom(owner: address, to: address, token_id: uint256, data: Bytes[1_024] = b"", is_payable = True):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage needs triage
Projects
None yet
Development

No branches or pull requests

3 participants
@AlbertoCentonze @pcaversaccio and others