# Delegation tokenization module **URL:** \ **Category:** Cosmos-SDK\ **Created:** [September 29, 2020, 12:14pm UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011 "2020-09-29T12:14:39Z")\ **Posts on this page:** 13\ **Page:** 1

**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:** [September 29, 2020, 12:14pm UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/1 "2020-09-29T12:14:39Z")

# **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` - Delegation tokenization process - Transfer ownership of `YToken(D)` - Delegation redemption process for any `TokenizedDelegation` - Slashing event hook ## 3. States and Messages ### States - `TokenizedDelegation` - `DelegationIndex` - pointing the delegation object which is tokenized - `BondedTokenAmount` - the amount of token bonded for this `TokenizedDelegation` - `YTokenOwner` - the account address of `YToken(D)` owner - `Maturity` - the maturity of this `TokenizedDelegation` ### Messages - `MsgDelegationTokenization` - `MsgSendYToken` - `MsgRedeemDelegation` ## 4. Discussions ### Governance Voting Rights - Problem - Discussion ### Universally Fungible `FToken` - Problem - Suggested Solution ### NFT Compatibility over IBC - Problem - Solution ### Marketplace for Trading `YToken` - Problem - Suggested Solution ---

**Author:** ![zaki\_iqlusion](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/zaki_iqlusion/32/1055_2.png) [@zaki\_iqlusion](https://forum.cosmos.network/u/zaki_iqlusion)\ **Post date:** [September 30, 2020, 12:08am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/2 "2020-09-30T00:08:45Z")

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](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 1. Maturity dates on the Reward Tokens affect the fungibility of the delegation. Bharvest scheme doesn’t recognize this. The right to issue more Reward Tokens or unbond only comes upon maturity. Our proposal incorporates this into the denom. 2. Bharvest’s proposal creates a stateful Non-fungible token (NFT) object for the Reward Token. This class of object does not have a mature IBC protocol as of today. The token objects proposed by Iqlusion are all IBC friendly. All distinguishing information is incorporated into the denom of the object. 3. These tokens should all be relatively easily priced as discounted to an ATOM. They should be easily integrated into yield farming using constant function market makers as price oracles. 4. The governance rights end up with the validator. We believe that this kind of structured cashflow will maximize the utility of stranded ATOM capital in DeFI but there is also ample room for experimentation. ---

**Author:** ![zaki\_iqlusion](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/zaki_iqlusion/32/1055_2.png) [@zaki\_iqlusion](https://forum.cosmos.network/u/zaki_iqlusion)\ **Post date:** [October 1, 2020, 5:11am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/3 "2020-10-01T05:11:39Z")

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. ---

**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 1, 2020, 5:31am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/4 "2020-10-01T05:31:13Z")

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. ---

**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 1, 2020, 10:59am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/5 "2020-10-01T10:59:24Z")

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, States and Messages ### **Parameters** - `DefaultTokenizationRatio` - The starting value of `TokenizationRatio` - This value decides how much of slashing loss can be covered by `YToken` - Lower `DefaultTokenizationRatio` results in less slashing risk for `NToken` holders - `MaturityLength` - The length of tokenization period until maturity - Longer `MaturityLength` results in - Less auction amount for each maturity - Less opportunity for `NToken` holders to redeem `TokenizedDelegation` - `TokenizationFrequency` - The frequency of delegation tokenization execution - Shorter `TokenizationFrequency` results in - Too many kinds of `YToken(V,M)` floating around - Too frequent auction held - But more diversified auction amount for each period - `AuctionPeriod` - The length of auction before entering into `SuddenDeath` mode - Shorter `AuctionPeriod` results in - Higher risk of significantly discounted auction winning price ### **States** - `TokenizedDelegation` - `DelegationIndex` - pointing the delegation object which is tokenized - `TokenizationDateTime` - datetime of tokenization - `Maturity` - the maturity datetime of this `TokenizedDelegation` - `Status` - `Tokenized` / `AuctionPeriod` / `SuddenDeath` - `DelegationAuction` - `DelegationIndex` - pointing the tokenized delegation object to be auctioned - `AuctionMaturity` - block height when the auction finalized - when 0, the auction entered `SuddenDeath` status - `HighestBid` - the bidder and bid price with highest bid price ### **Messages** - `MsgDelegationTokenization` - `TokenizationRequestor` - the account address of tokenization requestor - `DelegationIndex` - pointing the delegation object to be tokenized - `MsgRedeemDelegation` - `RedeemRequestor` - the account address of redeem requestor - `RedeemToken` - sending `NToken` and `YToken` for redemption - `DelegationIndex` - pointing the delegation object to be redeemed - `MsgDelegationAuctionBid` - `Bidder` - the account address of the bidder - `DelegationIndex` - pointing the tokenized delegation object which is under auction to be participated - `BidToken` - the bid price in `NToken` - the tokens are escrowed in the module until - higher bid is coming in - or auction is finalized ## 4. Process ### **Delegation Tokenization** - Description : a delegation with `OriginalBondedAmount` of `StakingToken` splitted into two kinds of tokens - `NToken` : Fungible delegation notional token - `YToken(V,M)` : Fungible delegation yield token for validator `V` and maturity `M` - Tokenization of `OriginalBondedAmount` of delegation → ( `TokenizationRatio` \* `OriginalBondedAmount` ) of `NToken` + `OriginalBondedAmount` of `YToken(V,M)` - Delegation Tokenization Schedule and Maturity - Delegation Tokenizations are executed `TokenizationFrequency` - `TokenizationFrequency` is a governance parameter - Users can reserve delegation tokenization for next available execution datetime - `MaturityLength` : A governance parameter which decides the length of the maturity for every delegation tokenization - Delegation ownership transfered to module account after tokenization ### **Delegation Redeem Process** - **Before Maturity** - Redeem requestor sends ( `TokenizationRatio` \* `OriginalBondedAmount` ) of `NToken` and `OriginalBondedAmount` of `YToken(V,M)` to the module account - Sent `NToken` and `YToken(V,M)` are burnt - Delegation ownership transfered to redeem requestor - Including all accumulated and automatically withdrawed rewards - Redeemed `TokenizedDelegation` is deleted - **After maturity or Automated unbonding triggered** - Auction held for the delegation ownership for each `TokenizedDelegation` - Bid token : `NToken` - `AuctionPeriod` : a governance parameter for the auction period length - Auction completion before end of `AuctionPeriod` - If `AuctionWinningPrice` ≥ ( `TokenizationRatio` \* `OriginalBondedAmount` ) : winning price is enough to cover originally minted `NToken` upon tokenization - Auction winner payout - The delegation ownership transfered to the auction winner including accrued rewards - ( `TokenizationRatio` \* `OriginalBondedAmount` ) of `NToken` is burnt - YToken(V,M) holders payout - ( `AuctionWinningPrice` - `TokenizationRatio` \* `OriginalBondedAmount` ) of `NToken` sent to `YToken(V,M)` holders - `NToken` distribution is proportional to YToken(V,M) holding shares - `OriginalBondedAmount` of `YToken(V,M)` are burnt - `YToken(V,M)` burns proportional to `YToken(V,M)` holding shares - If `AuctionWinningPrice` \< ( `TokenizationRatio` \* `BondedAmount` ) : winning price is not enough to cover originally minted `NToken` upon tokenization - Auction winner payout - The delegation ownership transfered to the auction winner including accrued rewards - Entire `AuctionWinningPrice` of `NToken` is burnt - `YToken(V,M)` holders payout - Nothing is paid out to `YToken(V,M)` holders - `OriginalBondedAmount` of `YToken(V,M)` are burnt - `YToken(V,M)` burns proportional to `YToken(V,M)` holding shares - Update `TokenizationRatio` as below - `TokenizationRatio` = `NTokenSupply` / SUM( `OriginalBondedAmount` in all `TokenizedDelegation` ) - Increased `TokenizationRatio` means the `NToken` value has been diluted - If auction has no winner after auction period? - `SuddenDeath` auction triggered - Anyone paying zero or more `NToken` will immediately win the auction ## 5. Advantages and Disadvantages ### **Advantages** - Fungibility - `NToken` is fungible over all validators and maturities - `YToken` is fungible over same validator and same maturity - No NFT is utilized - No Slashing Rate Assumption - `YToken` is firstly responsible for slashing loss - Residual slashing loss is distributed to all `NToken` by `TokenizationRatio` increment - Independent Solution - It already provides universally fungible `NToken` independently - It does not need any kind of liquidity pool utility for fungibility ### **Disadvantages** - Efficient auction participation is assumed - If the winning prices of auctions are not competent enough, `YToken` holders will get much less payout - All matured `TokenizedDelegation` are auctioned at the same time - Auction participants cannot utilize their capital into multiple auctions - There exists some capital utilization inefficiency for auction participants - Roll-over inconvenience by `YToken` holders - `YToken` holders need to buy a lot of `NToken` from the market to roll over their tokenization - To buy enough `NToken` , they have to bring significant capital - If they don’t roll over their tokenization until maturity - Auction will be automatically triggered - There exists some risk that the auction winning price is significantly lower than fair value - Lower auction winning price results in less payout to `YToken` holder - There can exist some services provided by large `NToken` holders - To roll-over the tokenization for `YToken` holders with appropriate fee - And send back new `YToken` with extended maturity to original `YToken` holder - These multiple messages can be atomically transacted in one transaction in a decentralized fashion ## 6. Discussions ### **Governance Voting Rights** - Discussions - Because the ownership of delegation is transfered to a module account, it is undecided who has the governance voting right - `NToken` is meant to be used for multiple DeFi purposes including providing liquidity to AMM, collaterized for lending, and trading activities - Most `NToken` will be held by modules, smart contracts or pegged out to different blockchains - So, it is difficult to distribute governance power to `NToken` holders - If we only distribute governance power to `YToken` holders - YToken holders locked relatively much less capital than `NToken` holders - So, it is unfair to give the governance right only to `YToken` holders ---

