-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat: SafeErc20 utility #289
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for contracts-stylus canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @0xNeshi and thanks for your contribution!
Appreciate it!
Hard to tell for me right now what kind of design should be the best for SafeErc20
with current state of the stylus-sdk.
IMHO we can try to build a working example first with end-to-end tests. Then later dive into optimization if it will make sense.
There is no good interoperability between rust struct, that defines a contract in stylus and an external call to that contract (deployed at some address) as it is in solidity.
So we can try to add Erc20
solidity abi into sol_interface!
macro like IERC721Receiver example.
And use call contract's type generated by sol_interface!
as a first argument like it is in solidity SafeErc20 example.
But we should process boolean responses from underlying Erc20
contract differently as it is specified in the solidity counterpart.
Then we can use IErc20 trait to create wrapped Erc20 contract. It should route most calls externally using the Call::new(..)
api from the stylus-sdk (like Erc721Receiver example)
How do you feel about this plan?
EDIT: I realized what the issue is, see #289 (comment) @qalisander sounds like a good plan! I implemented what I understood to be what you had imagined. See the most recent changes. Note: I'm trying to implement a working solution for the regular ERC20 I also implemented one "happy flow" test for For context, I implemented a mock ERC20 contract that on calling To test my hypothesis that I tried another approach by using
|
scripts/e2e-tests.sh
Outdated
@@ -11,4 +11,4 @@ cargo +"$NIGHTLY_TOOLCHAIN" build --release --target wasm32-unknown-unknown -Z b | |||
export RPC_URL=http://localhost:8547 | |||
# We should use stable here once nitro-testnode is updated and the contracts fit | |||
# the size limit. Work tracked [here](https://github.com/OpenZeppelin/rust-contracts-stylus/issues/87) | |||
cargo +"$NIGHTLY_TOOLCHAIN" test --features std,e2e --test "*" | |||
cargo +"$NIGHTLY_TOOLCHAIN" test --features e2e -p safe-erc20-example --test safe-erc20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will revert this once ready for merge, using this for easier testing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. If yours IDE allows to set build settings for tests, you can also run specific integration test from IDE's UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the msg sender issue above, I hope the explanation was clear enough. The same issue is there for safe_transfer_from
, as the msg sender isn't the one expected (the original sender of tx).
EDIT: I realized what the issue is, see #289 (comment)
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
|
Resolves #279
NOTE: It is possible I misused or misunderstood certain functionality of the Stylus SDK or just how to write Stylus contracts in general. If that is the case, it goes without saying that, for the sake of getting up to speed with Stylus, I would greatly appreciate any feedback on how to write contracts better (or just correctly).
I was torn between making
SafeErc20
an inheritable contract and making it a trait implemented against ERC20 tokens, but I opted for the latter as it seems to more closely fit the "this is an extension of the ERC20" paradigm. In other words, if devs need to have the "safe" functions, they can import the trait and use the functions as regular ERC20 ones.PR Checklist