Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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(contracts-rfq): relayer exclusivity [SLT-187] #3202
feat(contracts-rfq): relayer exclusivity [SLT-187] #3202
Changes from 21 commits
7109611
3125ba9
2b3775e
e06f942
c160a4e
0b71e5f
b00b2e0
0fdb834
72e0e7b
2f82a9a
ff924d3
1b26e0b
c8e9278
98d4539
181410c
aaa5b2c
a944c04
1582711
023dd13
3601866
be0cbaa
67f2b30
784457f
dbdd0b8
047df43
d31d882
e130127
b6a6f57
023ed31
d6e76ca
34378a5
ef4aa2b
e5fce17
415aa18
6f5ffa7
ad5bd73
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning
Code scanning / Slither
Uninitialized local variables Medium
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.
it seems like it might be possible for this to briefly delay a non-exclusive relay from occurring due to clock gaps btwn chains.
That is, if the dest chain is X seconds behind the origin, it would not be possible for anyone to relay until the EndTime is reached on the dest, no?
Should we restructure the checks like this:
if exclusivityRelayer is 0 or
relayer
, do not bother comparing exclusivity timestamp & just move along.Otherwise, proceed to check that the exclusivity end time is in the past & revert if not.
This might also be more gas efficient overall
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.
For "non-exclusive txs"
exclusivityEndTime == 0
(set by usingparamsV2.quoteExclusivitySeconds = 0
), so this will actually succeed without checking the relayer address.However, the dest chain being behind would mean that the exclusivity period is extended longer than it should be for "exclusive txs". I guess we could treat this in two ways:
quoteExclusivitySeconds
so that theexclusivityEndTime
could be set to a past timestamp origin-chain-wise, but a future timestamp for a destination chain, which is behind. In this casethe FE would use a negative value for such scenarios.These are mostly similar, with the only difference being setting "exclusivity seconds" to either one second, or to a negative value (setting it to zero will turn off the exclusivity).
What do you think about these options?
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 I was neglecting this piece of bridge() and instead thinking that a non-excl would just have an endtime +0 seconds from deposit block ts
uint256 exclusivityEndTime = paramsV2.quoteExclusivitySeconds == 0 ? 0 : block.timestamp + paramsV2.quoteExclusivitySeconds;
option 2 seems like the better choice -- offers more flexibility & seems like it should not cost anything extra to allow a negative offset. If wanted to also allow zero exclusive seconds, could we switch to exclRelayer address = 0 to indicate/detect that exclusivity is off?
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.
Could go for
quoteExclusivitySeconds
beingint256
rather thanuint256
to allow negative values, don't see any concerns with that (txs havingexclusivityEndTime
in the past could be still completed by anyone).As for allowing zero exclusive seconds with a quote relayer address, I think this is a very niche usecase, which might as well use +-1 instead of zero. Having this check in place allows to prevent bridge txs that mistakenly have only one exclusivity param from being initiated on the origin chain - this looks like a bigger concern to me than having to use +-1 instead of zero.
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.
Actually, I take back the comment above. Having
quoteRelayer
as a single indicator of whether exclusivity is requested feels simple enough, and the incorrect integration (setting quote relayer but not seconds) isn't actually that bad - it's easily solvable and doesn't put anything at risk.And this is also easier to enforce in the contracts. Will rework the tests and follow up with the contract changes