Autofarm
Autofarm fees varied with the vault's settings
Autofarm fees depended on the vault's deployed settings and the operation that incurred the charge. Archived V2 strategies separated deductions from harvested rewards, adjustments to deposit shares, and reductions on withdrawals. Each used its own calculation base, so adding the percentages wouldn't describe a depositor's total cost. AutoSwap had a separate swap-fee mechanism. Autofarm's public code organization was archived on August 9, 2023; these historical rules don't establish today's rates or a vault's operating status.
Reward percentages measured deductions from earned tokens
The archived StratX2 code expressed its controller and buyback settings as fractions of 10,000, making each unit one basis point. One basis point equaled 0.01%. Dividing a setting by 100 gave its percentage, while dividing by 10,000 gave the multiplier applied to its balance.
The controller charge used the earned-token balance that the strategy held when
earn()
processed rewards. It wasn't an annual percentage of the entire deposit. For a positive setting, the calculated deduction scaled with the earned-token balance, subject to integer rounding. A deposit's changing fiat valuation didn't enter that calculation. Reward tokens and deposit tokens also needed separate accounting whenever they were different assets.
Sequential deductions changed the combined reward cost
StratX2's
earn()
function passed the earned-token balance through the controller-fee calculation before the buyback calculation.
For earned-token balance
R
, controller setting
C
, and buyback setting
B
, the remainder before further conversion was
R × (1 - C / 10,000) × (1 - B / 10,000)
. This expressed the relationship before integer-rounding effects. The second deduction used the balance left after the first, so adding the two percentages overstated their combined effect whenever both applied.
The combined fraction removed was one minus the product of those retained fractions.
StratX2 transferred the controller portion to its configured
rewardsAddress
in the earned token. A positive buyback allocation went to
buyBackAddress
as AUTO, directly when AUTO was the earned token and through a swap otherwise. The configured governance address could change both recipients. The function's name alone didn't establish that every deduction burned tokens or paid AUTO stakers.
Entry factors changed the shares credited to a deposit
StratX2 applied its entrance factor in the proportional deposit calculation only when existing managed tokens and existing shares were both positive.
Internal shares represented a claim on the strategy's deposit tokens, called
want
. The factor affected the shares credited, while the strategy received the deposited tokens.
For deposit amount
D
, existing shares
S
, and existing managed deposit tokens
W
, that branch calculated
D × S × entranceFeeFactor / W / 10,000
. Its governance setter allowed factors from 9,950 to 10,000. Those endpoints represented a 0.5% reduction and no reduction in the proportional share calculation. They didn't describe an identical percentage loss in the new deposit's resulting asset claim. When either existing quantity was zero, the shown branch assigned shares equal to the deposit amount and skipped the factor.
Exit factors reduced the tokens returned
A withdrawal factor below 10,000 reduced the deposit-token amount that the strategy returned to the main Autofarm contract. At that step, StratX2 calculated
requested amount × withdrawFeeFactor / 10,000
. A factor of 10,000 made no reduction. Its governance setter allowed values down to 9,950, equivalent to a 0.5% reduction at that step.
Available balances could impose another limit. StratX2 applied the factor first and, when compounding was enabled, withdrew from the external farm. It then capped the amount against available tokens and its recorded locked balance. StratVLEV2 capped the amount against available tokens before applying its factor. Receiving fewer tokens than requested didn't, by itself, identify the fee. A configured deduction and a shortfall in available assets had different causes.
Fee settings governed different quantities
StratX2 and StratVLEV2 used separate settings for rewards, deposits, and withdrawals. AutoSwap's controls governed its swap output, while slippage settings constrained conversion.
| Contract setting | Quantity affected | Condition for use |
|---|---|---|
| Vault controllerFee | Earned-token balance | Positive fee and earned balance |
| Vault buyBackRate | Rewards remaining after controller deduction | Enabled buyback |
| Vault entranceFeeFactor | New internal shares | Managed-token balance and internal share count both positive |
| Vault withdrawFeeFactor | Deposit tokens returned | Factor below 10,000 |
| StratX2 slippageFactor | Minimum reward-swap output | Conversion through the configured router |
| AutoSwap feeRate | Output above guaranteedAmount | Positive surplus and nonzero rate |
| AutoSwap referrerFeeRate | Share of the calculated swap fee | Eligible recipient and successful transfer |
| Each setting governed its own calculation; the values weren't additive percentages of one common balance. | ||
How did AutoSwap calculate its own charge?
The archived AutoSwap contract calculated its fee on output above
guaranteedAmount
when
feeRate
was nonzero.
For output
O
above guarantee
G
, the calculation was
(O - G) × feeRate / 10,000
. Output at or below the guarantee bypassed this fee. The base wasn't the entire trade value.
A referrer qualified only if its address was nonzero and differed from both the caller and transaction origin. It could receive part of the fee, reducing the owner's portion without adding a surcharge. Actual deductions depended on successful transfers. The contract then required post-fee output to meet
minOutAmount
, separately from the guarantee used for fee calculation.
Gas and reward conversion added separate costs
Network execution and reward swaps carried costs beyond the configured vault deductions, so a zero withdrawal adjustment didn't describe every expense. For BNB Smart Chain transactions, gas used and gas price determined the network cost. Gas paid for computation, independently of the deposit-token balance. An approval transaction, when required separately, had its own execution cost. A fixed fiat estimate couldn't apply to every interaction.
A trading charge imposed by the underlying exchange affected the amount left for reinvestment. Separately, StratX2's
slippageFactor
set a minimum using the router's quoted output multiplied by the factor and divided by 1,000. This tolerance didn't mean every swap lost that fraction. It constrained acceptable execution; the actual output depended on the route and liquidity.
Leveraged Venus positions carried borrowing costs
The archived StratVLEV2 strategy supplied and borrowed assets on Venus, making borrowing costs relevant alongside its controller and buyback deductions. Its net-asset formula added local holdings to supplied assets, then subtracted borrowed assets. For WBNB deposits, those holdings included WBNB and native BNB. That net amount underpinned the assets represented by internal shares. Treating the supplied balance as the whole position ignored the outstanding debt.
The strategy's updateBalance() function refreshed cached supply and borrowing balances to account for accrued interest. Its withdrawal path could unwind borrowing when locally available tokens weren't sufficient. Changes in lending income and borrowing expense affected net assets independently of an entry or exit factor. These quantities described the underlying position, so they couldn't be folded into an additional universal Autofarm fee percentage.
Code limits didn't establish a vault's actual rate
StratX2's governance setter capped the controller setting at 300 and the buyback setting at 800, each against a 10,000 denominator. Those were setter ceilings of 3% and 8%, respectively. They weren't the rates charged by every deployment. The StratX2_PCS constructor accepted fee parameters, and subsequent governance calls could change deployed settings within the setter's bounds.
Initial values in an archived source file couldn't establish the settings that applied to an individual transaction. Deployed parameters could differ between pools, and governance updates could change them again. The code archive also didn't establish whether a deployed vault had funds available.
For an existing position, an exit-cost estimate needed the selected pool's withdrawal factor and available deposit tokens, with network gas counted separately. A historical annual percentage yield, or APY, couldn't supply those inputs. Compare token deductions in their own units before combining any costs in a common valuation.
Frequently asked questions about Autofarm fees
Were pending AUTO payouts subject to the StratX2 controller fee?
Pending AUTO payouts followed AutoFarmV2's separate reward accounting, outside the StratX2 controller-fee calculation. The main contract handled those payouts during ordinary deposit and withdrawal calls. StratX2 applied its controller fee to the earned-token balance processed by its strategy. Distinguishing the two balances avoided treating every AUTO payment as a harvest-fee deduction.
Could an emergency withdrawal bypass a vault's withdrawal factor?
The archived AutoFarmV2 emergency function still called the pool strategy's withdrawal function, so it didn't provide a blanket fee bypass. That path omitted the ordinary pending AUTO payout and still attempted the calculated pre-fee token transfer. If the main contract lacked enough deposit tokens afterward, the call could revert.
Did keeping a deposit longer reduce its V2 entry or exit charge?
The shown StratX2 entry and exit calculations used configured factors without a deposit-age discount. A governance change could alter the exit factor while a position remained open, but that wasn't a discount earned through waiting. Compounding could also change the token balance to which an eventual exit adjustment applied.
Can I choose a lower fee when withdrawing from an AutoFarmV2 pool?
AutoFarmV2's ordinary withdrawal call accepted a pool identifier and a requested token amount, without a user-selected fee parameter. The strategy's configured factor governed the fee step. StratX2 restricted changes through setSettings() to its governance address, so changing the requested withdrawal amount didn't grant control over the factor.
Why could a Deposit event show a different number from the credited shares?
The AutoFarmV2 Deposit event recorded the input token amount, while the strategy calculated and returned internal shares. Those quantities used different accounting units. Existing assets per share and an applicable entrance factor affected the shares credited, so subtracting the share count from the event's token amount didn't produce a valid fee calculation.
Was the comment beside withdrawFeeFactor enough to identify a charge?
The adjacent StratX2 comment didn't reliably describe the initialized withdrawal factor. It mentioned 0.1%, while the displayed initialization was 10,000, which produced no reduction at that step. Constructor parameters and later governance updates could establish different deployed values. The comment alone therefore couldn't identify the charge applied to a particular vault transaction.