<p></p><h2 id="what-is-babylon">What is Babylon?</h2><p><a href="https://twitter.com/babylon_chain?ref=p2p.org" rel="noreferrer">Babylon</a> is <strong>a revolutionary staking protocol that allows Bitcoin holders to provide their BTC assets to secure PoS systems</strong> and receive a yield on their assets.</p><blockquote>The idea of BTC staking is relatively new and needs further explanation. When discussing BTC staking, many people associate it with locking BTC in some multisig account, bridging BTC to other chains, and minting new synthetic tokens. The addition of third parties always reduces security. However, that's not the case with Babylon.</blockquote><p>To avoid misunderstandings, let’s clarify that Babylon is a Bitcoin Staking Protocol that provides shared security for PoS systems and allows Bitcoin holders to delegate their BTC to Finality Providers, who can then provide Bitcoin security to a consumer PoS chain or DA layer. On the other hand, there is also the Babylon chain, built on Cosmos SDK, which receives security from the Babylon Bitcoin Staking Protocol and acts as the first chain that Finality Providers can support. However, <strong>Babylon plans to support different PoS systems from various blockchain ecosystems and provide them access to shared security collateral with BTC.</strong></p><p>In this article, we’ll focus on the Babylon Bitcoin Staking Protocol. <strong>We’ll show you how the staking flow works</strong>, how Babylon applies non-custodial features, and why the process is secure.</p><h2 id="core-parts-of-the-babylon-bitcoin-staking-protocol">Core Parts of the Babylon Bitcoin Staking Protocol</h2><p>The Babylon Bitcoin Staking Protocol consists of two key protocols designed to enhance security in decentralized systems. These protocols leverage the robust features of both Bitcoin and Babylon:</p><ol><li><strong>Bitcoin Timestamping Protocol. </strong>This protocol in Babylon allows data from PoS systems, such as blockchains or DA layers, to be securely timestamped on the Bitcoin network. The protocol enables any data submitted to Babylon to receive Bitcoin timestamps, enhancing their security as more blocks are added over time. This increased immutability helps protect PoS systems from long-range attacks, improving their integrity. Additionally, this protocol facilitates data exchange between Bitcoin and other PoS systems that utilize BTC for security.</li><li><strong>Bitcoin Staking Protocol.&nbsp;</strong>Babylon’s Bitcoin Staking Protocol enables Bitcoin to secure decentralized systems through trustless, self-custodial staking. Bitcoin holders can stake their Bitcoin for PoS systems without needing third-party custody, bridges, or wrapping. This protocol offers economic security guarantees to PoS systems, allowing for slashing if necessary, and ensures efficient stake unbonding to enhance liquidity for Bitcoin holders. It’s designed to be modular and compatible with various PoS consensus protocols, serving as a foundation for building restaking protocols.</li></ol><p>These protocols form a solid foundation for Babylon, providing the ability to stake BTC and exchange data between Bitcoin and chains that use BTC as security collateral.</p><h2 id="how-does-staking-work">How does staking work?</h2><p>Before describing the entire flow, <strong>let’s briefly talk about the staking process's cornerstones: the Finality Providers' role, a time lock, and an EOTS signature.</strong></p><h3 id="finality-providers">Finality Providers</h3><p>Babylon introduces an additional layer of finality that can be added on top of CometBFT or other consensus protocols. Finality Providers are responsible for voting in a finality round on top of these consensus protocols.<br>Finality Providers can receive voting power delegations from BTC stakers and earn commissions from the staking rewards denominated in the tokens of the networks they support.</p><p>If a Cosmos chain decides to integrate with the Babylon Bitcoin Staking Protocol, they need to onboard Finality Providers in addition to their existing set of validators. Additionally, they must incentivize Finality Providers to secure the network by providing additional rewards.</p><p>This dual-layer security system creates a strong shared security that can be used by various PoS systems. <strong>By combining the efforts of current validators and Finality Providers, Babylon offers a solid foundation that PoS systems can use to boost their own security.</strong> This shared security strengthens the Babylon network and provides a reliable security setup for other networks and applications that connect with Babylon.</p><h3 id="a-time-lock">A Time Lock&nbsp;</h3><p>A UTXO time lock is a feature of the Bitcoin blockchain that ensures certain coins can't be used until a specific time or block height is reached. Since Bitcoin doesn't have smart contract functionality, developers use UTXO scripts to create these time locks. To set up a time lock on a UTXO, users need to utilize Bitcoin's script language. Bitcoin scripts define the conditions under which a transaction output can be spent. In the case of a time lock, the script includes specific opcodes (operations) that enforce the time-based restriction.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/1920x1080-9.jpg" class="kg-image" alt loading="lazy" width="1920" height="804" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/1920x1080-9.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/1920x1080-9.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/1920x1080-9.jpg 1600w, https://p2p.org/economy/content/images/2024/05/1920x1080-9.jpg 1920w" sizes="(min-width: 720px) 720px"></figure><p>Using time locks, Babylon can maintain a secure and trustless staking environment, giving users confidence that their staked assets remain controlled until the time lock conditions are met. This approach not only secures the funds but also enhances the overall integrity of the staking process.</p><h3 id="eots-signature">EOTS Signature</h3><p>An EOTS (Extractable One-Time Signature) is a cryptographic feature used by Babylon to enhance the security and integrity of its staking process. EOTS signatures are built using Schnorr signatures, which prevent finality providers from double-signing. In the context of Babylon, an EOTS signature ensures that if a finality provider attempts to sign two conflicting blocks, their secret key is revealed. This exposed secret key can then be used to penalize the malicious actor by triggering a slashing mechanism.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/1920x1080-36.jpg" class="kg-image" alt loading="lazy" width="1920" height="804" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/1920x1080-36.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/1920x1080-36.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/1920x1080-36.jpg 1600w, https://p2p.org/economy/content/images/2024/05/1920x1080-36.jpg 1920w" sizes="(min-width: 720px) 720px"></figure><p><br>Babylon employs EOTS signatures to ensure that Finality Providers validate blocks correctly and honestly. When a user like Alice stakes her Bitcoin, she relies on a Finality Provider to validate blocks using her staked BTC as collateral. If the Finality Provider behaves maliciously, for example, by signing the same block twice, the EOTS signature mechanism kicks in. Observers can detect the double-signing, reveal the provider’s EOTS secret key, and use this information to initiate a slashing transaction.</p><p><strong>Here’s how the EOTS signature is involved in the staking process:</strong></p><ol><li>Generating an EOTS Key Pair: The Finality Provider creates a pair of keys: a secret nonce and a public nonce.</li><li>Public Declaration: The Finality Provider announces in advance that for chain-X at block height-1000, this public nonce will be used to verify her vote. This ensures that only votes signed with this specific nonce will be accepted.</li><li>Signing the Block: After verifying block-1000 and being satisfied with it, the Finality Provider uses the secret nonce and her EOTS secret key to sign the block. She then publishes this signature as her vote.</li><li>Verification: The other participants can verify the vote using the finality provider’s EOTS public key and the pre-declared public nonce.</li></ol><p>Using EOTS signatures, Babylon adds an extra layer of security to its staking process. This mechanism guarantees that any attempt by a finality provider to act dishonestly is met with immediate consequences, such as slashing the staked BTC. This approach protects Alice's funds and maintains the integrity and trustworthiness of the entire Babylon staking system.</p><p>Let's imagine that Alice decides to stake her coins. What steps should she take?</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/1920x1080-37--1-.jpg" class="kg-image" alt loading="lazy" width="2000" height="782" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/1920x1080-37--1-.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/1920x1080-37--1-.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/1920x1080-37--1-.jpg 1600w, https://p2p.org/economy/content/images/2024/05/1920x1080-37--1-.jpg 2000w" sizes="(min-width: 720px) 720px"></figure><h3 id="creating-a-staking-transaction">Creating a Staking Transaction&nbsp;</h3><p>When signing the transaction, Alice makes four essential steps:</p><ol><li>Creates a time lock for her BTC for a specified time range.</li><li>Chooses a Finality Provider to validate blocks and use Alice's BTC as security collateral.</li><li>Pre-signs a slashing transaction: Alice approves the transaction to be slashed if the finality provider she chooses acts maliciously. The finality provider's secret key is the only thing needed to broadcast this transaction. Bitcoins are slashed by sending them to a Bitcoin burn address like 0000…0000.</li><li>Links a Cosmos-based wallet for receiving rewards.</li></ol><h3 id="block-validation">Block Validation</h3><p>After staking BTC, the Finality Provider starts validating blocks to secure the PoS systems using the BTC delegated by Alice. There are two main scenarios for the finality provider:</p><ol><li>Acts Correctly—If the Finality Provider acts correctly and validates blocks without double-signing or being offline, the provider receives rewards for validating blocks, which Alice can claim. The Finality Provider can charge a fee for its validation services.</li><li>Acts Maliciously – If the Finality Provider acts maliciously, it can lead to a slashing transaction. Here’s how it can happen:<ol><li>For example, the Finality Provider acts maliciously by signing one block twice.</li><li>Whoever sees both votes can decrypt the provider’s EOTS secret key.</li><li>A special covenant committee signs the pre-signed slashing transaction created by the staker using the finality provider’s EOTS secret key.</li><li>The slashing transaction is broadcast to the network, and a portion of BTC is sent to a burn address like 0000…0000.</li><li>The remaining portion is returned to Alice.</li></ol></li></ol><p>Because of Babylon's approach's beauty, BTC is always held in Alice's account. If slashing occurs, her Bitcoin can only be withdrawn or sent to a burn address. The EOTS secret key is required to slash Alice's transaction, which can only be revealed if the validator acts maliciously. This architectural approach provides confidence that the whole process is secure and trustless, ensuring that Alice maintains control over her assets at all times.&nbsp;</p><p><strong>Alice's most important decision is choosing a provider with enough experience in the validating industry to secure her BTC without the risk of slashing it.</strong></p><h2 id="why-is-babylons-btc-staking-approach-different-from-alternatives">Why is Babylon's BTC staking approach different from alternatives?</h2><p>BTC holders can find different BTC staking solutions on the market. The most popular ones are Bitcoin L2s. If users want to stake their Bitcoins, they typically need to bridge Bitcoin using bridges, mint BTC derivatives on the receiving network, and find a protocol that allows them to stake their coins.</p><p>Most Bitcoin Layer 2 solutions don't use BTC as collateral for supporting PoS chains. Instead, they provide yield to BTC holders through additional emission, liquidity provision, or lending mechanisms.</p><p>Babylon's approach is more secure because it doesn't involve bridging or minting synthetic BTC. The source of yield is always clear, as it comes from supporting PoS networks, which reward validators with their coins.</p><p>We believe in the Bitcoin staking narrative and are committed to helping the Babylon Foundation use idle Bitcoin capital to fortify PoS systems. We will continue sharing content about this. Stay tuned for updates!</p><h2 id="how-to-participate">How to Participate?</h2><p>If you're interested in participating in the launch of Babylon, we recommend two main directions for involvement:</p><ol><li><strong>Testnet Participation:</strong> Engage with the Babylon testnet by staking your SignetBTC directly on Babylon's <a href="https://btcstaking.babylonchain.io/?ref=p2p.org"><u>official website</u></a>. This allows you to familiarize yourself with the platform's features and functionalities without risking real assets.</li><li><strong>Support for Large Bitcoin Holders: </strong>If you hold significant Bitcoin, don't hesitate to contact our team. We can provide tailored validator solutions that will be optimal for you when the mainnet launches.</li></ol><p>The Babylon Testnet-4 has already been launched, and the mainnet launch is anticipated by the end of the first half of the year. This new testnet focuses on the security of staked Bitcoins by testing user interactions with the BTC Signet test network. The Babylon team is actively monitoring updates and feedback from the community to ensure the network's robustness and security before the mainnet launch. </p><h1 id="about-p2p-validator"><strong>About P2P Validator</strong></h1><p><a href="https://p2p.org/?ref=p2p.org">P2P Validator</a>&nbsp;is a world-leading non-custodial staking provider, securing over $7 billion from over 10,000 delegators/nominators across 40+ high-class networks. We have actively participated in the Babylon Chain activities since the beginning.</p><hr><p>Do not hesitate to ask questions in our&nbsp;<a href="https://t.me/P2Pstaking?ref=p2p.org">Telegram</a>&nbsp;chat or contact Alik via&nbsp;<a href="mailto:[email protected]" rel="noreferrer">[email protected]</a>. We are always open to communication.</p><hr><p><strong>Web:</strong>&nbsp;<a href="https://p2p.org/?ref=p2p.org">https://p2p.org</a></p><p><strong>Twitter:</strong>&nbsp;<a href="https://twitter.com/p2pvalidator?ref=p2p.org">@p2pvalidator</a></p><p><strong>Telegram:</strong>&nbsp;<a href="https://t.me/P2Pstaking?ref=p2p.org">https://t.me/P2Pstaking</a></p>

