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:
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):
Validators timeout after a configurable period (default: ~3 seconds)
The proposal responsibility rotates to the next validator in the deterministic schedule
A new consensus round begins immediately
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 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
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
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
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
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.
Last updated