Same-block swap bundling combines swaps witnessed in one block before executing them against a pool, removing the profit that depends on getting ahead of a particular swap in that batch. The protection applies to swaps that share a pool, direction and execution block; it does not guarantee a price or shield a trade from later market moves.
What does the bundle combine?
In Chainflip’s Just-In-Time AMM, deposits are witnessed on the State Chain, then eligible swaps are grouped by pool and direction for execution. Each group of buys or sells is treated as one larger swap, rather than a sequence whose members can be reordered to favour a frontrunner.
- Same pool: swaps must touch the same liquidity pool to share a bundle.
- Same direction: buys and sells are grouped separately.
- Same execution block: deposits witnessed in different blocks are not part of the same batch.
- Same batch price: a trader joining the group cannot secure an earlier position against a target swap.
Execution order is deterministic at the pool level: sells are processed before buys. Within each direction, the pool executes the combined amount against available range and limit liquidity. This reduces the need for liquidity providers to calculate a separate quote for every incoming transaction.
For example, suppose two traders each sell BTC into the BTC-USDC pool in one execution block. The pool treats them as a larger BTC sell, so a searcher cannot insert a separate sell ahead of the first trader and buy back after that trader moves the price. The searcher gets the batch’s price too, and the added trade may worsen the combined execution rather than earn a sandwich spread.
Why does external transaction order stop deciding the outcome?
The deposit becomes executable only after validators witness it on the State Chain, so execution is delayed while the source-chain transaction gains confirmations. Anyone can observe deposits on a public chain during that delay, but seeing the trade early does not create a useful ordering advantage inside its eventual batch.
Chainflip’s State Chain processes liquidity updates before swaps, then runs swaps in the protocol’s defined order. A market maker can respond to visible upcoming flow by submitting a competitive maker-only limit order; a searcher cannot win by paying to place a swap immediately before the target. The competition shifts from transaction priority to the price liquidity providers are willing to quote.
This is the relevant distinction when choosing a route for a time-sensitive trade: a native-asset swap can still face market risk while it waits for confirmation, but the target’s position in its source-chain block does not determine whether a searcher gets a better fill. For the cross-chain swap itself, the Chainflip swap is one way to move native assets without adding a wrapped-token hop; check the minimum acceptable price and refund terms before sending funds.
What risks does bundling leave in place?
Bundling limits ordering-based frontrunning; it does not remove price impact, oracle deviation or liquidity risk. A batch can be large enough to consume the best quotes, and multiple same-direction swaps increase the total amount the pool must fill. Liquidity providers may quote less aggressively when they expect a large imbalance.
There is also a timing trade-off. The protocol waits for chain-specific confirmations before witnessing a deposit, then gives liquidity providers time to update their quotes. As a rough illustration, the protocol’s swapping example uses three Bitcoin confirmations—about 30 minutes—before State Chain execution; actual timing depends on the source chain and its confirmation policy. The market can move during that interval even though a frontrunner cannot profit from transaction order within the eventual batch.
For slippage protection, set a minimum accepted price or, where supported, a maximum deviation from the oracle price. If the swap cannot meet its protection during its retry window, it can be refunded; that means protection can trade execution certainty for a failed or delayed swap. For a large order, compare its size with available pool liquidity and consider a slower split execution if the application supports it.
When is the protection useful, and what should you check?
It is most useful when your concern is a bot copying your visible deposit and jumping ahead of it in the same pool. It is less decisive when the main risk is a thin pool, a fast-moving market, or a long confirmation delay: those affect the attainable price without relying on transaction reordering.
Before depositing, confirm the source and destination assets, the refund address, the minimum-price condition and the estimated confirmation path. If the route crosses multiple pools, each leg is executed in sequence—often in the same State Chain block—so the final result depends on liquidity and price conditions for every leg, not only the first one.
Same-block bundling removes the usual front-run-before, sell-after ordering edge for swaps in the same pool and direction. It does not promise a fixed quote: use price limits for unacceptable outcomes, and treat confirmation time and pool depth as the remaining decision points.