DeFi Arbitrage: AMM Math, Gas, Slippage, and MEV Risk

DeFi arbitrage compares prices and exchange rates across automated market makers, order-book protocols, aggregators, lending markets, bridges, and centralized venues. Onchain execution can combine several actions in one transaction, allowing the whole route to succeed or revert together. That atomic property is powerful, but it does not make the trade free of risk. The transaction can be copied, reordered, outbid, delayed, or reverted after consuming resources.

A route should be evaluated from the state that will exist when it executes, not the state observed when it was discovered. Pool reserves change, other transactions enter the block, gas prices move, and private or public order flow affects ordering. The DeFi arbitrage page organizes this problem into pool math, simulation, transaction construction, submission, and post-settlement verification.

Understand the pricing function

Constant-product pools use a relationship commonly summarized as x times y equals k, with fees and implementation details modifying the exact output. Concentrated-liquidity pools distribute capital across price ranges, so effective depth changes as a trade crosses ticks. Stable-swap curves behave differently near their target region. A route finder must use each protocol’s actual math and current state rather than applying one generic slippage estimate.

The quoted price for a tiny trade is not the price for the intended size. The trade moves reserves, and each subsequent leg begins from the output of the previous one. Fees are deducted at each hop. Token decimals, transfer taxes, rebasing behavior, and wrapper conversions can alter amounts. Simulation should calculate exact integer units and minimum outputs, not rounded dashboard prices. A one-unit error can cause a contract call to revert or leave unexpected dust.

Atomic execution changes leg risk

A smart contract can borrow, swap across several pools, repay, and keep the residual in one transaction. If any condition fails, the state changes revert. This reduces the classic problem of one leg filling while another does not. However, it replaces that risk with inclusion and state-transition risk. The transaction may never be included, may execute after the opportunity disappears, or may revert while still incurring gas according to network rules.

Atomicity also requires correct contract logic. Approval handling, callback validation, reentrancy protection, token return values, and access controls matter. The executor should enforce minimum profit after gas, approved protocols and tokens, maximum input, and recipient addresses. It should not accept arbitrary call data from an unconstrained model. Contract code, dependencies, and deployment configuration need review and testing independent of the opportunity detector.

Gas is a random cost and a scheduling signal

Expected profit should be measured in a common numeraire after gas. Gas usage can be estimated by simulation, while the fee per gas depends on network conditions and the chosen inclusion strategy. A route that is attractive at a normal fee may be negative during congestion. If the trade uses a volatile gas token, the conversion price adds uncertainty. Failed attempts and canceled replacement transactions also belong in long-run cost estimates.

The system can set a maximum total fee and decline routes that require aggressive bidding. It can compare expected profit with several fee scenarios rather than one estimate. On some networks, priority mechanisms, local fee markets, or compute limits affect inclusion. A strategy should measure actual inclusion delay and realized fees by route and time of day. Gas is not merely an expense; it is feedback about competition for block space.

MEV changes who captures the opportunity

Maximal extractable value describes value obtained by controlling or influencing transaction inclusion and ordering. A public arbitrage transaction can reveal its route and minimum outputs before confirmation. Other participants may copy it with a higher fee, trade ahead of it, or construct a sandwich around a vulnerable swap. Even when the original transaction reverts, the attempted route can disclose information and consume gas.

Submission choices include the public mempool, private transaction relays, builder channels, and protocol-specific systems. Private submission may reduce visibility but introduces new dependencies and does not guarantee inclusion or confidentiality. The strategy should understand the trust model and failure behavior of each channel. It should also avoid presenting every ordering advantage as benign arbitrage; some behaviors may harm users or raise market-conduct concerns.

Use simulation as a gate, not a guarantee

Transaction simulation checks whether the exact call succeeds on a specified state and reports outputs, gas, and errors. It can reveal allowance failures, insufficient balances, pool limits, and contract reverts. Simulate with the same sender, value, calldata, and access list intended for submission. Record the block identifier and state assumptions so a later result can be compared with what was known.

Simulation is still a snapshot. Pending transactions can change the relevant pools, oracle updates can occur, and a reorganization can alter state. Conservative minimum outputs and profit floors protect against small moves, but broad tolerances invite adverse execution. Routes should expire quickly, and the detector should resimulate when the reference state changes materially. The executor must refuse stale signed transactions even if a queue delivers them later.

Flash liquidity is leverage, not free capital

Flash loans and flash swaps allow assets to be borrowed and repaid within one transaction. They can remove the need to pre-fund the gross trade amount, but they do not remove fees, contract risk, or competition. The route must produce enough output to repay principal and fee under the executed state. A larger flash amount can increase price impact faster than gross profit, so optimal size is constrained by the curves of all legs.

Reliance on a flash-liquidity provider adds protocol and availability risk. Caps, pauses, fee changes, and callback rules can invalidate routes. A robust contract verifies the caller and asset amounts, limits the protocols it touches, and sends residual funds to a controlled address. Tests should include zero profit, negative profit, partial token behavior, and malicious callback attempts. The system should never rely on a reverted transaction as its only safety mechanism.

Bridges break the atomic boundary

Cross-chain price differences can be large because capital and information move slowly between networks. But a bridge transfer usually settles asynchronously, so the full route cannot be atomic. Finality assumptions, relayers, validator sets, liquidity providers, message verification, and destination execution all add risk. A transfer can complete after the price difference disappears or become delayed during a security incident.

Pre-funded inventory on each chain can support near-simultaneous local trades, with bridging handled later as rebalancing. That resembles multi-exchange inventory management and requires chain-specific limits. A wrapped asset should be evaluated for redemption and bridge risk, not treated as identical to its origin asset. The expected edge should compensate for rebalancing cost and the probability that capital remains trapped.

Protect against token and contract edge cases

Not every token follows the most common transfer behavior. Fee-on-transfer tokens, rebasing tokens, pausable contracts, blacklists, upgradeable proxies, honeypot logic, and unusual decimal implementations can break routing assumptions. A token allowlist should be based on verified contract identity and known behavior. Static analysis, fork tests, and small bounded transactions can provide evidence, but they cannot eliminate governance or upgrade risk.

Protocol integrations require similar controls. Router upgrades, pool factories, oracle dependencies, and emergency pauses should be monitored. Approval amounts can be limited and revoked. The executor contract should expose pause controls and event logs, and private keys should be isolated. A strategy that finds a positive route through an unreviewed contract has found a security review task, not an executable opportunity.

Measure realized onchain performance

Post-trade analysis should track detection time, simulation state, submission channel, inclusion block, executed outputs, gas used, fee paid, revert reason, and final profit. Compare expected and realized reserves to identify competition or modeling error. Include reverted and displaced attempts in strategy economics. Reporting only successful transactions systematically overstates performance.

The external reference for transaction-ordering concepts is the Ethereum.org documentation on maximal extractable value. Network mechanics and protocol behavior evolve, so implementation should rely on current primary documentation and independent security review. DeFi arbitrage can make settlement programmable, but the durable edge comes from exact math, conservative simulation, secure contracts, and honest accounting for every failed attempt.