Skip to content

Conversation

@nicholaspai
Copy link
Member

@nicholaspai nicholaspai commented Jan 26, 2022

Signed-off-by: Nick Pai npai.nyc@gmail.com

Signed-off-by: Nick Pai <npai.nyc@gmail.com>
Copy link
Member

@chrismaree chrismaree left a comment

Choose a reason for hiding this comment

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

This looks great to me! I think you should add a bit more to events and perhaps consider changing how you are appending to arrays but other than this it looks great!

uint256 amountNetFees = amount - _getAmountFromPct(relay.realizedLpFeePct + relay.relayerFeePct, amount);
IERC20(relay.destinationToken).safeTransferFrom(msg.sender, relay.recipient, amountNetFees);

// If relay token is weth then unwrap and send eth.
Copy link
Member

Choose a reason for hiding this comment

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

do you think that we should try let the user choose to receive WETH or ETH? it's kinda strange that a user sending WETH or ETH always gets ETH? (obs not something for now but I'm curious what you think).

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm I think this could be useful, how do you propose the user lets the relayer know?

Copy link
Member

Choose a reason for hiding this comment

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

the depositor would need an extra bool, which is kind of a pain 🤔 . might not be worth it tbh

Copy link
Member

@chrismaree chrismaree left a comment

Choose a reason for hiding this comment

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

This is excellent! nice and simple, well commented and good code. good work

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 great! A few high-level comments

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.

This looks awesome! Thanks for adding the hashing logic. +1. I have one high-level comment

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.

Only remaining comment: #9 (comment).

@nicholaspai nicholaspai requested a review from mrice32 January 31, 2022 22:52
// Address of WETH contract for this network. If an origin token matches this, then the caller can optionally
// instruct this contract to wrap ETH when depositing.
address public wethAddress;
WETH9Like public weth;
Copy link
Member

Choose a reason for hiding this comment

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

nice. I prefer this pattern.

address timerAddress,
address _wethAddress,
uint64 _depositQuoteTimeBuffer
) Testable(timerAddress) {
Copy link
Member

Choose a reason for hiding this comment

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

in the constructor params might it be better to put the timer last? we always do this in all the other UMA contracts. wdyt?

Copy link
Member Author

Choose a reason for hiding this comment

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

sure

spokePool
.connect(relayer)
.fillRelay(
relayData[0],
Copy link
Member

Choose a reason for hiding this comment

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

can you not just use the spread operator here? ...relayData?

Copy link
Member

Choose a reason for hiding this comment

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

I see in a few of these cases you are overriding the data within relayData. this could be solved by returning an object from getRelayhash then overriding the named props using {...relayData, namedPropYouWantToOverride} or something like this so we dont need to define these long lists of indexes.

wdyt, my goal is fewer lines here

Copy link
Member Author

Choose a reason for hiding this comment

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

done

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! Two minor comments on the fill math, but this looks really good!

// that we'll add to the `relayFills` counter, and we do this math here in the contract for the user's
// convenience so that they don't have to do this math before calling this function. The user can simply
// pass in `maxTokensToSend` and assume that the contract will pull exactly that amount of tokens (or revert).
uint256 fillAmountPreFees = (maxTokensToSend / (1e18 - (realizedLpFeePct + relayerFeePct))) * 1e18;
Copy link
Contributor

Choose a reason for hiding this comment

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

Would swapping the order of the multiplication and division mean less rounding?

Copy link
Member Author

Choose a reason for hiding this comment

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

hm yeah

// to the amount filled so far for a particular `relayHash`, so this will start at 0 and increment with each
// fill.
require(
maxTokensToSend > 0 && totalRelayAmount >= relayFills[relayHash] + fillAmountPreFees,
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this would fail if the user passes in a number larger than the amount needed to fill the remainder of the relay. Should we do some something like min(totalRelayAmount - relayFills[relayHash], fillAmountPreFees) to determine how much they will actually fill?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah yes i forgot to add this logic, will do

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you think this logic is too convoluted and are there gas savings? c6970ae

@nicholaspai nicholaspai requested a review from mrice32 February 1, 2022 17:42
// we'll pull exactly enough tokens to complete the relay.
uint256 amountToSend;
if (totalRelayAmount - relayFills[relayHash] < fillAmountPreFees) {
amountToSend = totalRelayAmount - relayFills[relayHash];
Copy link
Contributor

Choose a reason for hiding this comment

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

Won't this cause them to send the amount including fees. Don't we need to multiply this by (1e18 - (realizedLpFeePct + relayerFeePct)) / 1e18?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah yes good call, fixed

@nicholaspai nicholaspai requested a review from mrice32 February 1, 2022 19:21
}

function _computeAmountPostFees(uint256 amount, uint256 feesPct) private pure returns (uint256) {
return (amount * feesPct) / 1e18;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: should this also be (1e18 - feesPct) rather than just feesPct?

Copy link
Member Author

Choose a reason for hiding this comment

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

shoot yeah, the test case where the fees are equally set to 0.25 and 0.25 is confusing because 1e18 - totalFeesPct == totalFeesPct. I changed the test values to 0.1 and 0.2 and changed this solidity code to 1e18 - feesPct

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.

Everything looks good, just that one nit: #9 (comment)

@nicholaspai nicholaspai requested a review from mrice32 February 1, 2022 19:39
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!

@nicholaspai nicholaspai merged commit a44eeb2 into master Feb 1, 2022
@nicholaspai nicholaspai deleted the npai/relay-flow branch February 1, 2022 19:59
pxrl pushed a commit that referenced this pull request Feb 13, 2024
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
pxrl pushed a commit that referenced this pull request Feb 20, 2024
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
pxrl pushed a commit that referenced this pull request Feb 20, 2024
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
pxrl added a commit that referenced this pull request Feb 20, 2024
Initially submitted by James.

Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
Co-authored-by: James Morris, MS <96435344+james-a-morris@users.noreply.github.com>
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.

4 participants