# A design for fungible staking-derivatives

**URL:** <https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441>\
**Category:** Research-Staking\
**Created:** [July 8, 2019, 5:21pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441 "2019-07-08T17:21:21Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![sunnya97](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/sunnya97/32/510_2.png) [@sunnya97](https://forum.cosmos.network/u/sunnya97)\
**Post date:** [July 8, 2019, 5:21pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/1 "2019-07-08T17:21:21Z")

</div>

# Staking Derivatives

At the inaugural Interchain Conversations, @zaki gave [a talk](http://kalpatech.co/Cosmos_Part_2_1.ogg) explaining the important of staking derivatives, and why #StakingIsDeFi. Also, as exchange validators like [Poloniex introduce trading on staked atoms](https://medium.com/circle-trader/cosmos-staking-is-live-78879f1523b4) 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](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](https://github.com/cosmos/cosmos-sdk/blob/master/x/distribution/spec/01_concepts.md). 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:

```auto
Delegation non-fungible-asset {
    To_Validator const

    Shares
    Last_Withdrawal_Time
    
    Unbond()
    Redelegate()
    Withdraw()
    Vote()
    GetSlashed()
}

```

where the holder of this asset is able to call any of the capabilities on that object (i.e. withdraw rewards, unbond, etc).

It is because of the `Last_Withdrawal_Time` attribute of a delegation object that they are not fungible as a Delegation asset with an earlier `Last_Withdrawal_Time` is entitled to more rewards from the F1 rewards pool than a delegation object with a later `Last_Withdrawal_Time`.

However, if staking derivative are to be useful in DeFi, it would be desirable to create one in which all derivatives from a single validator are fungible. While NFA derivatives could be traded OTC, it would be difficult to put them into a [Uniswap-style market](https://medium.com/scalar-capital/uniswap-a-unique-exchange-f4ef44f807bf) or even a traditional orderbook system. It would furthermore heavily complicate using the derivatives as collateral for a [Kava CDP](https://medium.com/kava-labs/defi-coming-to-cosmos-808034b733be) for example, as the price oracles would have to report prices for each different NFA seperately.

Thus, the search for fungible staking derivatives was on.

> Note that the Delegation struct currently tracks delegator shares, not number of Atoms. This is so that if a validator gets slashed, the number of outstanding shares stays the same, but the exchange ratio between a validators’ shares change. So if there are currently 10 Atoms in a validator’s bonded pool and 10 outstanding shares, the unbonding ratio from shares to Atoms is 1:1. But if the validator gets slashed by 20%, there are now 8 Atoms in the validator’s bonded pool and 10 outstanding shares, so the unbonding ratio is 1:0.8. And any new atoms that get deposited are credited with the inverse number of shares. So if someone deposits 4 Atoms, they will recieve 5 shares.

## Delegation Vouchers

At the Cosmos HackAtom Berlin, the [Sikka](https://www.sikka.tech/) and [Chorus One](https://chorus.one/) joint team implemented a mechanism called “delegation vouchers” outlined in [this blog post](https://blog.chorus.one/delegation-vouchers/). Essentially they successfully create fungible delegation vouchers by removing the F1 fee pool altogether and autobonding all rewards (thus allowing the delegator shares to appreciate). However, this is done by adding the constraint that all rewards can only be in the staking token of a chain. This may be reasonable for some chains, but one of the design goals of the Cosmos Hub is that fees can be [paid in a variety of tokens](https://github.com/cosmos/cosmos/blob/master/Cosmos_Token_Model.pdf), not just Atoms. This becomes even more of a concern when the Hub upgrades to do [interchain staking](https://github.com/cosmos/ics/issues/27) in which the validators could presumably be paid rewards in the native token of another chain.

> **[Chorus One Blog | The latest from the staking industry](https://chorus.one/blog)**
>
> Welcome to Chorus One's Blog - All you need to know about Staking, Proof-of-Stake and networks. Read the latest articles, news, and research reports from Chorus One.

## Delegation Claims

So, in order to make the vision of a fungible staking derivatives on the Cosmos Hub a reality, we have to make it work within the context of the F1 reward distribution system.

In the original thinking of framing the problem in terms of atributes and capabilities, I had ignored an interesting capability that is currently present in the delegation objects in the Gaia staking module, the ability to `Change_Withdrawal_Address()`. I assumed it was unimportant because the transfer of the Delegation NFA which contains the `Withdraw()` capability acts as a "changing of a withdrawal address anyways. (Also, amusingly, I can’t quite remember why this feature exists in the first place. I think it may be a remnant of the “`Create Validator on Behalf Of`” system that was removed right before launch of the Hub?)

By incorporating this capability into the design of the staking derivative asset, I think we can begin to make them fungible. To start, we’ll start by designing a derivative asset that is still non-divisble, but is “equivalent” with respect to everything but the amount of shares that the specific asset holds. Later we will turn these into truly fungible tokens. We’ll also ignore peripheral capabilities like governance voting for simplicity.

In this system, we will continue to have a delegation struct in the staking module keeper, but issue an asset that represents some capabilities on the delegation struct.

```auto
Delegation struct {
    ID const
    To_Validator const

    Withdrawal_Address
    Shares
    Last_Withdrawal_Time

    Withdraw() - only Withdrawal_Address
}

DelegationClaim non-fungible-asset {
    DelegationID const

    Unbond()
    Redelegate()
    Change_Withdrawal_Address()
}

```

In this model, when Alice bonds some Atoms to a validator, it generates her a new `Delegation` struct with her address as the `Withdrawal_Address` AND sends her account an `DelegationClaim` NFA. Now at any time, as so long as the `Delegation.Withdrawal_Address` is pointed to her address, she can call the `Withdraw()` function and withdraw the rewards that have been acculated since the `Delegation.Last_Withdrawal_Time`. Furthermore, as long as she is in possession of the associated `DelegationClaim` asset, she can also `Unbond()` and `Redelegate()`; essentially she is the owner of the underlying bonded Atoms.

Now if Bob wants to buy Alice’s position, he could pay her and obtain the `DelegationClaim` asset that corresponds to Alice’s `Delegation`. Now this is where the interesting part comes, by obtaining the `DelegationClaim` asset, Bob has become the effective owner of the underlying bonded Atoms (due to his ability the unbond the bonded atoms). However, he hasn’t started receiving the rewards yet. The `Delegation` struct in the Hub staking module still lists Alice as the `Withdrawal_Address`. Thus by obtaining the `DelegationClaim` NFA, Bob has NOT become the recipient of rewards earned by _his_ bonded atoms. But his NFA does have the capability to `Change_Withdrawal_Address()`, which means as the possessor of the `DelegationClaim` he can send a transaction on the Hub to change the `Withdrawal_Address` of the associated `Delegation` to his own address. When he sends the `Change_Withdrawal_Address()` the `Delegation` will `Withdraw()` the rewards to the previous owner, Alice, set `Withdrawal_Address` to Bob, and set `Last_Withdrawal_Time` to the current time. Until Bob actually decides to send that transaction, Alice actually continues to earn the rewards. Bob has to do action manually, because we can’t trigger it at the time-of-transfer as the transfer could have occured on a different chain than the Hub.

```auto
(claim DelegationClaim) func Change_Withdrawal_Address(newAddress) {
    delegation := GetDelegation(claim.DelegationID)
    delegation.Withdraw()
    delegation.Withdrawal_Address = newAddress
    delegation.Last_Withdrawal_Time = time.Now
}

```

If given the option of buying two different `DelegationClaims` both to the same validator and for the same number of shares, Bob doesn’t care who the current `WithdrawalAddress` is or what the `Last_Withdrawal_Time` is, because neither are relevant to his rewards. All that matters to Bob’s rewards is how quickly he actually goes to change the withdrawal address, but the result of that action is the same regardless of which `DelegationClaim` he bought. This allows these assets to be pseudo-fungible because the _ability to switch the reward address_ on any two `DelegationClaims` is the same. US Dollar Bills have serial numbers on them, but for all practical intents and purposes, we treat them as fungible. In the same way, equal-amount NFAs that correspond to different delegations with different owners, can be treated as fungible.

Now, if Bob is just trading on these derivatives, maybe it’s not worth actually changing the `Withdrawal_Address` because he’s planning on holding the asset for such a small period that it’s not actually worth claiming the rewards on it, as the amount he’ll earn is not worth the cost of making the tx (or the IBC packet if he’s on another chain). On the other hand, if Bob bought this asset to hold, he can change the withdrawal address and start earning off of the asset. Interestingly, for the seller, Alice, it might be in her incentive to sell to a “lazy buyer” who will be slow to make the change, because until then, she can continue to earn the rewards off of the claims she already sold.

## Fungible Delegation Shares

Now, the one thing we haven’t resolved yet is the divisibility of the claims. If a `DelegationClaim` corresponds to a `Delegation` of 10 shares, there’s no way to sell only 5 of the shares. This is a necessary property to achieve usefulness in DeFi applications. So, now we will take the strategy thus far and make it usable in the case of a fungible token.

When Alice creates a new delegation to a validator, instead of recieving a single NFA that represents her entire delegation, she receives tokens corresponding to the amount in the Delegation. The delegation struct in the staking module, instead of being indexed by an ID, will be indexed by “owner” (along with the `To_Validator` of course, as a delegator can be delegated to multiple validators).

```auto
Delegation struct {
    Owner const
    To_Validator const

    Shares
    Last_Withdrawal_Time

    Withdraw() - only Withdrawal_Address
}

DelegationShare token {
    Delegation_Owner const
    Delegation_To_Validator const

    Unbond()
    Redelegate()
    Change_Owner()
}

func HandleNewDelegation(delegator, amount, validator) {
    del := CreateDelegationStruct(
        Delegation {
            Owner: delegator,
            Shares: amount * conversion ratio,
            Validator: validator,
            Last_Withdraw_Time: time.Now,
        }
    )

    SharesDenom := sdk.CreateNewTokenDenom(
        DelegationShare {
            Delegation_Owner: delegator,
            Delegation_To_Validator: validator,
        }
    )

    bank.Mint(delegator, del.Shares * SharesDenom)
}

```

Now, these new `DelegationShare`s act very similarly to the `DelegationClaim`s introduced earlier, except they only affect the amount of shares in a delegation 1:1 with the `DelegationShares` owned.

Assuming the conversion ratio is currently 1:1, Alice could delegate 10ATOMs to the Sikka validator, and she will recieve 10 `Alice:Sikka:DelShares`. She can then sell 5 of these to Bob who will now be the owner of 5 `Alice:Sikka:DelShares`. He can then use these tokens to `ChangeOwner()` of up to 5 of `Shares` in the `Delegation` struct owned by Alice. When he changes the owner of some of Alice’s shares, the mechanism will automatically withdraw Alice’s rewards for the amount of shares that Bob is trying to `Change_Owner()` with, credit her with the rewards, and then update her `Delegation.Shares` to remove the amount that Bob is trying to change ownership of. It will then create Bob his own `Delegation` struct with `Shares` set to the amount of shares he took from Alice and the `Last_Withdrawal_Time` set to the current time. It will then burn Bob’s `Alice:Sikka:DelShares` and instead mint him some `Bob:Sikka:DelShares`.

But what if Bob already has a Delegation struct to the same validator? In this case, it will withdraw all the rewards for the shares already in Bob’s struct and then add his newly obtained shares to it and reset the `Last_Withdrawal_Time` to the current time.

```auto
func HandleChangeOwnership(validator, fromDelegator, toDelegator, numShares) {

    successful := bank.BurnCoins(toDelegator, numShares * fromDelSharesDenom)
    if not successful {
        throw
    }

    fromDel := GetDelegation(validator, fromDelegator)
    fromDel.Shares -= numShares
    fromDel.WithdrawRewards(numShares)

    toDel := GetDelegation(validator, toDelegator)

    if toDel not found {
        toDel = HandleNewDelegation(delegator, amount, validator)
    } else {
        toDel.WithdrawRewards(toDel.Shares)
        toDel.Shares += numShares
        bank.Mint(toDelegator, toDelSharesDenom)
    }
}

```

In this system, to a buyer Charlie, `Alice:Sikka:DelShares` should be equivalently valued to `Bob:Sikka:DelShares` because they are both 1:1 transformable into `Charlie:Sikka:DelShares`.

Now everything seems great…except two small problems.

1. For tokens that are currently in an active redelegation away from another validator, they are slashable for both the current validator’s faults and the previous validator’s fault, and thus have a higher risk profile and are not fungible with shares that are no longer in an active redelegation.
2. For newly bonded tokens, they’re not subject to slashes that happen before they started bonding. For example, if a validator commits a fault at block 10, Alice delegates at block 15, and evidence is submitted at block 20, Alice’s tokens should not be slashable. (This is not implemented in the Cosmos Hub yet, but [it should be](https://github.com/cosmos/cosmos-sdk/issues/1440).) Because these new delegations are slightly less at risk than tokens that have been bonded for longer than an unbonding period, they are not perfectly fungible.

Both of these edge cases involve some funkiness that happens for brand new delegations to a validator. Thus, the simple solution for resolving both these problems is to not allow a new delegation to issue derivatives until after it has been bonded for at least one unbonding period.

With this design, DelShares from the same `Delegation` are truly fungible and `DelShare`s to the same validator from different `Delegations` are “pseudofungible”. And interesting next step challenge would be to design a system in the Cosmos SDK and other frameworks that allow pseudofungible assets to be treated the same (for example, we want to be able to put pseudo-fungible shares in the same Uniswap pool). The design for such a system is out of scope for this spec, but some very preliminary discussion can be found [here](https://github.com/cosmos/cosmos-sdk/issues/1980).

## Still Open Questions:

**Can we auto-rebond staking token rewards?**

Currently, in the Cosmos Hub, all inflationary atoms are distributed as rewards. However, there may be some desire to have inflationary atoms auto-bonded instead. This would allow the rewards to a validator pool to be automatically added validator’s bonded pool and the conversion ratio of shares to atoms be constantly increasing. Some things around this still need to be thought through such as how it interacts with slashing and that it works in the context of this derivatives system.

**Do peripheral capabilities like `Vote()` go in the `Delegation` or the `DelegationShare`?**

In the spec, we mentioned that we will abstract away peripheral capabilities associated with staking such as the ability to vote in governance. Where should these capabilites be located, in the `Delegation` or in the `DelegationShare`?

**Should transfers of `DelegationShare`s on the Cosmos Hub automatically trigger `Change_Owner()`?**

If a `DelegationShare` is transferred on another zone (where most DeFi applications will be located), the owner has to come back the Hub to manually execute the changeing of owner. However, in the cases where a transfer is made on the hub itself, should we just make a hook that automatically changes ownership whenever a share is sent to a new address?

**Tax implications of Forced Withdraws**

Because when you merge `Delegation` structs, it causes a forced withdraw of rewards earned thus far so that it can reset the `Last_Withdrawal_Time`. This may have tax implications that should be accounted for. How can we design tags that make it as easy as possible for delegators to take these into account?

* * *

Special thanks to the [Chorus One](https://chorus.one/) team with whom many discussions took place in the process of designing this spec.

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [July 9, 2019, 5:50am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/2 "2019-07-09T05:50:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sunnya97](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/sunnya97/32/510_2.png) [@sunnya97](https://forum.cosmos.network/u/sunnya97)\
**Post date:** [July 9, 2019, 1:32pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/3 "2019-07-09T13:32:32Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [July 9, 2019, 1:49pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/4 "2019-07-09T13:49:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![valardragon](https://avatars.discourse-cdn.com/v4/letter/v/e0b2c6/32.png) [@valardragon](https://forum.cosmos.network/u/valardragon)\
**Post date:** [July 9, 2019, 3:20pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/5 "2019-07-09T15:20:09Z")

</div>

This isn’t what we worked on at the Hack Atom, the delegation voucher idea ([https://blog.chorus.one/delegation-vouchers/](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)

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [July 9, 2019, 4:48pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/6 "2019-07-09T16:48:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![meherroy](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/meherroy/32/903_2.png) [@meherroy](https://forum.cosmos.network/u/meherroy)\
**Post date:** [July 11, 2019, 12:29am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/7 "2019-07-11T00:29:25Z")

</div>

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:

1. **Delegation vouchers already exist on the Cosmos Hub, but only for a single validator:** [Infinity Stones and Poloniex](https://twitter.com/Poloniex/status/1144667209853276160) 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.

2. **Delegation vouchers inherit liquidity from instantly re-delegation:** The Chorus & Sikka design, hereafter called the Berlin design, had one powerful element. If a user holds a delegation voucher from validator X, they can instantly re-delegate to validator Y, and receive the delegation voucher from Validator Y. In other words, delegation vouchers are mutable. Each switch will cause ~5% of the vouchers to be frozen, but the rest can be fully liquid under switches. This feature makes the vouchers of the smallest validators quite liquid. Further iterations on the Berlin design will hopefully enhance the switch-ability aspect further.

3. **Small validators can partner up to build liquid staking indexes:** One already observes partnerships emerging amongst small validators - partnerships such as the [Decentralized Staking Defenders](https://chainflow.io/announcing-the-decentralized-staking-defenders/). Delegation Vouchers offer a business model for these groups. They can create a voucher of delegation vouchers, that represent a portfolio of delegations to all of the members of that particular group. Such staking indexes can be easily competitive, even dominant, over the delegation vouchers of Poloniex. After all, which liquid asset would you rather hold as a delegator - that of Poloniex or that of the Decentralized Staking Defenders? The delegator community realizes the need for network decentralization to safeguard their atom investment - if we make it painless for them to build decentralized delegation portfolios they will do so.

4. **Future Validation technology will remove double signing risk from small validators:** Today, many small validators run sub-par setups - we scanned the network and found \>30 validators running without sentries. Many validators, including some in the Top-10, run with keys on disk. There is a material difference in the double signing risk between Certus One and say that 60th validator on the list. But this asymmetry will disappear in the next 2-3 years. Look at SignOS - that product will make double signing protection an abject commodity. In the future, as a delegator, double signing risk will be a thing of the past unless the validator is actively malicious / abjectly incompetent. In that circumstance, why would I not delegate to a staking index of the Decentralized Staking Defenders? What attachment do I have to Poloniex?

All in all, let’s have a proper debate and a proper review of the second order consequences of all that is being built in the ecosystem. The game is young, and many twist await us all.

---

<div class="post-metadata">

**Author:** ![AdrienDLT](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/adriendlt/32/914_2.png) [@AdrienDLT](https://forum.cosmos.network/u/AdrienDLT)\
**Post date:** [November 4, 2019, 11:13am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/8 "2019-11-04T11:13:22Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jnaviask](https://avatars.discourse-cdn.com/v4/letter/j/ad7895/32.png) [@jnaviask](https://forum.cosmos.network/u/jnaviask)\
**Post date:** [November 14, 2019, 4:48pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/9 "2019-11-14T16:48:43Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![sunnya97](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/sunnya97/32/510_2.png) [@sunnya97](https://forum.cosmos.network/u/sunnya97)\
**Post date:** [December 19, 2019, 6:55pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/10 "2019-12-19T18:55:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [October 12, 2020, 11:52am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/11 "2020-10-12T11:52:46Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![dogemos](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/dogemos/32/860_2.png) [@dogemos](https://forum.cosmos.network/u/dogemos)\
**Post date:** [October 12, 2020, 4:23pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/12 "2020-10-12T16:23:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bharvest](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/bharvest/32/1042_2.png) [@bharvest](https://forum.cosmos.network/u/bharvest)\
**Post date:** [October 13, 2020, 12:35am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/13 "2020-10-13T00:35:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Random-Strings](https://avatars.discourse-cdn.com/v4/letter/r/439d5e/32.png) [@Random-Strings](https://forum.cosmos.network/u/Random-Strings)\
**Post date:** [February 24, 2021, 8:45am UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/14 "2021-02-24T08:45:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nhathongminh](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/nhathongminh/32/1613_2.png) [@nhathongminh](https://forum.cosmos.network/u/nhathongminh)\
**Post date:** [April 19, 2021, 4:07pm UTC](https://forum.cosmos.network/t/a-design-for-fungible-staking-derivatives/2441/15 "2021-04-19T16:07:14Z")

</div>

> [@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)