Autofarm vault types: single-token and LP-token deposits

The asset's role separated the deposit categories

Both categories could appear as one token in a wallet, because a liquidity pool's receipt was itself a token. Counting wallet entries couldn't distinguish a standalone asset from a claim on paired liquidity. The difference concerned what the token represented before it entered the vault.

The V2 pool record paired an accepted token with a strategy contract. The token identified the input, while the linked contract supplied the management logic. That separation allowed a single deposit category to contain strategies with different farm destinations and different ways of handling rewards.

CAKE staking and paired liquidity used different branches

The V2 strategy code distinguished direct CAKE staking from a branch that rebuilt paired liquidity. These branches handled different underlying assets, even though both used the same strategy framework. The deployed configuration selected which route the code followed.

CAKE staking

The V2 StratX2 strategy used PancakeSwap's dedicated staking functions in its CAKE-staking branch. The CAKE-staking flag selected those functions for moving assets into and out of the underlying staking contract. That branch handled the deposited asset without building a trading-pair LP position.

Paired liquidity

A pair-based strategy kept separate identities for the deposit token, the pool's component tokens, and the harvested reward token.

The pool receipt

The wantAddress field identified the asset that the strategy managed for depositors. In an LP strategy, that asset was the pool receipt. The token0Address and token1Address fields identified its components. Those component balances and the deposited LP-token balance represented different assets within the same strategy.

View full-size image

The liquidity inputs

Outside the CAKE-staking and same-asset branches, the auto-compounding code prepared component tokens and added liquidity when both balances were positive. It then farmed the resulting deposit asset. The CAKE-staking and same-asset branches returned to farming before reaching this liquidity-building code.

Did single-token deposits rule out leveraged lending?

No, the V2 Venus strategy could use lending and borrowing beneath a single-token deposit. With leverage enabled, its configured loop supplied the asset and borrowed against collateral repeatedly, then supplied the remaining balance. The borrow depth and borrow rate controlled that loop, so the number of deposited token types didn't describe the borrowing exposure.

A direct staking position and a leveraged lending position therefore belonged to the same broad deposit category while using different mechanisms. Borrowing introduced an obligation within the strategy. Calling the input a single token didn't remove that obligation or make every strategy using that token equivalent. The separate vToken address identified the lending-market receipt, while the deposit address identified the asset supplied to the strategy.

Compounding mode cut across both deposit types

The isAutoComp setting in StratX2 controlled whether its deposit path farmed the received asset or held it within the strategy. The strategy's earn function also required auto-compounding to be enabled. These were settings for the strategy's behavior; single-token and LP-token identified the input.

Farm rewards and AUTO had different roles

A strategy's farm reward token could differ from its deposit asset. The V2 strategy stored those identities separately, allowing reinvestment to convert rewards into the assets needed by the selected branch. A reward balance therefore didn't identify the deposit category.

The main V2 contract handled AUTO emissions separately from the strategy that managed deposits. Receiving AUTO didn't mean the underlying deposit was an AUTO staking position, just as a reward token from an LP farm wasn't itself the LP receipt.

Vault shares and LP tokens measured different claims

AutoFarmV2 calculated a user's deposit-token balance by multiplying their share count by recorded deposit assets and dividing by total shares. The share count was an accounting quantity, not a second name for the deposit-token amount. For an LP vault, the LP token separately represented a claim on the underlying liquidity pool.

There were therefore two layers of proportional ownership. Strategy shares related the depositor to managed deposit assets; LP tokens related those assets to trading liquidity. A raw share count couldn't be read as a fixed quantity of either component token. Neither layer, by itself, supplied a market valuation.

Could a growing LP balance still lose value?

A growing LP-token balance could still lose market value when its underlying assets fell in price. Reinvestment increased the amount held when successful; it didn't set the market price of the pool's assets. Liquidity provision also exposed the position to impermanent loss, a potential shortfall against holding the same starting assets outside the pool. That comparison concerned the changing asset mix within the pool, separately from a general decline in token prices.

Farm rewards and trading fees could offset some of those effects, but the LP category supplied no fixed return.

Network and pool identity completed the classification

The V2 system description covered Binance Smart Chain (BSC), Huobi ECO Chain (HECO), and Polygon. A shared ticker across networks didn't identify one interchangeable position. The network scoped token and strategy addresses. Where a StratX2 branch used a farm pool identifier, that identifier selected a pool within its configured farm contract. An old vault classification therefore needed its network and actual pool identity alongside the single-token or LP description.

Deposit categories didn't fix fees or slippage

The strategy's fee settings and conversion routes affected costs independently of whether it accepted a single token or an LP token. In StratX2, deposit and withdrawal factors applied at different points from fees deducted during reward processing. Those settings didn't follow automatically from the deposit category. A fee deducted from harvested rewards had a different calculation base from a deposit or withdrawal adjustment.

When a branch needed reward conversion, its configured route and slippage setting affected the swaps, while a same-asset branch could avoid the component-token swaps. An LP label couldn't establish identical costs across strategies, and a single-token label didn't promise conversion-free rewards.

Archived designs couldn't confirm an active vault

Autofarm's public code organization was archived on August 9, 2023. That status concerned code maintenance; it didn't establish an identical on-chain outcome for every strategy. An archived implementation explained historical deposit categories without proving that a particular deployment still accepted deposits or could release assets.

The underlying farm's state remained material to a position's operation. Strategy settings could also affect which functions were available, even when its deposit token hadn't changed. A single-token or LP classification described the asset relationship, without establishing operational availability.

CAKE staking remained a documented single-asset branch in the V2 design, regardless of any particular deployment's later condition.