The Great DHF Debate of 2026: Chasing the Code Instead of the Drama

Recently I've been seeing more and more debates about the DHF and the proposed HBD delisting on both Hive and Blurt.

At first I was ignoring most of the talk because most people don't even see past their own beliefs to actually see the underlining issues to understand the whole picture.

Or even dig into source codes and analyze structures and test their claims to see if it's even true what they are saying. At first it was just ,"another squirrelly drama show" that I did not want to take part of.

Then I stumbled through a Blurt post linking to a Hive proposal over the DHF. Apparently, it was a big deal and the discussion quickly became personal at times

Everyone seemed convinced they were right, and yet many of the arguments presented, depended on mere assumptions about how Hive actually works. I ended up finding everyone was talking past each other and people were getting nowhere.

IRather than choosing a side, I'm going to do something much simpler. I'm going to verify the claims that actually matter, one by one. The objective of this article is to understand the protocol itself...

I'm not trying to win an argument. I just want to know the truth and provide aid in giving clarity in this debate.

The goal is to leave behind an honest trail that anyone can follow and verify for themselves in the most clear and simple way, and as unbiased as I humanly possibly can be.

To view Hive account@igormuba proposal click here.

Click here to see my comment to Hive account@blocktrades.

---

---

The Questions

Before I can even determine whether the proposal has any merit or not, I first need to understand how the protocol actually works. This has taken me a while to gather some real info based on the entire thread. Sifting through comments, going back and forth throughout the page to figure out what actually mattered and what didn't.

The debate raised several technical claims, but the investigation ultimately comes down to a handful of questions (subject to change as I go along with this investigation):

• What exactly does hbd_print_rate do?
• What happens to author rewards as hbd_print_rate decreases?
• What really happens when it reaches 0%?
• Does it reduce the value of author rewards, or only change the asset they are paid in?
• How is the DHF funded?
• Where does the HBD in the DHF actually come from?
• Is the DHF affected by hbd_print_rate?
• Are author rewards and DHF payouts actually comparable mechanisms, or are they fundamentally different?

---

---

What exactly does hbd_print_rate do?

I THINK most of these questions can be answered using this website:

https://developers.hive.io/tutorials-recipes/understanding-dynamic-global-properties.html

I had to double and triple check this page and I was a bit frustrated to see nothing on this directly. What I mean is, I had expected to find some official documentation explaining hbd_print_rate, but the developer documentation only documents hbd_start_percent and hbd_stop_percent. The docs don't explain its behavior directly. That means I have to verify it from the protocol implementation rather than relying on secondary explanations.

So,... Off to GitHub or gitlab I go... I swear it's a clusterfuck of a website. Confusing to navigate around sometimes and frustrating finding what you need to find because, in my experience anyways, a lot of times it's written in some other way and or it's buried in deep under a lot of wording.

For example, I just spent 2 hour examining and reading (don't even ask me if I used the search boxes available, I checked on all available ones, i ain't stupid enough not to use it thank you) through the entire contents of Openhive-network on GitHub and the only thing I could find anything remotely close to what I'm looking for is on witness parameters set as:
"hbd_interest_rate" and "hbd_exchange_rate", but hbd_print_rate I'm more convinced now that the print rate is calculated by the protocol itself, and not a witness-set parameter.
But I'm going to look again just in case...

Searching....

Searching...

I swear I'm going to throw this pho GASP! SHUT UP!

I FOUND IT!

After a bit of digging I finally found where hbd_print_rate is handled inside the Hive source code.

There isn't some witness voting on hbd_print_rate. It isn't listed as a witness parameter. Instead, the protocol calculates it automatically based on the current HBD debt ratio.

Here's the relevant part:

if( percent_hbd >= dgp.hbd_stop_percent )
    dgp.hbd_print_rate = 0;
else if( percent_hbd <= dgp.hbd_start_percent )
    dgp.hbd_print_rate = HIVE_100_PERCENT;
else
    dgp.hbd_print_rate =
        ((dgp.hbd_stop_percent - percent_hbd) * HIVE_100_PERCENT) /
        (dgp.hbd_stop_percent - dgp.hbd_start_percent);

Looking at the code, the protocol compares the current HBD debt ratio against two thresholds: hbd_start_percent and hbd_stop_percent. If I am reading this correctly...

• if the debt ratio is below the start threshold, hbd_print_rate stays at 100%.

• If the debt ratio reaches the stop threshold, hbd_print_rate becomes 0%.

• If the debt ratio falls somewhere in between, the protocol will gradually reduce the print rate, according to the formula shown in the code.

So, at least for Question #1, I finally have an answer.

hbd_print_rate is an automatically calculated value derived from the current HBD debt ratio using the start and stop thresholds. It isn't an arbitrary number. The protocol calculates it every time based on those conditions.

what exactly does hbd_print_rate affect?

The next thing I want to know was whether hbd_print_rate actually reduces rewards, or whether it simply changes the currency they're paid in.

Back to the code... 😔

Tick tok tick tock, I found this:

auto to_hbd = ( gpo.hbd_print_rate * hive ) / HIVE_100_PERCENT;
auto to_hive = hive - to_hbd;

This was one of those moments where I stopped and stared at the screen for a second.

It tells me the code isn't reducing the total reward. Instead, it splits the payout into two parts. One portion is converted into HBD according to hbd_print_rate and the remainder stays as HIVE.

That means as hbd_print_rate decreases, the amount paid as HBD decreases , all while the amount paid as HIVE increases.

So unless I find code elsewhere that says otherwise, the total payout itself doesn't appear to be shrinking. The protocol is simply changing the ratio between HBD and HIVE.

