FLOW-12 AutoBalancer Threshold Bounds Allow Impractical Configurations

[nialexsan]

File(s) affected: cadence/contracts/interfaces/DeFiActions.cdc
Description: The threshold validation allows values very close to the extremes:

lower < upper && 0.01 <= lower && lower < 1.0 && 1.0 < upper && upper < 2.0

This allows configurations like: lower = 0.01 (rebalance when value drops to 1% of deposits) upper = 1.99 (rebalance when value
reaches 199% of deposits) Such extreme values are likely configuration errors rather than intentional choices. By the time value drops
to 1% or rises to 199%, the opportunity for meaningful rebalancing may have passed.
Recommendation: Consider enforcing tighter bounds.

[liobrasil]

I think we should keep this as-is and leave the responsibility to the implementer (i.e., the protocol integrating the AutoBalancer) to choose appropriate thresholds. We may even want to remove the upper < 2.0 cap so it’s clear these checks are about ensuring the values are valid and won’t break the protocol, not about providing guardrails for implementers or end-user inputs.

[vishalchangrani]

@vishalchangrani to do more product research.

[vishalchangrani]

FYV currently sets the upper and lower limit to a much tighter band,

$ flow scripts execute get_rebalance_thresholds.cdc 0xb1d63873c3cc9f79 --network mainnet

Result: [0.95000000, 1.05000000]

$ cat get_rebalance_thresholds.cdc 

import DeFiActions from 0x6d888f175c158410

access(all)
fun main(address: Address): [UFix64; 2] {
    return getAccount(address).capabilities.borrow<&DeFiActions.AutoBalancer>(
        /public/FlowVaultsAutoBalancer_0
    )
        ?.rebalanceThresholds()
        ?? panic("No AutoBalancer found at /public/FlowVaultsAutoBalancer_0")
}

[vishalchangrani]

Agree with Lionel's comment. We can go back to Quantstamp and mention that this is as-designed.

[vishalchangrani]

Here is the response for Quanstamp:

Re: FLOW-12 — AutoBalancer Threshold Bounds Allow Impractical Configurations

Thank you for flagging this. After review, we believe the current threshold validation is appropriate and does not require tighter bounds.

The current validation enforces mathematical correctness:

lower < upper prevents inverted thresholds
lower < 1.0 < upper ensures both deficit and surplus conditions can trigger a rebalance
0.01 <= lower provides a practical floor to avoid near-zero precision issues
These are the invariants that prevent protocol breakage. Anything beyond this is a governance decision best left to the integrating protocol.

The production deployment already uses conservative values: FlowYieldVault on mainnet sets its rebalance thresholds to [0.95, 1.05], a tight 5% band around equilibrium.

Threshold selection is a governance responsibility, not a framework constraint. DeFiActions is a composable framework, not an end-user product. Restricting threshold ranges at the framework level would limit legitimate use cases without meaningful safety benefit. The integrating protocol and its governance process are responsible for choosing operationally appropriate thresholds.

For these reasons, we consider this a design decision rather than a vulnerability and plan to keep the current validation as-is.

[vishalchangrani]

hey @liobrasil does this explanation sounds good ☝️

[liobrasil]

hey @liobrasil does this explanation sounds good ☝️

Yes. The explanation is sound: the validation on the framework side is mostly mathematical and there's a distinction between the validation and the use of the operational values for lower and upper.