The Risks of Restaking FAQ

Restaking extends the security of a layer one blockchain (Etheruem) and makes it reusable for other protocols and networks. This extension of Ethereum security allows builders to create new and bespoke protocols while solving many issues of current designs.

Key Takeaways

• Different restaking protocols present different risks to restakers.
• Restaking can be done without putting the validator’s principle at risk using Native Delegation with Restaking Cloud.
• Restaking Cloud eliminates many of the perceived risks associated with restaking.

Restaking Protocol Deisgn

When determining the risks for restakers, it is important to understand that there are different methods to extend Ethereum’s security. Let’s examine the two ways to make native staked ETH available for restaking. LSTs/LRTs are an extension of staked ETH, so we will focus on validators when assessing risks.

Withdrawal Credential Restaking (Native Restaking)

This method has the node operator point their withdrawal credential to a smart contract controlled by the restaking protocol. Slashing is then recorded as a lien against the validator. Upon validator withdrawal, any debts owed by the validator are collected against the ETH balance and the remainder is returned to the validator owner.

Restaking K2 Protocol (Native Delegation)

Node Operators run additional software on their node called MEV Plus. They then delegate their ETH at stake to the restaking pool. The restaking pool manages all payouts and slashings from middleware without putting the validator principle at risk.

For the rest of this article, we will focus on Restaking as found in Restaking Cloud K2 protocol.

The Ethereum Execution Layer — The First Restaking Protocol

To understand the risks of Restaking Cloud, it is important to understand how the consensus layer and execution layer relate. There is no ETH staked on the execution layer, yet it derives its security from the consensus layer’s staked ETH. The execution layer can not directly influence or slash the consensus layer, but rather its state.

When looking at the relationship between the consensus layer and execution layer in this way, you will realize that the execution layer is the first restaked application utilizing staked ETH economic security. Now, how do we expand the Ethereum infinite garden and give access globally?

Restaker Risks In Restaking Cloud

Below we will assess the risks at multiple layers for those using Native Delegation. Native Delegation syncs the consensus layer’s active stake weight of an ETH validator into Restaking Cloud’s K2 smart contract. Native Delegation uses Proof of Neutrality’s on-chain validator registry and is compatible with all clients and infrastructure including solo stakers, DVT, LST node operators, Eigenlayer validators, and more.

Do I need to give up validator ownership or change my withdrawal credential?

When using Native Delegation with Restaking Cloud, there is no change to withdrawal contract operations. There is no additional withdrawal risk to your staked ETH.

Will my validator’s principle be subject to smart contract risk?

When using Native Delegation, the node operator does not give any assets or permissions to smart contracts. There is no additional smart contract risk to your staked ETH principle.

I need to run MEV Plus for Native Delegation, is this riskier than MEVBoost?

MEV Plus is an additional software that runs on the validator. It can be turned on or off and allows for modules to be plugged into it. The risk depends on what modules the node operator gives permissions to. An easy way to think about it is that MEVBoost gives access to MEV revenue, whereas MEV Plus gives access to restaking yield.

Do I need to switch clients or change my infrastructure to find compatibility with Restaking Cloud?

MEV Plus and Native Delegation are compatible with all clients and infra. This includes MEVBoost, DVT, execution & consensus clients, Dappnode, splitters, Eigenpods, etc.

Restaking Cloud isn’t holding my withdrawal credential, how are slashings accounted for?

Slashing is the verifying of information. In Restaking Cloud’s K2 protocol, this is a paid service by middleware/networks. All slashing and payouts are algorithmically handled at the K2 protocol level. This means that the ETH at risk for node operators are their unclaimed rewards that remain in the pool. Restaking Cloud’s K2 has been formally verified; The risk engine makes sure that all networks have sufficient ETH to remain secured, all slashings can be honored, and the restakers’ principle remains protected. For a deep dive on K2, watch the walkthrough.

https://youtu.be/2847ofFpBiM?si=fNg6i_KxMBaAzHdP

Do I need to update my fee recipient? I’m part of a smoothing pool.

Restaking Cloud asks you to set your own K2 fee recipient as any Ethereum wallet address or smart contract. This is a separate fee recipient from your validator’s fee recipient you use for receiving block fees and tips; You can use the same address if you’d like. The K2 fee recipient address receives yield from K2 and other Restaking Cloud protocols.

Are the rewards that I earn at risk of being slashed?

Those using Native Delegation are part of the restaking pool. Any unclaimed rewards are subject to slashing by Restaking Cloud. Minimum yield is 0%. Max slashing for node operators is 100% of unclaimed yield if there is a correlated slashing event.

It sounds like 100% of validators can join, doesn’t that cause a centralization risk for Ethereum?

When it comes to Native Delegation, neither the protocol nor its smart contracts have any claim on an underlying validator or its ETH. This keeps Ethereum decentralized as each party retains full ownership of their assets. As far as a client, Native Delegation is similar to MEVBoost.

What kind of risk does this put on the consensus layer of Ethereum?

Restaking Cloud has no direct influence on the consensus layer or its assets.

Ok, but who has custody of assets within Restaking Cloud?

Restaking Cloud is a smart contract protocol without a single entity having custody.

Is there an Oracle risk?

Restaking Cloud does not use any oracles.

What risk is there of a multisig or veto stopping my rewards?

There are no committees, multisigs, or vetos that can stop a rewards payout.

Is Restaking Cloud compatible with current staking protocols?

Yes. In some cases, the protocol may need to determine how they will receive and distribute rewards for stakeholders. Not a bad problem to have — achieving an equitable distribution at social level.

Have a Question?

If you have any other questions or concerns related to becoming a node operator or restaker within Restaking Cloud, feel free to reach out to us on Discord.

Follow Restaking Cloud:

Website |+| Twitter |+| Youtube

DISCLAIMER: The text above is just a description of how Restaking Cloud works in theory. Any figures mentioned serve only as an illustration. Engaging in any blockchain activities with or without the necessary skills or experience can result in a loss of funds. This is a very experimental tool, so please treat it as such.

Before participating, please read the disclaimer here.