**Author:** ![ebuchman](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/ebuchman/32/6645_2.png) [@ebuchman](https://forum.cosmos.network/u/ebuchman)\ **Post date:** [October 5, 2020, 1:34am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/6 "2020-10-05T01:34:48Z")

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 whether it’s necessary in the base layer and whether it might create undue risks. My understanding is that our primary motivation is to defend against the centralization risk of exchanges that are offering effective staking derivates already. That’s not that high a bar (though we do have to make better UI/UX, accounting tools, etc., it’s not just about the raw on-chain ability to trade staked Atoms). There are other motivations, like improving capital efficiency and preparing staked Atoms for DeFi, and while important, it does feel like even a first order simple solution to the primary motivation can still support these secondary motivations, and more complex derivatives can be built on top later as the Cosmos DeFi system starts to mature and demand it. So basically I’d be proposing, at least for consideration to clarify the design space here: - convert all rewards/fees into Atoms with on chain AMM - autobond all rewards/fees - tokenize the existing validator pool share as the staking derivative, fungible per validator - consider building more complex multi token designs (ie separating collateral from cash flows) in future iterations, either through VMs on the hub or on zones, or in the base layer on the hub once there’s more confidence/demand Come to think of it, if we do want to stick with two derivatives tokens, does converting to Atom and autobonding simplify the design of perpetual yTokens (ie. without needing to worry about maturity?!) ---

**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 5, 2020, 10:08am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/7 "2020-10-05T10:08:20Z")

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 ---

**Author:** ![ebuchman](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/ebuchman/32/6645_2.png) [@ebuchman](https://forum.cosmos.network/u/ebuchman)\ **Post date:** [October 5, 2020, 12:13pm UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/8 "2020-10-05T12:13:41Z")

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

**Author:** ![zaki\_iqlusion](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/zaki_iqlusion/32/1055_2.png) [@zaki\_iqlusion](https://forum.cosmos.network/u/zaki_iqlusion)\ **Post date:** [October 6, 2020, 2:10am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/9 "2020-10-06T02:10:00Z")

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. ---

**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 6, 2020, 3:41am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/10 "2020-10-06T03:41:30Z")

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! ---

**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 6, 2020, 3:46am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/11 "2020-10-06T03:46:58Z")

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? ---

**Author:** ![ebuchman](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/ebuchman/32/6645_2.png) [@ebuchman](https://forum.cosmos.network/u/ebuchman)\ **Post date:** [October 6, 2020, 3:40pm UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/12 "2020-10-06T15:40:52Z")

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 one piece of the pie. ---

**Author:** ![zaki\_iqlusion](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.cosmos.network/zaki_iqlusion/32/1055_2.png) [@zaki\_iqlusion](https://forum.cosmos.network/u/zaki_iqlusion)\ **Post date:** [October 7, 2020, 5:07am UTC](https://forum.cosmos.network/t/delegation-tokenization-module/4011/13 "2020-10-07T05:07:12Z")

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.