Smart Contract Requirements

This section defines the functional and security requirements that every validator in the Leviathan system — Optim Account validators, sequencer/chain-extension validators, and the portal (entry/exit) validator — must satisfy. These are requirements, not implementation choices; the following chapter (Modular Contract Design Patterns) shows how the reference implementation meets them.

1. Functional Requirements

FR-1: Deterministic Validity

Every validator's spend/mint/withdraw logic must be a pure function of its declared inputs, redeemer, and script context. No validator may branch on external mutable state (oracle values excepted, and only via an explicitly-referenced, signed oracle UTxO — see FR-6).

FR-2: Exclusive Input Locking

A validator that participates in a Guaranteed Transaction chain must enforce that its outputs can be consumed only by a transaction that itself continues the chain correctly (FR-3), or by an explicitly-authorized exit path. This is what gives a chain member "exclusive rights to its inputs."

FR-3: Chain-Extension Continuity

Any validator producing an output destined for chain extension must encode, in its output datum, sufficient information for the next transaction's validator to verify:

• that it is spending the correct predecessor output,

• that the chain's sequence number is monotonically incrementing,

• that the aggregate chain has not exceeded any protocol-level bound (e.g., max chain length before mandatory L1 checkpoint).

FR-4: Intent Authentication

No Optim Account validator may authorize a state transition without verifying a signature (or multi-signature / threshold scheme, per account configuration) over the intent's canonical serialization. Signature verification must be the first check performed, before any other branch of validator logic executes, to minimize the attack surface of unauthenticated code paths.

FR-5: Fail-Closed Semantics

If any required datum field is malformed, missing, or the redeemer references a nonexistent chain predecessor, the validator must reject (return False / fail), never fall back to a default-permit state.

FR-6: Oracle-Anchored Time

Any validator whose logic depends on time (time-locks, expiry, rate-limits) must read the timestamp from a referenced, protocol-designated time-oracle UTxO via a reference input (not a spent input, to avoid unnecessary contention on the oracle UTxO itself), and must reject if that reference input is absent or does not match the expected oracle policy ID.

FR-7: Reversion Handling

Validators must define explicit behavior for the case where a chain cannot be extended further (compromised sequencer, competing spend, expired intent): the affected UTxO must remain spendable under its original L1-only spending path (i.e., revert to a state where only the depositing user's key, or the standard exit path, can act on it). No validator may design itself such that a halted chain leaves funds in a state reachable only by the sequencer.

FR-8: Composability Preservation

A validator must not require its output to be spent within the same transaction it is produced in (which would reintroduce batcher-style atomicity breakage). It must be independently spendable by any subsequent transaction that satisfies its stated conditions — including transactions constructed by a different solver or dApp than the one that produced it.

2. Security Requirements

SR-1: No Custodial Intermediary

At no point may a validator route funds through an address controlled by a private key held by the Optim Finance team, the sequencer operators, or any other centralized party. The only privileged addresses in the system are script addresses whose logic is public and auditable.

SR-2: Minimal Trusted Computing Base

Sequencer-network consensus (which transactions get ordered/batched, and in what order) must not be a precondition for validity — only for liveness. A malicious or offline sequencer set can prevent new chain extensions; it cannot produce a validator-accepted transaction that violates FR-1–FR-8.

SR-3: Double-Satisfaction Resistance

Where a single transaction consumes multiple UTxOs governed by the same validator script (a known Cardano-specific pitfall), the validator must disambiguate outputs per input — e.g., by requiring each input's corresponding output to carry a matching, input-derived token or index — rather than checking aggregate output value, which is exploitable when multiple same-script inputs are batched together.

SR-4: Redeemer Indexing Integrity

Validators must not assume a fixed index/order of inputs, outputs, or redeemers in the script context; they must locate their own input/output pair explicitly (e.g., via find_input/find_output by reference or by an embedded correlation token) to remain correct under arbitrary transaction construction by third-party solvers.

SR-5: Upgrade Path Isolation

Because Leviathan must tolerate protocol-level changes to the L1 (hard forks, cost-model updates), validator logic that encodes protocol parameters (min fee, max tx size, cost models) must read them from a versioned, on-chain reference rather than hardcoding them, so a parameter change does not silently invalidate in-flight chains.

SR-6: Bounded Chain Length

An unbounded Guaranteed Transaction chain is a denial-of-service and censorship vector (a very long unsettled chain increases the cost and latency of eventual L1 settlement, and increases the value at risk if the chain must revert). Protocol-level validators must enforce a maximum chain depth between mandatory checkpoints to L1.

SR-7: Audit-Traceable State

Every state-changing validator invocation must leave an on-chain-inspectable trail (datum diffs) sufficient to reconstruct, after the fact, the full sequence of intents that produced the current UTxO set — this is required both for user-facing transparency (real-time status tracking, as described in the architecture) and for post-incident forensics.

3. Requirement-to-Component Traceability

Requirement	Primarily Enforced By
FR-1, FR-5	All validators (baseline discipline)
FR-2, FR-3, SR-6	Sequencer / chain-extension validators
FR-4, SR-1	Optim Account validators
FR-6	Any time-sensitive validator, via shared oracle module
FR-7, SR-2	Portal (entry/exit) validator + chain-extension fallback logic
FR-8	All validators producing chain-extension outputs
SR-3, SR-4	All validators (Cardano-specific correctness discipline)
SR-5	Protocol-parameter reference module
SR-7	Datum schema design across all validators