With the upcoming Mesa Upgrade, a natural question arises for zkApp builders: What can Mesa unlock in practice, and how can we explore these changes ahead of time?
Mesa brings protocol-level improvements that expand what zkApps can do, including faster slot times out of the box. As part of these changes, zkApps will need to be redeployed due to updated verification keys.
This is where early experimentation comes in. It allows you to prepare for the necessary redeployment while simultaneously adapting your zkApp to leverage these expanded capabilities.
At o1Labs, we have been building Mesa-compatible zkApp examples to test these limits internally and to provide educational resources for the developer community.
In this post, we introduce one of these explorations: a Payout zkApp designed to exercise the increased limits of actions, events, and account updates.
High-level Design
This example is a payout zkApp built around actions and reducers: users request a payout by dispatching an action, and a designated payer later processes the pending requests up to a specified maximum amount.
When the payer runs a payout:
- they specify the maximum amount they’re willing to pay,
- all pending requests with amounts less than or equal to that maximum are fulfilled, and
- requests above the maximum are skipped and do not contribute to any state updates.
Example:
- Alice requests 1 MINA
- Bob requests 2 MINA
- Josh requests 3 MINA
If the payer chooses to pay up to 2 MINA, Alice and Bob are paid, while Josh is skipped.
This example is intentionally simple, but the same pattern can support workflows like donations or organization-managed payments; especially when combined with primitives like credentials (to enforce eligibility) and nullifiers (to prevent double-claims).
For a deeper dive, see the Technical Details section in the documentation of this example.
Why a payout zkApp?
At first glance, this flow might look like a sequence of simple MINA transfers. The key difference is the capability to provably track your zkApp-specific metadata under concurrent usage, such as:
- the total number of fulfilled requests,
- the total amount paid out by the payer, and possibly,
- additional metadata (e.g., tracking ignored payouts or participating payers).
Without actions and reducer, updating these state variables would frequently fail due to state precondition errors (i.e., race conditions) when multiple users transact simultaneously. By utilizing actions, we achieve several benefits:
- Concurrency: multiple requests can be processed together without conflicting state updates.
- Throughput: more account updates can fit into a single transaction.
- Efficiency: transaction fees are reduced by processing multiple requests at once.
- Verifiability: application-specific metadata remains provable on-chain, without relying on off-chain indexing or explorer-based analysis.
Taken together, this makes the Payout zkApp an ideal candidate for testing Mesa’s increased limits on actions, events, and account updates, while still serving a real, understandable use case.
Design Philosophy: Exercising Mesa’s Expanded Limits
The goal isn’t to push every limit to its maximum, but to exercise them incrementally in a way that keeps the code understandable and useful as a reference.
All limits discussed in the repository were tested internally to ensure they behave as expected under Mesa. That said, this example will focus on practical coverage rather than exhaustive stress-testing. Action and event field sizes, as well as the number of account updates per transaction are kept to the minimum required by the use case. This keeps the implementation readable while still demonstrating how the increased limits can be used in real zkApp workflows.
Where relevant, the documentation also points out how specific parameters can be adjusted to push individual limits further, for developers who want to experiment or stress-test in isolation.
A Note on Security
This payout zkApp is intentionally a proof-of-concept and not a production-ready design. Some design decisions (like letting any user request a payout) are intentional, because they make it easy to generate load and exercise the increased protocol limits.
If you were adapting this pattern for production, you’d typically need to add safeguards such as request gating, explicit rate/amount limits, or nullifier-based tracking to prevent double-claims. For more context, see the repository’s Security Considerations.
Complementary Example: Mesa-Compatible Mastermind zkApp Level 2
If you’re interested in on-chain state storage, we’ve also released a prerelease version of Mastermind zkApp Level 2 example.
While the payout zkApp focuses on transaction-level limits (actions, events, and account updates), the Mastermind example highlights the increase in zkApp account state from 8 to 32 fields.
It shows how expanded on-chain state can simplify your zkApp logic and reduce constraints by avoiding more complex techniques like state packing (as used in the standard Level 2 example).
Together, these examples offer complementary views into what Mesa enables:
- Payout zkApp → transaction-level limits (actions, events, account updates)
- Mastermind Level 2 → expanded on-chain application state
Getting Started with the o1js Mesa Prerelease Package
Ready to experiment? You can start developing with the increased limits today by using the prerelease o1js package.
1. Install the Mesa `o1js` package (as seen in the repo’s package.json):
- npm i https://pkg.pr.new/o1-labs/o1js@2701
2. Configure Mesa Testnet endpoints
To deploy and interact with Mesa Testnet, configure your zkApp with the following endpoints:
- Mina node (GraphQL): https://plain-1-graphql.mina-mesa-network.gcp.o1test.net/graphql
- Archive Node API (required for events/actions): http://mesa-archive-node-api.gcp.o1test.net
Summary
The Mesa Upgrade will bring remarkable improvements to the protocol, such as faster slot times and expanded capabilities for zkApps.
You’ve now seen how we tested these changes internally, along with practical examples you can use to prepare for redeployment and start experimenting with Mesa’s expanded limits today.
We hope these examples help you prepare for redeployment, experiment with the new limits, and inspire new zkApp features enabled by Mesa.
You can explore the full source code, including deployment scripts and stress-testing notes, in the Payout zkApp Repository.
If you have feedback or questions while testing or navigating the examples, please reach out to us on Discord.
Happy coding!