The re-staking narrative has been strong at play in crypto, and more recently we have seen several protocols emerge providing restaked security from blue-chip chains (i.e Bitcoin and Ethereum) to cosmos app-chains. All of them are broken - and very broken. I feel a duty to call them out in hopes that they will adjust their implementations to align themselves with decentralization + security values. 

The concept of providing restaked security is not the issue, in fact I’m a big fan of this idea. The issue is the design of these protocols that is currently being implemented (i.e Babylon for BTC and Ethos for ETH).

First let’s take a look at how these protocols work. On the base chain - the chain with the asset being used for security - there exists a staking/slashing contract (note for Babylon this structure is different but can be thought of as a contract for the purpose of this article). This contract has two core purposes 1) lock up capital to be used for security and 2) verify slashing requests that will burn said locked up assets of a malicious validator.  Then these protocols create their own-chain in which the validators of this chain run light clients for the base chain to acknowledge new validators staking on the contract. When validators lock up stake on the base chain contract they signify which chain they want to become validators on. This both allows them to receive token rewards issued by the chain they specify, and opens them up for slashing by that chain. Now that the re-staking provider’s chain acknowledges a new validator locking up stake, they forward this information to the chain specified by the validator via IBC. Specifically, most of these protocols run their chain as a cosmos app-chain and use the Interchain Security (ICS) standard for relaying this restaked security (ICS is the same standard the cosmos hub uses). These IBC packets forwarded to the target chain by the validator come in the form of Validator Set Change (VSC) packets. This packet relays the number that a validator’s voting power should be changed to as a result of their stake on the base chain. Then the chain receiving the security will update its validator set and respective power after verifying the IBC packet came from the right chain (i.e babylon or ethos chain). Now the validator can participate in consensus and earn token rewards for doing so. 

Ok that’s great so then what’s the issue? I’ll answer this question with another - wtf is the point of the chain these restaking protocols built? This chain is nothing more than a middleman, and if removed will 1) increase the security properties and 2) increase the liveness properties of the chain receiving the security.

Including this middleman chain to relay staking information to different chains receiving the security means the security being received isn’t how much ETH or BTC is staked on the respective base-chains but rather the market cap of the middleman chain. When an IBC connection is established - which is necessary for the middleman chain to send VSC packets to the consumer chain - the chain now will receive and fully trust packets coming from the middleman (in ICS the middleman chain I’m referring to is called the provider chain). Therefore you can imagine an attack where > ⅓ of the middleman’s chain token is bought and this chain forwards malicious VSC packets to the consumer chains. 

Now what’s really puzzling to me is the design works so well without this middleman chain. You can remove the middleman chain and have the consumer chain validators run light clients for the base chain so they can recognize validator updates themselves. With such a simple change now you have the full security and liveness properties of the base chain that you hope you would get from securing your chain with re-staked assets. 

Sure this adds complexity and (maybe) hardware requirements to the validator set of the consumer chain because they have to additionally run a light client, but this is a more than reasonable trade-off to make for the additional security the chain receives.

If you were to ask me why these protocols are building a middleman chain, the only response I can come up with is so they have a venue to create a token and pump their bags. It’s sad to see the sacrifice of decentralization + security in return for a group of people to profit from a piece of software, and I hope this will change in the near future.

If I have to create a public good that will provide true re-staked security to these consumer chains, I will. So if you are one of these protocols - find another way to monetize or public goods will eat your lunch. 

The re-staking narrative has been strong at play in crypto, and more recently we have seen several protocols emerge providing restaked security from blue-chip chains (i.e Bitcoin and Ethereum) to cosmos app-chains. All of them are broken - and very broken. I feel a duty to call them out in hopes that they will adjust their implementations to align themselves with decentralization + security values. 

The concept of providing restaked security is not the issue, in fact I’m a big fan of this idea. The issue is the design of these protocols that is currently being implemented (i.e Babylon for BTC and Ethos for ETH).

First let’s take a look at how these protocols work. On the base chain - the chain with the asset being used for security - there exists a staking/slashing contract (note for Babylon this structure is different but can be thought of as a contract for the purpose of this article). This contract has two core purposes 1) lock up capital to be used for security and 2) verify slashing requests that will burn said locked up assets of a malicious validator.  Then these protocols create their own-chain in which the validators of this chain run light clients for the base chain to acknowledge new validators staking on the contract. When validators lock up stake on the base chain contract they signify which chain they want to become validators on. This both allows them to receive token rewards issued by the chain they specify, and opens them up for slashing by that chain. Now that the re-staking provider’s chain acknowledges a new validator locking up stake, they forward this information to the chain specified by the validator via IBC. Specifically, most of these protocols run their chain as a cosmos app-chain and use the Interchain Security (ICS) standard for relaying this restaked security (ICS is the same standard the cosmos hub uses). These IBC packets forwarded to the target chain by the validator come in the form of Validator Set Change (VSC) packets. This packet relays the number that a validator’s voting power should be changed to as a result of their stake on the base chain. Then the chain receiving the security will update its validator set and respective power after verifying the IBC packet came from the right chain (i.e babylon or ethos chain). Now the validator can participate in consensus and earn token rewards for doing so. 

Ok that’s great so then what’s the issue? I’ll answer this question with another - wtf is the point of the chain these restaking protocols built? This chain is nothing more than a middleman, and if removed will 1) increase the security properties and 2) increase the liveness properties of the chain receiving the security.

Including this middleman chain to relay staking information to different chains receiving the security means the security being received isn’t how much ETH or BTC is staked on the respective base-chains but rather the market cap of the middleman chain. When an IBC connection is established - which is necessary for the middleman chain to send VSC packets to the consumer chain - the chain now will receive and fully trust packets coming from the middleman (in ICS the middleman chain I’m referring to is called the provider chain). Therefore you can imagine an attack where > ⅓ of the middleman’s chain token is bought and this chain forwards malicious VSC packets to the consumer chains. 

Now what’s really puzzling to me is the design works so well without this middleman chain. You can remove the middleman chain and have the consumer chain validators run light clients for the base chain so they can recognize validator updates themselves. With such a simple change now you have the full security and liveness properties of the base chain that you hope you would get from securing your chain with re-staked assets. 

Sure this adds complexity and (maybe) hardware requirements to the validator set of the consumer chain because they have to additionally run a light client, but this is a more than reasonable trade-off to make for the additional security the chain receives.

If you were to ask me why these protocols are building a middleman chain, the only response I can come up with is so they have a venue to create a token and pump their bags. It’s sad to see the sacrifice of decentralization + security in return for a group of people to profit from a piece of software, and I hope this will change in the near future.

If I have to create a public good that will provide true re-staked security to these consumer chains, I will. So if you are one of these protocols - find another way to monetize or public goods will eat your lunch.