Github username: @saidqayoumsadat Twitter username: S2AQ143 Submission hash (on-chain): 0xe2f5462516bcfb5a93fbba8bd78073356186e096f26abc9829919bb2d2d52232 Severity: medium

Description:

Description

Please note, sponsor has confirmed that collateralToken can be ANY ERC20 token, their confirmation can be checked here and here so this issue about Rebasing tokens like stETH is being reported considering these above issue comments by sponsors and based on that issue. This is not a duplicate of #64, as fees on transfer are different from rebasing tokens.

Certain ERC20 tokens like Rebasing tokens adjust the user's balance automatically either positively or negatively over time. The problem stems from the fact that Router.sol does not account for this dynamic change in balance. Consequently, these changes can result in token mismanagement, leading to potential understatements or overstatements of user balances. This can either lock funds within the system or improperly distribute them.

Affected Functions:

splitPosition() splits the position and sends the collateral token to router contract.

    function splitPosition(IERC20 collateralToken, Market market, uint256 amount) public {
        if (market.parentCollectionId() == bytes32(0)) {
            // transfer the collateral tokens to the Router.
@>            collateralToken.transferFrom(msg.sender, address(this), amount);
        }
        _splitPosition(collateralToken, market, amount);
    }

and mergePositions() merges the position and sends back the collateral token to user.

    function mergePositions(IERC20 collateralToken, Market market, uint256 amount) public {
        _mergePositions(collateralToken, market, amount);

        if (market.parentCollectionId() == bytes32(0)) {
            // send collateral tokens back to the user.
@>            collateralToken.transfer(msg.sender, amount);
        }
    }

The current implementation does not account for rebasing tokens like stETH, which dynamically change in balance. When these tokens are used:

If the token rebases downward (decreasing balance), the contract may hold fewer tokens than expected, but it will still report the original higher amount. This leads to insufficient token balances during operations like mergePositions(), resulting in failed transactions.
If the token rebases upward (increasing balance), the contract will hold more tokens than expected, which could result in locked excess tokens within the protocol.

Examples of Rebasing Tokens:

stETH: Automatically adjusts balances in accordance with staking rewards, increasing user balances over time.
AMPL: Adjusts balances based on market conditions, either increasing or decreasing.

Impact

Funds Locking: Excess rebased tokens will remain locked in the protocol, as the contract does not handle upward rebasing, effectively locking liquidity.
Inaccurate Accounting: If a rebasing token’s balance decreases, users may not be able to retrieve the full collateral they expect. This can lead to transaction failures, particularly when the system attempts to merge positions or redeem funds.

Recommendation

When rebasing token go down in value, you should have a method to update the cached reserves accordingly, based on the balance held. This is a complex solution.
When they go up in value, you should add a method to actually transfer the excess tokens out of the protocol.

hats-finance / SeeR-PM-0x899bc13919880db76edf4ccd72bdfa5dfa666fb7

`CollateralToken` as Rebasing tokens is not supported in `splitPosition()` and `mergePositions()` functions #86

Description

Affected Functions:

Impact

Recommendation