Testnet v0.14: New Client API, Wallet and Programmable Assets

Miden testnet has been upgraded to v0.14. This release again has some breaking changes, but that’s because it comes with significant updates that open new doors: a redesigned client API, a revamped wallet, programmable assets, and important progress on transaction batches and Agglayer bridging.

Read more below about what's in it, but if you can't wait to get your hands dirty – we’ve also taken the opportunity to update the docs for better readability. You can check it out now, or after reading this article.

New Client API: MidenClient

For web developers, v0.14 ships a complete redesign of the client API.

The WebClient class has been replaced by MidenClient, a resource-based API organized around the things you actually work with. Instead of a flat set of methods, you get structured resources:

client.accounts for account management
client.transactions for transaction submission and history
client.notes for note tracking and consumption
client.keystore for key management
client.compile for component and script compilation

Transactions now have high-level helpers:

await client.transactions.send({ ... })
await client.transactions.mint({ ... })
await client.transactions.consume({ ... })
await client.transactions.swap({ ... })

You can preview a transaction before submitting it, and poll for confirmation:

const preview = await tx.preview()
await client.transactions.waitFor(txId)

References to accounts and notes are flexible: the API accepts hex strings, bech32 strings, or WASM objects interchangeably. Factory methods make setup and testing clean: MidenClient.create(), MidenClient.createTestnet(), MidenClient.createMock().

For custom contracts, there are ImmutableContract and MutableContract types, and a client.compile resource for compiling components and transaction scripts. For local debugging, executeProgram lets you run view calls and inspect the stack without submitting a transaction.

For Rust developers: the client now has an AccountReader via Client::account_reader, a Keystore trait replacing TransactionAuthenticator, and typed error parsing for all node RPC endpoints so specific failure cases can be handled programmatically.

The MidenClient API is what developers will build on going forward. Its structure is also much better suited to agentic development now. So if you've been evaluating Miden for a web app, this is the right time to (re)take a proper look.

Miden Wallet

The Miden Wallet Chrome extension has received a significant update in v0.14. The wallet has been rewritten in React – it runs smoother, with substantially less code, and aligns directly with the @miden-sdk/react library that web developers already use to build on Miden.

Beyond the rewrite, this is the first release where we ran systematic stress tests on the real testnet. The note transport layer is more stable as a result, and the wallet's sync reliability reflects that.

For developers integrating wallet support into their applications, @miden-sdk/miden-wallet-adapter provides a React adapter library that handles connection management and session persistence, but also supports send, consume, and custom transaction types through a unified interface:

import { MidenFiSignerProvider } from '@miden-sdk/miden-wallet-adapter-react';
import { MidenProvider } from '@miden-sdk/react';
‍function App() {  
  return (    
    <MidenFiSignerProvider      
     appName="My Miden dApp"      
     network="testnet"    
    >      
      <MidenProvider config={{ rpcUrl: 'testnet' }}>        
        <YourApp />      
      </MidenProvider>    
    </MidenFiSignerProvider>  
  );
}

‍MidenFiSignerProvider bridges the wallet adapter into MidenProvider, so the standard @miden-sdk/react hooks (useSend, useConsume, useAccount, useSigner) work transparently against the connected wallet – no key handling required. Some wallet-specific features are not directly covered by the SDK: picking between multiple installed wallets, surfacing connect/disconnect UI states, or requesting private notes and known assets. These are all accessible through the useMidenFiWallet hook from the adapter – see the wallet-adapter repo for a full integration guide.

What's next for the wallet? Guardian integration 👀

Guardian is a coordination layer for Miden built in partnership with OpenZeppelin. It handles backup, sync, and policy enforcement for private accounts, and for the wallet, the first and main impact is it will improve the user experience dramatically around account recovery. We published an explainer recently, "What is Miden Guardian", where you can learn more about it.

Programmable Assets

Protocol v0.14 introduces asset callbacks. This is a way for the issuer of an asset to embed rules that must be evaluated every time that asset moves, regardless of who holds it or how the transaction is structured.

The clearest way to understand this is through a compliance example. Say you deploy a faucet for a regulated stablecoin. You want to ensure that only addresses not on a sanctioned list can hold or transfer it. With asset callbacks, you embed that rule at the faucet level. Now, whenever anyone sends that asset – even if the transaction is fully private – they have to generate a zero-knowledge proof that they are not on the list. The proof gets verified as part of the transaction, and critically, the proof reveals nothing about the sender beyond the fact that they pass the check. This is onchain compliance without breaking privacy.

The callbacks are also much more expressive than the sanctioned list example suggests. Future rules could check whether the sender holds a KYC credential, whether they meet an age threshold, or any other condition that can be proven in zero-knowledge. The framework is in place; the complexity of the rules is up to the issuer.

That said, we want to be direct: asset callbacks are available but not yet easy to use in practice. The missing piece is a set of standard implementations – but the good news is, OpenZeppelin is currently working on such standards, and they are expected in the coming weeks (as always the repo is open-source, feel free to check it out). Once they land, programmable assets become a practical tool for most builders, but for now it requires working close to the protocol.

Under the Hood

A few other areas that moved in v0.14, briefly:

Proving system. We've switched the VM's proving backend from Winterfell to a new system built on top of Plonky3. Rather than using Plonky3 off the shelf, we built our own STARK variant: LiftedSTARK. As far as we know, we're the first team to use this approach in practice, which improves soundness and efficiency. Building on Plonky3 makes the proving system more robust, more modular, and easier to audit and evolve. For most builders this is invisible; your contract code doesn't change.

Atomic transaction batches. The SubmitBatch endpoint is now live in the node, enabling chains of transactions that either all succeed or all fail. Client support isn't there yet – you can't use this from the Rust or web SDK today – but the core protocol piece is done.

Block building and proving separation. Block proving has been separated from the block producer. This is the architectural foundation for higher throughput, and it's in place. We're not at the throughput targets yet – there's more performance work ahead – but the structure is right and ready.

Agentic development. The repos are now structured to be agentic-friendly. For instance, if you want your favorite coding agent to know how to submit transactions using MidenClient, just point it at the miden-client repo and tell it to use the React SDK – it will be able to discover everything it needs from there.

Agglayer bridge. The protocol work is done: faucet registry with conversion metadata, FPI-based asset conversion, and GER deposit verification are all in. That means a significant milestone has been accomplished: Miden testnet is officially connected to the Agglayer, with the first live deposits and withdrawals bridging ETH between Miden and Sepolia completed. The UI is coming soon, but if you want to learn more about details, check out Gateway’s smoke test report.

What You Should Do Next

If you're building web applications:

Migrate from WebClient to MidenClient – check the migration guide for the full API mapping
Try the high-level transaction helpers (send, mint, consume) before reaching for lower-level APIs
Check out @miden-sdk/miden-wallet-adapter if your app needs wallet integration

If you're writing smart contracts:

Just starting out? The Rust Smart Contracts guide is the fastest on-ramp
Already have contracts? Run through the migration guide before upgrading
Explore asset callbacks if you're building a faucet or any asset with transfer logic – the capability is there, even if the standards aren't yet

And if you're completely new to Miden:

Try the Playground – no setup required
The docs have a new look, jump right into it and follow the path best suited to you
Join the community on Telegram

Looking forward to v0.15, mainnet is getting closer with every new testnet release…

Check out more blogs

How Miden Solves the Privacy Paradox With Guardian

Private accounts on Miden hide balances and transactions by default, but privacy breaks the coordination tools finance depends on. Miden Guardian, aka Private State Management (PSM), solves this: backup, multi-device sync, policy enforcement, and compliance, all without a custodian holding your keys.

Miden State Model

This series of blog posts has covered an overview of Miden’s architecture and a deep dive into its transaction model,

Miden × OpenZeppelin: Security, Standards and Privacy

To bring privacy and safety to real-world finance, Miden needs industry-standard smart contract security.

Go to Learn page