The Miden Experience

[phklive]

🧑‍💻 Improving Miden’s DevEx: Insights & Recommendations

During the past few weeks, the DevRel team has been researching, testing, and analyzing the DevEx of over 15 leading blockchain ecosystems. Our goal: identify what it would take to make Miden the most developer-friendly blockchain in the space — a best-in-class crypto ecosystem.

While the current Miden roadmap outlines important efforts aroundDevEx, we’ve observed that it's primarily implementation-focused, structured from the bottom-up. We propose complementing it with a more product-focused, top-down version: see proposed roadmap. We believe this reframing will accelerate developer onboarding and empower more meaningful integrations and applications.

This post summarizes our findings and presents concrete recommendations.

---

TL;DR

If you’re short on time, here’s the quick summary of our 5 major DevEx recommendations:

1. Build an all-in-one toolchain for frictionless development
2. Improve the Miden Playground to allow fast browser-based development
3. Improve documentation with clarity, onboarding flows, and better structure
4. Add scaffolding, examples, and standard libraries to speed up building
5. Build a native solution for private note propagation

---

🧰 All-in-One Toolchain

Explanation

One of the biggest lessons from top ecosystems like Solana, Aptos, and Ethereum is the power of a batteries-included CLI that streamlines the entire development lifecycle.

We propose building a single entry-point CLI (miden) that unifies key developer actions. This would lower the learning curve, reduce setup friction, and speed up iteration. Ideally, this should work with a single install command and intuitive subcommands.

Table

Action	Proposed Miden Command	Ethereum (Foundry)	Solana (Anchor)	Aptos
Install toolchain	cargo install miden	curl -L https://foundry.paradigm.xyz | bash	cargo install anchor-cli	brew install aptos
Create local account	miden account	cast wallet new	solana-keygen new	aptos init
Fund account via faucet	miden faucet	NA	solana airdrop	aptos faucet
Create new project	miden new	forge init	anchor init	aptos move init
Build project	miden build	forge build	anchor build	aptos move compile
Test project	miden test	forge test	anchor test	aptos move test
Run local node	miden node	anvil	solana-test-validator	aptos node run-local
Deploy contract	miden deploy	forge create	anchor deploy	aptos move publish
Open block explorer (local UI)	miden scan	NA	NA	NA
Call view function (read-only)	miden call	cast call	anchor call (or script)	aptos view
Send transaction (state-changing)	miden send	cast send	anchor client	aptos move run
Simulate transaction (no commit)	miden simulate	Tenderly	NA	aptos move run --dry-run

Why It Matters

A cohesive, ergonomic CLI lowers the barrier to entry, enables rapid iteration, and minimizes developer context-switching. This pattern is seen consistently in mature ecosystems.

Goal

Offer a frictionless command-line experience where developers can go from zero to deployed Miden application with a single toolchain, under 5 minutes.

---

🧪 Improve the Miden Playground

Explanation

The developer playground is one of the most important onboarding tools in a blockchain ecosystem. It enables new developers to test, iterate, and build applications directly in the browser without needing to install anything locally. This dramatically reduces friction and increases engagement.

We recommend:

• Supporting end-to-end flows: compile → test → deploy → interact
• Adding wallet-like identity support
• Integrating faucet for account funding
• Showing logs, errors, and feedback clearly
• Allowing quick forking and sharing of apps

Table

Feature	Miden Playground	Ethereum (Remix)	Solana Playground
Web-based IDE	✅ Yes	✅ Yes	✅ Yes
Compile	✅ Yes	✅ Yes	✅ Yes
Deploy	❌ No	✅ Yes	✅ Yes
Test support	❌ No	✅ Built-in	✅ With Anchor test files
Wallet integration	❌ No	✅ MetaMask	✅ Phantom
Faucet or test tokens	❌ No	✅ Plugin	✅ Built-in
End-to-end flow	❌ No	✅ Yes	✅ Yes

Goal

Enable developers to build and deploy a full end-to-end Miden application in the browser within 5 minutes — no installation required.

---

📖 Improve Documentation

Explanation

Documentation is the first thing developers encounter. It must guide them from curiosity to shipping code. Miden’s current docs are deep and technical, but lack onboarding clarity.

We recommend:

• Adding a TL;DR page as entrypoint
• Building a 0→100 "Getting Started" flow
• Moving to Mintlify or Docusaurus
• AI-enhanced search (ChatGPT-style)
• Tutorials, versioning, videos, and examples
• Writing documentation in simplified terms

Table

