[WIP] UMIP-179: Updates

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`.
 
@@ -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).