Immunefi
Immunefi
Back to Explore
Boost | Lido: Mellow Vault-logo

Boost | Lido: Mellow Vault

Mellow Decentralized Validator Vault

ETH
Defi
DAO
Liquid Staking
Staking
Solidity

Evaluating

10d: 10h remaining
Max Bounty
$100,000
Rewards Pool
$100,000
Vault TVL
To be determined
Started
15 August 2024
Ended
05 September 2024
Rewards Token
DAI
nSLOC
1,281

  • Triaged by Immunefi

  • PoC required

InformationScopeResources

Resources & Documentation

Mellow Vault code commit: https://github.com/mellow-finance/mellow-lrt/commit/1c885ad9a2964ca88ad3e59c3a7411fc0059aa3

Whitehat Educational Resources & Technical Info

Documentation & Resources

Is this an upgrade of an existing system? If so, which? And what are the main differences?

No, it’s a new Mellow project

Where do you suspect there may be bugs?

Most important parts: SimpleDVTStakingStrategy and deposit and withdraw flows, ACLs and ManagedValidator. Invariants: LP token price in ETH is strictly not decreasing.

What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?

Deposit and withdrawals support only ERC20 tokens. System internally can use rebasing tokens such as stETH. Tokens used: wstETH, stETH and wETH

What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

Possible actions: Disable deposits (Enable deposit locks)

What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?

Trusted actors:

  • VaultAdmin: 0x9437B2a8cF3b69D782a61f9814baAbc172f72003 (Lido+Mellow multisig)
  • ProxyVaultAdmin: 0x81698f87C6482bF1ce9bFcfC0F103C4A0Adf0Af0 (Lido+Mellow multisig (ProxyVaultAdmin can change the vault implementation.)
  • CuratorAdmin: 0x2E93913A796a6C6b2bB76F41690E78a2E206Be54 (Steakhouse multisig)
  • CuratorOperator: 0x2afc096981c2CFe3501bE4054160048718F6C0C8 (Steakhouse EOA)

What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?

Trusted actors:

  • VaultAdmin: 0x9437B2a8cF3b69D782a61f9814baAbc172f72003, (Lido+Mellow multisig)
  • ProxyVaultAdmin: 0x81698f87C6482bF1ce9bFcfC0F103C4A0Adf0Af0 (Lido+Mellow multisig (ProxyVaultAdmin can change the vault implementation.))
  • CuratorAdmin: 0x2E93913A796a6C6b2bB76F41690E78a2E206Be54 (Steakhouse multisig)
  • CuratorOperator: 0x2afc096981c2CFe3501bE4054160048718F6C0C8 (Steakhouse EOA)

What external dependencies are there?

Open Zeppelin 5.0.2, Lido

Where might whitehats confuse out-of-scope code to be in-scope?

Lido contracts

Are there any unusual points about your protocol that may confuse whitehats?

In emergency withdrawal we calculate amounts based on ERC20 balances of tokens and not based on baseTvl function (Vault) return values

Which chains are the smart contracts going to be deployed to?

Ethereum Mainnet Docs: https://docs.mellow.finance/mellow-lrt-lst-primitive/contract-deployments#dvsteth-vault

What is the test suite setup information?

https://github.com/mellow-finance/mellow-lrt/tree/fixes/audit-sherlock-fixes/tests/obol

Public Disclosure of Known Issues

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.

  • From Sherlock contest: - We consider the price of 1 steth == 1 eth. - In emergencyWithdraw, we process withdrawals not through the values from baseTvl but through regular ERC20 balances (this is a design decision). - In the SimpleDVTStakingStrategy, the convertAndDeposit function can be front-run by anyone.

  • From ChainSecurity: - The StakingModule may not deposit into the Simple DVT module (due to MinFirstAllocationStrategy in Lido). - Emergency withdrawal (the same second point from Sherlock). - All updates of important parameters can be front-run (this is 5.6 from ChainSecurity).

Previous Audits

Mellow’s completed audit reports can be found at https://github.com/mellow-finance/mellow-lrt/tree/fixes/audit-sherlock-fixes/audits. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

Asset In Scope Policies

Asset Accuracy Assurance

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

Private Known Issues Reward Policy

Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward.

Known Issue Assurance

Lido commits to providing Known Issue Assurance to bug submissions through their program. This means that Lido will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission.

In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.

Primacy of Impact vs Primacy of Rules

Lido adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.

Details
Resources