Skip to content

docs: correct migration slippage cap to 500 bps #1150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
collinsezedike merged 1 commit into from
Oct 23, 2026
Merged

docs: correct migration slippage cap to 500 bps #1150

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 7 additions & 8 deletions apps/docs/operations/migration-keeper.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,7 @@ only the systems that need it, unlike the accrue keeper's key, this is not a
key you'd hand to a low-trust automation path.

The vault contract itself does not restrict which address `migrate_adapter`
can be pointed at beyond `require_admin`, `max_slippage_bps <= 10000`, and
can be pointed at beyond `require_admin`, `max_slippage_bps <= 500`, and
`new_adapter != old_adapter`; there is no on-chain allowlist of permitted
adapter addresses. This differs from the deleted `MeridianRouter`'s
`add_vault`/`remove_vault` allowlist model. The admin gate is the entire
Expand All @@ -133,13 +133,12 @@ deployments fail closed when it's missing, only true local dev is permissive.

- `MERIDIAN_MIGRATION_MAX_SLIPPAGE_BPS` default `100` (1%). Passed directly
to `migrate_adapter`'s `max_slippage_bps` argument. The config loader
rejects only the literal `10000` (unlimited slippage): an unbounded
tolerance would accept a migration that loses an arbitrary fraction of
the vault's position to a stale rate read or a misbehaving adapter.
`9999` (99.99%) is accepted and is functionally equivalent to unlimited;
the check stops one integer short of the guarantee its own reasoning
states. Not tightened here since picking a real ceiling below "unlimited"
is a policy call, not a bug fix, flagging so it isn't mistaken for closed.
enforces the contract's `MAX_ADMIN_SLIPPAGE_BPS` cap of `500` (5%): any
value above it is rejected, since an unbounded tolerance would accept a
migration that loses an arbitrary fraction of the vault's position to a
stale rate read or a misbehaving adapter. See
[`environment-variables.md`](./environment-variables.md) and
[`vault-contract.md`](../architecture/vault-contract.md).
- `MERIDIAN_MIGRATION_MIN_IMPROVEMENT_BPS` default `50` (0.5%). A candidate
protocol's rate must exceed the vault's current rate by at least this
much before a migration is triggered, avoiding fee-losing churn between
Expand Down
Loading