Reactive Network

The _processRejection function is responsible for handling message rejections on the destination chain. If the condition holds, the function updates the message status to MessageStatus.REJECTED and subsequently calls _rejectDelivery(id). However, _rejectDelivery(id) checks whether its status is MessageStatus.DELIVERING. If the condition is met, the function updates the message status to MessageStatus.REJECTED and calls _sendDeliveryRejection(id).  The issue occurs because _processRejection modifies the message status to MessageStatus.REJECTED before _rejectDelivery(id) executes. Since _rejectDelivery explicitly requires the message status to be MessageStatus.DELIVERING, the require condition fails, causing the transaction to revert. This results in a denial of service (DoS), preventing the rejection from being processed successfully.

In the current bridge implementation, event subscription is critical for ensuring that the bridge can listen for and process specific event topics. The contract subscribes to various event topics such as SEND_MESSAGE_TOPIC, CANCEL_MESSAGE_TOPIC, RETRY_TOPIC, DELIVERED_TOPIC, FAILED_TOPIC, and others to ensure that all relevant transactions are properly handled.However, an issue has been identified in the subscription logic where the REJECTION_TOPIC has been mistakenly subscribed to twice instead of subscribing to the FAILED_TOPIC. The affected code snippet is as follows: As a result of this incorrect subscription, events emitted with the FAILED_TOPIC will not be captured by the bridge. This leads to a failure in handling failed transactions, as the necessary logic to process and recover funds from failed transactions will not be executed. Consequently, affected users may permanently lose their funds, as the system fails to recognize and act upon failed transaction events

The AbstractFeeCalculator contract implements a fee calculation mechanism using a fixed fee (fixed_fee) and a percentage-based fee (perc_fee). The fees are initialized via the constructor and used in the _computeFee function to determine the total fee applied to a given amount. Fees will be collected on the destination bridge once the delivery occurs. However, there are no constraints on the values of fixed_fee and perc_fee, which introduces several risks. If fixed_fee or perc_fee is set too high, users may be charged excessive fees upon message delivery, potentially making transactions infeasible.