Cross-Chain AMP Anti-Front-Running: Time-Locks, VDFs, and Optimistic Queues

Abstract: cross-chain message risk is about execution order, not only verification

Arbitrary Message Passing, or AMP, is often described as “a contract on chain A calling a contract on chain B.” That description hides the dangerous part. Once a source-chain message is visible, the destination chain does not automatically execute it in source-chain time order. Relayers, builders, private RPC endpoints, validators, and MEV searchers may learn enough about the intent before execution and use destination-chain ordering power to front-run, sandwich, or delay the message.

This article studies topic 87: cross-chain AMP anti-front-running based on time-lock puzzles and optimistic queues. The core claim is that cross-chain security cannot stop at proving “this message came from the source chain.” It must also constrain when message contents become visible, when the message enters the destination queue, which ordering rule governs execution, and how refunds work when execution fails. Time-lock puzzles and verifiable delay functions, or VDFs, can reduce the window for early decryption and destination-chain front-running. Optimistic queues can commit cross-chain messages to a disputable order before reveal and execution.

For a non-custodial cross-chain exchange such as [AllSwap](/exchange-swap), users care whether the target-chain asset arrives under the quoted constraints, and whether funds are refundable when execution fails. If destination ordering is manipulated, slippage, arrival time, and refund responsibility can diverge from the quote. Relevant product surfaces include [fees](/fees), [USDT TRC20 swap](/swap/usdt-trc20), [USDT ERC20 swap](/swap/usdt-erc20), and the [TRX asset page](/assets/trx).

1. AMP is not only message delivery; it is destination-chain execution

In an AMP system, a source-chain contract emits a message m containing the destination address, payload, nonce, fee, and execution constraints. A relay layer observes the source-chain event, waits for finality or a confirmation threshold, and submits the message plus proof to the destination chain. The destination contract verifies message origin and then calls the target contract or releases assets.

That path contains at least five clocks:

- the source-chain block and finality clock; - the relayer observation and proof-generation clock; - the destination-chain mempool or private transaction-channel clock; - the destination-chain block-building and ordering clock; - the user's timeout and refund clock.

LayerZero V2 documentation states that a source chain sending a cross-chain message has no knowledge of the destination chain's state or the resources needed to execute there, so execution requirements must be serialized for off-chain infrastructure. [1] Chainlink CCIP treats messages, token transfers, and programmable token transfers as part of one interoperability layer, with a Risk Management Network monitoring abnormal conditions. [2][3] Axelar General Message Passing supports cross-chain function calls and state synchronization. [4] Wormhole messaging similarly lets contracts send and receive messages across chains. [5]

These systems address message authenticity and reachability, but they do not automatically solve destination-chain ordering fairness. A cross-chain swap intent may have locked source-chain funds while destination execution is still exposed to destination mempools, builder ordering, and relayer submission strategy. The security boundary of AMP does not end at message verification. It ends only when destination execution is finalized, failure is attributable, and refunds are enforceable.

2. The attacker exploits time gaps, not broken signatures

A cross-chain front-runner does not need to forge signatures or message proofs. It only needs to observe a sensitive source-chain message and act on the destination chain before the legitimate message executes.

A typical timeline is:

```text T0: the user submits a cross-chain intent and funds or orders are locked on the source chain. T1: a relayer, searcher, or public indexer observes the message content. T2: the attacker predicts the destination execution path and submits a destination-chain transaction. T3: the valid message proof arrives on the destination chain after state has changed. T4: the user receives a worse price, the transaction fails, or a refund path is triggered. ```

Flash Boys 2.0 showed that transaction-ordering dependencies create front-running, reordering, priority gas auctions, and MEV-driven consensus pressure. [6] Cross-chain AMP amplifies the same problem because physical delay exists between source-chain observation and destination-chain execution. The destination-chain attacker does not need to sign faster than the user. It only needs to enter destination ordering before the legitimate cross-chain message.

Cross-chain execution is harder than a single-chain DEX trade. A single-chain transaction at least shares one mempool and one block-ordering domain. A cross-chain message exposes visibility, proof delay, relay policy, and target-chain execution across different systems. A relayer may delay submission because of fees, congestion, or strategy. A builder may prioritize local arbitrage. A private RPC path may leak message content. The attack surface becomes a cross-system timing gap.

