Flow

Summary

When creating a new stream, the number of decimals in the tokens are saved in the stream variable. If the token is upgradable and choose to change its decimal number, the protocol would then have an incorrect rate per second for every stream using this token.

Vulnerability Details

When a new stream is created, token.decimals is saved into _streams[streamId]. This is used to avoid querying the
decimals function from the token every time the protocol wants to read the decimals. Some tokens are upgradable and
may change this value after a stream was created. While very unlikely, the protocol would continue to operate using the outdated decimal value, leading to inaccurate scaling and descaling in all associated streams.

This misalignment introduces the risk of:

• Overpayment or underpayment: Streams could show amounts exceeding or falling short of the intended allocation.

• Locking of funds: If the protocol’s calculations no longer align with the actual token decimals, recipients may find it impossible to withdraw funds, as the protocol might misrepresent the stream balance.

Impact

This vulnerability may lead to loss of funds, overpayment, or the locking of funds due to discrepancies between the stored and actual decimal values in the protocol.

Tools Used

Manual review.

Recommendations

To prevent discrepancies in decimal handling, implement a check for every interaction with token decimals within a stream. Specifically:

1. Compare the stored _streams[streamId].tokenDecimals with the current token.decimals at each relevant interaction.

2. If a mismatch is detected, void the affected stream. Cancel its debt snapshot to prevent inaccurate debt calculations, as it is impossible to pinpoint when the decimal change occurred.

By enforcing this approach, the protocol can avoid unintended fund distribution errors, ensuring that all streams remain consistent with the token’s current decimal configuration.