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 recognize this. The right to issue more Reward Tokens or unbond only comes upon maturity. Our proposal incorporates this into the denom.
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.
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.
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.
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.
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.
bonding-token : auto rebonding
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.
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 one piece of the pie.
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.