Restaking has quickly gone from a niche experiment to one of the biggest narratives in Ethereum (ETH). Billions of dollars’ worth of ETH and liquid staking tokens now sit in restaking protocols, where the same collateral that already secures Ethereum is being pledged again to secure extra services and earn additional yield.
For stakers, the appeal is obvious: instead of letting your staked ETH “only” secure the beacon chain, you can put it to work in more places and potentially boost returns.
In simple terms, restaking lets you reuse staked collateral to help secure other networks or services on top of Ethereum—without fully unbonding first. On Ethereum, that usually means pointing your staked ETH toward Actively Validated Services (AVSs).
AVSs are off-chain or on-chain services that rely on validators to do specific jobs: things like data-availability layers, oracle networks, sidechains, or other middleware that need honest validation. Restaking tells those AVSs, “If I misbehave, you can slash my staked ETH,” which extends Ethereum’s economic security to more of the ecosystem.
Done well, restaking compounds security and yield: more services share the same strong collateral base, and stakers earn extra rewards for taking on additional duties.
Done poorly, it stacks risks on top of your original stake—if an AVS has poor design or governance, you can be slashed in multiple places at once.
What is Restaking?
In short, restaking is like taking the security deposit you’ve already put down for one job and using it to secure additional jobs for extra pay.
Normally, when you stake your crypto (like ETH) on a blockchain network, you’re locking it up to help keep that network secure, and you earn rewards for it. Restaking takes that same, already-staked crypto and lets you reuse its “security power” to help protect other, separate services and networks.
You don’t have to run new software yourself. Instead, you choose an “operator” who runs the software for these new services. You then delegate your staked assets to them. In return for lending your collateral to secure these extra services, you earn additional rewards on top of your original staking yield.
However, there’s a catch. You are taking on extra risk. You are putting your original staked assets “on the line” for more than one job. If the operator you choose misbehaves or fails—whether for the main network or for any of these new services—your staked assets can be penalized or “slashed.” This means you could lose money if something goes wrong.
The big reason this system exists is to help new, smaller projects. Instead of each new service having to build its own security system from scratch, which is slow and expensive, it can instead “rent” the existing, strong security of Ethereum. This makes the whole ecosystem more efficient.
For the person staking, the benefit is the chance to earn more from the same assets. For the new services, the benefit is instant, strong security. The trade-off for the staker is accepting more complexity and the risk that one mistake could affect your original investment.
The Risk–Reward Trade-Off in Restaking
Restaking gives you the chance to earn extra rewards, but it also means taking on extra risks.
Think of it like this: You’re already earning rewards by staking your crypto to help secure a network. Restaking lets you reuse that same staked crypto to help secure other services, too. In return, you can earn extra rewards on top of what you were already making.
But there’s a catch.
If something goes wrong—like the operator you’ve chosen makes a mistake, goes offline, or behaves dishonestly—you could lose a portion of your staked assets (this is called “slashing”). And since one stake is securing multiple services at once, one problem could affect all of them at the same time.
You’re also trusting the smart contracts that handle restaking, the operator you pick to do the work, and the rules of the new services you’re helping secure. This introduces smart contract risk, operator risk, and governance risk.
So, while restaking can boost your earnings, it also multiplies the things that can go wrong.
A safe way to approach it is:
- Understand the rules – know what could cause you to lose funds.
- Spread out your risk – don’t put everything with one operator or one service.
- Don’t overcommit – only restake an amount you’re comfortable potentially losing.
More rewards come with more responsibility. Make sure the extra income is worth the extra risk before you decide to restake.
Top Restaking Protocols in 2025
Below are five restaking protocols worth tracking in 2025, what makes each interesting, and where to be cautious.
1. EigenLayer — The AVS Marketplace on Ethereum
EigenLayer pioneered the concept of staking on Ethereum, allowing you to “rent” Ethereum’s economic security to new services. Stakers (native or via liquid-staking tokens) opt in to secure Actively Validated Services (AVSs) and earn incremental rewards. The flagship AVS, EigenDA, targets high-throughput data availability for rollups—lowering DA costs while inheriting Ethereum-aligned security.
Through 2025, expect more AVSs to plug in (oracles, coprocessors, shared sequencing, intents), making EigenLayer a de facto marketplace where security meets modular infrastructure.
Its main edge is simple: instead of every new protocol launching its own security token and hunting for stakers, EigenLayer lets them “rent” Ethereum’s existing staked ETH as shared security.
For stakers, that creates a single place to opt in to multiple AVSs and earn extra rewards on top of base staking yield, which is why EigenLayer has become the flagship name in restaking and a focal point for projects that want Ethereum-grade security without bootstrapping it from scratch.
How it works:
- Two on-ramps: native restaking (bond your validator balance) or LST restaking (delegate stETH, rETH, cbETH, etc.).
- Operator layer: you delegate to operators who actually run AVS software. Rewards flow if operators meet liveness/correctness targets; slashing applies if they fail published rules.
- AVS menus: each AVS defines its own rewards, duties, and slashing (e.g., double-signing, downtime, equivocation, fraud proofs). You can opt into multiple AVSs, but correlation risk rises when one operator services several at once.
What to validate before allocating:
- Slashing conditions (per AVS): objective vs subjective faults, dispute windows, evidence standards, and worst-case slash amounts.
- Correlation risk: avoid a single operator running all your AVSs; diversify by operator, client stack, geography, and infra provider.
- Operator due diligence: track SRE maturity (monitoring, failover, incident drills), client diversity, MEV policy, past uptime, and public postmortems.
- Liquidity & exits: unbonding/withdrawal queues, reward claim cadence, and any lockups for native vs LST restaking.
- Accounting & tax: reward sources, token types, and how you’ll recognize/track income across AVSs.
2. Symbiotic — Modular, Chain-Agnostic Restaking
Symbiotic positions itself as a universal, permissionless restaking framework by running a thin, immutable coordination layer on Ethereum that any network can plug into and by supporting a broad set of ERC-20 collateral types instead of just ETH/LSTs.
Protocols integrate via configurable vaults and modules, where they define their own slashing logic, reward rules, and operator sets, rather than conforming to a single, protocol-wide template.
Because the core contracts are non-upgradeable and don’t depend on governance whitelists or a central slashing committee, new projects and operators can join without asking permission, and participants can restake a variety of assets—staked ETH, liquid staking tokens, LP tokens, and other supported ERC-20s—into whatever security relationships those protocols design.
The core idea is to make “economic security” a marketplace primitive that any network or service can tap, with clearly defined roles and slashing logic.
Symbiotic does this by separating the key pieces into modular contracts: vaults that hold collateral, operators that opt in to secure specific protocols, and agreements that define what counts as misbehaviour and how slashing works.
Protocols plug into this framework instead of building their own from scratch, choosing which assets they accept, which operators they trust, and what penalties apply.
Because these components are reusable and composable, “renting” or providing security starts to look like joining a marketplace: restakers bring collateral, operators bring infrastructure, and protocols bring tasks and rewards—all wired together through explicit, on-chain slashing rules.
How it works:
- Modular roles and vaults: Assets are deposited into vaults that define who can provide collateral and under what rules. Curators configure vault policies, operators run the service software, and resolvers adjudicate slashable faults. Crucially, assets remain in vaults; enforcement happens via a slashing handler that executes penalties according to each service’s policy.
- Permissionless composition: Protocols define their own security relationships—what counts as collateral, who can operate, and how slashing is triggered—so the same restaked assets can secure different services with different policies.
- “Universal staking” posture: By design, Symbiotic aims to span multiple use cases and integrations rather than serving a single app stack, with a public-facing docs architecture that emphasizes modularity and role separation.
What to validate before allocating:
- Collateral rules: Which assets are accepted, haircuts by asset type, any reuse limits, and how collateral segregation works at the vault level.
- Slashing clarity: Objective vs subjective faults, evidence standards, resolver authority, dispute windows, and worst-case slash amounts per service.
- Operator pathway: Who can operate, required client software, uptime/monitoring expectations, and incident-response duties across operators and resolvers.
- Composability risk: Correlation when the same operator or collateral secures multiple services; ensure diversification across operators, clients, geographies, and infra. (General restaking risk; align with the framework’s role model.)
- Liquidity & exits: Unbonding mechanics at the vault level, reward claim cadence, and any lockups that differ by asset or service.
3. Karak Network — “Universal” Restaking for Many Assets
Karak Network extends restaking beyond a single ecosystem, aiming to let services “borrow” economic security from multiple crypto assets and validator/operators—not just ETH. Karak refers to these secured services as Distributed Secure Services (DSS).
That broader collateral model is attractive for new middleware (data availability, oracles, shared sequencing) that want diversified backing rather than tying security to one token.
How it works:
- Universal collateral: Karak is designed to accept a range of assets for restaking (asset- and chain-agnostic by design). Services built on Karak (often described as “distributed secure services,” or DSS) define their own duties and rewards, while restakers delegate to operators who actually run the software.
- Operator layer: You pick operators; they provide liveness/correctness for the target service. Rewards accrue when operators meet the Service Level Agreement (SLA); slashing applies under published fault conditions.
- Programmatic security: Each service specifies its own security relationship (who can post collateral, who can operate, how to slash), enabling modular compositions rather than a one-size-fits-all framework.
What to validate before allocating:
- Asset support & haircuts: Which assets are eligible today, how collateral is haircut or capped, and whether any rehypothecation is permitted. (Design goal is multi-asset, but confirm current lists and parameters.)
- Slashing clarity: Fault definitions (objective vs. subjective), evidence standards, dispute windows, and worst-case slash amounts for each service.
- Operator due diligence: Diversity, infra hygiene, monitoring/failover, historic uptime, and post-mortems; avoid concentration in a single operator across several services.
- Liquidity & exits: Unbonding/withdrawal queues for each supported asset, reward claim cadence, and any lockups or program-specific exit constraints.
4. Babylon — Bringing Bitcoin Economic Weight to PoS Security
Babylon exports Bitcoin’s economic weight to proof-of-stake (PoS) chains without wrapping BTC. It lets Bitcoin holders “restake” native BTC to secure external networks and services, offering slashable guarantees and fast unbonding while avoiding bridges or custodial pegs.
For teams that prefer BTC-anchored security over ERC-20 collateral, this is the leading path in 2025.
How it works:
- Trust-minimized BTC staking. BTC is locked using Bitcoin-native primitives; partner PoS chains reference that on-chain state and can slash for misbehavior, providing economic security to their consensus or middleware. The litepaper outlines slashable guarantees, a staking script, and a modular plugin for PoS consensus.
- Status. Babylon’s Bitcoin Staking Phase-1 mainnet went live on August 22, 2024, with ongoing ecosystem integrations through 2025.
What to validate before allocating:
- BTC custody model. How BTC is locked, who controls the unlock/slash paths, and the precise trust and failure assumptions in the staking script. Start with the docs and litepaper for the enforcement flow.
- Partner-chain integration. Which PoS chains verify Bitcoin state, how they read proofs, what governance gates exist, and how slashing propagates to penalties on the target chain.
- Slashing enforceability. Objective vs. subjective faults, evidence standards, dispute windows, and worst-case slash amounts defined by each integration
5. Solayer — Native Restaking on Solana
Solayer is the first Solana-native restaking protocol, built to let SOL staking power additional services while staying aligned with Solana’s speed and cost profile. It positions itself as a restaking layer plus an SVM (Solana Virtual Machine)-based execution environment, with native “yield” assets such as sSOL that are intended to plug into services like data availability or other middleware. If you live in the Solana ecosystem, this is the primary venue bringing the restaking model on-chain for SOL.
How it works:
- Restake SOL / LSTs: Users stake SOL and receive protocol assets (e.g., sSOL) designed to participate in Solayer’s service layer while continuing to reflect staking economics. Public materials describe Solayer as a restaking protocol built natively on Solana, with sSOL and related components tied into its SVM-based stack.
- Execution layer fit: Solayer runs an SVM environment (“InfiniSVM” in some comms) aimed at Solana-style performance and modular security for apps that want Solana-aligned throughput with restaked collateral backing services.
What to validate before allocating:
- Service menu and slashing: Which services exist today, how rewards accrue, and the specific, objective slashing criteria they use.
- Operator and infra risk: Who actually runs the infra, redundancy, monitoring, and incident response; concentration across a small operator set.
- Exit and liquidity: Unbonding timelines, any lockups for restaked positions, reward claim cadence, and how sSOL (or related tokens) unwind back to native SOL.
- Documentation depth: Confirm current docs for SVM components, custody flow for stake deposits through the protocol’s “Mega Validator,” and any audits published.
Strategic Roadmap: Managing Risk & Rewards in Restaking
Choosing a restaking protocol is about balancing risk and reward. You’re putting your staked assets on the line for extra services, so you want a protocol with clear rules, reliable operators, and a real business model—not just temporary token payouts. Use this checklist to make a safer choice.
- Security & Rules
Read the slashing rules carefully. You need to understand:
- What kind of mistake causes you to lose funds?
- Who can cut (“slash”) your stake?
- How are they caught?
Look for protocols that use automatic, verifiable rules—not vague “policies” or committees that vote.
- Who Runs It? (The Operators)
Your earnings depend on the operators you choose—these are the people running the software. Before you delegate to them, check:
- Their track record for reliability.
- How many different operators there are. Avoid setups where too much depends on one person or company.
- Their setup: Are they using different data centers, software, and locations? More variety means less chance of everything failing at once.
- Collateral & Chain Support
Understand what you’re actually putting in:
- Which assets can you use (ETH, a liquid staking token, or others)?
- How easy is it to withdraw? Are there waiting periods?
- How does the protocol work across different blockchains (if it does)? Prefer protocols that use secure methods to connect chains.
- The Rewards (The Economics)
Make sure you’re being paid for something real. Ask:
- Are rewards coming from real fees that users pay for the service?
- Or are they just new tokens being printed (which may not last)?
- What’s the actual profit after the operator and the protocol take their cut? It should be worth the risk you’re taking.
- User Experience & Clarity
A good protocol should be easy to use and transparent. Look for:
- A clear dashboard to track your funds and rewards.
- Simple processes for starting, stopping, or switching operators.
- Published audits and clear explanations of what happens if something goes wrong.
Restaking Risks to Watch Out For
Restaking doesn’t just add rewards—it adds new risks to your original stake. Be aware of how things can go wrong.
Correlation & Chain Reaction Risk
Since the same stake is securing multiple services, a single problem can cause losses across all of them at once—especially if those services use the same operators or software.
- What you can do: Spread your funds across different services and operators. Don’t put all your eggs in one basket.
New Service (AVS) Risk
Many of these extra services are brand new and untested. Their code or rules might have bugs, which could lead to unfair penalties or long downtimes.
- What you can do: Start by using only well-audited, more established services. Begin with a small amount of money and increase only as the service proves itself.
Bridge & Cross-Chain Risk
If the protocol works across multiple blockchains, it depends on a “bridge” to connect them. If that bridge is insecure or fails, your funds could be at risk on another chain.
- What you can do: Understand how the bridge works. Prefer protocols that use the most secure type of bridges (like “light clients”). Be extra careful and expect higher rewards if you accept more risk here.
Institutional Approach: Aligning Security with Yield
Restaking turns staked collateral into a productivity layer, but it also stacks new risks on top of your base position. The winners will pair clear slashing rules with proven operators, objective fault proofs, clean exits, and rewards that scale with real usage.
Treat selection like vendor risk for core infrastructure: diversify operators and client stacks, cap exposure per service, stage capital, and monitor telemetry and postmortems before you size up.
If you plan to launch or integrate restaking, bring bank-grade ops to day one. Align custody with policy controls, separate treasuries, automate reward and slash accounting, and stand up dashboards for operator health, correlation risk, and exits. Build incident playbooks you can test, not just document.
Your Wallet Matters for Safe Restaking
A secure, well-designed wallet is the foundation of a safe restaking experience. ChainUp’s institutional-grade wallet technology—featuring MPC security, segregated vaults, and comprehensive audit trails—is used by leading exchanges and wallet providers to power their staking and restaking products.
When you choose a restaking provider, look for platforms that prioritize security and transparency at the infrastructure level. Many of the safest options are built on secure, professional-grade technology like ChainUp‘s wallet solutions. Your assets deserve nothing less.