From 867733df22673de8be1ec1dbd5a8d96b4f95619e Mon Sep 17 00:00:00 2001 From: Paul <108695806+pxrl@users.noreply.github.com> Date: Mon, 22 Apr 2024 12:03:09 +0200 Subject: [PATCH 1/4] [fix]: Address UMIP-179 feedback - Specify proposer action on invalid FilledV3Relay repaymentChainId. - Clarify proposer action on un-executable RelayerRefundLeaf. - Add link to OZ audit for Across V3. --- UMIPs/umip-179.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/UMIPs/umip-179.md b/UMIPs/umip-179.md index e5ba4b07..a4990dac 100644 --- a/UMIPs/umip-179.md +++ b/UMIPs/umip-179.md @@ -355,6 +355,11 @@ At least one Relayer Refund Leaf shall be produced for each unique combination o - Expired `V3Fundsdeposited` events, OR - A negative running balance net send amount. +If a validated `FilledV3Relay` event specifies an invalid `repaymentChainId`, the proposer shall issue repayment on the HubPool 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`. + Each Relayer Refund Leaf shall be constructed as follows: - `amountToReturn` shall be set to `max(-netSendAmount, 0)`. - `l2TokenAddress` shall be set to the L2 token address for the corresponding `l1Token` considered in Pool Rebalance Root production. @@ -368,7 +373,7 @@ Each Relayer Refund Leaf shall be constructed as follows: 1. `refundAmount` descending order, then 2. `relayerAddress` ascending order (in case of duplicate `refundAmount` values). -In the event that the number of refunds contained within a Relayer Refund leaf should exceed [`MAX_RELAYER_REPAYMENT_LEAF_SIZE`]((https://github.com/UMAprotocol/UMIPs/blob/7b1a046098d3e2583abd0372c5e9c6003b46ad92/UMIPs/umip-157.md#global-constants) refunds: +In the event that the number of refunds contained within a Relayer Refund leaf should exceed [`MAX_RELAYER_REPAYMENT_LEAF_SIZE`](https://github.com/UMAprotocol/UMIPs/blob/7b1a046098d3e2583abd0372c5e9c6003b46ad92/UMIPs/umip-157.md#global-constants) refunds: 1. Additional `RelayerRefundLeaf` instances shall be produced to accomodate the excess. 2. The ordering of `refundAddresses` and `refundAmounts` shall be maintained across the ordered array of leaves. 3. Only the first leaf for a given `l2TokenAddress` shall contain a non-zero `amountToReturn`. @@ -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. +Note: +- This is intended to deal with unlikely situations, such as a centralized token issuer censoring transactions concerning a relayer address, and is required to prevent deadlocking of all other relayer repayments in the same Relayer Refund Leaf. +- In the event of relayer repayment exclusion, the proposer should provide reproducible evidence that the relayer repayment would fail as part of any subsequent dispute. + + Note: - Once these leaves are constructed, they can be used to form a merkle root as described in the previous section. @@ -413,7 +424,4 @@ The V3 rules defined in this UMIP will apply beginning when the VERSION field in The Across v3 implementation is available in the Across [contracts-v2](https://github.com/across-protocol/contracts-v2) repository. # Security considerations -Across v3 has been audited by OpenZeppelin. - -Note: -- If a particular relayer refund is known to be unexecutable, it can be removed from the bundle by the proposer if a sufficient public justification is made before the proposal. This is intended to deal with unlikely situations, such as ag centralized token issuer blacklisting an address that is due a refund. If this leaf were to remain unaltered, this blacklisted address could block other addresses from recieving refunds. +Across v3 has been [audited by OpenZeppelin](https://blog.openzeppelin.com/across-v3-incremental-audit). From a45310c8103efea61dbc1c016b56d55283d28b1f Mon Sep 17 00:00:00 2001 From: Paul <108695806+pxrl@users.noreply.github.com> Date: Mon, 22 Apr 2024 12:13:32 +0200 Subject: [PATCH 2/4] Fix repayment chain wording --- UMIPs/umip-179.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/UMIPs/umip-179.md b/UMIPs/umip-179.md index a4990dac..702d1225 100644 --- a/UMIPs/umip-179.md +++ b/UMIPs/umip-179.md @@ -257,6 +257,11 @@ For a validated `FilledV3Relay` event, the relayer repayment amount shall be com - `(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`. - The applicable rate model shall be sourced from the AcrossConfigStore contract for the relevant `l1Token`. +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`. + ### Computing Deposit Refunds For an expired `V3FundsDeposited` event, the depositor refund amount shall be computed as `inputAmount` units of `inputToken`. @@ -355,11 +360,6 @@ At least one Relayer Refund Leaf shall be produced for each unique combination o - Expired `V3Fundsdeposited` events, OR - A negative running balance net send amount. -If a validated `FilledV3Relay` event specifies an invalid `repaymentChainId`, the proposer shall issue repayment on the HubPool 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`. - Each Relayer Refund Leaf shall be constructed as follows: - `amountToReturn` shall be set to `max(-netSendAmount, 0)`. - `l2TokenAddress` shall be set to the L2 token address for the corresponding `l1Token` considered in Pool Rebalance Root production. From d06ad9e799cdf9e329ad2b3f31d69be01cf1838e Mon Sep 17 00:00:00 2001 From: Paul <108695806+pxrl@users.noreply.github.com> Date: Mon, 22 Apr 2024 12:19:58 +0200 Subject: [PATCH 3/4] Fix 1 -> 1e18 --- UMIPs/umip-179.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UMIPs/umip-179.md b/UMIPs/umip-179.md index 702d1225..1eff95bc 100644 --- a/UMIPs/umip-179.md +++ b/UMIPs/umip-179.md @@ -254,7 +254,7 @@ The bundle LP fee for a target block range on a SpokePool and token pair shall b ### 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`. - The applicable rate model shall be sourced from the AcrossConfigStore contract for the relevant `l1Token`. If a validated `FilledV3Relay` event specifies an invalid `repaymentChainId`, the proposer shall issue repayment on the fill destination chain. @@ -267,7 +267,7 @@ For an expired `V3FundsDeposited` event, the depositor refund amount shall be co ### Computing Slow Fill updated output amounts For the purpose of computing the amount to issue to a recipient for a SlowFill, the relayer fee shall be nulled by applying the following procedure: -- `updatedOutputAmount = (inputAmount * (1 - realizedLpFeePct)) / 1e18`, where `realizedLpFeePct` is computed at the deposit `quoteTimestamp` between `originChainId` and `destinationChainId`. +- `updatedOutputAmount = (inputAmount * (1e18 - realizedLpFeePct)) / 1e18`, where `realizedLpFeePct` is computed at the deposit `quoteTimestamp` between `originChainId` and `destinationChainId`. Constraint: - The `V3FundsDeposited` `outputAmount` shall _not_ be considered when determining SlowFill amounts. From 4812cc3e66ef5eb91566823f8be7be07328d2ad1 Mon Sep 17 00:00:00 2001 From: Paul <108695806+pxrl@users.noreply.github.com> Date: Mon, 22 Apr 2024 12:28:59 +0200 Subject: [PATCH 4/4] Clarify LP fee precision --- UMIPs/umip-179.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/UMIPs/umip-179.md b/UMIPs/umip-179.md index 1eff95bc..9898c246 100644 --- a/UMIPs/umip-179.md +++ b/UMIPs/umip-179.md @@ -244,9 +244,9 @@ Each valid `FilledV3Relay` event is subject to an LP fee. The procedure for comp - The `HubPool` `liquidityUtilizationCurrent()` and `liquidityUtilizationPostRelay()` functions shall be used instead of the `BridgePool` variant. - The event `inputToken` shall be mapped from the SpokePool address to a HubPool `l1Token` address by following the matching procedure outlined above. - The LP fee is computed between the `originChainId` and `FilledV3Relay.repaymentChainId` where the `relayExecutionInfo.FillType != SlowFill` and `FilledV3Relay.destinationChainId` otherwise. - -Note: -- 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. ### 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: