Description

Funds can be seized in a few cases.

Swaps

The input asset is seized if its amount is less than the MinimumSwapAmount:

if amount < MinimumSwapAmount::<T>::get(from) {
    // If the swap amount is less than the minimum required,
    // confiscate the fund and emit an event
    CollectedRejectedFunds::<T>::mutate(from, |fund| {
        *fund = fund.saturating_add(amount)
    });

Cross-chain messaging

There are multiple edge-cases where funds can be seized when using cross-chain messaging (CCM).

First, if the CCM call-destination asset's chain is not Ethereum:

if ForeignChain::Ethereum != destination_asset.into() {
    return Err(CcmFailReason::UnsupportedForTargetChain)

Funds can also be seized if a CCM's deposit amount is not large enough to cover the requested gas budget:

} else if deposit_amount < gas_budget {
    return Err(CcmFailReason::InsufficientDepositAmount)

Finally, when swapping an asset using a CCM, funds can be seized if the input asset amount is less than the MinimumSwapAmount:

} else if source_asset != destination_asset &&
    !principal_swap_amount.is_zero() &&
    principal_swap_amount < MinimumSwapAmount::<T>::get(source_asset)
{
    // [...]
    return Err(CcmFailReason::PrincipalSwapAmountTooLow)

Funds are seized by accounting them in the pallet storage in CollectedRejectedFunds. There is no mechanism to refund users of their seized funds, however the funds may be used to cover fees in some cases. We outline this behavior below.

Impact

Regardless of whether or not this is an issue, we feel the need to document the behavior; however, we do consider this an issue for the following reasons.

How seized funds are used

Seized funds — regardless of how or why they are seized — are left wherever they are transferred to.

In the case of a transfer of Ether to the vault contract, for example, the funds can be used to pay for gas fees.

However, in the case of a transfer of a non-native coin/token (e.g., an ERC-20 such as USDC), the seized amount would be permanently locked in the contract and would not be usable for gas fees or any other purpose.

Situations in which users may lose funds unintentionally

Though intentionally sending funds that do not meet the conditions to swap or CCM — hence causing the funds to be confiscated — would be akin to intentionally sending funds to the 0x0 address (i.e. a footgun), we believe users may also unintentionally lose funds in a few cases including (but not limited to) the following:

• First, a user or application wanting to directly interact with the protocol (i.e., bypassing the dApp and its front-end restrictions) may not be aware of the requirement for a CCM call's destination to be Ethereum. A potentially large amount of assets may be seized in this case.

• Also, users who make deposits cannot atomically commit to swapping and execute their swap. That is, it is possible that — between the time they publish a signed transaction in an Ethereum mempool and the time the swap is recorded on chain (schedule_swap_from_channel) and validated to be above the minimum swap amount (among other checks) — the minimum swap amount configuration could be changed by the governance. It would not be the user's fault that their funds are confiscated.

• It is not unheard of for governance to pass a proposal that unintentionally harms a protocol such as configuring a MinimumSwapAmount that is off by a couple orders of magnitude and does not get noticed. Funds may be seized in this case, too.

Finding impact considering severity and likelihood

When evaluating a finding's impact, we first answer two questions:

1. In the event that the issue happens, regardless of why or how unlikely it is for the issue to happen, how bad would it be in the worst-case scenario? The possibility for large amount of funds to be seized exists in the case that the CCM destination chain is incorrect. However, it only impacts one user's funds. So, we rate this as Medium severity.

2. How likely is this issue to be exploited or triggered in practice? Realistically, users would not intentionally trigger this issue as they are deincentivized to do so, of course; however, it is possible for users to unintentionally encounter this issue as described above (poor timing with governance configuration changes, when building on the protocol or bypassing the dApp, etc.). Because the possibility exists for this issue to be unintentionally triggered — though it may be unlikely — we consider this to be Low likelihood, our lowest likelihood rating.

Combining these two criteria, we calculate the Low impact.

Recommendations

Provide a mechanism to refund (or retrieve) seized funds. Note that, whatever the mechanism is, it is critical that the user whose funds are seized pays the gas fees for retrieval to prevent denial-of-service attacks; if the seized funds are enough to be worth retrieving, the user will pay gas fees for them (or, otherwise, the user will not receive their funds).

We understand that such a feature is not trivial to safely implement. We respect Chainflip Labs's position, described below, considering the Low impact rating of this finding.

Remediation

Chainflip Labs's position on this finding is that the likelihood is low enough to not consider this an issue. Seized native coin (e.g., Ether) can be used for gas fees in the vault contract.