Igra Attesting Protocol

Last updated on: 2026-01-05

Scope: This document describes the attestation system at mainnet launch. Sections marked [Phase 0] are temporary constraints that may be revised post-launch.

Attestation Protocol Overview

Table of Contents

• Summary

• Motivation

• Background and Technical Terms

• Roles

• Attestation Contract Suite

• Slashing and Penalties

• Attester Lifecycle and Staking

• Technical Challenges

• Solutions

• Technical Implementation Details

• Security Considerations

• Future Considerations

Summary

This document defines the new attestation mechanism for Igra that enables light and ultra-light nodes to securely verify L2 state without rebuilding the entire chain from genesis. The design introduces substantial economic risks for misbehaving attesters through slashing mechanisms while providing rewards for correct attestations. This economic security model is essential for making light nodes practically viable.

Motivation

The primary goal of the new attestation design is to make attesters bear real economic risk through stake slashing for wrongdoing. This requires:

• Substantial slashing to create meaningful economic risk

• Reliable identification of offenses to enable substantial slashing

• Handling L1 reorgs which cannot be detected on-chain by L2 smart contracts

Attesters taking real economic risks is required to facilitate light Igra nodes, which depend on attestations for security guarantees.

Design Rationale

This design addresses challenges that simpler approaches do not adequately handle:

• The challenge of reliably identifying offenses in the presence of L1 reorgs

• The need for substantial slashing to create real economic security

• The distinction between slashing (for provable wrongdoing) and penalties (for probable offenses that cannot be reliably proven on-chain)

The design addresses these challenges through careful handling of reorgs, introduction of challengers, and clear separation between slashing and penalties.

Background and Technical Terms

This section defines key terms and concepts related to L2 block windows, SPC, DAA Score, and Sequencing commitments.

Node Types

• Full nodes: Independently verify all L2 state from genesis. Do not rely on attestations for security.

• Light nodes: Can read L1 state. Verify attestations directly from L1. Rely on attestations combined with challenger economics for security guarantees.

• Ultra-light nodes: Cannot read L1 state. Rely on peer-gossiped attestations. Have weaker security guarantees than light nodes.

Igra and Kaspa

Igra is an L2 blockchain built on top of the Kaspa block DAG. Igra transactions are first included in L1 and sequenced by Kaspa's consensus; L2 blocks are built from L1 blocks.

Kaspa is a Directed Acyclic Graph (DAG) of blocks. A deterministic algorithm builds a chain of L1 blocks from the DAG called the Selected Parent Chain (SPC).

L2 Block Window

An L2 block window is a set of consecutive L1 blocks in Kaspa's SPC that an L2 block is built from.

DAA Score

DAA Score is Kaspa DAG's analog to logical time. It represents deterministic time in the DAG and is used for timestamping L2 blocks.

Igra Sequencing Commitment (ISC)

ISC is a modified version of Kaspa's "Sequencing Commitment" — a chained commitment in the Kaspa block header that commits to all L1 transactions accepted by the block and its ancestors (transitively, via the chained hash structure where each commitment includes the previous commitment). The modified version includes the DAA Score and L1 block timestamp, committing to both transaction sequence and their logical time.

Note: If a future Kaspa hard fork adds DAA Score and timestamp to the native Sequencing Commitment, Igra can use L1 SC directly, deprecating ISC.

Using ISC to Reference L2 Block Windows

For attestation purposes, an L2 block is referenced by the ISC of the 1st L1 block in the next L2 block window (not the current window).

Why ISC? In case of reorg, ISC changes. An ISC pointing to a reorged window will not point to the replacement window. This is not true for other L1 block parameters like DAA Score or timestamp.

Why the next window? Attestations reference the 1st L1 block of the next window. If this block remains in the SPC (not reorged), all its ancestors—including the entire attested window—also remain. This ensures an un-reorged attestation guarantees its referenced L2 block is also un-reorged.

Even if the 1st (or the last) L1 block of a window remains in the SPC, later blocks in that window may still be reorged, changing the set of L1 block in the window, and thus affecting the L2 block built from that window.

Why the 1st block? The ISC of the 1st block is stored in the L2 block header and L2 state (accessible to smart contracts), making it convenient for on-chain analysis.

Why reference windows instead of L2 blocks? Different light nodes may temporarily have different views of L2 state while syncing. Referencing L2 block windows (which are independent of L2 state) is universal, while L2 block's parameters like hash may differ temporarily.

