Intents and Solvers

_{1. What is an Intent?}

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.

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:

Clause	Role
Outcome invariant	Predicate over the post‑settlement state (“I own ≥ 999 USDC on Base”). This is the success condition and it's non‑negotiable.
Settlement conditions	Verification rules and value exchange. Escrowed assets, rights, or fees are released if a solver presents proof that the invariant holds.

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.”

_{2. Type of Intents}

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.

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

_{3. Why Intents Matter}

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.

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.

_{4. What is a Solver?}

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.

_{5. Solver Specializations}

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

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

_{6. Solver Networks}

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.

_{7. Why Open Solver Markets Matter}

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.