DYAD - Jorgect's results

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/4a987e536576139793a1c04690336d06c93fca90/src/core/VaultManagerV2.sol#L101

Vulnerability details

Users can add and remove vaults through the add and remove functions.

 function add(uint256 id, address vault) external isDNftOwner(id) {
        if (vaults[id].length() >= MAX_VAULTS) revert TooManyVaults();
        if (!vaultLicenser.isLicensed(vault)) revert VaultNotLicensed();
        if (!vaults[id].add(vault)) revert VaultAlreadyAdded(); 
        emit Added(id, vault);
    }

function remove(uint256 id, address vault) external isDNftOwner(id) {
        if (Vault(vault).id2asset(id) > 0) revert VaultHasAssets(); <-------
        if (!vaults[id].remove(vault)) revert VaultNotAdded();
        emit Removed(id, vault);
    }

[Link]

The remove function is checking is the nft has balance associate in the vault to remove (see the arrow above).

The problem is that an attacker can deposit on behalf of any nft id, so attacker can front run the remove transaction of a user sending 1 wei to the same vault that user is trying to remove, successfully making revert the user transaction.

Impact

Remove function can be DOS to any honest user trying to remove a vault of his nft.

Proof of Concept

See the deposit function:

 function deposit(
    uint    id,
    address vault,
    uint    amount
  ) 
    external 
      isValidDNft(id) <-----
  {
    idToBlockOfLastDeposit[id] = block.number;
    Vault _vault = Vault(vault);
    _vault.asset().safeTransferFrom(msg.sender, address(vault), amount);
    _vault.deposit(id, amount);  <------
  }

[Link]

As we can see the deposit functions is allowing any user(or attacker) to deposit in any vault and any nft id, the only validation associate with the nft is if the nft id is valid (see the first arrow above). see the vault deposit call (second arrow above):

function deposit(
    uint id,
    uint amount
  )
    external 
      onlyVaultManager
  {
    id2asset[id] += amount;  <-----
    emit Deposit(id, amount);
  }

[Link]

As you can see the deposit function is incrementing the id2asset[id] in the vault(see arrow above) same variable that have to be zero to remove an vault from a nft id.(see arrow above)

function remove(uint256 id, address vault) external isDNftOwner(id) {
        if (Vault(vault).id2asset(id) > 0) revert VaultHasAssets(); <-------
        if (!vaults[id].remove(vault)) revert VaultNotAdded();
        emit Removed(id, vault);
    }

[Link]

So an attacker can:

1. See the a honest remove transaction of a user.
2. Front running this transaction sending a deposit transaction with more amount of gas than the remove transaction, the attacker has to pass the vault that honest user want to remove, the id of the nft and 1 wei of the asset into the deposit transaction.
3. Remove transaction of the honest user revert.

Tools Used

Manual review.

Recommended Mitigation Steps

The most straightforward solution is changing the isValidDNft(id) modifier in the deposit function for the isDNftOwner(id) modifier. (This have to be carefully review and may be different from the design of the project).

Assessed type

DoS

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/4a987e536576139793a1c04690336d06c93fca90/src/core/VaultManagerV2.sol#L143

Vulnerability details

User can deposit and withdraw from a vault through the deposit and withdraw functions

function deposit(
    uint    id,
    address vault,
    uint    amount
  ) 
    external 
      isValidDNft(id)
  {
    idToBlockOfLastDeposit[id] = block.number;  <-----
    Vault _vault = Vault(vault);
    _vault.asset().safeTransferFrom(msg.sender, address(vault), amount);
    _vault.deposit(id, amount);
  }

  /// @inheritdoc IVaultManager
  function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
    if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock(); <-----
    uint dyadMinted = dyad.mintedDyad(address(this), id);
    Vault _vault = Vault(vault);
    uint value = amount * _vault.assetPrice() 
                  * 1e18 
                  / 10**_vault.oracle().decimals() 
                  / 10**_vault.asset().decimals();
    if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat();
    _vault.withdraw(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO)  revert CrTooLow(); 
  }

[Link]