Roles

The Igra protocol introduces two roles: Attesters and Challengers.

Attesters

Attesters significantly enhance security (through economic guarantees via staking and slashing) and user experience (by reducing synchronization time) for light and ultra-light Igra nodes, making them practically viable. The protocol remains fully operational without attesters — full nodes can operate independently — but light nodes depend heavily on attestations.

To become an attester, a user must stake (lock) Igra tokens with the Smart Contract on L2 (further - "SC").

Attestation Process

A pseudo-random selection algorithm selects which attesters must attest each L2 block.

An attestation is an on-chain transaction — a call to the attestation SC containing:

• The hash of the L2 block being attested

• The ISC identifying the L2 block window

• Additional data (see Attestation Data section)

This call represents the attester's commitment to these parameters.

The SC validates attestation parameters against the current L2 state and reverts mismatching attestations.

Since Igra is an L2 blockchain, attestations first appear on L1 and are observable by challengers even if the transaction is not included on L2 (e.g., insufficient balance for L2 gas) or reverted by the SC (e.g., parameters mismatch L2 state). So, challengers are capable of detecting attacks (off-chain) even if the L2 misses attestation transactions.

Rewards

The SC rewards attesters for correct attestations.

Rewards are proportional to the attester's effective stake balance, and computed in Igra Attester Score (IAS). Attesters claim their share of two pools at any time:

• Igra token reward pool: Tokens vested by the protocol linearly over time according to a predefined schedule

• iKAS gas fee pool: iKAS collected from users as L2 gas fees

The share in each pool is proportional to the IAS.

Effective stake balance is calculated as:

• Initial stake amount

• Minus slashed amounts

• Minus penalties

When the effective balance falls below a threshold (3× the slashing amount), the SC stops accepting attestations from that attester and excludes the attester from the active attester set.

Challengers

Challengers detect "state-faking" attacks by misbehaving attesters against light nodes when attacks cannot be detected on-chain automatically. Challengers prepare and submit to the SC a proof of fakes ("verifiable fraud and fault proofs"). The SC verifies presented proofs, and slashes (or penalizes - depending on the offense proved) stakes of misbehaved attesters.

Challengers must operate a full Igra node but are otherwise permissionless — anyone can act as a challenger and receive Igra token rewards for successful challenges.

Challengers substantially improve protocol security for light nodes, though they are not strictly required for basic protocol operation.

For a successful challenge, a challenger receives 50% of the Igra tokens slashed or charged to the attester's stake.

Attestation Contract Suite

References to "the SC" mean a cooperating set of contracts which:

• track deposits, effective balances, and lifecycle states (pending, active, exiting); enforce entry delays and exit locks.

• accept attestations, maintain submission bitmaps, and enforce selection rules.

• verify fraud and fault proofs and apply slashing or penalties.

• hold iKAS fee pool and Igra reward pool; distribute shares proportional to effective stake.

The contracts are permissionless to call and share constants/storage as needed; together they provide the attestation functionality.

Slashing and Penalties

The design treats slashing as the remedy for provable, attack-enabling wrongdoing and penalties as the remedy for offenses that are either non-attack vectors (e.g., missed attestation) or not reliably provable on-chain.

Proof types and verifiability

• Slashable offense (proved by a verifiable fraud proof): evidence an attester signed a fraudulent attestation which may enable attacks (wrong hash for a known window, or contradicting attestations for the same window). Contracts verify deterministically and apply slashing.

• Penalizable offense (proved by a verifiable fault proof): evidence of operational or ambiguous failures (missed selected window, attested to non-existent/reorged window). Contracts verify and apply penalties.

• Verifiable: the contract can check the proof using only on-chain state plus the submitted evidence; challengers are untrusted submitters, not trusted oracles.

• Why this is possible: stakes live on L2 alongside the authoritative L2 headers (ISC, DAA scores), so contracts can independently derive ground-truth values while challengers only supply candidate evidence.

Slashing

If challengers detect and prove a Slashable offense to the SC, the attester's stake will be slashed (1/16 of stake per offense). Challengers receive 50% of slashed amounts.

Slashable offenses:

1. Invalid attestation: Attesting to an invalid L2 block hash, if the attested L2 block (its window) has not been reorged (so the block remains in L2 state and is accessible to the SC)

   • Applies regardless of whether the attester was selected for this window

