1inch Fusion

In the `Create` context of the fusion-swap program, makers are required to specify protocol fee and integrator fee parameters as well as their corresponding associated token accounts (protocol_dst_ata and integrator_dst_ata). However, the current implementation does not enforce these parameters strictly. This means that a maker can potentially create an order without setting protocol or integrator fees or by misconfiguring the protocol_dst_ata. Consequently, the maker might avoid fee deductions and receive a higher net amount than intended by the protocol fee design. Note that even if the UI enforces fee parameters, malicious makers could bypass these checks by directly interacting with the program. While this issue might be less impactful because takers (or resolvers) must be whitelisted by the protocol and are incentivized to fill only orders with correct fee configurations, it still poses a risk. In practice, resolvers may refuse to fill orders that do not have fees applied to the correct token accounts, but the absence of on-chain enforcement or fixed values allows makers to manipulate these parameters.

In the `get_fee_amounts()` function of the fusion-swap program, surplus fees are conditionally applied based on the comparison between the calculated destination amount (after applying the Dutch auction adjustments and subtracting the protocol and integrator fees) and the user-supplied `estimated_dst_amount`. Specifically, the surplus fee is added only if the adjusted destination amount exceeds the `estimated_dst_amount`. This design allows a maker to avoid the impact of surplus fees by setting the `estimated_dst_amount` to an excessively high value relative to `min_dst_amount`. As a result, the condition to trigger the surplus fee is never met, and the protocol fee component intended to capture surplus (positive slippage) is effectively bypassed.

The protocol does not enforce the `authority` constraint on the `taker_src_ata` account. This allows the taker to provide any account as long as the `mint` constraint is correct, which can lead to fund loss if an incorrect address is provided.

The protocol allows the maker to set a `min_dst_amount` during order creation. By definition, this amount represents the minimum destination tokens the maker is willing to receive in exchange for source tokens. However, the protocol currently uses this amount to calculate exchange rates via the `get_dst_amount()` function and then deducts fees from the calculated amount using the `get_fee_amounts()` function. However, under certain conditions—particularly when the calculated fees (protocol, integrator, and surplus) exceed the bump provided by the Dutch auction—the resulting destination amount for the maker may fall below the intended `min_dst_amount`. This behavior effectively breaks the slippage protection mechanism. Makers expect `min_dst_amount` to represent the minimum amount of destination tokens they will receive, but due to the fee calculations, they may receive less than this minimum.

The protocol documentation specifies that the auction operates on a Dutch auction model, where the price is expected to decline over time. However, in the `calculate_rate_bump()` function in `fusion-swap/src/dutch_auction.rs`, there is no check to ensure that the rate bumps specified by the user in `points_and_time_deltas` are in a strictly declining order. This omission allows a user to supply rate bump values that could be non-monotonic (i.e., a subsequent bump could be higher than a previous one), which contradicts the intended Dutch auction behavior and the protocol documentation.

The fusion-swap program currently allows makers to supply fee parameters via the `ReducedFeeConfig` and rate bump values in the Dutch auction data without performing explicit bound checks. Unlike the surplus fee—which is validated to be less than `BASE_1E2`—there is no on-chain validation to ensure that: - The protocol fee and integrator fee values (or their sum) are within a reasonable range (e.g., less than or equal to `BASE_1E5`). Without this check, makers could specify arbitrarily high fees, potentially leading to unintended pricing behavior and potential underflow when substracting the fees from the `dst_amount`. - The rate bumps provided in the Dutch auction parameters are within an acceptable range relative to `BASE_1E5`. This extra validation would help prevent overflow in the `calculate_rate_bump()` function and ensure that the auction price adjustment behaves as intended.