Skip to main content
@al-ft/midgard-sdk is the official off-chain TypeScript library for interacting with the Sundial L2. It is the same library the Sundial node uses internally, so anything the node’s HTTP API can trigger, you can build directly with the SDK. The library is built on two foundational dependencies: Effect for typed, composable error handling, and Lucid Evolution for L1 transaction construction. Every public function returns either a plain Promise or an Effect blueprint, giving you a choice of programming style.

Installation

1

Bundle the tarball

Clone the sundial-monorepo repository and bundle the SDK into a local tarball:
This produces al-ft-midgard-sdk-0.1.0.tgz inside the package directory.
2

Add to your project

Reference the tarball in your package.json:
3

Initialize Lucid Evolution

The SDK requires a LucidEvolution instance. Create one against your preferred L1 provider before calling any SDK function:

Core Modules

The SDK is organized into vertical modules. All names are globally unique, so you can either import the entire namespace or import individual functions.

user-events/deposit

Construct and fetch deposit event UTxOs. A deposit places funds in the deposit validator on L1, and the operator credits them on L2.

user-events/withdrawal

Construct L2 withdrawal orders. A withdrawal order names an L2 output to withdraw. It is paid out on L1 after the including block matures.

user-events/tx-order

Post an L2 transaction on L1 so that operators must include it. Use this when an operator ignores your transaction.

hub-oracle

Query the Hub Oracle UTxO for authoritative protocol policy IDs, validator addresses, and protocol parameters. Pass the result as a reference input in transactions.

scheduler

Query the operator scheduling state to determine which operator is currently authorized to produce blocks.

state-queue

Interact with the L2 state queue linked list — commit new blocks, merge confirmed state, and read the current queue head.

fraud-proof

Construct and submit multi-step fraud proofs against invalid blocks. Covers double-spend, invalid range, non-existent input, and computation-thread dispute programs.

active/registered/retired-operators

Manage the operator directory lifecycle: register, activate, and retire Operator nodes.

Usage Examples

Constructing a Deposit

A deposit locks funds in the deposit validator on L1. The block whose event interval covers the deposit’s inclusion time must include it, and the funds then appear at your L2 address. Each builder needs the bech32 address and the minting policy script of the validator it targets. These belong to your Sundial instance’s deployment. The Hub Oracle datum gives you the policy IDs.
Every builder also accepts an optional nonceUTxO: the wallet UTxO whose output reference identifies the event.
Functions ending in Program (e.g., unsignedDepositTxProgram) return an Effect blueprint for use inside Effect.gen pipelines. Functions without the suffix return a plain Promise. Use whichever style fits your codebase.

Constructing a Withdrawal

A withdrawal order names the L2 output you want to withdraw and the L1 address to pay. Once a block includes it, the output leaves the L2 ledger. The order is paid out on L1 after that block’s maturity period.

Posting a Transaction Order (Guaranteed Inclusion)

A transaction order posts your L2 transaction on L1. The block whose event interval covers the order’s inclusion time must include it, so an operator can’t ignore it.

Querying the Scheduler

Check which operator is currently scheduled to produce blocks before submitting operator tooling transactions.

Submitting a Fraud Proof

Fraud proofs challenge invalid blocks committed to the state queue. The SDK exposes multi-step incomplete*TxProgram builders for each fraud proof type — wire the Effect result into your Effect pipeline and complete the transaction with your wallet.

Error Handling with Effect

The SDK’s internal Program functions use Effect’s typed error channel. Wrap them with Effect.runPromise or handle errors with Effect.catchTag to distinguish between LucidError, HashingError, DepositError, and others.
Use Effect’s error handling for robust SDK integrations. Each tagged error type carries a message and a cause field that pinpoints exactly where the failure occurred.

SDK-to-Validator Reference

Each SDK module targets a specific pair of Plutus V3 validators in the Sundial smart contract system.

Midgard Types

TypeScript type definitions and binary codec for L2 blocks, transactions, and user events. Use midgard-ts to validate transactions before submission.

REST API Overview

The Sundial node also exposes an HTTP RPC API. Use the REST API as an alternative to the SDK if you prefer HTTP-based integration.