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, which is written in Aiken.

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.