Brief Review of "Why Stake When You Can Borrow?"

Archived Cosmos-SDK
1

This document is a brief review of “Why Stake When You Can Borrow?”(https://arxiv.org/abs/2006.11156) in the context of Cosmos-SDK based staking derivatives

The Title of This Paper

Wrong Title

This paper describes a borrowing mechanism from staked assets. Therefore, we stake the underlying assets, and then we borrow staking derivatives from it. So, this is an additional process, not a process which can replace staking activities. So the title itself is not correct because it says that we can borrow instead of staking, which is impossible.

Where Did the Title Come From?

This title is inspired by the paper “Why buy when you can rent?”. This title is indeed having a correct context because the paper describes an attack vector on PoW by renting hash power without actually buying the mining machines.

For Major Properties

Context

Because this paper assumes Tezos model for the suggested staking derivative, this doesn’t fit well on our dPoS model. But if we think every validator in Tezos as every delegator in Cosmos, many characteristics are similar, so here I review its methdology from this point of view

Property 1

image
image921×84 20.4 KB

  • This property assumes that the staking derivative can be defaulted

    • who is responsible for the defaulted value?

  • Case study

    1. If a delegator borrowed 70 sAtom from 100 staked Atom

    2. If the staked Atom is slashed 50%, only 50 staked Atom remains as the collateral

    3. Then, the delegator has no incentive to redeem the staked Atom because the value of collateral is lower than what he received from borrowing

    4. There is no one who is responsible for 20% of defaulted amount

    • Actually every sAtom holder will suffer the loss by dilution of the sAtom price against Atom
    • Responsibility of slashing is distributed to non-responsible sAtom holders
    • This design can weaken the security of dPoS because the responsibility and risk of slashing is diluted to all sAtom holders, opening attack vectors and irresponsible staking activities

Property 2

image
image919×112 27 KB

  • This property ensures that the user should pay equal or more than what he received from minting.
    • When more? : when the validator is slashed
    • But, when a validator is slashed in Cosmos, the validator is tombstoned, therefore any delegation towards the tombstoned validator cannot be used for borrowing anymore
    • So, this property is unnecessary in Cosmos

Property 3

image
image920×106 27.4 KB

  • Slashed validators are tombstoned in Cosmos, therefore this property is not necessary in Cosmos

Property 4

image
image923×107 29.2 KB

  • This property heavily relies on the efficient price discovery in a market where people trades the staking derivatives against underlying asset
    • This assumption is very strong one, because we cannot guarantee the efficient market with enough liquidity
    • Sometimes, there can exist a situation when the market is unavailable for technical or financial reasons
  • We think that this kind of very dependent methodology should be avoided for simpler and independent solution for staking derivatives
    • Using the market price as oracle is as dangerous as using external oracle as the price source

Problems on Creating Fungible Tokens via AMM

  • This paper suggests an Constant Function based Market Making utility to create fungible tokens for staking derivatives
  • But, if we don’t deal with separated slashing responsibility, the AMM approach will cause
    • No specific person is responsible for slashing risk
    • Everyone holding the fungible token will suffer slashing loss together
    • Resulting in “Tragedy of Common” situation, which can break down dPoS security
  • Therefore, we need to wisely separate this different slashing risk before we put everything inside one basket to dilute every slashing risk, to have a good financial incentives for investors to act responsibly upon slashing risk
3 Likes