# Engineering update - January 2026

### Executive summary

In the last 3 months we've made significant advances across the entire Miden tech stack. We are currently focused on:

- Finishing foundational protocol-level features which will allow us to support use cases like compliant private stablecoins and provide best-in-class token standards, institution-grade wallets etc.
- Adding functionality which will simplify integrations with partners and customers. These include support for widely used signature schemes, private state management systems, integration with bridges etc.
- Creating tooling to make writing smart contracts in Rust on Miden as easy as possible. This includes Rust compiler improvements, debugging and diagnostics infrastructure, project scaffolding and toolchain management.

We have also progressed with our testnet deployments:

- **v0.12 testnet** was launched on November 25, 2025 and is currently running. So far, users and pioneers have created close to **300K accounts** and almost **5M transactions**.
- **v0.13 testent** development is nearing completion with launch planned for late January 2026.
- **Mainnet alpha** is planned for **v0.15** or **v0.16** release of the protocol, slated for mid Q2 2026.

Below are the key highlights of the functionality enabled in these releases.

### Protocol improvements

#### Lazy account loading

Implemented the ability to load only the relevant parts of an account during transaction execution. This enables foreign procedure invocation (FPI) calls in network transactions and simplifies support for accounts with large amounts of storage. The former is critical for programmable asset functionality slated for v0.14 release.

#### Authentication improvements

Refactored transaction authentication framework to make it more generic and implemented support for ECDSA signature scheme. The latter allows us to reduce client-side latency for simple transaction by a factor of 5 compared to our default RPO Falcon signature scheme. This enables sub 2-second local proving on mobile devices. The new framework is easily extensible and we are planning to add other signature schemes in subsequent releases (e.g, EdDSA, canonical Falcon).

#### Address format adjustments (again)

Based on the feedback from pioneers, we've updated our address format to be more easily correlateable with account IDs. The new address format consists of 3 parts: an identifier (e.g., account ID), routing parameters, and encryption information. The latter part can be used by senders to encrypt notes so that only the recipient can view their content.

#### Transaction kernel API enhancements

Implemented additional kernel API procedures to help with account and transaction introspection and re-organized kernel procedures to be grouped by logical functions (e.g., active account, active note etc.). These pave the way for updating token and authentication standards slated for v0.13 and v0.14 releases.

#### Initial guardrails

In v0.12 release we begun the implementation of guardrails aimed at double-checking validity of locally-generated transaction proofs by re-executing them in the node. After this release, the users are required to send additional transaction data to the node, which is used by the node's newly introduced _validator_ component to check transaction execution results. This functionality will be expanded in the subsequent releases to include batch and block validation as well.

#### Mempool refactoring

Refactored the node's mempool to use a single DAG across transactions and batches. This works lays the foundation for user-provided transaction batches which will unlock several use-cases including advanced private state management (PSM) systems.

#### Account sync improvements

Refactored account synchronization endpoints of the node to support incremental syncing of large accounts. This includes synchronization of account's asset vaults and storage maps. Future improvements to this endpoint will allow requesting partial storage maps. This functionality is critical for programmable asset refactoring slated for v0.14 release.

#### Miden network monitor

Implemented a dashboard which provides a detailed view into Miden [network status](https://status.testnet.miden.io). This functionality was frequently requested by the pioneers to understand whether various components of the network are functioning as expected.

#### DevOps transition to Gateway

In preparation for eventual mainnet launch, we've started to transition our infrastructure to Gateway, an infrastructure provider with vast experience of running blockchains in production. The initial transition involved Gateway taking over management of our block explorer (Midenscan) and remote prover infrastructure. In subsequent releases, Gateway will assume more responsibility and will start running the nodes as well.

#### AggLayer integration

Started working on smart contracts for AggLayer integration. These will lay the foundation for the AggLayer bridge functionality which is slated for v0.14 release.

### Miden VM

Over the same timeframe, we've released two new versions of the Miden VM: [v0.19](https://github.com/0xMiden/miden-vm/releases/tag/v0.19.0) (November 2, 2025) and [v0.20](https://github.com/0xMiden/miden-vm/releases/tag/v0.20.0) (December 5, 2025). Key feature highlights of these releases are described below.

#### Dynamic kernel calls

Implemented ability to make dynamic calls from within kernel contexts. This functionality is critical for the upcoming programmable asset support, where a callback to the asset's issuing faucet must be made dynamically from the transaction kernel - eg., when account A transfers token `X` → account B, we must call faucet or intermediary contract via the kernel.

#### New precompiles

Building on the foundation laid in the previous releases, these releases introduced support for ECDSA, EdDSA, and SHA512 precompiles. These precompiles are important because they allow us to efficiently support commonly-used signature schemes at the protocol level and enable integration with existing wallets (e.g., ECDSA signature support was critical for Para wallet integration).

#### Arithemtization-friendly encryption

Implemented instructions and core modules needed to support efficient encryption (and decryption) within the VM. Providing encryption primitives at the VM level is important because it enables encrypted on-chain data which makes the UX more robust and also unlocks compliance/regulation-oriented use cases. One example of the latter is attaching encrypted blobs to notes which only specific entities can decrypt. An example of a specific entity could be an asset issuer who may need to have a viewing key for monitoring movements of their asset through the network.

#### Miden assembly linker refactoring

Refactored Miden assembly linker to fix several long-standing bugs and enable new functionality required for downstream usages. The new functionality includes ability to export/import types and constants from modules.

#### Sparse Merkle tree

Completed Sparse Merkle tree implementation in the Miden core library. This is a foundational data structure which is used in numerous places in the protocol (e.g., nullifier and account trees, storage maps, asset vaults). Previous implementation did not handle certain edge cases which made it vulnerable to exploits. The updated implementation covers all functionality and will be audited in the coming weeks.

### Rust compiler

#### Standard library and transaction kernel bindings

Implemented Rust binding for the most common transaction kernel APIs. This is an essential component of our Rust SDK that enables developers to write smart contracts in Rust. Automatic binding generation is expected to land by end of Q1 2026, which will remove the need for us to maintain bindings by hand, and ship new compiler releases just to add bindings.

#### Rust smart contract ergonomics improvements

Implemented foundational infrastructure tot simplify the task of defining Miden smart contracts in Rust. These include a suite of Rust macros for defining accounts, notes, scripts and other blockchain-related concept using near-native Rust syntax.

#### Diagnostics and debugging improvements

A significant amount of work has been done to identify and fix areas where we were not emitting source location information, emitting incomplete locations, or failing to attach location information to errors surfaced at various points in the toolchain. Additionally, we are adding support to the compiler to propagate DWARF debugging information through from frontend to codegen, and are working on other parts of the toolchain to make it available during debugging in `miden-debug`. This additional information includes the location and type information of source-level local variables, which allows those to be displayed in the debugger as developers step through a program.

#### `midenup` toolchain

Introduced the first version of `midenup`, our new toolchain installer and project scaffolding utility. This provides: a one-step installer that sets up the local toolchain (client, VM, CLI, WASM bindings) for the Miden ecosystem, project-scaffolding (e.g., Rust + WASM + client skeleton), quality-of-life improvements - e.g., up-to-date dependencies, version management, example flows embedded. This is a major DevEx improvement for new developers onboarding to Miden.