♻️Restaker Risks In Restaking Cloud♻️ If you own or operate any ETH validator, this is for you. A lot of questions have been coming in around what are the risks of Restaking Cloud. Below we will assess the risks at multiple layers for those using Native Delegation. Remember that Native Delegation syncs the consensus layer’s active stake weight of an ETH validator into Restaking Cloud’s K2 smart contract. Native Delegation uses @pon_network's on-chain validator registry and is compatible with all clients and infrastructure including solo stakers, @ObolNetwork , LST node operators, Eigenlayer EigenPods, @dappnode, and more. Do I need to give up validator ownership or change my withdrawal credential? When using Native Delegation, there is no change to the 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, 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, 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. youtu.be/2847ofFpBiM?si=fNg6… 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 yield. This is only possible during a correlated slashing event across the entire Restaking Cloud network. 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, you can think of Native Delegation as 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 within their stakeholder matrix. Not a bad problem to have – achieving a equitable distribution at the social level. If you made it this far and still have questions. Feel free to add them to the comments below.

As we continue through testnet, we're curious about your journey. How is your validator staked that you restaked using Native Delegation?