<p>Restaking in presents unique opportunities and challenges. <strong>This article explores the risks involved in restaking, such as smart contract vulnerabilities, operator issues, and protocol flaws, and offers practical strategies to mitigate these risks. </strong>Whether you're an experienced investor or a newcomer, this guide provides essential insights for secure and profitable restaking. Equip yourself with the knowledge needed to navigate this complex landscape confidently.</p><h3 id="contents">Contents</h3><ul><li>Intro</li><li>Map of risks<ul><li>EL smart contract risks</li><li>Operator risks</li><li>Protocol risks</li><li>Operational risks</li></ul></li><li>Risk mitigation</li></ul><h2 id="intro">Intro</h2><p>In April,&nbsp;<a href="https://www.eigenlayer.xyz/?ref=p2p.org">EigenLayer</a>&nbsp;restaking entered Stage 3 on the mainnet with an assortment of Actively Validated Services (AVS) becoming live and ready to be delegated. This marked the beginning of active restaking portfolio construction &amp; management and refreshed the importance of restaking risk evaluation.<br><br>We at&nbsp;<a href="http://p2p.org/?ref=p2p.org">P2P.org</a>&nbsp;take risk considerations carefully and are delighted to share our thoughts. This blog post aims to inform restakers of risks and risk mitigation measures. We will outline:</p><ul><li>the importance of building a risk framework</li><li>risks that may exist in restaking</li><li>risk mitigation strategies and why Operator choice is essential</li><li>challenges in risk evaluation<br></li></ul><blockquote><em>We exclude LRTs and risks specific to liquid restaking. However, a reader&nbsp;can use the provided information&nbsp;to explore the risks of underlying LRT restaking portfolios.</em></blockquote><p>We assume that a reader has an essential awareness of Ethereum, delegated proof of stake (DPoS) staking, and Eigenlayer restaking. For those who are not sure about that, we recommend checking out these resources:</p><ul><li><a href="https://ethereum.org/en/what-is-ethereum/?ref=p2p.org">What is Ethereum</a></li><li><a href="https://www.ledger.com/academy/what-is-delegated-proof-of-stake-dpos?ref=p2p.org">What is Delegated PoS</a></li><li><a href="https://docs.eigenlayer.xyz/eigenlayer/overview/?ref=p2p.org">Intro to Eigenlayer</a></li><li><a href="https://www.blog.eigenlayer.xyz/ycie/?ref=p2p.org">You Could’ve Invented Eigenlayer</a><br></li></ul><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2024/05/image-7.png" class="kg-image" alt loading="lazy" width="1602" height="1120" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/image-7.png 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/image-7.png 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/image-7.png 1600w, https://p2p.org/economy/content/images/2024/05/image-7.png 1602w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">*</span><i><em class="italic" style="white-space: pre-wrap;">Mostly for illustrative purposes.</em></i></figcaption></figure><h3 id="background">Background</h3><p>In classic DPoS (<em>Delegated Proof of Stake</em>), a token holder who wants to stake chooses a staking service provider (SSP) who will operate nodes and perform protocol duties on the staker's behalf for some fee. This form of staker-SSP relationship is called a delegation. Delegations provide economic security to the protocol, require locking the funds, and are incentivized by reward earnings. A delegator is supposed to do their research on validators and decide who is the best in terms of yield &amp; credibility.</p><p>Conceptually, the restaking process is similar to mere staking but introduces an additional layer of complexity. In addition to choosing an Operator, a delegator must now consider a set of protocols (AVSs).</p><p>We assume a case when a delegator has already settled with Ethereum - they run nodes themselves or stake via Ethereum staking service provider (SSP) or liquid staking protocol (LSP) and has yet to opt in restaking offered by Eigenlayer.</p><p>In Eigenlayer, a delegator (also referred to as a restaker) must choose a Strategy. The Strategy comprises an Operator and the set of AVSs supported by this Operator.</p><p>Operators are obliged to perform duties prescribed by AVS protocols. If they don't, they might be penalized, and the penalty is usually either slashing (burning a fraction of a stake) or jailing (de-registering, banning from operations).</p><div class="kg-card kg-callout-card kg-callout-card-grey"><div class="kg-callout-emoji">💡</div><div class="kg-callout-text">A list of some slashing &amp; jailing conditions that AVSs can have:<br><br>- Misattestation of block/data<br>- Doublesigning<br>- Operational<br>- Downtime<br>- Laziness (imitation of proper work)<br>- Wrong computation output</div></div><p><br>Slashing events may occur due to Operator misbehavior, failure, or protocol flaws, which are sometimes induced by specific market conditions (e.g., high load due to market volatility) and massive technical collapses. Even though slashing is not currently enabled in Eigenlayer, it eventually will be, and it's about the right time to start thinking about it if you didn't before.</p><p>Since a restaking choice is narrowed down to choosing a single Operator (per the same capital), the choice of the Operator is critical, as in case of severe operator-related issues, there is a chance of being penalized on all AVS simultaneously—risks become correlated to some extent. The infrastructure automation, monitoring, and support of AVSs will likely be handled by dedicated DevOps engineers, who may share a common architecture and resources.</p><p>For example, the whole cluster of different AVS nodes may go down because they were hosted on the same cloud provider, which went offline in disaster cases.</p><p><strong>Besides slashing risks, one could also think of Eigenlayer smart contract risks and operational risks.</strong></p><p>All these risks can be loosely classified by fundamental sources:</p><ul><li>Eigenlayer Smart contract risk</li><li>Strategy risk<ul><li>Operator (validator) risk</li><li>Protocol (AVS) risk</li><li>Operational (delegators operations) risk</li></ul></li></ul><p>Let’s look into these categories in the next section.</p><h1 id="map-of-risks"><br>Map of risks</h1><p></p><h2 id="eigenlayer-smart-contract-risks">EigenLayer Smart Contract risks</h2><p>EigenLayer consists of a complex set of smart contracts. Here are the most important ones:</p><ul><li><strong>EigenPod</strong>&nbsp;- verifies ETH Beacon deposits via Beacon chain oracle</li><li><strong>EigenPodManager</strong>&nbsp;- deploys pods, keeps track of pod shares (podOwnerShares)</li><li><strong>DelegationManager</strong>&nbsp;- registers operators</li><li><strong>StrategyManager</strong>&nbsp;- the primary entry- and exit point for funds into and out of EigenLayer</li><li><strong>Slasher</strong>&nbsp;- is attached to StrategyManager but does nothing at the moment</li></ul><p>Although we won't delve into their details in this chapter (how they function is well described in this <a href="https://www.blog.eigenlayer.xyz/ycie/?ref=p2p.org" rel="noreferrer">article</a>), it still merits mentioning mechanics related to slashing and draining risks.</p><p>EigenLayer restakes&nbsp;<strong>shares</strong>, not the underlying assets (ETH, LSTs) directly. Shares only exist in EigenLayer contracts for accounting and are subject to slashing. They are not tokens and are not transferrable. That highlights the possible foundation for developing slashing cancelation mechanisms. In the previous version of Eigenlayer, the slashing of real assets could happen via asset locks during the withdrawal process.</p><p>The most significant risk in EigenLayer in the existing version (and potentially in the following versions) is the <a href="https://docs.eigenlayer.xyz/eigenlayer/security/multisig-governance?ref=p2p.org" rel="noreferrer">upgrade governance</a>. Nine out of 13 community EOAs (P2P.org is one of the signers) can ruin the system if they coordinate or get hacked. Any malware code can be pushed to the mainnet smart contracts and drain the funds through them.</p><p>We will continue tracking the development and determine if additional jeopardizing features appear with new version releases.</p><h2 id="operators-risks">Operators risks</h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/image-9.png" class="kg-image" alt loading="lazy" width="2000" height="885" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/image-9.png 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/image-9.png 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/image-9.png 1600w, https://p2p.org/economy/content/images/2024/05/image-9.png 2000w" sizes="(min-width: 720px) 720px"></figure><h3 id="hardware">Hardware</h3><p>Under hardware, we understand the physical properties of infrastructure—location, CPU, bandwidth, power stability, etc. Operators can use various cloud providers and configure nodes that don't fully meet the requirements or face capacity problems over time. It won’t be clear until the protocol issues a penalty, and then it might be too late for a delegator as they lose funds.</p><p>Hardware issues usually lead to higher downtime risks (meaning losing rewards), but sometimes also to slashing.</p><blockquote>As an abstract example, bad connectivity may lead to delays in the perceived state of the network; therefore, a node will attest to wrong data that does not fit the consensus.</blockquote><h3 id="software">Software</h3><p>Software may include nodes’ clients, various plugins, and automatization and management solutions deployed by an Operator. Software problems can come from AVS developers and an Operator; sometimes, the node client might come from external developers, and an Operator may choose to use it. Bad, unaudited code and the absence of timely client updates may cause unexpected operational behavior and lead to downtime and slashing.</p><h3 id="hardware-software-setup">Hardware + Software = Setup</h3><p>Technical issues related to hardware and software are not perfectly independent. Problems with one may reveal issues with another.</p><blockquote>Consider an Operator who runs two nodes. The second one is a backup node in case the first one goes down. It is managed automatically. Imagine if the system wrongly decides that there’s a need to turn on the secondary node while the main one operates, maybe because of losing the connection to the primary node or for other reasons. This will then lead to double signing and, hence, slashing.</blockquote><p>In this example, a minor hardware (connectivity) problem highlighted suboptimal software configuration, which resulted in a catastrophe. Thus, it is also reasonable to evaluate hardware and software as a whole system from the design perspective.</p><h3 id="security-breaches">Security breaches</h3><p>Poor security procedures, such as weak passwords, access management, and key management, put node operations at risk. This won’t necessarily lead to the total loss of the delegation funds unless the delegation is made in a custodial way. Still, it may expose a protocol to dishonesty/griefing attack vectors, resulting in slashing.</p><h3 id="bad-actors-dishonesty">Bad actors &amp; dishonesty</h3><p>Generally, dishonesty is driven by two major factors: profit extraction and griefing. Dishonesty is intentional. For this to happen, there should be a condition satisfied:&nbsp;</p><blockquote><em>Value from the attack &gt; Cost of the attack</em></blockquote><p>The cost of the attack can be decomposed into a) financial cost and b) reputation cost.</p><p>Reputation cost is hard to denote in exact numbers but easy to grasp. If an Operator is caught doing dishonest actions, eventually, they will lose credibility and, consequently, delegations and future earnings. AVS operations do not limit the reputation damage and will spread across all Operator businesses. One can roughly say that reputation cost is the net present value of all future profits that an Operator can earn. The higher the TVL (as a proxy of profit), the higher the chance that the Operator will be honest. It merits mentioning that it is not essential that Operators are the only participants in the attack. They can be just members of the attack group and, in the end, bribed (or even hacked) by another party.</p><p>Financial costs will vary across AVSs depending on the protocol design. An abstract example would be network congestion or spamming to disable other Operators to take over a protocol for a short period. This may include fees, infrastructure, bribes to other Operators, etc. To determine the cost, one should inspect all possible attack vectors on AVSs, which is sometimes difficult.</p><p>The value from the attack will also depend on the AVS type and ecosystem around it — value locked, trading activity, etc.</p><h2 id="protocol-risks">Protocol risks</h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/image-10.png" class="kg-image" alt loading="lazy" width="2000" height="885" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/image-10.png 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/image-10.png 1000w, https://p2p.org/economy/content/images/size/w1600/2024/05/image-10.png 1600w, https://p2p.org/economy/content/images/2024/05/image-10.png 2000w" sizes="(min-width: 720px) 720px"></figure><h3 id="protocol-logic">Protocol logic</h3><p>Protocol logic resembles the set of rules, policies, and processes that govern the operations and, in particular, ensure that Operators are properly incentivized to perform duties well. Rules include consensus, slashing conditions, reward schemes, etc. Improper protocol logic design may cause unintended violations of slashing conditions.</p><blockquote>Imagine an oracle that delivers an aggregated exchange rate for some asset pair. Let it be a median price. Oracles gather data from external providers like Coingecko or CMC, each has their own version of truth. <br><br>Let this oracle protocol pursue accuracy of the data, it should be gathered timely. So if some Operator posts the price that diverges from the resulting median too much, then they get slashed. For example, this might happen when an operator is lagging and delivers an “old price”, which is inaccurate, or the Operator might want to influence the result value to attack DeFi protocols. These are Operator side issues that should be disincentivized. <br><br>But what if there’s a problem with the external source? The Operator performs their duties well but gets slashed anyway because their truth source differs from others. This is exactly the case of bad protocol rules’ design. No bad intention, no bad performance, still slashed.</blockquote><p>The example above may generally be applied to occasions when slashing cannot be organized purely based on on-chain data. However, such slashing conditions can be potentially mediated through $EIGEN token staking. Learn more in <a href="https://p2p.org/economy/how-eigen-works/">our blog post</a>. </p><h3 id="software-vulnerabilities">Software vulnerabilities</h3><p>There is a chance of AVS having code flaws, which may then expose it to security vulnerabilities and operations breaks. The consequences can vary depending on the attack goal, making operators attest to malicious state transition (i.e., enabling double spending), Oracle price misreporting, etc.</p><h3 id="infrastructure-landscape">Infrastructure Landscape</h3><p>Even if everything is good with Operators and AVS, the infrastructure landscape itself can still present slashing risks. For instance, imagine something like the supermajority of Geth clients in Ethereum*. This particular case is a protocol-level risk, but it comes from the existing infrastructure landscape and sometimes can be managed by an Operator.</p><div class="kg-card kg-callout-card kg-callout-card-blue"><div class="kg-callout-emoji">❗</div><div class="kg-callout-text">*For a bigger picture, learn more about Ethereum supermajority risk here:&nbsp;<a href="https://supermajority.info/?ref=p2p.org">https://supermajority.info</a></div></div><h3 id="centralization-led-risks"><br>Centralization-led Risks</h3><p>Depending on the protocol design, sometimes large stake centralization poses risks for the whole network. If operators possessing large amounts of stake go offline or experience bugs, they can affect the whole network and cause mass slashing events. The probability of such a risk is higher when some Operator has a critical amount of delegations requiring just this Operator to fail to initiate the issue.</p><h3 id="staking-derivatives-contagion">Staking Derivatives Contagion</h3><p>LRTs appeared to be an important market player and have attracted large amounts of ETH since the launch of Eigenlayer. Some AVSs softly deal with them to ensure the initial amounts of security delivered. At the same time, the limit on LST restaking has been removed recently; therefore, an additional inflow of LST restaking can be expected.</p><p>Therefore, there can be situations when liquid restaking and staking protocols provide most of the AVS stake.</p><p>In normal market conditions, it doesn't pose any significant risk, but in the case of LRT and LST depegging, the security of AVS might evaporate, exposing it to attacks and instability.</p><h2 id="operational-risks">Operational Risks</h2><h3 id="reward-management-risks">Reward Management risks</h3><p>Security provisions are supposed to be rewarded, and restaking is no exception. There will be a large variety of AVSs; some may pay in the native tokens, some may pay out in tokens of integrated protocols (i.e., roll-ups), and tokens can even be issued in the non-Ethereum ecosystem (i.e., in Ethos). Once a restaker is rewarded, they must decide what to do with rewards - sell or stake again, if AVS accepts this token for staking, or swap to ETH and (re)stake ETH (or LST). Additional actions can be taken to accomplish that, such as reward withdrawal, bridging, swapping, etc. Apparently, restaking on multiple (imagine 10+ or even 20+) AVS will result in a resource-consuming reward management process.</p><p><strong>From a practical perspective, restakers can encounter the following:</strong></p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2024/05/image-11.png" class="kg-image" alt loading="lazy" width="1430" height="972" srcset="https://p2p.org/economy/content/images/size/w600/2024/05/image-11.png 600w, https://p2p.org/economy/content/images/size/w1000/2024/05/image-11.png 1000w, https://p2p.org/economy/content/images/2024/05/image-11.png 1430w" sizes="(min-width: 720px) 720px"></figure><p><br>In the most basic cases, rewards are paid in ETH and occur at predefined Ethereum addresses. There is no need to make any withdrawals or trade tokens. It's almost the same as Ethereum staking itself.</p><p>In a complicated dual staking case, rewards are paid in the AVS token on the external blockchain. AVS has a dual staking model, and rewards should be claimed. Then, they might be compounded or sold, bridged, and dispersed across different trading venues.</p><p>There can be so many actions and various data to track that <strong>the number of points of failure and reporting nuances is pretty high</strong>. Compared to mere ETH staking, restaking requires additional time and resources in rewards management; otherwise, stakers may <strong>miss rewards, not meet tax liabilities, and fail to realize the yield.</strong></p><p>Regarding reward management procedures, restakers should consider market conditions for reward tokens. In particular, it is important to track the available liquidity on trading venues and choose an optimal execution strategy to preserve yield.</p><h3 id="additional-unbonding-period">Additional unbonding period</h3><p>Eigenlayer restaking increases the duration of ETH withdrawals as there’s the time of undbonding from AVSs. Therefore, additional opportunity costs can arise due to the inability to move ETH.</p><blockquote>Currently, Eigenlayer unbonding period equals 7 days, but the period can change in the future.</blockquote><h3 id="legal-risks">Legal risks</h3><p>A delegator should check whether the AVS and owning the AVS token or even restaking itself doesn’t violate legislation of the country of their residence.</p><p></p><h1 id="risk-mitigation">Risk mitigation</h1><h3 id="protocol-risks-the-devil-is-not-so-terrible-as-he-is-painted"><br>Protocol risks: The&nbsp;devil is not so terrible&nbsp;as he is painted.</h3><p>Mass slashing events caused by improper protocol functioning theoretically do not harm a restaker. Eigenlayer has a special committee that is expected to revert the consequences. Also, the protocols are examined and audited for such possibilities during the onboarding procedures. Therefore, without regulatory complications, a protocol risk is expected to be minimized to reward handling.</p><p>Nevertheless, it’s better to be aware of all kinds of scenarios, even if they can be managed post-factum. The odds are small, but can something go wrong? Keep that in mind while constructing a portfolio and checking for risks we outlined previously.</p><h3 id="choose-a-credible-operator">Choose a credible Operator</h3><p>To minimize Operator risk (which seems to be the largest source of risks so far), delegating to Operators with a solid track record and large TVL, public recognition, or personal assurance is important. Before choosing between different Operators, <strong>it is worth building a checklist</strong> highlighting TVL in other networks, acknowledgment from Eigenlayer and AVSs’ foundations, availability of SOC certificates, and previous cases of dishonest &amp; unprofessional behavior that led to the loss of funds.</p><h3 id="plan-in-advance-how-the-reward-monitoring-and-reporting-will-work">Plan in advance how the reward monitoring and reporting will work</h3><p>As we saw above, the variety of yield extraction paths is huge, so a delegator should carefully examine it and construct business/monitoring/reporting processes themselves or outsource it to a specialized third party. Doing it properly will help maximize yield and avoid unnecessary tax and legal pressure. Data services become crucial in this regard.</p><h3 id="role-of-data-services">Role of data services</h3><p>Besides helping operational functions, data services can be applied to operator and protocol risk evaluation. The qualitative approach determines the surface of possible slashing risks but cannot tell the probabilities of outcomes.</p><p>Practically, almost always, there will be no available data or method to predict slashing risks with verifiable accuracy. Most slashing events have an extremely low probability, making it almost impossible to figure out the exact exposure. Historically, there have been few slashing events in matured networks, all having diverse origins.</p><p>Nevertheless, we still want to have something that might indicate the issue.</p><p>Generally, we expect gathering data about AVS operators’ performance to be possible. It can still be used to rank Operators and spot signs of infrastructure disturbances, which then can be used as a proxy for downtimes &amp; slashing risks. For example, if an Operator frequently (and recently) experiences spikes in attestation miss rates in some abstract protocol, they may face harsher problems in the future unless the problem is fixed. These algorithms and models based on performance data are yet to be developed, and their sensitivity must be fine-tuned.</p><p><strong>About Lambda</strong><br>Historically,&nbsp;<a href="http://p2p.org/?ref=p2p.org">P2P.org</a>&nbsp;extensively uses data services for internal needs (i.e., business analysis &amp; planning) and external reporting (clients &amp; research). Now, we aim to build a new data product to cover new data domains introduced by restaking.</p><figure class="kg-card kg-embed-card"><blockquote class="twitter-tweet"><p lang="en" dir="ltr">We are working on the Lambda data platform with partners <a href="https://twitter.com/DroseraNetwork?ref_src=twsrc%5Etfw&ref=p2p.org">@DroseraNetwork</a> and <a href="https://twitter.com/OpenLayerHQ?ref_src=twsrc%5Etfw&ref=p2p.org">@OpenLayerHQ</a> to bring consensus layer data on-chain.<br><br>This innovation enhances Ethereum's EVM, providing accurate data for <a href="https://twitter.com/eigenlayer?ref_src=twsrc%5Etfw&ref=p2p.org">@eigenlayer</a> ecosystems and making it more developer-friendly.<br><br>Details in the 💬 <a href="https://t.co/BIz4bgRa73?ref=p2p.org">pic.twitter.com/BIz4bgRa73</a></p>— P2P.org (@P2Pvalidator) <a href="https://twitter.com/P2Pvalidator/status/1794032940512665879?ref_src=twsrc%5Etfw&ref=p2p.org">May 24, 2024</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></figure><p></p><p>Lambda is a data product from&nbsp;P2P<a href="http://p2p.org/?ref=p2p.org">.org</a>&nbsp;that originally stems from the staking data API for P2P clients. Lambda will offer pre-built real-time API endpoints for EigenLayer ecosystem builders, including:<br><br>- Operator performance metrics to monitor duties and slashing events for Beacon Chain, AVS, and Cosmos chains.<br>- Rewards and APRs to monitor profits from direct staking for each pair delegator-operator. It also includes rewards per re-staked ETH to measure the profit of re-staking.<br>- DeFi (DEX, Lend-borrow) reserves to manage liquidity for LRT.<br><br>The platform will also provide a customization engine for real-time APIs, allowing builders to integrate new endpoints without additional latency or loss in data quality. The Lambda team works with several AVS projects to explore integration methods. <br><br>Stay tuned for updates!</p><h3 id="conclusion">Conclusion</h3><p>In this blog post, we discussed risks that restakers might face when they choose the strategy and shared high-level recommendations around risk mitigation. There are still many open questions: slashing conditions and amounts are not stated for most of the AVSs, and Eigenlayer slashing logic has not been released yet. The restaking market is young, and protocols are not battle-tested. No slashing phase will give some time to work through unknowns.</p><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a>&nbsp;aims to actively contribute to risk evaluation discussion and continue working on risk assessment methodologies from qualitative and quantitative perspectives. As an operator in Ethereum and AVSs, we aim to navigate our clients and partners in the Eigenlayer ecosystem.</p><div class="kg-card kg-button-card kg-align-center"><a href="https://eth.p2p.org/auth?ref=p2p.org" class="kg-btn kg-btn-accent">Stake and restake your ETH with us!</a></div><h1 id="about-p2p-validator"><br><strong>About P2P Validator</strong></h1><p><a href="https://p2p.org/?ref=p2p.org">P2P Validator</a>&nbsp;is a world-leading non-custodial staking provider, securing over $7 billion from over 10,000 delegators/nominators across 40+ high-class networks.</p><p>Do not hesitate to ask questions in our&nbsp;<a href="https://t.me/P2Pstaking?ref=p2p.org">Telegram</a>&nbsp;chat or contact our team directly on X or LinkedIn. We are always open to communication.</p><hr><p><strong>Web:</strong>&nbsp;<a href="https://p2p.org/?ref=p2p.org">https://p2p.org</a></p><p><strong>Twitter:</strong>&nbsp;<a href="https://twitter.com/p2pvalidator?ref=p2p.org">@p2pvalidator</a></p><p><strong>Telegram:</strong>&nbsp;<a href="https://t.me/P2Pstaking?ref=p2p.org">https://t.me/P2Pstaking</a></p>