Delegation tokenization module

Delegation Tokenization Module This post is to describe most concise and simple, but expandable design of delegation tokenization feature on Cosmos-SDK. 1. Problem • Each delegation has different • Accumulated rewards • Risk of double signing • How can we create fungible tokens from delegations ? 2. Processes • `FToken(V)` and `YToken(D)` for given validator `V` and delegation `D` • Delegators can tokenize their delegation into `FToken(V)` and `YToken(D)` • `FToken(V)` • Fungible token which has redemption rights on every `BondedTokenAmount` in `TokenizedDelegation` staking to validator `V` • `FToken(V)` is only fungible among delegations to the same validator `V` • All `FToken(V)` holders will be affected by slashing events from the validator `V` • `YToken(D)` • Non-fungible token which has redemption rights only on accrued rewards from the specific `TokenizedDelegation` of the delegation `D` • Delegation tokenization process • Definitions • `TokenizationRatio(V)` for validator `V` : the amount of `FToken(V)` minted or burnt for every 1 `BondedTokenAmount` in `TokenizedDelegation` on validator `V` • The module account…

Excerpt (1196 of 5484 characters). Read the whole post on the forum ↗

Here is what Iqlusion thinks an optimal staking derivatives system would look like. Like in Bharvest’s proposal, there are two types of derivative token: Delegation Tokens and Reward Tokens. h/t StakeWise for naming the tokens: https://github.com/stakewise/contracts/tree/feature/stakewise-2/contracts/tokens Delegation & Reward Token Delegation Tokens are a fungible token denominated by validator and maturation date issued by the staking derivatives module. A delegation of 1000 ATOM to Iqlusion with a maturity date of Oct 26th would be ‘1000 ATOM_Oct26_iqlusion_Delegation tokens. The staking derivatives module would also issue Reward Tokens that act as zero coupon bonds for the future rewards. There should be a normative duration for the bond. The module would issue 1,000 Iqlusion Reward Tokens for each week between the delegation and maturity: • 1000 ATOM_Sept28_iqlusion_Reward • 1000 ATOM_Oct5_iqlusion_Reward • 1000 ATOM_Oct12_iqlusion_Reward • 1000 ATOM_Oct19_iqlusion_Reward • 1000 ATOM_Oct26_iqlusion_Reward Key advantages over Bharvest’s scheme • Maturity dates on the Reward Tokens affect the fungibility of the delegation. Bharvest scheme doesn’t…

Excerpt (1196 of 2046 characters). Read the whole post on the forum ↗

So Tarun says discrete maturation events are bad for a De-Fi instrument and I can’t argue with him.

If you try to have perpetual Delegation token, your token’s denom would be validator and origination date.

It’s very difficult to coordinate origination dates so I expect that a fungible set will be small for a naive perp delegation token.

It should be very easy to produce a schelling point for the maturation date of tokens in my plan. This produces a large fungible set.

Another way to have a perpetual tokens is to have synethetic instruments that are collateralized and IBC application protocol that allow rolling over the maturity of a delegation token atomically so that tokens don’t need to be rotated out of collateral pools.

Perpetual delegation token is naturally provided from my model.

Is the Non-existence of IBC compatible NFT really a blocker for my model?

It is still transferable inside the origin chain, and it can be upgraded when we have the IBC compatible NFT so that the YToken becomes IBC transferable NFTs.

Below is our new model integrating our original model and zaki’s fungible ytoken concept. Delegation-Tokenization-Module Delegation tokenization module, a native Cosmos-SDK module which allows delegations to be tokenized to fungible tokens 1. Problem • Each delegation has different • Validator to stake on • Accumulated rewards • Risk of double signing • How we can standardize staked atom into universal one token? 2. Solution Utility • Delegators can tokenize their delegation into `NToken` and `YToken` • Tokenized delegations either can be • redeemed by submitting both `NToken` and `YToken` • or auctioned to any `NToken` holder after maturity Basic Analogy of each token • `NToken` • It has ultimate rights to redeem “any” tokenized delegation whose maturity is passed • `YToken(V,M)` • It is fungible over same validator `V` and same maturity `M` • `YToken` holders get accrued rewards until redemption, but are exposed to slashing risk • `YToken` holders will • redeem delegation with `NToken` and `YToken` submitted to the module before maturity • or get auctioned by `NToken` holders after maturity 3. Parameters,…

Excerpt (1194 of 9396 characters). Read the whole post on the forum ↗

