Skip to main content
Version: v1

Node v2.1.101 release notes

For the complete documentation index, see llms.txt
  • Version: v2.1.101
  • Date: November 6, 2026
  • Components: node-2.1.101, node toolkit 2.1.101, runtime 2.1.100 (spec_version 2001100), ledger 9.1.0.1

Docker images​

docker pull midnightntwrk/midnight-node:2.1.101
docker pull midnightntwrk/midnight-node-toolkit:2.1.101

The public GitHub release and images for node 2.1.101 follow in the next few days.

High-level summary​

Node v2.1.101 is the node release for the ledger 9 network upgrade on Mainnet. It runs the 2.1.100 runtime, which is the runtime that the governance upgrade enacts. The binary runs ledger 8 for blocks before the upgrade and ledger 9 for blocks after it.

Every Mainnet validator and RPC node must run v2.1.101 before the governance upgrade. Upgrade from v1.0.400 or v2.1.100 directly to v2.1.101, and upgrade block producers together. The v2.1.0 release candidates aren't a supported upgrade step. A node that still runs v1.0.400 stops at the upgrade block.

The upgrade has two steps. First, node operators replace the binary across the network. Then a governance action applies the on-chain runtime upgrade, which moves the chain to ledger 9.1.0.1. Mainnet applied the governance upgrade on 6 November 2026.

On 6 November 2026, Preview was reset as a new chain that runs ledger 9 on node v2.1.101. The reset isn't a hard fork, and the new chain keeps no ledger 8 history. Preprod stays on node v1.0.400 and ledger 8.1.3 until a later upgrade.

Audience​

This release note is relevant for users who:

  • Run a Midnight node on Mainnet: validator, RPC, full, boot, or archive node.
  • Run an indexer, a wallet backend, or other infrastructure that reads Mainnet blocks or runtime metadata.
  • Build DApps or wallets that submit transactions to Mainnet.

If you run a node on Preview, start it on v2.1.101 against the reset chain with a fresh data directory. The old Preview chain data is no longer valid. The binary and governance upgrade steps on this page don't apply to Preview.

If you run a node only on Preprod, keep running v1.0.400 for now.

What changed (Summary of updates)​

The updates below describe the key changes introduced in this release.

  • Added ledger 9 support (ledger 9.1.0.1). The node keeps ledger 8 for blocks before the upgrade and switches to ledger 9 at the governance upgrade.
  • Removed ledger 7 support from the binary.
  • Added runtime 2.1.100 (spec_version 2001100) for the ledger 9 network upgrade.
  • Added two pallets: SafeMode and C2MBridge. The bridge pallet ships turned off and stays off until governance enables it. Its rollout will be announced separately.
  • Removed three subcommands: smart-contracts, sign-address-association, and sign-block-producer-metadata.
  • Changed the connection to Cardano db-sync to TLS only.

New features​

SafeMode pallet​

The runtime adds the SafeMode pallet.

C2MBridge pallet​

The runtime adds the C2MBridge pallet for transfers from Cardano to Midnight. It ships turned off and stays off until governance enables it. Its rollout will be announced separately, so don't treat bridging as available.

Breaking changes​

Upgrade before the governance upgrade​

The node binary and the on-chain runtime upgrade separately:

  • Binary upgrade: you replace v1.0.400 or v2.1.100 with v2.1.101. Until the governance upgrade, the node keeps running the current runtime and ledger 8, and nothing changes on chain. This upgrade is one-way: once v2.1.101 has opened a data directory, v1.0.400 can't start on it. Snapshot the data directory before you swap binaries. To return to v1.0.400, restore that snapshot, or wipe the data directory and resync.
  • Runtime upgrade: a governance action moves Mainnet to the new runtime and ledger 9. It runs after node binaries across the network have moved to v2.1.101.

A node that has not moved to v2.1.101 when the governance upgrade runs stops importing blocks at the upgrade block.

To upgrade your node:

  1. Snapshot the node data directory.
  2. Pull midnightntwrk/midnight-node:2.1.101, or download the node tarball for your architecture (midnight-node-2.1.101-linux-amd64.tar.gz or midnight-node-2.1.101-linux-arm64.tar.gz) from the node-2.1.101 release and check it against the SHA256SUMS file.
  3. Check your configuration against the operator changes in the next section. Keep the default separate storage layout. For the reason, see Known issues.
  4. Restart the node with the new image or binary.
  5. If you use the toolkit, switch to node toolkit 2.1.101 from the same release.

Mainnet applied the governance upgrade on 6 November 2026. A node still on v1.0.400 stops at the upgrade block, so upgrade it now.

To confirm the binary upgrade, call these RPC methods on your node:

  • system_version returns a value that starts with 2.1.101.
  • Before the governance upgrade, state_getRuntimeVersion still returns specVersion 1000300.

To confirm the runtime upgrade after the governance action:

  • state_getRuntimeVersion returns specVersion 2001100.
  • midnight_ledgerVersion returns a value that names crate-ledger-9.1.0.1.

After the runtime upgrade, the node replays DUST registrations for about 48 blocks. Don't restore a snapshot or warp-sync a node until the DustReapplyCompleted event.

