Skip to main content
The midgard CLI is the command-line interface for interacting with the Sundial L2. You use it to create and manage wallets, send transactions on the L2, look up transaction history, and check the status of a running node — all without writing any code. It communicates directly with the Sundial node’s HTTP RPC endpoints, so anything the node exposes is accessible from the terminal.

Installation

After installation, confirm it is working:

Global Options

These flags apply to every midgard command and can be set as environment variables to avoid typing them on every invocation. To point every command at the public testnet node without repeating --endpoint on each call, set the node.endpoint value in your manager config file (demo/midgard-manager/config/settings.json):
Alternatively, pass --endpoint https://rpc.testnet.sundialprotocol.com with each command.

Wallet Commands

The CLI stores wallet keys locally in config/wallets/default.json. This file is git-ignored and never leaves your machine — treat it with the same care as any private key file.

midgard wallet create

Generate a new wallet with a fresh keypair.
Example output:
Save your private key immediately after creating a wallet. The CLI prints it once — if you lose it, the wallet cannot be recovered.

midgard wallet import

Register an existing private key under a local name.
Use this to bring in a key you already hold rather than generating a new one.

midgard wallet list

Display all locally saved wallets and their addresses.
Example output:

midgard wallet balance

Check the sBTC balance of a saved wallet.
Example output:
Balances are displayed in sBTC. The underlying unit is lovelace, where 1 sBTC = 1,000,000 lovelace.

midgard wallet address

Print the address for a saved wallet without showing the balance.

Transaction Commands

midgard send

Transfer sBTC from one of your saved wallets to any address on the Sundial L2.
Example output:
--amount is in sBTC, not lovelace. To send 5 sBTC, pass --amount 5, not --amount 5000000.
The send command signs the transaction with the locally stored private key and submits it through POST /submit. The node queues it for processing; there may be a brief delay before the transaction appears in lookups.

midgard tx-lookup

Look up a transaction by its 64-character hex hash.
Transactions submitted via send are queued before being processed. If you see “Not found” immediately after sending, wait a few seconds and try again — a background worker on the node deserializes and validates the transaction shortly after receipt.

midgard query utxos

List the UTxOs held at a given address.
Example output:

Node Commands

midgard node node-status

Check whether the node you are connected to is live and ready.
Example output (healthy node):
Example output (node starting up):
A node can be live (the process is running) but not yet ready (database, Redis, or L1 provider are still initializing). If the node stays in not_ready for more than a minute, check your L1 provider credentials in .env.
Run midgard node node-status first whenever wallet balance or send can’t connect — it tells you immediately whether the issue is the node or the command itself.

Key Generation (Operators)

These commands are for operators who need to manage raw Cardano key pairs and addresses — for example, when setting up the seed phrases required by the node’s environment file.

Generate a payment key pair

This produces two files: payment.vkey (the public verification key) and payment.skey (the private signing key). Store payment.skey securely.

Build an enterprise address from a payment key

An enterprise address has a payment credential but no staking credential. It cannot delegate or earn staking rewards.

Generate a stake key pair

Build a base address with payment and staking credentials

A base address carries both a payment credential and a stake credential. Use this address type when you want a wallet that can participate in staking.

Address Formats

Sundial L2 uses the same address format as the Cardano L1 testnet, following CIP-19.
Always use a addr_test1… address when working with the testnet. A mainnet addr1… address will be rejected by the faucet and by the testnet node.

Node Socket and Network Configuration

For operators who need to configure the node-to-client socket path and network ID directly:
Alternatively, supply --testnet-magic 1 with each command instead of exporting the environment variable.

Layer Node Deployment

Run a Sundial node with Docker Compose or Nix, including the full observability stack.

Node Configuration

Full reference for every environment variable the node reads at startup.