Skip to content

Consider APY impact for deposits#2857

Merged
shahthepro merged 13 commits intoshah/auto-rebalancerfrom
shah/rebalancer-apy-impact
Apr 7, 2026
Merged

Consider APY impact for deposits#2857
shahthepro merged 13 commits intoshah/auto-rebalancerfrom
shah/rebalancer-apy-impact

Conversation

@shahthepro
Copy link
Copy Markdown
Collaborator

Code Changes

  • Compute/Estimate current APY of Morpho Vaults
  • Figure out APY impact for deposits and skip if it's over a threshold

Copy link
Copy Markdown
Collaborator

@clement-ux clement-ux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few questions on the new APY-impact path. Not blocking — mostly want to confirm intent.

let best = { maxDeposit: BigNumber.from(0), impactBps: 0, postDepositApy: 0 };

while (hi.sub(lo).gt(step)) {
const mid = lo.add(hi).div(2).div(step).mul(step); // round to step
Copy link
Copy Markdown
Collaborator

@clement-ux clement-ux Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the binary search collapses to zero on small ranges. With step = $100K and lo = $5K, say maxAmt = $150K and the fast path failed:

iter 1: mid = (5K + 150K) / 2 = 77.5K → /100K * 100K = 0 → mid.lt(lo) → break
returns { maxDeposit: 0 }

So any strategy with maxPossible below ~2 * step ($200K) whose full amount fails the impact check always returns zero, even when $50K or $100K would have been fine. The fast path gets one shot; if it fails the search can't make forward progress.

Also best starts at zero and only updates inside the impactBps <= max branch, so if the first probe is over the threshold and the loop exits, we return zero without ever probing lo itself. The implicit "minMoveAmount is always acceptable" assumption never gets verified.

Probably matters most for the smaller cross-chain strategies (Base/HyperEVM) where target allocations could routinely sit in that <$200K range.

A few ways out: skip the search entirely below 2 * step, shrink the step when the range is narrow, or just probe lo as a final fallback before giving up.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is something we will run with almost any step amount. Right now, I set it to 100k because we barely have 4mil in TVL. Reducing that to 50k or even 10k would cover the case all the time but it'll go through more iterations on the binary search. I'll check if any of the options you listed would work

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wait, I misunderstood this one. Will fix this

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the logic to use a different step if the range is too narrow: 644d180

@shahthepro shahthepro merged commit ce3541c into shah/auto-rebalancer Apr 7, 2026
11 of 16 checks passed
@shahthepro shahthepro deleted the shah/rebalancer-apy-impact branch April 7, 2026 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants