Bonzo is paused: signing a supply transaction and verifying the balance

The pause stopped the supply path before signing

Zero new Bonzo Lend supplies were executable while the market pause remained active, so no wallet confirmation could create a fresh supplied balance.

A disabled Supply control, an absent confirmation request or a pause notice all described the same protocol state. Reconnecting HashPack, changing browsers or lowering the amount did not turn the disabled market into an executable one. A wallet signature existed only after the interface built a valid Hedera transaction. If that transaction request never appeared, no asset left the account and no aToken position was created. Existing balances and any separate recovery process belonged to different workflows; neither converted the paused supply screen into a fresh deposit route.

The correct paused-state outcome was zero signatures, zero wallet deductions and zero new lines in the Supplied panel.

Three prerequisites determined whether the modal could proceed

Three prerequisites governed Bonzo’s former supply flow: a supported wallet session, Hedera mainnet access and enough HBAR for contract execution.

Wallet session

HashPack and Kabila connected through WalletConnect. A desktop extension requested one account selection, while a phone offered two pairing routes: scanning a QR code or entering the pairing string. The account displayed in Bonzo had to match the account selected inside the wallet before an amount was entered.

Network and HBAR

Hedera mainnet used EVM chain ID 295. HBAR paid the network charge even when the supplied asset was USDC or another supported token. An HBAR supply therefore needed room for both the entered principal and the fee preview; filling the amount field with the entire wallet balance could leave the payer unable to fund execution.

Market and amount

Bonzo displayed only assets that its lending markets supported. Each market could also carry a supply cap expressed in token units. Reaching that cap prevented additional supply even when the wallet held the asset, the connection worked and the payer retained enough HBAR.

The supply modal converted one amount into a contract request

One entered asset amount drove Bonzo’s former supply modal, which translated the balance selection into an Aave v2-style contract request.

The modal joined four pieces of context: the selected asset, the connected account, the entered quantity and the transaction overview. Selecting the full balance merely populated the amount field; it did not reserve HBAR automatically for a contract fee. The overview described the position impact before the interface handed anything to HashPack or Kabila. A displayed annual percentage yield was a live market input, driven by pool utilization and the interest-rate model, rather than a fixed promise encoded into the signature.

Supplying and collateral selection were related but separate state changes. Bonzo enabled supplied assets as collateral by default, while disabling that role required another transaction after supply. With no outstanding borrow, the collateral flag did not by itself create a liquidation event. A borrowing position used a health factor boundary of 1, so an existing borrower also had to read any projected account impact shown before confirmation.

Wallet approval was the final decision boundary

One wallet decision controlled Bonzo’s final handoff: reject the proposed transaction or sign it with the connected Hedera account.

Account and network

The approval screen identified the payer and network. Mainnet chain ID 295 distinguished the intended ledger from testnet chain ID 296. A mismatch meant the preview belonged to a different account context, so the clean response was to reject it, reconnect the intended account and rebuild the modal.

Amount and contract

The asset amount had to match the figure entered in Bonzo. A Hedera EVM contract address occupied 20 bytes, shown as 40 hexadecimal characters before the optional 0x prefix. The approval represented a smart contract call, not an ordinary transfer to another personal account. Token supplies could add a preparatory allowance request, which explained why the interface referred to required transaction or transactions.

Fee ceiling and validity

The maximum fee in the wallet was a ceiling, not the amount necessarily charged. Gas used by the contract call, transaction size and signature verification contributed to the settled Hedera fee. A standard Hedera transaction validity duration could not exceed 180 seconds. An expired request needed a newly built preview because its transaction ID and valid-start window no longer described a submit-ready instruction.

One successful supply changed two balance views

Two balances moved after one successful Bonzo supply: the wallet’s liquid asset decreased and the protocol’s interest-bearing position increased.

The underlying asset left the spendable wallet balance and entered its single-asset liquidity pool. Bonzo issued an EVM ERC-20 aToken position representing the supplied claim. At settlement, the aToken mapped to the underlying asset at a 1:1 unit relationship, then its displayed balance reflected accrued supply interest. That receipt was the accounting output of the Aave v2 mechanism; it was not an extra reward that doubled the user’s assets.

HBAR required one additional line in the arithmetic because HBAR also paid the network fee. An HBAR supply reduced the wallet by the entered principal plus the charged fee. Supplying USDC instead reduced USDC by the entered principal while the execution fee came from the separate HBAR balance.

Only a successful consensus result produced both the wallet deduction and the protocol balance.

The Supplied panel was the primary position check

Three readings confirmed a completed Bonzo supply: the Supplied amount, the wallet deduction and the matching Hedera consensus result.

Interface position

The Bonzo dashboard placed a completed asset in the Supplied box with its position details. Refreshing once after consensus let the interface fetch the updated account state. A success animation alone was weaker evidence because it described the interface response, while the refreshed panel displayed the position that the protocol associated with the connected account.

