-
Notifications
You must be signed in to change notification settings - Fork 75
feat: relay logic #9
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
Signed-off-by: Nick Pai <npai.nyc@gmail.com>
…ill to pull from relayer
chrismaree
left a comment
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.
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. |
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.
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).
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.
Hm I think this could be useful, how do you propose the user lets the relayer know?
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.
the depositor would need an extra bool, which is kind of a pain 🤔 . might not be worth it tbh
chrismaree
left a comment
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.
This is excellent! nice and simple, well commented and good code. good work
mrice32
left a comment
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! A few high-level comments
mrice32
left a comment
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.
This looks awesome! Thanks for adding the hashing logic. +1. I have one high-level comment
mrice32
left a comment
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.
Only remaining comment: #9 (comment).
| // 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; |
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.
nice. I prefer this pattern.
| address timerAddress, | ||
| address _wethAddress, | ||
| uint64 _depositQuoteTimeBuffer | ||
| ) Testable(timerAddress) { |
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.
in the constructor params might it be better to put the timer last? we always do this in all the other UMA contracts. wdyt?
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.
sure
test/SpokePool.Relay.ts
Outdated
| spokePool | ||
| .connect(relayer) | ||
| .fillRelay( | ||
| relayData[0], |
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.
can you not just use the spread operator here? ...relayData?
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.
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
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.
done
mrice32
left a comment
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! Two minor comments on the fill math, but this looks really good!
contracts/SpokePool.sol
Outdated
| // 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; |
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.
Would swapping the order of the multiplication and division mean less rounding?
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.
hm yeah
contracts/SpokePool.sol
Outdated
| // 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, |
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.
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?
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.
Ah yes i forgot to add this logic, will do
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.
Do you think this logic is too convoluted and are there gas savings? c6970ae
contracts/SpokePool.sol
Outdated
| // we'll pull exactly enough tokens to complete the relay. | ||
| uint256 amountToSend; | ||
| if (totalRelayAmount - relayFills[relayHash] < fillAmountPreFees) { | ||
| amountToSend = totalRelayAmount - relayFills[relayHash]; |
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.
Won't this cause them to send the amount including fees. Don't we need to multiply this by (1e18 - (realizedLpFeePct + relayerFeePct)) / 1e18?
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.
Ah yes good call, fixed
contracts/SpokePool.sol
Outdated
| } | ||
|
|
||
| function _computeAmountPostFees(uint256 amount, uint256 feesPct) private pure returns (uint256) { | ||
| return (amount * feesPct) / 1e18; |
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: should this also be (1e18 - feesPct) rather than just feesPct?
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.
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
mrice32
left a comment
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.
Everything looks good, just that one nit: #9 (comment)
…art-contracts-v2 into npai/relay-flow
mrice32
left a comment
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!
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
Signed-off-by: james-a-morris <jaamorris@cs.stonybrook.edu>
Signed-off-by: Nick Pai npai.nyc@gmail.com