Are we going to get Hive bonds? Will Smart Media Tokens (remember them) come into being? What is going on with the coding of the Hive blockchain?

Over the last week, I dug into what was forwarded to me in a comment. Since that time, we can see a great deal of what is being discussed.

Before going any further, this is a working list that has no confirmation of what will eventually roll out. If you will, consider it an idea board. That said, it does appear to be a culmination of the ideas discussed, listed in order of what needs to be done.

Here is what was posted in GitLab:

This is a collection of buzzwords that are related to [potential] work in hived, improvements, optimizations, new functionality, testing tools or code safety changes. There is no particular order to them other than in case one point depends on completion of a different point, the latter is earlier on the list. Some are easy and quick to implement, some are hard and require a lot of work, testing and possibly even new APIs and front end tools, some are unknown and need to start from research, discussion and design. The list is not complete - some tasks have separate issues already, there are also tasks that have separate issues that are not on this list.

There are a total of 30 "ideas" listed. Much of it is written in "code-speak", detailing some technical operations that require addressing. Also, as stated, some of these are required to develop the ensuring operations on the list. Thus, it is not a situation where we chose #30, for example, and code it.

The Path Of Hive Coding

It is easy to fall victim to thinking there is nothing going on. The reason for sharing this document along with a write up is to show some of what the thinking is. Also, it presents us with some idea of what might roll out in the next couples years.

Before going any further, here is the page called "Meta Issue" which we will be referencing.

To give a quick summary of some of the more interesting ideas that users might like:

• Hive bonds
• SMTs
• RC-fee
• RC scaling (tied to block size)
• Lite accounts
• Bitcoin Signing

We will not go through each one. Simply refer to the page and scroll down towards the bottom of the list.

The first thing that jumps out at me is there is a lot of work to be done before some of these features can be activated. As one who is not a developer, the process is foreign to be. But like anything, we are not operating in a vacuum. Often a lot of "cleanup" or new development is required simply to then start coding something else.

It certainly appears to be the case here.

That said, what is being conveyed?

Base Layer Operations

Many will point out there are a number of things on the list that are already either being worked upon or in operation. After all, many of these topics were discussed regarding VSC. Tokens are already available on there and Hive-Engine (although I don't believe the smart contracts for token creation on VSC was written).

Why the redundancy? What changed?

The answer to the latter is nothing changed. What we are dealing with is two separate issues. This about sums it up:

There are L2 tokens on Hive. The problem is, they are L2. It means they are subject to potential shortcomings of L2 solutions that host them. If they were represented on L1 a lot of problems could be avoided, lessening the amount of trust needed to operate/invest in them, even if the management of emissions is still left for L2.

We have to revert back to the original premise of blockchain and cryptocurrency: we are looking to provide trust in a trustless state. This means removing as much counterparty risk as possible.

The safest way for any of this is to incorporate it at the base layer. From what I understand, if correct, the challenge is to follow this path while not bloating the system. There is a tradeoff between what is coded in to operate on chain versus the processing required. Obviously, the goal is to do as much of the first without increasing the second too much. Fortunately, part of the list includes the need to restructure certain operations to use less RAM.

To me, we have to avoid the L1 versus L2 concept of competition. Instead, it is beneficial to look at it as complimentary.

Are layer 2 tokens sufficient in many instances? Sure. For 90% of the cases, this is no problem. However, what about the other 10%? Here is where Hive is missing the boat.

That said, there is another issue to consider: what is built on top of the token. It is where we see the idea of L1 tokens potentially having greater utility.

If we operate from the premise that an asset is most trustworthy on L1, then it stands to reason that another asset built utilizing the L1 token is going to be safer than one with L2. In the financial arena, producing something on top of an asset with counterparty risk means that is transferred to the new product.

Hence, we are dealing with the potential for two points of vulnerability. We have the risk of the new asset along with the token itself. If we are using a L1 token, there is still counterparty with the new asset but that is where it is limited.

The point is we are not looking at either/or. Instead, it is simply providing developers with choices as to what best meets their needs.

Hive Bonds And SMTs

Here is a piece of number 27 called "DHF" bonds.

That's why I think it is better if bonds are only produced "by the system", at predictable intervals and amounts, making it easy to calculate resulting HBD debt ratio far into the future (with weight of future-HBD increasing the closer it is to maturity).

The thing in Hive that matches best for the role of issuer is DHF. It already receives funds from inflation and it has a large buffer for them. It means that it should be relatively safe to change its funding mechanism to emission of bonds (with appropriately higher value since it will also covers current savings interest payments). DHF could keep bonds to maturity, but it should try to sell them on open market (needs to be created - big front-end task) receiving (smaller) funds earlier. Witnesses would no longer be setting HBD APR (the mechanism should be removed), but rather a max discount DHF can give when selling bonds. This way the effective APR would be subject to market conditions: owners of previously emitted bonds can be selling them pressuring DHF for bigger discount for new bonds, but if someone was trying to buy a lot, they might need to make do with smaller discount, because there is no guarantee there will be any available (in volume) at bigger discount levels.

This is a different spin of what we discussed in the past. It is having the DHF serve as the producer of the bonds.

The basic idea is to not have an interest rate paid out. Bonds would be offered out at a discount with a certain time date. This would be stamped so the transaction (bond) was clear.

For example, a $1,000 bond could be sold for $800. This means that, holding the bond to maturity would pay out $1,000. That means a $200 profit for the purchaser, a return of 25%.

This directs the HBD inflation in a different manner as compared to the present system. We would have a maximum discount rate set which then it tied to market conditions to set the realize interest rate. In other words, in times of great demand, the discount would be smaller. If things are slow, the discount is increased to entice investors.

All of this is integrated with SMTs. While there could be fungible tokens like we see on L2, these could also be similar to NFTs. Each bond is a SMT (NFT), being its own individual asset. These could then be traded through different front ends.

Collateralization

The final point, at least for this article, is collateralization.

My idea relating to Hive bonds was always, ultimately, as a vehicle for collateralization. This is what we are really lacking. In short, this means the potential for lending platforms.

Tied to this idea was to create high quality collateral. Within the present system, the standard falls to US Treasuries. From a Web 3.0 perspective, the idea of counterparty risk is against the nature of what we are trying to build.

As spelled out here, if the bonds created on L1, we see the only counterparty risk being the blockchain. There are no third party intermediaries. Hence, nobody can take the bonds away.

It is at this point that lending platforms can be developed. These can utilize the bonds as collateral.

Let us take a look at what we are dealing with:

• The asset used as collateral has a stated value at maturity. It also have a timestamp date meaning the exact monetary payout at a future time is known. This does not fluctuate.
• The underlying of the bond is the Hive Backed Dollar (HBD), a stablecoin that has the conversion rate of $1 worth of HIVE built into the L1 code that is guaranteed by the blockchain (unless the haircut level is exceeded).

The combination means the removal of volatility associated with using value capture tokens such as Bitcoin or HIVE. If a lender accepts $300K worth of Hive Bonds against a loan, it knows the $300K will be paid out and when.

Of course, the details of when the bonds are issues by the DHF, how long the duration, and the process have to be worked out. That said, we have a framework of how this could look.

In closing, these are some of the ideas being floated around regarding the base layer development. Read through the list to see some of the areas that are in discussion.

Again, this is not a guarantee of what will be developed and certainly is providing no timeline. Some of these require a hard fork; others do not.