Polygon Miden Alpha Testnet v6 is Live

As pioneers continue to build sovereign dApps on Polygon Miden, the team is rolling out new features for builders. Today, Miden Alpha Testnet v6 launched with a more stable environment and additional functionality, including making it easier (and faster) for end-users to create accounts.

Explore the new Miden tutorials and start building on the testnet today. 

Miden reimagines how blockchains are built and operated by allowing users to prove their own state transitions.  

This approach allows developers to build dApps where users can independently prove local state transition, ensuring greater sovereignty and significantly higher throughput compared to traditional architectures.

Miden is making DeFi and crypto payments better and more efficient by building together with pioneers in the space, including::

1. Arcane Finance: A privacy-centric DEX on Aleo, exploring novel, high-throughput DeFi solutions.
2. Pragma: The best-working oracle on StarkNet, extending services to Miden. 
3. VeriSync Labs: Specing out a perpetual market  on Miden. 

In Miden Alpha Testnet v6, builders can use a more powerful foreign procedure invocation including also private smart contracts, account creation is way faster, the VM switched to element-addressable memory, and our Node has a real mempool.The next update will be our Beta testnet, where users can write smart contracts in Rust. So, what new features does the latest testnet bring to builders, and how does it upgrade the chain?Added features to foreign procedure invocationIn the last release, Alpha v5, we introduced the concept of foreign procedure invocation (FPI). This enabled accounts to read a particular state of another (foreign) account, and include that information in their transaction. For example note and transaction scripts can read a certain foreign account state during execution and include that information as a parameter. Builders can create note scripts that read the state of an oracle smart contract and use the information as a price for a SWAP. But this initial version of FPI was limited to public smart contracts and users were only able to read one type of storage. In this release, we expand FPI functionality in two important ways:

• First, note and transaction scripts can now access values from storage maps stored at foreign accounts. StorageMaps are key / value stores in smart contracts with quasi-unlimited space. Now, users can read it in their transactions. That way it is possible to store more than 255 price pairs in an oracle smart contract for other smart contracts to read from.
• Second, foreign accounts don’t have to be public anymore, i.e., stored with full data on-chain. Now, private account states can also be read and processed in transactions. The executing entity doesn’t need to know the complete foreign and private account data but the values and inclusion paths it wants to read. This is particularly interesting in two cases, first for privacy, but second, whenever the state of the private account is too big to store it onchain.

Improved account handling

There are major updates for accounts, Miden’s version of smart contracts. Builders need to update their code as there is a breaking change. An AccountId now takes two Felt’s. As an example, this changes the inputs to P2ID or P2IDR notes or how assets are constructed in MASM. See here for a detailed explanation.

1st felt: [random (56 bits) | storage mode (2 bits) | type (2 bits) | version (4 bits)]
2nd felt: [block_epoch (16 bits) | random (40 bits) | 8 zero bits]

The change allows us to make account creation way faster while maintaining the same level of security. Account creation is faster, because the Proof of Work difficulty needed when creating an account decreased significantly. This drastically improves the UX. However, PoW was put in there first to make potential rainbow table attacks more expensive. In those attacks, the attacker pre-computes many different account Ids and tries to block other accounts or even consume notes on their behalf. Decreasing PoW means it is easier to create such tables. So in order to keep Miden safe and improve the UX, we increased the account Id to 120 bits from 64 bits before. 

Another major change, Alpha v6 introduces account component templates. These allow builders to add custom functionality to accounts more easily. Builders can create templates to instantiate account components and inject them into their client. Account components in Miden provide a modular way to define smart contract behavior. Each component specifies its own code library, storage layout, and supported account types, ensuring clear boundaries and independent execution. 

Builders can combine multiple components to build custom account logic while maintaining strict control over state access. For example, a wallet component can be combined with a signature component and a user-defined custom component. For example, the wallet component allows users to send and receive assets. This can be combined with a custom component that allows users to register their account ID in the smart contract when an asset is received. The custom component could also add a function that allows registered accounts to withdraw from the account. Now the combination of the wallet component and the custom component builds an easy deposit contract. This approach enhances flexibility, prevents unintended interactions, and enables easy-to-write, safe smart contracts.

The Miden client now allows the injection of a template via the CLI by providing a simple file, like this:

# Create a new wallet that includes extra components from local templates
miden new-wallet --extra-components template1,template2

Element-addressable memory in Miden Assembly 

The Miden VM now features element-addressable memory, replacing the previous word-addressable model. This means builders can retrieve a single element from memory directly, rather than fetching an entire Word (4 Felts) and discarding the unnecessary ones.

This seemingly small shift unlocks major efficiency gains across the board. The VM executes operations more efficiently, while the compiler benefits from a leaner, smarter memory model—reducing unnecessary assumptions about value locations and streamlining code generation. Even in hand-written Miden Assembly (MASM), developers no longer need to extract full Words just to access a single Felt, eliminating unnecessary computational overhead.

For builders writing smart contracts or note scripts, this change affects how

mem_store

and

mem_load

work. Previously, these commands always stored and loaded full Words, padding unused elements with zeros. Now, they operate directly on single elements, cutting out redundant steps and making memory access simpler, faster, and more cost-efficient.

Delegated proving - a pragmatic approach

Client-side proving on low-power devices can be slow, but Miden offers a pragmatic alternative: delegated proving. Instead of waiting for complex computations to finish on your device, you can hand off proof generation to a service, ensuring a consistent 1-2 second proving time, even on mobile.

With this release, we’ve taken it a step further. A new load balancer now distributes proving tasks efficiently across multiple workers, keeping performance smooth under any load. Best of all, anyone can run a prover service using our open-source code.

Users stay in control—choosing a delegated prover per transaction in the Rust client, WebClient, or Miden Wallet. Whether you prioritize speed, privacy, or running your own proving service, Miden gives you the flexibility to decide.

Rewrite of the mempool

The mempool now uses a DAG instead of a FIFO queue, enabling transaction expiration and other cool block-building strategies. The first iteration of the Miden node's mempool was implemented as a simple FIFO queue. Transactions were placed sequentially into batches, and then into blocks in the order they arrived. This was easy to implement correctly which made it ideal as the initial implementation. A FIFO implementation has several draw-backs. It does not allow for prioritizing transactions, preventing selection strategies e.g. prioritizing transactions with higher fees. Notably this also fails to support transaction expiration as the FIFO did not retain transaction dependencies, making it impossible to "rollback" expired transactions from the mempool state.

The new implementation uses a DAG representation, which maps the transactions relation to each other, allowing for a more flexible batch and block-building strategy. At the moment, transactions are simply randomly selected from the edges of the DAG (aka only transactions whose parents are all already included). We plan on improving this by prioritizing soon-to-expire transactions where possible.

As for transaction expiration, with Alpha 6, transactions may optionally include an expiration block height. This prevents the transaction from being included in a block once the chain exceeds this height. The node will drop expired transactions from the mempool - including all transactions based on them. Transaction expiration is useful in a variety of situations. Use it to avoid using stale information, or to prevent transactions stuck in mempool jail. This avoids situations where the node indefinitely holds a transaction in the mempool without including it in a block.

Developers and pioneers can look up all changes for the new version in the corresponding changelogs (base, client, node).

This new version focuses on developer-facing features but includes many other changes, simplifications, and improvements behind the scenes.

What's Next?

In the coming weeks, expect the following:

• A fully working Rust compiler
• Excellent tutorials and documentation
• Network transactions

Tune into the blog and our social channels to keep up with updates about Polygon.

The future of Web3 is aggregated.

Website | Farcaster | X (Twitter) | Forum | Telegram | Discord | Instagram | LinkedIn | Polygon Knowledge Layer