## RocketTokenrEth.sol Contract Let's make some comments about the contract `RocketTokenrEth.sol`. This is the rEth token contract. The three things that we want to comment on here are the functions `mint` and `burn`, and their exchange rates. Finally, there is also a transfer before hook, which checks that there is a block delay before a transfer can happen. Let's start with the function `mint`. The function `mint` can only be called by an authorized contract, which must be the `RocketDepositPool` contract. It then calculates the amount of rEth to mint by calling the function `getREthValue`. Now moving onto the function `burn`. This function can be called by anyone to burn their rEth, and they can redeem the ETH. The way it calculates the amount of ETH to give back to this user is by calling the function `getEthValue`. These are two functions that calculate the exchange rates between rEth and ETH, the function `getREthValue`, and the function `getEthValue`. Now let’s take a look at these two functions. Here they are, the function `getEthValue`, and the function `getREthValue`. There are two things to highlight here. The first thing is how it gets another contract. Here you can see the function `getContractAddress`, which we discussed in the previous video, will eventually call the function `getAddress` on the `RocketStorage` contract. Here, it’s getting a contract called `RocketNetworkBalances`. Once it does that, it queries for the total ETH balance locked inside the protocol, and the total rETH supply. Once these two numbers are fetched, it will then use the calculation that we discussed, that the amount of ETH to mint is given by the amount of rETH that was provided, multiplied by the total ETH divided by the total supply of rEth. You’ll see a similar pattern with the function `getREthValue` as well. This function calculates the amount of rEth to mint to a user given the amount of ETH that they provided, and again the equation follows: the amount of rEth to mint will be equal to the amount of ETH that was given by the user, multiplied by the total supply of rEth, divided by the total ETH locked in the protocol. These two values again are queried by getting the contract `RocketNetworkBalances`, from the `RocketStorage`, and then calling the function `getTotalEthBalance`, and `getTotalREthSupply`. The final comment that we want to make is on the transfer hook. At the bottom, you see that there is a hook called `_beforeTokenTransfer`. If `from` is not equal to the address 0, if this is not a mint, if this is a regular transfer, then there is a block delay before another transfer can happen, and you can see this check over here: block passed must be greater than deposit delay. To clarify, this isn’t a block delay on all transfers. Let’s dig a little bit deeper inside this code to see what the condition is for the block delay. The first thing to note here is that inside the comment, it says check which block the user’s last deposit was. The way it does this is it first computes the key to get from the `RocketStorage` contract, calls the function `getUint` to get the last deposit block. Then, it will get the configuration for the deposit delay. Then it checks that the current block, minus the last block, this user deposited is greater than the deposit delay that is stored inside the protocol settings. This block delay doesn’t apply to all transfers, it only applies to the last block that the user deposited. This information is stored inside the key `user.deposit.block`, inside the `RocketStorage` contract. Let's search inside this RocketPool repo to see where this might be stored. We search for this keyword and you can see over here that it only appears inside this contract. So for now, there's no block delay after the last time the user deposited. However, this might change in the future. So if you're writing a contract that integrates with the rEth contract, then you should be aware of this. The reason why the deposit delay exists is for a historical reason. Currently it's not used, since its functionality is replaced by the mint fee. The code still remains inside this contract, because the rEth contract is an immutable contract. Some ERC20 tokens are upgradeable, however, for the rEth contract, it is not upgradeable, this code cannot be changed. Although the deposit block is no longer used, it still exists inside the code.