How To Implement Time Vaults And Hive Bonds
We have a lot of discussion surrounding the Hive Backed Dollars (HBD), time vaults, and Hive Bonds.
In this article we will look at a few options as to how to accomplish this.
The Complete Package
We will start with the end first.
In a perfect world, it would be ideal to have the bond system put in place immediately. This would include time vaults that mirror a bond tree with time breakdowns something like this:
You could even go out to the 20 and 30 year duration.
This would then be complimented, on the base layer, with the bonds. Here we see another token created when the time vaults are entered into. The transaction is tied to the token (which is basically a NFT), containing amount, vault, date, and APR.
The reason why this is best at the base layer, from a financial perspective, is counterparty risk. We are removing any application or entity serving as the counterparty. We all know one of the main tenets of Bitcoin was the removal of this risk that is tied to financial institutions.
The ideal and reality often differ.
We could be looking at a number of valid reasons as to why going full-tilt is not the proper approach. The most obvious factor that pops out is simply time of coding. This could be a mammoth task for the core developers to undergo. For that reason, we need to phase things in.
Another is to start the "testing" process. We can game theory things all we want. However, until we see it in the real world, it is just theory.
Hence, the most logical starting point is to get the time vaults built. This is crucial for any type of "bonding" system.
My suggestion would be to start with the 1 year and under vaults. Establish 4 of this so people have options. This will allow the community tojudge how people are approaching this. We will have to understand, from the base layer, there will be no access to the funds. This is another reason for keeping it relatively short-term.
Layer 2 Bonds
To provide a solution to this problem, layer 2 bonds can be created.
At this point, we have to mention this will incur another layer of risk. This is why it is not part of the ideal scenario. However, for brevity with time along with testing, this approach makes sense.
Projects can start to tinker with developing bonding platforms. This would likely require applications that take the HBD in and the application operates as the bonding mechanism. It is something that could utilize multi-sig wallets as a means of security.
Once the level of success is determined, discussion can occur around the idea of moving this to the base layer or not.
Of course, these tokens are pretty useless unless they can be traded. This means an exchange is required so people can move in and out of their positions. Some are going to use the time vaults and get the full return over the duration of the transaction. Others will want to liquidate at some point.
This is what the bonds allow for.
Collateral is not very useful if there is no way to post it and get a loan.
If there are layer 2 bonds constructed, then projects can also look at developing lending platforms. Here is where the bonds can be posted in return for a loan. Under this scenario, I would think the payout coin is HBD, since this is all tied to Hive.
Here again, we are dealing with some additional risk since we are not operating at the base layer. However, as we will see, there is a valid reason for this.
The tendency might be to conclude that we are engaging upon extra work that will eventually be negated. By this I mean that why build all this layer 2 stuff if we eventually move it to the base layer?
To start, not everything is going to end up on there. Secondly, nothing has to be eliminated.
Even if the community does decide to move the bonding to the base layer, so there are both time vaults and basically the NFT creation there, that does not mean layer 2 stuff is eliminated. People need options and are willing to take on varying degrees of risk. There is nothing that says base layer and layer 2 bonding solutions cannot co-exist. In fact, it is healthy for the ecosystem to have more options since thais helps to provide resiliency.
The same holds true for the lending platform. Perhaps the base layer does, at some point, get the ability to post the tokens as collateral in return for a HBD loan. That does not mean other applications cannot offer the same. They will have the ability to offer different rates, most likely compensating people for some additional risk. We could also see some other value-added services provided by these platforms that the base layer does not.
Since we are small in number, we seem to believe that have multiple options means dilution since all projects are fighting over the same people. If we are talking hundreds of millions of dollars flowing into the ecosystem, there will be enough to support many options.
This seems to get a lot of attention of late.
Let me start by emphasizing this:
The interest rates for the time have only one purpose: draw in capital. We are not looking at controlling the money supply through this mechanism. The money supply, i.e. the amount of HBD, is really going to be controlled through the conversion mechanism. Lowering an interest rate does not eliminate any excess HBD.
With that in mind, what are the proper rates?
Here we are throwing darts at a board, after drinking a 12 pack of beer, while on a slippy-slide. Nobody has the answer.
If we have 4 time vaults, I would suggest something like this to start:
1 month - 5% 3 months - 7% 6 months - 10% 1 year - 25%
There is another factor that we must raise with interest rates. We can already foresee people saying what is the 10 year going to be 60%? That is not possible.
Let us look at the present rates for U.S. Treasuries:
Notice how it goes from 1 month to 30 under 1%. With the size of the market, we see very tight rate separations.
The point is we might have a time where all the Hive bonds is a much tighter range. Again, the interest rate is to set to attract the most capital (or whatever capital is desired).
To me, the time vaults start the entire process. I think it critical that we get at least some semblance of a tree going with multiple lock up options. It is easy to get caught up in words so let us make it easy.
What is being constructed, in this aspect, is nothing more than the idea of certificates of deposit. If the decision is to simply have the time vaults at the base layer and leave the "bonds" to sidechains, perhaps, at some point, an early withdrawal penalty is implemented. This would allow for base layer lock up while also offering access to the funds, albeit at a cost.
Without knowing the technical challenges, if there is a coding issue, then perhaps the first starting point is simply to move the lock up from 3.5 days to 365. That will provide developers with the opportunity for layer 2 development and could kickstart the process.
Personally, I would like to see the different options to get a sense of what people will gravitate towards with their money. Nevertheless, it does have to be framed against the backdrop of development.
Now it is time for the discussion to start. These are some of my ideas for the moment regarding the path forward.
What are yours?
Posted Using InLeo Alpha