> 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/for-developers/architecture/specifications/igra-attesting-protocol.md).

# Igra Attesting Protocol

Last updated on: 2026-03-31

> **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](/files/HcADvVp1przrYLqlrTDk)

## Table of Contents

* [Summary](#summary)
* [Motivation](#motivation)
* [Background and Technical Terms](#background-and-technical-terms)
* [Roles](#roles)
* [Attestation Contract Suite](#attestation-contract-suite)
* [Slashing and Penalties](#slashing-and-penalties)
* [Attester Lifecycle and Staking](#attester-lifecycle-and-staking)
* [Technical Challenges](#technical-challenges)
* [Solutions](#solutions)
* [Technical Implementation Details](#technical-implementation-details)
* [Security Considerations](#security-considerations)
* [Delegated Attestation](#delegated-attestation)
* [Future Considerations](#future-considerations)

## Summary

This document defines the new attestation mechanism for Igra that enables light and ultra-light nodes to securely verify Igra 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 Igra 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 Igra block windows, SPC, DAA Score, and Sequencing commitments.

### Node Types

* **Full nodes**: Independently verify all Igra 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 a blockchain built on top of the Kaspa block DAG. Igra transactions are first included in L1 and sequenced by Kaspa's consensus; Igra 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)**.

### Igra Block Window

An **Igra block window** is a set of consecutive L1 blocks in Kaspa's SPC that an Igra 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 Igra 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 Igra Block Windows

For attestation purposes, an Igra block is referenced by the ISC of the **last L1 block in the next Igra 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 last 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 Igra block is also un-reorged.

> Even if the last L1 block of a window remains in the SPC, earlier blocks in that window may still be reorged, changing the set of L1 blocks in the window, and thus affecting the Igra block built from that window.

**Why the last block?** The ISC of the last block in the next window is stored in the Igra block header and Igra state (accessible to smart contracts), making it convenient for on-chain analysis.

**Why reference windows instead of Igra blocks?** Different light nodes may temporarily have different views of Igra state while syncing. Referencing Igra block windows (which are independent of Igra state) is universal, while an Igra 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 Igra (further - "SC").

#### Attestation Process

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

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

* The hash of the Igra block being attested
* The ISC identifying the Igra block window
* Additional data (see [Attestation Data](#attestation-data-format) section)

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

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

> Since Igra is a based rollup, transactions are first included on L1 and are observable by challengers even if the transaction is not included on Igra (e.g., insufficient balance for gas) or reverted by the SC (e.g., parameters mismatch Igra state). So, challengers are capable of detecting attacks (off-chain) even if Igra 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 Igra 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/16 of original stake, equivalent to 3x the slashing amount at the current 1/16 slash ratio), 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. Challenger rewards are deducted directly from the penalized attester's staked IGRA — there is no separate reward pool. The remainder stays in the contract as part of the reward bonus pool for attesters.

## 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

> **Note:** All economic parameters (slash ratios, penalty ratios, reward percentages, cooldowns) are configurable by DAO governance vote. The values listed below reflect the current on-chain configuration.

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 Igra alongside the authoritative Igra 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 original stake per offense, capped at effective stake). Challengers receive 50% of slashed amounts.

Slashable offenses:

1. **Invalid attestation**: Attesting to an invalid Igra block hash, if the attested Igra block (its window) has not been reorged (so the block remains in Igra 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 Igra block window
   * Applies regardless of selection status
   * Applies even if one attestation is valid (matches current Igra state)
   * Applies even if the Igra 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 Igra 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 gas fee is not refunded. This disincentivizes excessive use of Igra block space by attesters.

### Penalties

Penalties 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.

Current on-chain penalty ratios:

* **Missed attestation**: 1/11,520 of original stake per offense
* **Invalid window attestation**: 1/4,860 of original stake per offense

**Penalizable offenses and limits**

1. **Missed attestation**: attester was selected but did not attest the window.
   * Rate-limited: one penalty per attester per cooldown period (2,700 blocks, \~45 min), 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 cooldown 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 (activation delay, currently 7,200 blocks / \~2 hours), `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]: Global 6-month lock from attestation campaign activation (`VALIDATION_START_BLOCK + LOCK_PERIOD_BLOCKS`). This lock applies equally to all attesters regardless of when they registered. Note: Token holders may choose to lock tokens without staking (no rewards, no slashing risk) as an alternative. After the global lock expires, an attester may `requestExit`, enters *PendingExit*, and stops being selected; funds unlock after the **exit cooldown** (8,200 blocks, \~2.3 hours), then `exit` releases the effective balance. The exit cooldown covers the 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 Igra blocks (\~2.5 hrs); the exit cooldown 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**: Igra gas (iKAS) for correct attestations is refunded in the same transaction. L1 gas (KAS) is never refunded; Igra 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:

#### Activation Delay (per-attester)

After registration, an attester must wait for the activation delay (currently 7,200 blocks, \~2 hours) before they can either be activated or declare an exit from PendingActivation state. This delay is per-attester and starts from their individual registration block. Once active, an attester may declare exit at any time.

#### Exit Cooldown

After an attester declares their intention to exit, they must wait for the exit cooldown period (currently 8,200 blocks, \~2.3 hours) before the stake can be withdrawn. During this period, the attester may be penalized or slashed for offenses committed before the exit declaration.

#### Special 6-Month Exit Lock

This is a global 6-month period that starts from when the attestation campaign (smart contracts) is activated (`VALIDATION_START_BLOCK`). During this period, no attester can finalize an exit, regardless of when they registered.

> For example, if a public sale participant chooses to become an attester 2 months after the campaign starts, they will be restricted from finalizing 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.3 hours after the exit declaration.

## 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 Igra state than correct nodes. Igra block hashes cannot reliably identify "same block" attestations across different state views. *Solution: use ISC to identify the Igra block window the attestation submitted for.*
3. **Selection algorithm correctness**: The attester selection algorithm must work correctly even when a node's Igra 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 Igra state manipulation.

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

**Selection formula**: An attester MUST attest to the Igra 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 last 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 Igra 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 Igra block if they commit to the same Igra block window -i.e., they have the same `reference_isc`. This allows Igra nodes to correctly identify same-block attestations even with different Igra state views.

If all other parameters (Igra 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 Igra blocks after the block being attested): Attesters may submit attestations. Challengers cannot submit challenges (SC reverts them).
* **Stage 2 — Challenging** (256 Igra 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 Igra 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 Igra 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 Igra 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 Igra (e.g., due to inconsistent EVM transaction nonce) - in both cases the SC won't see it.

If an attacker falsifies Igra 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 last L1 block in the window following the attested block's window
* `l2_block.hash`: Hash of the Igra block being attested
* `l2_block.number`: Block number (height)
* `reference_daa_score`: DAA Score of the last L1 block in the window following the attested block's window
* `daa_score_delta`: Difference (increase) in DAA Score between the attested window and the next window
* ECDSA (EVM EoA's) signature over the above data

These fields are defined as separate typed fields in the `AttestData` struct (`uint32` for block number, DAA score, and delta).

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

### Handling Reorgs

When an L1 (and hence Igra) 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 Igra 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 Igra. Two scenarios are possible:

1. Transaction is not included in Igra due to EVM parameter mismatch (e.g., nonce inconsistency, insufficient balance for gas)
2. Transaction is included in Igra but reverted by the SC without storage update since the attestation mismatches the updated Igra state.

> There is also another scenario possible but unused: transaction is included in Igra 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 Igra (case 2) is also prohibitively expensive. So, the SC can neither differentiate between never submitted attestations and submitted ones but missing on Igra 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

## Delegated Attestation

Delegated attestation allows a registered attester (the **controller**) to authorize a separate address (the **operator**) to submit attestation transactions on their behalf. This enables cold/hot key separation — the staking key stays offline while a hot operator key handles daily attestation submissions.

### Motivation

Without delegation, the same private key that holds staked IGRA must sign every attestation transaction. This requires the staking key to be hot (online), which is a security risk for professional operators managing significant stake.

With delegation:

* The **controller** (cold wallet) holds the stake and earns rewards
* The **operator** (hot wallet) submits transactions and receives gas refunds
* The controller signs a time-bounded authorization offline

### DelegationAuth

The controller signs an EIP-712 message authorizing a specific operator address with a block-number expiry. This authorization is passed per-transaction — no on-chain registration is needed.

```solidity
struct DelegationAuth {
    address controller;  // Registered attester address (cold wallet)
    uint64 expiry;       // Block number after which this authorization is invalid
    bytes signature;     // Controller's EIP-712 signature over (operator, expiry)
}
```

The function signature for delegated attestation:

```solidity
function attestDelegated(
    AttestData calldata data,        // Same attestation data as attest()
    bytes calldata signature,        // Operator's EIP-712 signature over AttestData
    DelegationAuth calldata auth     // Controller's delegation authorization
) external;
```

### EIP-712 Signing Details

Both the attestation data and the delegation authorization use EIP-712 typed data signatures with the same domain:

**Domain:**

* Name: `"Igra Labs"`
* Version: `"1"`
* Chain ID: `38833` (Igra Mainnet)
* Verifying Contract: Attestation Diamond address
* Salt: `keccak256("IGRA_EIP712_DOMAIN_SALT")`

**Delegation type:** `DelegationAuth(address operator, uint64 expiry)`

The struct hash commits to the specific operator address, preventing an authorization from being reused with a different operator.

### Reward and Gas Routing

| What                      | Goes to            |
| ------------------------- | ------------------ |
| IAS (Igra Attester Score) | Controller         |
| IGRA emission rewards     | Controller         |
| iKAS gas refund           | Operator           |
| Penalties and slashes     | Controller's stake |

### Key Properties

* **Stateless**: No on-chain mapping of operator-to-controller. Key rotation is instant — sign a new authorization. Revocation is implicit — stop signing or set a short expiry.
* **Calldata-verifiable**: Light nodes can verify the delegation chain from calldata without off-chain services.
* **Expiry**: Block-number based. After expiry, the contract rejects the authorization. Choose expiry based on operational needs — shorter limits exposure if the operator key is compromised.
* **Controller and operator must be different addresses**.

### Challenger Interaction with Delegated Attestations

When a delegated attestation is challenged, the challenger must include the `DelegationAuth` from the original `attestDelegated()` calldata so the contract can resolve the actual attester (controller).

* For `slash()` and `penalizeInvalidWindow()`: pass the `DelegationAuth` from the original calldata
* For `penalizeMissed()`: not needed — the attester is identified by address directly
* For non-delegated attestations: pass a zeroed `DelegationAuth` (`controller = address(0)`)

Delegation expiry is NOT checked during slashing — the authorization was valid when the attestation was made, and the slash proof remains valid regardless.

### Comparison: attest() vs attestDelegated()

|                             | `attest()`                | `attestDelegated()`             |
| --------------------------- | ------------------------- | ------------------------------- |
| Selector                    | `0xc84c8ea3`              | `0xd5b1840d`                    |
| Signer                      | Attester (same as staker) | Operator (separate from staker) |
| `msg.sender`                | Must be the attester      | Must be the operator            |
| Key exposure                | Staking key must be hot   | Staking key stays cold          |
| Gas refund                  | To attester               | To operator                     |
| Rewards                     | To attester               | To controller                   |
| `AttestationRecorded` event | `attester` = signer       | `attester` = controller         |

## 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