Cross-chain message replay on a second destination

An Endpoint on each chain assigns nonces to outgoing messages and records delivered ones. The AttestationVerifier recovers attester signatures over the message digest and checks the threshold; the VerifierRegistry tells the endpoint which verifier an application uses; the Executor submits verified messages, subject to a per-asset outflow limiter.

The boundary that matters in this case is the digest: whatever it does not include, the attesters never approved.

On 22 July 2026 the cross-chain replay rule raised a critical alert: the digest of message 48211, a 206,000 axUSD transfer from Optimism delivered on Avalanche the previous evening, had just been accepted by the Arbitrum endpoint. Ninety seconds later a second Avalanche message, 48202, was replayed the same way, and axUSD outflows on Arbitrum reached 118% of the window limit.

Both messages had been sent by the same account, from Optimism to its own address on Avalanche. Relaying the attestations to Arbitrum credited it a second time.

The response had to stop further replays, establish whether attester keys were compromised or the protocol was accepting signatures it should not, and identify every message that was exposed.

The investigation listed every input the destination endpoint trusted when accepting a message.

The first question was whether the attesters had signed anything unusual. They had not: the signatures accepted on Arbitrum were byte-for-byte the signatures produced for the Avalanche deliveries. The sender had simply relayed its own delivered messages to another endpoint.

Rebuilding the v1 digest showed why that worked. It hashed the source chain ID, nonce, sender, receiver and payload. The destination chain was carried in the payload envelope but not in the signed digest, and each endpoint recorded only the digests it had delivered itself.

Because axUSD has the same address on Avalanche and Arbitrum, the Arbitrum endpoint resolved the same receiver, the registry returned the same verifier, and the threshold check passed. Any attested message to an application deployed on more than one destination could be replayed once on each of the others.

Operations paused the executor on Arbitrum seven minutes after the first alert. Fourteen further replay attempts against other Avalanche deliveries reverted while it was paused. A scan of earlier deliveries found no replays before 22 July.

During the incident the replay is modelled as an open critical finding, and Operational Security is reduced for the alert-only limiter. Axeline still carries open items from its research assessment, so the after state is its current profile rather than a perfect score.

Verifier v2 signs EIP-712 typed data. The domain binds the destination chain ID and the destination endpoint, the message struct repeats the destination fields, and the endpoint rejects messages not addressed to block.chainid. v2 became the default for every application on the afternoon of the incident.

Delivery resumed the next morning once every receiver was confirmed on v2. The outflow limiter now blocks rather than alerts, and axUSD added its own destination check as defence in depth.

Two replays succeeded before containment, releasing 412,000 axUSD on Arbitrum. No further replay succeeded, no attester key was compromised, and the replayed amount was reconciled against the axUSD supply accounting on both chains.

The cross-chain replay rule and the outflow rule remain in the monitoring rule set, and the limiter now blocks at its window limit.