Elfi — disclosed vulnerability reports and payouts

Every publicly disclosed and closed bug bounty report we hold for Elfi, with our own summary of each finding and a link to the original disclosure.

Reports indexed
42
Total paid
$0
Critical
0
Largest payout
$0

This page collects the 42 closed, publicly disclosed Elfi reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.

The findings concentrate in Logic error, Integer overflow / underflow, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.

Use the vulnerability class links below to compare these findings against the same bug class in other protocols.

What reviewers look for

  • Logic error findings disclosed against Elfi
  • Integer overflow / underflow findings disclosed against Elfi

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

mediumLogic errorEVM-Solidity$0

Elfi: The implementation of `payExecutionFee()` didn't take `EIP-150` into consideration. Keepers can steal additional execution fee from users.

Elfi's GasProcess.processExecutionFee() undercharges nothing but over-counts gas: it derives the keeper's execution fee as startGas minus gasleft(), yet because the call into the external library is governed by EIP-150, only 63/64 of the remaining gas is forwarded and the 1/64 reserved in the caller is refunded to the keeper while still being counted as consumed. A malicious keeper can raise tx.gaslimit to inflate the reserved portion, inflating usedGas and pushing the computed fee above the user's actual execution cost. In the report's example, raising startGas from 164K to 6500K grows the keeper fee from 101K to 200K Gwei, reducing the user's refund to zero. The confirmed fix multiplies gasleft() by 64/63 to restore accurate accounting.

ElfisherlockJun 20, 2024Open
mediumLogic errorEVM-Solidity$0

Elfi: If stable tokens depeg, short funding fees will not be accounted properly

Elfi's perpetual-futures funding-fee accounting uses a Masterchef-style per-quantity accumulator that is asymmetric: long positions accrue in the base token, but the short-side accumulator is denominated in USD and only converted to the margin token at the current price during settlement. Because the accumulator tracks USD rather than the actual token value over the accrual window, any deviation of the stable margin token from $1 means shorters settle at the latest price instead of the historical average, misattributing funding income and liability. The finding walks through a DAI depeg scenario showing shorters in profit are incentivized to close during a depeg (over-crediting tokens) while those with a loss are incentivized to wait for re-peg, making funding distribution unfair with the pool absorbing the imbalance. The protocol acknowledged the issue and declined to change the code, stating the pool is designed to bear stablecoin fluctuation risk under the assumption that stables trade at $1.

ElfisherlockJun 20, 2024Open
highLogic errorEVM-Solidity$0

Elfi: Anyone can change the balance of an account to drain the entire portfolio vault

Elfi's AccountFacet exposes `batchUpdateAccountToken`, an unauthenticated state-update function that lets any caller overwrite the recorded balance of an account in the portfolio vault without depositing or transferring underlying tokens. Because the mutation performs no access control and no token movement, an attacker can write arbitrarily large amounts for tokens such as USDC and WBTC and then withdraw real funds from the vault. The issue was reported by more than twenty Watson teams, confirmed as high severity, and remediated by the protocol team in a pull request that the Lead Senior Watson signed off on.

ElfisherlockJun 20, 2024Open
highLogic errorEVM-Solidity$0

Elfi: Users can use weth to replace any margin token in createUpdatePositionMarginRequest()

Elfi's PositionFacet.createUpdatePositionMarginRequest fails to validate that the isNativeToken flag matches the position's actual margin token. A user can set isNativeToken=true on a wBTC-margined position, which deposits ether into the shared trade vault while the request records wBTC as the margin token. On keeper execution the add-margin path transfers wBTC out of the vault to the LP pool, letting the attacker convert ether into other traders' deposited margin tokens and, because the vault's wBTC is consumed, block or revert legitimate update requests. The finding was confirmed by the protocol, fixed in a follow-up PR, and signed off by the Lead Senior Watson. The underlying cause is insufficient input validation tying the token deposit to the recorded margin token.

ElfisherlockJun 20, 2024Open
highLogic errorEVM-Solidity$0

Elfi: Closing partial positions miscounts the settled fees

In Elfi's perpetuals protocol, the partial-close path in DecreasePositionProcess._updateDecreasePosition misprices settled fees. Each fee component (borrowing, funding, close) is already scaled down by the decrease quantity ratio, but the aggregate _getPosFees term used in the settleMargin computation divides by that ratio a second time. This under-deducts fees when net fees are positive, inflating the user's recorded PnL, and does the opposite when fees are negative. Because the bug is purely reachable through the normal partial-close flow with no special privileges, any trader can profit by closing positions in two parts instead of one. The finding was accepted as high severity and fixed in the protocol's PR, with the Lead Senior Watson signing off on the remediation.

ElfisherlockJun 20, 2024Open
mediumLogic errorEVM-Solidity$0

Elfi: Incorrect settleFee process for cross-margin account

Elfi's DecreasePositionProcess._settleCrossAccount misfires on cross-margin positions because it applies the generated settle fee (borrow/funding/close) to the account and then, whenever the recorded PnL is non-negative, applies that same fee a second time in the opposite direction. This double-processing means traders who should pay a positive settle fee end up having it refunded, while the protocol cannot correctly redistribute fees between accounts. A secondary defect is that when a positive recordPnlToken is combined with a negative settledFee whose sum is negative, the code calls toUint256() on that negative sum, which reverts and blocks the decrease order entirely. The judges acknowledged the issue, the Elfi team fixed it via pull request 31, and the lead senior Watson signed off on the fix.

ElfisherlockJun 20, 2024Open

All reports in this group

Vulnerability classes disclosed here

Related protocol pages