One finding was classified as medium severity and five as low severity; the audit records five issues as resolved and one as partially resolved, with no critical or high-severity findings reported. For bridge operators and developers, the important signal is not the count alone but the failure mode: validator-set transitions and administrative messages were not given sufficiently strong replay and liveness protections.
The vulnerable state transition
Bridge2 is a custodial USDC bridge deployed on Arbitrum One and connected to TxFlow’s L1. Cross-chain operations are authorized through EIP-712 messages signed by validators, with routine actions requiring a strict greater-than-two-thirds hot-wallet quorum and high-assurance actions requiring a corresponding cold-wallet quorum.
That architecture establishes authorization, but authorization is only one stage in the transaction lifecycle. A signed message must also be bounded by time, sequence, and execution state. According to the audit, signed administrative messages—including locker modifications, parameter changes, and withdrawal invalidations—carried neither an expiration timestamp nor a sequential nonce. Within a single epoch, a valid message could therefore remain usable indefinitely and could be submitted out of order.
The validator-set update path contained a more concrete liveness failure. The updateValidatorSet function constructed a deterministic message from the new epoch, validator addresses, and powers, but did not call checkMessageNotUsed and did not include a nonce in the signed payload. After a valid update transaction was broadcast, its calldata could be copied and submitted again by any third party.
Each repeated submission overwrote the pending validator-set update and refreshed both updateTime and updateBlockNumber. Because finalization checks the dispute period against those values, the same update could be replayed indefinitely, continuously resetting the waiting window. The result was not an unauthorized validator-set change; it was a failure of progress. Finalization could be prevented, leaving the emergency-unlock route as the mechanism through which the transition would have to be forced.
What bridge teams should verify
The practical review target is the complete state machine, not merely the signature verifier. For every signed operation, operators should establish whether the payload contains a unique sequence value, an epoch binding, an expiration condition, and an on-chain record proving that the message has already been consumed. A valid signature without replay protection is authentication without execution discipline.
Validator-set transitions deserve a separate sequence diagram:
1. The active hot-validator set signs the incoming validator set.
2. The update enters a dispute period.
3. The contract stores the pending update and its timing markers.
4. A finalizer attempts to complete the transition.
5. Any repeated submission must be rejected rather than rewriting the pending state.
The fourth and fifth steps are where liveness guarantees are determined. If a third party can replay an already broadcast update and reset the dispute clock, the protocol’s Byzantine fault-tolerance model is incomplete: quorum may prevent unauthorized state, but it does not guarantee that legitimate state can eventually become final.
The audit also describes a pause mechanism in which designated lockers vote to halt the bridge, while a cold-wallet quorum can restore operation by rotating the validator set, clearing outstanding locker votes, and unpausing the contract. That recovery path should be tested as a coordinated state transition, including the interaction between pending updates, dispute windows, locker votes, and emergency unlocks.
The broader bridge threat model remains visible in recent incidents. KuCoin reported that Allbridge suffered an approximately $190,000 theft after forged CCTP-style messages bypassed sender, recipient, and actual-mint validation; the attacker used a flash loan to inflate the router balance before withdrawing nearly 999,000 USDC. The specific contracts differ, but the architectural lesson is shared: message authenticity does not by itself prove that the underlying asset movement occurred.
The binary assessment
TxFlow’s Bridge2 audit does not describe a critical or high-severity finding in the supplied report, and the reported issues are not equivalent to a demonstrated exploit. It does, however, expose a protocol that can authenticate validator operations while permitting replay-driven obstruction of validator-set finalization.
For integrators, the binary question is whether the deployed implementation has the audited behavior or the corresponding fixes: if signed updates are uniquely consumable and dispute timers cannot be refreshed through replay, the liveness defect is bounded; if not, the bridge’s emergency path is part of its normal security model, not merely a contingency.
The surrounding news cycle also contains unrelated material, including Pitchfork’s rare zero-score review of Tyga’s “$TARFACE”, which should not be mistaken for evidence about cross-chain infrastructure.