Liquid Staking Community Call #1 - Jan 15th 2020

[bdflex]

Agenda:

The call will take place at 5pm CET on Jan 15th 2020
https://calendar.google.com/calendar/embed?src=chorus.one_lpdago3de5bpuimvogu9r24kdc@group.calendar.google.com&ctz=Europe/Berlin

Intro (15-25 minutes)

Intro to the working group and timeline
The scope that we have agreed with the ICF
The aspects of the problem that we will investigate
Quick round of intros from call participants - What is your name, what org do you represent, what do you want to get out of participating (limit to one minute each)

Overview of Liquid Staking - Brian Fabian Crain (20 mins)
Overlap of staking and DeFi
Why is liquid staking a great opportunity
Why could be it be a threat
Paint a picture of a custodial version of liquid staking

Community Discussion: identify goals of liquid staking solutions (45 minutes) - moderated by Brian

Desired outcome of the report (framework and evaluation of liquid staking approaches)
What are the goals a liquid staking design should fulfil?

Some themes to explore:

• Fungibility
• Important to ensure liquidity & utility
• Decentralization-friendly
• Non-custodial
• Non-subtractive to network security
• Modularity / flexibility
• Allowing for many competing designs
• Non-subtractive to functionality of governance

Discussion about what to add / importance of different factors

Wrap up & next steps (5 minutes)

Summary of call and outline of next steps

• Capture suggestions for next calls
• Feel free to add an issue to Github repo to start a conversation
• Next call: Jan 30, 5pm CET - topic:

[dlguddus]

i want to add two thoughts

1. extreme flexibility : not stucking in specific design

• solution 1 : programmable staking -> many dPoS does not have VM connected to staking module
• solution 2 : interchain account -> adopting IBC will allow to control staked asset in decentralized fashion for different dPoS networks. But it needs seperate sovereign blockchain to operate it
• I personally think delegation voucher, delegation tranche, bAtom are "specific design" for specific application, and it is not a universal solution for low level protocol.
• So I think we should not discuss on each "specific solution" in this group, but we need to discuss on lower level protocol which can accept most of such "specific solution"
• especially we should focus on solutions via IBC technology because in that way, our solution will not be bounded to Cosmos, but many other dPoS blockchains in the future who will accept standard IBC protocol.

2. shared security

• shared security is the important part for solution 2 : interchain account
• any defi project using interchain accounts needs enough security provided to be sovereign
• but most small application will not possess enough security to bootstrap the ecosystem
• so, we might need a big chain which provides security to different zones
• the big chain can be providing security to different kinds of dPoS defi applications
• discussion point : how can we leverage shared security feature to prosper different defi apps by providing them shared security?

so in result, I want to suggest a brainstorming on "PoS_Defi_SuperChain" which serves as the "mother" chain of different defi application "child" chains. It works like below.

• the mother chain has governance to choose which child chain to support
• when gov decides to support a child chain, the mother chain provides shared security to the child chain
• the child chain distribute rewards to the mother chain delegators for the incentive of shared security providing.
• child chains can decide to be independent from the mother chain if they think its security is strong enough to become a sovereign chain

the mother chain might be the cosmos-hub, or another new blockchain with its own native staking token. this mother chain itself can be supported its security from cosmos-hub via shared security too.

this mother chain does not execute every transaction on each child chain, but she just provides dPoS shared security on each child chain by providing shared security. So we can see this as the merkle tree proof ledger of many different child ledgers.

I imagine this mother chain will incubate many different dPoS defi related application chains such as pegzones, staking derivatives, DeXs, escrows, stable coins, lendings, oracles, etc

[maigoh]

I would like to provide clarity on the point "fungibility" which I bought up.

Fungibility exists on many different levels - for example, many will think that token X staked to validator A and B are essentially the same token, but each validator charge a different fee and have different level of slashing risks.

True fungibility is when a token X staked to any validator have exactly the same properties down to fees and slashing risks. This is important because it impacts how liquidity aggregates. In the case of the former definition of fungibility, the deriviative from each validator will be treated differently and priced differently as it isn't exactly able to be mutually substituted with another validator's deriviative.

You don't want to open n(n-1)/2 different markets (where n = number of validators) to trade deriviatives because its much more beneficial to have a single large liquidity pool for trading.

[bdflex]

i want to add two thoughts

1. extreme flexibility : not stucking in specific design

• solution 1 : programmable staking -> many dPoS does not have VM connected to staking module
• solution 2 : interchain account -> adopting IBC will allow to control staked asset in decentralized fashion for different dPoS networks. But it needs seperate sovereign blockchain to operate it
• I personally think delegation voucher, delegation tranche, bAtom are "specific design" for specific application, and it is not a universal solution for low level protocol.
• So I think we should not discuss on each "specific solution" in this group, but we need to discuss on lower level protocol which can accept most of such "specific solution"
• especially we should focus on solutions via IBC technology because in that way, our solution will not be bounded to Cosmos, but many other dPoS blockchains in the future who will accept standard IBC protocol.

