Intent Replication Attack

What are the specific differences between an Intent Replication Attack and an ordinary MEV Sandwich Attack? Which is more dangerous?

Both exploit the visibility of blockchain transactions, but the attack layer and goals are entirely different. MEV Sandwich Attack (short-term, tactical): the attacker spots one of your pending transactions, inserts their own transactions before and after it, makes you fill at a worse price, and profits. Each attack is independent and one-time. Your loss is 'this trade filled X% worse than optimal.' The attacker doesn't need to understand your overall strategy — just identify one profitable transaction. Intent Replication Attack (long-term, strategic): the attacker doesn't target individual transactions but analyzes your Agent's operation history over weeks or months, inferring your complete strategy logic — 'whenever ETH spot-to-futures premium exceeds Y basis points, this Agent executes operation Z.' Once the pattern is learned, the attacker enters before the Agent's trigger conditions are met. The Agent's every trade 'buys the top.' The loss isn't one trade's slippage but the entire strategy's Alpha being completely consumed — the strategy should have earned 10%, but because someone constantly front-runs, you actually earn 1% or even consistently lose. Which is more dangerous: from a single-loss perspective, MEV sandwich is more immediately painful. From a long-term impact perspective, Intent Replication Attack is more lethal — it's hidden, cumulative, and hard to detect (your Agent is still 'running normally,' just with increasingly poor returns, which you might attribute to market conditions rather than being attacked).

How do attackers infer an Agent's strategy from on-chain data? What technical capabilities are required?

The technical feasibility of this attack is higher than most people imagine — because blockchain's design is inherently completely transparent. Data sources needed: your Agent wallet address's on-chain transaction history (all public); market conditions at the time of each transaction (reconstructable from historical price APIs); and the timing patterns of transactions (timestamps, operation interval regularities). All of this data is freely queryable on-chain. The inference method: attackers use machine learning models to analyze historical correlations between 'what market conditions' and 'what operations this address executes.' For example: analyzing 200 past operations finds 'when ETH 4-hour RSI falls below 30 AND Aave USDC rate exceeds 7%, this Agent adds USDC position 100% of the time.' Once this pattern is extracted, the attacker only needs to monitor the same market indicators and enter before the Agent's trigger conditions are met. Technical barriers: Python or similar data analysis capability; on-chain data queries (The Graph, Dune Analytics); and basic ML or statistical analysis knowledge. This is not a high-difficulty attack — anyone with sufficient quantitative analysis background can execute it. The longer and more regular the Agent's on-chain operation history, the easier the strategy inference.

What effective defenses exist against Intent Replication Attacks? Is complete defense possible?

Complete defense is impossible because on-chain transactions are inherently public. But several measures can significantly raise the difficulty of attack. Strategy obfuscation (most important): make Agent operations not entirely driven by deterministic rules — add random elements. For example: after conditions are met, randomly wait 0–60 minutes before executing; change fixed thresholds (RSI < 30) to floating ranges (randomly select a value between RSI 28 and 35); split single large operations into multiple randomly-sized ones executed at different times. This means even if attackers have learned your general strategy logic, they can't precisely predict your entry timing or trade size. Use private RPC: prevent the Agent's transactions from broadcasting to the public mempool, submitting directly to miners via Flashbots Protect or similar private transaction channels. Attackers can't see your pending transactions and can't execute real-time front-runs. But this only protects the 'transaction broadcast' step — it can't hide the on-chain history of already-confirmed transactions. Wallet address rotation: periodically (e.g., monthly) have the Agent switch to a new operations wallet address. The old address's history remains public, but attackers need to re-accumulate new data before building a new strategy inference model — increasing attack cost and time. Cross-chain and cross-protocol diversification: don't concentrate all Agent operations on a few protocols on one chain. Distributing operations across multiple chains and protocols requires attackers to track more addresses and more complex cross-chain logic, significantly raising attack costs.

How do you detect that your Agent is being subjected to an Intent Replication Attack? What signals can you observe?

Intent Replication Attacks are hard to detect directly — unlike MEV sandwiches where 'every transaction has obvious anomalies,' they manifest as long-term, gradual deterioration of strategy returns. But several signals can be monitored. First, fill quality deterioration: observe the gap between Agent trade fill prices and market mid-price when transactions are submitted (slippage). If this gap shows a systematic expanding trend over recent weeks — not just during high-volatility periods but across market conditions — someone may be trading ahead of you and raising your fill cost. Second, anomalous pre-execution trades: analyze whether specific addresses appear repeatedly in the 1–3 blocks before Agent operations, with the same trade direction as the Agent. If you find an address appearing with same-direction trades before most of the Agent's operations, suspect tracking. Third, strategy Alpha decay: compare the Agent strategy's excess return rate in its 'initial period (first 3 months)' vs. 'recent period (last 3 months).' If strategy Alpha persistently declines while your strategy logic hasn't changed and market structure hasn't fundamentally shifted, strategy replication attack probability is high. Fourth, build a 'competitor monitoring' tool that periodically scans all transactions on DEXes/protocols your Agent commonly uses in the N blocks before each Agent operation, computing correlations in direction and timing. This proactive detection can help you identify attack patterns earlier.