---
# System prepended metadata

title: Staking Derivatives Lead To Capture

---

# Staking Derivatives Lead To Capture

With moderate confidence there is a dangerous path in PoS evolution:

1. Protocol launches or transitions to PoS.
2. Staking derivatives inevitably arise.
3. Derivates exhibit winner-takes-all dynamics.
4. Block production is thus centralized.

The inevitability of each step is uncertain, but I am wary that the dynamics/incentives push a protocol down this path.

I was already concerned about this, but this braindump crystalized after hearing Lido skeptics [Ryan Berckmans & Alex Bergeron on Unchained Podcast](https://unchainedpodcast.com/post-merge-if-lido-becomes-dominant-what-does-that-mean-for-ethereum-ep-372/) where the path laid out above may be happening right now on Ethereum.

Digging into each step:

## Step 1. PoS Launch

When a PoS chain launches, there's some distribution of tokens, and some portion of those are bonded for stake.

## Step 2. Staking Derivatives Inevitably Arise

Users want staking derivatives, because if they have two options (a) with no derivative, and (b) which provides a derivative, the latter gives them more optionality for the same starting tokens.

### In-Band Derivatives

First off, the staking protocol itself might support derivatives at the base layer. In this case, derivatives exist, so proceed to step 3.

(We'll return to important differences between in-band vs out-of-band in the mitigations section below.)

### Out-of-Band Derivatives

If the protocol itself doesn't offer derivatives, then third parties can, and given their competitive pressure, the successful ones will.

#### Centralized Derivative Issuers

A quick'n'dirty third party derivative works like this:

Some custodian, "Alice", tells you if you stake with them, not only do you earn a return of native `TOK`, but you also also immediately receive the same number of `aliceTOK`. It doesn't even matter if `aliceTOK` lives on the staking chain. All that matters is that `aliceTOK` has some liquidity and can be used somewhere. It's quite likely one of the first places it could be used is a `TOK / aliceTOK` trading pair.

- It seems easiest for centralized exchanges to launch this, because they have the exchange for a trading pair and it encourages customer deposits. They wouldn't even need a blockchain for `aliceTOK`: it could just be an entry in their db.

What happens next? Custodian number 2 follows suit to be competitive.

Where do users stake?
- If they're self-custody idealists, maybe they shy away from these custodians.
    - For this argument, it doesn't matter if the protocol has in-band staking delegation or if self-custody users must run their own block-producer infra. In the latter case, the effect is even worse since the barrier to participate is that much higher.
- Otherwise, they might just compare the alternatives on financial terms:
    - The custodians may offer worse yield, since they presumably earn revenue by taking a fee.
    - Derivatives may counteract that difference. In fact, an exchange might not take any staking fee using a growth strategy, for example hoping to earn trading fees on `TOK/aliceTOK` trades.
    - The more options for earning a return on `aliceTOK` the more appealing their offer, so they'll probably want to integrate `aliceTOK` into as many products as possible, likely Defi on multiple chains sooner or later.

#### Upper Layer Protocol Derivatives

So the centralized derivatives seem likely. Meanwhile, decentralized protocols layered above the staking protocol may be likely to arise.

This follows the same playbook as the centralized derivative issuers, but now just decentralize those functions. This seems to successful because some of the decentralization benefits (example: no KYC barrier) allow growth to scale competitively.

Lido atop Ethereum is the prime example of this category.

### Step 2 Conclusion

The competitive pressure for customer staking tokens pushes market participants to offer derivatives.

The potential for both centralized derivative issuers and more decentralized derivative protocols layered atop the base staking protocol mean that the protocol itself cannot prevent derivatives, even if it does not provide them in-band.

Thus, derivatives are inevitable.

## Step 3. Winner-Take-All Dynamics

Again, a new user shows up with `TOK` and wants to earn a return on them passively. 

(Tangent: there can be other ways to earn returns besides staking and that can in turn impact staking security! But that's a whole different topic. For now, assume the only way to earn return on `TOK` is via staking.)

So, they select among all the staking options. The options with the most liquid derivative is likely to be the most compelling: more liquidity means a better price if they want to sell it, but moreso it implies the derivative will be useful in more places: trading, Defi, yield generation, etc…

Even more concerning, derivatives allow "leveraging up": deposit `TOK`, receive `aliceTOK`, sell it for more `TOK`, deposit the new `TOK`. At the base layer of `TOK` this allows a person who leverages to "pull" more `TOK` into the Alice issuer than their starting capital would otherwise allow.

This means there's a dynamic for incoming `TOK` tokens to stake with the offering that has the most liquid derivative. More `TOK` staked with that system also means more of the derivative, and thus it gains even more liquidity in a feedback loop.

This sure seems like a winner-take-all dynamic.

## Step 4. Capture

Now a single system or entity controls most of block production via PoS consensus.

This entity is likely to have incentive alignment with many but not all of the underlying `TOK` holders.

Via this support of most `TOK` combined with control of significant block production, it exerts significant control over the protocol.

# Mitigation

So if we anticipate this development, what can or should we do?

First, we should keep in mind the original goals of the base protocol. For Zcash, those include permissionless, censorship resistant, financial sovereignty.

If the path is inevitable, then we want to ensure the resulting system which "captures" block production meets those same goals as the base chain.

I see three options:

- Avoid PoS altogether. (It's not yet clear to me if PoW or any other consensus system won't follow a similar path long term, though!)
- Improve permissionless social coordination so that users can revolt and "fork out" a capturing entity. (I don't discuss this more in this post, but it's definitely worth digging into more.)
- Design the protocol to embrace this path and itself become the ultimate self-capturing entity.

Let's dig into the third option, which I call the "embrace-and-self-capture" strategy.

## Embracing Derivatives

Embracing derivatives would need to influence each step towards a goal of "self-capture":

### Step 1. Embrace PoS

This "embrace-and-self-capture" notion assumes the protocol is PoS or transitioning to PoS in the first place.

While the path laid out above shows the risks, it doesn't expound on benefits. A healthy derivatives market enables more participation in staking, which spreads block rewards to a wider audience, so as long as those risks are addressed, a transition to PoS may be better than alternative consensus mechanisms in terms of distributing rewards more broadly.

### Step 2. Embrace Derivative Inevitability

Since we are taking the embrace-then-self-capture strategy, the next step is to ensure the base protocol supports derivatives in-band. This has a few effects:

- Third parties have less of a head start by shipping derivatives first, because any block producer does it automatically.
- Since derivative support comes out-of-the-box, there's less specialized/in-house knowledge to compete in the derivative landscape.
- Perhaps most importantly: if derivatives are built into the protocol, then wallets can support the UX around derivatives across the board, which further levels the playing field across different derivative offerings. By contrast, if derivatives are not in-protocol, third parties can gain an upper hand by integrating their derivative (only) into more wallets and services first with a slick UX.

### Step 3. Embrace Derivative Liquidity

This one currently has me somewhat stumped, not having a financial background.

It seems like these widgets would be helpful:

- A base-layer DEX for trading derivatives to prevent capture of liquidity by CEXes or upper layer DEXes. Other exchanges may still try to out-compete the base DEX with "growth strategy incentives" (ie: subsidizing with war chests or other tactics), so this one seems even harder than the already challenging technical aspects of basic DEX design.
    - This doesn't directly address the winner-take-all dynamics, but external exchanges might introduce incentives that might not be best for `TOK` holders in general, so a base-layer DEX could sap the ability for other exchanges to sway incentives as much. 
- Base-layer support for derivatives: derivative tokens should be easy to integrate into any system that the base layer integrates with: wallets, on-chain defi, etc… If a third party service, say an exchange or a point-of-sale product integrates "the chain", it should hopefully be very low effort to support all of the derivatives in that service. This way those derivatives are attractive to users.
    - The purpose of this is to reduce out-of-band advantages that large derivative issuers might develop for their token.

#### Counteracting Winner-Takes-All

But what about the winner-takes-all dynamic? How can we attract new users to smaller derivatives?

Brainstorms:

- Provide a "derivative aggregate token", `superTOK` which users can somehow acquire for any derivative token. The motivation is that if `aliceTOK` has 90% of the liquidity of all derivatives, and `bobTOK` has 1%, a user can deposit either 1 `aliceTOK` *or* 1 `bobTOK` and get 1 highly liquid `superTOK`.
    - This approach smells really fishy to me, because I doubt you can really counteract underlying asset liquidity differences with a new derivative without introducing some weird systemic risks.
- Provide an in-protocol incentive for smaller derivative tokens. Example: maybe the base-layer DEX charges higher fees for bigger pairs, and those fees subsidize exchange of smaller tokens.
    - This approach smells fishy to me because:
        - Other exchanges can compete against the base DEX if the fees are too high.
        - There are probably weird second order effects of built-in subsidies to small players. (What about Sybil attacks to aggregate subsidies or other shenanigans?)
- Embrace the winner tokens: treat them as-good-as base `TOK`.
    - This seems fishy to me because the issuer of `aliceTOK` has an outsized control over block production.
- Allow stake delegators to re-delegate away from a large block producer, and in doing so, somehow reduce the liquidity of their token.
    - This one is fishy to me because the delegators _prefer_ that derivative in the first place. What could they get that's better elsewhere?

So yeah, this step has me stumped.

### Step 4. Embrace-and-Extend Capture

Since Step 3 has me stumped, Step 4 is also a mystery. If we assume a single block producer has the lion's share of `TOK` delegated to them, how can we ensure the protocol resists their efforts to influence it?

# Homework

I wonder if [Osmosis Superfluid Staking](https://medium.com/osmosis-community-updates/osmosis-superfluid-staking-faq-a7b49797cb72) somehow has better dynamics, but I don't understand the implications of it well, yet.