Transparency Report 20: Avail Bridge Wrapped Transaction Safety Fix

Governance V1 Avail Transparency Report
1

Report Author: Toufeeq [5CoVaWrZnaV3BSeUJCA8Ca3SPMJDtjT1zPvZkzovkxJU7dkr]

Execution Details: Changes have been applied at block #2920735

Technical Committee Consensus: 5/7 signers Subscan | Aggregate Substrate ecological network high-precision Web3 explorer

Introduction

This report aims to provide transparency to the Avail community regarding an emergency proposal that has been executed on Avail Mainnet. The Avail Technical Committee (TC) approved a runtime upgrade to address a bridge transaction handling issue involving wrapped Vector::send_message calls.

The issue affected bridge send transactions submitted inside call wrappers such as Proxy, Multisig, Scheduler, or Utility batch calls. The runtime upgrade ensures that bridge messages are generated only from direct bridge send transactions, and that wrapped bridge send transactions are rejected during transaction validation.

The TC chose the emergency proposal path for this upgrade because the issue affected the safety of bridge transactions. Waiting through the normal proposal execution delay would have prolonged the period in which wrapped bridge transactions could create unsafe bridge behavior or stuck user funds. The emergency execution allowed the fix to be applied promptly, while this ATR provides post-execution transparency to the community.

Executed changes

This upgrade changed the runtime bridge filtering and transaction validation rules for Avail bridge send transactions.

After the upgrade:

  • Direct Vector::send_message bridge transactions continue to work as expected.
  • Wrapped bridge send transactions are rejected.
  • Normal non-bridge Proxy, Multisig, Scheduler, and Utility batch transactions continue to work as expected.

Code Modifications:

For those interested, you can review the necessary code modifications in the following PR:

PR1

Potential Merits to the Network:

This change improves bridge safety by ensuring bridge data is derived only from supported direct bridge transactions. Previously, wrapped bridge transactions could create an unsafe mismatch between transaction structure and actual execution. In some wrapper cases, an inner bridge call may not execute, while the bridge filter could still interpret the transaction as bridge data.

The upgrade removes this unsafe behaviour by disallowing wrapped bridge sends and keeping bridge proof generation aligned with direct Vector::send_message execution. This helps protect users from stuck bridge transfers and strengthens the integrity of Avail-to-Ethereum bridge message generation.

If you have any questions, feel free to share them on the forum.

Thank you.