airKUNAIn short: the mechanism works and it shows in the numbers. Our own position is too small to trigger it, and we first misread that as "nothing is happening". This document corrects that reading and gathers the open questions in one place.
Method — and why to trust it only so far
Every number below was obtained by decoding the Hobba program's Program data: logs via Anchor discriminators (sha256("event:<Name>")[0:8]), using the layout from IDL 0.1.4 (from the npm package @hobba-io/core — the on-chain IDL is not published), plus direct reads of account state from mainnet.
Nothing was copied from a user interface. Where we had to assume something, it says so explicitly below.
How the harvest actually works — and why zero does not mean zero
Yield does not arrive as a transaction. It accrues in the vault share price. Only the harvest_vault instruction crystallises it: it computes profit as share value − cost basis, takes the fee, splits the remainder between debt repayment and a user payout — and only then emits UserHarvestPayout with the fields gross_harvest, fee_amount, debt_repaid, user_amount.
debt_repaid means "not crystallised", not "not earned".| What our position account holds | Mint | Amount |
|---|---|---|
| Vault share — the yield-bearing asset | star9ag…RGiFM | 34.713899 |
| Position token (Hobba) | B7opsVGR…irYCwB | 1 |
| WSOL | So1111…111112 | 0 |
| USDC | EPjFWdd5…yTDt1v | 0 |
The mint authority of that share is exactly current_vault from our UserState account — confirmation that it really is the vault share token and not something else. The implied acquisition price per share: 37.403475 ÷ 34.713899 = 1.077478. The position is in profit if the current share price is above that. We did not read the current price — see question 2.
An observed threshold: the harvest only starts at ~1 USDC
The question that prompted this document: why is our position not among the 22 receiving harvests, even though the leveraged capital is properly deployed? We looked at all 60 positions with OperatorBorrowed and compared them against harvest counts.
| Borrowed (total, USDC) | Harvests | Average per harvest |
|---|---|---|
| 47,747.75 | 170 | 1.6659 |
| 29,216.25 | 180 | 1.3245 |
| 17,127.67 | 52 | 1.1019 |
| 4,411.40 | 108 | 1.1984 |
| 624.25 | 13 | 1.0228 |
| 233.09 | 2 | 1.0008 |
| 77.23 | 2 | 1.0035 |
| 49.32 | 2 | 1.0025 |
| 39.09 | 1 | 1.0015 |
| 45.04 — our position | 0 | — |
The pattern: the average per harvest sits between 1.0 and 1.7 USDC regardless of position size. If harvesting ran on a schedule, large positions would show multiples of that per harvest. Instead the large ones simply cross the threshold more often (170–180 times), while small ones cross it once or never — and the first harvest of every small position is 1.0008–1.0035 USDC. That looks like a fixed threshold of ~1 USDC, not a percentage one.
What that means for us specifically
With ~37.4 USDC in the vault and ~8.2% APY from the snapshot, accrual runs at about 0.0084 USDC per day. To date ≈ 0.18 USDC. Reaching the 1 USDC threshold needs roughly 98 more days → a first harvest around 2 November 2026.
A consequence worth saying out loud: repayment of a small loan is lumpy, not smooth. A hundred days of nothing, then suddenly ~0.85 USDC (1 USDC gross minus the 15% fee) lands against a debt of 1.14. That does not overturn our earlier "~8 months" projection — it gives it a shape.
The 8.2% APY is an assumption taken from the interface snapshot of 8 Jul, not a measurement. The exact accrued yield would come from the current share price — see question 2.
Eight questions that cannot be answered from outside
Ordered by how much they change the picture for an end user.
Is there a minimum harvest threshold, and is it in the contract or in operator policy?
The data suggests ~1 USDC. If that is a fixed threshold, small positions wait months for their first repayment — which is perfectly fine, but it should be in the documentation, because otherwise "self-repaying" sounds like a daily process.
Can the current vault share price be read without simulating a transaction?
Without it a user cannot compute how much they earned between two harvests — and that is the one number that actually tells them whether their capital is working. A price_of_share instruction exists, but it has to be simulated; there is no read-only account holding the price.
Does the liquidation threshold look at gross or net encumbrance of the collateral?
Two debts hang off our 1 SOL: our 1.14 USDC and the operator's 45.04 USDC. The interface shows an LTV of 1.5% — that is the user loan only. Gross encumbrance of the same collateral is ~60%, against a liquidation threshold of 85%.
Economically the operator's 45 USDC is covered by the vault position it bought (a carry trade, net flat). But if the liquidation logic looks at gross debt, the message "SOL would have to fall 98%" is considerably too optimistic.
Which debt does debt_repaid pay down — the user loan or the operator leverage?
On our position OperatorRepaid (7.634980 USDC, 12 Jul) was a separate event, not part of a harvest — which suggests two distinct paths. From outside it is not visible which of them the harvest services.
Is the vault really Perena?
The account sM6P4mh5…QF7A is owned by the program save8RQ…pD9H (the Save / ex-Solend family), while the IDL enum says vault_provider = 1 (Perena) and the interface on 8 Jul read "Perena USD vault". It may be a white label; we have confirmed neither, and so we assert neither anywhere.
Why does our position have a different operator from the global one?
UserState.operator = 67aoqr6W…Rfvk, while ProgramConfig.operator = FHgh76AC…tgCYg. Set by the SetUserOperator instruction on 12 Jul 2026. We assume it is deliberate, but we do not know whether it means anything for servicing cadence.
Is 15% now the steady state?
Measured day by day: 0% until 7 Jul 2026, 25% from 9 to 12 Jul, 15.000% from 14 Jul onwards — exactly, every day. Today profit_fee_bps = 1500. An admin can change the fee (set_profit_fee), and the documentation does not mention it at all.
Registering airKUNA as an "origin" channel
The mechanism works and is measurable: since 23 Jul 2026 the first partner channel (origin 1) has received 1.5590 USDC over five days — the ratios of 15.000% fee and 60.000% partner share come out exactly. We are asking for the same arrangement, with a Squads v4 vault as the receiver (for which a precedent already exists in origin 1).
What is, measurably, good
So the list of questions does not leave the wrong impression — these are findings in Hobba's favour that we also measured rather than assumed:
- The engine really does repay debt. The sum of the
debt_repaidfield across all harvests: 1,033.01 USDC out of 1,280.73 USDC of harvested yield (14 Apr – 27 Jul 2026). - It runs without interruption. 699 harvests in 32 days, without a single day off; the latest on the day of measurement.
- The fee is exactly what it claims to be — 15.000% of yield, never of principal, confirmed in every harvest since 14 Jul.
- The partner split is exact — 60.000% of the fee to the partner, to three decimal places.
- Growth comes from deposits, not from price. TVL $259,862 (8 Jul) → $345,544 (27 Jul), while the SOL price fell over the same period ($77.76 → $76.41).
- Events and account state agree to the last digit.
45.038455 − 7.634980 = 37.403475= the livedeposited_to_vaultvalue. There is no discrepancy between what the contract emits and what it holds.
Check for yourself
Addresses and sources
Hobbakk1LmW2DhE4nAKnCeU1iK7V7pKHTq3ihaE2i8qG · Solscan ↗Our wallet:
6bwzpkSKSXbjVMBYMSdazEytkaCZatibRdmExpjSgCyA · Solscan ↗Our position account:
A2Pmj1ArCn3REhAnpbXcqqgHNcrrexLPEA1YdK9oyLEX · Solscan ↗ProgramConfig:
9fisLWPRhyfhaQfi1GbpSvJPSSr11h7iS3oLabRtiAPf · Vault: sM6P4mh53CnG4faN4Fo3seY7wMSAiHdy8o6gKjwQF7AShare mint:
star9agSpjiFe3M49B3RniVU4CMBBEK3Qnaqn3RGiFM · Obligation (JupLend): 9dvcngz5zNuzncwzY7AWrCpLPrtmUVyaz6mgCgivb9qYDune queries: 8127360 (harvest population) · 8125404 (fee/origin split) · 8125398 (event mix) · 7530804 (TVL)