-
Notifications
You must be signed in to change notification settings - Fork 75
feat: Add ERC7683 depositor #492
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
Conversation
The Permit2 stuff doesn't compile yet, need to model this off of the Permit2OrderLib
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.
Looks good! A few comments
| address(SPOKE_POOL), | ||
| resolvedOrder.swapperInputs[0].amount | ||
| ); | ||
| SPOKE_POOL.depositV3( |
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.
Thoughts on integrating directly into the SpokePool contract rather than making an external call?
Pros: cheaper on gas, people are permitting the spoke pool contract directly
Cons: more complexity in the spoke pool
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.
we're also going to run into bytecode limits
|
|
||
| /// @title CrossChainOrder type | ||
| /// @notice Standard order struct to be signed by swappers, disseminated to fillers, and submitted to settlement contracts | ||
| struct CrossChainOrder { |
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.
nit: might make sense to move the canonical ERC7683 types into a separate file, just to distinguish them from our Across-specific types.
|
|
||
| /// @title ISettlementContract | ||
| /// @notice Standard interface for settlement contracts | ||
| interface ISettlementContract { |
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.
Same for this interface: might be good to put it in a separate file for just "pure" ERC7683 interfaces/structs
| // Data unique to every attempted order fulfillment | ||
| struct AcrossFillerData { | ||
| // Filler can choose where they want to be repaid | ||
| uint32 repaymentChainId; | ||
| } |
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.
Since we can't accurately assess fees if the filler takes repayment elsewhere and we can't enforce this choice on the fill side, thoughts on just resolving assuming that they will take repayment on origin and not having them specify the repayment chain here?
Then the fees and repayment location change if they input a different repayment chain on the destination?
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.
LGTM!
|
|
||
| /// @title ISettlementContract | ||
| /// @notice Standard interface for settlement contracts | ||
| interface ISettlementContract { |
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.
should this file be named IERC7683.sol?
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.
looks great, thanks for refactoring
|
Will add tests in a follow-up |
This adds an ERC7683 Depositor contract that takes a signed ERC7683 order and converts it into an AcrossV3 deposit.