QuillAudits Secures Reactive Bridge: Stopping Fee Abuse, DOS and Unrecoverable Losses

What is Reactive Network?

Reactive Network is a parallelized interoperability execution layer for EVM ecosystems. Reactive Network supports a bunch of use cases that can be built on top of it. We were involved in auditing their Reactive Bridge.

Reactive Bridge is a cross-chain token bridging solution that connects the Ethereum network to the Reactive Network. It enables seamless and secure transfers of tokens, specifically converting native ETH on Reactive Network into WREACT tokens on Ethereum and vice versa.
 

The architecture involves:

• A Bridge contract on Ethereum for minting/burning WREACT.
• A ReactiveBridge contract on the Reactive Network for handling ETH transfers.
• Multi-confirmation logic, cross-chain message states, retry mechanisms, and safety features to mitigate fraud and stuck transactions.
   

Its design includes various core components:

• AbstractBridgehead: Manages message states and transitions.
• AbstractDispenser: Handles ETH and token withdrawals securely.
• AbstractCallback & AbstractReactive: Ensures secure cross-chain messaging and validation.
• Utility contracts like BridgeLib and extended IERC20ForciblyMintableBurnable for WREACT operations.
   

Our Audit Process

Two highly experienced auditors from our team dedicated themselves to the Reactive Bridge Smart Contract audit for nearly 7 days.

1. Information Gathering

• Collected and reviewed all relevant documentation, including whitepaper, technical specifications, and design documents.
• Obtained a clear understanding of the Reactive Bridge Smart Contracts functionality and intended user interactions.
• Discussed client concerns and specific areas of focus for the audit.
   

2. Manual Code Review

• Conducted a line-by-line review of the smart contract code, focusing on:
  • Vulnerability identification: Searching for known vulnerabilities like reentrancy, front-running, integer overflows, access control issues, etc.
  • Logic flaws: Identifying inconsistencies or unintended behaviors in the code logic.
     

3. Functional Testing

• Developed and executed a comprehensive set of test cases covering various user interactions and edge cases.
• Leveraged tools like Hardhat and Ganache to deploy and test the smart contract locally.
   

4. Reporting & Remediation

• Prepared a detailed report outlining all identified vulnerabilities, categorized by severity and potential impact.
• Provided clear recommendations for fixing each vulnerability, including code snippets and best practices.
• Collaborated with the Reactive Bridge team to prioritize and address the identified issues.
• Conducted additional verification testing after vulnerability fixes were implemented.
   

Comprehensive Audit Discoveries

Here are the key bugs we uncovered and their implications:

1. Incorrect Event Subscription Leading to Unprocessed Failed Transactions

Description: The ReactiveBridge contract's event subscription mechanism contained a critical flaw where the FAILED_TOPIC events were not properly subscribed to. Instead, another topic (likely REJECTION_TOPIC) was inadvertently subscribed to twice, creating a blind spot in the system's ability to detect and process failed transactions.

Impact: When a transaction fails on the destination chain, the bridge emits a FAILED_TOPIC event that should trigger recovery mechanisms. Due to the improper subscription configuration, these events are never captured by the bridge, leaving transactions in a permanent "limbo" state.
 

2. Denial of Service via Incorrect Message Status Update in Rejection Handling

Description: The message rejection flow contains a logical error that leads to transaction failures. Specifically, the _processRejection function changes a message's status to MessageStatus.REJECTED before calling _rejectDelivery(), which requires the message status to be MessageStatus.DELIVERING. This state inconsistency causes all rejection processing to revert.

Impact: When a rejection needs to be processed, the system consistently reverts due to the failed requirement check. This creates a denial-of-service condition, where legitimate rejections cannot be processed, thereby blocking the rejection flow entirely.
 

3. Lack of Bounds on Fees in AbstractFeeCalculator

Description: The fee calculation mechanism in the AbstractFeeCalculator contract lacks bounds on the fixed_fee and perc_fee parameters. Without constraints, these parameters could be set to arbitrarily high values, resulting in excessive fees for users.

Impact: With no upper bounds on fee parameters, transfers may become economically impractical. In extreme cases, the calculated fee might exceed the transfer amount itself, making transactions impossible to execute.
 

4. Lack of Refund Mechanism on Failed Transfers in the Bridge Interaction Scenario

Description: The current implementation lacks a proper refund mechanism when bridges interact directly with each other (BRIDGE ↔ BRIDGE) rather than through the intended BRIDGE ↔ RNBRIDGE flow. If a transaction fails on the destination bridge, users have no way to recover their funds.

Impact: In bridge-to-bridge interactions, failed transfers result in permanent fund loss since there is no mechanism to detect failures and refund the sender. The system assumes that all transfers will either succeed or be properly handled by the ReactiveBridge, leaving a critical gap in error handling.
 

Conclusion

The Reactive Bridge Smart Contracts security audit identified and addressed several vulnerabilities, protecting user funds and ensuring platform stability.

This case study demonstrates the importance of proactive security measures for blockchain-based projects, especially those dealing with financial assets. By conducting audits and addressing identified issues, the Reactive Team has taken a significant step towards securing its platform and safeguarding user trust.