Can we fill in a bit more context/motivation/assumptions behind these designs? I think it would help others getting up to speed. My understanding is that the two token design is motivated by the existing reward pool structure, which makes delegations non fungible, so the two tokens are about ways to extract fungibility. I wonder if we could get the desired fungibility through an overall simplification of the staking system. Ie rather than the reward pool which can collect any kind of token, we convert all rewards/fees to atoms with an onchain AMM, and autobond them. Then I think the existing validator pool shares could become the fungible (per validator) staking derivative. This also has the potential added benefit of creating constant upwards price pressure on the atoms. The downside to converting all tokens to Atoms is that folks might genuinely want to built exposure to these tokens, but they can still do so by trading out for them, or possibly through mechanisms on their zones to reward the bonded atom holders for cross-chain staking directly on the zones (?) While the two token design is interesting, and potentially appealing to more financialized use cases, I question…

Excerpt (1198 of 2676 characters). Read the whole post on the forum ↗

i will write another post with lists of possible designs, assumptions, and contexts.
thanks for suggestion!

just one note here.

I wonder if we could get the desired fungibility through an overall simplification of the staking system. Ie rather than the reward pool which can collect any kind of token, we convert all rewards/fees to atoms with an onchain AMM, and autobond them.

I think it is very fragile assumption that the AMM can successfully swap every reward token to bonding token, atoms. This relates to the liquidity environment of AMM, so I think we don’t want to have the staking/distr module which relies on AMM market condition.

What I can suggest is splitting of handling bonding-token(atom in Hub case) and non-bonding-token to two different process.

1. bonding-token : auto rebonding
2. non-bonding-token : airdrop RewardToken which provides right to withdraw the corresponding accumulated rewards

RewardTokens are fungible over same validator and same reward accumulation period

bharvest:

I think it is very fragile assumption that the AMM can successfully swap every reward token to bonding token, atoms. This relates to the liquidity environment of AMM, so I think we don’t want to have the staking/distr module which relies on AMM market condition.

What I can suggest is splitting of handling bonding-token(atom in Hub case) and non-bonding-token to two different process.

1. bonding-token : auto rebonding
2. non-bonding-token : airdrop RewardToken which provides right

My assumption is that the fee tokens are governance gated, so accepting them would also require some analysis about expected liquidity, and folks would be incentivized to provide the liquidity. But you’re right it might still create fragility. An option could be for the system to include some maximum slippage so that the trade only happens if theres enough liquidity. If not, the extra rewards could pool separately somewhere (I guess this is what you’re suggesting too), either in a place that doesn’t support derivatives at all (might be fine!) or in a place that supports only time-bound derivatives if we can’t find a good mechanism for perpetuals

So I have concerns about outsourcing product market fit for staking derivatives to a zone. This could potentially make a large amount of hub security dependent on a zone with a different validator set that holds all the stake of the hub.

If it wasn’t for the rise of exchange staking, I would say that staking derivatives inherently pose this risk but exchange staking makes this risk avoidable. It looks like there are sufficiently diverse set of different DeFi activities that it’s unlikely all the derivatives will end up on one other chain.

If we don’t think anyone design is a clear winner, there should be a place to build financial primitives on top of staking derivatives on the hub to avoid the Hub Security becoming too tied to a zone.

I think amm automated swap is adoptable if it can be an optional automation, in other words, if we have plan B.

I think I agree to have this model upon tokenization of withdrawal right as plan B!

This is a very important concerns I believe.

If majority of liquid staking tokens go outside the Hub and be placed in some insecure zone or contract, that is a significant threat to the security of the Hub.

Maybe we can have a limit on delegation tokenization ratio (tokenized delegation / total delegation). We can gradually increase this limit over time when we have more firm prevention mechanism. Maybe like 20% as start is a good number?

Zaki what outsourcing to zones were you referring to? If majority of liquid staking tokens go outside the Hub and be placed in some insecure zone or contract, that is a significant threat to the security of the Hub. This is why I’ve been so concerned about and hesitant towards staking derivates work, since we don’t have a clear sense of impact on security model. Maybe it’s something Gauntlet can start to help with. Of course we need it to combat exchanges but we should air on the side of risk mitigation here rather than focus too much on just enabling massive DeFi with staked atoms (which will be important but we need to roll it out responsibly). And I totally took for granted that there would be a cap on how much of a delegation could be used for derivatives, meant to bring that up. It would certainly help with some of these concerns. So I totally agree we should start with something like ~20% and it can potentially increase over time Also note there’s more we need to combat centralization on exchanges, like better UI/UX, accounting tools, and just over all making the experience seamless for people to stake directly vs through coinbase. Staking derivatives are just…

Excerpt (1196 of 1218 characters). Read the whole post on the forum ↗

What I’m saying is

Let’s say the best derivatives for collateral, yield farming, synthetic assets are constructed from tokenized shares. A zone that that takes shares tokens and builds those derivatives might find itself custodying a large amount of the total stake on behalf of users.

I think the experiences so far with yield farming is that UI/UX, accounting etc tools are weak effects compared to larger returns.

The ability to have instant access to liquidity and participate in DeFi swamps the other issues. We should improve the above but the most important thing is landing a derivative.