Today we are shipping NexusForge v2.4, the most significant performance release in the protocol's history. At its core is a full migration of our proof pipeline to Plonky3, the latest recursive SNARK framework from Polygon Labs. The result: proof generation that was previously measured in seconds now completes in milliseconds, unlocking an entirely new class of real-time agent applications.
The Numbers: From 4.8 Seconds to 380 Milliseconds
In v2.3, generating a single execution proof for a standard agent action took an average of 4.8 seconds on our reference hardware. That latency was acceptable for many batch-oriented workflows, but it created a hard ceiling for agents that need to react in real time -- liquidation bots, arbitrage agents, and high-frequency rebalancers were all constrained by proof throughput.
With Plonky3, the same proof now generates in 380 milliseconds on identical hardware -- a 12.6x improvement. On nodes equipped with GPU-accelerated proving (CUDA or Metal), we have seen times as low as 140ms. This puts NexusForge squarely in the sub-second proving tier, a threshold that has long been considered the gateway to production-grade real-time verification.
Why Plonky3 Changes Everything
Plonky3 introduces a modular arithmetic backend that lets us compose proof circuits more efficiently. Unlike its predecessor, Plonky3 supports field-agnostic recursion, which means we can verify proofs generated on one field inside circuits defined over a completely different field. This is critical for cross-chain operations, where different networks use different elliptic curves and hash functions.
The practical impact is threefold. First, agents can now execute and prove actions at a cadence that matches block times on most L1 and L2 networks. Second, proof aggregation becomes cheaper -- we can batch up to 256 proofs into a single recursive proof, reducing on-chain verification gas by 94%. Third, the new architecture opens the door to client-side proving in browser-based agent dashboards, something that was computationally infeasible before.
Agent Manifest v2: A New Format for a New Era
Alongside the prover upgrade, v2.4 introduces the Agent Manifest v2 specification. The manifest is the declarative file that defines an agent's execution parameters, constraints, and proof requirements. The v2 format adds support for conditional proof granularity -- developers can now specify which actions require individual proofs and which can be batched, giving teams fine-grained control over the cost-latency tradeoff.
Manifest v2 also introduces cross_chain_routes, a new top-level field that declares which chains an agent is authorized to interact with and what message formats it expects. This replaces the ad-hoc routing configuration from v1 and integrates directly with our new cross-chain message batching system.
Cross-Chain Message Batching
One of the most requested features from our enterprise partners has been the ability to batch cross-chain messages. In v2.3, each cross-chain action required its own proof and its own relay transaction. With v2.4, agents can accumulate messages destined for the same target chain and submit them as a single batched proof. In our internal benchmarks, a 10-message batch to Arbitrum costs 67% less gas than 10 individual messages, while adding only 50ms of additional latency for the batch aggregation step.
SDK TypeScript v4.0
To make all of this accessible, we are releasing @nexusforge/sdk v4.0 for TypeScript. The new SDK includes native support for manifest v2 authoring, streaming proof status via WebSocket, and a simplified deployment API that handles node selection and stake delegation automatically. Migration from v3.x is straightforward -- we have published a detailed guide in our documentation, and the v3 API surface remains available under a compatibility namespace through at least Q3 2026.
What's Next: The Road to v2.5
Looking ahead, v2.5 will focus on two major workstreams. The first is verifiable model inference -- proving not just that an agent executed a set of actions, but that those actions were derived from a specific model checkpoint running specific inputs. This is the last mile for full end-to-end verifiability. The second is shared proving pools, where node operators can contribute spare proving capacity to a shared marketplace, reducing costs for smaller teams and improving utilization across the network.
We are incredibly excited about this release and the applications it unlocks. If you are building on NexusForge, upgrade to v2.4 today -- the migration takes under ten minutes for most deployments. As always, join our Discord for support and feedback, and keep an eye on the changelog for incremental patch notes.