Pre-Flight Simulation

Simulation is not optional. Every payment simulates before it executes.

This is the decision that costs a small amount of latency and saves a meaningful amount of failed transfers. Most routing systems skip simulation because it adds a step. We include it because the alternative is sending real money into a route that was going to fail.

Here is what simulation actually checks.

Liquidity depth at your exact amount. A DEX might have enough liquidity to swap $100 of ETH to USDC but not enough to swap $50,000 without catastrophic slippage. Simulation checks depth at the real amount, not a sample.

Real slippage estimation. The difference between quoted price and execution price. Simulation calculates this against actual pool state at the moment of the check, not theoretical slippage from a formula.

Off-ramp partner availability. The engine pings the off-ramp partner API to confirm they are currently accepting transfers to that corridor. Partners occasionally pause specific corridors for liquidity rebalancing. Simulation catches this before funds move.

Compliance pre-check. The compliance engine runs in simulation mode. If the transfer would be blocked - sanctioned corridor, blocked address, limit exceeded - simulation returns that result immediately. Nothing moves.

Expected output vs minimum. If the expected output after all fees and slippage is below the user's stated minimum, simulation fails and execution does not begin. The user sees exactly what went wrong and what the actual expected output would have been.

If simulation passes, the engine proceeds with high confidence. Not certainty - on-chain state can change between simulation and execution - but enough confidence that the success rate on post-simulation payments is significantly higher than on unsimulated payments.