If that's correct, then this matches what Hive account@blocktrades told me in his reply:

"It only changes the currency used."

So, for now at least, that claim appears to be supported by the source code itself. And matches with what I have been told all these years. So, if anyone is in doubt about that, just reread above.

Of course, that raises the next obvious question...

Does this same mechanism also apply to the DHF, or is the DHF funded differently?

Simple answer: No, hbd_print_rate does NOT affect DHF payouts.

It only affects how author rewards are paid out (HIVE vs HBD mix).

Let me explain the order as per what the code and protocols say.

1. New HIVE inflation is created per block
2. Inflation is divided into 3 major buckets: Reward pool (authors + curators), DHF treasury, other protocol allocations.
3. THEN reward pool is processed
4. THEN reward pool is split using hbd_print_rate

So structurally... DHF happens before the system ever reaches the hbd_print_rate code.

In short:

• hbd_print_rate = inside reward pool logic

• DHF = outside reward pool logic

---

At this point I finally understood something important.

The current protocol does not appear to treat author rewards and the DHF as the same mechanism.

From everything I have traced so far, hbd_print_rate only appears in the reward payout logic. I have not found any evidence that it directly controls DHF proposal payouts.

That also helped me better understand what Igor's proposal is actually trying to do.

Initially I was under the impression that perhaps the DHF was supposed to already follow hbd_print_rate and that some loophole or oversight existed. But after tracing the code, that doesn't appear to be the case.

Instead, the proposal is attempting to introduce a new connection between two mechanisms that currently appear to operate independently.

In other words, the proposal is not saying that the protocol already scales DHF payouts using hbd_print_rate. It proposes changing the protocol so that it does.

That distinction is important.

It changes the question from:

"Does the protocol already apply hbd_print_rate to the DHF?"

to:

"Should the protocol apply hbd_print_rate to the DHF?"

Those two are completely different fundamental questions.

The first is a question of fact that can be answered by examining the code.

The second is a question of protocol design and economics.

Before I can decide whether that proposed change has merit or not, I still have another question to answer first:

Where does the HBD inside the DHF actually come from?

This part is crucial because it is the foundation of Igor's proposal. His proposal assumes there is a treasury full of HBD that can continue paying proposals even while hbd_print_rate is suppressing HBD in author rewards. So let's figure out how that Treasury gets HBD. Because right now I'm trying to evaluate whether Igor's proposal is connecting two mechanisms that are intentionally separate, or whether it is exposing something that was overlooked.

Luckily for us it already answered in the first website I listed above and here below again:

https://developers.hive.io/services/dhf.html

It states

The DHF (Hive account@hive.fund) receives 10% of the annual new supply.

It also states HBD printing for the DHF does NOT follow the haircut rules and will continue regardless of hbd_print_rate.

But look what I found:

auto dhf_new_funds = ( new_hive * props.proposal_fund_percent ) / HIVE_100_PERCENT;

This above calculates how much of the newly-created HIVE inflation is allocated to the DHF.

Then immediately afterwards:

new_hbd = dhf_new_funds * feed.current_median_history;
adjust_balance( get_treasury_name(), new_hbd );

The DHF does not appear to consult hbd_print_rate when it receives new funds. Instead, it follows a separate funding path inside process_funds(), where a fixed percentage of newly created inflation is converted into HBD and deposited directly into the treasury.

So now my next question is whether those two systems should remain independent, or whether hbd_print_rate should also influence this funding path.

So far, everything I have found suggests the current protocol intentionally treats them separately.

The author reward pool is affected by hbd_print_rate.

The DHF funding path is not.

Instead, the protocol allocates a fixed percentage of newly created inflation to the DHF, converts that allocation into HBD using the median price feed, and immediately credits the treasury account.

At no point in the code I have examined so far does this funding path reference hbd_print_rate.

That doesn't automatically mean Igor's proposal is wrong. It simply means his proposal is asking to change an existing protocol behavior rather than fixing one that already exists.

The remaining question I still need to answer is how the protocol balances the accounting behind that conversion. In other words, exactly how does the protocol create the HBD that ends up in the treasury, and what happens to the corresponding HIVE supply?

So, I think I've answered the question I originally set out to answer.

The DHF appears to have its own funding system. It receives a fixed share of newly created inflation, that share is converted into HBD, and the treasury is credited with it. None of the code I have examined so far suggests that hbd_print_rate plays any role in that process.

Which means I'm no longer trying to figure out what the protocol does. I think I've established that part reasonably well.

At this point, I think I've answered the factual questions I originally set out to investigate.

The current protocol treats the author reward system and the DHF as separate mechanisms. Whether they should remain separate is a protocol design question rather than a source code question.

My goal here wasn't to argue for or against changing the protocol itself. It was to establish, as accurately as I could, how it currently behaves so future discussions can start from the same factual foundation.

---

---

Enjoyed the Investigation?

These posts don't magically appear out of thin air.

They cost hours of reading documentation, crawling through source code, testing claims, chasing dead ends, and occasionally yelling at GitHub until it finally gives up the answers.

If you found this useful and want to support more investigations like this, consider leaving a tip or donation.

It helps fund future rabbit holes... because apparently I can't resist jumping into them.

XMR:

86fXjLUF7W9SwGSjTtsbqq4t1LKzzypEZa1t77S5c68WF3yK9SmEfzPTtRyjUhDSk9Zn7p1ahFJT4PcKW8MN4h3QRpjx2Q5

Hive: muhshrooms

Post Rewards are burned