That is why AMP anti-front-running cannot be reduced to “relay faster.” Faster relaying becomes an arms race and eventually rewards actors closest to destination builders or private order flow. Protocol design should instead make sensitive payloads unusable before ordering is fixed, or make early exploitation detectable and punishable.

3. Time-lock puzzles and VDFs delay useful information until after ordering

Time-lock puzzles were introduced by Rivest, Shamir, and Wagner as a way to construct information that can only be opened after a sequential computation delay. [7] The mechanism does not rely on a trusted key custodian releasing secrets at the right time. It relies on the difficulty of parallelizing the required computation.

VDFs add efficient public verification to this idea. Boneh, Bonneau, Bünz, and Fisch define a VDF as a function that requires a specified number of sequential steps to evaluate but produces an output that is efficient and public to verify. [8] For cross-chain AMP, the appeal is that delay becomes a verifiable object rather than a relayer promise.

A simplified construction looks like this:

```text payload = Enc_k(message) puzzle = VDFCommit(k, delay = D) packet = {sourceProof, target, payload, puzzle, deadline}

the destination chain first accepts packet into a queue; after D elapses or the VDF output is verified; k is revealed and message is decoded; message executes according to queue order. ```

The goal is not to hide every cross-chain field. Amount ranges, target chain, fees, and recipient constraints may still be needed for risk checks and quoting. The fields worth delaying are the ones that enable front-running: exact target pool, direction, minimum output, strategy parameters, callback path, or liquidation condition.

Time locks are not free. If D is too short, attackers can recover the payload before execution. If D is too long, users absorb unnecessary latency and price risk. VDF verification is cheaper than evaluation, but direct on-chain verification still costs gas. If evaluation or verification is moved off-chain, the protocol must define who submits the result, who can challenge it, and how long the challenge window stays open.

Time locks are therefore a timing defense layer. They do not replace finality checks, message proofs, or refund state machines. They protect the part of a cross-chain message that should not be known before order is fixed.

4. Optimistic queues fix order before reveal and execution

The purpose of an optimistic queue is to replace “whoever gets a transaction into the destination chain first” with “whoever commits a verifiable queue position first.” A minimal state machine is:

```text Submit(packet): verify sourceProof or committee attestation append hash(packet) to queue set status = Pending

Reveal(packet, key): require hash(packet) in queue require delay elapsed or VDF output valid decode payload set status = Revealed

Execute(packet): require status = Revealed require all earlier executable packets handled or timed out call target with payload set status = Executed or Failed

Timeout(packet): if deadline passed and not Executed mark Refundable or Slashable ```

The model has two hard constraints. First, queue order must be verifiable. It may use destination-chain contract nonces, batch Merkle roots, message sequence numbers, or a target-chain timestamp rule, but the evidence must be reproducible. Second, execution cannot block forever. If an earlier message fails because of gas shortage, target contract revert, or missing proof, the queue must be able to skip, mark failure, or trigger refund. Otherwise one bad message can block every message after it.

Themis and Aequitas study fairness in Byzantine message ordering. Aequitas aims to add order-fairness to consensus protocols. Themis gives a strong ordering property in a setting with n >= 4f + 1. [9][10] AMP does not have to adopt these consensus protocols directly, but they show the right direction: fair ordering is not the same as naive first-come-first-served, because different nodes observe messages at different times. A cross-chain system must reason about source-chain order, destination-chain queue order, and disputable evidence.

Optimistic queuing is optimistic because most messages are assumed valid and are not forced through expensive disputes. But the system keeps a challenge window. If a challenger proves that packet content, sourceProof, queue position, or VDF output is invalid, the message is marked failed and the submitter or relayer is penalized. The result is low latency for normal messages and attribution for abnormal ones.

Engineering requires a clean split between queue proofs and refund proofs. A queue proof answers whether a message occupied a fixed position in a destination-chain batch. A refund proof answers whether the message failed to enter `Executed` before the deadline, or entered `Failed` for a refund-eligible reason. These cannot collapse into a single boolean. Otherwise the user only sees “failed” and cannot know whether the relayer failed to submit, the destination execution reverted, the VDF reveal timed out, or the target contract state violated constraints.

