RE: This Is How Hive Bonds Will Work
You are viewing a single comment's thread:
I'm actually a little confused as to why any of this would be on L2.
If Hive implements timelocks in this manner then it wouldn't be that difficult to turn those timelocks into NFTs directly validated by the witnesses, which could then be made transferable. This completely eliminates the need for multi-sig and trusting a small group of people. At that point the only L2 solution that needs to come into play is the frontend exchange used to provide fungibility, but even then all the backend transactions could be confirmed by the individual that actually controls the bond.
Maybe I'm getting a little ahead of myself here in thinking there won't need to be a transition phase with multi-sig, but if the protocol takes off it seems almost guaranteed that we would bake it into the core code.
My confusion is in the NFT area.
I know NFT is still a buzzword but since the bonds are supposed to be tradeable, you want to have a reasonable amount of fungible token classes.
In plain English: let's have a SEP28 token that represents a bond that pays out 1 HBD on 01/Sep/2028. Speaking of reasonable amount of classes, you do not want a 28AUG28 token (at least until the thing really grows). If you buy SEP28 on 28/Aug/2023, the blockchain will gladly compute the correct price for you off the (witness-signalled) 5-year APR.
NFT can be thought of denoting contract.
It is going to become more commonplace as tokenization of financial assets occurs.
No doubt about that, but I do not see any relevance to my point.
Chopsticks have become more commonplace over here but I still observe the fossils reaching for a spoon whenever soup hits the table.
I would prefer the idea on the base layer but not sure it is possible. Nevertheless, the answer I got is that the Bonds would have to be built on L2.
I am not sure if this is because of the tech or to keep the base code limited in terms of focus.
I dont even pretend to know the technical details of how this is coded.
Yeah I get it... it's because the code they are going to use is just a basic extension of the current savings account system. Making the positions transferable would be a whole other thing. Certainly not the worst option so I guess we'll have to prove the theory in the field before it's taken more seriously.
My sense is the general rule of thumb is to keep the base code as streamlined as possible by having basic features and pushing more onto L2. I think that is why we see Spk and HAF development.
But like you said, we will have to see how it works. Time vaults will start the process and is a good first step.
In the devs hands.