Axeline Bridge

Attesters sign keccak256(abi.encode(srcChainId, nonce, sender, receiver, keccak256(payload))). The destination chain ID and destination endpoint travel in the message envelope but are not part of the signed hash. Each endpoint records delivered messages by keccak256(abi.encode(srcChainId, nonce)) in its own storage.

A message sent from Optimism to Avalanche is therefore also valid on Arbitrum: the signatures verify, and the Arbitrum endpoint has never seen that (srcChainId, nonce). Many applications deploy receivers at the same address on every chain with deterministic deployment, so the Arbitrum endpoint resolves a real receiver that uses the same verifier.

This is the root cause of the 22 July 2026 incident, in which a release message delivered on Avalanche was replayed on Arbitrum. Every attested message for an application deployed on more than one destination was replayable once on each other destination.

Duplicate execution of any message on each additional chain where the receiver exists, draining receiver liquidity.

Sign EIP-712 typed data whose domain binds the destination chain ID and the destination endpoint as verifyingContract, include source endpoint, destination fields and verifier version in the struct, reject messages not addressed to block.chainid and address(this), and record delivered messages by full typed-data hash.

Fixed on 12 August 2026 and verified. Attesters sign the new typed-data format; property P2 holds on the remediation commit. A scan of the 90 days before the incident found no earlier replays.

When a receiver reverts, the endpoint stores the message hash as failed. Executor.retry(message) can be called by anyone at any time and re-executes the message without checking signatures again, because it was verified on first delivery. Messages have no deadline.

Two problems follow. A message whose meaning depends on time (a limit order, a liquidation, a price-dependent mint) can be executed weeks later under very different conditions, at a time the executor chooses. And because the failed record is keyed by the hash and not tied to the verifier that approved it, a message that was verified under a later-removed verifier configuration remains executable after the application has changed its verifier, which defeats the purpose of rotating away from a compromised configuration.

Execution of stale messages at attacker-chosen times and of messages approved by configurations the application has since revoked.

Add a signed deadline to every message and reject expired deliveries and retries; record the verifier configuration that approved a failed message and require re-verification if it has changed; allow applications to restrict retries.

Partially resolved. An optional deadline field is supported and enforced when set; messages without a deadline and the link between failed messages and verifier configuration remain open.

setVerifier(app, verifier) and setThreshold(app, t) are callable by the application's owner and take effect in the same transaction. The registry accepts any verifier contract and any threshold of at least one, so an owner can configure a 1-of-1 attestation with a key it controls, or a custom verifier that returns true for everything.

Protocol upgrades are behind a 24-hour delay, but application settings are not, and users of an application generally cannot see which verifier it uses. A compromised owner key, or a malicious owner, can switch the verifier and deliver a forged message in one transaction, before any monitoring can react.

Loss of all funds held by the affected application. Other applications are unaffected.

Apply a delay to verifier and threshold changes with an event at proposal time, enforce a minimum threshold (for example three attesters) for the default attestation verifier, allow only verifiers from a reviewed allow-list for applications that opt into a "protected" mode, and expose the configuration in a view function for front ends.

Open. The team plans a two-day delay and a minimum threshold of three attesters.

verify(hash, sigs) loops over the signatures, recovers each signer with ecrecover and increments a counter when the signer is a registered attester. It does not check that signers are distinct. Submitting the same signature t times satisfies a threshold of t with one attester key.

The raw ecrecover call also accepts high-s signatures, so even a distinctness check on signature bytes would not suffice: each ECDSA signature has a second valid form. The check must be on recovered addresses.

This was not the cause of the July incident, in which the replayed signatures were the original, legitimate set, but it reduces the security of every attestation configuration to a single key.

Arbitrary messages for any application using the attestation verifier, with one attester key.

Use OpenZeppelin ECDSA.recover, which rejects malleable signatures, and require recovered signers to be strictly increasing so each attester is counted once.

Fixed and verified; property P3 holds on the remediation commit.

Senders specify gasLimit for the receiver call, but _execute calls the receiver inside try/catch with whatever gas remains and does not check that at least gasLimit was available. Because of the 63/64 rule, an executor can choose a transaction gas limit at which the receiver call runs out of gas while the endpoint still has enough to catch the failure and mark the message failed.

On its own this delays messages. Combined with AX-02, it lets a malicious executor take control of when a message is eventually executed.

Delays for applications and executor-chosen execution timing for failed messages.

Check gasleft() against the sender's gas limit plus a buffer before calling the receiver and revert the whole delivery if it is insufficient.

Open.

On ordered channels the endpoint delivers nonce n only after n - 1 has executed. If a message keeps failing, for example because its payload is invalid for the receiver, every later message on the channel is blocked. Before remediation there was no way to skip a message.

Loss of liveness for the affected channel.

Allow the application owner to skip a failed message after a delay, with an event, and let receivers mark payloads as permanently invalid.

Partially resolved. Application owners can skip the head message; a minimum delay before skipping, and receiver-driven invalidation, are pending.

Removing an attester affects future verification only. A message that was delivered and failed before the removal stays executable through retry, even if the removed attester's signature was needed to meet the threshold. When an attester is removed because its key is suspected to be compromised, messages it helped approve should be reviewed rather than remaining executable.

Narrow window for messages approved by a revoked attester.

Record the attester-set version with failed messages and require re-verification against the current set on retry.

Acknowledged; to be addressed together with the verifier-configuration link in AX-02.

MessageDelivered(srcChainId, nonce) did not include the message hash or destination fields, so monitoring had to decode calldata to compare deliveries across chains. The rule that detected the July incident relied on this decoding.

Slower and more fragile cross-chain monitoring.

Emit the typed-data hash, source and destination fields, with the hash indexed.

Fixed.