pay_holding_debt requires the owner to send ETH to extinguish storage liabilities. The routine reduces holding_debt, but it never credits company_balance with the transferred funds. Because the contract keeps the ETH on-chain, the internal ledger now understates available liquidity and reports net worth as zero.
Likelihood: Holding debt appears under normal operations whenever _apply_holding_cost exceeds available cash. The owner is incentivized to repay it, so the faulty path is expected during routine maintenance.
Investors cannot withdraw after debt service because company_balance stays at zero, triggering “Insufficient company funds!!!”
get_share_price continues to return zero, freezing new public investment.
Liquidity becomes trapped: the ETH sent to service debt remains on-chain but is unreachable through legitimate flows.
Induce debt by running _apply_holding_cost once company_balance is exhausted (e.g., create inventory, fast-forward time).
Pay the debt exactly: pay_holding_debt with msg.value == holding_debt.
Observe post-call state: holding_debt == 0, company_balance == 0, yet the contract’s actual ETH balance increased by the payment.
Attempt withdraw_shares; it reverts with “Insufficient company funds!!!” despite the contract holding sufficient ETH.
Illustrative pytest-style check:
Accurately mirror liquidity on the ledger:
This approach treats the owner’s payment as cash-in first, then offsets liabilities. The ledger now matches on-chain ETH, preserving withdrawals and accurate share pricing
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.
The contest is complete and the rewards are being distributed.