Bald Licorice Gibbon - in the custom _update(...)

[sherlock-admin2]

Bald Licorice Gibbon

Medium

in the custom _update(...)

in the custom _update(...) function, where the call order results in old balances being used to update the user’s indexed assets.
https://github.com/sherlock-audit/2024-12-plaza-finance/blob/14a962c52a8f4731bbe4655a2f6d0d85e144c7c2/plaza-evm/src/BondToken.sol#L154
In other words, before super._update(from, to, amount) has actually deducted from’s balance and credited to’s new balance, the function prematurely calls:

updateIndexedUserAssets(from, balanceOf(from));
updateIndexedUserAssets(to, balanceOf(to));

At this point, balanceOf(from) and balanceOf(to) still reflect their pre-transfer balances, causing the user to be credited with an incorrect share for this period. A more correct approach would typically be:
1. First, execute the parent contract’s actual transfer logic (which updates balanceOf(from) and balanceOf(to)).
2. Then, use the new balances after the transfer to update indexed assets.

This is usually structured as follows (pseudocode):

function _update(address from, address to, uint256 amount)
    internal
    virtual
    override
    whenNotPaused()
{
    // Call super first to ensure balances are updated
    super._update(from, to, amount);

    // Then update with the new balances after transfer
    if (from != address(0)) {
        updateIndexedUserAssets(from, balanceOf(from));
    }
    if (to != address(0)) {
        updateIndexedUserAssets(to, balanceOf(to));
    }
}

This ensures that the transferred amount is not mistakenly included in the sender’s latest share calculation. Otherwise, at the moment the user transfers tokens, their share is still calculated based on the pre-transfer higher balance, which is inconsistent with expectations.