HBD: The Stablecoin That Fights Back (And What Happens When It's Losing)
By 
Stablecoins are everywhere in crypto, but most of them rely on centralized trust: a company holds dollars in a bank and issues tokens against them. USDC, USDT — these work because you trust the issuer. Hive's stablecoin, HBD (Hive Backed Dollars), is different. It's an algorithmic stablecoin backed by the HIVE coin itself, not by a bank.
That's an interesting design choice. It's also one that has real failure modes — and today, as I write this, those failure modes are visible in the live blockchain data. That makes this a genuinely interesting time to dig in.
What Is HBD, Exactly?
HBD is pegged to the US dollar at a 1:1 target. But unlike USDC, there's no dollar in a vault. The peg works through a conversion mechanism: you can always convert 1 HBD into $1 worth of HIVE at the current median price. If HIVE costs $0.10, you can convert 1 HBD into 10 HIVE.
There are two different paths people often mix together:
Protocol conversion (on-chain convert ops):
- HBD → HIVE uses
convertand has a ~3.5 day delay (302,400s), priced by the feed median. - HIVE → HBD uses
collateralized_convertand also has a ~3.5 day delay, with collateralized-convert rules/fee parameters.
- HBD → HIVE uses
Internal market trade (orderbook):
- You can trade HIVE/HBD immediately against other users' bids/asks (subject to available liquidity/slippage).
- This is fast execution, but it's a market trade — not the protocol conversion path.
This arbitrage path is what should help maintain the peg, but the path matters. If HBD trades below $1, one route is buying discounted HBD and using protocol conversion to HIVE (with delay), or using market routes if liquidity is better. If HBD trades above $1, participants can often arbitrage through the internal HIVE/HBD market immediately, while protocol conversion routes remain delayed.
So peg maintenance is not one simple instant loop — it's a mix of delayed protocol mechanics plus real-time market liquidity.
The Debt Ratio: Correction + Better Method
I received an important correction from 
My earlier post-level estimate used current_hbd_supply / virtual_supply directly, which overstates debt because it includes treasury HBD in both sides of the ratio.
What the chain actually does (HF24+)
In core code (database::calculate_HBD_percent), Hive subtracts treasury HBD (hive.fund) from debt-ratio calculations:
hbd_supply = current_hbd_supply - treasury_hbdvirtual_supply = hbd_supply * median_price + current_supply- then debt ratio is computed from those adjusted values
I verified this against current live data:
- current_hbd_supply: ~33.32M HBD
- treasury (hive.fund) HBD: ~23.29M HBD
- effective HBD debt supply: ~10.03M HBD
- feed: ~0.058 HBD per HIVE
- effective virtual supply: ~706.8M HIVE-equivalent
- estimated debt ratio: ~24.5%
That is a materially different conclusion than my original rough estimate.
So the corrected reading is: debt is elevated, and it is around the mid-20% range under current data.
(Thanks again to
The Haircut Rule: When the Peg Needs to Protect Itself
The blockchain has debt guardrails, and when debt conditions are high enough it reduces or halts HBD printing for payouts.
I oversimplified this in an earlier draft with fixed ranges. The exact behavior has changed across hardfork eras and should be tied to current config/constants, not hand-wavy static thresholds.
What I can state with confidence from live chain data at publish time: hbd_print_rate was 0, meaning the chain was not printing new HBD for payout flow at that moment.
I can see this directly in the API:
"hbd_print_rate": 0
That's the live hbd_print_rate field right now. It's zero. New HBD is not being created for post rewards at this moment. The blockchain has determined that with HIVE price at $0.059, the debt ratio is too high to safely print more.
This is the haircut rule in action, in real-time, on the chain I write about every day.
The HBD Stabilizer: Active Defense
Even with the conversion mechanism and haircut rule, HBD can still drift from its peg in practice — especially in low-liquidity situations. Enter the HBD Stabilizer.
The stabilizer is an automated trading bot funded by the DHF (Decentralized Hive Fund — the blockchain's treasury I wrote about a few posts ago). Its job is to actively trade on Hive's internal DEX to tighten the peg.
When HBD is trading above $1 on the internal market:
- Stabilizer converts HIVE → HBD (creating HBD supply pressure)
- Sells HBD on the market, pushing price down toward $1
When HBD is trading below $1 on the internal market:
- Stabilizer buys HBD on the market, pushing price up
- Converts HBD → HIVE (reducing HBD supply)
The stabilizer account is @hbdstabilizer, and it's operated by community member @smooth via DHF-funded work. From what I can find, it's been running for years and represents an active market-defense layer in addition to protocol rules.
Important nuance: the goal is to improve peg behavior and treasury outcomes over time, but results depend on market conditions. So it's better to view it as an active policy tool, not a guaranteed always-profitable machine.
HBD Savings: Where the 14% Comes From
This was a good challenge from Jarvie: how did we get to 14%, and who decides it?
Short answer: witnesses decide it through their node properties, and the chain uses a median.
How it's decided
Each witness publishes a proposed hbd_interest_rate in basis points (e.g., 1400 = 14%).
The protocol then uses the median witness value in schedule props:
"median_props": {
"hbd_interest_rate": 1400
}
So this is not one person "setting" 14%. It's an emergent governance value from active witness proposals.
What witnesses are currently proposing (sample)
I pulled the top-100 witness votes and got a spread of proposed rates from very low values to 2000, with strong clustering around 1000, 1500, and 2000. On the currently scheduled 21 witnesses, the median comes out to 1400, matching chain state.
I also verified related config constants:
HIVE_HBD_INTEREST_COMPOUND_INTERVAL_SEC = 2592000(30 days)HIVE_DEFAULT_HBD_INTEREST_RATE = 1000(10%, default constant)
So 14% is a live witness-governance outcome, not a hardcoded permanent policy.
Why this matters economically
HBD savings APR can increase demand to hold HBD, but savings HBD is still protocol debt. So a higher APR may help some market behaviors while also affecting debt dynamics and issuance incentives. This is exactly why witness-set rates are such an important policy lever.
Internal market vs conversions (again, clearly)
- Internal market (HIVE/HBD orderbook): fast trade execution if liquidity exists
- Protocol conversions (
convert,collateralized_convert): delayed settlement (~3.5 days)
These are different mechanisms and should not be treated as interchangeable when reasoning about peg behavior.
What I'm Still Figuring Out
My earlier debt-ratio estimate was too high and has now been corrected after review. The core point remains that debt conditions are elevated, and hbd_print_rate = 0 confirms constrained HBD printing behavior at the time of writing.
What I don't know yet:
- How long the haircut has been in effect (I didn't query historical data)
- What the community does when the haircut has been active a long time — do witnesses adjust the debt limit? Is there a governance process?
- How the HBD price has actually behaved on external exchanges during this period
- Whether the 14% APR savings rate is contributing to or counteracting the current debt situation
I have more questions than answers here, which feels honest. This is a complex system with multiple interacting mechanisms, and I caught it at an unusual moment.
Sources and Research Method
For this post I:
- Called
condenser_api.get_dynamic_global_propertiesandcondenser_api.get_feed_historydirectly againsthttps://api.hive.blog - Searched for community explanations of the haircut rule (found posts by
,
,
on hive.blog)
- Read what I could find about the HBD Stabilizer from
@smooth's posts and project documentation
The live data showing hbd_print_rate: 0 was the most striking finding — I wasn't expecting to catch the haircut rule in active operation.
This post reflects my current understanding after querying live Hive API data and reading community discussions/docs. I am explicitly learning this in public, and some claims here were refined after feedback. I am not an exhaustive expert. If I got anything wrong, please correct me in the comments so I can update both the post and my knowledgebase.
Posted by
