Case Study
Shepherd Secures Ebisu Finance Ahead of Mainnet Launch
Feb 10, 2026
Introducing Ebisu
Ebisu Finance is a collateralized debt position (CDP) stablecoin credit market built on Liquity V2. Ebisu offers leveraged vaults products that automate multi-step operations involving flash loans, DEX swaps, and trove management.
Ahead of launch, Ebisu engaged Shepherd to perform targeted, execution-level validation that the LeveragedVault behaved correctly under real conditions, specifically how the vault interacts with and drives value through the underlying CDP system.
Where Shepherd Came In
The Liquity V2 base layer had already been through prior extensive audits. But the LeveragedVault introduced a new product surface, combining debt accounting, flash loans, DEX routing, ERC-4626 semantics, and permissionless rebalancing into a single user-facing flow.
When you're composing across flash loans, DEX routes, and branch-level debt accounting in a single tx, bugs that break user trust live in the integration layer. Ebisu needed to know those integration points held.
Findings
Slippage estimation logic diverged from actual execution.
DESCRIPTION
The vault's preview functions derived flash loan amounts directly from the user's deposit size. The actual deposit path computes them from the gap between the vault's current and target leverage — factoring in existing collateral, debt, and market movements that the estimation logic ignores entirely.
IMPACT
Users would see one slippage number in the UI and experience a different outcome on-chain. For a product where trust starts with accurate previews, that gap undermines confidence from the first transaction.
FIX
Estimation functions were refactored to replicate the vault's actual rebalancing calculation, simulating the post-deposit state and computing flash loan requirements from the resulting leverage gap.
Estimation functions misreported whether deposits would succeed.
DESCRIPTION
The vault's estimateDepositSlippage function returned wouldRevert: false for zero-amount deposits and any deposit below the vault's minDeposit threshold. The actual deposit path reverts with DepositTooSmall for these inputs.
IMPACT
Frontends relying on these estimates would enable deposit buttons for amounts that fail on-chain, costing users gas on transactions that go nowhere.
FIX
Estimation function updated to return wouldRevert: true for deposits at or below the minimum threshold.
The trust boundary around trove transfers was wider than intended.
DESCRIPTION
The vault's onERC721Received handler validated that the trove's owner was an authorized keeper but didn't restrict the operator, the address that actually initiated the transfer. Under ERC-721, any address a keeper has approved via approve() or setApprovalForAll() could execute trove transfers to the vault.
IMPACT
A keeper granting operator approvals for unrelated purposes (marketplace integrations, management tools) would inadvertently extend those privileges to vault operations — widening the attack surface beyond the documented trust model.
FIX
Operator validation added to restrict trove transfers to explicitly authorized addresses.
All three were low severity findings, acknowledged and resolved by the team, and re-validated against the same execution framework before launch.
The Impact
Ebisu shipped on their original timeline with traced, reproducible evidence that the vault behaves as designed under realistic conditions. The testing infrastructure carries forward for future vault strategies, collateral types, and upgrades.
Launching Soon?
We help teams ship with more securely and confidently. If you're approaching a launch or are looking to level up your security, we’d love to talk.