Bonzo is a Hedera lending protocol whose HBAR markets are paused

Oracle dependence and the Bonzo Lend pause

Importantly, Bonzo Lend remains paused because a third-party price feed accepted an invalid SAUCE value on July 11, 2026. The feed error reached the collateral valuation path, where token prices determined borrowing power. A small SAUCE deposit was therefore assigned an extreme HBAR value. The application halted lending at 01:41 UTC, about 50 minutes after the abnormal update entered the oracle system.

The event exposed a dependency that collateralized lending cannot remove: the lending contracts rely on external prices to value unlike assets. Chainlink and Supra had supplied feeds to Bonzo, while per-asset caps, loan-to-value ratios and liquidation thresholds limited ordinary market exposure. Those controls did not validate the upstream price message. A recovery announcement on July 16, 2026 committed advances for affected positions at their values immediately before 00:51:39 UTC. Until a redemption mechanism and reopening conditions are published, Bonzo Lend should be treated as unavailable rather than merely illiquid.

Rates, network fees and protocol charges

Bonzo’s cost stack combined Hedera transaction fees, variable borrowing interest and four protocol-level fee categories. Borrow rates followed a two-slope curve: a gentler slope below optimal utilization and a steeper slope above it. Utilization ran from 0% when nothing was borrowed to 100% when the pool had no unborrowed liquidity.

Suppliers earned the borrowers’ interest after the reserve factor sent a configured share to protocol reserves. Bonzo displayed two reward layers: native supply APY accrued into the position, while separate liquidity incentives required a manual claim. Neither layer had a durable percentage because utilization, reserve parameters and incentive budgets changed by asset. A flash loan, which had to begin and repay inside 1 transaction, carried a fixed 0.09% fee. The fixed charge equaled 9 units for every 10 000 units of principal while the market operated.

Hedera charged execution costs separately in HBAR. The asset uses 8 decimal places, making 1 HBAR equal to 100 000 000 tinybars.

How did supplying HBAR and borrowing work on Bonzo?

Barring an unusual setup, Bonzo pooled each supported asset separately, issued receipt tokens to suppliers and recorded borrower debt on-chain. HBAR supplied to its HBAR reserve financed HBAR borrowing; it was not paired with another token.

Supplying HBAR

A supplier approved an asset transfer, signed the supply transaction and received an aToken balance representing the claim on that reserve. Interest increased the redeemable claim rather than arriving as a separate HBAR payment. Bonzo’s receipts used the ERC-20 interface inside the Hedera EVM, even when the underlying asset came from Hedera Token Service. An EVM address contains 20 bytes and appears as 40 hexadecimal characters after its 0x prefix. HashPack required manual display configuration for those receipt tokens, but visibility did not create the claim.

aTokens recorded the claim

An aToken was minted at supply and burned during withdrawal. It represented the deposited principal plus accrued native interest, while the underlying HBAR sat in the liquidity pool contract. The receipt therefore tracked ownership of a pool claim, not HBAR resting in the wallet account.

Utilization set the native yield

The HBAR reserve’s utilization ratio divided borrowed liquidity by total supplied liquidity. At 0% utilization, all deposits remained available; at 100%, no unused pool liquidity remained for an immediate withdrawal. The two-slope rate model raised borrowing costs after its configured optimal point, directing most paid interest to aToken holders after the reserve factor.

Borrowing against collateral

A borrower enabled supplied assets as collateral, selected a supported debt asset and signed the borrow transaction. The protocol converted each collateral balance into a common HBAR value through oracle prices, applied that asset’s LTV and limited the requested loan to remaining borrow power. Debt tokens then recorded principal and accrued interest. Borrowing 1 asset against another created price exposure on both sides: falling collateral value and rising debt value each weakened the position. Repayment burned debt tokens, while withdrawal burned the corresponding aTokens.

What did the health factor mean for liquidation?

More context is available in Using Bonzo. In that configuration, Bonzo used health factor as the solvency ratio, with any value below 1 making a position eligible for liquidation. The calculation divided collateral value multiplied by its weighted liquidation threshold by total debt value. A value above 1 left a buffer; exactly 1 marked the boundary, and a lower result opened the position to liquidators.