As you can see in the arrows above users can just use deposit and withdraw function one time each block.number.

The problem is that an attacker can deposit on behalf of a nft setting the idToBlockOfLastDeposit[id] = block.number so he can see the withdraw function in the mempool and front run depositing one wei in any vault, this vault can be even a fake vault.

Impact

withdraw function can be complete DoS by an attacker stucking the funds of the user in the contract.

Proof of Concept

As you can see in the deposit function any user(or attacker) can deposit on any vault and set the idToBlockOfLastDeposit[id] variable to the last block.number (see the first arrow above):

function deposit(
    uint    id,
    address vault,
    uint    amount
  ) 
    external 
      isValidDNft(id)
  {
    idToBlockOfLastDeposit[id] = block.number;  <-----
    Vault _vault = Vault(vault);
    _vault.asset().safeTransferFrom(msg.sender, address(vault), amount);
    _vault.deposit(id, amount);
  }

  /// @inheritdoc IVaultManager
  function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
    if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock(); <-----
    uint dyadMinted = dyad.mintedDyad(address(this), id);
    Vault _vault = Vault(vault);
    uint value = amount * _vault.assetPrice() 
                  * 1e18 
                  / 10**_vault.oracle().decimals() 
                  / 10**_vault.asset().decimals();
    if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat();
    _vault.withdraw(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO)  revert CrTooLow(); 
  }

[Link]

So an attacker can:

1. See the a honest withdraw transaction of a user.
2. Front run this transaction sending a deposit transaction with more amount of gas than the withdraw transaction, the attacker has to pass a vault(this vault can be a fake vault), the id of the nft and 1 wei of the asset into the deposit transaction.
3. withdraw transaction of the honest user revert.

Tools Used

Manual review

Recommended Mitigation Steps

The most straightforward solution is changing the isValidDNft(id) modifier in the deposit function for the isDNftOwner(id) modifier. (This have to be carefully review and may be different from the design of the project).

Assessed type

DoS

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/VaultManagerV2.sol#L150

Vulnerability details

There are two types of vault in the protocol kerosene(vaultsKerosene) and nonkerosene(vaults), the collateral allocate in nonkerosene behave as exogenous collateral which have to be at least equal to the dyad minted:

 function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
    if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock();
    uint dyadMinted =+ dyad.mintedDyad(address(this), id);
    Vault _vault = Vault(vault);
    uint value = amount * _vault.assetPrice() 
                  * 1e18 
                  / 10**_vault.oracle().decimals() 
                  / 10**_vault.asset().decimals();
    if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat(); <-----
    _vault.withdraw(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO)  revert CrTooLow(); 
  }

[Link]

The withdraw function is checking is user have enough exocollateral left in the NonKeroseneVault if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat(); the problem is that this value is substrate no matter is the collateral is keroseneVault or NonkeroseneVault.

Imagine that a user have exact quantity of getNonKeroseneValue(id) and dyadMinted(which is correct) when this user want to withdraw his kerosene vaults assets(supossing that his collatRatio is major than the minimum obviously) the transaction will revert because the check is resting the value to the nonKeroseneValue even if the collateral to withdraw is kerosene.

Impact

the kerosene collateral assets of users may get stuck in the contract.

Proof of Concept

 function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
    if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock();
    uint dyadMinted =+ dyad.mintedDyad(address(this), id);
    Vault _vault = Vault(vault);
    uint value = amount * _vault.assetPrice() 
                  * 1e18 
                  / 10**_vault.oracle().decimals() 
                  / 10**_vault.asset().decimals();
    if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat(); <-----
    _vault.withdraw(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO)  revert CrTooLow(); 
  }

[Link]

As you can see in the arrow above the function is checking is the user exocollateral is major or equal of the dyadminted, if not revert, the problem is that this condition is not checking if the value is from a NonkeroseneVault of keroseneVault.

See the next example:

1. User have 100 usd in exocollateral (depositing in a nonKeoseneVault).
2. User have 65 usd in kerosene Vaults (no matter the assets).
3. User mint 100 dyad (min collateral ratio is 1.5 so is good).
4. User want to withdraw 10 usd from his kerosene Vaults.(it can because his collateral ratio is still more than 1.5).
5. withdraw Transaction revert because exocollateral is 100 subtracting the 10 to withdraw we get 90 this is less than the 100 dyad minted.

The user is trying to withdraw 10 dollar from his kerosene vault but he can not because the function is assuming that user is withdrawing exocollateral.

Tools Used

Recommended Mitigation Steps

Consider subtract the value in getNonKeroseneValue(id) just is the collateral is in NonKeroseneVaults:

 function withdraw(
    uint    id,
    address vault,
    uint    amount,
    address to
  ) 
    public
      isDNftOwner(id)
  {
    if (idToBlockOfLastDeposit[id] == block.number) revert DepositedInSameBlock();
    uint dyadMinted =+ dyad.mintedDyad(address(this), id);
    Vault _vault = Vault(vault);
    uint value = amount * _vault.assetPrice() 
                  * 1e18 
                  / 10**_vault.oracle().decimals() 
                  / 10**_vault.asset().decimals();
if (vaults[id].contains(vault){
    if (getNonKeroseneValue(id) - value < dyadMinted) revert NotEnoughExoCollat(); } <-----
    _vault.withdraw(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO)  revert CrTooLow(); 
  }

Assessed type

Other

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/VaultManagerV2.sol#L221

Vulnerability details

User have two type of vaults to deposit, kerosene and non kerosene each type have his own vaults to deposit for (vaults[id] for non kerosene and vaultsKerosene[id] for kerosene).

  mapping (uint => EnumerableSet.AddressSet) internal vaults; 
  mapping (uint => EnumerableSet.AddressSet) internal vaultsKerosene; 

[Link]

non Kerosene vaults are used as exocollateral, users need to have at least the same amount of nonKerosene of the minted dyad, the rest of the collateral can be collateral allocate in kerosene vaults because you need at least 1.5 of collateral for 1 unit of dyad:

 function mintDyad(
    uint    id,
    uint    amount,
    address to
  )
    external 
      isDNftOwner(id)
  {
    uint newDyadMinted = dyad.mintedDyad(address(this), id) + amount;
    if (getNonKeroseneValue(id) < newDyadMinted)     revert NotEnoughExoCollat();<-------
    dyad.mint(id, to, amount);
    if (collatRatio(id) < MIN_COLLATERIZATION_RATIO) revert CrTooLow(); <------
    emit MintDyad(id, amount, to);
  }

[Link]

The problem is that liquidation function is just taking the collateral allocate in the vaults[id] (non kerosene vaults) but is missing taking the collateral from vaultsKerosene[id] this is so bad because liquidator are not taking any reward from this.

 function liquidate(uint256 id, uint256 to) external isValidDNft(id) isValidDNft(to) {
        ...
        uint256 numberOfVaults = vaults[id].length(); <-------
        for (uint256 i = 0; i < numberOfVaults; i++) {
            Vault vault = Vault(vaults[id].at(i));
            uint256 collateral = vault.id2asset(id).mulWadUp(liquidationAssetShare); 
            vault.move(id, to, collateral);
        }
        emit Liquidate(id, msg.sender, to);
    }

[Link]

Impact

Liquidator have not incentive to liquidate users, which mean bad debt, which mean that the protocol is unsustainable.

Proof of Concept

As you can see in the liquidate function the vaultsKerosene are not been taking in consideration when a user get liquidated which is a mistake because users may have his dyad backed for vaultsKerosene(kerosene vaults) and vaults(non kerosene vaults)

  function liquidate(
    uint id,
    uint to
  ) 
    external 
      isValidDNft(id)
      isValidDNft(to)
    {
      uint cr = collatRatio(id);
      if (cr >= MIN_COLLATERIZATION_RATIO) revert CrTooHigh();
      dyad.burn(id, msg.sender, dyad.mintedDyad(address(this), id));

      uint cappedCr               = cr < 1e18 ? 1e18 : cr;
      uint liquidationEquityShare = (cappedCr - 1e18).mulWadDown(LIQUIDATION_REWARD);
      uint liquidationAssetShare  = (liquidationEquityShare + 1e18).divWadDown(cappedCr);

      uint numberOfVaults = vaults[id].length(); <-----
      for (uint i = 0; i < numberOfVaults; i++) {
          Vault vault      = Vault(vaults[id].at(i));
          uint  collateral = vault.id2asset(id).mulWadUp(liquidationAssetShare);
          vault.move(id, to, collateral);
      }
      emit Liquidate(id, msg.sender, to);
  }

To explain this imagine the next scenario:

1. User have 100 usd in exocollateral (depositing in a nonKeoseneVault).
2. User have 50 usd in kerosene Vaults (no matter the assets).
3. User mint 100 dyad (min collateral ratio is 1.5 so is good).
4. The price of asset in kerosene vaults drop to 30 usd.
5. User now can get liquidated.

At this point we get that user have 100 usd in non kerosene vaults, 30 usd in kerosene vaults, and 100 dyad minted, if liquidator liquidate this position he has to liquidate the 100 dyad and get rewarded just the collaterals in the vaults[id] which is just 100 usd, liquidator liquidate 100 dyad and get 100 usd so instead of the liquidator get rewarded they just lost his gas.

in practice there is a liquidationAssetShare that is multiplied by the amount that liquidatee has in the nft id so the rewarded amount for liquidator is even lower.

Tools Used

Manual

Recommended Mitigation Steps

Take the collateral in vaultsKerosene[id] variable

Assessed type

Error

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/4a987e536576139793a1c04690336d06c93fca90/src/core/VaultManagerV2.sol#L113

Vulnerability details

Users can add and remove kerosene vaults through the addKerosene and removeKerosene functions.

  function addKerosene(
      uint    id,
      address vault
  ) 
    external
      isDNftOwner(id)
  {
    if (vaultsKerosene[id].length() >= MAX_VAULTS_KEROSENE) revert TooManyVaults();
    if (!keroseneManager.isLicensed(vault))                 revert VaultNotLicensed();
    if (!vaultsKerosene[id].add(vault))                     revert VaultAlreadyAdded();
    emit Added(id, vault);
  }

function removeKerosene(
      uint    id,
      address vault
  ) 
    external
      isDNftOwner(id)
  {
    if (Vault(vault).id2asset(id) > 0)     revert VaultHasAssets();
    if (!vaultsKerosene[id].remove(vault)) revert VaultNotAdded();
    emit Removed(id, vault);
  }

https://github.com/code-423n4/2024-04-dyad/blob/4a987e536576139793a1c04690336d06c93fca90/src/core/VaultManagerV2.sol#L106)

The removeKerosene function is checking is the nft has balance associate in the vault to remove (see the arrow above).

The problem is that an attacker can deposit on behalf of any nft id, so attacker can front run the remove transaction of a user sending 1 wei to the same vault that user is trying to remove, successfully making revert the user transaction.

Impact

removeKerosene function can be DOS to any honest user trying to remove a vault of his nft.

Proof of Concept

See the deposit function:

 function deposit(
    uint    id,
    address vault,
    uint    amount
  ) 
    external 
      isValidDNft(id) <-----
  {
    idToBlockOfLastDeposit[id] = block.number;
    Vault _vault = Vault(vault);
    _vault.asset().safeTransferFrom(msg.sender, address(vault), amount);
    _vault.deposit(id, amount);  <------
  }

[Link]

As we can see the deposit functions is allowing any user(or attacker) to deposit in any vault and any nft id, the only validation associate with the nft is if the nft id is valid (see the first arrow above). see the vault deposit call (second arrow above):

function deposit(
    uint id,
    uint amount
  )
    external 
      onlyVaultManager
  {
    id2asset[id] += amount;  <-----
    emit Deposit(id, amount);
  }

[Link]

As you can see the deposit function is incrementing the id2asset[id] in the vault(see arrow above) same variable that have to be zero to remove an vault from a nft id.(see arrow above)

function removeKerosene(
      uint    id,
      address vault
  ) 
    external
      isDNftOwner(id)
  {
    if (Vault(vault).id2asset(id) > 0)     revert VaultHasAssets(); <------
    if (!vaultsKerosene[id].remove(vault)) revert VaultNotAdded();
    emit Removed(id, vault);
  }

[Link]

So an attacker can:

1. See the a honest remove transaction of a user.
2. Front running this transaction sending a deposit transaction with more amount of gas than the remove transaction, the attacker has to pass the vault that honest user want to remove, the id of the nft and 1 wei of the asset into the deposit transaction.
3. Remove transaction of the honest user revert.

Tools Used

Manual review.

Recommended Mitigation Steps

The most straightforward solution is changing the isValidDNft(id) modifier in the deposit function for the isDNftOwner(id) modifier. (This have to be carefully review and may be different from the design of the project).

Assessed type

DoS

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/VaultManagerV2.sol#L179

Vulnerability details

The vaultManagerV2 is exposing a burnDay and redeemDay functions to burn their dyad and clear his debt.

 function burnDyad(
    uint id,
    uint amount
  ) 
    external 
      isValidDNft(id)
  {
    dyad.burn(id, msg.sender, amount); <------
    emit BurnDyad(id, amount, msg.sender);
  }

  /// @inheritdoc IVaultManager
  function redeemDyad(
    uint    id,
    address vault,
    uint    amount,
    address to
  )
    external 
      isDNftOwner(id)
    returns (uint) { 
      dyad.burn(id, msg.sender, amount);  <-----
      Vault _vault = Vault(vault);
      uint asset = amount 
                    * (10**(_vault.oracle().decimals() + _vault.asset().decimals())) 
                    / _vault.assetPrice() 
                    / 1e18;
      withdraw(id, vault, asset, to);
      emit RedeemDyad(id, vault, amount, to);
      return asset;
  }

The problem is that burn function can be called by anyone for any id, so honest user trying to burn all his dyad or redeem his dyad, attacker can repay just one wei 1 and make revert for overflow the transaction.

Note that this jus work for transactions that burn all the dyad that a id have, the DoS work because the Dyad contract is maintaining a state of the minted dyad for id:

function burn(
      uint    id, 
      address from,
      uint    amount
  ) external 
      licensedVaultManager 
    {
      _burn(from, amount);
      mintedDyad[msg.sender][id] -= amount;  <------ 
  }

Impact

burnDyad and redeemDyad can be D.o.S when user trying to repaid all his dyad, that this can be de case in much cases.

Proof of Concept

The burn function in the dyad contract is maintaining the above state(see the arrow):

function burn(
      uint    id, 
      address from,
      uint    amount
  ) external 
      licensedVaultManager 
    {
      _burn(from, amount);
      mintedDyad[msg.sender][id] -= amount;  <------ 
  }

If someone try to burn a amount major than mintedDyad[msg.sender][id] the execution will revert for overflow.

Now see the next scenario:

1. User have 100 dyad minted.
2. He wants to burn the 100 dyad to get his collateral
3. User send a transaction trying to burn his 100 dyad in the vault manager(this transaction could be burnDyad or redeemDyad ).
4. Atacker see this transaction and send burnDyad with more gas than the user burning just 1 wei of dyad on behalf of a id.
5. Transaction of the honest user revert for overflow becuase the amount that he passed is major than the minted day that he have because an attacker burn one wei.
6. Now honest user try to burn 100 dyad - 1 wei, attacker can do the same again, a user then have to burn some amount and let dust in the protocol.

Tools Used

Manual review

Recommended Mitigation Steps

The most straightforward solution is change isValidDNft(id) for isDNftOwner(id) in the burnDyad function.

Assessed type

DoS

  function burnDyad(
    uint id,
    uint amount
  ) 
    external 
      isValidDNft(id)
  {
    dyad.burn(id, msg.sender, amount);
    emit BurnDyad(id, amount, msg.sender);
  }

  function burn(
      uint    id, 
      address from,
      uint    amount
  ) external 
      licensedVaultManager 
    {
      _burn(from, amount);
      mintedDyad[msg.sender][id] -= amount;
  }

  modifier licensedVaultManager() {
    if (!licenser.isLicensed(msg.sender)) revert NotLicensed();
    _;
  }

  // vault manager => (dNFT ID => dyad)
  mapping (address => mapping (uint => uint)) public mintedDyad; 

    function burnDyad(uint256 id, uint256 amount) external isValidDNft(id) {
@>      dyad.burn(id, msg.sender, amount);
        emit BurnDyad(id, amount, msg.sender);
    }

function burn(
      uint    id, 
@>    address from,
      uint    amount
  ) external 
      licensedVaultManager 
    {
      _burn(from, amount);
      mintedDyad[msg.sender][id] -= amount;
  }

Lines of code

https://github.com/code-423n4/2024-04-dyad/blob/cd48c684a58158de444b24854ffd8f07d046c31b/src/core/Vault.kerosine.unbounded.sol#L65

Vulnerability details

UnboundedKerosineVault is a vault that the main asset is kerosene token, this could be checked in the deploy script:

UnboundedKerosineVault unboundedKerosineVault = new UnboundedKerosineVault(
      vaultManager,
      Kerosine(MAINNET_KEROSENE), 
      Dyad    (MAINNET_DYAD),
      kerosineManager
    );

This unboundedKerosineVault from part of the Licenser vaults so users can uses them to borrow dyad. The problem is that the asset price of this unboundedKerosineVault is relaying in a balanceOf the kerosineManager vaults which are easily manipulable:

 function assetPrice() 
    public 
    view 
    override
    returns (uint) {
      uint tvl;
      address[] memory vaults = kerosineManager.getVaults();
      uint numberOfVaults = vaults.length;
      for (uint i = 0; i < numberOfVaults; i++) {
        Vault vault = Vault(vaults[i]);
        tvl += vault.asset().balanceOf(address(vault))  <-------
                * vault.assetPrice() * 1e18
                / (10**vault.asset().decimals()) 
                / (10**vault.oracle().decimals());
      }
      uint numerator   = tvl - dyad.totalSupply();
      uint denominator = kerosineDenominator.denominator();
      return numerator * 1e8 / denominator;
  }

[Link]

Impact

Asset price of unboundedKerosineVault are easily manipulable and attacker can exploit this minting a lot Dyad possibly draining the contract and letting it with bad debt.

Proof of Concept

The assetPrice function is relaying in a vault.asset().balanceOf(address(vault)) which is easy manipulable, since the protocol is not allowing deposit and withdraw in the same block.number attacker can not use a flash loan but he can use his own liquidity (there are plenty of attacker with bunch of liquidity to perform hacks):

 function assetPrice() 
    public 
    view 
    override
    returns (uint) {
      uint tvl;
      address[] memory vaults = kerosineManager.getVaults();
      uint numberOfVaults = vaults.length;
      for (uint i = 0; i < numberOfVaults; i++) {
        Vault vault = Vault(vaults[i]);
        tvl += vault.asset().balanceOf(address(vault))  <-------
                * vault.assetPrice() * 1e18
                / (10**vault.asset().decimals()) 
                / (10**vault.oracle().decimals());
      }
      uint numerator   = tvl - dyad.totalSupply();
      uint denominator = kerosineDenominator.denominator();
      return numerator * 1e8 / denominator;
  }

[Link]

To manipulate the price attacker just have to:

1. Deposit kerosene in the unboundedKerosineVault to later mint against them.
2. Deposit a lot liquidity for a kerosene vault (at this moment kerosene vault are ethVault and wstEth).
3. Mint Dyad with a manipulated unboundedKerosineVault.
4. withdraw his liquidity in the next block.number from the kerosene vault.

Tools Used

Manual

Recommended Mitigation Steps

balanceOf are susceptible to this kind of manipulation consider implement another mechanism to prices. Other option is lock the liqudity on a vault for more time.

Assessed type

Other