Intent-Based Transactions

Execution & Parameters

Intent-Based Transactions (IBTs) are the mechanism by which a user expresses a desired outcome — not a specific sequence of on-chain steps — and delegates the work of finding an execution path to a solver. This chapter covers the declarative constraint format, the solver/sequencer division of labor, and the full execution lifecycle.

1. Declarative Constraint Format

An intent's action field (see Optim Account Mechanisms) is one of a fixed set of declarative constraint types. Each type specifies an outcome, with the specific execution path left open for a solver to fill in:

Constraint Type	User Specifies	Solver Determines
Limit Order	Target price, asset pair, expiry	Which pool/counterparty fills it, and when
Gas Sponsorship	Willingness for a third party to cover fees	Which sponsor, and the OADA/fee settlement path
Delegation	Authority scope (e.g., DAO vote, trade execution)	The specific transaction(s) exercising that authority
Transaction Batching	Set of desired actions to consolidate	Optimal batching/ordering to minimize fees
Aggregation	Desired trade, no venue specified	Best price across available DEXs
Execution-Path Flexibility	Target smart contract function + outcome	The specific call path/route to reach it

type IntentAction {
  LimitOrder { pair: AssetPair, target_price: Rational, expiry: Int }
  GasSponsorship { max_fee: Value }
  Delegate { scope: DelegationScope }
  Batch(List<IntentAction>)
  Aggregate { sell: Asset, buy_min: Asset }
  ExecutionTarget { target: ScriptHash, outcome: Data }
}

The key design property: the validator that ultimately checks a solver-constructed transaction never needs to understand solving strategy. It only needs to check that the outcome the solver produced satisfies the constraint the user declared — price at or better than target_price, fee at or below max_fee, output matching buy_min, etc. This keeps solver competition (an off-chain, economically-driven process) fully decoupled from on-chain validation correctness.

2. Solver Responsibilities

A solver is any actor — permissionless, competing on execution quality — that:

1. Monitors the intent-discovery channel where structured, authenticated intents are broadcast (post Optim Account processing).

2. Constructs a concrete Cardano transaction (or Guaranteed Transaction chain step) that would satisfy the intent's declared constraint.

3. Submits that transaction to the sequencer network for ordering/inclusion.

Solvers do not have any special on-chain privilege — a solver-constructed transaction is checked by exactly the same validator logic (constraint satisfaction, signature/consent scope from Account Abstraction §4, chain-continuity rules from Modular Design Patterns §2) as any other transaction. This is what allows an RFQ-style "solvers compete to provide optimized execution paths" market to exist without introducing a new trust assumption: a losing or malicious solver's transaction simply fails validation or loses the ordering race, it can never produce an invalidly accepted outcome.

3. Execution Lifecycle

 1. Intent authoring       user's wallet composes a declarative IntentAction
 2. Structuring            Optim Account normalizes to canonical form
 3. Authentication         signature verified against account + consent scope
 4. Intent discovery       authorized intent broadcast to the solver market
 5. Solving                solver(s) construct a candidate satisfying transaction
 6. Sequencing             sequencer network orders/batches/compresses candidates
 7. Initial verification   sequencer performs preliminary constraint + validity check
 8. Chain extension        transaction becomes link N (or N+1...) in a Guaranteed Tx chain
 9. Gas settlement         OADA fee deducted per the account's fee-authorization scope
10. Execution & finality   instant finality at sequencer-agreement time
11. L1 settlement          chain checkpoints to Cardano per SR-6 bound / voluntary checkpoint

Steps 1–3 are covered in depth in Optim Account Mechanisms; this chapter focuses on 4–10.

4. Intent Discovery

Intent discovery is a publish step, not itself a validated on-chain action — an authenticated intent is broadcast (e.g., over a sequencer-network gossip channel or public mempool-analogue) so that any solver can see it and compete to fulfill it. Because the intent was already authenticated in step 3, discovery does not need to re-establish trust; it only needs to establish visibility. Intent broadcast should include enough of the constraint (but not necessarily the full signed payload, depending on privacy requirements) for solvers to evaluate whether they can profitably fulfill it, without leaking information that would let a solver front-run the user ahead of a competing solver's fill.

5. Constraint Satisfaction Checking (On-Chain)

Every declarative constraint type has a corresponding, mechanical satisfaction check the validator applies to whatever concrete transaction a solver produced:

pub fn satisfies(constraint: IntentAction, tx: Transaction) -> Bool {
  when constraint is {
    LimitOrder { pair, target_price, expiry } ->
      and {
        current_oracle_time() <= expiry,
        realized_price(tx, pair) <= target_price,  // or >=, direction-dependent
      }
    GasSponsorship { max_fee } ->
      fee_paid_by_sponsor(tx) <= max_fee
    Aggregate { sell, buy_min } ->
      asset_delivered(tx, sell.policy) >= buy_min.quantity
    // ...
  }
}

This function is deliberately the only place solving-strategy-agnostic correctness lives — it must hold regardless of which solver, which venue, or which specific route was used.

6. Gas Parameters and OADA

All IBT execution settles fees in OADA, Leviathan's native gas-payment currency, rather than ADA directly. Two execution-relevant parameters flow from this:

• Fee predictability: because OADA gas pricing is decoupled from ADA's staking-driven supply dynamics, a solver can quote a fee for fulfilling an intent without exposure to L1 fee-market volatility between solving and settlement.

• Sponsorship compatibility: GasSponsorship constraints are only meaningful because gas is a fungible, account-abstraction-compatible token rather than a protocol-level ADA deduction tied to the submitting key — this is what allows a third party (a dApp, a solver, a sponsor) to cover a user's gas without needing custody of that user's ADA.

7. Batching and Compression Parameters

At the sequencer layer (step 6), multiple solver-submitted transactions satisfying independent intents are compressed into a single more compact structure before touching L1. Batching parameters relevant to solvers and integrators:

• Compatibility grouping: only transactions with non-overlapping input sets (or ones forming a valid extension chain) can be batched together — a solver targeting the same account/UTxO as another concurrently-solving transaction will lose the ordering race, not be silently merged.

• Compression is a data-layout optimization, not a semantic one: it reduces L1 block-space consumption but must not change which individual transaction's constraint-satisfaction check applies to which output — per SR-3/SR-4 discipline, each batched transaction's own correlation data must remain independently verifiable post-compression.

8. Failure Modes and Re-Solving

If a solver's candidate transaction fails initial verification (step 7) — because a competing solver's transaction already consumed the relevant input, or because the constraint is no longer satisfiable (price moved outside target_price before inclusion) — the intent is not lost: it remains valid (subject to its expiry) and re-enters the solver market for another attempt. This retry path is why intents, not raw transactions, are the unit of user commitment: a failed solving attempt costs the solver, not the user, consistent with the broader protocol principle that liveness failures should not become safety or fund-custody failures.