Skip to main content
The Engine is ILLA’s protocol-aware orchestration and execution runtime. It takes an approved execution plan and turns it into a coordinated transaction sequence across protocols, chains, and asset types.

​
From plan to execution

The intelligence layer decides what to do. Safety validates that it is safe. The Engine runs it. An approved plan arrives as structured data: an ordered list of steps, each with its target protocol, parameters, dependencies, and expected outputs. The Engine’s job is to execute that plan faithfully, handling the coordination complexity that arises when a single user intent spans multiple protocols and networks. Engine does not reinterpret intent or make autonomous decisions. It follows the contract established during planning, with the verification and signing gates enforced at every write step.

​
Dependency ordering

Financial operations often have inherent dependencies. You cannot deposit into a yield pool until the required bridge transaction completes. You cannot swap unless the withdrawal has settled. The Engine resolves these dependencies from the execution schema. Steps are ordered so that each step’s preconditions are satisfied by the outputs of previous steps. The dependency graph is computed at plan time and enforced at execution time. Where steps are independent (two swaps on different protocols, a balance check alongside a price query), the architecture supports concurrent execution.

​
Step execution

Each write step follows a strict sequence:
  1. Simulate the transaction against current network state.
  2. Verify the simulation result against the original plan intent.
  3. Present a human-readable preview to the user.
  4. Handoff for approval and execution.
  5. Confirm the result.
Read-only steps execute without user interaction. They resolve automatically and feed their outputs into subsequent steps that depend on them.

​
Failure handling

Financial execution cannot silently fail. The Engine implements controlled recovery paths. If a step fails, ILLA does not retry indefinitely or improvise a workaround. The response depends on the failure type: input errors halt immediately, execution errors are retried up to three times. If the failure persists, execution halts and the failure is surfaced to the user with a clear explanation of what happened and what options are available. Partial completion is handled explicitly. If a three-step plan completes steps one and two but fails on step three, the user sees exactly where things stand. Already-executed steps are recorded, and the user can choose to resume, modify, or abandon the remaining steps. Nothing is left in an ambiguous state.

​
Stateless execution

Statelessness is a security property. In a system handling financial execution, stale state is a liability. The Engine treats each execution as self-contained: the approved plan is the complete source of truth for what should happen. Statelessness also enables horizontal scaling. Any instance can handle any request without session affinity.

​
Multi-chain coordination

ILLA operates natively across multiple networks. A single plan can span several, with the Engine coordinating the sequence and managing handoffs between them. Cross-chain operations introduce additional complexity: bridge latency, finality differences between chains, and the possibility that conditions on the destination chain change between plan approval and execution arrival. The Engine coordinates cross-network handoffs, with verification applied at each execution boundary. When funds arrive on the destination chain, conditions are re-verified before the next step proceeds.

​
Protocol routing

The Engine routes transactions through integrated protocols based on the execution plan, respecting partner-specific routing preferences while optimising for execution quality. Protocol and operation selection are determined during planning. Execution-time routing (for example, optimal swap paths) may be resolved at execution for best available pricing. As ILLA’s capability set grows, the Engine’s protocol routing will expand to cover additional financial domains. The execution pattern remains the same: structured plan in, coordinated transactions out. Integrators can scope protocol access to their specific needs. By default, ILLA routes through the full set of integrated protocols for optimal execution. An integrator can restrict to specific protocols, chains, or asset types to match their product’s domain. These preferences are defined at the integration level and enforced at the Engine level.