Miden helps the future of finance handle privacy. As mainnet approaches, we've kept working with the team on developer tooling. This post covers what we shipped in the Miden ecosystem in Q3 2026.
Last quarter ended with the basics in place. End-to-end transaction debugging worked, but the debugger still showed more of the VM than of the Rust code developers wrote. miden call could invoke a contract, but it printed raw field elements. Contract verification had become shared infrastructure, but there was no public place to read verified source. In Q3, each of these got a proper developer-facing version, while Miden went through two testnet upgrades.
The work covers five areas: the debugger and compiler, Miden Foundry-like tooling, source code verification, the Miden Local Package Registry, and Miden Playground.
Debugger & Compiler
Why it matters: Developers write Miden contracts in Rust, so they should be able to debug them in Rust. This quarter the debugger moved closer to how Rust developers think: real types, real call stacks, and executions they can reproduce.
In Q2, developers could step through a full transaction. In Q3, we made what they see at each step much more accurate. Five features stand out.
Rust types. Variables display with their declared Rust types: structs show field names, and enums and u256 values are decoded. Before, many showed up as anonymous structures or raw stack elements.
Inlined functions in stack traces. The compiler inlines small functions, which used to make them disappear from backtraces. They now appear as [inlined] frames, as in LLDB and GDB, so a backtrace matches the call chain in the Rust source.
Record and replay. miden-client can record a transaction's execution, including the non-deterministic inputs the VM receives. The debugger replays it exactly, so a failing transaction can be reproduced and stepped through as often as needed, without going back to the network.
Profiling from replays. Flamegraphs, added in Q2 for tests, can now be generated from any recorded transaction, showing where cycles go in a real execution.
Python scripting. As in LLDB and GDB, developers can write Python pretty-printers for their own types, or add custom commands, without modifying the debugger.
Next up: Metadata-driven stack traces, where the assembler records each procedure's boundaries instead of the debugger inferring them at runtime, and IDE integration so the same experience runs inside the editor.
Miden Foundry-like tooling
Why it matters: Developers need to call contracts, test them, inspect transactions, and understand what happened without decoding field elements by hand. This quarter, the Miden CLI started speaking the developer's types.
The main release is typed output for miden call, available from midenup 1.0.1 and covered in a dedicated post: Introducing miden call. miden call runs a procedure on a Miden account locally, without submitting anything to the chain, so it's instant, free, and repeatable. It reads procedure signatures, so arguments go in as readable values like account IDs or assets, and results come back decoded instead of as raw hex. State-changing calls also list the storage slots and map entries they would modify. It works on your own accounts and, read-only, on public accounts deployed by others. miden account --inspect lists an account's procedures and their signatures.
Transaction inspection. miden tx --show displays an existing transaction by ID, with its metadata and notes. For standard notes (P2ID, P2IDE, SWAP, PSWAP), it decodes the note storage: who a P2ID is for, the reclaim and timelock heights of a P2IDE, or the asset a SWAP requests.
Safer transaction tests. MockChain is the local chain simulator that miden-testing uses to run transactions in tests. Its old transaction API had a quiet trap: notes added to a transaction after build_tx_context were ignored, so a test could pass without testing what it was meant to. We replaced it with a single builder, MockChain::build_transaction, which only fetches the transaction's inputs from the chain once every note is known, so nothing is dropped. The new API shipped with 0.16, replacing build_tx_context entirely.
Next up: miden call --trace, to display a call tree with per-function cycle counts plus the transaction effects (storage, notes, vault, nonce) in one view, and miden send, to submit transactions on-chain with the same typed interface as miden call.
Source Code Verification
Why it matters: Privacy is at the core of Miden. Verifying accounts and notes is how you make sure the code you interact with doesn't accidentally leak your private data.
In Q2, verification became a standalone service. In Q3, we made it cover more of the chain automatically and gave it two public web interfaces.
Verify once, match everywhere. Verification is now tied to the code, not to a single account or note ID. Once a contract or note is verified, every account or note running the same on-chain code is verified automatically. Upgraded contracts need to be verified again, because their code no longer matches.
Web verifier. Miden Verify verifies an account or note from the browser. You enter its ID, pick the network, and select the Rust project folder. The service recompiles the source and checks it against what's on-chain.
Verified-resources registry. Miden Registry is a public, browsable list of everything that has been verified. Each entry shows the package digest, procedure signatures, dependencies, when and how it was verified, and the full Rust source.
MidenScan integration. Both apps are now integrated with MidenScan. The explorer's Code tab links verified accounts and notes to their source in Miden Registry, so verified code is one click away from anything you look up on-chain.
Next up: Automatic verification of accounts when they're deployed with midenup, so verification becomes part of deployment instead of a separate step. The verification service, Miden Verify, and Miden Registry will also support mainnet from day one.
Miden Local Package Registry
Why it matters: Packages are how Miden code gets built, shared, and deployed. A better local package registry improves the developer experience day to day, and will let contracts be verified automatically when they're deployed.
Most Miden commands that need a package take a path to a compiled .masp file. Our vision is a local registry of the packages you work with: packages would come from your own builds, from GitHub or crates.io, or from Miden Registry, a repository of verified packages. Commands could then reference a package by name (-p counter-contract@0.1.0). Eventually, the registry would remember which package each account was deployed with, so the flag can be dropped entirely.
Next up: The first improvements to the Miden Local Package Registry, starting with referencing packages by name@version.
Playground
Why it matters: The Playground is where many developers first try Miden. It needs to follow the chain closely, so what developers learn there matches what they'll deploy.
The Playground went through both testnet upgrades this quarter, 0.15 and then 0.16, with every tutorial and example migrated. It's ready to follow Miden to mainnet with 0.17.
Transaction fees. Fees are one of the fundamental changes in 0.16. Every transaction preview now shows its fee next to its effects on notes, storage, and the vault, and new accounts are funded automatically so developers can transact right away.
Upstream contributions. Issues some users hit in the Playground led to bug fixes in Miden's official web SDK: a WebAssembly loading failure in Safari and on iOS browsers, and a database migration race condition that blocked returning users. We shipped workarounds in the Playground and reported both upstream with full diagnostics, so every app built on the SDK benefits.
Next up: Wallet tutorials reworked around Bread Wallet, and mainnet support with the 0.17 upgrade.
Most of what Q2 left rough is now in developers' hands. The debugger shows Rust types, inlined frames, and replayable executions. miden call speaks the developer's types, miden tx --show decodes standard notes, MockChain tests can no longer silently drop notes, and call tracing is close behind. Verification covers every account or note running verified code, and anyone can browse the results in Miden Registry or from MidenScan. The Miden Local Package Registry lays out how packages will be referenced by name, and eventually verified as they're deployed. The Playground tracked two testnet upgrades and is ready for mainnet. As mainnet approaches, we'll keep working with the Miden team on the developer tooling builders need to ship on day one.