# Consensus & Finality

> **InterLink's proprietary consensus engine delivers deterministic finality within seconds — the non-negotiable foundation for payment-grade settlement of tokenized business assets.**

***

### Design Rationale

A blockchain serving as global payment infrastructure for tokenized businesses cannot tolerate probabilistic finality. When a customer pays for a subscription, when an invoice settles between two enterprises, when transaction revenue is algorithmically routed into an AMM pool — the network must guarantee that settlement is **immediate, irreversible, and mathematically final**.

Traditional Proof-of-Work chains (Bitcoin, Ethereum pre-Merge) achieve finality only probabilistically: users must wait for multiple block confirmations to be reasonably confident a transaction won't be reversed. Even modern Proof-of-Stake networks like Ethereum post-Merge require \~12 minutes for economic finality. This latency is fundamentally incompatible with real-time commerce.

InterLink Chain implements a **Byzantine Fault Tolerant (BFT) consensus protocol** that achieves **deterministic finality in a single block cycle** — typically within 3 seconds. Once a block is committed, it is cryptographically impossible to reorganize, revert, or fork. Settlement is as immediate as swiping a credit card, but with on-chain cryptographic proof.

***

### Consensus Protocol Architecture

#### Byzantine Fault Tolerance Model

InterLink's consensus engine is built on classical BFT theory, extended with modern optimizations for throughput and validator coordination. The protocol guarantees:

* **Safety:** No two honest validators will commit conflicting blocks at the same height — even in the presence of malicious actors.
* **Liveness:** The network continues producing blocks as long as **more than 2/3 of total validator stake** is online and behaving honestly.
* **Deterministic Finality:** A block is final the moment it receives 2/3+ lock-confirmation signatures. No confirmation period. No probabilistic "deepness."

The fault tolerance threshold — tolerating up to **1/3 of validators** acting maliciously or going offline — is the theoretical maximum for any BFT protocol and represents the strongest possible safety guarantee.

#### Block Production Cycle

Each block is produced through a **four-phase consensus round**:

```
┌─────────────────────────────────────────────────────────────────┐
│                     BLOCK PRODUCTION CYCLE                      │
│                                                                 │
│  ┌──────────┐   ┌──────────┐   ┌───────────┐   ┌────────────┐ │
│  │ PROPOSE  │──▶│  VERIFY  │──▶│   LOCK    │──▶│ FINALIZE   │ │
│  └──────────┘   └──────────┘   └───────────┘   └────────────┘ │
│                                                                 │
│  Block         Validators     Validators       Block is        │
│  producer      verify and     lock in their    finalized and   │
│  assembles     vote on the    commitment       written to      │
│  candidate     proposed       with 2/3+        chain state     │
│  block         block          agreement                         │
└─────────────────────────────────────────────────────────────────┘
```

**Phase 1 — Propose:** A designated block producer (selected through deterministic round-robin weighted by stake) assembles a candidate block from the transaction mempool. The candidate block includes:

* Ordered list of validated transactions
* Previous block hash (cryptographic chain linkage)
* Timestamp and block metadata
* Producer's cryptographic signature

**Phase 2 — Verify:** All validators in the active set receive the proposed block, independently verify its validity (transaction execution, state transitions, identity checks), and broadcast a signed **verification vote**. A verification vote signals: *"I have verified this block and consider it valid."*

If a validator detects an invalid block (malformed transactions, incorrect state root, identity verification failures), it casts a `nil` vote — effectively rejecting the proposal.

**Phase 3 — Lock:** Once a validator observes **2/3+ verification votes** for the same block, it broadcasts a signed **lock-confirmation**. A lock-confirmation signals: *"I have confirmed that a supermajority of validators agree on this block, and I lock my commitment to it."*

This two-phase voting structure (verify → lock) prevents validators from finalizing a block without knowing whether the network has reached consensus — eliminating the possibility of network forks.

**Phase 4 — Finalize:** When **2/3+ lock-confirmations** are collected, the block achieves **deterministic finality**. The block is appended to the chain, state transitions are applied, and the cycle begins for the next block height.

> **Critical Property:** There is no "longest chain" rule. There is no block reorganization. Once committed, a block exists permanently and irrevocably — this is what makes InterLink suitable for settling real business revenue.

#### Timeout & Liveness Guarantees

If the block producer fails to propose within the designated timeout window (network partition, node crash, Byzantine behavior):

1. Validators timeout after a configurable period (default: \~3 seconds)
2. The proposal responsibility rotates to the next validator in the deterministic schedule
3. A new consensus round begins immediately
4. **No blocks are skipped** — the network simply selects a new producer and retries at the same block height

This ensures the network maintains liveness even when individual validators fail, without compromising the safety guarantees.

***

### Validator Infrastructure

#### Foundation Phase: Proof of Authority (POA)

During the initial network launch (Mainnet Phase 1), InterLink operates under a **Proof of Authority** model:

* The validator set is curated by the InterLink Foundation — composed of known, audited infrastructure operators.
* Each validator signs a **Service Level Agreement (SLA)** committing to uptime, security practices, and hardware standards.
* The Foundation monitors validator performance in real-time: block production rate, signing consistency, network latency.

This controlled environment ensures network stability during the critical early phase — when the RWA engine, AMM pools, and identity layer are being battle-tested with real business transactions.

#### Transition to Open Validator Participation

The POA phase is explicitly temporary. InterLink's architecture is designed for a structured transition to **open, permissionless validator participation**:

