A newly reported accounting bug in Heliobond’s Stellar-based investment vault could allow queued withdrawals to remain inside the vault’s reported net asset value after the corresponding shares have already been burned, potentially leaving the contract with more withdrawal claims than assets available to back them.
The issue was reported at 09:31 UTC on September 26 against Heliobond’s open-source investment_vault contract. A locally reproduced test submitted with the report ends with the equivalent of 50,000 USDC in total assets while the withdrawal queue is owed 90,040 USDC.
There is no evidence that the bug has been exploited against users, and the issue remains unconfirmed by Heliobond maintainers. Publicly available repository information also does not establish that the affected version of the contract is currently securing mainnet funds.
Still, the reproduction exposes a potentially serious accounting failure if the same code is deployed with real assets because one pool of value can effectively be recognized twice: once as money owed to a user who has already surrendered their shares, and again as assets supporting the shareholders who remain.
Shares Are Burned but the Withdrawal Liability Stays Inside NAV
Heliobond describes itself as a green bond platform built on Stellar. Its InvestmentVault accepts USDC and issues HBS shares representing an investor’s proportional interest in the vault.
The contract calculates total_assets() by adding liquid USDC held by the vault, capital already invested into projects and expected investment returns. Share conversions then use that figure to calculate the amount of HBS issued for deposits and the amount of USDC owed when HBS is redeemed.
The problem appears when the vault does not have enough liquid USDC to immediately satisfy a withdrawal.
According to the GitHub issue and reproduction, the withdrawal function first calculates how much USDC the shares are worth. If the redemption exceeds available liquidity, it burns the investor’s shares immediately and creates a QueuedClaim recording the fixed amount of USDC that investor is owed.
That part of the mechanism is intentional. Instead of keeping the shares outstanding until enough cash returns to the vault, the user receives a place in a first-in, first-out withdrawal queue.
The reported bug is what happens to the accounting afterward.
The USDC owed to the queued investor is not deducted from total_assets(). Because the cash or investments backing that future payment have not yet physically left the vault, they remain included in NAV even though an enforceable withdrawal claim has already been created against them.
At the same time, the withdrawing investor’s shares have disappeared from total_supply.
The result is a smaller number of remaining shares dividing an asset figure that still includes value economically committed to the withdrawal queue. That pushes the calculated value of each remaining share higher.
The Test Ends With $50,000 Backing $90,040 of Queued Claims
The researcher reproduced the problem using two holders, project funding that reduces available liquidity and subsequent redemptions.
Once the larger redemption enters the queue, its HBS shares are burned while the assets backing its USDC claim continue contributing to the vault’s NAV. A later shareholder can then calculate a redemption against that inflated NAV and receive liquid assets that should economically be reserved for the earlier queued claimant.
The deterministic counterexample eventually reaches 50,000 USDC of assets against 90,040 USDC owed to the queue.
The researcher describes the condition as total_assets < queued_liabilities. At that point, even if all assets represented by the vault accounting were recovered, the recorded asset figure would be insufficient to satisfy the queued obligations shown by the test.
The same distortion could affect new investors. Heliobond’s deposit function calculates newly issued shares using usdc_amount × total_supply / total_assets. If total_assets contains assets already promised to queued withdrawals, a new depositor could receive fewer shares than the vault’s true net equity would justify.
That makes this more than a withdrawal-ordering problem. It potentially affects redemption values, deposit pricing and the economic ownership represented by every remaining share after a withdrawal enters the queue.
A repository search also shows the queue being tracked separately through its head, tail and individual QueuedClaim entries, while the share-pricing path continues to derive total_assets from liquid USDC, investments and expected returns. No separate deduction for outstanding queued liabilities was evident in that NAV calculation at the time of review.
No Public Evidence Yet Shows the Bug Is Affecting Mainnet Funds
The distinction between a reproducible code defect and an active exploit is important here.
The issue was still open when reviewed, with no maintainer response confirming the finding and no patch merged to address it. A related pull request adds stateful invariant testing for vault accounting and includes the deterministic queue reproduction as an ignored test so it does not break the normal build before the underlying bug is resolved.
That test suite specifically checks whether total assets remain greater than or equal to queued liabilities, alongside other accounting properties such as share supply consistency and deposit-withdrawal behavior.
More importantly for investors, the repository does not provide enough public deployment information to establish that the current implementation is holding production funds.
Heliobond’s README primarily documents testnet deployment. The checked-in deploy/testnet.json manifest contains placeholder fields rather than active contract IDs. Separate deployment documentation supports both testnet and mainnet deployment, but explicitly notes that mainnet contract IDs are not written back into the public testnet manifest.
That means the absence of a mainnet ID in the repository cannot prove that no mainnet deployment exists. It also means there is currently no public contract identifier in the reviewed material that allows the reported bug to be tied confidently to a live Heliobond vault holding user assets.
Until that link is established, describing the issue as a live loss or exploit would go beyond the available evidence.
The Bigger Risk Is Accounting That Looks Solvent Until Liquidity Is Needed
The bug is interesting because nothing obviously malicious has to happen for the accounting to break.
There is no attacker draining the contract, manipulating an oracle or forging authorization. A user can simply request a legitimate withdrawal at a time when too much capital has been deployed and too little USDC remains liquid.
Once that withdrawal is queued, the vault has created something economically similar to a payable. The former shareholder no longer owns HBS, but the protocol still owes that person a fixed amount of USDC.
Ignoring that liability when calculating NAV is the core problem.
Traditional funds would not normally treat assets committed to redeeming one investor as simultaneously belonging to the remaining shareholders. Tokenized vaults should not either. A smart contract can execute every instruction exactly as written and still produce economically incorrect ownership if the accounting model behind those instructions is wrong.
That is the same broader lesson seen in other crypto failures. A latent transaction-signing bug can remain harmless until a particular edge case activates it, while a live USDC bridge exploit shows how quickly a software weakness becomes an asset-loss event once real liquidity sits behind the code.
Heliobond’s situation is materially different because there is no evidence of exploitation. That is precisely why the timing matters. Finding an accounting invariant failure before meaningful capital is committed is far cheaper than discovering it during a liquidity crunch.
A Fix Needs to Separate Assets From Money Already Promised to Withdrawers
The reporter outlined several possible approaches. The most direct is to calculate shareholder NAV after subtracting outstanding withdrawal liabilities. Another would leave the queued user’s shares outstanding until payment is actually made, preventing the denominator from shrinking before the associated assets leave. A third approach could segregate amounts owed to the queue so they are explicitly excluded from assets available for share pricing.
Each approach has different implementation consequences, but economically they are trying to enforce the same rule: one dollar cannot simultaneously back an exited investor’s withdrawal claim and a remaining investor’s share value.
That rule becomes especially important in vaults investing into less-liquid assets. A protocol can appear comfortably capitalized in aggregate while having insufficient immediately available cash to honor redemptions. Queues are a reasonable mechanism for managing that mismatch, but only if queued obligations remain visible as liabilities.
For Heliobond, the next important developments are therefore technical rather than market-driven: whether maintainers confirm the reproduction, how the NAV logic is changed, whether the invariant is converted into a mandatory passing test, and whether any deployed contract can be shown to run the affected implementation.
The case also illustrates why accounting-focused testing deserves as much attention as conventional security testing. Recent incidents such as the backend wallet compromise at Bitget show that catastrophic crypto losses do not always begin with a broken blockchain primitive. Sometimes the dangerous assumption sits one layer higher.
Here, the questionable assumption is simple: assets still physically inside a vault are treated as belonging to current shareholders even after some of those assets have already been promised to former shareholders waiting in line.
If Heliobond’s production infrastructure has not yet adopted the affected code, issue #640 may amount to exactly what open-source review is supposed to produce: an expensive-looking bug discovered before it becomes an expensive real-world incident.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.