Testnet v0.13: Major DevEx & Protocol Improvements

Miden testnet has been upgraded to v0.13. This is the biggest release since we launched testnet – it touches the developer experience end-to-end, from how you name storage slots to how fast blocks finalize.

This post is for builders already building on Miden, but also for those evaluating it for the first time. If you're in the first camp, you'll want to read this alongside the migration guide. If you're in the second, this should give you a good sense of where Miden is headed.

TLDR: v0.13 makes building on Miden more intuitive while hardening the protocol for what's ahead.

The Big Picture

We made a deliberate choice with v0.13: group breaking changes into a couple releases only rather than spreading them across several. That means more to update at once, but fewer disruptions over time. We paired everything with a comprehensive migration guide to make the transition as smooth as possible.

The changes cluster around two themes. First, developer experience: named storage, unified auth, cleaner APIs, better naming, and comprehensive new documentation. Second, protocol maturity: faster blocks, validator architecture, network monitoring, new crypto primitives. Let's walk through the most significant changes.

React SDK for Web Developers

If you're building web applications on Miden, this one's for you. We're shipping @miden-sdk/react, a hooks library that gives you idiomatic React bindings for the Miden client.

Instead of wiring up WASM clients manually, you get hooks that handle state management, syncing, and transaction submission the way React developers expect. The SDK also handles concurrency – under the hood, it uses the Web Locks API to coordinate sync calls across tabs and components, with result coalescing so you're not duplicating work.

This is the beginning of our push to make Miden accessible to frontend developers, not just Rust and zero-knowledge engineers. Stay tuned on that front, there is a lot more coming in the next releases…

New Documentation: Writing Smart Contracts in Rust

Alongside the protocol changes, we've shipped a complete documentation overhaul for writing smart contracts on Miden – trust us, you’ll want to check out this one.

The new Rust Smart Contracts section is a ground-up guide covering everything you need to go from zero to a deployed contract. It includes:

• Getting started – setup, first contract, development workflow
• API reference – comprehensive reference for the smart contract API
• Type system – how Miden's type system works and how to define custom types
• Design patterns – battle-tested patterns for structuring contract logic
• Account operations – interacting with accounts, storage access, and component architecture
• Transactions – note handling, authentication, transaction context, and cross-component calls

You now have a proper developer reference to build from scratch. If you've been waiting for a clear on-ramp to building smart contracts on Miden in Rust, this is it.

A huge shoutout to the DevRel team who put in serious work to deliver these docs alongside the v0.13 release. Shipping a major protocol upgrade is one thing; but shipping it with documentation this thorough is what actually makes it usable. Kudos to them, builders certainly thank them!

Other Top Changes for Builders

Named Storage Slots

This is the change you'll feel most in day-to-day development.

Previously, accessing account storage looked like this – cryptic numeric indices where you had to remember what slot 0, slot 1, slot 2 meant:

account.storage().get_item(0)
account.storage().get_item(1)

‍

Now storage slots have names:

account.storage().get_item("balance")
account.storage().get_item("owner")

‍

It's a small change syntactically but a big one ergonomically. Your code is now self-documenting. You don't need to cross-reference slot indices with documentation. New team members can read your contract code and understand what it does. And an entire class of off-by-one bugs simply disappears.

Cleaner Note Metadata and Attachments

Notes are one of Miden's core primitives, and their metadata layer was getting unwieldy. The aux and NoteExecutionHint fields were overloaded – carrying both routing information and payload data in ways that weren't always clear.

v0.13 introduces NoteAttachment, a dedicated structure that cleanly separates note payloads from metadata. We've also introduced NetworkAccountTarget as the standard way to route network transactions, replacing the old NoteTag::NetworkAccount pattern.

And one practical improvement: note input capacity has been increased 8x, from 128 to 1024 elements. If you were bumping up against the old limit when passing data through notes, you have a lot more room now.

Unified Authentication via AuthScheme

Authentication used to involve several scattered patterns. Different key types handled differently, numeric identifiers for auth methods, separate APIs for different schemes... It was workable but inconsistent.

Now there's a single AuthScheme enum that covers all supported authentication methods. Whether you're using Falcon-512 or ECDSA, you go through the same interface. The client APIs have been updated to match: createAuthComponentFromSecretKey gives you a single entry point, and SecretKey has been consolidated into AuthSecretKey.

One consistent way to handle auth across the whole stack.

Simplified Input Notes

If you've worked with Miden transactions, you know that input notes used to be split into authenticated and unauthenticated categories, each with their own methods and handling paths. This was a source of boilerplate and conceptual overhead.

v0.13 unifies them into a single input_notes interface. Less code, simpler mental model, fewer places for things to go wrong. We've also added helper methods like read_foreign_account_inputs() and read_vault_asset_witnesses() that make common patterns more ergonomic.

Better Naming Across the Board

Names should tell you what things do. We renamed two core crates:

• miden-objects → miden-protocol
• miden-lib → miden-standards

And in the VM layer:

• The MASM standard library is now miden::core
• StdLibrary → CoreLibrary

There is a cosmetic aspect to it, but it also supports better DX: when a new developer looks at your Cargo.toml now, miden-protocol and miden-standards immediately communicate what those dependencies are for. The old names didn't.

To update, replace the crate names in your Cargo.toml and run cargo update && cargo build. Again, the migration guide has the full details.

New Crypto Capabilities (VM v0.20)

The Miden VM has jumped to v0.20, bringing three new cryptographic primitives that expand what you can do onchain.

SHA-512 hashing. Available as a precompile at miden::core::crypto::hashes::sha512. This is important for interop – SHA-512 is widely used outside the zero-knowledge world, and being able to verify SHA-512 hashes inside the VM means you can validate data from external systems without offchain workarounds.

Ed25519 signature verification. EdDSA (Ed25519) is one of the most widely deployed signature schemes – and is most notably used by Solana. Now you can verify Ed25519 signatures directly in the VM via the precompile at miden::core::crypto::dsa::eddsa_ed25519. After ECDSA (used by EVM chains) in the last release, this opens the door to verifying signatures from systems like Solana, SSH keys, and any other ecosystems that use Ed25519.

AEAD encryption. The new crypto_stream instruction enables authenticated encryption with associated data. This is a building block for encrypted onchain computation – you can encrypt data, prove computations over it, and verify authenticity, all within the VM.

Together, these primitives make Miden significantly more interoperable and unlock use cases that require working across cryptographic ecosystems.

Under the Hood: Protocol and Network

While the developer-facing changes get the headlines, the protocol layer has been getting serious work too. Here are some highlights.

Faster blocks. The default block interval has been reduced from 5 seconds to 2 seconds. That means faster inclusion and quicker feedback for transactions. To support this, we've increased the retained account tree history from 33 to 100 blocks, giving clients more time to sync without losing context.

Smarter network monitoring. The network monitor now tracks mempool statistics, transaction latency, and success rates. It monitors explorer status, performs gRPC-Web health probes, and marks the chain as unhealthy if block production stalls. Reminder, you can always check our Network Status Dashboard for visibility into the network’s health.

More precise note queries. Last but not least, a nice-to-have improvement: network note queries now use full account IDs instead of 30-bit prefixes, eliminating ambiguity when querying for notes targeting specific accounts.

Bottom line is, the network is steadily moving toward mainnet readiness.

Client and Tooling Updates

Beyond the React SDK, the client stack has seen significant improvements as well.

Pagination for sync endpoints. Syncing large account state no longer risks hitting response size limits. The sync_nullifiers, sync_storage_maps, and sync_account_vault endpoints now support pagination, handling large datasets gracefully.

Remote prover timeout configuration. The new --remote-prover-timeout CLI flag lets you set timeouts for remote proving, which is especially useful when proving complex transactions that take longer than the default window.

Web Locks API for concurrent sync safety. If your web app has multiple tabs or components calling syncState(), the client now coordinates these calls automatically using the Web Locks API. Duplicate syncs are coalesced, preventing race conditions.

AccountId parsing. The new AccountId::parse() helper accepts both hex and bech32 formats, so you no longer need separate parsing logic depending on the input format. On the web side, there's a matching fromBech32 convenience function.

Multiple WebClient instances. You can now run multiple WebClient instances in the same browser by providing optional database names, useful for apps that need to manage multiple accounts or contexts.

MASM Syntax Modernization

The VM's assembly syntax has been updated to align more closely with Rust conventions. Hash function naming has been standardized: hash_2to1 is now merge, hash_1to1 is now hash, and the standard library namespace has been reorganized under miden::core.

If you're writing MASM directly, check the migration guide for the full list of renames.

What You Should Do Next

If you're already building on Miden:

1. Read the migration guide
2. Update your dependencies: rename miden-objects to miden-protocol and miden-lib to miden-standards
3. Run cargo update && cargo build and work through any compilation errors
4. Test your transactions against the new testnet

If you're writing smart contracts:

1. Start with the new Rust Smart Contracts docs – they cover the full workflow
2. Adopt named storage slots – your future self will thank you
3. Update note handling to use NoteAttachment and NetworkAccountTarget
4. Explore the new crypto primitives if you need cross-ecosystem interop

If you're building web applications:

1. Check out @miden-sdk/react for idiomatic React integration
2. Take advantage of fromBech32 and the Web Locks API for cleaner client code

If you're new to Miden:

1. Start with the Rust Smart Contracts guide – it's the fastest path to building something real
2. Explore the full documentation
3. Join the conversation on Telegram

‍

Now, what’s planned for the next release v0.14?

Two things we’re particularly excited about: programmable assets (i.e. encoding logic directly into a faucet so it executes at every asset transfer), and protocol improvements aimed at significantly increasing throughput…

In the meantime, happy building on v0.13!