MEV and sandwich attacks
Why public-mempool sandwich attacks do not apply to satcap swaps, and which risks remain.
What is a sandwich attack?
On a public-mempool AMM, an attacker can observe a pending buy, buy before it to push up the price, and sell after it. The victim trades at a worse price while the attacker tries to profit. MEV (maximal extractable value) is the broader value that block producers or other actors can extract by including, excluding or reordering transactions.
No swap in the Bitcoin mempool
satcap token buys and sells settle on the platform’s internal BTC ledger, not as individual Bitcoin transactions. A wallet trade approval is a signed authorization sent to satcap; it is not a swap broadcast to Bitcoin’s public mempool. There is no pending on-chain swap for a mempool bot to copy or bracket, and miners cannot use Bitcoin transaction fees to move another satcap swap ahead of yours.
Deposits, Allocate, Return and Withdraw are Bitcoin transactions and still have normal network fees and confirmation delays. They move BTC; they do not execute a token AMM swap in the mempool.
Locked settlement and signed limits
Trade requests pass through a bounded per-market queue on each server instance. The database market lock is the final serialization guard across instances: current reserves, balances, fees and signed minimum output are checked within settlement. A trade is not partially settled while another trade changes the same market.
Your fresh wallet approval binds the trade and its minimum received. If market movement means that minimum cannot be met, settlement rejects the trade. Another trader cannot reuse your approval to change your amount or signed limits.
What this protection does not promise
The public-mempool, miner-ordered sandwich mechanism does not apply to satcap swaps. That is not a guarantee that every form of MEV, front-running or manipulation is impossible. Internal execution depends on the platform: queues do not guarantee a global first-in-first-out order across server instances, and row locks do not prevent separate trades from executing before and after yours.
Leaked pending order information, platform ordering decisions or an attacker anticipating a trade can still create order-flow risks. Other trades can move prices before settlement, and a wide slippage tolerance permits a worse fill within your signed bounds. Price impact, liquidity, custody and availability risks remain. Review the minimum received and use a slippage tolerance you are willing to accept.