Security Model
InterLink Chain is designed under the assumption that every component will be attacked — and engineers defenses at the protocol level so that the cost of attack always exceeds the potential reward.
Security Philosophy
InterLink's security model is not an afterthought bolted onto a general-purpose architecture. It is intrinsic to the network's design — because InterLink handles real business revenue, real customer identities, and real tokenized assets. A security failure does not merely result in speculative token losses (as on most chains); it represents a direct attack on the economic infrastructure of verified businesses and their customers.
The security architecture follows three principles:
Defense in Depth — No single layer is solely responsible for security. Identity, consensus, execution, and economic incentives create overlapping protection zones.
Economic Rationality — Every attack vector is analyzed through the lens of cost-versus-reward. The protocol is parameterized so that attacks are always economically irrational.
Verifiable Guarantees — Security properties are not mere claims. They are mathematically provable from the protocol's design parameters.
Threat Model & Mitigation Matrix
Layer 0: Identity-Level Threats
Sybil Attack
Attacker creates thousands of fake identities to manipulate governance, drain airdrops, or dominate AMM pools
ZK-Biometric InterLink ID: 1 living human = 1 identity. No synthetic identity is possible without passing on-device biometric verification in the Secure Enclave.
🔴 Critical — Eliminated by design
Identity Spoofing
Attacker forges or steals another participant's InterLink ID
Biometric data never leaves the hardware Secure Enclave. ZK proofs are non-transferable and bound to device + biometric hash. Spoofing requires physical compromise of both the device hardware AND the biometric input.
🔴 Critical — Mitigated to hardware-attack level
Identity Farming
Attacker recruits real humans to create InterLink IDs and then controls their wallets
Economic incentive design: minimal value in fresh identities without genuine transaction history. Behavioral analysis at the application layer detects coordinated identity clusters.
🟡 Medium
Layer 1: Consensus-Level Threats
Byzantine Validator (< 1/3)
A minority of validators act maliciously — proposing invalid blocks, withholding votes, or attempting selective censorship
BFT consensus tolerates up to 1/3 Byzantine validators while maintaining both safety and liveness. Malicious proposals are rejected by honest supermajority.
🟢 Tolerated by design
Byzantine Validator (≥ 1/3)
An attacker controls 1/3 or more of the total validator stake
Network halts (liveness failure) but does not produce invalid state (safety preserved). Social consensus and governance mechanisms activate to resolve. Cost to acquire 1/3+ stake is economically prohibitive (see Economic Security below).
🔴 Critical — Economically prohibitive
Double Signing (Equivocation)
A validator signs two conflicting blocks at the same height, attempting to fork the chain
Automatic detection via consensus protocol. Immediate slashing (5–10% of stake) and permanent tombstoning. Cryptographic evidence published on-chain.
🔴 Critical — Punished automatically
Long-Range Attack
Attacker uses old validator keys to construct an alternative chain history
Mitigated by deterministic finality — there is no "longer chain" to switch to. Additionally, validator key rotation and weak subjectivity checkpoints prevent historical key reuse.
🟡 Medium — Mitigated by finality model
Transaction Censorship
A block producer deliberately excludes certain transactions
Round-robin proposer rotation ensures no single validator controls block production for consecutive rounds. Censored transactions are included by the next honest proposer within seconds.
🟡 Medium — Mitigated by rotation
Layer 2: Execution & Economic Threats
MEV Extraction (Front-running)
Bots observe pending transactions and insert their own transactions before/after to extract value (sandwich attacks, front-running, back-running)
InterLink ID gating — all transactions require a verified identity. Bots cannot obtain InterLink IDs. Protocol-embedded AMM pools cannot be accessed by unverified addresses. Combined with fair transaction ordering within blocks.
🔴 Critical — Structurally eliminated
Sandwich Attack on AMM
Attacker places trades before and after a large swap to profit from price movement
Same as MEV: requires InterLink ID. Additionally, protocol-level slippage protection and minimum output enforcement at the AMM layer.
🔴 Critical — Eliminated
Flash Loan Attack
Attacker borrows large capital in a single transaction to manipulate AMM pricing, oracle readings, or governance votes
Protocol-embedded AMMs use time-weighted average pricing (TWAP) for oracle feeds, which cannot be manipulated by single-block flash loans. InterLink ID prevents the creation of anonymous attack contracts.
🔴 Critical — Mitigated
Smart Contract Exploit
Vulnerability in deployed contract code (reentrancy, integer overflow, access control failure)
Standard EVM security applies. InterLink provides: audited reference implementations, mandatory code verification for RWA contracts, and pre-compiled contracts for critical operations (reducing smart contract surface area).
🟡 Medium — Developer responsibility + protocol safeguards
Oracle Manipulation
Attacker manipulates price feeds to trigger unfavorable liquidations or trades
Protocol-embedded AMMs serve as native price oracles with TWAP smoothing. No dependency on external oracle networks for core protocol operations.
🟡 Medium — Mitigated by native oracles
Network-Level Threats
DDoS on Validators
Attacker floods validator nodes with traffic to prevent block production
Rate limiting at the P2P layer, geographic distribution of validators, sentry node architecture (validators hidden behind relay nodes). Minimum stake-weighted identity requirement for peer connections.
🟡 Medium
Eclipse Attack
Attacker isolates a node from the honest network, feeding it false information
Minimum peer diversity requirements, persistent peer lists, and seed node bootstrapping from multiple independent sources.
🟡 Medium
Network Partition
Natural or adversarial network split isolating validator subsets
BFT safety guarantee: no partition with < 2/3 validators can produce a valid block. Network halts rather than forks — preserving safety at the cost of temporary liveness.
🟡 Medium — Safety preserved
Consensus Security Analysis
BFT Security Guarantees
InterLink's BFT consensus provides mathematically proven security properties:
Safety Theorem:
Liveness Theorem:
Finality Guarantee:
Validator Set Security Budget
The economic cost to compromise the network's safety is:
Key Insight: Due to deterministic finality, a Byzantine attack cannot produce double-spend profits (unlike PoW chains where reorgs enable double-spending). The attacker can, at best, halt the network — which earns zero financial reward while costing 1/3+ of staked value. The attack is economically irrational at any meaningful stake level.
Identity-Based Security: The InterLink ID Advantage
InterLink's ZK-Biometric identity layer provides a security dimension that no other blockchain possesses: the structural guarantee that every on-chain actor is a verified, unique human being.
How Identity Enhances Each Security Layer
MEV/Bot Protection
Bots freely front-run transactions in public mempool
Bots cannot obtain InterLink ID → cannot submit transactions to identity-gated contracts
Governance Integrity
Whale wallets dominate voting; Sybil rings amplify influence
1-person-1-vote possible; governance weight can factor identity verification
Airdrop/Distribution
Bot farms capture majority of distributions
Verified 1:1 distribution to unique participants
AMM Pool Safety
Automated scripts extract value 24/7
AMM interactions require verified identity; pools are protected by default
Spam Prevention
Must rely on gas price to deter spam
Economic deterrent (gas) + identity deterrent (limited accounts per human)
Privacy-Preserving Security
Critically, InterLink ID provides these security benefits without compromising participant privacy:
No personal data is stored on-chain or transmitted to any server
The ZK proof asserts only: "this is a unique, living human who has not previously registered"
The protocol knows WHO is verified (by wallet address) but not WHO they are (no PII linkage)
Participants retain full pseudonymity — their on-chain activity is not linked to their real-world identity
Smart Contract Security Framework
Protocol-Level Safeguards
Pre-compiled Contracts for Critical Operations — Core protocol functions (InterLink ID verification, AMM pool interaction, RWA token issuance) are implemented as pre-compiled contracts, not user-deployed Solidity. This eliminates entire classes of smart contract vulnerabilities for the protocol's most critical operations.
Audited Reference Implementations — InterLink provides officially audited contract templates for common use cases:
IRC-20 RWA token issuance
Paymaster for gasless transactions
Vesting contracts for token distribution
Multi-signature wallets
Mandatory Verification for RWA Contracts — All contracts that interact with the RWA engine (token issuance, value capture configuration, pool management) must be source-verified on the InterLink Explorer before activation. This ensures transparency and enables community review.
Audit Pipeline
Internal Review
All protocol-level contracts undergo internal peer review by the InterLink Labs engineering team
External Audit
Independent audit by [TBD — tier-1 audit firm(s)] with public report publication
Formal Verification
Critical modules (consensus interface, AMM pricing logic, identity verification) undergo formal mathematical verification
Bug Bounty
Ongoing bug bounty program (see below) incentivizes responsible disclosure
Continuous Monitoring
Real-time contract monitoring for anomalous state transitions post-deployment
Bug Bounty Program
InterLink maintains a public bug bounty program to incentivize responsible security research:
Critical
Consensus failure, unauthorized fund movement, identity bypass
Up to [TBD] USD equivalent
High
AMM pricing manipulation, slashing logic bypass, governance exploit
Up to [TBD] USD equivalent
Medium
DoS vectors, information disclosure, non-critical logic errors
Up to [TBD] USD equivalent
Low
UI issues, non-exploitable edge cases
Up to [TBD] USD equivalent
Post-Quantum Security Roadmap
As quantum computing advances toward cryptographic relevance, InterLink's security architecture is designed for proactive migration rather than reactive patching:
Current Cryptographic Stack
Transaction Signing
ECDSA (secp256k1)
⚠️ Vulnerable to quantum
Address Derivation
Keccak-256
✅ Quantum-resistant (hash)
ZK Proofs (Identity)
[TBD — PLONK/Groth16/etc.]
⚠️ Depends on scheme
Consensus Signatures
ECDSA / Ed25519
⚠️ Vulnerable to quantum
Migration Path
Phase 1: Preparation
Implement post-quantum signature verification as optional precompile
Pre-Mainnet
Phase 2: Hybrid Mode
Support both classical and post-quantum signatures in parallel
Post-Mainnet Year 1
Phase 3: Mandatory Migration
Require post-quantum signatures for all new accounts and validator registrations
Triggered by NIST/industry quantum threat assessment
Candidate Post-Quantum Algorithms:
CRYSTALS-Dilithium — NIST-standardized lattice-based digital signatures (primary candidate)
FALCON — Compact lattice-based signatures (secondary candidate for resource-constrained environments)
SPHINCS+ — Hash-based signatures (fallback — conservative, proven security assumptions)
Incident Response Framework
Severity Classification
P0 — Critical
Active exploit draining funds or compromising consensus
Immediate (< 1 hour)
AMM pool exploit, consensus halt
P1 — High
Confirmed vulnerability with clear exploit path
< 4 hours
Smart contract logic flaw, identity bypass vector
P2 — Medium
Potential vulnerability requiring investigation
< 24 hours
Unusual transaction patterns, validator anomaly
P3 — Low
Minor issue with no immediate security impact
< 1 week
UI inconsistency, documentation gap
Response Protocol
Detection — Automated monitoring, community reports, or bug bounty submissions
Triage — Security team assesses severity and assigns classification
Containment — For P0/P1: emergency parameter adjustment via Foundation multi-sig if necessary
Remediation — Develop, audit, and deploy fix through appropriate governance channel
Post-Mortem — Public disclosure of root cause, timeline, and preventive measures
Emergency Governance
For P0-critical situations requiring immediate protocol intervention, the InterLink Foundation maintains a multi-signature emergency mechanism capable of:
Pausing specific contract interactions (not the entire chain)
Adjusting risk parameters (gas limits, AMM circuit breakers)
Triggering a pre-approved emergency upgrade
This mechanism is:
Governed by a
[TBD]-of-[TBD]multi-sig composed of Foundation members and external security advisorsRate-limited (cannot execute more than one emergency action per 24-hour window without full governance vote)
Fully transparent — every emergency action is logged on-chain with justification
Time-bound — authority transfers to full on-chain governance as the network decentralizes
Design Philosophy: Emergency mechanisms exist to protect real business assets during the network's early maturation. As the validator set expands and governance matures, these mechanisms are progressively deprecated in favor of fully decentralized governance — with the ultimate goal of the Foundation having zero unilateral authority over protocol operations.
Last updated