Skip to main content
Financial actions are high-value but dangerous to get wrong. Every design decision starts from one premise: financial actions are irreversible, and AI systems are probabilistic. ILLA’s architecture is built to reconcile that tension.

​
Plan, then execute

ILLA maintains an architectural separation between planning and execution. The intelligence layer is used to produce a plan. Once that plan is approved, no further probabilistic decision-making occurs anywhere in the execution path. The plan is a deterministic contract between what the user approved and what the system will execute. This separation is the foundation that other safety mechanisms build on.

​
Simulation and verification

Once a plan is approved, each write step follows the same sequence: simulate, verify, present for execution. ILLA encourages human oversight because trust in agentic finance is earned, not assumed. As trust is established, the approval surface is configurable. The approval surface is defined by the integration. ILLA provides structured simulation data and approval checkpoints; the integrator determines which actions require explicit confirmation and which resolve automatically. Transactions are simulated before the user is asked to sign. The simulation produces structured outcome data — which assets move, how much, to where, at what cost — presented by the integration layer as a clear, human readable preview. After simulation the result is presented alongside the original intent, allowing verification that the outcome matches the request. If the planned outcome and the simulated result diverge, the user is presented with a clear decision: continue, modify, or stop.

​
Approval and signing

ILLA never holds private keys or custodies assets. Transaction signing is always controlled by the user’s wallet. ILLA produces ready-to-sign transaction data and hands off to the wallet for approval and execution. ILLA’s architecture supports session-scoped signing delegation through smart wallets — bounded, revocable authority for flows where step-by-step confirmation creates friction.

​
Stateless core

Each request stands on its own, evaluated against current conditions. No session bleed nor cross-request contamination. The stateless core reduces attack surface, with no shared session state to compromise. User context, identity, and preferences persist across sessions through Hub. The safety evaluation path does not.

​
Policies and controls

Safety configuration is per-integration. Every ILLA instance operates under a set of policies that define the boundaries of what the system can do. Contract and address scoping. Execution is bounded to ILLA’s integrated protocol set, as scoped by the integrator. Transactions route only through vetted, approved protocol contracts. The AI layer cannot reach outside this boundary. Spending limits. Per-transaction limits enforced before simulation. Per-period and per-integration configurability in active development. Autonomy policies. Read-only queries resolve automatically. All write transactions surface for approval by default. Granular policies (auto-approve thresholds, per-capability rules, per-integration configuration) are in active development. These execution boundaries are enforced at the infrastructure level. Wallet level policies can add a second layer of security.

​
Evaluation pipeline

ILLA maintains a domain-specific evaluation pipeline focused on financial correctness: does the system produce the right plan for the stated intent? Does it correctly refuse when it should? Does it disambiguate rather than assume? Does simulation match execution? “Close enough” is not a standard that applies when real money is at stake. The evaluation pipeline runs continuously, catching regressions and edge-case failures before they reach production. It runs continuously and evolves alongside the product.