> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flash Intents

> Settle same-chain stablecoin orders atomically using the user's own funds, with fill size bound by the user's balance rather than solver inventory.

A **Flash Intent** is a same-chain routing mode where the solver fulfills the order atomically using the user's own funds instead of fronting its own inventory. The solver operates trustlessly on the user's capital, simulating, splitting, and orchestrating the lowest-cost swap pathway, as long as the intent's exit conditions hold. Because the fill draws on the user's balance rather than the solver's, order size is not capped by solver inventory.

Flash Intents remove the liquidity bottleneck that historically capped large same-chain orders: in the standard configuration, orders only fill when a solver has sufficient liquidity on hand.

## When to use

* Large same-chain stablecoin orders that exceed available solver inventory
* Orders where no direct liquidity match exists and a multi-hop pathway is more efficient
* Same-chain swaps where solvers can offer superior routing logic even without providing liquidity

## How it works

1. The user publishes and funds a same-chain intent (destination equals source), with the [Local Prover](/routes/architecture/provers/local) as the intent's prover.
2. A solver computes the optimal swap pathway. It needs no inventory of its own.
3. The solver triggers `flashFulfill`, a flash-loan-style operation that routes the vault's own funds through the chosen pathway and delivers the outcome within a single atomic transaction.

If the pathway cannot satisfy the intent's exit conditions, the transaction reverts. There is no partial-fill state.

## Standard vs Flash

Both same-chain modes run through the Local Prover; the difference is whose capital fills the order.

| Mode     | Capital source                          | Best for                                                             |
| -------- | --------------------------------------- | -------------------------------------------------------------------- |
| Standard | Solver inventory                        | Direct liquidity match, often the fastest and least expensive fill   |
| Flash    | User's vaulted funds via `flashFulfill` | Larger orders, no direct liquidity match, complex multi-hop pathways |

You don't choose the mode per order. The protocol selects the optimal one based on solver competition and available pathways, the same tiering described in [Settlement vs Orchestration](/routes/architecture/settlement-vs-orchestration).

## Properties

* **Atomic.** The swap either completes end-to-end or it doesn't happen at all. No partial-fill risk.
* **Trustless.** The solver operates on the user's funds only within the constraints encoded in the intent itself.
* **No inventory cap.** Fill size is bound by the user's balance, not the solver's reserves.
* **Same API surface.** Applications integrated with Routes inherit Flash Intents automatically: no contract upgrades, no API migration, no user-facing configuration.

## Integrate

Existing Routes integrations inherit Flash Intents automatically. New integrators can [start with the CLI](/routes/integrate/cli) and issue a same-chain intent, or use the [REST API](/routes/integrate/api). For the underlying mechanism, see the [Local Prover](/routes/architecture/provers/local).