Loan-to-value and liquidation threshold served different jobs. LTV set initial borrow power, while the higher liquidation threshold set the later boundary for closing risk. Once health factor dropped below 1, a liquidator could repay up to 50% of the borrower’s debt in one liquidation and receive corresponding collateral plus the asset-specific bonus. The bonus, LTV and reserve cap varied by asset, so the dashboard’s position-level health factor mattered more than any single token parameter. Repaying debt improved the ratio directly; adding eligible collateral increased its numerator.

With zero debt, a supplied position stayed outside the borrower liquidation process and continued accruing its native supply yield.

Primary uses for HBAR holders

Once that is set, Bonzo gave HBAR holders three core choices: supply without debt, borrow against collateral or build a leveraged position. Supply-only users earned pool interest without the two-token price divergence associated with an automated market maker. Borrowers accessed assets such as USDC while retaining their collateral exposure, though interest and health factor continued changing. Re-supplying borrowed HBAR or moving it into SaucerSwap V2 increased capital use and added another contract dependency. Each route started from a single-asset HBAR reserve rather than a two-asset liquidity pair.

What would I need to use Bonzo Lend after reopening?

A Bonzo user would need a Hedera wallet, HBAR for fees and an asset supported by an open reserve. These were prerequisites during normal operation and remain useful context for any future redemption or reopening flow. No transaction should be prepared until the interface states that the relevant market is active.

HashPack and Kabila connected through WalletConnect, while the Hedera mainnet used EVM chain ID 295. The account also needed enough HBAR for every approval, supply, collateral and borrow signature. A supported token could still be blocked when its supply cap or borrow cap was full.

• Confirm the wallet is on Hedera mainnet, chain ID 295.
• Keep HBAR available for network and contract execution fees.
• Match the asset by its HTS token ID or ERC-20 address.
• Read the reserve’s active, frozen, collateral and borrowing flags.
• Review LTV, liquidation threshold and the resulting health factor.

Receipt display was a separate step. HashPack could hide Bonzo’s EVM ERC-20 aTokens and debt tokens until their 20-byte addresses were added manually, whereas the protocol position still existed on-chain. A missing icon therefore did not mean the supply had vanished. HashScan displayed native Hedera activity, while Bonzo’s dashboard and data service combined HTS balances with EVM contract state. During the pause, the recovery or redemption process has priority over the historic supply sequence, and its published wallet-verification rules would control access.

Aave v2 architecture adapted to Hedera

A companion page walks through Bonzo pricing. Seen from the other side, Bonzo launched its lending design on Hedera mainnet on October 28, 2024 by adapting the open-source Aave v2 pool model. The adaptation connected Solidity contracts in the Hedera EVM to HBAR, Hedera Token Service assets and Hedera account tooling. Bonzo Finance Labs built the interface and protocol integrations, while Halborn published contract audits dated September 5, 2024 for Bonzo Lend and September 23, 2025 for later ERC-20 and wHBAR updates. The design combined Aave-style aTokens, debt tokens, variable rates and liquidations with Hedera finality and chain ID 295.

Alternatives for putting HBAR to work

HBAR holders had alternatives that changed both the return mechanism and the layer where operational risk sat. Hedera native staking kept HBAR in the account and delegated stake to a node. Stader issued HBARX for liquid staking, while SaucerSwap V2 used concentrated-liquidity pools that exposed two assets to price movement. The table uses two security tiers as design layers, not quality grades, as documented in Bonzo troubleshooting.

Native staking removed borrower, oracle and liquidation mechanics from the position, although its reward rate remained network-set. Stader added HBARX smart-contract and redemption dependencies. SaucerSwap V2 exchanged lending risk for automated-market-maker range and price-divergence risk. Aave V3, Compound III and Morpho Blue offered direct lending comparisons on other networks, but none gave the same native HBAR route on Hedera. With Bonzo Lend paused, the decisive distinction is whether the holder wants network-native staking, a liquid-staking receipt or a two-asset market such as SaucerSwap V2.