M-6 Discrepencies in block.timestamp typecasting

Summary

Block timestamp is typecasted differently in different parts of the code leading to inconsistency and potentially bricking the system due to interoperability issues with different components typecasting it differently

Vulnerability Detail

RioLRT.sol


 function clock() public view override returns (uint48) {
        return uint48(block.timestamp);
    }

RioLRT#rebalance()

// remaining code
if (!isDepositCapped) {
            assetNextRebalanceAfter[asset] = uint40(block.timestamp) + rebalanceDelay;
        }

RioToken.sol

  function clock() public view override returns (uint48) {
        return uint48(block.timestamp);
    }

RioDeployer.sol


// MockBeaconChain#setNextTimestamp :

function setNextTimestamp(uint256 timestamp) public {
        nextTimestamp = uint64(timestamp);
    }

// RioDeployer.sol#verifyCredentialsForValidators
        beaconChain.setNextTimestamp(block.timestamp);

Impact

inconsistency and potentially bricking the system due to interoperability issues with different components

Code Snippet

Adding one of the lines for reference https://github.com/sherlock-audit/2024-02-rio-network-core-protocol/blob/main/rio-sherlock-audit/contracts/restaking/RioLRTCoordinator.sol#L148

Tool used

Manual Review

Recommendation

Consider having a uniform typecasting, like uint48 in all the places

sherlock-audit / 2024-02-rio-network-core-protocol-judging

0xumarkhatab - M-6 Discrepencies in block.timestamp typecasting #274