One post tagged with "Security-as-a-Service"

Restaking Explained: In Ethereum’s proof-of-stake model, validators normally stake ETH to secure the network and earn rewards, with the risk of slashing if they misbehave. Restaking allows this same staked ETH (or its liquid staking derivatives) to be reused to secure additional protocols or services. EigenLayer introduced restaking via smart contracts that let ETH stakers opt in to extend their security to new systems in exchange for extra yield. In practice, an Ethereum validator can register with EigenLayer and grant its contracts permission to impose additional slashing conditions specified by external protocols. If the validator performs maliciously on any opted-in service, the EigenLayer contracts can slash their staked ETH, just as Ethereum would for consensus violations. This mechanism effectively transforms Ethereum’s robust staking security into a composable “Security-as-a-Service”: developers can borrow Ethereum’s economic security to bootstrap new projects, rather than starting their own validator network from scratch. By leveraging the 31M+ ETH already securing Ethereum, EigenLayer’s restaking creates a “pooled security” marketplace where multiple services share the same trusted capital base.

EigenLayer’s Approach: EigenLayer is implemented as a set of Ethereum smart contracts that coordinate this restaking process. Validators (or ETH holders) who wish to restake either deposit their liquid staking tokens or, in the case of native stakers, redirect their withdrawal credentials to an EigenLayer-managed contract (often called an EigenPod). This ensures EigenLayer can enforce slashing by locking or burning the underlying ETH if needed. Restakers always retain ownership of their ETH (withdrawable after an exit/escrow period), but they opt-in to new slashing rules on top of Ethereum’s. In return, they become eligible for additional restaking rewards paid by the services they secure. The end result is a modular security layer: Ethereum’s validator set and stake are “rented out” to external protocols. As EigenLayer’s founder Sreeram Kannan puts it, this creates a “Verifiable Cloud” for Web3 – analogous to how AWS offers computing services, EigenLayer offers security as a service to developers. Early adoption has been strong: by mid-2024 over 4.9 million ETH (~$15B) was restaked into EigenLayer, demonstrating demand from stakers to maximize yield and from new protocols to bootstrap with minimal overhead. In summary, restaking on Ethereum repurposes existing trust (staked ETH) to secure new applications, and EigenLayer provides the infrastructure to make this process composable and permissionless.

Design Patterns of Actively Validated Services (AVSs)​

What are AVSs? Actively Validated Services (AVSs) refer to any decentralized service or network that requires its own set of validators and consensus rules, but can outsource security to a restaking platform like EigenLayer. In other words, an AVS is an external protocol (outside the Ethereum L1) that hires Ethereum’s validators to perform some verification work. Examples include sidechains or rollups, data availability layers, oracle networks, bridges, shared sequencers, decentralized compute modules, and more. Each AVS defines a unique distributed validation task – for instance, an oracle might require signing price feeds, while a data availability chain (like EigenDA) requires storing and attesting to data blobs. These services run their own software and possibly their own consensus among participating operators, but rely on shared security: the economic stake backing them is provided by restaked ETH (or other assets) from Ethereum validators, rather than a native token for each new network.

Architecture and Roles: EigenLayer’s architecture cleanly separates the roles in this shared security model:

• Restakers – ETH stakers (or LST holders) who opt in to secure AVSs. They deposit into EigenLayer contracts, extending their staked capital as collateral for multiple services. Restakers can choose which AVSs to support, directly or via delegation, and earn rewards from those services. Crucially, they bear slashing risk if any supported AVS reports misbehavior.

• Operators – Node operators who actually run the off-chain client software for each AVS. They are analogous to miners/validators for the AVS’s network. In EigenLayer, an operator must register and be approved (initially whitelisted) to join, and can then opt in to serve specific AVSs. Restakers delegate their stake to operators (if they don’t run nodes themselves), so operators aggregate stake from potentially many restakers. Each operator is subject to the slashing conditions of whatever AVS they support, and they earn fees or rewards for their service. This creates a marketplace of operators competing on performance and trustworthiness, since AVSs will prefer competent operators and restakers will prefer those who maximize rewards without incurring slashing.

• AVS (Actively Validated Service) – The external protocol or service itself, which typically consists of two components: (1) an off-chain binary or client that operators run to perform the service (e.g. a sidechain node software), and (2) an on-chain AVS contract deployed on Ethereum that interfaces with EigenLayer. The AVS’s Ethereum contract encodes the rules for that service’s slashing and reward distribution. For example, it might define that if two conflicting signatures are submitted (proof of equivocation by an operator), a slash of X ETH is executed on that operator’s stake. The AVS contract hooks into EigenLayer’s slashing managers to actually penalize restaked ETH when violations occur. Thus, each AVS can have custom validation logic and fault conditions, while relying on EigenLayer to enforce economic punishments using the shared stake. This design lets AVS developers innovate on new trust models (even new consensus mechanisms or cryptographic services) without reinventing a bonding/slashing token for security.

• AVS Consumers/Users – Finally, the end-users or other protocols that consume the AVS’s output. For instance, a dApp might use an oracle AVS for price data or a rollup might post data to a data availability AVS. Consumers pay fees to the AVS (often funding the rewards restakers/operators earn) and depend on its correctness, which is assured by the economic security the AVS has leased from Ethereum.

Leveraging Shared Security: The beauty of this model is that even a brand-new service can start life with Ethereum-grade security guarantees. Instead of recruiting and incentivizing a fresh set of validators, an AVS taps into an experienced, economically bonded validator set from day one. Smaller chains or modules that would be insecure alone become secure by piggybacking on Ethereum. This pooled security significantly raises the cost to attack any single AVS – an attacker would need to acquire and stake large amounts of ETH (or other whitelisted collateral) and then risk losing it via slashing. Because many services share the same pool of restaked ETH, they effectively form a shared security umbrella: the combined economic weight of the stake deters attacks on any one of them. From a developer’s perspective, this modularizes the consensus layer – you focus on your service’s functionality while EigenLayer handles securing it with an existing validator set. AVSs can thus be very diverse. Some are general-purpose “horizontal” services that many dApps could use (e.g. a generic decentralized sequencer or an off-chain compute network), while others are “vertical” or application-specific (tailored to a niche like a particular bridge or a DeFi oracle). Early examples of AVSs on EigenLayer span data availability (e.g. EigenDA), shared sequencing for rollups (e.g. Espresso, Radius), oracle networks (e.g. eOracle), cross-chain bridges (e.g. Polymer, Hyperlane), off-chain computation (e.g. Lagrange for ZK proofs), and more. All of these leverage the same Ethereum trust base. In summary, an AVS is essentially a pluggable module that outsources trust to Ethereum: it defines what validators must do and what constitutes a slashable fault, and EigenLayer enforces those rules on a pool of ETH that is globally used to secure many such modules.

