On 11 June 2026, a user swap on Chainflip settled to the wrong destination address. The cause was a broker node still running an outdated release that pre-dated a fix shipped weeks earlier. This report walks through the background, the specific failure mode that triggered the misattribution, and the steps taken since.
Background
As part of the Chainflip 2.1.0 release, we upgraded to Polkadot SDK v1.18. That upgrade introduced a bug that affected extrinsic status reporting. Some liquidity providers reported seeing errors for submitted extrinsics that had, in fact, been successfully included and executed on-chain.
Our investigation identified the issue as originating from the extrinsic block watcher. The tx_index reported by the Polkadot SDK transaction pool listener was not guaranteed to correspond to the correct extrinsic in the block. As a result, the watcher could reference the wrong extrinsic when extracting events, leading to false error reports even though the original transaction had succeeded.
The issue was rare and only surfaced under specific usage patterns: LPs submitting a high volume of limit order extrinsics within a single block. Other transaction flows were not impacted.
A workaround was implemented in PR #6494, which removes the dependency on the tx_index value reported by the transaction_pool_listener. The extrinsic watcher now uses the submitted extrinsic hash to identify and process the correct transaction. This fix was included in Chainflip release 2.1.16.
Incident on 11 June
During the incident on 11 June, one broker was still running an older version (2.1.13) that did not include this fix. As a result, the previously described extrinsic indexing issue occurred on that node.
In this case, two deposit channel creation extrinsics submitted within the same block were incorrectly associated due to the incorrect tx_index mapping. Due to an unlikely coincidence, the index of one of the extrinsics was not only remapped to a different extrinsic, but specifically to the other deposit channel creation extrinsic. This meant no decoding errors were triggered. Instead, a mixed-up deposit channel ID and address were returned.
As a consequence, the broker frontend displayed deposit channel details that did not correspond to the deposit channel requested by the user.
The user subsequently deposited funds into the incorrectly displayed deposit channel. Those funds were processed and swapped according to the destination details associated with that deposit channel. The swap completed to the destination address associated with that channel rather than the one the depositor had selected.
Resolution
The issue was resolved by upgrading the affected broker to a version containing the fix.
We reviewed the affected flows to ensure that future transaction processing relies on cryptographic extrinsic identification rather than transaction ordering assumptions.
We asked all brokers to upgrade to Chainflip release 2.1.20, which includes the fix and prevents similar issues in the future.
We are working with investigators to contact the parties involved.
Resources
Swap Now - Start swapping native assets
Lend BTC - Borrow against native Bitcoin
Blog - Product updates and announcements
Chainflip Scan - Track swaps and network activity
Website - Explore Chainflip
Find us:
