Autofarm compounding reinvested farm rewards into the vault's deposit asset

Deposit shares measured the claim on compounded assets

A depositor participated through the asset that the selected V2 pool accepted, and a successful deposit recorded internal shares representing a proportional claim on the strategy's deposit tokens, called want in the contracts. For StratX2, the isAutoComp setting determined whether deposits entered the external farm. Its non-compounding branch held the deposit tokens without running that farming path.

For a pool with nonzero total shares, stakedWantTokens() returned user shares multiplied by wantLockedTotal , divided by sharesTotal . Successful reinvestment could increase the deposit tokens backing those shares while leaving the depositor's share count unchanged. The accounting measured token quantities; it didn't assign them a fixed market value. Integer division also made token precision relevant to the smallest recorded changes.

The Deposit event recorded the submitted amount; it didn't measure a later harvest's reinvestment.

Did collecting AUTO also compound the farm rewards?

Collecting pending AUTO through AutoFarmV2 didn't call the strategy's earn() function, which performed farm-reward reinvestment. The main contract calculated AUTO entitlements using a pool's allocation and accumulated rewards per share. Its zero-amount deposit path could process an existing depositor's pending AUTO without adding strategy funds. The transfer was capped by the AUTO balance available in the main contract. Consequently, an AUTO payment showed a reward distribution, while growth in the strategy's deposit-token backing concerned compounding. Pending AUTO used AUTO units, while the depositor's vault claim used the pool's deposit-token units.

How did harvested rewards become deposit assets?

StratX2 restaked rewards directly in its CAKE-staking and same-asset branches, while its paired-liquidity branch rebuilt LP tokens. The function first harvested through the configured external farm. After reward deductions, the direct branches called _farm() and returned without entering the paired-liquidity conversion logic. CAKE staking used PancakeSwap's dedicated staking functions.

For paired liquidity, the strategy allocated half the remaining earned-token amount toward each component. It skipped a component swap when the reward token already matched that component. When both component balances were positive, the strategy passed their available balances to the router's liquidity-addition function and farmed the resulting LP tokens.

Harvesting, conversion, and redeposit were operations within the same earn() call; they didn't require separate user transactions.

Reward deductions came before reinvestment

A positive controller fee reduced the strategy's earned-token balance before the remaining rewards entered the buyback calculation. A positive buyback rate then applied to that remainder. These deductions reduced rewards available for compounding; their calculation base wasn't the depositor's entire vault balance. Zero settings skipped their respective deductions. The deployed strategy's settings therefore affected how much of a harvest reached reinvestment, alongside the conversion prices that its router obtained.

The buyback destination was configurable. In StratX2, rewards already denominated in AUTO could be transferred directly there; other reward tokens used a conversion route. A buyback setting didn't establish an unconditional payment to depositors.

What determined when a V2 strategy could compound?

V2 StratX2 compounded during successful earn() calls, subject to its compounding-mode, pause, and caller checks. The function itself imposed no fixed minimum interval between calls. With onlyGov enabled, the caller had to match govAddress . Disabling that restriction removed the governance-only caller check, while the compounding-mode and pause requirements still applied. Those settings controlled access to the harvest function; elapsed time alone didn't execute reinvestment.

The rest of the call also had to succeed. External farming, reward transfers, and any required conversion depended on their respective contracts. A reverted transaction rolled back its changes, so an attempted harvest couldn't be treated as completed reinvestment. Those dependencies also prevented a fixed harvest frequency from establishing a fixed return.

Venus reward reinvestment followed a separate lending path

The archived Venus strategy harvested its rewards, applied deductions, and converted the remainder into the deposit asset when necessary. In StratVLEV2 , the reward-reinvestment function finished by calling _farm(false) . That argument supplied available assets without running another configured borrowing loop, although the strategy still updated its lending balances and could deleverage when its borrowing relationship exceeded the target; deposits used _farm(true) . Its asset accounting combined idle tokens and supplied assets, then subtracted borrowing. Lending interest could therefore change net backing alongside harvested rewards, so the reward amount alone didn't determine the change in each share's deposit-token claim.

View full-size image

Annualized yield depended on repeated net reinvestment

Compounded growth depended on the rewards that the underlying farm supplied and the deposit assets that conversion actually produced. A projected annual percentage yield (APY) assumed repeated reinvestment. A constant-rate model expressed annual growth as (1 + r)^n - 1 , where r meant the net return per reinvestment expressed as a decimal, and n meant the number of reinvestments over a year. That relationship described compound growth, so dividing the annual yield by the number of days didn't recover its daily rate. Changes in farming income, reward-token prices, deductions, or execution changed the growth that subsequent cycles could produce. Reinvesting more often couldn't fix an underlying decline in the amount earned.

For an LP strategy, accumulating more LP tokens also remained separate from their market value and underlying token exposure. A larger token claim could coexist with a lower monetary value. Lending strategies had an additional dependency on interest and borrowing. StratX2 restaked rewards or rebuilt LP tokens, while supplied assets and outstanding borrowing shaped net backing in StratVLEV2.