Incentive Mechanisms for Restakers, Operators, and Developers​

A robust incentive design is critical to align all parties in a restaking ecosystem. EigenLayer and similar platforms create a “win-win-win” by offering new revenue to stakers and operators while lowering costs for emerging protocols. Let’s break down incentives by role:

• Incentives for Restakers: Restakers are primarily motivated by yield. By opting into EigenLayer, an ETH staker can earn extra rewards on top of their standard Ethereum staking yield. For example, a validator with 32 ETH staked in Ethereum’s beacon chain continues earning the ~4-5% base APR, but if they restake via EigenLayer, they can simultaneously earn fees or token rewards from multiple AVSs that they help secure. This “double dipping” dramatically increases potential returns for validators. In EigenLayer’s early rollout, restakers received incentive points that converted into EIGEN token airdrops (for bootstrap); later a continuous reward mechanism (Programmatic Incentives) was launched, distributing millions of EIGEN tokens to restakers as liquidity mining. Beyond token incentives, restakers benefit from diversification of income – instead of relying solely on Ethereum block rewards, they can earn in various AVS tokens or fees. Of course, these higher rewards come with higher risk (greater slashing exposure), so rational restakers will only opt into AVSs they believe are well-managed. This creates a market-driven check: AVSs must offer attractive enough rewards to compensate for risk, or restakers will avoid them. In practice, many restakers delegate to professional operators, so they may also pay a commission to the operator out of their rewards. Even so, restakers stand to gain significantly by monetizing the otherwise idle security capacity of their staked ETH. (Notably, EigenLayer reports that over 88% of all distributed EIGEN went straight into being staked/delegated again – indicating restakers are eagerly compounding their positions.)

• Incentives for Operators: Operators in EigenLayer are the service providers who do the heavy lifting of running nodes for each AVS. Their incentive is the fee revenue or reward share paid by those AVSs. Typically, an AVS will pay out rewards (in ETH, stablecoins, or its own token) to all validators securing it; operators receive those rewards on behalf of the stake they host, and often take a cut (like a commission) for providing infrastructure. EigenLayer allows restakers to delegate to operators, so operators compete to attract as much restaked ETH as possible – more stake delegated means more tasks they can do and more fees earned. This dynamic encourages operators to be highly reliable and specialize in AVSs they can run efficiently (to avoid getting slashed and to maximize uptime). An operator with a good reputation may secure a larger delegation and thus greater total rewards. Importantly, operators face slashing penalties for misconduct just as restakers do (since the stake they carry can be slashed), aligning their behavior with honest execution. EigenLayer’s design effectively creates an open marketplace for validator services: AVS teams can “hire” operators by offering rewards, and operators will choose AVSs that are profitable relative to risk. For instance, one operator might focus on running an oracle AVS if it has high fees, while another might run a data layer AVS that requires lots of bandwidth but pays well. Over time, we expect a free-market equilibrium where operators choose the best mix of AVSs and set an appropriate fee split with their delegators. This contrasts with traditional single-chain staking where validators have fixed duties – here, they can multitask across services to stack earnings. The incentive for operators is thus to maximize their earnings per unit of staked collateral, without overloading to the point of slashing. It’s a delicate balance that should drive professionalization and maybe even insurance or hedging solutions (operators might insure against slashing to protect their delegators, etc.).

• Incentives for AVS Developers: Protocol developers (the teams building new AVSs or chains) arguably have the most to gain from restaking’s “security outsourcing” model. Their primary incentive is cost and time savings: they do not need to launch a new token with high inflation or persuade thousands of independent validators to secure their network from scratch. Bootstrapping a PoS network normally requires giving early validators large token rewards (diluting the supply) and can still result in weak security if the token’s market cap is low. With shared security, a new AVS can come online secured by Ethereum’s $200B+ economic security, instantly making attacks economically unviable. This is a huge draw for infrastructure projects like bridges or oracles that need strong safety guarantees. Moreover, developers can focus on their application logic and rely on EigenLayer (or Karak, etc.) for the validator set management, greatly reducing complexity. Economically, while the AVS must pay for security, it can often do so in a more sustainable way. Instead of huge inflation, it might redirect protocol fees or offer a modest native token stipend. For example, a bridge AVS could charge users fees in ETH and use those to pay restakers, achieving security without printing unbacked tokens. A recent analysis notes that eliminating the need for “highly dilutive reward mechanisms” was a key motivation behind Karak’s universal restaking design. Essentially, shared security allows “bootstrapping on a budget.” Additionally, if the AVS does have a token, it can be used more for governance or utility rather than purely for security spend. Developers are also incentivized by network effects: by plugging into a restaking hub, their service can more easily interoperate with other AVSs (shared users and operators) and gain exposure to the large community of Ethereum stakers. The flip side is that AVS teams must design compelling reward schemes to attract restakers and operators in the open market. This often means initially offering generous yields or token incentives to kickstart participation – much like liquidity mining in DeFi. For instance, EigenLayer itself distributed the EIGEN token widely to early stakers/operators to encourage participation. We see similar patterns with new restaking platforms (e.g. Karak’s XP campaign for future $KAR tokens). In summary, AVS developers trade off giving some rewards to Ethereum stakers in return for avoiding the dead-start problem of securing a new network. The strategic gain is faster time-to-market and higher security from day one, which can be a decisive advantage especially for critical infrastructure like cross-chain bridges or financial services that require trust.

Regulatory Risks and Governance Concerns​

Regulatory Uncertainty: The novel restaking model exists in a legal gray area, raising several regulatory questions. One concern is whether offering “security-as-a-service” could be seen by regulators as an unregistered security offering or a form of high-risk investment product. For example, the distribution of the EIGEN token via a staker airdrop and ongoing rewards has drawn scrutiny about compliance with securities laws. Projects must be careful that their tokens or reward schemes don’t trigger securities definitions (e.g. Howey test in the U.S.). Additionally, restaking protocols aggregate and reallocate stakes across networks, which might be viewed as a form of pooled investment or even a bank-like activity if not properly decentralized. EigenLayer’s team acknowledges the regulatory risk, noting that changing laws could impact the feasibility of restaking and that EigenLayer “might be classified as an illegal financial activity in some regions”. This means regulators could determine that handing off slashing control to third-party services (AVSs) violates financial or consumer-protection rules, especially if retail users are involved. Another angle is sanctions/AML: restaking moves stake into contracts that then validate other chains – if one of those chains is processing illicit transactions or is sanctioned, could Ethereum validators inadvertently fall foul of compliance? This remains untested. So far, no clear regulations target restaking specifically, but the evolving stance on crypto staking (e.g. the SEC’s actions against centralized staking services) suggests that restaking may attract scrutiny as it grows. Projects like EigenLayer have taken a cautious approach – for instance, the EIGEN token was initially non-transferrable upon launch to avoid speculative trading and potential regulatory issues. Nonetheless, until frameworks are defined, restaking platforms operate with the risk that new laws or enforcement could impose constraints (such as requiring participant accreditation, disclosures, or even prohibiting certain types of cross-chain staking).

Governance and Consensus Concerns: Restaking introduces complex governance challenges both at the protocol level and for the broader Ethereum ecosystem:

• Overloading Ethereum’s Social Consensus: A prominent worry, voiced by Vitalik Buterin, is that extended uses of Ethereum’s validator set could inadvertently drag Ethereum itself into external disputes. Vitalik’s admonition: “Dual-use of validator staked ETH, while it has some risks, is fundamentally fine, but attempting to ‘recruit’ Ethereum’s social consensus for your application’s own purposes is not.”. In plain terms, it’s acceptable if Ethereum validators also validate, say, an oracle network and get slashed individually for misbehavior there (no effect on Ethereum’s consensus). What’s dangerous is if an external protocol expects the Ethereum community or core protocol to step in to resolve some issue (for example, to fork out validators who behaved badly on the external service). EigenLayer’s design consciously tries to avoid this scenario by keeping slashable faults objective and isolated. Slashing conditions are cryptographic (e.g. double-signing proof) and do not require Ethereum governance intervention – thus any punishment is self-contained to the EigenLayer contract and doesn’t involve Ethereum altering its state or rules. In cases of subjective faults (where human judgment is needed, say for an oracle pricing dispute), EigenLayer plans to use its own governance (e.g. an EIGEN token vote or a council) rather than burden Ethereum’s social layer. This separation is critical to maintain Ethereum’s neutrality. However, as restaking grows, there is a systemic risk that if a major incident occurred (such as a bug causing mass slashing of a huge portion of validators), the Ethereum community might be pressured to respond (for instance, by reversing slashes). That would entangle Ethereum in the fate of external AVSs – exactly what Vitalik warns against. The social consensus risk is thus mostly about extreme “black swan” cases, but it underscores the importance of keeping Ethereum’s core minimal and uninvolved in restaking governance.

• Slashing Cascades and Ethereum Security: Relatedly, there is concern that slashing events in restaking could cascade and compromise Ethereum. If a very popular AVS (with many validators) suffered a catastrophic failure leading to mass slashing, thousands of ETH validators might lose stake or get forced out. In a worst-case scenario, if enough stake is slashed, Ethereum’s own validator set could shrink or centralize rapidly. For example, imagine a top EigenLayer operator running 10% of all validators is slashed on an AVS – those validators could go offline after losing funds, reducing Ethereum’s security. Chorus One (a staking service) analyzed EigenLayer and noted this cascade risk is exacerbated if the restaking market leads to only a few large operators dominating. The good news is that historically, slashing on Ethereum is rare and usually small-scale. EigenLayer also initially limited the amount of stake and disabled slashing while the system was new. By April 2025, EigenLayer enabled slashing on mainnet with careful monitoring. To further mitigate unintended slashes (e.g. due to bugs), EigenLayer introduced “slashing veto committees” – essentially a multi-sig of experts who can override a slashing if it appears to be a mistake or an attack on the protocol. This is a temporary centralizing measure, but it addresses the risk of a flawed AVS smart contract wreaking havoc. In time, such committees could be replaced by more decentralized governance or fail-safes.

• Centralization of Restaking and Governance: A key governance concern is who controls the restaking protocol and its parameters. In EigenLayer’s early stages, upgrades and critical decisions were controlled by a multisig of the team and close community (e.g. a 9-of-13 multisig). This is practical for rapid development safety, but it’s a centralization risk – those key holders could collude or be compromised to maliciously change rules (for instance, to steal staked funds). Recognizing this, EigenLayer established a more formal EigenGov framework in late 2024, introducing a Protocol Council of experts and a community governance process for changes. The council now controls upgrades via a 3-of-5 multisig, with community oversight. Over time, the intent is to evolve to token-holder governance or a fully decentralized model. Still, in any restaking system, governance decisions (like which new collateral to support, what AVS to “bless” with official status, how slashing disputes are resolved) carry high stakes. There’s a potential conflict of interest: large staking providers (like Lido or exchanges) could influence governance to favor their operators or assets. Indeed, competition is emerging – e.g. Lido’s founders backing Symbiotic, a multi-asset restaking platform – and one can imagine governance wars if, say, a proposal arises to ban a certain AVS that is seen as risky. The restaking layer itself needs robust governance to manage such issues transparently.

