Architecture

The system is built around a single rule: models propose, deterministic code decides, and wallet and venue rules enforce. Everything below follows from wanting that to be structurally true rather than a policy we maintain.

A proposal crosses every plane. It is only signed if the plan engine, the policy gate and the venue all agree — three separate refusals, none of them in the app — and the whole descent is written to the journal.

The diagram in words

Four stacked planes. From the top: Control, the app where you set your plan; Agent, where Lloyd runs and proposes; Money, where the wallets and the signing policy sit; and Data, the append-only journal. A proposal descends through all four and must pass the policy gate on the Money plane, which refuses anything not explicitly permitted.

Four planes

Control — the app you use. Onboarding, the account surfaces, manual trading, approvals, monitoring.

Agent — the durable runtime where Lloyd’s work happens. Long-running, restartable, and able to wait for a human approval for as long as it takes without holding anything open.

Money — wallets, signer provisioning, venue mapping, and signing. Vault wallets are embedded and user-controlled; operator wallets are server-side and policy-gated. Signing happens inside a secure enclave.

Data — the system of record. An append-only journal, projections derived from it, versioned policies, and execution receipts. State is derived from the log, not maintained beside it.

The path a trade takes

1. Lloyd emits a structured proposal.

2. The proposal is schema-validated. Malformed proposals stop here.

3. The Trading Plan engine evaluates it — plain TypeScript, unit-tested, no model involved.

4. If your trust mode requires approval, the runtime waits for you. Indefinitely, and without acting.

5. The wallet layer signs, inside the enclave, subject to a default-deny policy.

6. The exchange applies its own rules and executes.

7. The journal records what happened.

8. The interface updates from the journal.

The model participates in step 1 and nowhere else.

Three independent gates

The plan engine, the wallet policy engine, and the venue each evaluate independently and each can refuse. They do not share code, so a bug in one is not a bug in all three. The policy engine is default-deny — an action is refused unless explicitly permitted — and it lives with the keys rather than in application code, so XIO’s own backend cannot talk it into signing something out of scope.

Two wallets, never merged

The vault holds your money and only you can withdraw from it. The operator trades and cannot withdraw at all. They are separate wallets with separate permissions, and collapsing them would remove the property that makes the rest of the design meaningful.

Each trading signer has exactly one writer, and a retired signer address is never reused.

Strategies are specs, not code

Your English becomes a typed, bounded specification over an audited template. The model authors a proposal of what the spec should be — it never writes executable code, and nothing it produces enters the signing path.

This is deliberate. The alternative pattern — a model writing code that trades against a live key — is the one failure mode in this category that reliably ends badly.

What is live today

The wallet architecture, the plan engine, the policy layers, the journal, onboarding, and the manual trading surfaces are built. Hyperliquid execution is finished and being audited before it is switched on; until then, orders run against a simulated venue and the app says so.

We would rather document that plainly than describe a system you cannot yet use.