> For the complete documentation index, see [llms.txt](https://optim-finance.gitbook.io/optim-finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://optim-finance.gitbook.io/optim-finance/leviathan-technical-dev-guide/summary.md).

# Summary

## Leviathan Technical Documentation

**Leviathan** is a Layer 2 scaling architecture for Cardano built by Optim Finance. It targets the two structural bottlenecks of the extended-UTxO (eUTxO) model — **concurrency** (contention over shared UTxOs) and **composability** (the loss of atomicity introduced by off-chain batching) — without abandoning the settlement guarantees of the base layer.

This documentation is a technical reference for engineers building against, auditing, or extending the Leviathan protocol. It goes beyond the conceptual whitepaper to describe concrete smart contract design, validator responsibilities, and implementation conventions consistent with the reference implementation at [`OptimFinance/leviathan`](https://github.com/OptimFinance/leviathan), which is written in [Aiken](https://aiken-lang.org).

### Design Thesis

Cardano's eUTxO model gives every transaction deterministic, locally-verifiable validity: a transaction's outcome depends only on its declared inputs, not on global mutable state. That determinism is the source of Cardano's predictability, but it also means that **only one transaction can consume a given UTxO at a time**. Every existing Layer 2 or scaling pattern on Cardano — batchers, order books, state channels — either serializes access to a shared UTxO (recreating the bottleneck one layer up) or breaks atomic composability by settling in a queue.

Leviathan's thesis is that these are not two separate problems but one: **the lack of an account abstraction layer that lets a user's signed intent be turned into a chain of deterministic, self-authorizing UTxO transitions, ahead of L1 confirmation.** Given that abstraction, a sequencer network can extend a chain of *Guaranteed Transactions* — each one consuming the previous transaction's not-yet-settled output — and achieve instant finality at the L2 level while preserving the property that the whole chain either resolves to a valid L1 state or safely halts without any custodial loss.

### How This Documentation Is Organized

| Section                            | Covers                                                                                            |
| ---------------------------------- | ------------------------------------------------------------------------------------------------- |
| System Architecture                | Component topology, the sequencer network, transaction chain extension, finality and safety model |
| Smart Contract Requirements        | Functional and security requirements every Leviathan validator must satisfy                       |
| Modular Contract Design Patterns   | How the validator/lib split, datum design, and redeemer routing are structured in Aiken           |
| Implementation Best Practices      | Aiken conventions, testing, auditing, and deployment discipline used in the reference repo        |
| Optim Account Mechanisms           | The account-abstraction contract layer: intent structuring, authentication, permissioning         |
| Account Abstraction Technicalities | How EOA/contract-account bifurcation is resolved on an eUTxO chain                                |
| Intent-Based Transactions          | Declarative constraint format, solver responsibilities, execution lifecycle                       |

### Non-Goals of This Document

This documentation does not cover tokenomics, governance, or the OADA fee-token design beyond what is structurally necessary to explain gas abstraction — those are covered in separate product documentation. It also does not restate audit findings; where a design choice has open security considerations, this doc flags them explicitly rather than asserting they are resolved.