A design for fungible staking-derivatives

Staking Derivatives At the inaugural Interchain Conversations, @zaki gave a talk explaining the important of staking derivatives, and why #StakingIsDeFi . Also, as exchange validators like Poloniex introduce trading on staked atoms it is necessary to allow trustless derivatives to be created for staked atoms on any validator, not only custodial validators like Poloniex and Coinbase, in order to allow non-custodial validators to remain competitive. http://kalpatech.co/Cosmos_Part_2_1.ogg Assetizing Delegations In some of the early designs for staking derivatives that @zaki and I were designing, we started with the premise of turning the `Delegation` struct already existing in the gaia codebase into an asset that could be transferred. However, these delegation assets would have to be non-fungible assets (NFAs) because of the way that the F1 fee-distribution works . Because F1 needs to keep track of the last time each individual delegator withdrew, these delegation assets are not fungible. We can imagine the delegation asset as follows with attributes and capabilities: ``` Delegation non-fungible-asset { To_Validator const Shares Last_Withdrawal_Time…

Excerpt (1191 of 16768 characters). Read the whole post on the forum ↗

B-Harvest also explored the DelegationTransfer(=Change_Owner) approach in Berlin Hackatom, but we now think it is not a good idea because delegators will tend to delegate to validators with high-liqudity-DelegationShare market, which will accelerate validator centralization.

So, we think the fungible token should not represent a delegation to specific validator, but should be independent of validators.

How would that work? Staked atoms need to be bonded to a specific validator and are slashable for a specific validator’s faults. How would you create a staking derivative independent of validator?

It is more like building an stock index to effectively remove alpha factors from individual stocks. Portfolio with >90% intersection with entire staked atom basket will practically work as an validator independent instrument, which was approached by chorusOne and sikka at Berlin hackatom.

I have another idea which is to split any delegation into two tranches, one having no responsibility on slash/commission, and the other with full responsibility on slash/commission. Former tranche can be fungible over most validators, later will be NFT. I still have some practical issue to detail out the solution yet.

This isn’t what we worked on at the Hack Atom, the delegation voucher idea (https://blog.chorus.one/delegation-vouchers/) was validator dependent.

Your proposal of making it like a stock index would effectively preserve the current stake / delegation distribution indefinitely, even when slashes occur, right? We want the distribution to be able to change, to reflect the market / delegators change in beliefs regarding different validators.

To your second idea, wouldn’t you need a single “risk oracle” to determine the distribution of no-risk delegated atoms and “risky” atoms? (This may be handleable, but I’m not sure if the risk oracle would move fast enough / would be game-able by the validators themselves)

The word independent does not mean 100%. If it is >90% independent(orthogonal), it is practically independent, as we say index fund is independent of individual stock return. I am not talking about mathematical purity. I am mostly on practical side. If the delegation pool copy more than 90% of whole staked atom basket, then it is basically what I am referring to. Of course it needs dynamic rebalancing, as it needs too in traditional finance.

Yes. The zone needs to observe each validator’s double-signing evidence to exclude such delegation from the pool.

I thought the decentralized voucher is about the voucher of delegation pool composed of many different validators. Maybe I misunderstood it.

What I want to ask to Sunny or other people is that is the market for each validator’s delegation proxy instrument dangerous for decentralization. I strongly expect that it will lead to acceleration of centralization because of preference of liquid market for cashing out the position instantly.

That is why I keep trying to imagine other solutions dealing with entire basket portfolio, or a tranche which allows validator-independent fungible tokenization without validator specific market.

Hello! This is Meher Roy from Chorus One. The proposition that delegation vouchers will lead to centralization of the Cosmos Hub are unsupported by the facts on the ground. Here are some things to consider: • Delegation vouchers already exist on the Cosmos Hub, but only for a single validator: Infinity Stones and Poloniex have partnered up to offer their users the ability to both earn interest and trade delegation positions on the order book of Poloniex. Today, delegators are able to earn ~3% interest and have full liquidity with that one particular validator. For all intents and purposes, atoms on the book of Poloniex are close analogues of delegation vouchers. This is a perilous state. Only custodial exchanges can offer the combination of liquidity and interest today. It is the current state that contains latent potential for Cosmos Hub staking to be entirely dominated by custodial exchanges. Pictorially, we are not in a Garden of Eden for decentralization. The current state is an asymmetric battlefield - custodial exchange validators spawn into the staking game with rocket launchers, whereas pure play validators spawn into it with sticks and stones. This problem is…

Excerpt (1197 of 3819 characters). Read the whole post on the forum ↗

Hi all, I’m a bit late to the party & wanted to check if there was further development on this “staking voucher” topic ?

Cool proposal – one question I had was whether, in the case of large DelegationShare transfers, the effect of having to call Change_Owner() for each share individually would put unnecessary stress on the network. Any thoughts on this? Would it be negligible or problematic?

You won’t have to call Change_Owner() for each share individually. You’d call ChangeOwner(amtShares staking.Shares) and pass in the number of shares to change, and it does them all at once. Shares are kept as sdk.Coins, it’s still an account balance model, not a UTXO-like thing where each share is a separate object.

I am imagining a case where the DelegationShare is transferred to other chain and deposited to a contract.

Then, it is natural for the contract to change the ownership to itself at the origin chain, so that it can accumulate value over time. But I guess the contract cannot do this because it does not have a private key to sign the transaction.

Even if the contract managed to change the ownership somehow, it still needs to withdraw rewards and store it or even sell it automatically from the origin chain, which seems practically impossible.

So, do we really want to create this kind of complexity?

I think a lot of the issues that exist regarding external contracts managing validator shares can be managed very simply using interchain accounts and(or) an internal ledger within the smart contract that keeps track of shareholders.

I am not sure how the interchain account can do the job.

How contract can hold their private key? I think it is not possible.

Also I have another question. If the DelegationShare token is transferred to other blockchain via IBC, how does the module verify the possession of the token?
To change the ownership of the delegation, the module needs to verify the possession of the token, but its ability to verify the possession is limited to its own chain.

So, I think it is impossible to verify the possession of the token outside origin chain, therefore it is impossible to change the owner of delegation outside origin chain. It has to be moved into the origin chain to create the owner change transaction.

So, I think this model is not an interchain compatible solution.

My understanding is that what holders want is to be able to remain liquid (right to trade the ATOM at any time) while at the same time wanting to not be diluted via inflation or miss other rewards, in addition to now the Network also wanting to avoid a situation where not enough are delegating, creating critical risks that leave the network vulnerable. Is this more or less accurate? Thanks.

valardragon:

To your second idea, wouldn’t you need a single “risk oracle” to determine the distribution of no-risk delegated atoms and “risky” atoms? (This may be handleable, but I’m not sure if the risk oracle would move fast enough / would be game-able by the validators themselves)

To your second idea, wouldn’t you need a single “risk oracle” to determine the distribution of no-risk delegated atoms and “risky” atoms? (This may be handleable, but I’m not sure if the risk oracle would move fast enough / would be game-able by the validators themselves)