[WIP] [fix]: Address UMIP-179 feedback #602
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
pxrl
commented
Apr 22, 2024
pxrl
commented
- Specify proposer action on invalid FilledV3Relay repaymentChainId.
- Clarify proposer action on un-executable RelayerRefundLeaf.
- Add link to OZ audit for Across V3.
- Specify proposer action on invalid FilledV3Relay repaymentChainId. - Clarify proposer action on un-executable RelayerRefundLeaf. - Add link to OZ audit for Across V3.
pxrl
commented
Apr 22, 2024
Comment on lines
+260
to
+263
| If a validated `FilledV3Relay` event specifies an invalid `repaymentChainId`, the proposer shall issue repayment on the fill destination chain. | ||
| Reasons for the `repaymentChainId` to be considered invalid are: | ||
| - `repaymentChainId` is not supported by Across. | ||
| - `inputToken` is not supported as a repayment token on `repaymentChainId`. |
There was a problem hiding this comment.
I think forcing repayment on the destination chain is the only safe approach here, since if the relayer fills via a contract on zkSync and the proposer proposes repayment on some other chain then the relayer will never receive their repayment.
There was a problem hiding this comment.
Yeah, good point. I think that's right.
pxrl
commented
Apr 22, 2024
| - The LP fee is typically referenced as a multiplier of the `V3FundsDeposited` `inputAmount`, named `realizedLpFeePct` elsewhere in this document. | ||
| - The LP fee as a multiplier of `inputAmount` (typically named `realizedLpFeePct` elsewhere in this document) shall be: | ||
| - Promoted to 18 decimals, where 1e18 represents 100%, and | ||
| - Truncated (zeroed) between 0 and 1e10, providing 8 decimals of effective precision. |
There was a problem hiding this comment.
Would appreciate feedback on the wording here.
There was a problem hiding this comment.
Do you think it's easier to understand if you show the math?
The LP fee is truncated via the following formula: output = input / 1e10 * 1e10
mrice32
reviewed
May 6, 2024
| - The LP fee is typically referenced as a multiplier of the `V3FundsDeposited` `inputAmount`, named `realizedLpFeePct` elsewhere in this document. | ||
| - The LP fee as a multiplier of `inputAmount` (typically named `realizedLpFeePct` elsewhere in this document) shall be: | ||
| - Promoted to 18 decimals, where 1e18 represents 100%, and | ||
| - Truncated (zeroed) between 0 and 1e10, providing 8 decimals of effective precision. |
There was a problem hiding this comment.
Do you think it's easier to understand if you show the math?
The LP fee is truncated via the following formula: output = input / 1e10 * 1e10
|
|
||
| ### Computing Bundle LP Fees | ||
| The bundle LP fee for a target block range on a SpokePool and token pair shall be determined by summing the applicable LP fees for each of the following validated events: | ||
| - `FilledV3Relay` | ||
|
|
||
| ### Computing Relayer Repayments | ||
| For a validated `FilledV3Relay` event, the relayer repayment amount shall be computed as follows: | ||
| - `(inputAmount * (1 - realizedLpFeePct)) / 1e18`, where `realizedLpFeePct` is computed over the set of HubPool `l1Token`, `originChainId` and `repaymentChainId` at the HubPool block number corresponding to the relevant `V3FundsDeposited` `quoteTimestamp`. | ||
| - `(inputAmount * (1e18 - realizedLpFeePct)) / 1e18`, where `realizedLpFeePct` is computed over the set of HubPool `l1Token`, `originChainId` and `repaymentChainId` at the HubPool block number corresponding to the relevant `V3FundsDeposited` `quoteTimestamp`. |
Comment on lines
+260
to
+263
| If a validated `FilledV3Relay` event specifies an invalid `repaymentChainId`, the proposer shall issue repayment on the fill destination chain. | ||
| Reasons for the `repaymentChainId` to be considered invalid are: | ||
| - `repaymentChainId` is not supported by Across. | ||
| - `inputToken` is not supported as a repayment token on `repaymentChainId`. |
There was a problem hiding this comment.
Yeah, good point. I think that's right.
| @@ -380,6 +385,12 @@ The set of relayer refund leaves shall be ordered according to: | |||
|
|
|||
| The Relayer Refund Leaf `leafId` field shall be numbered according to the ordering established above, starting at 0. | |||
|
|
|||
| If a Relayer Refund Leaf would be unable to be executed due to an ERC20 reversion when transferring the repayment token to the recipient on the destination chain, the proposer may exclude the relayer repayment from the Relayer Refund Root. | |||
There was a problem hiding this comment.
Two things:
- Long term, I think this would be better handled in the contracts (having a data structure to store unexecuted payments that can be claimed anytime).
- I think the way this is written, it's ambiguous. I think we should say to be excluded from the bundle, it needs to be unexecutable at the bundle end block of the chain where the repayment will take place.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.