**A** (0:00):
This is a. So this is a post I have. It's in the like Cosmos forum there. It's called Design for Fungible Staking Derivatives. And it's very much, you know, it's a design for how to do the native variant of staking derivatives. And it sort of is meant specifically for the Cosmos SDK because it's designed in such a way that it handles a lot of the oddities that show up in the Cosmos SDK, which I'll walk through now and hopefully make sense. So the forum post is a bit difficult to understand. And so that's why I hope this walkthrough can make it a bit, allow people to understand it much easier. Okay, so the first thing we're going to start off with is at the hack Adam Berlin last summer course on SIKA came up with this delegation vouchers system. And I'll quickly walk through that just for the basics and then, so that way if. And then I'll show you why it doesn't quite work for what we want to do in the Closet hub and then how we go about fixing it. If anyone has any questions, please, like interrupt in the middle. Yeah. Okay, so this is the delegation voucher system. So let's say a user wants to go ahead and delegate some atoms to the validator. What they would do is they could go ahead and delegate 100 atoms and what you do is you get back some certain number of shares. Most of this accounting is actually what's already happening in the staking module of the Cosmos hub. But all we're going to do, the main change we're doing now here is instead of shares just being a number that's accounted for in the right now, each delegator's shares is just number accounted for in the state of the staking module. Instead what we would do is, would actually be a token that's returned to the user. So now they have 100 shares of that validator and we keep track of the conversion ratio between atoms to shares. And so that way if another user comes in and deposits 100 atoms, they also get shares back at the same atom to share ratio, so they'll get back 100 shares. So now there's a total of 200 atoms in the pool and 200 outstanding shares. Now let's say there's a 50 atom reward that was added so you know, the dollar that are staking. And now there's 250 atoms in the pool and only 200 outstanding shares. What this means is that the conversion ratio now has increased to 1.25 atoms per share. Just the number of atoms over the share over the outstanding shares. So what this does is when one of the users says, okay, you know what, I want to unbond half my amount, right? So I have 100 shares. I'm going to unbond 50 of them. So it will go ahead and return to the user atoms at that conversion ratio. So now there's only 187.5 atoms left in the pool. But because it gave 62.5 to the user, but the number of shares also went down because the user unbonded or burned 50 of those shares, you'll notice that when people bond or unbond, it doesn't ever change the conversion ratio. Conversion ratio only changes when the validator gets rewards. Or if it slashes, it gets slashed, right? So if the validator gets 100, like let's say you got a slash of 100 atoms, right? It suddenly dropped the current number of atoms in the pool from 187.5 to 87.5, but the number of outstanding shares is still the same. So all that we did now was change the conversion ratio. And so, you know, let's say the user tries to unbond 50 shares, they'll get back a much lower amount of atoms than they did earlier because conversion ratio has decreased due to slashing. So whenever there's rewards, the conversion ratio is always going to be increasing. And when there's a slash, the conversion ratio will decrease. But now here's where the problem comes in. What happens? In the Cosmos SDK, we've designed it such that fees are meant to be able to be paid in any asset that you desire, right? Or any, at least any whitelisted fee token. And so what happens if the reward is in some other asset other than atoms? Right? Let's say it's in 100 photons. Not that we know what photons are yet, but let's say it's in 100 protons. And now what does this mean? Like, the current pool has atoms and photons and the shares, but the conversion ratio, like, does that mean that the conversion ratio is 0.58 atoms and 1 photon per share? And does that mean when you want to bond, you have to put in 100 atoms and some photons? Like, it doesn't really quite, you know, it doesn't really make sense. Once you start putting other stuff into the pool along with the atoms, then you don't really know what the conversion ratio means anymore. And this is important because you know, let's say someone. Yeah, okay, so you know, to solve this, that's why in the Cosmos SDK we developed this thing called the F1 Phi distribution. And if anyone is part of the game of stakes last year, you might know this thing because it was causing a lot of bugs and stuff. But essentially the key of what it's doing this is what the delegation struct looks like. But what the F1 fee distribution does essentially is it keeps track of what happened when a specific validator rewards are not automatically rebounded. One thing you'll notice is in the voucher system this is essentially auto rebonding Rewards. But in F1 it doesn't auto rebound the rewards and keeps track of, let's say the reward pool for a certain validator has 500 photons in it at time 5 and then you bond into that validator at time 6. The F1 feed distribution system makes sure that you are not entitled to those 500 photons. You don't get a share of those photons. You only get a share of the tokens that enter the reward pool after you bonded. And this is sort of, and conversely it also makes sure that if there was a slash that happened before you joined, then you don't get punished for something that your atoms are not going to get slashed if you join afterwards. So that's what the F1 fee distribution does. And we kind of need this to, you know, if we want to have multi fee tokens, if we want rewards to be able to be paid in multiple tokens, which is, you know, especially when we start to get to like shared security stuff, I imagine that's, you know, that that's going to be very necessary I think for the UX of the shared security model to work. And so, so this is sort of what I, how I kind of structure my things. I have my pseudocode so I have these constants. These are the constant fields of a struct. You have the variable fields and then you have the capabilities or functions like what can you do? If you are the owner of that struct, what can you do with it? So the thing that's important here is the reason that these are non. You can read the F1 fee distribution spec here. So what we could say is, hey, what if we just turn this thing into an asset? So this is the delegation struct that is already in the state of the staking module. Why don't we just turn this into an asset? So that way instead of it be like, you know, instead of the from ballot from delegator being in the state, saying like, you know, saying, okay, who owns this? It's, you know, this person. What if we just make it into an nft, right? Where whoever is the holding, the NFT is the delegator, right? So if I give it to someone else, then they would become the delegator. So why is this non fungible though? Why is this non fungible though? It's non fungible because of that last withdrawal time that the F1 fee distribution needs. So because, you know, let's say I delegated to, I delegated to Sitka at, you know, time 10. Last time I withdrew was time 10. But let's say someone else, Felix, delegated to Sika and he hasn't withdrawn his rewards since time zero. Right? The fee distribution system has to keep track of when was the last time each person withdrew their rewards. So that way when Felix withdraws, he'll get more rewards at that time because it has to also give him the pro rata rewards for times 0 to 10, while if I withdraw, it'll only give me the pro rata reward from my last withdrawal time to the current time. And so because of that last withdrawal time is different for every delegator. These delegation assets are non fungible. And what is the issue with them being non fungible, right? So you know, you can trade them otc, which is fine, right? Like, you know, I could go up to, you know, Brendan, I can be like, hey, look, here's my delegation's nft. You can see how many items on there, you can see how many ones the last time I withdrew. And you know, we can come up with our deal ourselves, but you can't put it really into like a uniswap style thing because they're non fungible. Or you know, it'd be even really, even very difficult to put them into like an order book like exchange as well. It really only works on like a OTC system. And it's also much more difficult to reason about and thus much more complex to use in defi. So imagine like, you know, kava CDPs. We wanted to use these as collateral in the CDP. We'd have to make, we have, you know, price oracles would have to give the value of each of these delegation NFTs separately because they're going to have separate values because their last withdrawal time is different. So, okay, so here's solution number one. What we're going to do is we're going to keep, we're actually going to keep a Delegation struct in state. But we're going to create a separate asset called a delegation claim, which is still an NFT for the moment, but we'll explain how to get that finish turning it fungible. But for now it's an nft, but what it does is it refers to a specific delegation in state. So. And what you can see is the functionality it has is this ability to change the withdrawal address. So let me walk through how that works. So let's say Alice wants to delegate to this validator, validator A, right? So she'll go ahead and say, okay, I'll delegate 100 atoms. What will happen is in state, it'll create a new delegation object, which let's say the ID is A1. It's the first delegation to validator A. It's to validator A. The withdrawal address is Alice. It's 100 shares. And the last withdrawal time was time 50. Now let's say it's time 100 now and the validator has accumulated some rewards. So Alice can go ahead and say, okay, withdraw. It will send her back some rewards and it will update the last withdrawal time to 100. Now let's say she wants to unbond 50 shares. It could do that as well, you know, it will unbond 50 atoms and it will reduce the number of shares that still all works the same. Now what happens when she wants to sell this asset? She wants to sell ownership of this asset. What she can do is she can go to Bob and basically sell her the NFT. That is a claim on delegation A1. Now Bob is now the owner of this and he can go ahead and unbond if he wants, and he'll get out 10 atoms. Great. So now the shares went out, went down by 10, and he got back 10, 10 atoms. But let's see what happens when he tries to withdraw. He says, okay, I'm going to withdraw. Rewards the best with all time went up. But you'll notice that the withdrawal address is still alice. So the rewards actually get sent to Alice. So what actually needs to happen is when Bob receives the asset, he needs to first say change withdrawal address. And what this does is it first takes all the rewards that have been accumulated thus far, gives them to the last withdrawal, to the withdrawal address, which is currently still Alice. Then it changes the withdrawal address to Bob and it resets the last withdrawal.
**B** (13:59):
Time.
**A** (14:03):
He can withdraw. And so what does this mean? Like, why are we. What, like this makes it so it doesn't matter which. And let's say you have two. Let's say you have the option to buy the delegation claim from Alice or Charlie, right? And they both have the same number of bonded atoms. Let's say it's 100 shares, right? But Alice has not withdrewn in months, while Charlie has withdrawn just yesterday. Right. In the previous system, you would want to buy Alice's, right? Because there's more rewards there. But what we've done here is it doesn't matter whether you buy Alice or Charlie's claim, because when you buy either one of them, the the first thing you do is you change the withdrawal address by sending that function and then it takes all the rewards that have not been claimed yet and gives them to Alice or to Charlie. Then you only start to start accumulating the rewards from the point after you call change withdrawaladdress. What this does is it makes both of these assets fungible because they both have the same capability, which is to start accumulating rewards. It doesn't matter what rewards are already been accumulated to the past owners because those will get given to the past owners. And so that kind of makes them both sort of fungible. Now, this change withdrawal address, I mean, one of the cons of this is let's say you have so the struct is on the Cosmos hub. Let's say we're staking on the Cosmos Hub, but we're on a separate chain, right? And we move that nft. Alice has moved that NFT onto a separate chain. She can sell Bob the delegation claim. But the problem is Bob is not gonna start earning the rewards because the withdrawal address is still Alice on the Cosmos hub. So he actually does need to IBC it over to himself on the Cosmos Hub, change the withdrawal address. So now it gets set to Bob and then he can send it back to himself over there. So this is one of the more. It is kind of a little bit annoying that you have to do this, but this is how it has to be done so that the withdrawal address in state, you have to be able to update it. The question is, do you always need to change the withdrawal address? I would say not always. So sometimes let's say you're trading really quickly, right? And let's say you're on this other chain and you're just trading really quickly on like uniswap, you're doing some arbitraging or something. Maybe it's not even worth changing withdrawal address because like the amount of time, the amount of rewards you get in the time that you're like holding the Asset maybe it's actually barely any rewards. Like not maybe you're trading these on like a minute to minute basis. So maybe the rewards aren't actually worth that much really. It's like the potential for someone else to buy that asset and start claiming the rewards themselves is what gives it value. And so maybe it might not even be worth like the IBC fee to do that. Weirdly so for the buyer, like I said, it doesn't matter to the buyer, it's the ability to change withdrawal address that makes it valuable for the seller. It is sort of in this weird kind of like it's a little bit odd because it is in the seller's incentive to sell to a lazy buyer who will be slow to make the change. So let's say I'm Alice, I, you know, I can sell to Bob or I can sell to Charlie. And let's say I know Charlie is like really lazy and he, you know, he's not gonna actually go and like update the withdrawal address for like a few days at least. I would rather, and Bob, I know, you know, he's on top of his thing, he'll go do it immediately. Weirdly enough, I'd actually rather sell to Charlie because for those few days he takes to update his withdrawal address, I'm actually earning extra rewards even after selling the asset. But really the fungibility really comes from the buyer's perspective because usually it's the, if you think about it, in a uniswap market, as long as to the buyer it's the same. That's what really sort of matters. So and if you are long term holding an asset, then yes, it is worth going to change the withdrawal address. Okay, so great, you know, we're almost done. The only problem is here it's still a non fungible asset because the withdrawal address isn't what matters anymore. It's only now non fungible just because the shares are different. Right. Let's say, you know, Alice has delegated with 100 atoms and Charlie has delegated with 50 atoms. Obviously their delegations are not worth the same amount and thus their delegation claim can't be worth the same amount. So to make this fungible, we want to turn these into tokens. And so what we can do is the final iteration of this model is we say, okay, we're still doing the delegations in as a struct in chain. We're going to stop calling it the withdrawal address, we're just going to call it the owner now we're going to create this delegation Share token. You can think of this like a denom. The denom will be like. It'll be like the delegation owner name concatenated with the validator name. These are the capabilities you get when you own the delegation share. So once again, let's walk through it because I'll probably be much simpler. So let's say Alice, she goes ahead and delegates to Sika here, right? So she'll go ahead and delegate 100 atoms. And what she'll get is. Can everyone see the thing at the bottom or is it blocking it?
**C** (20:22):
Shares.
**A** (20:22):
Yeah, okay, cool. Yeah, yeah. So, yeah, so Alice gets. Yeah, sorry, my zoom thing was blocking the bottom of the screen. Okay, so Alice gets a. So when she delegates 100 Adams, she'll get 100 Alice Sitka shares. And in state there will be a state object that says, okay, there's this delegation object. The owner's Alice. It's two validators, Sicka. The shares 100. And the last withdrawal time is 50. What she could do is she could sell 50 of those Alice Sika shares to Bob and she can go, and if she tries to, you know, now she'll say, okay, I'm going to unbond 100 atoms. The system will be like, no, no, no, you can't do that. You only have 50 Alice Cica shares. So when you unbond, you have to actually, you know, burn your atoms a lot you your shares along with it. So now she'll say, sorry, the text here is wrong. It should say unbond 25 Aliceka shares. And then it will decrease the number of shares by 25. Now Bob can once ahead, similar to the change with all that is now we just call it change owner. He'll say change owner and pass in 50 Alice Sicka shares. And he'll burn those tokens. And what that will do is it will create a new delegation structure in State with 50 shares. So it decreases 50 shares from Alice's. So now she's back down to 25 and it creates a new one for Bob. And now Bob gets 50 Bob Sitka shares. And so these represent claims on that delegation. And the rest of it still works sort of exactly the same. The rewards now are kind of just done based off your own last withdrawal time and whatnot. So two pesky problems in this one. It's that tokens that are in an active. Wait, sorry, really quick, before we go that. So you'll see that these Alice Zika shares and Bob Zika shares, while they are separate assets, right? They are separate denoms. They are still like truly fungible with each other. They both because let's say I once again, I'm Charlie. I can buy 25 Alice shares or I can buy 25 Bob Sika shares. It doesn't matter to me. I'll buy either one. Because as soon as I get them, my intent is just to go and change the owner of them and create a new delegation and to go create 25 Charlie sick of shares. And so one thing we'll have to do in the Cosmos SDK is provide abstractions around denoms such that you can. I have an issue open for this in the Cosmos SDK where you can basically say that both these two different denoms both share the same property. And so let's treat them the same for this purpose. So for example, let's say you have a uniswap market, right? You want it to be, I don't know, Dai to Sitka shares. So you'd make it in that uniswap market. So it's, it doesn't care whether it's getting Alice sick of shares or Bob sick of shares or Charlie sick of shares. It will just care that it's getting Blank sick of shares. And so that does require some modification, like some updating to how assets work on the SDK. So yeah, two pesky problems. One is if a token is currently in an active redelegation from another validator, let's say so I can. So when I, when I do these tokens, not only can I unbond, I can also redelegate, right? So I can turn Bob Sicka shares into. So Bob can turn Bob Sicka shares into Bob Chorus shares. He just has to call a chain, instant redelegate and Pass in his 50 bob sicker shares and goal mint him a new delegation struct where the owner is still Bob within the two validator is Chorus. The problem is when you're, you know, when you're in this active redelegation, for the period of one unbonding period, you are slashable for both the validators faults. So if sick of faults, you're slashable for them. And of course faults, you're slashable for them. And thus these for that short period of time, for that first unbonding period, the Bob Korus shares are not fungible with other, you know, Charlie Kor shares who may while. Because Charlie may have been delegated to Chorus for ages. Right? That's one. And number two is that newly bonded tokens are not subject to slashes that happen before they start bonding so Bob changes to chorus and chorus had slash at block 10, but he changed at block 15. And so there's some weirdness around that. So the simple solution to both of these problems at once is just say a delegation cannot issue derivatives until it has been bonded for at least one unbonding period. So let's say I bond tokens to chorus. I have to wait three weeks before getting the derivative, the shares of them and same with an instant redelegation. If I rebound from chorus to state capital, I have to wait three weeks before I get the state capital shares. Yeah, that's about it. Thanks.
**B** (25:54):
That was great, Sunny. Thanks. Really clear. Can you just go back to that last data structure there? The very last solution?
**A** (26:03):
Yes.
**B** (26:06):
So this owner is down as a constant there for the delegation share.
**A** (26:13):
Right, but it's not constant. We're no longer changing the owner of a delegation struct when. When you change owner, but we're rather just creating a new delegation struct.
**B** (26:24):
Okay.
**A** (26:26):
And so that way, let's say Bob had bought all of Alice's tokens and decided to change the owner of them. It will just. Once Alice's struct hits zero shares, it'll just be like pruned from state. So it'll just disappear.
**D** (26:47):
Okay, I have one question which is like why do you need the last withdrawal time? And whenever someone is transferring their delegation shares, why do. Why do they need to, you know, like change the last withdrawal, the withdraw address? Basically because you know, you can keep the withdrawable tokens in a separate pool so that the validator pool tokens can be fungible and easily transferable.
**A** (27:18):
Sorry, can you repeat that? I didn't quite understand the question.
**D** (27:22):
So instead of having the withdrawal address, you can keep those with like withdrawn token into a separate pool. So then like let's say if Bob is transferring 50 tokens and he like he has withdrawn like let's say 50 tokens already, then you don't need to have the last withdrawal time or withdraw address. Basically because these both are separate pool and he can just transfer the 50 tokens which are already bonded.
**A** (27:50):
One of the key designs of the fee distribution in the Cosmos SDK is that when reward. So like the rewards for two Alice, like so the rewards of the sick of pool. Right. Are actually all in one pool together. The ALICE rewards are not kept separately from the Bob rewards and. Right, and so that's why you need the last withdrawal time to do the account. Because we do lazy accounting, we don't separate them, we just take. We use the last withdrawal time to calculate how many rewards from the overall pool should go to Alice. That's why, you know, we need to keep track of that last withdrawal time. We don't want to when, when on a blockly basis. We do never want to be iterating over all delegators to distribute rewards to them.
**D** (28:47):
I think not. Not really. Because like if I understand the conversion rate it will have, it should handle the, the part where you don't need to have the last withdrawal time.
**A** (29:03):
Where like there's no. So there's no more conversion rate happening. Right. So for now we're assuming that all rewards are going in. So there's a separate delegation pool versus the reward pool. Right. So because we're not auto rebonding atoms now in the final, in this version here, then the one to one between shares and atoms is always one to one.
**D** (29:29):
I might be misunderstanding something. So let's say we have two variables for one, one validator delegations.
**A** (29:35):
Right?
**D** (29:36):
So which is like the one is active stake, which is bonded atoms and another one is reward. So whenever there is like whenever. So let's say for whatever reasons the rewards come, you just keep adding into the rewards. So now you have active stake plus rewards divided by whatever shares you have minted.
**A** (29:57):
Yeah.
**D** (29:58):
So in that case you don't need to like keep track of last withdrawal time.
**A** (30:02):
No, because let's say Alice, let's say. So let's say there's 100 tokens in the pool, right? Alice decides to withdraw her rewards right now, right? So she gets 50 of them, right? And so now. But she still has 50 shares, right?
**D** (30:24):
Oh, I see.
**A** (30:25):
I see. And so now let's say later on there's another 50 items re added to the reward pool. She can't go ahead and say oh, I have 50% of the shares, let me withdraw another 50. Because no, she only gets actually is deserving of 25 of them right now because a previous 50 are owed to Bob and then half of the new atoms, 25. So Bob is actually entitled to 75 of them. Does that make sense?
**D** (30:55):
Yeah, now I get it. So in that case, like why don't you just burn the shares?
**A** (30:59):
Actually because the shares are shares of the bonded pool, not of the reward pool. So when you withdraw rewards, you don't burn shares.
**D** (31:12):
I understand it. So in, in my design, what I did, what I did was basically so let's say initially you bought a hundred token hundred shares. So so let's say whenever you are withdrawing something. So right now let's say the exchange rate is 2. So for one token, one shares, it's 2. So let's say you are withdrawing hundred shares then. Sorry, hundred tokens, then I'll burn for 50 tokens actually. So in that case we don't need to manage the last withdrawal time.
**A** (31:43):
So the design that you seem to be describing is the original delegation vouchers from last summer. But the problem here, like I mentioned, is it only works if all rewards are in the staking token, which might be the design of the. But for the Cosmos hub we, you know, it was very much a design decision. Like as far as I understand, it's still probably a design decision that want rewards to be able to be paid in other tokens other than atoms.
**E** (32:17):
Yeah, so if I. So I also just wanted to talk a little bit about because you know, after we worked with CICAD together in last June, you know, we talked about this issue and there was a hackathon, another hackathon in July and we kind of, you know, took a different approach to solving sort of the same problem. So I also just wanted to explain a little bit what we did back then. So you know, as Sonny pointed out, like the original design works kind of, kind of very nicely where you have to share and then you have this atom pool that gets filled up and anyone can take any of these shares to perfectly fungible and just redeem it for the safe for this accumulating atoms and you can take it to other chains, you can use it there, there's no need to like bring it back, there's no need for withdrawal adders and those kind of things. And you know, as Sunny pointed out, this kind of starts falling apart when you have basically the income starts to be in like various different tokens. And you know, I guess this will depend a lot on, you know, what's the network, what's their goal? And you know, if they do want to have fees in various different tokens, but you know, presumably some will. And for Cosmos there's very much the idea, right, that if you, if you're routing basically packets of tokens across many networks that you can pay this native token of whatever you're writing to. So then totally is the case that in Cosmos it will make sense to accept fees be paid in various different tokens. And so then you have this challenge here. So we thought there is a sort of a very elegant way of solving this problem as well as another problem that I'll get to in a second in that way is basically to say all of those non atom Rewards, they go into kind of a separate pool and they're auctioned off on chain for atoms. And that sort of happens, you know, continuously, automatically. And you know, the frequency that this, the frequency that this happens would depend on, you know, kind of like how much those VWAP revenues would be. So let's say it's like 0.1% of the rewards that, you know, atoms represent block rewards, right? Then probably doing it like once a day will be fine. So what happened then is that, you know, when this auction happens, you just have some additional atoms that get paid into, into this reward pool and it basically makes no difference for these shares. It's not noticeable. Of course there is a little bit that effect if you have this kind of mechanism that you have with shares of companies as well, where you know, if you own a share like right before dividend gets paid, it's worth a little bit more than afterwards. But here, you know, you would essentially have sort of dividends from like non Adam income, but you could pay these dividends, you know, on it on a daily or maybe every few hours or something basis. So this effect is going to be so tiny it will be, you know, it could be ignored. And so then you just have these extra rewards, right? And then basically the old design works and you know, there's much more simplicity with the design. You know, you have perfectly fungible tokens, there are no NFTs, there's no withdrawal address. And so I think there's a great benefit from that side just in terms of keeping it very, very simp. But there's also a great benefit if you look at it from another perspective, which let's say you are now staking atoms on the Cosmos hub and you're earning atom rewards. And you know, that's nice, right, because like that's what you bought in the first place. So getting more of them makes a lot of sense. But let's say you're also earning like some other tokens and maybe down the line you're going to have like 5, 10, 50, 100 different tokens that people pay fees in. So what you essentially start to have is that all of these delegators are going to get like minuscule amounts, basically dust in like lots of different tokens. Of course that's like a nightmare. Like you don't want to have atom rewards as well as 100 different tokens in these tiny amounts that then you have to go and try to convert into some token that you actually want. So I think from also a user experience perspective, you don't actually want.
**B** (37:12):
To.
**E** (37:13):
Get rewards in like lots and lots of different tokens. It's much nicer if you just get more atoms. Of course this is all a little bit specific to the Cosmos Hub and sort of to the specific use case that the Cosmos Hub is trying to fill. But that's kind of the alternative approach that one could take. And for these on chain auctions you could use something like Uniswap. So it would be very simple to do that. And yeah, that's also something we built in a hackathon in Seoul last year. So yeah, I just wanted to share that kind of as a sort of another version, another alternative design for the allegation modules that we did some work on.
**A** (37:59):
Right.
**F** (38:02):
Sorry, go ahead.
**A** (38:03):
Oh no, yeah, I have some questions.
**F** (38:07):
In regards to fungibility cost validators. So like the basis of validator fungibility. So like the value is equal because you basically can switch validators for these delegation vouchers. Right. But I was just kind of wondering. Sorry, go ahead.
**A** (38:29):
Well, it's not, it's not. The goal here was fungibility between ALICE shares and BOB shares. It was not about fungibility between validators and it's not really intended to be fungible between validators. I mean it will be a little bit because of that instant reallocation because you can buy Alice Sicka shares and change them. Alice Kor shares. They're close to fungible, but they might be slightly different because of slashing risks, which is what you want. You want these to not be fungible because you want the shares to be somewhat reflective of the stashing risk of each validator.
**F** (39:12):
Yeah. And just kind of as a follow up question to that, like do you think these shares because we have specific to the Cosmos hub, there's a limit of like 6, 7 redelegations as far as I understand. So you know, obviously a specific validator sure would be. Could be less in value if it has been. It's in that part of that six redelegation period. Like so that would have to account for that as well.
**A** (39:39):
Well, this is why I. This kind of goes back to this piece of, you know, let's just make it so if you're in. If you're. If you've been bonded to a validator for less than an unbonding period. Just no shares at all. That way we get rid of all cases. Okay, cool, thank you. I realized I actually forgot this one slide. Basically a couple of things is one, we can still here I actually said I made it so that. Okay. You know, new rewards are going directly into the reward pool. But there's no reason actually in this design why you can't still auto rebound all atom rewards and allow other token rewards to use the F1 fee distribution. So that's completely okay. Still we would need to decide whether peripheral capabilities like voting. Right, like your voting rights. Is that so? Let's say you're in this case, right, Where Alice has already sold some 50 of her Alice shares to Bob, but Bob hasn't called change owner yet. Does Alice only have the voting rights of 50 Adams or does she have the voting rights of 100 atoms? That's a decision that has to be made. I mean it can go either way. I personally think that she should get all of the voting rights until Bob changes owner. But that's my opinion. Two, we can probably make it so the transfers that happen on the hub itself automatically cause change owner. So when Alice sends to Bob, it could just trigger a hook that automatically changes the owner to Bob. So that way you only have to manually call change owner if you're doing the transfer on a different chain other than the hub. And then finally we should add a time lock module. So if we're just kind of like not specific to this design, but this is just the query for something for like all staking derivative stuff where if we're having staking derivatives, we should have a system where let's say as a validator operator, I want to show that I'm long term bonded. I can take my derivatives and put them in a token lock module which basically prevents me from moving them for like, you know, it basically re inserts me into a, into a forced unbonding period. Like so I can't move them for at least like three weeks notice or something like that. So that's a separate point. Yeah. So you know, I agree that. So I think that you know, either this model or the auction model to me seems like the right way to go. I do see the benefits of, you know, not having so much dust and stuff and all these different tokens. But at the same time then we do in that case we do have to guarantee that there is a market for people who are, you know, buying from the auction. So you need a set of, you know, a participant like set who's willing to buy play those auctions.
**E** (42:33):
If there's value then yeah, total, right.
**A** (42:37):
Yeah. But it comes to how liquid it is, right. Because if there's less people playing that market then the VAL and not actually buying the they might be buying from the auction at a discounted price, which means the validators are getting less atoms than the tokens, the fee tokens that they sold off for.
**E** (42:57):
Yeah, sure. I mean maybe if it's very liquid, it's like, let's say it's a discount of 10% or something. I mean as soon as it gets substantial amount, I'm sure there would be this and that's much less. But even if it's this kind of 10%, you know, that's probably still economically better for me as like a delegator than if I get like lots of little coins and then I have to go and like transfer them somewhere. I'm probably gonna pay more in fees and certainly in hassle to do that.
**A** (43:31):
Yeah, you also need, you also need a fairly liquid amount of atoms. That's the other thing which you know, maybe not a big, big issue, but you will need liquid atoms. My issue is less with the fees on the hub, that my issue is more when we get to shared security. I imagine that like a chain that's being shared security might want to give some of its rewards in its native token. And so that's where I think that the issue becomes a bit greater than in the fees.
**B** (44:08):
Sunny, there's a few questions about sub keys there in the channel. Do you want to just introduce the idea of sub keys and maybe talk a bit about how sub key functionality could help this design, you know, make it more flexible.
**A** (44:27):
So as far, you know, so the whole sub key stuff has gone quite a bit like progressed quite a bit since I worked on it. But you know, sub keys are pretty independent design like thing in my opinion. But essentially the idea of sub keys was just that an account can provide, can provision additional keys other than its master key to do different functionality. So I can basically if I want to provision a new key for, you know, I don't want, you know one of the annoying things about like, you know, participating in Cosmos Governance is I have to like, you know, Dave and I have this like complex multi sig procedure to sign all transactions for security reasons. But it's really annoying for like governance voting. It'll be nice if I can provision a specific key that all it's able to do is vote in governance and nothing else. And that one I can keep a little bit more hot. And so that's what the sub key system is designed to do where like our validator account, it could say, okay, this key is allowed to do voting only transactions. There might be ways where it relates to this where maybe you know, One of the ways that, you know, one of the things that you might really want is a provision, a new key that all it's allowed to do is call withdraw rewards. Because that way you could just constantly maybe you can only call withdraw rewards and rebond. So that way it you can just have that as a hotkey and every like you can keep that on your phone if you want to. And you can, you can just like regularly just withdraw rewards and then rebound the rewards as as a stake. So that's something that kind of helps with the sub keys, but for the most part it's a pretty independent thing to this.
**B** (46:10):
Okay, Hyung, do you want to jump in there? I see a few comments just related to the sub Q functionality. Do you see this working in a different way?
**G** (46:24):
Okay, so one of the expansion of sub key from our team is to build a sub key which does not have original private key, but only having a member key. So it's a sub key only sub key, but does not have a main private key. So if you have only one member key, then a transaction to change this member key can be seen as a transfer of ownership from myself to another one. So that is our analysis of applying this sub key thing to transfer locked assets. So if you can send the ownership of an account to another person, then you can trade this assets. So you can just trade this account against some liquid assets. So that is our approach to make locked asset which is one of the locked asset is delegation. So that is how we approach to liquidate this or locked assets.
**A** (48:02):
How would you use this in a defi sense though? How do I assetize the ability to change the sub key ownership? One of the goals of the staking derivatives is you want to make it easy to use in defi purposes.
**B** (48:22):
Yeah.
**G** (48:23):
So we already built a POC of OTC market to trade a staked atom against liquid atom. So the trade will be done via atomic swap. One side of atomic swap will be transfer of ownership, the other side will be a transfer of liquid atomic. So if both sides agree about the contents of the agreement, then they can build an atomic transaction so that this transaction will execute these two directional transaction at the same time.
**A** (49:08):
Right. So like I said, I can see how this works in an OTC style system. Right. And so this kind of what, what this is is essentially it's an NFT model of doing this. But the problem with the nft, how would I put this into a uniswap contract for example? Or how would I put into an order book? Or how Do I get Kava CDPs? How do I get the price oracle data of each of these NFTs independently?
**G** (49:38):
Yeah, so this solution does not solve fungibility issue. So each of the account is like an nft, it's non fungible, so we cannot solve any fungibility issue.
**A** (49:56):
Right. And yeah, so if we don't want fungibility, there are like easier ways. We can actually do something much simpler like one of these earlier models, but where we just. This would actually be a very simple, simple change where we already have this struct in state, we just have to turn it into an asset where get rid of the from delegator as in state and just say, okay, it's whoever holds the asset is the delegator. That's pretty simple to do and probably safer than transferring ownership of an entire account because there might be other things in that account you don't want to transfer ownership of. But for me, the fungibility is a key design goal because I really want these things to be usable in different defi applications. Yeah, I agree.
**B** (50:53):
Okay, I'll try and get a couple more questions. And I know we're getting short on time here, so Colin's asking about can we separate out the rewards? So I would keep my stake tokens, but I'd be able to sell on the rewards somebody else. I think this kind of goes back to what Felix was talking about earlier of an interest rate swap. So I'm basically selling the rewards onto somebody else, but keeping the actual asset. Sony, how do you see that fitting into this model? Or you think that's a completely different design?
**A** (51:25):
Yeah, sure. So this is actually one of the things we were thinking about back in Berlin. But the problem is then the reward vouchers would still have to be NFTs because it still falls into the same problem. It has to keep track of last withdrawal time. And so you'd have this weird situation where the staked vouchers are fungible tokens but the rewards are NFTs. But it's like what's the point of the staked derivatives if they're not. If they don't entitle. So let's say I have 50, I delegated to chorus and I have, you know, 50 stake token fungible token like vouchers. And then I have an NFT that represents my delegation to chorus and I set and I send my 50 tokens to Brendan and. But if the NFT is still in my name, the reward voucher is still in my name. What, what is the. What are those 50 tokens, like even representing anymore at this point, like they're, I guess all you could do with them is unbond them. But that's kind of like, you know, I feel like the goal is you, you want the reward and the staking amount to be linked because otherwise why would someone buy them? All they're buying is then they're just buying atoms with no upside because they can't earn rewards but they only have slashing risk.
**C** (52:51):
Yeah, I mean, so the way I look at it is this. If I need liquidity, but I want to keep the underlying, I do believe that there will be people that will, that will basically create discounted cash flow valuations for the future value of what those returns could be similar to like an annuity stream or a fixed income security. And you know, for the first time ever you can actually separate the two. Whereas today in the financial world you can't separate the two. They're inherently linked. So I think it's important that there will be people in these new business models that we're going to create that will be looking for programmatic cash flow and then there will be methodologies put in place to evaluate programmatic cash flow. And as someone who owns the underlying, who's long it, if there is anticipation from people of increased staking rewards, if staking rates become a new risk free rate of a new global financial system that things are built on top of, there will be people who just want like fixed income purchasing. They may not want the underlying, they just want to be entitled to that revenue stream.
**A** (54:00):
So what I would say is I agree with that. So what you could actually do is once you have this delegation share token as a primitive, then you can actually put these into, so you can actually split these assets if you want to and separate out the unbond and redelegate capability from the change owner capability. So you can imagine, let's say I created a smart contract, I put delegation share tokens into that smart contract and that issues, so I'm still the owner of the delegation share, but it issues a new token which only allows someone to change the owner. And so that way you could go ahead and buy that change owner token. And using my shares that are there, you could go ahead and change the owner to yourself and you'd start earning those rewards until and then you could sell that change owner token someone else, they can start earning those and they can change the owner so they start earning the rewards, but they never have the ability to unbond the underlying. And that's one way you could do it.