Reactive Network

In the current bridge implementation, once a transfer message is confirmed and successfully relayed from the source bridge to the destination bridge, the user's funds are effectively deducted from the source chain. However, if the transaction fails on the destination bridge due to any factors, the bridge does not provide a mechanism to refund the user’s assets.This issue specifically arises in BRIDGE <-> BRIDGE interactions, where one bridge communicates directly with another bridge without involving the ReactiveBridge (RNBRIDGE). Since BRIDGE <-> RNBRIDGE interactions are the intended, the lack of a refund mechanism is only a concern when bridges interact directly with each other. In such cases, users may face an irreversible loss of funds, exposing them to financial risk.

The bridge contract currently lacks a comprehensive testing suite, which poses significant risks to its reliability, security, and functionality. Without unit and integration tests, there is no systematic way to verify that the contract behaves as intended across different scenarios, including edge cases and failure conditions. This absence of testing increases the likelihood of undetected vulnerabilities, incorrect logic implementation, and potential financial losses due to undiagnosed bugs.