Igra and Toccata: How Kaspa’s Interim EVM Layers Shape the Run‑Up to Covenants

Igra, Covenants and the in‑between

As Kaspa approaches the Covenant hard fork (branded “Toccata”), third‑party execution layers have already started to fill the programmable‑execution gap. The most visible example is the Igra Network, a public EVM‑compatible layer that launched in March and bills itself as a "based rollup" that uses Kaspa miners for ordering and inclusion ^[3]. That practical, production‑grade rollout changes how builders and indexers should approach the months leading to Toccata’s mainnet activation window.

What Toccata brings — and when

Toccata is Kaspa’s Covenant upgrade that introduces two programmability paths: a native L1 compiler/runtime called SilverScript and zk‑centric covenants that can leverage new opcodes and on‑chain verifiers. The Toccata rollout also bundles several KIPs intended to support these capabilities, including KIP‑16 (zk opcodes/verifier), KIP‑17 (extended script opcodes), and KIP‑20 (covenant IDs/lineage) ^[1]. A feature freeze was set for April 15, 2026, and the expected mainnet activation window has been shifted to roughly June 5–20, 2026 while sequencing commitments are finalized ^[1][5].

Why interim EVMs like Igra matter

Igra and similar projects provide an execution surface before Toccata lands. By handling execution off‑chain while relying on Kaspa for ordering and data availability, these systems let teams ship EVM contracts and user experiences now rather than waiting for L1 covenant programmability. Igra’s launch materials specifically position it as a decentralized EVM layer on Kaspa with claims of 3,000+ TPS and sub‑second inclusion, illustrating the kind of execution throughput teams can test and deploy against today ^[3].

How the two approaches coexist

• Order and DA on Kaspa: Both Igra‑style rollups and future zk‑based covenant apps treat Kaspa as the sequencing and data‑availability layer. That means Kaspa’s ordering guarantees and blockDAG behavior remain central while execution can live off‑chain or in covenant‑driven L1 code ^[3][1].
• Different tradeoffs: EVM rollups give immediate developer familiarity and tooling; Toccata’s Covenants and SilverScript will offer native L1 semantics and zk‑opcode support once activated ^[4][1].
• Complementary roadmaps: Kaspa’s public roadmap lists SilverScript, a developer SDK, and ZK verifier support as part of the Covenants rollout, positioning L1 programmability as groundwork for longer‑term ZK rollups and verified off‑chain execution ^[2].

Key technical and operational signals to watch

• Sequencing commitments / KIP‑21: Partitioned sequencing (KIP‑21) is central to how on‑chain ZK verification will scale; finalizing those sequencing commitments is the explicit reason Kaspa pushed the activation window into June ^[7][1]. Builders depending on deterministic sequencing models should track KIP‑21 progress closely.
• Testnet rehearsals: The team has signaled a TN10 rehearsal ahead of mainnet activation; participating or following rehearsal results is the best way to validate integration patterns and discover practical edge cases ^[1].
• Node and indexer impacts: The Toccata rollout will require node upgrades and is expected to increase disk usage materially (Kaspa’s guidance estimates ~20–50% growth); indexers and archival node operators should model additional storage and upgrade windows now ^[1]. Community threads also flag indexer and tooling readiness as active discussion points among node operators and builders ^[9].
• SilverScript on testnet: SilverScript is available experimentally on Testnet‑12; teams planning to migrate to L1 covenants should begin compiling and running representative contracts in that environment to uncover differences from EVM semantics (loops, arrays, UTXO/local‑state model) ^[4].

Practical checklist for teams right now

1. For execution layer teams (EVM rollups): Use Igra’s mainnet or public testnets to validate your sequencing and inclusion assumptions; document where your architecture relies on Kaspa ordering vs. L1 semantics and track KIP‑21 so you can adapt if partitioning rules change ^[3][7].
2. For L1 covenant developers: Experiment on Testnet‑12 with SilverScript and follow the SDK tooling work in Kaspa’s roadmap; keep contract designs compatible with the UTXO/local‑state model rather than assuming EVM global state ^[4][2].
3. For indexers and node operators: Schedule node upgrades, provision extra disk capacity (plan for ~20–50% growth), and coordinate to observe TN10 rehearsals. Community rehearsals and runbooks will help reduce downtime risk at activation ^[1][9].
4. For protocol researchers and ZK teams: Track the vProgs draft research for patterns on stitched proofs and metering; vProgs remains a research lane describing verifiable off‑chain execution and an economic model for provers, not an immediate mainnet capability ^[6].

Bottom line

Kaspa’s ecosystem is entering a transitional phase where native L1 programmability (Toccata and SilverScript) is approaching mainnet while production‑grade, off‑chain EVM execution already runs on networks like Igra. That duality is pragmatic: teams that need execution today can leverage EVM layers built on Kaspa’s ordering, while teams building long‑term L1 integrations should begin validating on SilverScript testnets and watching KIP‑21 and rehearsal outcomes. Monitor the official Toccata communications and rehearsal reports closely—those signals will determine how quickly builders can shift from interim rollups to native covenants ^[1][3][7].