xanoutas/solidity-security-findings huggingface dataset:
`latestAnswer()` may return stale values
Audit: 2022-01-dev-test-repo-findings
Severity: MEDIUM

### Lines of code

--------------

[121](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/oracle/implementations/ARBTriCryptoOracle.sol#L121-L121), [122](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/oracle/implementations/ARBTriCryptoOracle.sol#L122-L122), [123](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/oracle/implementations/ARBTriCryptoOracle.sol#L123-L123), [124](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/oracle/implementations/ARBTriCryptoOracle.sol#L124-L124), [51](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/oracle/implementations/SGOracle.sol#L51-L51)

### Vulnerability details

-------------

`latestAnswer()` only returns the latest answer or zero, and thus there is no way to tell whether the value is stale or not. Use `latestRoundData()` instead, and check whether the latest timestamp is within your protocol's limits.

```solidity
File: contracts/oracle/implementations/ARBTriCryptoOracle.sol

121:         uint256 _btcPrice = uint256(BTC_FEED.latestAnswer()) * 1e10;

122:         uint256 _wbtcPrice = uint256(WBTC_FEED.latestAnswer()) * 1e10;

123:         uint256 _ethPrice = uint256(ETH_FEED.latestAnswer()) * 1e10;

124:         uint256 _usdtPrice = uint256(USDT_FEED.latestAnswer()) * 1e10;

```



```solidity
File: contracts/oracle/implementations/SGOracle.sol

51:              uint256(UNDERLYING.latestAnswer())) / SG_POOL.totalSupply();

```


### Assessed type

------------

other
Use of `transferFrom()` rather than `safeTransferFrom()` for NFTs in will lead to the loss of NFTs
Audit: 2022-01-dev-test-repo-findings
Severity: MEDIUM

### Lines of code

--------------

[230](https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionBroker.sol#L230), [342](https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionBroker.sol#L342), [514](https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/Penrose.sol#L514-L519), [536](https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/Penrose.sol#L536)

### Vulnerability details

-------------

The EIP-721 standard says the following about `transferFrom()`:
```solidity
  /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE
  ///  TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE
  ///  THEY MAY BE PERMANENTLY LOST
  /// @dev Throws unless `msg.sender` is the current owner, an authorized
  ///  operator, or the approved address for this NFT. Throws if `_from` is
  ///  not the current owner. Throws if `_to` is the zero address. Throws if
  ///  `_tokenId` is not a valid NFT.
  /// @param _from The current owner of the NFT
  /// @param _to The new owner
  /// @param _tokenId The NFT to transfer
  function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
```
https://github.com/ethereum/EIPs/blob/78e2c297611f5e92b6a5112819ab71f74041ff25/EIPS/eip-721.md?plain=1#L103-L113

Code must use the `safeTransferFrom()` flavor if it hasn't otherwise verified that the receiving address can handle it

```solidity
File: contracts/options/TapiocaOptionBroker.sol

230:          tOLP.transferFrom(msg.sender, address(this), _tOLPTokenID);

342:          tOLP.transferFrom(address(this), otapOwner, oTAPPosition.tOLP);

```



```solidity
File: contracts/Penrose.sol

514               yieldBox.transfer(
515                   address(this),
516                   address(swapper),
517                   assetId,
518                   feeShares
519:              );

536:              yieldBox.transfer(address(this), feeTo, assetId, feeShares);

```


### Assessed type

------------

other
Unsafe use of `approve()` with `IERC20`
Audit: 2022-01-dev-test-repo-findings
Severity: MEDIUM

### Lines of code

--------------

[321](https://github.com/Tapioca-DAO/tapiocaz-audit/blob/bcf61f79464cfdc0484aa272f9f6e28d5de36a8f/contracts/Balancer.sol#L321-L321), [215](https://github.com/Tapioca-DAO/tapiocaz-audit/blob/bcf61f79464cfdc0484aa272f9f6e28d5de36a8f/contracts/tOFT/modules/BaseTOFTLeverageModule.sol#L215-L215), [184](https://github.com/Tapioca-DAO/tapiocaz-audit/blob/bcf61f79464cfdc0484aa272f9f6e28d5de36a8f/contracts/tOFT/modules/BaseTOFTStrategyModule.sol#L184-L184), [450](https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/bigBang/BigBang.sol#L450-L450), [761](https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/markets/bigBang/BigBang.sol#L761-L761), [217](https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contracts/usd0/modules/USDOLeverageModule.sol#L217-L217), [157](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/Magnetar/modules/MagnetarMarketModule.sol#L157-L160), [234](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/Magnetar/modules/MagnetarMarketModule.sol#L234-L234), [339](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/Magnetar/modules/MagnetarMarketModule.sol#L339-L342), [386](https://github.com/Tapioca-DAO/tapioca-periph-audit/blob/023751a4e987cf7c203ab25d3abba58f7344f213/contracts/Magnetar/modules/MagnetarMarketModule.sol#L386-L389), [76](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/aave/AaveStrategy.sol#L76-L76), [106](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/convex/ConvexTricryptoStrategy.sol#L106-L106), [107](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/convex/ConvexTricryptoStrategy.sol#L107-L107), [108](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/convex/ConvexTricryptoStrategy.sol#L108-L108), [172](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/convex/ConvexTricryptoStrategy.sol#L172-L172), [174](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/convex/ConvexTricryptoStrategy.sol#L174-L174), [79](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/curve/TricryptoLPStrategy.sol#L79-L79), [80](https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audit/blob/05ba7108a83c66dada98bc5bc75cf18004f2a49b/contracts/curve/TricryptoLPStrategy.sol#L80-L80), [81](https://github
Upgraded Q -> 3 from #534 [1702060375162]
Audit: 2023-11-kelp-findings
Severity: HIGH

Judge has assessed an item in Issue #534 as 3 risk. The relevant finding follows:

 [L-03] Consider use stETH/UDS oracle
Issue Description: The sponsor has confirmed their choice of Chainlink as an oracle to fetch prices. Since all other LST price feeds are 18 decimal places, they will most likely use stETH/ETH price feeds. However, this feed has a long heartbeat and a 2% deviation threshold, which could lead to fund loss. The 24-hour heartbeat and 2% deviation threshold mean the price can move up to 2% or remain unchanged for 24 hours before triggering a price update. This could result in the on-chain price being significantly different from the true stETH price, leading to incorrectly calculated rsETH to mint.

Recommendation:

Consider using the stETH/USD oracle instead, as it offers a 1-hour heartbeat and a 1% deviation threshold. To accommodate this change, also need to adjust the decimal calculation in LRTOracle::getAssetPrice to multiply by 18 ** (token.decimal - pricefeed.decimal) or a similar factor. This adjustment ensures that the price of all tokens is returned with the same decimal precision.
Fractional shares are not respected
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTOracle.sol#L52


# Vulnerability details

## Impact
getRSETHPrice() will return the rate at which RSETH are being minted as to maintain each user stake in balance. Goal is to maintained fractional shares. However, since users are expected to swap on external AMMs, the fractional share will not be kept as AMMs follow a bonging curve and have no knowledge of the fractional share. 

Latter users to sell on AMMs, will lose funds as price don't account for original share in the deposit vault.

## Proof of Concept
https://blog.kelpdao.xyz/exploring-a-new-defi-primitive-liquid-restaked-token-lrt-ed0a8f63a4e2
```
Restakers can swap their LRT tokens for other tokens on AMMs or choose to redeem underlying assets through LRT contracts.
```

## Tools Used
Manual review.

## Recommended Mitigation Steps
Dont use external AMMs.


## Assessed type

Other
The initial deposit of an asset will always fail due to the fact that `getTotalAssetDeposits()` returns 0.
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L119


# Vulnerability details

## Impact

The `LRTDepositPool#depositAsset()` function is employed for users to deposit supported assets. This function relies on `LRTDepositPool#getTotalAssetDeposits()` to determine the amount of `rsETH` to be minted. However, the absence of initial deposits in the protocol—whether in the deposit pool, Node Delegator, or in assets staked in EigenLayer—results in `LRTDepositPool#getTotalAssetDeposits()` always being 0. This vulnerability prevents the protocol from successfully receiving deposits from users.

The getTotalAssetDeposits() function does always return 0 due to the absence of initial deposits, it could prevent the protocol from successfully receiving deposits from users.

The amount of rsETH to be minted is calculated based on the total asset deposits, and this total is initially 0, then no rsETH would be minted when users deposit assets. This could effectively prevent the protocol from receiving deposits, as users would not receive any tokens in return for their deposits.

## Proof of Concept



```solidity

File: src/LRTDepositPool.sol
// @audit line 141 in depositAsset() calls _mintRsETH()
141:    uint256 rsethAmountMinted = _mintRsETH(asset, depositAmount);

File: src/LRTDepositPool.sol
// @audit line 152 in _mintRsETH() calls getRsETHAmountToMint() to get amount rsETH to mint 
151:    function _mintRsETH(address _asset, uint256 _amount) private returns (uint256 rsethAmountToMint) {
152:        (rsethAmountToMint) = getRsETHAmountToMint(_asset, _amount);

File: src/LRTDepositPool.sol
// @audit line 109 in getRsETHAmountToMint() calls lrtOracle.getRSETHPrice() to get the price
109:    rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice();

File: src/LRTOracle.sol
// @audit line 70 lrtOracle.getRSETHPrice() call LRTDepositPool.getTotalAssetDeposits() to get all combined value of deposited assets, but initially
// this will be 0
70:     uint256 totalAssetAmt = ILRTDepositPool(lrtDepositPoolAddr).getTotalAssetDeposits(asset);
```

1. [**depositAsset()**](https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L119)
    - Allows a user to deposit a supported asset into the deposit pool.
2. [**_mintRsETH()**](https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L151)
    - Internal function to mint the equivalent amount of rsETH based on the deposited asset.
3. [**getRsETHAmountToMint()**](https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L95)
    - Returns the amount of rsETH to mint based on the deposited asset amount.
4. [**getRSETHPrice()**](https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTOracle.sol#L52C14-L52C27)
Precision loss in getRsETHAmountToMint
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L109


# Vulnerability details

## Impact
users may lose their assets 

## Proof of Concept
The price of rsETH increases against ETH price, this leads to precision loss in getRsETHAmountToMint. 
Consider a scenario that one rsETH worth 10 ETH; now if a user tries to deposit 9 ETH he losses assets due to precision loss , precision loss happens in the following line.
``` rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice(); ```

## Tools Used
Manual Review 
## Recommended Mitigation Steps
use a scale factor to prevent precision loss 


## Assessed type

Other
Potential arbitrage opportunity
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTDepositPool.sol#L119


# Vulnerability details

## Impact
According to the logic of the protocol (https://blog.kelpdao.xyz/exploring-a-new-defi-primitive-liquid-restaked-token-lrt-ed0a8f63a4e2), minted tokens can be swapped on AMMs. This is a serious problem as prices on AMMs follow a bonding curve that are independent from the Chainlink pricing feed. This will create arbitrage opportunities for hackers to profit using the price difference to mint the LRT token on LRTDepositPool (that uses chainlink for pricing) and the price to swap on external AMMs. Furthermore, depending on which AMMs, prices in these AMMs could be manipulated with flashloans.

The end result would be the protocol funds being drained.

## Proof of Concept
https://blog.kelpdao.xyz/exploring-a-new-defi-primitive-liquid-restaked-token-lrt-ed0a8f63a4e2:
```
Restakers can swap their LRT tokens for other tokens on AMMs or choose to redeem underlying assets through LRT contracts.
```

## Tools Used
Manual review.

## Recommended Mitigation Steps
Do not use external AMMs to redeem as the prices are not the same as those returned by chainlink.


## Assessed type

Other
`stETH/ETH`, `rETH/ETH` and `cbETH/ETH` chainlink oracles has too long of heartbeat and deviation threshold which can cause loss of funds
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/oracles/ChainlinkPriceOracle.sol#L17


# Vulnerability details

`ChainlinkPriceOracle` fetches prices from the Chainlink contracts. But the price feeds in the consideration has a very long price `heartbeat` and `deviation` rate which might lead to wrong price calculation and loss of token to the user.

## Impact

According to the chainlink docs, following are the Price feeds info for the assets that will be used initially:


| Feed       | Heartbeat  | Deviation | Docs link |
| -----------| ---------- | --------- | --------- |
| `RETH / ETH`           | 2%        | 86400s           |    [Docs](https://docs.chain.link/data-feeds/price-feeds/addresses?network=ethereum&page=1&search=RETH)       |
| `CBETH / ETH`           | 1%        | 86400s           |    [Docs](https://docs.chain.link/data-feeds/price-feeds/addresses?network=ethereum&page=1&search=CBETH)       |
| `RETH / ETH`           | 0.5%        | 86400s           |    [Docs](https://docs.chain.link/data-feeds/price-feeds/addresses?network=ethereum&page=1&search=stETH+%2F+ETH)   |

For Info, `Heartbeat` and `Deviation` are variables on which the update of the prices for price feeds depends. That mean the current price feed price will be updated for the token only if one of them is met. That means if we take the example of `RETH` here, the price feed will be update only when the market price for the `RETH` fluctuates by `2%` or time equal to `86400s`(1 day) has passed since last price update. This could be a very problematic thing. Let's assume a following scenario:

-> Let's say price feeds was updated at time `T1` and price for `RETH / ETH` is [1]. And since then `43200s`(half day) has passed and price has become [1.018] (up by 1.8 %). 
-> Now `Bob` comes and decides to deposit `50 RETH` by calling `LSTDepositPool::depositAsset(...)`.
-> But the amount of `RSETH` token he will get is equal to:
```text
depositAmount = 500 RETH

// balances
bob = 500 RETH
LRTDepositPool = 0
EigenStrategy = 0
NodeDelegator = 0

// RETH Price
RETHPrice = 1e18 // hasn't updated because heartbeat and deviation hasn't reached


// total ETH (assuming zero for the sake of simplicity)
totalETHInPool = 0
RSETHSupply = 0


///////////////////////////////////////////////////////////////
// functions calculations according to chainlink price feeds //
///////////////////////////////////////////////////////////////

rsETHPrice(...) = if -> 
                      (supply = 0) 1 ETH // this condition will met
                  else -> 
                      totalETHInPool / rsETHTotalSupply

rsEthAmountToMint(...) = depositAmount * RETHPrice / rsETHPrice()
                  = 500 * 1e18 / 1e18 = 500 rsETH


/////////////////////////////////////////////////////////
/// functions calculations according to market price ////
/////////////////////////////////////////////////////////

rsETHPrice(...) = if ->
`getRSETHPrice` formula is wrong
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/main/src/LRTOracle.sol#L52-L79


# Vulnerability details

## Impact
While auditing the `getRSETHPrice` function i've indicated a dynamic but non-linear relationship between the supply of the RSETH token and its price.An increase in RSETH supply is associated with an increase in the price of RSETH. 

## Proof of Concept
Let's consider a scenario where the relationship between RSETH supply and the rstETH price is not strictly exponential but exhibits non-linear behavior.

#### Scenario:
1. **Initial State**:
   - \( {RSETH Supply} = 0 \)
   - \( {rstETH Price} = 1 \)

2. **Moderate Increase in Supply with Significant Deposits**:
   - \( {RSETH Supply} = 10 \)
   - \( {Total Deposit Tokens} = 500 \)
   - \( {rstETH Price} = 1.5 \)

3. **Large Increase in Supply with Even Larger Deposits**:
   - \( \text{RSETH Supply} = 100 \)
   - \( \text{Total Deposit Tokens} = 3000 \)
   - \( \text{rstETH Price} = 2.2 \)

4. **Subsequent Increment in Supply with Moderate Deposits**:
   - \( \text{RSETH Supply} = 150 \)
   - \( \text{Total Deposit Tokens} = 5000 \)
   - \( \text{rstETH Price} = 2.5 \)

#### Observations:
- **Non-Linear Behavior**: The relationship between RSETH supply and rstETH price does not follow a constant exponential pattern. But the price of rstETH does increase with the increase of deposit.

when the function `depositAsset` is called it first deposit the money into the smart contract and then call `_mintRsETH` function which then further calls for `getRsETHAmountToMint` function, Now before `getRsETHAmountToMint` is called the money should be transferred into the contract and `getRsETHAmountToMint` calls for `getTotalAssetDeposits` function which will be updated. 


## Tools Used
Manual Review







## Assessed type

Math
First depositor will get twice more minted token for the same amount deposited
Audit: 2023-11-kelp-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTDepositPool.sol#L95-L110
https://github.com/code-423n4/2023-11-kelp/blob/f751d7594051c0766c7ecd1e68daeb0661e43ee3/src/LRTOracle.sol#L52-L79


# Vulnerability details

## Impact

The initial depositor stands to gain an unfair amount of RSETH tokens compared to later depositors, as a result of the fixed exchange rate of **1 ether** when no RSETH supply exists (i.e., no minted tokens are available).

Consequently, the first deposit will receive ETH price of deposited token **(rETH price in term of ETH at the moment: 1,090,300,000,000,000,000)** in RSETH tokens.

## Proof of Concept

As mentioned earlier, the current price of rETH in terms of ETH is 1,090,300,000,000,000,000. 

Obtain this information from [0x536218f9E9Eb48863970252233c8F271f554C2d0](https://etherscan.io/address/0x536218f9E9Eb48863970252233c8F271f554C2d0)

![rETH-ETH-Oracle](https://user-images.githubusercontent.com/84782275/283229965-ae2e52bc-b204-478e-9e4a-3c3e385a9b67.png)

![rETH-ETH-Oracle-answer](https://user-images.githubusercontent.com/84782275/283229971-445b250c-8c2f-4095-a942-3865d06862d8.png)

1. Alice deposits 1e18 tokens of any supported asset can be either rETH, cbETH, or stETH (will use rETH for the explanation).
2. The code calculates the RSETH token amount using the formula:

```solidity
src: src/LRTDeposit#L109
rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice();
```

Considering it's the first deposit, `lrtOracle::getRSETHPrice` returns a hardcoded value of 1 ether (1e18):

```solidity
uint256 rsEthSupply = IRSETH(rsETHTokenAddress).totalSupply();
if (rsEthSupply == 0) {
    return 1 ether;
}
```

For a single `rETH` token, the contract will mint `the value of rETH taken from the chainlink at the moment` RSETH tokens for Alice.

1. Bob deposit 1e18 token.
2. In `depositAsset()`, it starts by adding the depositAmount and then calculates the amount of rsETH tokens to be minted.
3. `getRsETHAmountToMint()` will be called.

In this line, the amount on the left stays the same as the initial deposit, but the value from lrtOracle.getRSETHPrice() on the right side will change.

```solidity
rsethAmountToMint = (amount * lrtOracle.getAssetPrice(asset)) / lrtOracle.getRSETHPrice();
//                   1e18 * 1,090,300,000,000,000,000 / ? (calculated in the next steps)
```

1. `getRSETHPrice()` will get the `rsEthSupply` which will be 1,090,300,000,000,000,000. It then calculates the totalETHInPool based on the two deposited 1e18 rETH tokens from Alice and Bob.
2. It will get 2e18 and will multiple it by 1,090,300,000,000,000,000 (price of rETH at the moment)

```solidity
return totalETHInPool / rsEthSupply; 
// (2e18 * 1,090,300,000,000,000,000) / 1,090,300,000,000,000,000
// = (2e18 * ~~1,090,300,000,000,000,000~~) / ~~1,090,300,000,000,000,000~~
// = 2e18
```

```solidity
rsethAmountToMint = (amount * lrtOracle.getAssetPrice