2. Contradicting attestations: Two or more attestations by the same attester for the same L2 block window

   • Applies regardless of selection status

   • Applies even if one attestation is valid (matches current L2 state)

   • Applies even if the L2 block window was removed from the SPC due to reorg or never existed

Technical Details: The SC never stores invalid attestations, but challengers may obtain them by reading L1 and provide them to the SC as part of the proof of offense. The SC identifies the attester by the signature the attestation contains.

Slashing Only for Provable Wrongdoing

Due to L1 reorgs, a correct attestation may become invalid without any wrongdoing by the attester. Slashing requires reliable on-chain proof of fraud. Offenses that cannot be reliably proved on-chain cannot be slashed (the cost of mistakes is too high). However, such offenses may be penalized, even with the risk of penalizing innocent attesters (acceptable if penalties are small).

No Slashing for Unknown or Reorged Windows

It is prohibitively expensive (if possible at all) to distinguish on-chain between:

• Honest attestations to windows removed by reorg (after the attestation)

• Malicious attestations to never-existed windows (may falsify L2 state for ultra-light nodes)

This represents a security threat to ultra-light nodes, which cannot verify attestations on L1 directly. Light nodes can identify and ignore attestations to reorged or non-existent windows by monitoring L1.

Since smart contracts cannot distinguish honest attestations (influenced by reorgs) from malicious ones, such malicious attestations cannot be slashed.

Unselected Attestations

A valid attestation for a window the attester was not selected for is neither slashed nor penalized. However, the attester receives no reward and the L2 gas fee is not refunded. This disincentivizes excessive use of L2 block space by attesters.

Penalties

Penalties (≈1/100 stake, TBD) apply to penalizable offenses—faults that are either non-attack vectors or indistinguishable from innocent reorg side-effects on-chain. Challengers receive 50% of penalty amounts.

Penalizable offenses and limits

1. Missed attestation: attester was selected but did not attest the window.

   • Capped to at most one penalty per minute (TBD), so an offline node is not drained.

2. Missed re-attestation after reorg: a previously included attestation was removed by reorg and not resubmitted.

   • Shares the same one-per-minute cap because the SC cannot distinguish it from case (1).

3. Attestation to non-existent window: references a window that never existed.

   • Each such attestation may be penalized once; no global rate limit.

4. Attestation to reorged window: references a window removed by reorg and unknown to the SC.

   • Penalized once per attestation; no rate limit. Appears identical on-chain to case (3).

Why penalties, not slashing, for (3), and why (4) is penalized? Proving on-chain that a referenced window was never in SPC (case 3) versus was reorged out (case 4) is prohibitively expensive. To avoid slashing innocents in case (4), both cases are treated as penalizable; occasional unfair Case (4) penalties are offset by reward parameters that include reorg risk.

Attester Lifecycle and Staking

• Entry (two-step): register+stake puts an attester's address into pending; after a fixed delay/epoch boundary, activate moves it to active. This prevents unknown pop-up attesters from being instantly trusted by light nodes.

• Minimum stake [Phase 0]: 400,000 Igra tokens (enforced on-chain, DAO-adjustable).

• Exit lock [Phase 0]: 6 months from initial stake. Note: Token holders may choose to lock tokens without staking (no rewards, no slashing risk) as an alternative. Afterward, an attester may declare_exit, enters exiting, and stops being selected; funds unlock after a 24h exit delay, then claim_exit releases the effective balance. The delay covers the full challenge window so challenges can still land.

• Penalties/slashes persist: Effective balance is reduced by penalties or slashes during exit; exiting cannot evade accountability. After exit completes, no further penalties apply. Note: On-chain fraud proof verification is limited to the most recent 8191 L2 blocks (~2.5 hrs); the 24h exit delay ensures challenges can land before funds release.

• State commitment for light nodes: The registry maintains a rolling commitment (e.g., one-sided incremental hash new_root = hash(prev_root, concat(attester, state))) over {pending, active, exiting, exited}. Relays can periodically (e.g., every 8 hours) sign and gossip the commitment so light/ultra-light nodes can ignore attestations from unknown or exited keys without full on-chain access.

• Gas refunds: L2 gas (iKAS) for correct attestations is refunded in the same transaction. L1 gas (KAS) is never refunded; L2 gas for reverted attestations is not refunded.

Exit process in details

The process for exiting and claiming the stake, similar to the entry process, is a two-stage procedure:

• Declaration (registration) of exit

