Open Intent Framework (OIF)

Enable cross-chain intent-based settlement where users express desired outcomes and permissionless solvers compete to execute them across chains. The framework separates user intent (what) from execution strategy (how) and plugs into external settlement, oracle, and messaging layers.

Works best when

  • Cross-chain settlement is needed.
  • Intent-based execution is preferred over step-by-step transactions.
  • Permissionless solver participation is desired.

Avoid when

  • Single-chain operations are sufficient.
  • Transaction privacy is required; intents are visible to solvers by default.

I2I vs I2U — context differences

Institution to institution

I2I

Intents broadcast assets, chains, amounts, and deadlines to the solver network, exposing institutional trading strategy to competing solvers. Institutions may need permissioned solver sets or encrypted intents to protect order flow.

Institution to end user

I2U

Unencrypted user intents are a clear front-running vector against retail order flow. A user-facing deployment must combine OIF with encrypted or committed intents and a sealed-bid auction before the intent becomes visible.

Components

  • Intent contracts: input-collection and output-delivery entry points that escrow user assets, record intent parameters, and release funds on proof of fulfilment.
  • Solver: off-chain service that indexes intents, computes execution routes (swaps, bridges, liquidity routing), and submits fulfilment transactions.
  • Cross-chain messaging layer: transports proofs of fulfilment between origin and destination chains.
  • Oracle or proof mechanism: verifies that outputs have been delivered before the origin contract releases inputs.
  • Settlement module: finalises the intent and handles refund or cancellation on failure.

Protocol

  1. user Sign and submit an intent (for example, sell X on chain A, receive Y on chain B) to the origin contract.
  2. contract Record the intent and escrow the input asset.
  3. operator Solvers monitor the contracts, index new intents, and compute candidate execution routes across chains and liquidity sources.
  4. operator The selected solver executes the required cross-chain operations: swaps, bridging, and destination-chain transfers.
  5. contract The oracle or proof mechanism verifies that the output has been delivered per the intent.
  6. contract The settlement module marks the intent complete and releases locked inputs to the solver; on failure or missed deadline, it refunds or cancels per the configured policy.

Guarantees & threat model

Guarantees:

  • Permissionless execution: any solver meeting the protocol can participate.
  • Modularity: settlement, oracle, and messaging layers can be swapped while keeping the intent-based front-end.
  • Intent-level abstraction: users focus on outcomes; solvers deal with routing and bridging complexity.

Threat model:

  • Intent visibility exposes order flow to MEV and strategy leakage during solver discovery.
  • Cross-chain atomicity is approximated via escrow and settlement logic; it is not guaranteed at the protocol level and depends on the chosen messaging and settlement modules.
  • Oracle and messaging failures can stall withdrawals or cause disputed fulfilment. Escrow and resource-locking design must bound the blast radius.
  • Solver liveness: if no solver picks up an intent, the user falls back to cancellation or refund flows.

Trade-offs

  • Solver network must be active and sufficiently liquid for timely fulfilment.
  • Cross-chain flows inherently carry higher latency and more failure modes than single-chain transactions.
  • Multi-step settlement increases the attack surface (messaging proofs, oracle delays, bridge compromise).
  • Intent visibility is a systemic drawback: strategy leakage and front-running are the price of permissionless solver competition.

Example

  • A corporate treasury submits the intent "transfer 5 M USDC on Ethereum, receive 5 M USDT on Arbitrum".
  • The solver network indexes the intent and computes an execution path (bridge USDC to Arbitrum, swap to USDT).
  • The winning solver executes the steps: USDC is moved, USDT is delivered to the treasury's destination address.
  • The settlement layer verifies delivery, the origin contract releases escrowed funds to the solver, and the intent is marked complete.
  • On failure or missed deadline, the fallback mechanism refunds the treasury.

See also

Open-source implementations