Like I said in other comments, where this topic was already touched, time vaults are interesting concept, but part of much bigger new functionality of lite accounts ("free floating funds" tied to address, not an account). There are many reasons to introduce such accounts, there was already some back and forth exchange of ideas on CoreDev chat, but I won't go into the details here.
Time vaults are basically NFTs. Some people will need many, with different time locks, others (most) won't use them at all. That's why they can't be implemented in a way similar to current savings where every account has a corresponding balance (in fact I think we should go the other way and make current saving balances into "free floating funds"). I'm guessing here, but they could probably be implemented as some form of Pay-to-Script-Hash with built-in script that would only "free" the balance for transfer after check on head block time is passed (plus proper signature of course). But I'm not familiar with the details on various address/signature schemes - that's part of the initial research that needs to be made and one of the reasons I don't think the topic has a short time-to-market, definitely not HF28.
Some issues: I don't see the auto-redeposit, neither from technical standpoint nor as a user. If they are to be like bonds, then they should not pay anything after maturity, no? The window of opportunity that user could have to "turn off" auto-redeposit complicates things a lot. Without it we can pay all the interest upfront (since it is locked anyway) and the vault could be stored as just address and asset.
Another issue: how do we calculate funds in vaults towards HBD debt limit? It seems natural to have some time-to-maturity weight attached to each one, but we'd need a way to compute such sum without running over all existing vaults. Besides we might open ourselves to a debt problem in case a lot of vaults unlocking near the same time. So maybe there should be no way for users to create those vaults but rather witnesses/system should hold "bond auctions"?
Well I certainly cannot speak to the technicalways of creating this so that will have to be directed to people a lot more capable than myself.
Yes bonds pay at maturity yet the bond idea is, at this point, a layer 2 solution. At the base layer, it is more akin to a CD or savings bond. The liquidity is not at the base layer, under this scenario, unless there is a penalty for early withdrawal like other people brought up.
Of course, if that path wants to be pursued at the base layer, it could but then we would add a lot more complexity to the equation. Certainly, that might extend the time to plan/develop.
I would say a weighted average somehow makes sense. We know something that is 5 weeks from expiration is a greater threat than HBD that was locked up a week ago. How that will calculated is a topic for discussion.
Of course, there is another factor in this: a lot of the vulnerability of the debt comes from the value tied to HBD. If we have no use cases and it is only used to create more HBD, than we have a tremendous flaw there. However, if we starts to become build out with derivatives, payments, used for funding, and being collateralized, then we are dealing with something completely different.
As always we are dealing with things from a holistic poerspective as opposed to being in a vacuum.
Posted Using LeoFinance Beta
Could it work better if person would "burn" hbd then gain small amounts of it everyday for a year totalling 125% of the original?
Such solutions have two problems: they add automated work to the core code. Nodes have to observe timers (extra index needed) and do some transfers on their own. Second, while each single step of such work takes very little time, there is risk of it accumulating inside single block. Then we have to have a mechanism that prevents that. We already have those, f.e. for recurrent transfers, but such situations should be avoided rather than worked around.