In implementation, this split usually means storing at least three commitments rather than one. The first commitment binds the source-chain event and its finality evidence. The second binds the destination queue position, often through a nonce, batch root, or append-only accumulator. The third binds the revealed execution parameters. A refund proof should reference all three: the source message exists, the destination queue position did or did not progress, and the revealed payload either failed under an allowed condition or never became executable. This is more expensive than a single message hash, but it gives the protocol a precise dispute surface. A relayer can be penalized for non-submission, an executor can be penalized for invalid reveal, and the user can be refunded without pretending that all failures have the same cause.

5. Anti-sandwich design must cover builders and relayers

A cross-chain sandwich is not merely slow relaying. An attacker can surround the legitimate destination execution with local transactions: move the pool price first, let the cross-chain message execute against a worse state, then reverse the position. If payload details are public on the source chain, the attacker may not even need to wait for the relayer.

The defense has three layers.

The first layer is payload visibility control. Sensitive fields stay as commitments or ciphertext before queue position is fixed. Time-lock puzzles, VDFs, threshold encryption, and delayed reveal all fit here.

The second layer is execution-window control. The destination contract can require execution within a fixed window after reveal, or require price, state-root, pool-version, and slippage conditions to match the queued commitment. Even after reveal, the attacker should not have unlimited time to wait for the best sandwich state.

The third layer is attribution and refund. If destination-chain state no longer satisfies the user constraint because of ordering manipulation, the system should not force execution. It should move into refund or requote. For the user, “the message eventually executed” is not equivalent to “the original intent was respected.”

PBS and MEV-Boost show that modern block construction has moved transaction ordering from a single validator action into a builder market. [11][12] AMP design must treat that as a fact. If destination execution enters builder-controlled ordering, it faces the local MEV market. A cross-chain protocol cannot assume that the destination chain is naturally neutral.

6. Failure modes: fairness layers create new attack surfaces

The first failure mode is wrong delay calibration. If delay D is too short, attackers can recover payloads before execution. If D is too long, normal users pay unnecessary time and price risk. D should not be a global constant. It should vary by chain pair, asset, order type, destination block time, and historical MEV risk.

The second failure mode is queue blocking. An attacker submits a validly queued message that is guaranteed to fail at execution and sits at the head of the queue. If strict sequential execution is required, all later messages are blocked. The defense is to split status into `Pending`, `Revealed`, `Executable`, `Failed`, and `Refundable`, with timeout-based skipping and explicit failure reasons.

The third failure mode is selective relayer submission. A relayer sees a message that is not profitable or that benefits a competitor, then delays it or submits it through a private channel. Defenses include competing relayers, relayer bonds, delay evidence, and an “anyone can submit” fallback path.

The fourth failure mode is VDF outsourcing centralization. If only a small number of high-performance nodes can solve VDFs on time, the delay layer becomes a new chokepoint. VDF solvers should not receive exclusive execution rights. Result submission and execution rights should be separated.

The fifth failure mode is refund-window mismatch. The source chain may consider a message refundable while the destination chain has already executed, or the destination chain may fail while source-chain funds remain locked. Refunds must bind to message-state proofs, not just to a single-chain clock.

7. Why this matters for AllSwap

AllSwap users do not need to understand AMP internals, but they directly absorb destination-ordering risk. A user may exchange from one chain into a stablecoin on another chain. At quote time, the destination pool is in state A. At execution time, it may be in state B. If the change is normal market movement, slippage controls apply. If it is caused by observing the cross-chain message and front-running it, the system needs timing protection and failure attribution.

A more robust AllSwap cross-chain execution layer can evolve in four steps.

First, make the cross-chain message state machine explicit. Each order should have states such as `SourceLocked`, `QueuedOnTarget`, `Revealed`, `Executed`, `Refundable`, and `Refunded`, so both users and internal systems can locate the failure.

