How Does Karak Work?

Supports restaking of ETH, liquid staking tokens (stETH, rETH), stablecoins (USDC, USDT), wBTC, LP tokens from major DEXs, and Pendle PT positions — extending restaking beyond ETH-only to heterogeneous collateral types

EigenLayer initially focused on ETH/LSTs; Karak's extension to stablecoins and LP tokens creates a distinct risk profile. The economics of slashing non-ETH assets (e.g., what happens when restaked USDC is frozen by Circle) are largely untested at scale. Fewer than 3 protocols have operated this model for 3+ years.

Distributed Secure Services (DSS) model: external developers deploy DSS contracts that define tasks for operators and slashing conditions for non-performance; operators register and earn fees for securing DSSs

Conceptually equivalent to EigenLayer's AVS (Actively Validated Services) model. DSS contracts include optional hooks for allocation/unallocation events and enforce a 2-day cooldown between slash requests per operator. Karak V2 was among the first restaking protocols to activate slashing on mainnet (October 2024).

Per-asset ERC4626 vaults where each operator maintains dedicated vaults for each accepted asset; operators manage deposits and delegate restaking power to registered DSS contracts

Standard ERC4626 implementation. Custom ERC4626 vaults can be built for native restaking or custodied restaking with Core contract approval. Code4rena audit found share inflation attack vectors (H-03, fixed via guard checks for rounding discrepancies).

V2 SlashingHandler: DSS-triggered slashing with 7-day lookback window, 2-day cooldown per DSS per operator; asset-specific SlashingHandler contracts define burn/send-to-zero/custom slash mechanics

Karak V2 was among the first live restaking protocols with active slashing (October 2024). Architecture separates slashing logic into dedicated SlashingHandler contracts per asset. Karak's mitigation of H-04 added validation of operator registration status during slash finalization.

Unified restaking protocol deployed across 7 networks: Ethereum (primary), Arbitrum, Fraxtal, BSC, Mantle, Blast, and K2 (Karak's own L2); operators maintain vaults on each chain independently

Cross-chain restaking with slashing that must coordinate across multiple finality assumptions is a novel design challenge. Fewer than 3 protocols have operated this model for 3+ years. The interaction between Ethereum L1 slashing windows and faster L2 finality creates edge cases not present in single-chain restaking.

Operators register to DSSs and allocate restaked capital from their vaults; DSSs can slash operators for non-performance; stakers choose operators who manage their assets

Standard operator delegation model common to EigenLayer and Symbiotic. Key risk is over-allocation: operators can register with multiple DSSs without explicit on-chain caps on total slashable allocation as a percentage of vault assets.

K2 is a risk management Layer 2 built by Karak that uses Karak's own DSS model for security, creating a protocol-owned security consumer within the restaking ecosystem

K2 is both a showcase for Karak's DSS model and a structural part of the protocol stack. Creates a circular dependency: K2 security quality depends on Karak TVL and operator health.

If USDC or USDT held in Karak ERC4626 vaults is frozen by its issuer (Circle or Tether) during an active DSS slashing event, the SlashingHandler cannot execute the slash — the burn/transfer transaction will revert. Operators backed by frozen stablecoins become effectively immune to slashing, voiding DSS security guarantees for services relying on stablecoin-backed operators.

An operator registered across multiple DSSs can receive concurrent slashing requests from all registered DSSs within the 7-day lookback window. If total slash amounts exceed the operator's vault balance, the Core contract distributes assets pro-rata, leaving some DSSs with partial or zero compensation — violating the implicit guarantee that each DSS's slashing conditions are independently satisfiable.

The Core contract governs all vaults, adjudicates slashing requests, and controls asset/vault additions. If the Core contract admin can modify critical parameters or upgrade vault logic without a timelock, this represents a single point of control over all staker positions. The absence of confirmed on-chain governance creates reliance on Andalusia Labs team trust.

The 7-day slashing lookback window was designed for Ethereum L1 finality assumptions. Assets restaked on Arbitrum, Fraxtal, or BSC have different finality characteristics and withdrawal latencies. Cross-chain message delays could create windows where operators initiate withdrawals on a destination chain before a slash request is submitted on L1.

K2 uses Karak's DSS model for its own security. If Karak's TVL declines significantly or operator quality degrades, K2's economic security degrades proportionally without an independent security backstop. A macro event damaging Karak restaking also damages K2, creating correlated risk for K2-native applications.