# Intents and Solvers

## <sub>1. What is an Intent?</sub>

An intent is an outcome‑predicated expression over future settlement transactions: a declaration that encodes invariants about state transitions while remaining agnostic to how they are accomplished.&#x20;

Think of it as a goal plus guardrails: what must be true, not the step‑by‑step recipe.

> Analogy: “Get me from NYC to Paris tomorrow in < 8 hours for under $800.” The traveller constrains price, timing, and destination; the planner optimizes the itinerary across airlines, layovers, insurance, and ground transport.

At minimum, every intent carries two clauses:

<table><thead><tr><th width="196.82421875">Clause</th><th>Role</th></tr></thead><tbody><tr><td><strong>Outcome invariant</strong></td><td>Predicate over the post‑settlement state (<em>“I own ≥ 999 USDC on Base”</em>). This is the success condition and it's non‑negotiable.</td></tr><tr><td><strong>Settlement conditions</strong></td><td>Verification rules and value exchange. Escrowed assets, rights, or fees are released if a solver presents proof that the invariant holds.</td></tr></tbody></table>

**Verifiability of an intents is non-optional.** Both the outcome and the author’s guard-rails _must_ be provable against an agreed verification system, otherwise the declaration loses semantic weight. Implicit in every intent is the statement:

> “The outcome **and** constraints are satisfied, according to verification system _X.”_

## <sub>2. Type of Intents</sub>

_Intents are an open-ended design space. The categories below are illustrative examples, not an exhaustive list. Developers can mix, extend, and compose new intent types as the ecosystem evolves._

<table><thead><tr><th width="167.73828125">Category</th><th>Description</th><th>Typical use cases</th></tr></thead><tbody><tr><td><strong>Single‑step intents</strong></td><td>One‑off, atomic outcomes.</td><td>Spot swaps, instant loan repayments</td></tr><tr><td><strong>Service intents</strong></td><td>Off‑chain or hybrid service promises settled with verifiable proofs.</td><td>Cross-chain asset transfer or off-chain data requests</td></tr><tr><td><strong>Long‑running intents</strong></td><td>Persistent on‑chain programs that keep an invariant true over time.</td><td>Market‑making vaults, automated portfolio rebalancing</td></tr><tr><td><strong>Higher‑order intents</strong></td><td>Intents that compose or spawn subordinate intents, enabling hierarchical or conditional workflows.</td><td>Multi‑chain yield farming with auto‑compounding, automated liquidation ladders</td></tr></tbody></table>

## <sub>3. Why Intents Matter</sub>

1. **Outcome-first simplicity:** Intents replace step-by-step transaction choreography with an outcome-first interface. A user specifies the desired end state once - for example, “start with ETH on Chain A and finish with a USDC loan on Chain B.” Khalani’s solver networks then coordinate every approval, gas payment, bridge hop, deposit, and borrow required to reach that outcome, eliminating all manual integrations.
2. **Deterministic settlement guarantees:** Because the intent itself embeds deterministic settlement terms: maximum slippage, fee ceilings, and explicit deadlines, the intent publisher locks in costs and outcome before funds ever move. These guarantees make results predictable and auditable across chains.
3. **Abstraction over Execution:** Intents reduce any workflow to a minimal, deterministic state machine: `PUBLISHED` to either `FILLED` or `CANCELLED`. The transition rules are fixed and self-contained, so the state machine can be proven on any chain using standard cryptographic primitives such as merkle proofs. This makes intent-based cross-chain composition straightforward: an intent can be published on chain A, fulfilled on chain B, and settled on chain C without bespoke proof machinery.&#x20;
4. **Market-driven execution:** Because intents are broadcast to open solver markets, users automatically get best‑price routing or auctions at their chosen latency.
5. **MEV resistance:** Finally, by delegating execution to neutral or incentive-aligned off-chain actors and enforcing deterministic invariants, intents allow orderflow sources to markedly narrow the attack surface for front-running, sandwiching, and other forms of MEV extraction.

## <sub>4. What is a Solver?</sub>

A solver is an off‑chain agent or service that:

1. **Discovers** open intents expressed by users.
2. **Generates** a concrete execution plan that satisfies the intent’s outcome invariants.
3. **Executes** a on-chain transaction that convinces the on-chain settlement program that the user's intents are satisfied.
4. **Receives** payment _only_ if the settlement transaction is accepted.

Put simply, solvers turn “what” into “how”, but are only rewarded when their _how_ is executed and verified as correct.

## <sub>5. Solver Specializations</sub>

_The categories below are illustrative - solvers can combine roles or introduce new specializations as the market evolves._

<table><thead><tr><th width="196.78515625">Specialization</th><th>Core responsibilities</th></tr></thead><tbody><tr><td><strong>Routing solvers</strong></td><td>Scan DEXs, bridges, and rollups to assemble the cheapest, fastest path that meets the intent’s constraints</td></tr><tr><td><strong>Market‑making solvers</strong></td><td>Provide firm quotes and inventory, absorbing order flow or supplying liquidity for RFQs and auctions</td></tr><tr><td><strong>Liquidation solvers</strong></td><td>Monitor lending positions, repay under‑collateralised debt, and atomically seize collateral in line with protocol rules</td></tr><tr><td><strong>Settlement solvers</strong></td><td>Generate or relay cryptographic proofs: light‑client headers, ZK succinct proofs, optimistic attestations that attest state change across domains</td></tr></tbody></table>

## <sub>6. Solver Networks</sub>

Relying on a single solver is brittle. Khalani therefore models _solver networks_: open participation marketplaces where many solvers _compete or collaborate_ under shared rules:

* **Competition** drives best execution based on user expressed preferences.
* **Collaboration** enables partitioned expertise - one solver handles routing, another supplies liquidity, a third generates the ZK proof.

Khalani enforces atomic settlement, so either _all_ sub‑tasks succeed or funds are returned.

## <sub>7. Why Open Solver Markets Matter</sub>

Healthy solver markets behaves like a self-integrating, ever-evolving execution mesh. The advantages below unfold from basic reliability to broader ecosystem resilience.

1. **Liveness & redundancy:** When one solver goes offline or runs out of capacity, peers immediately back-fill its role. This fail-over behavior keeps user intents from stalling and removes single-point-of-failure risk.
2. **Innovation surface:** Because solvers stay off-chain, developers can drop in smarter routing heuristics, AI-driven risk engines, or cutting-edge proof systems without redeploying a single contract. The protocol stays stable while execution layer evolves by itself.
3. **Specialization at scale:** Independent solver teams can focus on routing, liquidity, or proof generation, compounding expertise rather than siloing it inside a single operator.
4. **Transparent price discovery:** Open bidding exposes the full range of quotes and routes, letting users and applications benchmark execution quality in real‑time.
5. **Censorship resistance:** A broad, permissionless solver pool makes it difficult for any single actor to block, delay, or censor user intents.