• Validator Centralization: On the operational side, there is concern that AVSs will preferentially choose big operators, causing centralization in who actually validates most of the restaked services. If, for efficiency, many AVS teams all select a handful of professional validators (e.g. major staking companies) to service them, those entities gain outsized power and share of rewards. They could then undercut others by offering better terms (thanks to economies of scale), potentially snowballing into an oligopoly. This mirrors concerns in vanilla Ethereum staking (e.g. Lido’s dominance). Restaking could amplify it since operators that run multiple AVSs have more revenue streams. This is as much an economic concern as a governance one – it might require community-imposed limits or incentives to encourage decentralization (for instance, EigenLayer could cap how much stake one operator can control, or AVSs could be required to distribute their assignments). Without checks, the “rich get richer” dynamic could lead to a few node operators effectively controlling large swathes of the Ethereum validator set across many services, which is unhealthy for decentralization. The community is actively discussing such issues, and some have proposed that restaking protocols include mechanisms to favor smaller operators or enforce diversity (perhaps via the delegation strategy or through social coordination by staker communities).

In summary, while restaking unlocks tremendous innovation, it also introduces new vectors of risk. Regulators are eyeing whether this represents unregulated yield products or poses systemic dangers. Ethereum’s leadership stresses the importance of not entangling base-layer governance in these new uses. The EigenLayer community and others have responded with careful design (objective slashing only, two-tier tokens for different fault types, vetting AVSs, etc.) and interim central control to prevent accidents. Ongoing governance challenges include decentralizing control without sacrificing safety, ensuring open participation rather than concentration, and establishing clear legal frameworks. As these restaking networks mature, expect improved governance structures and possibly industry standards or regulations to emerge that address these concerns.

EigenLayer vs. Karak vs. Babylon: A Comparative Analysis​

The restaking/shared-security landscape now includes several frameworks with different designs. Here we compare EigenLayer, Karak Network, and Babylon – highlighting their technical architectures, economic models, and strategic focus:

Technical Architecture & Security Base: EigenLayer is an Ethereum-native protocol (smart contracts on Ethereum L1) that leverages staked ETH (and equivalent Liquid Staking Tokens) as the security collateral. It “piggybacks” on Ethereum’s beacon chain – validators opt in via Ethereum contracts, and slashing is enforced on their ETH stake. This means EigenLayer’s security is fundamentally tied to Ethereum’s PoS and the value of ETH. In contrast, Karak positions itself as a “universal restaking layer” not tied to a single base chain. Karak launched its own L1 blockchain (with EVM compatibility) optimized for shared security services. Karak’s model is chain-agnostic and asset-agnostic: it allows restaking of many types of assets across multiple chains, not just ETH. Supported collateral reportedly includes ETH and LSTs plus other ERC-20s (stablecoins like USDC/sDAI, LP tokens, even other L1 tokens). This means Karak’s security base is a diversified basket; validation in Karak could be backed by, say, some combination of staked ETH, staked SOL (if bridged in), stablecoins, etc., depending on what the AVS (or “VaaS” in Karak’s terminology) accepts. Babylon takes a different route: it harnesses the security of Bitcoin (BTC) – the largest crypto asset – to secure other chains. Babylon is built as a Cosmos-based chain (Babylon Chain) that connects to Bitcoin and PoS chains via the IBC protocol. BTC holders lock native BTC on the Bitcoin mainnet (in a clever time-locked vault) and thereby “stake” BTC to Babylon, which then uses that as collateral to secure consumer PoS chains. Thus, Babylon’s security base is the value of Bitcoin (over $500B market cap), tapped in a trustless way (no wrapped BTC or custodians – it uses Bitcoin scripts to enforce slashing). In summary, EigenLayer relies on Ethereum’s economic security, Karak is multi-asset and multi-chain (a generic layer for any collateral), and Babylon extends Bitcoin’s proof-of-work security into PoS ecosystems.

Restaking Mechanism: In EigenLayer, restaking is opt-in via Ethereum contracts; slashing is programmatic and enforced by Ethereum consensus (honoring the EigenLayer contracts). Karak, as an independent L1, maintains its own restaking logic on its chain. Karak introduced the concept of Validation-as-a-Service (VaaS) – analogous to Eigen’s AVS – but with a universal validator marketplace across chains. Karak’s validators (operators) run its chain and any number of Distributed Secure Services (DSS), which are Karak’s equivalent of AVSs. A DSS might be a new app-specific blockchain or service that rents security from Karak’s staked asset pool. Karak’s innovation is standardizing requirements so that any chain or app (Ethereum, Solana, an L2, etc.) could plug in and use its validator network and varied collateral. Slashing in Karak would be handled by its protocol rules – since it can stake e.g. USDC, it presumably slashes a validator’s USDC if they misbehave on a service (the exact multi-asset slashing mechanics are complex and not public, but the idea is similar: each collateral can be taken away if violations are proven). Babylon’s mechanism is unique due to Bitcoin’s limitations: Bitcoin doesn’t support smart contracts to auto-slash, so Babylon uses cryptographic tricks. BTC is locked in a special output that requires a key. If a BTC-staking participant cheats (e.g. signs two conflicting blocks on a client chain), the protocol leverages an extractable one-time signature (EOTS) scheme to reveal the participant’s private key, allowing their locked BTC to be swept to a burn address. In simpler terms, misbehavior causes the BTC staker to effectively slash themselves, as the act of cheating gives away control of their deposit (which is then destroyed). Babylon’s Cosmos-based chain coordinates this process and communicates with partner chains (via IBC) to provide services like checkpointing and finality using BTC’s timestamps. In Babylon, the validators of the Babylon chain (called finality providers) are separate – they run the Babylon consensus and assist in relaying information to Bitcoin – but don’t provide economic security; the economic security comes purely from locked BTC.

Economic Model & Rewards: EigenLayer’s economic model is centered on Ethereum’s staking economy. Restakers earn AVS-specific rewards – these could be paid in ETH fees, the AVS’s own token, or other tokens depending on each AVS’s design. EigenLayer itself introduced the $EIGEN token largely for governance and to reward early participants, but AVSs are not required to use or pay in EIGEN (it’s not a gas token for them). The platform targets a free-market equilibrium where each AVS sets a reward rate to attract sufficient security. Karak appears to be launching its native token $KAR (not yet live as of early 2025) as the primary asset in its ecosystem. Karak raised $48M and was backed by major investors, implying $KAR will have value and likely be used for governance and possibly fee payments on the Karak network. However, Karak’s main promise is “no inflation” for new networks leveraging it – instead of issuing their own tokens for security, they tap into existing assets via Karak. So a new chain using Karak might pay validators in, say, its transaction fees (which could be in a stablecoin or in the chain’s native token if it has one) but would not need to continuously mint new tokens for staking rewards. Karak set up a validator marketplace where developers can post bounties/rewards for validators to restake assets and secure their service. This marketplace approach aims to make rewards more competitive and consistent rather than extremely high inflation followed by crash – theoretically reducing costs for developers and giving validators steady multi-chain income. Babylon’s economics differ as well: BTC stakers who lock their Bitcoin earn yield in the tokens of the networks they are securing. For example, if you stake BTC to help secure a Cosmos zone (one of Babylon’s client chains), you receive that zone’s staking rewards (its native staking token) as if you were a delegator there. Those partner chains benefit by getting an extra layer of security (checkpoints on Bitcoin, etc.), and in return they allocate a portion of their inflation or fees to BTC stakers via Babylon. In effect, Babylon acts as a hub where BTC holders can delegate security to many chains and get paid in many tokens. The Babylon chain itself has a token called $BABY, used to stake in Babylon’s own consensus (Babylon still needs its own PoS validators to run the chain’s infrastructure). $BABY is also likely used in governance and maybe to align incentives (for instance, finality providers stake BABY). But importantly, $BABY does not replace BTC as the source of security – it’s more for running the chain – whereas BTC is the collateral that backs the shared security service. As of May 2025, Babylon had successfully bootstrapped with over 50,000 BTC staked (~$5.5 billion) by BTC holders, making it one of the most secure Cosmos chains by capital. Those BTC stakers then earn staking rewards from multiple connected chains (e.g. Cosmos Hub’s ATOM, Osmosis’s OSMO, etc.), achieving diversified yield while holding BTC.

Strategic Focus and Use Cases: EigenLayer’s strategy has been Ethereum-centric, aiming to accelerate innovation within the Ethereum ecosystem. Its early target use cases (data availability, middleware like oracles, rollup sequencing) all enhance Ethereum or its rollups. It essentially supercharges Ethereum as a meta-layer of services, and now with its planned “multi-chain” support (added in 2025), EigenLayer will allow AVSs to run on other EVM chains or L2s while still using Ethereum’s validator set. This cross-chain verification means EigenLayer is evolving into a cross-chain security provider, but anchored in Ethereum (validators and staking still live on Ethereum for slashing). Karak positions itself as a globally extensible base layer for all kinds of applications – not just crypto infrastructure, but also real-world assets, financial markets, even government services, according to its marketing. The name “Global Base Layer for Programmable GDP” hints at an ambition to work with institutions and nation-states. Karak emphasizes integration of traditional finance and AI, suggesting it will pursue partnerships beyond the crypto-native realm. Technically, by supporting assets like stablecoins and potentially government currencies, Karak could enable, for example, a government to launch a blockchain secured by its own fiat token staked via Karak’s validators. Its support for enterprise and multiple jurisdictions is a differentiator. In essence, Karak is trying to be “restaking for everyone, on any chain, with any asset” – a broader net than EigenLayer’s Ethereum-first approach. Babylon’s focus is on bridging the Bitcoin and Cosmos (and broader PoS) ecosystems. It specifically enhances inter-chain security by providing Bitcoin’s immutability and economic weight to otherwise smaller proof-of-stake chains. One of Babylon’s killer apps is adding Bitcoin finality checkpoints to PoS chains, making it extremely hard for those chains to be attacked or reorganized without also attacking Bitcoin. Babylon thus markets itself as bringing “Bitcoin’s security to all of crypto”. Its near-term focus has been Cosmos SDK chains (which it calls Bitcoin Supercharged Networks in Phase 3), but the design is meant to be interoperable with Ethereum and rollups as well. Strategically, Babylon taps into the vast BTC holder base, giving them a yield option (BTC is otherwise a non-yielding asset) and at the same time offering chains access to the “gold standard” of crypto security (BTC + PoW). This is quite distinct from EigenLayer and Karak, which are more about leveraging PoS assets.

Table: EigenLayer vs Karak vs Babylon

Feature	EigenLayer (Ethereum)	Karak Network (Universal L1)	Babylon (Bitcoin–Cosmos)
Base Security Asset	ETH (Ethereum stake) and whitelisted LSTs.	Multi-asset: ETH, LSTs, stablecoins, ERC-20s, etc.. Also cross-chain assets (Arbitrum, Mantle, etc.).	BTC (native Bitcoin) locked on Bitcoin mainnet. Uses Bitcoin’s high market cap as security.
Platform Architecture	Smart contracts on Ethereum L1. Uses Ethereum validators/clients; slashing enforced by Ethereum consensus. Now expanding to support AVSs on other chains via Ethereum proofs.	Independent Layer-1 chain (“Karak L1”) with EVM. Provides a restaking framework (KNS) to launch new blockchains or services with instant validator sets. Not a rollup or L2 – a separate network bridging multiple ecosystems.	Cosmos-based chain (Babylon Chain) connecting to Bitcoin via cryptographic protocols. Uses IBC to link with PoS chains. Babylon validators run a Tendermint consensus, and Bitcoin network is leveraged for timestamps & slashing logic.
Security Model	Opt-in restaking: Ethereum stakers delegate stake to EigenLayer and opt into AVS-specific slashing conditions. Slashing conditions are objective (cryptographic proofs) to avoid Ethereum social consensus issues.	Universal validation: Karak validators can stake various assets and are assigned to secure Distributed Secure Services (DSS) (similar to AVSs) across many chains. Slashing and rewards handled by Karak’s chain logic; standardizes security as a service for any chain.	“Remote staking” BTC: Bitcoin holders lock BTC in self-custody vaults (timelocked UTXOs) and if they misbehave on a client chain, their private key can be exposed to slash (burn) their BTC. Uses Bitcoin’s own mechanics (no token wrapping). Babylon chain coordinates this and provides checkpointing (BTC finality) to client chains.
Token & Rewards	EIGEN token: Used for governance and to reward early participants (via airdrop, incentives). Restakers mainly earn in AVS fees or tokens (could be ETH, stablecoins, or AVS-native tokens). EigenLayer itself doesn’t mandate a cut for EIGEN token holders in AVS revenue (though EIGEN may have future utility in subjective validation tasks).	KAR token: Not yet launched (expected in 2025). Will be main utility/governance token in Karak’s ecosystem. Karak touts no native inflation for new chains – validators earn consistent rewards by securing many services. New protocols can incentivize validators via the Karak marketplace rather than high inflation tokens. Likely KAR will be used for Karak chain security and governance decisions.	BABY token: Native to Babylon Chain (for staking its validators, governance). BTC stakers do not receive BABY for their service, instead they earn yield in the tokens of the connected PoS chains they secure. (E.g. stake BTC to secure Chain X, earn Chain X’s staking rewards). This keeps BTC stakers’ exposure mostly to existing tokens. BABY’s role is to secure the Babylon hub and possibly as gas or governance in the Babylon ecosystem.
Notable Use Cases	Ethereum-aligned infrastructure: e.g. EigenDA (data availability for rollups), oracle networks (e.g. Tellor/eOracle), cross-chain bridges (LayerZero integrating), shared sequencers for rollups (Espresso, Radius), off-chain compute (Risc Zero, etc.). Also exploring decentralized MEV relay services and liquid restaking derivatives. Essentially, extends Ethereum’s capabilities (scaling, interoperability, DeFi middleware) by providing a decentralized trust layer.	Broad focus including traditional finance integration: tokenized real-world assets, 24/7 trading markets, even government and AI applications on bespoke chains. For example, KUDA (data availability marketplace) and others are being built in Karak’s ecosystem. Could host enterprise consortia chains that use USD stablecoins as staking collateral, etc. Karak is targeting multi-chain developers who want security without being limited to Ethereum validators or ETH only. Also emphasizes interoperability and capital efficiency – e.g. using lower-opportunity-cost assets (like smaller L1 tokens) for restaking so that yields can be higher without competing with ETH’s yield.	Security for Cosmos chains and beyond: e.g. using BTC to secure Cosmos Hub, Osmosis, and other zones (enhancing their security without those zones increasing inflation). Provides Bitcoin timestamp finality – any chain that opts in can have important transactions hashed onto Bitcoin for censorship-resistance and finality. Especially useful for new PoS chains that want to prevent long-range attacks or add a Bitcoin “root of trust.” Babylon effectively creates a bridge between Bitcoin and PoS networks: Bitcoin holders gain yield from PoS, and PoS chains gain BTC’s security and community. It’s complementary to restaking with ETH; for instance, a chain might use EigenLayer for ETH economic security and Babylon for BTC robustness.

Strategic Differences: EigenLayer benefits from Ethereum’s massive decentralized validator set and credibility, but it is limited to ETH-based security. It excels at serving Ethereum-oriented projects (many AVSs are Ethereum rollup or middleware projects). Karak’s strategy is to capture a larger market by being flexible in asset support and chain support – it’s not married to Ethereum and even pitches that developers can avoid being “confined exclusively to Ethereum for security”. This could attract projects in ecosystems like Arbitrum, Polygon, or even non-EVM chains that want a neutral security provider. Karak’s multi-asset approach also means it can tap into assets that have lower yields elsewhere; as co-founder Raouf Ben-Har noted, “Many assets have lower opportunity costs versus ETH… meaning [our services] have an easier path to sustainable yields.”. For example, staked ARB (Arbitrum’s token) currently has few uses; Karak could let ARB holders restake into securing new dApps, creating a win-win (yield for ARB holders, security for the dApp). This strategy, however, comes with technical complexity (managing different asset risks) and trust assumptions (bridging assets into Karak’s platform safely). Babylon’s strategy is distinct by focusing on Bitcoin – it is leveraging the largest crypto asset by market cap, which also has a very different community and use profile (long-term holders). Babylon basically unlocked a new staking source that was previously untapped: $1.2 trillion of BTC that could not natively stake. By doing so, it addresses a huge security pool and targets chains that value Bitcoin’s assurances. It also appeals to Bitcoin holders by giving them a way to earn yield without giving up custody of BTC. One might say Babylon is almost the inverse of EigenLayer: instead of extending Ethereum’s security outward, it is importing Bitcoin’s security into PoS networks. Strategically, it could unify the historically separate Bitcoin and DeFi worlds.

Each of these frameworks has trade-offs. EigenLayer currently enjoys a first-mover advantage in Ethereum restaking and a large TVL (~$20B restaked by late 2024), plus deeply integrated Ethereum community support. Karak is newer (mainnet launched April 2024) and aims to grow by covering niches EigenLayer doesn’t (non-ETH collateral, non-Ethereum chains). Babylon operates in the Cosmos arena and taps Bitcoin – it doesn’t compete with EigenLayer for ETH stakers, but rather offers an orthogonal service (some projects might use both). We are seeing a convergence where multiple restaking layers could even interoperate: e.g. an Ethereum L2 could use EigenLayer for ETH-based security and also accept BTC security via Babylon – demonstrating that these models are not mutually exclusive but part of a broader “shared security market”.

Recent Developments and Ecosystem Updates (2024–2025)​

EigenLayer’s Progress: Since its inception in 2021, EigenLayer has rapidly evolved from concept to a live network. It launched on Ethereum mainnet in stages – Stage 1 in mid-2023 enabled basic restaking, and by April 2024 the full EigenLayer protocol (with support for operators and initial AVSs) was deployed. The ecosystem growth has been substantial: as of early 2025 EigenLayer reports 29 AVSs live on mainnet (and 130+ in development) ranging from data layers to oracles. Over 200 operators and tens of thousands of restakers are participating, contributing to a restaked TVL that reached ~$20 billion by late 2024. A major milestone was the introduction of slashing and reward enforcement on mainnet in April 2025, marking the final step of EigenLayer’s security model coming into effect. This means AVSs can now truly penalize misbehavior and pay out rewards trustlessly, moving past the “trial phase” where these were turned off. Alongside this, EigenLayer implemented a series of upgrades: for example, the MOOCOW upgrade (July 2025) improved validator efficiency by allowing easier restake withdrawals and consolidation (leveraging Ethereum’s Pectra fork). Perhaps the most significant new feature is Multi-Chain Verification, launched in July 2025, which enables AVSs to operate across multiple chains (including L2s) while still using Ethereum-based security. This was demonstrated on Base Sepolia testnet and will roll out to mainnet, effectively turning EigenLayer into a cross-chain security provider (not just for Ethereum L1 apps). It addresses a prior limitation that EigenLayer AVSs had to post all data on Ethereum; now an AVS can run on, say, an Optimistic Rollup or another L1, and EigenLayer will verify proofs (using Merkle roots) back on Ethereum to slash or reward as needed. This greatly expands EigenLayer’s reach and performance (AVSs can run where it’s cheaper while keeping Ethereum security). In terms of community and governance, EigenLayer rolled out EigenGov in late 2024 – a council and ELIP (EigenLayer Improvement Proposal) framework to decentralize decision-making. The Protocol Council (5 members) now oversees critical changes with community input. Additionally, EigenLayer has been conscious of concerns raised by Ethereum’s core community. In response to Vitalik’s warnings, the team has published materials explaining how they avoid overloading Ethereum’s consensus, for instance by using the EIGEN token for any “subjective” services and leaving ETH restaking for purely objective slashing cases. This two-tier approach (ETH for clear-cut faults, EIGEN for more subjective or governance-led decisions) is still being refined, but shows EigenLayer’s commitment to aligning with Ethereum’s ethos.

On the ecosystem side, EigenLayer’s emergence has inspired a wave of innovation and discussion. By mid-2024, analysts noted restaking had become “a leading narrative within the Ethereum community”. Many DeFi and infrastructure projects started plotting how to leverage EigenLayer for security or additional yield. At the same time, community members are debating risk management: for example, Chorus One’s detailed risk report (April 2024) brought attention to operator centralization and cascade slashing risks, prompting further research and possibly features like stake distribution monitoring. The EIGEN token distribution was also a hot topic – in Q4 2024 EigenLayer conducted a “stake drop” where active Ethereum users and early EigenLayer participants received EIGEN, but it was non-transferrable initially. Some community members were unhappy with aspects of the drop (e.g. large portions allocated to VCs, and some DeFi protocols that integrated EigenLayer not being directly rewarded). This feedback has led the team to emphasize more community-centric incentives moving forward, and indeed the Programmatic Incentives introduced aim to continuously reward those actually restaking and operating. By 2025, EigenLayer is one of the fastest-growing developer ecosystems – even recognized in an Electric Capital report – and has secured major partnerships (e.g. with LayerZero, ConsenSys, Risc0) to drive adoption of AVSs. Overall, EigenLayer’s trajectory in 2024–2025 shows a maturing platform addressing early concerns and expanding functionality, solidifying its position as the pioneer of Ethereum restaking.

Karak and Other Competitors: Karak Network stepped into the spotlight with its mainnet launch in April 2024 and quickly positioned itself as a notable EigenLayer rival on Ethereum and beyond. Backed by large investors and even certain Ethereum stakeholders (Coinbase Ventures, among others), Karak’s promise of “restaking for everyone, on any chain, with any asset” garnered attention. In late 2024, Karak upgraded to a V2 mainnet with enhanced features for universal security, completing migrations across Arbitrum and Ethereum by November 2024. This indicates Karak expanded support for more assets and possibly improved its smart contracts or consensus. By early 2025, Karak had grown its user base via an XP incentive program (encouraging testnet participation, staking, etc., with the hope of a future $KAR airdrop). Community discussions around Karak often compare it to EigenLayer: Bankless noted in May 2024 that while Karak’s total value staked was still “nowhere near the size of EigenLayer,” it had seen rapid growth (4x in a month) possibly due to users seeking higher rewards or diversifying away from EigenLayer. Karak’s appeal lies in supporting assets like Pendle yield tokens, Arbitrum’s ARB, Mantle’s token, etc., which broadens the restaking market. As of 2025, Karak is likely focusing on onboarding more “Validation-as-a-Service” clients and possibly preparing the launch of its KAR token (its documentation suggests following official channels for token updates). The competition between EigenLayer and Karak remains friendly but significant – both aim to attract stakers and projects. If EigenLayer holds the ETH maximalist segment, Karak is appealing to multi-chain users and those with non-ETH assets looking for yield. We can expect Karak to announce partnerships in the coming year, perhaps with Layer2 networks or even institutional players given its “institutional-grade” branding. The restaking market is thus not a monopoly; rather, multiple platforms are finding niches, which could lead to a fragmented but rich ecosystem of shared security providers.

Babylon’s Launch and the BTC Staking Frontier: Babylon completed a major milestone in 2025 by activating its core functionality – Bitcoin staking for shared security. After a Phase-1 testnet and gradual rollout, Babylon’s Phase-2 mainnet went live in April 2025, and by May 2025 it reported over 50k BTC staked in the protocol. This is a remarkable achievement, effectively plugging in ~$5B of Bitcoin into the interchain security market. Babylon’s early adopter chains (the first “Bitcoin Supercharged Networks”) include several Cosmos-based chains that integrated Babylon’s light client and started relying on BTC checkpoint finality. The Babylon Genesis chain itself launched on April 10, 2025, secured by the new $BABY token staking, and one day later (April 11) the trustless BTC staking was piloted with an initial 1000 BTC cap. By April 24, 2025, BTC staking opened permissionlessly to all, and the cap was lifted. The smooth operation for the first weeks led the team to declare Bitcoin staking “successfully bootstrapped,” calling Babylon Genesis now “among the most secure L1s in the world in terms of staking market cap.”. With Phase-2 complete, Phase-3 aims to onboard many external networks as clients, turning them into BSNs (Bitcoin Supercharged Networks). This will involve interoperability modules so that Ethereum, its rollups, and any Cosmos chain can all use Babylon to draw security from BTC. The Babylon community – comprising Bitcoin holders, Cosmos devs, and others – has been actively discussing governance of the $BABY token (ensuring the Babylon chain remains neutral and reliable for all connected chains) and the economics (for instance, balancing BTC staking rewards among many consumer chains so that it’s attractive to BTC holders without over-subsidizing). One interesting development is Babylon’s support for things like Nexus Mutual cover (as per a May 2025 post) to offer insurance on BTC staking slashing, which could further entice participants. This shows the ecosystem maturing around risk management for this new paradigm.

Community and Cross-Project Discussions: As of 2025, a broader conversation is taking place about the future of shared security in crypto. Ethereum’s community largely welcomes EigenLayer but remains cautious; Vitalik’s blog post (May 2023) set the tone for careful delineation of what is acceptable. EigenLayer regularly engages the community via its forum, addressing questions like “Is EigenLayer overloading Ethereum’s consensus?” (short answer: they argue it is not, due to design safeguards). In the Cosmos community, Babylon sparked excitement as it potentially solves long-standing security issues (e.g. small zones suffering 51% attacks) without requiring them to join a shared-security hub like Polkadot or Cosmos Hub’s ICS. There is also interesting convergence: some Cosmos folks ask if Ethereum staking could ever power Cosmos chains (which is more EigenLayer’s domain), while Ethereum folks wonder if Bitcoin staking could secure Ethereum rollups (Babylon’s concept). We are seeing early signs of cross-pollination: for instance, ideas of using EigenLayer to restake ETH onto non-Ethereum chains (Symbiotic and Karak are steps in that direction) and using Babylon’s BTC staking as an option for Ethereum L2s. Even Solana has a restaking project (Solayer) that launched a soft test and hit caps quickly, showing the interest spans multiple ecosystems.

Governance developments across these projects include increasing community representation. EigenLayer’s council includes external community members now, and it has funded grants (via the Eigen Foundation) to Ethereum core devs, signaling goodwill back to Ethereum’s core. Karak’s governance is likely to revolve around the KAR token – currently, they run an off-chain XP system, but one can expect a more formal DAO once KAR is liquid. Babylon’s governance will be crucial as it coordinates between Bitcoin (which has no formal governance) and Cosmos chains (which have on-chain governance). It set up a Babylon Foundation and community forum to discuss parameters like unbonding periods for BTC, which require careful alignment with Bitcoin’s constraints.

In summary, by mid-2025 the restaking and shared security market has gone from theory to practice. EigenLayer is fully operational with real services and slashing, proving out the model on Ethereum. Karak has introduced a compelling multi-chain variant, broadening the design space and targeting new assets. Babylon has demonstrated that even Bitcoin can join the shared security party via clever cryptography, addressing a completely different segment of the market. The ecosystem is vibrant: new competitors (e.g. Symbiotic on Ethereum, Solayer on Solana, BounceBit using custodial BTC) are emerging, each experimenting with different trade-offs (Symbiotic aligning with Lido to use stETH and any ERC-20, BounceBit taking a regulated approach with wrapped BTC, etc.). This competitive landscape is driving rapid innovation – and importantly, discussion about standards and safety. Community forums and research groups are actively debating questions like: Should there be limits on restaked stake per operator? How to best implement cross-chain slashing proofs? Could restaking unintentionally increase systemic correlation between chains? All of these are being studied. The governance models are also evolving – EigenLayer’s move to a semi-decentralized council is one example of balancing agility and security in governance.

Looking ahead, the restaking paradigm is poised to become a foundation of Web3 infrastructure, much like how cloud services became essential in Web2. By commoditizing security, it enables smaller projects to launch with confidence and larger projects to optimize their capital use. The developments through 2025 show a promising yet cautious trajectory: the technology works and is scaling, but all players are mindful of risks. With Ethereum’s core devs, Cosmos builders, and even Bitcoiners now involved in shared security initiatives, it’s clear this market will only grow. We can expect closer collaboration across ecosystems (perhaps joint security pools or standardized slashing proofs) and, inevitably, regulatory clarity as regulators catch up to these multi-chain, multi-asset constructs. In the meantime, researchers and developers have a trove of new data from EigenLayer, Karak, Babylon, and others to analyze and improve upon, ensuring that the “restaking revolution” continues in a safe and sustainable manner.

Sources:

1. EigenLayer documentation and whitepaper – definition of restaking and AVS
2. Coinbase Cloud blog (May 2024) – EigenLayer overview, roles of restakers/operators/AVSs
3. Blockworks News (April 2024) – Karak founders on “universal restaking” vs EigenLayer
4. Ditto research (2023) – Comparison of EigenLayer, Symbiotic, Karak asset support
5. Messari Research (Apr 2024) – “Babylon: Bitcoin Shared Security”, BTC staking mechanism
6. HashKey Research (Jul 2024) – Babylon vs EigenLayer restaking yields
7. EigenLayer Forum (Dec 2024) – Discussion of Vitalik’s “Don’t overload Ethereum’s consensus” and EigenLayer’s approach
8. Blockworks News (Apr 2024) – Chorus One report on EigenLayer risks (slashing cascade, centralization)
9. Kairos Research (Oct 2023) – EigenLayer AVS overview and regulatory risk note
10. EigenCloud Blog (Jan 2025) – “2024 Year in Review” (EigenLayer stats, governance updates)
11. Blockworks News (Apr 2024) – Karak launch coverage and asset support
12. Babylon Labs Blog (May 2025) – “Phase-2 launch round-up” (Bitcoin staking live, 50k BTC staked)
13. Bankless (May 2024) – “The Restaking Competition” (EigenLayer vs Karak vs others)
14. Vitalik Buterin, “Don’t Overload Ethereum’s Consensus”, May 2023 – Guidance on validator reuse vs social consensus
15. Coinbase Developer Guide (Apr 2024) – Technical details on EigenLayer operation (EigenPods, delegation, AVS structure).