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 mints FToken(V) and YToken(D) and sends to the delegation tokenization requestor
      • Number of FToken(V) minted : BondedTokenAmount(D) * TokenizationRatio(V)
      • The unique NFT YToken(D) representing the reward rights on this delegation D
  • Transfer ownership of YToken(D)

    • YToken(D) can be transfered to others via MsgSendYToken
  • Delegation redemption process for any TokenizedDelegation

    • Two redemption processes available

      ① By sending both FToken(V) and YToken(D) into the module account

      • Redemption requestor receives both the delegation ownership and accrued rewards of D
      • Both FToken(V) and YToken(D) are burnt after redemption
      • Available period : this process is available any time

      ② By sending only FToken(V) into the module account

      • FToken(V) sender only receives the delegation ownership without accrued rewards
      • YToken(D) owner receives all accrued rewards from the redeemed delegation
      • Both FToken(V) and YToken(D) are burnt after redemption
      • Available period : this process is only available after the maturity of targeted TokenizedDelegation
    • Number of FToken(V) needed for redemption of delegation D : BondedTokenAmount(D) * TokenizationRatio(V)

  • Slashing event hook

    • Definitions
      • TotalBondedTokenAmount(V) : the sum of total BondedTokenAmount in TokenizedDelegation staking to validator V
    • Update TokenizationRatio(V) upon every slashing event from validator V
      • TokenizationRatio(V) starts from 1
      • TokenizationRatio(V) is updated to FToken(V)Supply / TotalBondedTokenAmount(V) everytime when slashing happens from validator V

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

    • TokenizationRequestor
      • the account address of tokenization requestor
    • DelegationIndex
      • pointing the delegation object to be tokenized
  • MsgSendYToken

    • Sender
      • the account address of YToken(D) sender
    • Receiver
      • the account address of YToken(D) receiver
    • DelegationIndex
      • pointing the delegation object which YToken ownership is being transfered
  • MsgRedeemDelegation

    • RedeemRequestor
      • the account address of redeem requestor
    • RedeemTokens
      • option1) sending FToken(V) and YToken(D) for redemption
      • option2) sending FToken(V) for redemption
    • DelegationIndex
      • pointing the delegation object which YToken(D) ownership is being transfered

4. Discussions

Governance Voting Rights

  • Problem

    • Because the ownership of delegation is transfered to the module account, governance voting right is unavailable
  • Discussion

    • Who should get the governance voting rights?
    • How we can effectively prevent vote buying?
    • How we can allow governance voting without any inconvenience?

Universally Fungible FToken

  • Problem

    • FToken(V) is only fungible over the same validator V
  • Suggested Solution

    • Hub AMM expansion to Curve.fi like pool model
      • A FToken pool where users can swap any FToken(V1) to any other FToken(V2)
      • The PoolToken which represents the share ownership of the assets inside the pool
    • This PoolToken can become the universally fungible FToken across the validators

NFT Compatibility over IBC

  • Problem

    • There exists no standard NFT object which is compatible over IBC
    • YToken cannot be transfered to different blockchains via IBC
  • Solution

    • After we have standard NFT object supported by IBC, this module can be upgraded so that YToken becomes IBC compatible NFT object

Marketplace for Trading YToken

  • Problem

    • There exists no way to trade YToken in fully decentralized way
  • Suggested Solution

    • NFT DeX
      • Hub AMM can be expanded to NFT DeX which allows fully decentralized NFT marketplace

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

  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.

1 Like

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

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

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

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?

1 Like

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.

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.