Ecosystem	Docs Structure	Onboarding Clarity	Examples / Scaffolding	AI Search	TL;DR Overview	Language Complexity
Starknet	✅ Simple	✅ Clear 0 → 100	✅ Available	✅ Yes	✅ Yes	🟠 Medium (Cairo)
Ethereum	✅ Modular & Mature	✅ Excellent	✅ Extensive	❌ No	✅ Yes	🟢 Easy (Solidity)
Solana	⚠️ Fragmented	❌ Confusing at start	✅ Anchor templates	✅ Yes	⚠️ Partial	🔴 Complex (Rust)
Aptos	⚠️ Verbose & Deep	❌ Steep learning curve	⚠️ Some	✅ Yes	❌ No	🔴 Complex (Move)
Miden	⚠️ Theoretical & deep	❌ Lacks clear flow	⚠️ Few (WIP)	❌ No	❌ No	🔴 Very High (MASM)

Goal

Create the most intuitive, example-rich blockchain documentation that takes developers from 0 to deployed in less than 10 minutes.

---

🧱 Scaffolding, Examples & Standards

Explanation

Many developers struggle to know where to start. The best ecosystems scaffold best practices, provide real-world examples, and include safe, composable standards.

We recommend:

• Adding CLI scaffolding templates (e.g., miden new my-amm --template amm)
• Building and maintaining example apps: voting, vaults, bridges, DAOs
• Creating audited, reusable standards: tokens, Merkle proofs, access control

Table

Ecosystem	CLI Scaffold Tool	Example Apps Repo	Standards / Primitives	Dev Speed Impact
Starknet	✅ protostar new	✅ starknet-examples	✅ cairo-lang/std	🟢 High
Ethereum	✅ forge init	✅ Scaffold-ETH, examples	✅ OpenZeppelin	🟢 High
Solana	✅ anchor init	✅ Anchor examples	✅ Solana Program Library	🟢 High
Aptos	⚠️ aptos move init	⚠️ Sparse repos	⚠️ Few standards	🟡 Medium
Miden	❌ Not available	⚠️ 1-2 examples (deep)	❌ No official standards	🔴 Low

Goal

Make it possible to go from miden new myapp --template vault to deployed, tested app in under 15 minutes — with standards, examples, and scaffolding all in sync.

---

🔐 Private Note Propagation

Explanation

Miden uses private notes to enable privacy-preserving logic, but today there’s no native way to propagate these notes off-chain. This limits Miden’s ability to support private apps.

We recommend:

• A minimal relay layer (P2P or centralized) for note routing
• Encryption of notes on-chain

Goal

Enable reliable, private, and user-friendly off-chain / on-chain propagation of private notes in Miden — via a standard protocol, relay layer, or wallet integration.

---

✅ Conclusion

Through research and internal testing, we’ve identified five key pillars that will transform Miden’s DevEx. If we deliver on these five fronts, we believe Miden can offer One of the most-productive blockchain environment for developers.

[greenhat]

I studied the docs for the Solana's Anchor and I see the value in having an all-in-one CLI.
We started working on our toolchain CLI. It seems like we should consider its relation and maybe transition its responsibilities to all-in-one miden CLI. @bitwalker What do you think?

I suggest we sunset our cargo extension in favor of miden new and miden build. I'll be happy to take care of them.
As for the miden test I'd rather try to stick to the pure cargo test and leverage the whole Rust testing ecosystem (think of code actions to run a selected test via LSP in your IDE, etc.) unless we absolutely have to introduce our own miden test. Besides, there are others cargo commands that will be useful for our developers (update, clean, etc.) so we have to rely on cargo anyway.

[phklive]

For test, clean, update, etc...

I believe that we could wrap around the cargo test, etc... commands so we have a coherent package.

Basically simply miden test just under the hood passes the arguments to cargo test.

[greenhat]

Yes, it's a viable option. I'm not a fan of this approach for the following reasons:

1. The context of the miden CLI is much larger (basically everything) than cargo, so some cargo commands start to sound ambiguous. E.g. miden update for a newcomer sounds more like "update deployed contract" than "update dependencies in the Rust project".
2. Insulating smart contract developers from the cargo seems suboptimal, given they are writing Rust code and the Rust ecosystem is our moat.

[bitwalker]

I definitely think we should avoid trying to combine everything literally into a single CLI (as opposed to a Git-style porcelain approach). There are multiple reasons for that:

