Lorenz

Introduction

Lorenz Protocol, an experimental, non-custodial reference architecture for deterministic, atomic, flash-loan-funded arbitrage on Solana, with an agentic control plane and on-chain safety invariants.

Lorenz Protocol is an experimental, open-source research platform for atomic, flash-loan-funded arbitrage on Solana, with an agentic control plane and safety guarantees enforced on-chain.

An AI arbitrage hedge fund you own the keys to: open-source, non-custodial, deterministic.

Order inside chaos.

Status: experimental. Not production. No profitability claims.

This repository is an engineering foundation under active development. It does not trade live yet, it has not been audited, and nothing here is financial advice. See the Disclaimer.

Why this exists

Most "arbitrage bot" repositories are a thin wrapper of marketing over a forked engine, with disconnected modules presented as working features and invented performance numbers. This project takes the opposite stance: every claim in these docs is meant to be verifiable from the code or the chain, or it is labelled as roadmap. If you find a discrepancy, that is a bug. Please open an issue.

The design bet is simple: in a latency game you cannot win on latency alone, so the durable edge is a well-architected, auditable system with an intelligent control plane operating on the niches the largest players ignore.

The two planes, one-way control

Lorenz separates two concerns that operate on completely different time scales and must never be conflated: the data plane (microseconds, deterministic) and the control plane (seconds to minutes, intelligent).

The control plane proposes parameters and tighter limits; the data plane executes within hard ceilings. The on-chain program is the final backstop: the chain itself refuses any trade that would lose money or exceed the cap.

The honesty stance

  1. Determinism in the data plane. No floating-point money, no AI on the hot path. Every trade is reproducible from logs.
  2. Auditability as an on-chain property. Safety is enforced by the program, not promised by the bot.
  3. Honesty as a feature. Stubs are visible; roadmap is labelled; no metric is fabricated.
  4. Non-custodial by design. Users keep ownership of their vault; the bot gets a scoped delegate that cannot withdraw.

Status legend

Used consistently across all chapters:

  • Implemented + tested: real code with unit/property tests.
  • 🟡 Seam: a typed, documented integration point that compiles and returns an explicit NotImplemented, so the surrounding logic is reviewable.
  • 🔭 Roadmap: described and scoped, not present in code yet.

Where to go next

On this page