• Withdrawal of stake

There are three key parameters which define the "exit lock" and timeline for exiting:

Exit Declaration Delay

This is the delay after an attester declares (registers) their intention to exit, during which the stake can NOT be withdrawn. It lasts 8191 L2 blocks (~2.5 hours). During this period, the attester may be penalized or slashed for offenses committed before the exit declaration.

Active Attestation Delay

This is the delay from the time an attester becomes active, until they are eligible to declare (register) their exit. This period lasts 24 hours.

Special 6-Month Exit Lock

This is a specific 6-month period that starts from when the attestation campaign (smart contracts) is activated. During this period, attesters cannot declare (register) an exit.

For example, if a public sale participant chooses to become an attester 2 months after the campaign starts, they will be restricted from declaring their exit for the remaining 4 months of this 6-month period. After this 6-month lock ends, the attester can declare their exit and withdraw the stake approximately 2.5 hours after the exit registration. After the special 6-month period expires, the attester can register their exit 24 hours after becoming an active attester, and they will then have the same exit process as described in the previous points.

Technical Challenges

Two main challenges arise from L1 reorgs and potential state attacks:

1. Distinguishing attacks from failures caused by reorgs: It is difficult to determine if an invalid attestation results from a mistake or an intended attack, or a reorg that occurred after the attestation. Solution: challengers distinguish and build proofs of offense - off-chain, then provide proofs to the SC that verifies proofs on-chain.

2. Identifying same-block attestations: not-synchronized light nodes and attacked ultra-light nodes may see different L2 state than correct nodes. L2 block hashes cannot reliably identify "same block" attestations across different state views. Solution: use ISC to identify the L2 block window the attestation submitted for.

3. Selection algorithm correctness: The attester selection algorithm must work correctly even when a node's L2 state is falsified due to attack. Solution: base selection solely on L1 state.

Solutions

Attester Selection Algorithm

The selection algorithm is based solely on L1 state, making it resistant to L2 state manipulation.

L2 block windows start when L1_block.DAA_Score \ 10 changes (where \ denotes integer division). The start of an L2 block window (the 1st L1 block in the window) can be reliably identified by any Igra node connected to L1, regardless of their L2 state view.

Selection formula: An attester MUST attest to the L2 block whose window is referenced by an ISC satisfying:

is_selected_block = keccak(reference_isc XOR attester_wallet_address) > THRESHOLD

where:

• reference_isc is the ISC of the 1st L1 block in the window that follows the referenced window (i.e., the window to be attested)

• THRESHOLD is computed to give approximately 1/32 probability (with L2 blocks generated every ~1 second on average, an attester is expected to attest approximately twice per minute)

Assuming keccak is well-distributed:

THRESHOLD = 2^256 - 2^256 / 32 = 0xf800000000000000000000000000000000000000000000000000000000000000

Same-Block Attestation Rule

Two or more attestations relate to the same L2 block if they commit to the same L2 block window -i.e., they have the same reference_isc. This allows Igra nodes to correctly identify same-block attestations even with different L2 state views.

If all other parameters (L2 block hash, ...) also match, the attestations are considered the same. Otherwise, they are "contradicting" attestations.

Attestation Stages

The attestation process has two distinct stages:

• Stage 1 — Submission (256 L2 blocks after the block being attested): Attesters may submit attestations. Challengers cannot submit challenges (SC reverts them).

• Stage 2 — Challenging (256 L2 blocks following the Stage 1 end): Attesters may still submit attestations, but Challengers may submit slashing or penalty transactions before attesters submit (or resubmit) attestations.

Why 256 and 256 blocks? A compromise between:

• Deep reorg probability

• Expected time light nodes must monitor L1 for attestations/slashing

• Convenience of manipulating bitmasks (256-bit words)

Additionally, 512 blocks (256 + 256) fit within the latest 8191 L2 blocks, for which system contracts in the Igra EVM know block hashes and window ISCs.

Technical Implementation Details

Tracking Submitted Attestations

For each attester, the SC maintains a ring buffer of two 256-bit words, each containing a bitmask for 256 blocks. Each bit indicates whether an L2 block has been attested, with bit position corresponding to block number.

The start (or end) block number is also stored. On each attestation, the bitmap and block number are rotated/cleaned. The buffer tracks at least the 512 most recent L2 blocks.

The bitmask is used to check if an attestation was submitted (when attesters submit attestations) or skipped (when challengers claim missed attestations).

