Universal restaking layer with multi-asset Vaults (ETH LSTs, BTC LSTs, stablecoins, EIGEN, ENA, KAR) delegated to Operators that secure Distributed Secure Services (DSSs). Live on Ethereum, Arbitrum, BNB, Mantle, K2 (Karak L2).
- 01multi-asset restaking (LSTs, BTC, stables)
- 02running or delegating to Operators
- 03DSS economic security
- 04Karak XP / KAR points farming
- pnpm add viem
| Variable | Scope | Description |
|---|---|---|
| NEXT_PUBLIC_KARAK_VAULT_SUPERVISOR | Client | VaultSupervisor on Ethereum mainnet: 0x54e44DbB92dBA848ACe27F44c0CB4268981eF1CC. Routes deposits/withdrawals to per-asset Vaults. |
| NEXT_PUBLIC_KARAK_DELEGATION_SUPERVISOR | Client | DelegationSupervisor on Ethereum mainnet (see docs.karak.network for the current proxy). Manages staker→operator delegation and queued withdrawals. |
Integrate Karak restaking. Each supported asset has its own ERC-4626-style Vault registered with `VaultSupervisor`. To deposit: `IERC20(asset).approve(vault, amount); VaultSupervisor.deposit(IKarakBaseVault vault, uint256 amount, uint256 minSharesOut)`. To delegate: `DelegationSupervisor.delegateTo(address operator, ISignatureUtils.SignatureWithExpiry approverSig, bytes32 salt)`. Withdrawals follow a TWO-step queue: `DelegationSupervisor.startWithdraw(QueuedWithdrawalParams[] params)` enters the 9-day `MIN_WITHDRAW_DELAY`, then `finishWithdraw(StartedWithdrawal[] withdrawals)` after the delay. Operators register DSSs via `CoreLib.registerOperatorToDSS(...)`. Custom ERC-4626 vaults (native restaking, custodied restaking) must be allowlisted by the protocol owner before deposits open. Read shares with `IKarakBaseVault(vault).balanceOf(account)` and ETH-equivalent value via `vault.totalAssets()`.
- ⚑Withdrawals have a hard `MIN_WITHDRAW_DELAY` of 9 days specifically to prevent front-running a slashing event — funds are slashable the entire window.
- ⚑Custom ERC-4626 vaults (e.g. native ETH restaking, custodied restaking) must be approved + allowlisted by the owner; users can deploy a vault contract but cannot accept deposits until allowlisted.
- ⚑Karak vs EigenLayer vs Symbiotic: an Operator can opt into multiple frameworks; same underlying ETH restaked across all three multiplies slashing surface — verify which DSSs/AVSs/Networks an Operator serves before delegating.
- ⚑Per-Vault `slashAssets(...)` calls the Vault's `slashingHandler` — different assets (LSTs, BTC, stables) have different burn/slash mechanics; review the slashingHandler implementation per asset.
- ⚑Karak XP and KAR rewards are off-chain Merkle distributions, not auto-credited; redemption is governance-controlled.
- ⚑On L2s (Arbitrum, BNB, Mantle, K2) the VaultSupervisor and DelegationSupervisor are deployed at DIFFERENT addresses per chain — never reuse mainnet addresses.
- ⚑BTC restaking via Karak relies on wrapped BTC variants (cbBTC, LBTC, eBTC); each adds its own custody/bridge trust assumption on top of restaking risk.