Skip to content

feat: add BabylonSpoke with its own cap-bounded liquidation logic and per-reserve bypass flags - #1343

Closed
avniculae wants to merge 6 commits into
mainfrom
feat/babylon-spoke-generic
Closed

feat: add BabylonSpoke with its own cap-bounded liquidation logic and per-reserve bypass flags#1343
avniculae wants to merge 6 commits into
mainfrom
feat/babylon-spoke-generic

Conversation

@avniculae

@avniculae avniculae commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Alternative to the feat/babylon-spoke branch. All Babylon behavior lives in a BabylonSpoke subclass and a dedicated BabylonLiquidationLogic library; the canonical LiquidationLogic is byte-identical to main and Spoke's only change is virtual on liquidationCall (no bytecode change for canonical instances, so gas snapshots stay at main).

BabylonLiquidationLogic mirrors the canonical sizing and reuses its building blocks (_validateLiquidationCall, _liquidateCollateral/_liquidateDebt, _calculateCollateralToLiquidate, bonus and target-HF formulas) instead of forking them. Its own param structs carry a LiquidationOverrides input, and sizing differs from canonical in three ways: the collateral available for seizure is min(suppliedShares, maxCollateralSharesToRemove) (the cap slots in where the canonical full-collateral bound sits), the dust threshold is a parameter (zero disables dust protection), and bypassTargetHealthFactor sizes the repayment to min(debtToCover, full reserve debt). When the cap binds below the user's balance, the remaining collateral and debt must respect the dust threshold or the call reverts with MustNotLeaveDust. A zero cap degenerates to a zero-amount liquidation, which the Hub rejects, so there is no bespoke zero check.

BabylonSpoke disables the canonical entry (UnsupportedLiquidationCall), exposes the overload with maxCollateralToRemove (uint256.max = no cap), and stores per-reserve LiquidationBypass flags (restricted updateLiquidationBypass; a flag on either reserve of a liquidation applies). The liquidation manager gate comes in a follow-up.

BabylonSpokeInstance exceeds EIP-170 at the standard spoke profile (24,952 bytes at via-ir/750), so it compiles under a new via-ir/200 profile (23,844 bytes, 732 margin). Slimming the contract instead is an option if the lower runs are a concern.

Tests: an equivalence test pins Babylon sizing with neutral overrides to the canonical output; deterministic unit tests cover cap/bypass/dust-threshold sizing including the dust-bump-exceeds-cap revert; an integration suite upgrades a spoke proxy to BabylonSpokeInstance in place. No canonical test or snapshot is modified.

Note for reviewers: repeated fuzz runs on this branch surfaced a pre-existing failure in test_getUserRiskPremium_fuzz_two_users_two_reserves_borrowed that reproduces on unmodified main (forge test --fuzz-seed 0x640, fails within ~20 runs with HealthFactorBelowThreshold). Unrelated to this change; happy to file it separately.

@avniculae
avniculae force-pushed the feat/babylon-spoke-generic branch from e798dcb to daf8f4b Compare August 24, 2026 14:15
@avniculae avniculae changed the title feat: generalize liquidationCall with maxCollateralToRemove and per-reserve bypass flags feat: add BabylonSpoke with cap-bounded liquidationCall and per-reserve bypass flags Aug 24, 2026
@avniculae avniculae changed the title feat: add BabylonSpoke with cap-bounded liquidationCall and per-reserve bypass flags feat: add BabylonSpoke with its own cap-bounded liquidation logic and per-reserve bypass flags Aug 24, 2026
@avniculae
avniculae force-pushed the feat/babylon-spoke-generic branch from 30ffcf9 to de878e0 Compare August 26, 2026 10:12
@avniculae

Copy link
Copy Markdown
Contributor Author

Superseded by #1345: we're going with the dedicated Babylon liquidation logic scoped to the vaultBTC use case instead of generalizing the canonical LiquidationLogic. Keeping this branch around as a reference for the generic-overrides approach.

@avniculae avniculae closed this Aug 27, 2026
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.

1 participant