[WIP] UMIP-179: Updates

UMIPs/umip-179.md

@@ -407,6 +407,9 @@ Each valid `Fill` is subject to an LP fee. The procedure for computing LP fees i
 - 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` specified by the `Deposit` and `repaymentChainId` specified by the relayer, where the `relayExecutionInfo.FillType != SlowFill` and the Fill `destinationChainId` otherwise.
+- 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.
 
 #### Note
 - The LP fee is typically referenced as a multiplier of the `Deposit` `inputAmount`, named `realizedLpFeePct` elsewhere in this document.
@@ -421,7 +424,7 @@ The bundle LP fee for a `Bundle Block Range` on a SpokePool and token pair shall
 Each `FilledRelay` or `FilledV3Relay` can have multiple associated deposit events. In the event of multiple matching deposit events, there will be multiple LP fees paid per event in the case of a non slow fill.
 
 ### Computing Relayer Repayments
-For each validated matching `Deposit` event, the relayer repayment amount shall be computed as follows:
+For each validated `Fill`, 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 `Deposit` `quoteTimestamp`.
 - The applicable rate model shall be sourced from the AcrossConfigStore contract for the relevant `l1Token`.
 - For a given `Fill` that satisfies the requirements for relayer repayment, each matching `Deposit` generates a distinct repayment computed against its `quoteTimestamp`.
@@ -441,12 +444,17 @@ If the applied `repayment address` is not valid for the applied `repaymentChainI
 - Examples of an invalid `relayer` address include:
     - An SVM address on an EVM chain.
 
+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 `Deposit` event, the depositor refund amount shall be computed as `inputAmount` units of `inputToken`.
 
 ### 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 earliest matching deposit's `quoteTimestamp` between `originChainId` and `destinationChainId`.
+- `updatedOutputAmount = (inputAmount * (1e18 - realizedLpFeePct)) / 1e18`, where `realizedLpFeePct` is computed at the earliest matching deposit's `quoteTimestamp` between `originChainId` and `destinationChainId`.
 
 #### Constraint
 - The `Deposit` `outputAmount` shall _not_ be considered when determining SlowFill amounts.
@@ -606,4 +614,4 @@ The array of Slow Relay Leaf instances shall be sorted according to;
 The Across v3 implementation is available in the Across [contracts-v2](https://github.com/across-protocol/contracts) repository.
 
 # Security considerations
-Across v3 has been audited by OpenZeppelin.
+Across v3 has been [audited by OpenZeppelin](https://blog.openzeppelin.com/across-v3-incremental-audit).