• The surface area of such a CLI would be enormous, would be critical to every team of the Miden project, and would certainly be a bottleneck for development and release.
• Dependency management would almost certainly be a nightmare.
• Huge CLIs are slow to start and consume much more memory
• The value in smaller components that work together is that they can tailor themselves to their purpose, be released more frequently, and with less coordination, and be maintained by the respective team as part of their normal development flow (akin to how cargo-miden is maintained within the compiler repo, as part of our regular development process).

As an aside, I think we should avoid conflating two closely related activities:

• Toolchain Management (bootstrapping the environment, integrating with the user's shell, fetching/installing components, versioning and updates)
• Toolchain Usage (creating a project, building/testing/deploying it, etc., using the currently installed/selected toolchain)

With that in mind, I think our approach should be comprised of two tools, midenup and miden, as follows:

• Use midenup for toolchain management. This would involve a user running cargo install midenup && midenup init to walk through configuring their environment and installing the desired set of initial components. Updating the currently installed toolchain components would be as simple as running midenup update. The midenup tool gets information about available toolchains, and their components, by fetching it from GitHub (published as JSON via GitHub Pages). Thus new versions and components can be made available without having to release a new version of midenup itself.
• Toolchains would be described either in the form of channels, e.g. stable, or explicit versions. Toolchain versions I think could be based on the Miden VM version initially, since it is currently the most foundational component, and the one most likely to break compatibility; but we can also version toolchains independently, so that we can more accurately represent changes between toolchain versions. Channels are a way of staying up to date with latest versions of all components without pinning a version. For example, the stable channel would always reflect the latest versions of all components, and running midenup update stable would update to those latest versions, even if there are breaking changes since the last time you updated it. A channel corresponding to a specific Miden version, e.g. 0.15.0, would always reflect the latest versions of all components compatible with that toolchain version, i.e. if a new version of the Miden node is released, but it isn't backwards-compatible with 0.15.0, then running midenup update 0.15.0 would ignore that new version.
• The midenup CLI would provide shell integration so that switching to a directory with a miden-toolchain.toml file would activate the toolchain specified in that file. If the toolchain is not currently installed, midenup would do so the first time miden is run. Toolchains are activated at a low-level by setting MIDEN_SYSROOT to the appropriate toolchain root directory, and prepending $MIDEN_SYSROOT/bin to the current PATH, making all of the executables of that toolchain available for use.
• Provide a miden executable which is a thin wrapper around the set of binaries installed by midenup, and integrates with midenup when necessary. The miden executable would be installed by midenup init. This executable would consist of any number of subcommands implemented as one of the following:
  1. Native subcommands, i.e. functionality which is implemented as part of the miden binary. It is unlikely that there would be many of these, but things related to global settings and such might be appropriate for this kind of subcommand.
  2. External subcommands, i.e. functionality which is implemented in an executable that is expected to be present in the user's PATH, and which requires no pre-processing of its arguments. When invoking this type of subcommand, the miden CLI would execute the external tool as a subprocess, forwarding all of the arguments. For example, miden foo [ARGS..] would expect an executable in the current PATH called miden-foo, which would be invoked as miden-foo [ARGS..]. If miden-foo is not found, we could either inform the user that they need to install that component; prompt them if they'd like to install it; or automatically install it.
  3. Aliased subcommands, i.e. functionality which is implemented externally as in 2, but in a way that we wish to expose differently via miden. For example, miden send might correspond to something like miden-client transaction send. This form of subcommand essentially converts/forwards its arguments to whatever is expected by the underlying executable, as if it had been invoked as a regular external subcommand.

Putting all of this together, we get the following:

• A streamlined installer and updater for all Miden toolchain components
• Simple toolchain management (i.e. for doing development in different projects that have different version requirements)
• The benefits of a unified CLI interface, without the downsides of trying to build everything into a single giant executable (if we could even do so)
• Individual components can be released/versioned/updated independently, but end users don't need to install/manage them all, they can simply run midenup update when they wish to pick up updates that are compatible with their current channel/toolchain.

Work on midenup has already started here (the repo was just created today, so it may be a few days before the repo where prototyping started gets merged in, but that's where things will live going forward). The immediate goal is to build an MVP of the midenup functionality, i.e. bootstrapping the stable toolchain with a subset of the Miden components, namely the VM, compiler, cargo-miden, and standard and transaction kernel libraries.

From there, the next step is to define the miden CLI as described above. Following that, we'll want to create/rename all of the executables that we wish to expose via miden wherever they live today (e.g. miden executables in the VM and client repos would be renamed to miden-run (my suggestion) and miden-client respectively). Once that's done, we can expose more components for installation via midenup. Further improvements to both midenup and miden can be identified and implemented from there.