> For the complete documentation index, see [llms.txt](https://igra-labs.gitbook.io/igralabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://igra-labs.gitbook.io/igralabs-docs/igra-multitude/igra-multitude-litepaper.md).

# Litepaper

### Igra Multitude: Shared-Sequenced Logic Zones over a Kaspa BlockDAG

### Abstract

A single Kaspa-sequenced node derives **N independent EVM logic zones** from one shared Layer-1 BlockDAG \[1]. A *logic zone* is a self-contained execution environment — its own VM, chain id, genesis, and authentication/admission policy — but all zones share one ordering and one data-availability substrate. Execution is sharded by zone; sequencing and availability are singular.

This yields a settlement base for heterogeneous execution policies — distinct signature schemes, compliance regimes, virtual machines — with no bridge between zones. A zone's state is not trusted but *re-derivable* from L1. Two guarantees compose: **sequencing integrity** is verified trustlessly, by replaying Kaspa's consensus-enforced sequencing commitment, with no honest-challenger assumption; the **binding of that sequence to Igra state** is secured optimistically, by staked attestations under permissionless challenge.

We define the primitive, the derivation architecture, and the security model, and report three zone classes live on Kaspa testnet-10: canonical (ECDSA), quantum (post-quantum Falcon-L5), and a KYC zone enforced at the execution layer. We mark throughout what is live versus proposed.

***

### 1. Motivation: the coupling problem

Blockchain architectures couple three concerns that need not be coupled: **consensus** (transaction order), **data availability** (DA — published transaction data), and **execution policy** (the VM, the authentication scheme, the admission rules).

Monolithic L1s fix one execution policy for every application. Changing the VM, signature scheme, or admission rule is a hard fork affecting all users; an application needing a different policy — post-quantum signatures, a compliance gate, a non-EVM runtime — must leave the chain. Modular stacks decouple execution from consensus and DA: a DA layer such as Celestia \[2] supplies ordering and availability while rollups supply execution. But moving value or messages *between* execution environments reintroduces bridges and per-environment trust — each rollup an island with its own settlement. App-chain ecosystems (Cosmos zones \[3]) meet the same boundary: sovereign chains linked by bridging protocols.

The unmet case: **multiple execution environments with different policies sharing one ordering, one DA layer, and one settlement base with no bridge between them.** Igra Multitude occupies this space.

Note: Igra Multitude builds on Kaspa's BlockDAG and GHOSTDAG consensus \[1] and the KIP-21 partitioned sequencing commitment \[5] (activated via the Toccata hard fork) as its assumed substrate. Restaking systems (EigenLayer \[4]) share *security* across services and lie on an orthogonal axis.

***

### 2. The logic zone (the primitive)

A **logic zone** is the unit of multiplicity: an execution environment defined by its VM, chain identity and genesis, sender-authentication scheme, and any additional admission rules. Two zones may differ in any of these while remaining peers on one settlement base.

Zones are addressed on L1 by a **carrier**: an Igra transaction is wrapped in an ordinary Kaspa transaction whose payload encodes the Igra transaction inside a small envelope naming its destination zone. A zone derives its state by reading only the carriers addressed to it; the rest are opaque.

Two properties follow:

* **Adding a zone changes nothing else** — it is one more derivation pipeline over the same L1 data, with no change to Kaspa L1 or to any other zone.
* **A node may follow a subset of zones** — recognizing a foreign carrier is an identifier check; a node derives the zones it cares about and skips the rest.

Heterogeneity is confined to the VM and the authentication/admission policy; ordering and availability are zone-agnostic.

***

### 3. Architecture: derivation from a shared DAG

One node sequences many zones by **derivation, not a second consensus.** Building on Kaspa's BlockDAG substrate \[1], a modified Kaspa node embeds an Igra adapter and a derivation service. Finalized L1 windows become per-zone block-build requests: the adapter parses a window's carriers, routes them to their zones by the envelope identifier, validates them, and drives each zone's execution layer through the standard Ethereum engine interface. Several zones run under one Kaspa node, all consuming the same finalized windows.

The sequencer is singular; the derivations are independent and parallel. The *n*-th zone adds the *n*-th derivation and nothing to the layer below.

***

### 4. Verification and soundness

A zone's state is re-derivable from L1, and the re-derivation is verifiable. Two guarantees compose and secure different things.

#### 4.1 Sequencing integrity — trustless, by replay

Every Kaspa block header carries a **sequencing commitment** — a chained commitment fixing the ordered set of accepted transactions, recomputed and enforced by every node as a validity condition \[1, 5].

Igra extends this into the **Igra Sequencing Commitment (ISC)**: a *deterministic function of these on-DAG header fields*, adding the block's DAA score and timestamp.

Because the ISC is a pure function of data Kaspa consensus already commits to and enforces, **any party with the L1 chain (or faithful archival data) recomputes the ISC and bit-exactly checks the carrier sequence a zone derived from** — no trusted party, no challenge period. A divergence is immediate, local, and proves the derivation stream departed from L1.

Replay checks the sequencing input (which carriers, in what order), not EVM re-execution. And the ISC is *derived from* on-DAG data and recorded on Igra; it is not posted to L1.

Trustlessness comes from its inputs being on-DAG and consensus-enforced, so honest parties recompute it identically.

#### 4.2 Archival replay across pruning

To re-derive across Kaspa's pruning point \[1], an archival tier serves historical header and acceptance data. Archived data is self-authenticating insofar as each header carries its own sequencing commitment, chaining to a known-good tip; a separate commitment binding the whole archived dataset to the live DAG is an open item (§8).

#### 4.3 Optimistic binding sequence to Igra state

A second layer secures the *binding* of that order to Igra block state, and its liveness. Staked attesters sign that an Igra window corresponds to the L1 sequencing state, keyed by the window's ISC so a reorg cannot let a stale attestation stand in for its replacement. The layer is **optimistic**: attestations carry no prior proof, and a faulty one is detected and slashed after the fact, within a bounded challenge window, by a **permissionless** challenger. Economic security ≈ total honest attester stake (§6).

The layers are distinct: sequencing integrity needs no honest party; the binding layer does. Igra commits to L1 sequencing trustlessly (replay against on-DAG commitments) and binds it to Igra state optimistically (staked attestations, permissionless slashing).

***

### 5. Zone classes (worked examples)

Three zone classes run on a single node, deriving from the same L1 DAG, on Kaspa TN10.

**Canonical — EVM, ECDSA.** Standard Ethereum semantics and signatures; the baseline.

**Quantum — post-quantum authentication.** A Falcon-L5 signature scheme \[6] verified by a precompile, over an otherwise standard EVM. A post-quantum scheme is thus a *zone*, not a separate chain to bridge to — the same operation, authenticated differently.

**KYC — execution-layer policy.** A compliance gate enforced **at the EL, not in a contract**: each sender is checked against an on-chain allow-list *before derivation*, so a non-allow-listed sender's transaction is **filtered — it never enters a derived block**, unlike a contract gate that executes and reverts. The check reads the allow-list at the transaction's own chain position, making the verdict a deterministic function of chain height and identical across re-deriving nodes; allow-listing affects only later transactions. A bootstrap exemption lets the registry be deployed and administered first.

**Result.** The *same* operation — e.g. an ERC-20 transfer — **succeeds, reverts, or is filtered by zone policy alone**, while ordering and DA are shared. This is demonstrated end-to-end: a supply-controlled token deployed and transferred on all three zones shows identical token behavior under ECDSA and Falcon-L5 authentication; on the KYC zone an identical transaction from a non-allow-listed sender is **filtered before derivation** (no block inclusion, no receipt, no state change), and the *same* transaction **succeeds** once that sender is allow-listed — divergence by zone policy alone.

The filtering is enforced in the execution layer (`check_sender_allowed`, returning `Err` so the builder skips the transaction and the validator rejects any block that includes it) and was reproduced live: a non-allow-listed sender's transfer left no receipt and did not advance the sender's nonce, while a contract-creation from the same sender was admitted (bootstrap exemption).

Artifacts (L1 carrier + Igra transaction hashes per zone, including the filtered transaction): §8.

***

### 6. Security and trust model

**Settlement is below execution.** Kaspa orders carriers and makes them available; it treats payloads as opaque bytes and never executes them. No zone's code runs on the settlement layer, so no zone's code can affect settlement or another zone's ordering — structural, not a policy choice.

**Isolation.** Deployed today, each zone is a separate process on a separate chain; its blast radius is that zone alone, and zones share only the immutable, read-only L1 DAG. This is **strong process-level isolation** and not a claim to the strongest isolation conceivable (formally-verified or hardware-isolated designs sit elsewhere on that axis) and is why arbitrary per-zone customization is safe today.

**The roadmap deliberately relaxes it:** the proposed in-process design (§9) trades isolation for composability — sub-zones share a process, finalizer, and storage, so the executor and the cross-zone boundary become shared-fate even though contract code stays sandboxed. The architecture Igra Multitude is moving toward is therefore explicitly *not* the most-isolated point in the design space; it chooses composability over maximal isolation.

**Determinism.** State-dependent policy (the KYC check) is evaluated at the transaction's own chain position, never against "current" state — what makes re-derivation bit-identical across nodes. Reading mutable current state would split a zone. A practical corollary: a block-validity policy must be applied *symmetrically* by the block **producer** and the block **validator** — the producer must exclude what the validator would reject, or it builds blocks that fail their own validation. EL-level policy thus lives at a single admissibility point both paths share; treating a producer/validator divergence as a fatal error rather than a recoverable one is a robustness hazard the implementation must avoid.

**Disclosed limits.** Slashing is permissionless. Attester selection is not stake-weighted. Some fault categories are penalized, not fully slashed, being indistinguishable on chain. Light clients cannot self-verify. Economic parameters are governance-mutable. None of these touches the trustless sequencing layer; they bound the optimistic binding layer.

**Attester set (current).** The binding layer is multi-operator, not a single point: **\~13 nodes and \~17 attesters** are on-chain-verifiable today via the attestation contract. The set is early and modest in size, and selection is not stake-weighted, so this is a count, not yet a stake-weighted decentralization guarantee.

***

### 7. Comparison

| System                     | Shares ordering + DA        | Heterogeneous execution policy | Cross-env without a bridge  |
| -------------------------- | --------------------------- | ------------------------------ | --------------------------- |
| Monolithic L1              | Yes (one chain)             | No                             | —                           |
| Rollups on a DA layer \[2] | DA yes; ordering per-rollup | Per-rollup VM, bridged         | No                          |
| Shared sequencer \[7]      | Ordering yes                | Per-chain, bridged             | Partial                     |
| App-chains / zones \[3]    | No (sovereign)              | Yes, per-chain                 | No                          |
| Restaking \[4]             | Shares *security*           | Orthogonal axis                | —                           |
| **Igra Multitude zones**   | **Yes — one BlockDAG**      | **Yes — per-zone**             | **Same base — \[proposed]** |

* **The sequencing guarantee is stronger than the table conveys.** Shared-sequencer and DA designs give an availability or economic guarantee on ordering; Igra's is *trustless replay against consensus-enforced commitments* — no honest-challenger assumption. The optimistic, stake-secured guarantee (where the EigenLayer/Celestia framing applies) secures a *different* thing: the binding of that order to Igra state.
* **The novelty is shared-sequenced, heterogeneous-policy zones with no inter-zone bridge.** Others share one of {sequencing, security}, or decouple execution but reintroduce bridges; Igra shares sequencing, DA, and settlement across policy-divergent zones, bridge-free.
* The "no bridge" property is partly a consequence of scope: there is currently no cross-zone value path, since zones share ordering and DA but execute as isolated processes that cannot interact. The comparison systems' "bridged" cells describe shipped functionality; Igra's bridge-free cross-execution is proposed (§9), not delivered. Whether it remains bridge-free depends on the trust semantics of that unbuilt work (atomic all-or-none commit, target-decides-trust), which are unresolved.

***

### 8. Status: implemented vs. proposed

**\[live]** runs on testnet-10 · **\[implemented]** compiles, not yet packaged · **\[proposed]** designed, not built · **\[open]** unconfirmed.

* **\[live]** Three zones (canonical, Falcon-L5 quantum, KYC) derive on one node from one L1 DAG, each on its own EL, in sync at the tip. A supply-controlled ERC-20 deployed and transferred on **all three zones** (identical behavior under ECDSA and Falcon-L5). Chain ids, contract addresses, and L1+Igra transaction hashes are in the deployment artifacts — independently checkable.
* **\[live]** EL-level KYC enforcement, end-to-end: a non-allow-listed sender's transaction filtered before derivation (no block inclusion, no receipt), `setAllowed` admitting that sender, and the same transaction then succeeding — the full filter / allow / retry contrast, with the zone deriving healthily throughout. (This required the EL block *builder* to honor the same allow-list rule its *validator* enforces; see §6.)
* **\[live]** Verification machinery: Kaspa's consensus-enforced sequencing commitment and the derived ISC chain; the archival validator re-deriving and checking the sequence; the KIP-21 \[5] lane mechanism for native on-DAG isolation of Igra carriers.
* **\[proposed]** The in-process multi-zone executor; atomic cross-zone calls; non-EVM sub-zones; a dynamic zone registry.
* **\[open]** Whether the live deployment has its dedicated Kaspa lane configured (native on-DAG isolation vs. an off-DAG selection convention); a commitment binding archival data to the live DAG; empirical per-node zone density (current figures are estimates); whether a specialized single-zone node can rely on a shared Kaspa node rather than a full local sync.

***

### 9. Open problems and future work

* **In-process multi-zone execution.** One executor running internal sub-zones under one finalizer, committing per-sub-zone state in one header field with namespaced state. The zone-model types, the header commitment, and the policy hook are implemented; the executor and cross-zone call mechanism are not.
* **Synchronous atomic cross-zone calls.** Safe synchronous calls across sub-zones (eventually non-EVM) with all-or-none commit and target-decides-trust semantics, bridge-free. Open: cross-VM reentrancy, call-depth bounds, deterministic unwind order, resource-budget propagation.
* **VM-adapter conformance** for non-EVM zones — deterministic journaling, metering, identity, result mapping — the trusted interface making arbitrary execution safe in a shared executor.
* **Generalized deterministic policy reads** beyond the KYC chain-position read, and the bootstrap problem for EL-level policy.
* **Dynamic zone registration**, distinguishing a new instance of a supported VM (dynamic) from a new VM kind (a consensus change).
* **Light-client / specialized-node trust** for cross-zone state; empirical zone-density limits.
* **Closing the §6 operational gaps**: an archive-to-DAG commitment, and a shipped challenger watchdog.

***

### References

\[1] Y. Sompolinsky, S. Wyborski, A. Zohar. *PHANTOM and GHOSTDAG: A Scalable Generalization of Nakamoto Consensus.* Proc. 3rd ACM Conference on Advances in Financial Technologies (AFT '21), 2021. [ePrint 2018/104](https://eprint.iacr.org/2018/104) · [ACM](https://dl.acm.org/doi/10.1145/3479722.3480990)

\[2] M. Al-Bassam. *LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts.* 2019. [arXiv:1905.09274](https://arxiv.org/abs/1905.09274) — basis for [Celestia](https://celestia.org).

\[3] J. Kwon, E. Buchman. *Cosmos: A Network of Distributed Ledgers* (Cosmos whitepaper), 2016. [github.com/cosmos/cosmos](https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md) — sovereign application-chains and IBC.

\[4] EigenLayer Team. *EigenLayer: The Restaking Collective.* Whitepaper, 2023. [eigenlayer.xyz](https://eigenlayer.xyz) · [whitepaper](https://docs.eigencloud.xyz/assets/files/EigenLayer_WhitePaper-88c47923ca0319870c611decd6e562ad.pdf)

\[5] M. Sutton, M. Biryukov, H. Moog. *KIP-21: Partitioned Sequencing Commitment with O(activity) Proving.* Kaspa Improvement Proposals. [kip-0021.md](https://github.com/kaspanet/kips/blob/master/kip-0021.md)

\[6] P.-A. Fouque, J. Hoffstein, P. Kirchner, V. Lyubashevsky, T. Pornin, T. Prest, T. Ricosset, G. Seiler, W. Whyte, Z. Zhang. *Falcon: Fast-Fourier Lattice-based Compact Signatures over NTRU.* NIST Post-Quantum Cryptography submission (spec v1.2, 2020) [falcon-sign.info](https://falcon-sign.info/) · [spec](https://www.di.ens.fr/~prest/Publications/falcon.pdf)

\[7] Espresso Systems. *The Espresso Sequencing Network: HotShot Consensus, Tiramisu Data-Availability, and Builder-Exchange.* 2024. [ePrint 2024/1189](https://eprint.iacr.org/2024/1189) · [docs](https://docs.espressosys.com/)

\[8] Igra Labs. *Igra Attesting Protocol* (ISC construction, attestation and slashing). [igra-labs.gitbook.io](https://igra-labs.gitbook.io/igralabs-docs/for-developers/architecture/specifications/igra-attesting-protocol)

\[9] Igra Labs. *Igra Transaction Protocol* (L1 carrier/envelope byte format). [igra-labs.gitbook.io](https://igra-labs.gitbook.io/igralabs-docs/for-developers/architecture/specifications/igra-transaction-protocol)

\[10] Igra Labs. *Challenger Guide* (slashing conditions, equivocation detection). [igra-labs.gitbook.io](https://igra-labs.gitbook.io/igralabs-docs/for-attesters/challenger-guide)

\[11] Igra Labs. *Igra Bootstrap & Network Parameters* (stake, activation/exit delays, initial attesters, lane/network params). [bootstrap](https://igra-labs.gitbook.io/igralabs-docs/for-developers/architecture/specifications/igra-bootstrap) · [network parameters](https://igra-labs.gitbook.io/igralabs-docs/for-developers/architecture/specifications/igra-network-parameters)