Wallet balance

The wallet showed the corresponding asset decrease. For a token supply, the token deduction matched the entered quantity and HBAR covered execution. For an HBAR supply, both principal and fee came from the HBAR line, so the liquid balance fell by more than the supplied amount.

Receipt token

HashPack did not display every Bonzo EVM ERC-20 receipt token automatically. The aToken could require manual addition by its EVM address before it appeared in the wallet’s token list. Its absence from the default view therefore did not outweigh a matching Supplied panel and successful Hedera record. That manual display change did not alter protocol ownership or accrual.

A ledger record separated settlement from display delay

One transaction ID let a Bonzo user separate a settled supply from a delayed dashboard refresh or an unsubmitted request.

HashScan read Hedera mirror-node data and exposed the transaction result, charged fee, consensus timestamp and contract details. A SUCCESS result established that consensus accepted the contract execution. A precheck response or a wallet approval screen did not establish settlement on its own. The transaction ID joined the payer account with a valid-start timestamp, while the consensus timestamp identified the network-ordered outcome with up to 9 fractional digits for nanoseconds.

A Hedera account or contract ID used three numeric parts - shard, realm and number - while an EVM address occupied 20 bytes. Bonzo’s contracts could therefore appear in native Hedera form or hexadecimal EVM form. Matching either representation to the same contract result resolved an apparent address difference without relying on the dashboard label.

When Hedera showed SUCCESS and Bonzo remained stale, one refresh addressed presentation; the ledger still fixed the settled outcome.

A stale wallet session produced a recoverable setup failure

Two logged-in components caused one common Bonzo failure: the interface retained an old WalletConnect session while HashPack used another account.

The recovery used four fresh actions. First, the user disconnected the account inside Bonzo and closed the abandoned WalletConnect pairing. Next, HashPack was unlocked on Hedera mainnet and the intended account was selected. Reconnecting from the Bonzo dashboard created a new account approval, after which the asset and amount were entered again. This sequence rebuilt the transaction context rather than resubmitting an old payload. The rebuilt session also replaced any stale account identifier cached by the browser. While Bonzo Lend remained paused, the process correctly stopped before a supply request appeared.

A locked extension produced a similar symptom because the browser could open the modal without the wallet presenting its approval. Unlocking the wallet before opening Supply restored the handoff when markets operated. Repeatedly pressing the confirmation control did not improve a stale session and risked creating confusing duplicate prompts if the first request was merely hidden behind another window.

An HBAR example reconciled principal and fee

Four hypothetical inputs define this worked Bonzo example: 500 HBAR available, 250 HBAR supplied, a 0.15 HBAR fee and no prior position.

After successful consensus, the liquid wallet balance became 249.85 HBAR: 500 minus 250 minus 0.15. The Supplied panel began with 250 HBAR of principal, represented by 250 units of the corresponding aToken at settlement. The two views therefore reconciled to 499.85 HBAR before subsequent interest: 249.85 remained liquid and 250 was represented inside the lending position. The missing 0.15 HBAR was the network charge, not supplied principal (see Bonzo pricing ).

If the panel and transaction amount did not match, the worked figures would not reconcile. The user would compare the transaction amount, existing position and consensus result before assuming the difference was a display issue. No market price or annual percentage yield was needed for this unit check.

Asset precision changed the encoded supply amount

Six decimal places defined Hedera-native USDC, while HBAR used 8, so Bonzo encoded each supply amount with the asset’s own precision.

One HBAR equalled 100 000 000 tinybars, making 0.00000001 HBAR the smallest native unit. Hedera-native USDC used 6 decimals, so its smallest unit was 0.000001 USDC. The interface converted the human-readable amount into these integer units before the contract call. Extra digits beyond the asset’s precision could not become a smaller on-ledger fraction.

Hedera Token Service assets used a three-part token ID, while EVM ERC-20 assets used a 20-byte contract address. Bonzo supported both forms and issued ERC-20 receipt tokens for lending positions. Confirming the identifier and decimal precision kept a familiar ticker from being paired with the wrong asset representation.

A five-field record preserved the completed decision

Five retained fields preserved a completed Bonzo supply for later verification: account, asset, amount, transaction ID and consensus status.

The account fixed ownership, while the token ID or contract address fixed the asset representation. The amount captured principal in the asset’s own decimals. The transaction ID linked the wallet instruction to Hedera and SUCCESS fixed the settled outcome. Recording the charged HBAR fee separately kept principal, execution cost and accrued interest distinct. For a pre-pause position, these fields reconciled differences across the interface, HashPack and an aToken display. During the pause, no new SUCCESS record meant no new supply. Consensus data outweighed a spinner, a closed wallet window or an unchanged browser message.