| Phase                             | Validator Model                                                  | Target Timeline |
| --------------------------------- | ---------------------------------------------------------------- | --------------- |
| **Phase 1: Genesis**              | Foundation-curated POA (8–12 validators)                         | Mainnet Launch  |
| **Phase 2: Controlled Expansion** | Approved external validators join (20–50 validators)             | +6 months       |
| **Phase 3: Open Staking**         | Permissionless validator onboarding with minimum stake threshold | +12–18 months   |

The transition criteria are objective and publicly verifiable:

* Network has sustained target TPS for 90+ days
* RWA protocol has processed a minimum aggregate transaction volume
* Slashing mechanism has been audited and tested on testnet
* Validator tooling and monitoring infrastructure is mature

#### Validator Requirements

| Requirement                 | Specification                                                              |
| --------------------------- | -------------------------------------------------------------------------- |
| **Minimum Stake**           | `[TBD]` ITL (Phase 3)                                                      |
| **Hardware**                | 16+ CPU cores, 64GB+ RAM, 2TB+ NVMe SSD, 1Gbps network                     |
| **Uptime SLA**              | ≥ 99.5% over rolling 30-day window                                         |
| **Identity**                | Validator operator must hold a verified InterLink ID                       |
| **Security**                | HSM (Hardware Security Module) recommended for key management              |
| **Geographic Distribution** | Foundation encourages geographic diversity to minimize correlated failures |

#### Delegated Staking

ITL holders who do not wish to operate validator infrastructure can **delegate** their stake to an active validator:

* Delegators share proportionally in the validator's block rewards
* Delegators also share in slashing penalties if their chosen validator misbehaves
* Delegation and undelegation are processed on-chain with a defined unbonding period
* Delegators retain full custody of their ITL throughout — delegation is non-custodial

***

### Slashing & Validator Accountability

To maintain consensus integrity, validators face **automatic, protocol-enforced penalties** for provable misbehavior:

#### Double Signing (Equivocation)

If a validator signs two different blocks at the same block height — an attempt to fork the chain — the protocol automatically:

* **Slashes** a significant percentage of the validator's staked ITL (and their delegators' stake)
* **Permanently removes** the validator from the active set (tombstoning)
* **Publishes** cryptographic evidence of the double-sign on-chain for transparency

Double signing is the most severe offense because it directly threatens the deterministic finality guarantee that underpins the entire RWA settlement model.

#### Prolonged Downtime

If a validator misses a consecutive threshold of block signatures (indicating the node is offline or unresponsive):

* The validator is temporarily **jailed** (removed from the active set)
* A minor percentage of stake is slashed
* The validator can **unjail** after resolving the issue and waiting a cooldown period

#### Slashing Parameters

| Offense                | Slash Percentage             | Jail Duration          | Recovery                          |
| ---------------------- | ---------------------------- | ---------------------- | --------------------------------- |
| **Double Signing**     | `[5–10%]` of total stake     | Permanent (tombstoned) | None — permanent removal          |
| **Prolonged Downtime** | `[0.01–0.1%]` of total stake | 10 minutes minimum     | Unjail transaction after cooldown |

> **Design Philosophy:** Slashing is not punitive — it is a **credible economic commitment**. Validators put capital at risk to guarantee their honest behavior. This economic bond is what gives the network's deterministic finality its trustworthiness for real business settlement.

***

### Post-Quantum Consensus Security

The consensus engine's validator signature scheme is architecturally designed for **modular cryptographic migration**. As quantum computing advances threaten classical elliptic curve cryptography:

* The validator signing algorithm can be upgraded to **lattice-based post-quantum schemes** (e.g., CRYSTALS-Dilithium, FALCON) through a coordinated network upgrade
* The block header format reserves space for extended signature sizes required by post-quantum algorithms
* The consensus voting protocol is agnostic to the underlying signature scheme — only requiring that signatures are valid and attributable to a specific validator

This ensures that the finality guarantees protecting tokenized business assets and ITL-denominated liquidity pools remain mathematically unbreakable — even in a post-quantum computing era.

***

### Performance Characteristics

| Metric                 | Specification                                            |
| ---------------------- | -------------------------------------------------------- |
| **Block Time**         | \~3 seconds                                              |
| **Finality**           | Deterministic — final upon commit (single block)         |
| **Finality Latency**   | \~3 seconds (= 1 block time)                             |
| **Fault Tolerance**    | Tolerates < 1/3 Byzantine validators                     |
| **Target TPS**         | 2,000 transactions per second                            |
| **Validator Set Size** | 8–12 (Phase 1) → 50–100+ (Phase 3)                       |
| **Consensus Overhead** | O(n²) message complexity per round (n = validator count) |

#### Comparison with Alternative Finality Models

| Property                            | InterLink Chain | Ethereum (Post-Merge)  | Solana                | Bitcoin                  |
| ----------------------------------- | --------------- | ---------------------- | --------------------- | ------------------------ |
| **Finality Type**                   | Deterministic   | Economic (\~12 min)    | Probabilistic (\~13s) | Probabilistic (\~60 min) |
| **Fork Possibility**                | Impossible      | Theoretically possible | Possible              | Possible                 |
| **Confirmation Required**           | 1 block         | \~32 slots + 2 epochs  | \~32 slots            | \~6 blocks               |
| **Time to Finality**                | \~3 seconds     | \~12 minutes           | \~13 seconds          | \~60 minutes             |
| **Suitable for Payment Settlement** | ✅ Yes           | ❌ Too slow             | ⚠️ Not deterministic  | ❌ Too slow               |

> **Bottom Line:** InterLink's consensus model is specifically engineered for payment-grade settlement — where "probably final" is not acceptable, and "final in 12 minutes" is commercially unviable. Deterministic, single-block finality is the only model compatible with real-time commerce infrastructure.