Attester Signatures

An attestation transaction signed by an attester may be removed by reorgs or reverted by L2 (e.g., due to inconsistent EVM transaction nonce) - in both cases the SC won't see it.

If an attacker falsifies L2 state for a light node, the attacked node may accept an attestation transaction that would be rejected by correct nodes. Challengers monitoring L1 can detect invalid attestations off-chain. To simplify proving the attester's identity to the SC, attestations must include the attester's ECDSA signature.

Attestation Data Format

An attester submits:

• reference_isc: ISC of the 1st L1 block in the window following the attested block's window

• l2_block.hash: Hash of the L2 block being attested

• l2_block.number: Block number (height), concatenated with DAA score to save space

• reference_daa_score: DAA Score of the 1st L1 block in the window following the attested block's window

• daa_score_delta: Difference (increase) in DAA Score of the 1st L1 block in the attested block's window relatively to reference_daa_score

• ECDSA (EVM EoA's) signature over the above data

l2_block.number, reference_daa_score and daa_score_delta are concatenated into a 256-bit word.

Note: The DAA Score and ISC of the 1st L1 block in an L2 block's window are stored in the L2 block header and Igra system contract storage. The reference_isc for an L2 block is the l2_block.isc of its child block. Equivalently, an L2 block's isc refers to its parent block's window.

Handling Reorgs

When an L1 (and hence L2) block is removed due to reorg, all state changes (including SC storage) introduced by the removed block(s) are automatically removed.

Reorged Attestations Leave No On-Chain Trace

An attestation transaction submitted in a removed block is automatically removed from L2 state, as if it was never submitted. However, challengers monitoring L1 can see and store reorged attestation transactions off-chain and use them to challenge attesters.

Resubmission After Reorg

A reorged attestation transaction will likely be included in another SPC block and resubmitted to L2. Two scenarios are possible:

1. Transaction is not included in L2 due to EVM parameter mismatch (e.g., nonce inconsistency, insufficient balance for L2 gas)

2. Transaction is included in L2 but reverted by the SC without storage update since the attestation mismatches the updated L2 state.

There is also another scenario possible but unused: transaction is included in L2 and the SC writes invalid attestation in the storage. However, proving an attestation was valid before reorg (and made invalid due to reorg) is prohibitively expensive if not impossible. It means the SC can not differentiate between previously valid attestations and ones which have never been valid. On the other hand, proving a transaction was submitted to L1 but has not got to re-organized L2 (case 2) is also prohibitively expensive. So, the SC can neither differentiate between never submitted attestations and submitted ones but missing on L2 due to reorg. Therefore, there are no benefits in recording invalid attestations in the (expensive) storage at all.

In other words, reorged attestation transactions are likely resubmitted but rejected by the SC, leaving no records in the contract storage.

Attesters May Be Penalized but Not Slashed for Initially Correct Attestations

If reorg invalidates a previously valid attestation, challengers may submit the proof of fault (see Penalties section, case (4)) and claim penalty.

Furthermore, if attester fails to resubmit the attestation to the reorged window before challengers prove missing attestation, the attester will be penalized for missed attestation (Penalties, case (2)).

However, on proper re-submission after reorg, reference_isc in the re-submitted attestation will be different rather than the one in the first attestation - so, the 1st and resubmitted attestations will be different, and the attester can't be slashed for contradicting attestations.

Security Considerations

Light Nodes

Light nodes (that can read L1 state) benefit significantly from this design:

• They can verify attestations directly from L1, and be sure challengers also see these attestations

• Challengers can detect and slash misbehaving attesters

• Economic security is approximately equal to the total stake of trusted attesters

Ultra-Light Nodes

Ultra-light nodes (that can't read L1 state) face limitations:

• They cannot verify attestations on L1 directly

• They rely on peer-gossiped attestations, which may be falsified

• Gossiped fake attestations may be unknown to challengers, representing a security threat

• The design acknowledges these limitations and facilitates slashing/penalties for such cases

Full Nodes

Full nodes do not rely on attestations for security but can use them for cross-validation:

• They independently verify everything from genesis

• Attestations provide additional confidence but are not required

Future Considerations

• Attester set governance: Mechanisms for updating the trusted attester set

• ZK-proof verification: Using zero-knowledge proofs to verify attestations more efficiently

• Attestation aggregation: Efficiently handling large numbers of attestations