# Engineering update - October 2025

Over the last 3 months, we've achieved the following milestones:

### Testent deployments

- **v0.10 testnet** was launched on July 14, 2025 and ran through September 9, 2025. During this time, pioneers and users created over **160K accounts** and almost **1.5M transactions**.
- **v0.11 testnet** was launched on September 9, 2025 and is currently running. So far, users and pioneers have created over **150K accounts** and almost **1.2M transactions**.
- **v0.12 testnet** development is in progress with launch planned for early November.

Full changelogs for these deployments can be found here:

- `miden-protocol` [v0.10](https://github.com/0xMiden/miden-base/releases/tag/v0.10.0), [v0.11](https://github.com/0xMiden/miden-base/releases/tag/v0.11.0).
- `miden-node` [v0.10](https://github.com/0xMiden/miden-node/releases/tag/v0.10.0), [v0.11](https://github.com/0xMiden/miden-node/releases/tag/v0.11.0).
- `miden-client` [v0.10](https://github.com/0xMiden/miden-client/releases/tag/v0.10.0), [v0.11](https://github.com/0xMiden/miden-client/releases/tag/v0.11.1).

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

#### In-kernel account delta computations

implemented tracking of account deltas inside transaction kernel and outputting account delta commitment as part of transaction outputs. This makes transaction authentication schemes more flexible by allowing users to sign account deltas rather than new account states. One of the benefits of this is enabling out-of-order transaction processing in multi-sig settings. Another benefit is the ability to check validity of account delta for public accounts simply by verifying transaction proofs.

#### Authentication procedures

Introduced the concept of account authentication procedures. These procedures are automatically run by the transaction kernel in the transaction epilogue. This mechanism guarantees account owner-defined code is executed last in the transaction (i.e., after the transaction script) giving the user more control over how to authenticate transactions. In turn, this enables more sophisticated authentication schemes (e.g., multisig with rate limiting).

#### Transaction introspection procedures

Added a set of procedures to the transaction kernel to enable retrieving of detailed information about input/output notes and account changes. This allows, among other things, authentication procedures to check which assets are being sent out of the account in a given transaction enabling things like rate-limiting.

#### Flexible note construction

`create_note` and `add_asset_to_note` kernel procedures can now be called directly from note and transaction scripts. One consequence of this is allowing users to delay asset consistency checks until transaction epilogue enabling such capabilities as transaction-level "flash loans".

#### Async transaction execution

Enabled asynchronous callback from the transaction executor to the transaction authenticator (and in the future, data store). This enables the `WebClient` to implement more robust and safe key-management, paving the way for future support of signing via hardware wallets.

#### Initial fee model

Introduced fee handling in the transaction kernel. In the initial approach fees, in the native token, are automatically computed in the transaction epilogue. In the future, this will be expanded to allow fee payments in non-native tokens and to enable more fine-grained and user-defined fee payment strategies.

#### Network transactions improvements

Simplified and improved handling of network transactions. Now, the network transaction builder subscribes to the events emitted by the mempool and is able to learn about network notes as soon as corresponding transactions are admitted into the mempool. This addresses several race conditions which existed in the previous implementation.

Improved handling of failures during network transaction execution to identify "offending" notes, and apply retry-strategies without exhausting the node's resources.

#### Node deployment and telemetry

Implemented Open Telemetry reporting for all node components, added Honeycomb collectors, and set up Slack-based alerts to monitor network activity. Additionally, automated infrastructure setup (via Terraform) and deployment workflows to simplify devenet and testnet deployments.

### Miden VM

Over the same timeframe, we've released 3 new versions of the Miden VM: [v0.16](https://github.com/0xMiden/miden-vm/releases/tag/v0.16.0) (July 8), [v0.17](https://github.com/0xMiden/miden-vm/releases/tag/v0.17.0) (August 6), and [v0.18](https://github.com/0xMiden/miden-vm/releases/tag/v0.18.0) (September 21). Key feature highlights of these releases are described below.

#### Fast processor

Introduced a separate processor (i.e., the "fast processor") that executes Miden VM programs as fast as possible collecting minimal amount of information required for trace generation in later stages. The fast processor is capable of executing programs at around 300 MHz. This enables executing simple Miden transactions in under 5ms.

Another benefit of the fast processor is that it is able to execute transactions using asynchronous runtime. This enables asynchronous transaction execution mentioned previously.

#### Assembler refactoring

Refactored the assembler to address several existing bugs and prepare for the introduction of Miden packages. This included internal refactoring of the module graph, as well as splitting out assembly syntax and debug info handling into separate crates.

Introduced ability to describe procedure signatures in Miden Assembly. This paves the way for automated binding generation for the Rust compiler which will simplify integration of hand-written MASM libraries (e.g., the Miden VM core library and the protocol library) into the Rust-based smart contracts.

Enabled specifying advice data (advice map entries) in MASM. This allows generating MASM files in AirScript which contain full description of arithmetic circuits to be evaluated in the context of recursive verifiers.

#### Initial precompile support

Refactored non-deterministic event handling infrastructure. Now, a Miden library can define its own custom event handlers (currently expressed as Rust closures). These event handles can the be used to perform custom non-deterministic computations and return the results to the VM. As a part of this several "native" VM instructions were downgraded to events and their handlers were move into the core VM library.

Additionally, we've introduced the Keccak precompile which makes use of the new event handler infrastructure. This precompile is essential for efficient AggLayer smart contracts. Additional precompiles will be added in subsequent VM releases covering things like ECDSA and EdDSA signature schemes.

### Rust compiler

On August 15, 2025, we have released [v0.4](https://github.com/0xMiden/compiler/releases/tag/v0.4.0) Rust compiler. For the first time, this release enabled compilation of smart contracts written in Rust to Miden Assembly demonstrating the end-to-end functioning of the compiler pipeline. The functionality is currently still limited, but it will be expanded in subsequent releases. See [blog post](https://miden.xyz/resource/blog/compiler-release-04) for additional details.