code-423n4 / 2024-02-spectra-findings

4 stars 2 forks source link

`block.timestamp` does not correspond to the same values on multi chains #258

Closed c4-bot-2 closed 8 months ago

c4-bot-2 commented 8 months ago

Lines of code

https://github.com/code-423n4/2024-02-spectra/blob/383202d0b84985122fe1ba53cfbbb68f18ba3986/src/tokens/YieldToken.sol#L124 https://github.com/code-423n4/2024-02-spectra/blob/383202d0b84985122fe1ba53cfbbb68f18ba3986/src/tokens/PrincipalToken.sol#L86

Vulnerability details

Impact

Block time refers to the time separating blocks. The average block time in Ethereum is 12 seconds, but this value is different on different chains on Polygon and in Arbitrum chains.

Proof of Concept

Consider a Principal Token (PT) with a maturity date set based on block.timestamp.

On Ethereum, this might work predictably, but on Arbitrum and on Polygon chain, the PT could reach maturity earlier or later than expected due to how these other networks handles timestamps. This discrepancy could mislead token holders regarding the maturity of their investments, potentially leading to confusion or loss if tokens appear to mature at unexpected times.

// YieldToken.sol
function balanceOf(
        address account
    ) public view override(IYieldToken, ERC20Upgradeable) returns (uint256) {
        return (block.timestamp < IPrincipalToken(pt).maturity()) ? super.balanceOf(account) : 0;
    }

// PrincipalToken.sol
 modifier notExpired() virtual {
        if (block.timestamp >= expiry) {
            revert PTExpired();
        }
        _;
    }

Tools Used

Manual Review

Recommended Mitigation Steps

Implement a more flexible maturity calculation and other operations involving block.timestamp whilst using the block.timestamp values.

Assessed type

Invalid Validation

c4-pre-sort commented 8 months ago

gzeon-c4 marked the issue as insufficient quality report

gzeon-c4 commented 8 months ago

lack actual exploit

c4-judge commented 8 months ago

JustDravee marked the issue as unsatisfactory: Invalid