System Architecture
1. Component Topology
Leviathan is composed of four cooperating layers, each with a distinct trust boundary:
┌───────────────────────────────────────────────────────────────────┐
│ User Wallet │
│ signs an INTENT (not a raw tx) — an off-chain message expressing │
│ a desired end state and consent │
└────────────────────────────────┬──────────────────────────────────┘
│ signed intent
▼
┌───────────────────────────────────────────────────────────────────┐
│ Optim Account Layer (on-chain, smart-contract accounts) │
│ • intent structuring & signature verification │
│ • permissioning / spend-limit / time-lock logic │
│ • emits an authorized "guaranteed" transaction request │
└────────────────────────────────┬──────────────────────────────────┘
│ authorized request
▼
┌───────────────────────────────────────────────────────────────────┐
│ Leviathan Sequencer Network (off-chain execution layer) │
│ • ordering, batching, compression, initial verification │
│ • Guaranteed Transaction chain construction (N → N+1 → N+2 ...) │
│ • current-time oracle anchoring │
└────────────────────────────────┬──────────────────────────────────┘
│ chained tx submission
▼
┌───────────────────────────────────────────────────────────────────┐
│ Cardano L1 Settlement Layer │
│ • eUTxO ledger rules, script validation, probabilistic finality │
│ • portal / bridge contract for entry & exit │
└───────────────────────────────────────────────────────────────────┘Each layer only has to trust the layer immediately below it for liveness, never for safety. Safety — custody of funds — is enforced entirely by the L1 spending rules that every Guaranteed Transaction must satisfy when it eventually settles.
2. The Concurrency Problem, Restated Precisely
In the eUTxO model a transaction is deterministic with respect to its declared inputs: it becomes invalid the instant any one of those inputs is consumed by a competing transaction. This gives strong local guarantees but means throughput on any single "hot" UTxO (a DEX pool, an order book head, a shared vault) is capped at one confirmed transaction per block interval, regardless of how much of the chain's total capacity is idle. Account-based chains such as Ethereum avoid this by giving every account a monotonically-incrementing nonce, decoupling "who can spend" from "which specific output must be spent." Leviathan's architectural bet is that this same decoupling can be achieved without giving up eUTxO's deterministic validation, by moving nonce-like sequencing into an off-chain, cryptographically-anchored layer that still resolves to ordinary eUTxO spends at settlement time.
3. Guaranteed Transactions and Chain Extension
A Guaranteed Transaction is one whose validity does not depend on when it settles, only on the unchanged state of its declared inputs. Concretely:
Its inputs are exclusively locked to the transaction the moment it is constructed — no other transaction, on or off Leviathan, can consume them.
Its outputs are deterministically computable from its inputs and the encoded transaction logic alone (no external state, no block hash, no wall-clock dependency beyond an oracle-anchored time value).
It carries a signed intent from the account that authorized it, rather than a direct signature over the raw transaction bytes.
Because outputs are computable and inputs are exclusively locked, transaction N+1 can be constructed using the (not-yet-L1-confirmed) outputs of transaction N as its inputs. This is the Leviathan Chain Extension: a sequence of transactions that is internally consistent and independently verifiable before any member of the chain has touched the L1 mempool. The chain is only bounded by sequencer throughput, not by Cardano block cadence — this is the mechanism that decouples user-perceived latency from L1 confirmation time.
Chain integrity invariant
For a chain [tx_0, tx_1, ..., tx_n]:
If any tx_i fails this check — because its required input state changed, or because the sequencer network is compromised and stops producing valid successors — the chain halts. It does not partially settle, and it does not surrender custody: unsettled outputs remain spendable only under the original L1 spending conditions, which always include a fallback path back to the depositing user. This is the property that distinguishes Leviathan from optimistic constructions that require a fraud-proof window: Leviathan's worst case is liveness loss, not safety loss.
4. Determinism vs. Ethereum-style Account Models
Validity determined by
Declared inputs only
Global state at execution time
Declared inputs, computed off-chain, settled on-chain
Concurrency unit
Per-UTxO
Per-account (nonce)
Per-account, via Optim Account abstraction
Fee predictability
High (script cost known pre-submission)
Variable (gas market)
High — fees fixed in OADA at intent time
Finality
Probabilistic (Nakamoto-style)
Probabilistic
Instant at L2 (sequencer-agreed), eventually settled probabilistically at L1
5. Instant Finality: Liveness/Safety Trade-off
Leviathan's sequencer network agrees on state transitions under pre-determined consensus rules encoded in smart contracts, not via a separate PoS/BFT validator set. This makes Leviathan's finality claim narrower and more auditable than a general L2's: a transaction is final the moment the sequencer network has produced a valid successor chain for it, because that chain is cryptographically self-verifying — no re-execution or subjective judgment is required to confirm it will settle correctly. The system explicitly prioritizes safety over liveness: if the sequencer network is compromised or unavailable, the protocol's designed response is to halt chain extension rather than risk producing an invalid or double-spent settlement.
6. Data Availability and Time
Time: Leviathan does not trust wall-clock time supplied by a transaction submitter. A current-time oracle anchors every time-sensitive Guaranteed Transaction to a value the sequencer network attests to, so that time-locked or conditional intents (e.g., "execute this swap only if price ≤ X within the next 10 minutes") have a deterministic temporal reference that survives chain re-sequencing.
Data availability: because unsettled chain state is off-chain, sequencers are responsible for retaining and serving the intermediate UTxO states of an in-flight chain until settlement. The architecture treats DA as an operational property of the sequencer network today, with the roadmap (see Future Sequencer Network) targeting a decentralized, multi-operator sequencer set specifically to remove any single point of DA failure.
7. Entry and Exit
Entry and exit are ordinary, non-custodial L1 transactions against a portal smart contract:
Entry: user deposits ADA/OADA/any Cardano Native Token into the portal; the deposit is credited as an account-model balance inside Leviathan.
Exit: user submits an intent through Optim Account signaling withdrawal; after the standard security checks (exit transaction legitimacy, balance accounting, destination validity), the portal releases the corresponding L1 UTxO.
No party other than the portal contract and the exiting user's own signed intent is in the custody path at any point.
8. Layer 2 Execution Environment
Off-chain, the sequencer's execution environment mirrors L1 script semantics closely enough that any transaction it produces is guaranteed to be independently re-validatable by an ordinary Cardano node — Leviathan does not introduce a divergent VM or a distinct notion of validity. This is a deliberate constraint: it means every Leviathan transaction, once it reaches L1, is subject to the exact same validator logic as a native Cardano transaction, with no additional trust assumption about the correctness of an L2-specific execution engine.
Last updated