According to Ori Newman, Kaspa could gain useful programming features sooner by adding covenants, rather than waiting for the deeper changes needed for vProgs. vProgs, short for verifiable programs, are a planned system that would let separate programs on Kaspa share state and work together. [1][2] Those covenants also support the later vProgs work. ZK (zero-knowledge) verification arrived with the broader Toccata upgrade, which went live on 30 June 2026; the shared-state vProgs application path remains under construction. [3][1][2]
Ori’s reason: a smaller change with useful results
In his 7 September 2026 interview with XXIM, Ori explained that the covenant change he initially wanted was not very large or deep. He thought it could give Kaspa much more ability to express application rules with substantially less effort than introducing vProgs, which would reach much deeper into the system. [3]
A covenant is a rule attached to coins that restricts how a later transaction can spend them. Toccata brought these programmable transaction outputs to Kaspa, together with transaction inspection, ZK verification and sequencing support. These are capabilities on Kaspa’s base network, not a completed vProgs runtime. [2]
Ori also gave a second reason for doing this work first: many things in vProgs would need covenant support on the base network anyway. The work was therefore both useful immediately and preparation for the more complex programming system. [3]
He said he raised the idea with Yonatan Sompolinsky and Michael Sutton, and gave a lecture to the Kaspa community to start discussion. In Ori’s account, recognizing that vProgs would take considerable time helped lead to the approach of advancing programmability with covenants first and continuing with more complex work afterward. [3]
Why that brought ZK verification before vProgs
Asked later in the same interview when ZK was added to Toccata, Ori said it was planned almost from the start. The idea was not to delay programmability and to bring whatever was possible now, with covenants as one side and ZK opcodes as the other. He said the ZK opcodes are self-contained: the network does not have to check much beyond knowing how to verify the supported proof types. [4]
Michael’s 3 April 2026 Toccata outlook supplies the connection between Ori’s original covenant effort and the larger upgrade. He wrote that the effort began with Ori’s proposal to introduce covenants into Kaspa’s script engine, then expanded beyond covenants. Its scope included both direct covenant programming and infrastructure for applications using cryptographic proofs. [1]
ZK verification means checking a cryptographic proof that a program ran correctly, rather than running the whole calculation again. The KIP-16 specification, now marked Active, describes proofs showing that a given program, run with given inputs, produced a given output. That makes proof checking a useful building block in its own right, rather than something that must wait for a complete vProgs system. [5]
The code for that proof-checking opcode was merged on 5 February 2026 into the Rusty Kaspa branch where the Toccata upgrade was being built. Toccata subsequently made ZK verification live on mainnet on 30 June 2026. The community build page distinguishes those live capabilities from vProgs, whose runtime is still evolving and is not yet a stable external developer interface. [6][2]
A telling detail in Ori’s explanation is that some covenant-based operations can require several transactions, but he said one or two would be enough in most cases. His argument was about delivering substantial practical capability through a smaller change, not completing every part of the future programming model at once. Watch Ori’s XXIM interview at the relevant discussion for his explanation of that choice and why it also helps vProgs. [3]