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: safe erc20 transfer builtin #2753

Closed
Tracked by #2758
charles-cooper opened this issue Apr 6, 2022 · 4 comments
Closed
Tracked by #2758

VIP: safe erc20 transfer builtin #2753

charles-cooper opened this issue Apr 6, 2022 · 4 comments
Labels
Easy Pickings Used to denote issues that should be easy to implement VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting

Comments

@charles-cooper
Copy link
Member

Simple Summary

add a builtin to handle non-compliant ERC20 tokens

Motivation

I see this in the wild all the time:

res: Bytes[32] = raw_call(_abi_encode(sender, receiver, amount), method_id=method_id("transferFrom(address,address,uint256)"))
if len(res) > 0:
    assert convert(res, bool)

We could do it more efficiently as a builtin.

Specification

add a function, (name: safeTransferFromERC20?), which implements a safe ERC20 transfer as above.

Dependencies

May be good to implement this as a library function once #2431 is implemented.

Copyright

Copyright and related rights waived via CC0

@charles-cooper charles-cooper added VIP: Approved VIP Approved Easy Pickings Used to denote issues that should be easy to implement labels Apr 6, 2022
@fubuloubu fubuloubu added VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting and removed VIP: Approved VIP Approved labels Apr 6, 2022
@charles-cooper
Copy link
Member Author

charles-cooper commented Apr 8, 2022

whoops, i searched for the "VIP" label and clicked the first one. obviously needs to go up for discussion first!

@charles-cooper
Copy link
Member Author

charles-cooper commented Apr 8, 2022

By the way, I've been thinking about this and i think we might want to add a "default" returnvalue to calls. this is a more general mechanism for dealing with contracts which return less data than expected, so we do not have to add a builtin for every ERC20 (or, could be other standards) function implementation which is buggy. something like

ExternalContract(msg.sender).some_function(<args>, default=False)

The compiler can issue code to fill the return buffer with the default value if returndatasize is empty.

@charles-cooper
Copy link
Member Author

note: default is just a placeholder, real name of the kwarg TBD if we decide to move forward with this idea.

@charles-cooper
Copy link
Member Author

closed in favor of #2812

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Easy Pickings Used to denote issues that should be easy to implement VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting
Projects
None yet
Development

No branches or pull requests

2 participants