1. shared security

• shared security is the important part for solution 2 : interchain account
• any defi project using interchain accounts needs enough security provided to be sovereign
• but most small application will not possess enough security to bootstrap the ecosystem
• so, we might need a big chain which provides security to different zones
• the big chain can be providing security to different kinds of dPoS defi applications
• discussion point : how can we leverage shared security feature to prosper different defi apps by providing them shared security?

so in result, I want to suggest a brainstorming on "PoS_Defi_SuperChain" which serves as the "mother" chain of different defi application "child" chains. It works like below.

• the mother chain has governance to choose which child chain to support
• when gov decides to support a child chain, the mother chain provides shared security to the child chain
• the child chain distribute rewards to the mother chain delegators for the incentive of shared security providing.
• child chains can decide to be independent from the mother chain if they think its security is strong enough to become a sovereign chain

the mother chain might be the cosmos-hub, or another new blockchain with its own native staking token. this mother chain itself can be supported its security from cosmos-hub via shared security too.

this mother chain does not execute every transaction on each child chain, but she just provides dPoS shared security on each child chain by providing shared security. So we can see this as the merkle tree proof ledger of many different child ledgers.

I imagine this mother chain will incubate many different dPoS defi related application chains such as pegzones, staking derivatives, DeXs, escrows, stable coins, lendings, oracles, etc

@dlguddus I think you are right here. I think delegated account control and shared security must go hand in hand. Even other decentralized custodial models (e.g tBTC, Ren) where a chain controls assets on another chain (using threshold signatures + sMPC) probably require shared security to be economically viable. As I said on the call, shared security is such a massive area that I'm wary of adding to the scope of the project. But at the same time it also seems pretty fundamental to liquid staking. So we'll discuss it on the next call, where we can explore if shared security can be integrated into the research.

[bdflex]

I would like to provide clarity on the point "fungibility" which I bought up.

Fungibility exists on many different levels - for example, many will think that token X staked to validator A and B are essentially the same token, but each validator charge a different fee and have different level of slashing risks.

True fungibility is when a token X staked to any validator have exactly the same properties down to fees and slashing risks. This is important because it impacts how liquidity aggregates. In the case of the former definition of fungibility, the deriviative from each validator will be treated differently and priced differently as it isn't exactly able to be mutually substituted with another validator's deriviative.

You don't want to open n(n-1)/2 different markets (where n = number of validators) to trade deriviatives because its much more beneficial to have a single large liquidity pool for trading.

@maigoh Yes, I think your point was clear on the call (at least to me).

And I wanted to clarify my point. I wanted to make sure that we weren't concluding that fungibility and liquidity were the same thing. [And by the way I'm not saying this was you were saying - it's just something that was mentioned on the call]. Yes, if we can design liquid staking with genuinely fungible tokens it would greatly improve our chances of building highly liquid trading venues. But there are other variables that will feed into liquidity e.g. the obvious one is that we have to create demand for these tokens, or we may have to create liquidity networks to share liquidity across venues, we may need to incentivize market makers etc. So I'd say fungibility is the biggest challenge on our way to liquid markets. But that is not the same thing as saying fungibility equals liquidity, or fungibility implies liquidity.

The two types of fungibility we have so far are:

Validator (Non-)Fungibility: you can argue that with similar uptime & low number of slashing events, that every validator delegation is almost fungible. But if attacks ramp up then this could change pretty quickly. So I do agree the market will (eventually) price in the risks here, which will damage liquidity. And variations in validator commissions might also mean were stuck with non-fungibility unless we can automatically adjust for commissions (which might be possible).

Token Denominations: in the Stafi model, a 1000 XTZ delegation is turned into a 1000 XTZ_S, a liquid version of the delegation. But it is an atomic unit. An NFT. I can't break this up into 10 x 100 XTZ_S units. So this is another form of non-fungibility. And it also will greatly impact the liquidity of such tokens.

My suspicion is there are other types. For example, if we had multiple chains issuing liquid staking tokens, then each chain would have it's own risk profile which would need to be priced in. There might also be custodial models where an exchange issues a liquid staking token, where again the risk rating of the exchange will impact price. Even if we try to create pegs (i.e. Chain X tokens will accept Chain Y liquid tokens at par and vice versa), eventually these pegs will break when reality diverges from theory.

So yeah fungibility is a big one to think about.

[FelixLutsch]

Notes from the first call (copying from Google Docs to Github ruins formatting so linking to the published gdoc here):

https://gdoc.pub/doc/e/2PACX-1vSxhQZ2RDP1fPu6RZTUiywx_ydMxHYfplAwf5sP7faTrQ7MlIS94_05_wGNSLudH19tKOJYlN1bsiRa

Recording: https://www.youtube.com/watch?v=gCMa1k5pbJk