Operator changes​

These changes affect how you run the node.

  • Removed subcommands: the smart-contracts, sign-address-association, and sign-block-producer-metadata subcommands no longer exist. Remove them from your scripts. The wizards subcommand stays.
  • db-sync connection: the node connects to the Cardano db-sync PostgreSQL database over TLS only. The node ignores the ALLOW_NON_SSL setting. Set ssl_root_cert to turn on certificate checks. A node pointed at a PostgreSQL server without TLS exits at startup.
  • New flags: --no-hardware-benchmarks, --rpc-max-finality-subscriptions (default 512), and --ipfs-bootnodes.
  • New configuration settings: storage_separation (separate or unified, environment variable STORAGE_SEPARATION) and chainspec_c2m_bridge_config. The default is separate, the same layout as v1.0.400. Keep it for this upgrade.
  • Changed defaults: block_stability_margin moves from 10 to 30, and storage_cache_size moves from 10000 to 100000.
  • Startup hardware benchmark: the node runs a hardware benchmark at startup. Validators below the reference hardware profile get a warning. Use --no-hardware-benchmarks to skip it.

Ledger 8 transactions stop working on Mainnet​

After the governance upgrade, the ledger 8 transaction format doesn't decode on Mainnet, so Mainnet rejects transactions built for ledger 8. Wallets on wallet SDK 1.x can't transact on Mainnet. DApps and wallets need wallet SDK 2.0.0, Midnight.js 5.0.0, and indexer 4.4.101. For the full version set, see the support matrix.

Clients that read runtime metadata must fetch it again after the upgrade, because the runtime adds pallets and changes pallet error enums.

What DApp developers do​

You do not run a node, but your DApp talks to Mainnet through one. Before the governance upgrade:

  • Move your DApp to wallet SDK 2.0.0 and Midnight.js 5.0.0, and point it at indexer 4.4.101. In Midnight.js 5.0.0 and Compact.js 3.0.0, the types are aware of the ledger era, so select the era explicitly.
  • Compile new contracts with Compact toolchain 0.36.0 (language version 0.28.0).
  • The tested upgrade rehearsal checks that a contract deployed before the upgrade can still be called. In an earlier devnet test, contracts built with Compact toolchain 0.31.1 kept working without a recompile when the ZK config provider uses verify: 'require-if-present'.
  • Midnight.js 5.0.0 refuses artifacts built with Compact toolchain 0.30.0, with EraMismatchError. Move those contracts to Compact toolchain 0.36.0 through their maintenance authority, or redeploy them.
  • A contract action subscription that you open without an offset now delivers only new actions. To replay history, pass an explicit offset, such as height 0. Midnight.js 5.0.0 does this. Midnight.js 4.x doesn't, and receives no history.
  • A fee floor, min_block_price, applies from the first block after the upgrade, so fees rise slightly. Update your fee estimation before the upgrade.

For the full list of steps, see the ledger 9 upgrade page.

At the upgrade, DUST state resets once, and NIGHT balances don't change. Every DUST registration on Mainnet is backed by cNIGHT, and the network replays all of them automatically, straight to their full cap, so Mainnet users don't need to do anything. The replay takes about 48 blocks, under five minutes on a recent Mainnet snapshot, and ends with a DustReapplyCompleted event. Transactions submitted while it runs wait in the transaction pool and are included once it ends.

What indexer operators do​

Indexer 4.4.101 stores contract state in a new layout and needs a full re-index from genesis. Plan the re-index before the governance upgrade. The indexer then follows the chain across the upgrade by itself. Indexers must run 4.4.101 to report DUST capacity correctly after the upgrade. A local archive node on v2.1.101 syncs the indexer faster than a public RPC endpoint. For details, see the ledger 9 upgrade page.

Known issues​

Switching to unified storage on an existing data directory stops block import​

Node v2.1.101 defaults to the separate storage layout, the same as v1.0.400. A node set to storage_separation=unified that keeps its v1.0.400 data directory stops importing blocks. The process keeps running with no crash and no peers, so liveness checks don't flag it.

Keep the default separate layout for this upgrade. To move to unified, stop the node, delete the whole data directory (chains/ and ledger_storage/), and resync. Track it in the node issue for unified storage.

Removing a verifier key in a maintenance update is rejected​

A maintenance transaction that removes a verifier key (VerifierKeyRemove) is rejected with BalanceCheckOverspend when the client packages use ledger 9.1.0.0, even though the client reports it as paid. Node 2.1.101 runs ledger 9.1.0.1, which changes the fee for transactions whose fallible part deletes state, so clients on ledger 9.1.0.0 underestimate that fee. Maintenance transactions that insert a verifier key or replace the maintenance authority are accepted.

Most contracts aren't affected. A contract with ZKIR version 2 keys moves to Compact toolchain 0.36.0 by inserting its new keys, and inserts are accepted. Only a contract that makes cross-contract calls and takes the cross-contract call fix in Compact toolchain 0.36.0 needs to remove its old keys. Until your client packages move to ledger 9.1.0.1, redeploy that contract instead. Track it in the node issue for verifier key removal.

If you find a problem with v2.1.101, report it in the midnight-node issue tracker.