Second, use delayed reveal only where it matters. Not every swap requires a VDF or a time-lock puzzle. Small, low-MEV-risk paths may use ordinary relaying. Large orders, thin-liquidity assets, and destination-chain paths that are easy to sandwich should hide sensitive execution details until ordering is fixed.

Third, separate [fees](/fees) from time risk. Users are not paying one generic cross-chain fee. They are paying source-chain gas, destination execution gas, relayer service cost, possible delay-protection cost, and refund-handling cost. Explaining these components early makes it easier to justify why some paths are more expensive.

Fourth, encode the non-custodial security boundary into product behavior. AllSwap does not need to custody user funds or promise that destination-chain MEV cannot exist. It does need to define when execution happens, when refunds happen, and which failure belongs to which actor. For high-frequency routes such as [USDT TRC20](/swap/usdt-trc20) and [USDT ERC20](/swap/usdt-erc20), transparent state transitions matter more than a vague promise of “instant arrival.”

The quote layer should read these states, not only final outcomes. If a path often stops at `QueuedOnTarget`, the problem may be destination ordering or relay congestion. If it often fails after `Revealed`, the issue is more likely target-contract state, slippage, or execution-window mismatch. Feeding these states back into routing scores makes future quotes reflect real execution risk.

This feedback loop is also how AMP security becomes visible to users without exposing protocol internals. A route can be marked more expensive or slower because its historical queue-to-execute latency is worse, not because the interface vaguely adds a risk premium. That turns timing risk into a measurable routing input for future execution decisions.

8. Open problems

The first open problem is how to price the time-lock parameter. D jointly controls security, latency, and capital efficiency. Different chain pairs, assets, and order sizes require different values, but dynamic D may itself leak risk information to attackers.

The second open problem is where to verify VDFs. On-chain verification is auditable but costs gas. Off-chain verification is cheaper but needs a challenge mechanism. Target-chain precompiles, gas models, and proof costs directly affect the design.

The third open problem is combining fairness with finality. Source-chain order, destination queue order, and destination execution order may conflict. The protocol must define which order wins and how reorgs trigger rollback or refund.

The fourth open problem is the conflict between privacy and recoverability. Payload encryption reduces front-running, but it also makes simulation, risk checks, and failure diagnosis harder. A practical system may need layered disclosure: public constraint summaries and delayed reveal for sensitive execution details.

The fifth open problem is who can punish cross-chain ordering abuse. If the malicious actor is a relayer, bonded penalties can help. If the actor is a destination-chain builder or private RPC provider, the protocol can only defend indirectly through redundant channels, price protection, and refund rules. That boundary must be explicit.

References

[1] LayerZero V2 Message Execution Options, LayerZero Docs, https://docs.layerzero.network/v2/tools/sdks/options

[2] Chainlink CCIP Documentation, Chainlink Docs, https://docs.chain.link/ccip

[3] Chainlink CCIP Risk Management Network, Chainlink Blog, https://blog.chain.link/ccip-risk-management-network/

[4] General Message Passing and How Can It Change Web3, Axelar, https://www.axelar.network/blog/general-message-passing-and-how-can-it-change-web3

[5] Wormhole Cross-Chain Messaging Contracts, Wormhole Docs, https://wormhole.com/docs/products/messaging/tutorials/cross-chain-contracts/

[6] Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges, arXiv, https://arxiv.org/abs/1904.05234

[7] Time-lock puzzles and timed-release Crypto, Rivest, Shamir, Wagner, 1996, https://people.csail.mit.edu/rivest/pubs/RSW96.pdf

[8] Verifiable Delay Functions, Boneh, Bonneau, Bünz, Fisch, IACR ePrint 2018/601, https://eprint.iacr.org/2018/601

[9] Order-Fairness for Byzantine Consensus, Kelkar et al., IACR ePrint 2020/269, https://eprint.iacr.org/2020/269

[10] Themis: Fast, Strong Order-Fairness in Byzantine Consensus, IACR ePrint 2021/1465, https://eprint.iacr.org/2021/1465

[11] Proposer-builder separation, ethereum.org, https://ethereum.org/roadmap/pbs/

[12] MEV-Boost Overview, Flashbots Docs, https://docs.flashbots.net/flashbots-mev-boost/introduction