Skip to content

Conversation

@nicholaspai
Copy link
Member

@nicholaspai nicholaspai commented May 8, 2024

This adds an ERC7683 Depositor contract that takes a signed ERC7683 order and converts it into an AcrossV3 deposit.

The Permit2 stuff doesn't compile yet, need to model this off of the Permit2OrderLib
Copy link
Contributor

@mrice32 mrice32 left a 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(
Copy link
Contributor

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

Copy link
Member Author

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 {
Copy link
Contributor

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 {
Copy link
Contributor

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

Comment on lines 96 to 100
// Data unique to every attempted order fulfillment
struct AcrossFillerData {
// Filler can choose where they want to be repaid
uint32 repaymentChainId;
}
Copy link
Contributor

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?

mrice32 added 5 commits May 19, 2024 22:17
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
@mrice32 mrice32 changed the title WIP: feat: Add ERC7683 depositor feat: Add ERC7683 depositor May 20, 2024
@mrice32 mrice32 marked this pull request as ready for review May 20, 2024 05:33
Copy link
Contributor

@mrice32 mrice32 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

mrice32 added 4 commits May 20, 2024 01:56
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
Signed-off-by: Matt Rice <matthewcrice32@gmail.com>
@mrice32 mrice32 requested review from bmzig, james-a-morris and pxrl May 20, 2024 09:13

/// @title ISettlementContract
/// @notice Standard interface for settlement contracts
interface ISettlementContract {
Copy link
Member Author

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?

Copy link
Member Author

@nicholaspai nicholaspai left a 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

@mrice32
Copy link
Contributor

mrice32 commented May 20, 2024

Will add tests in a follow-up

@mrice32 mrice32 merged commit 95c4f92 into master May 20, 2024
@mrice32 mrice32 deleted the npai/erc7683 branch May 20, 2024 22:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants