Insufficient Handling of Fee-on-Transfer Tokens in the Boost Protocol
Details
The Boost protocol, designed to support diverse incentive mechanisms using ERC20 tokens, faces challenges when handling "fee-on-transfer" tokens like PAXG. These tokens deduct a fee during transfers, causing discrepancies between the intended transfer amount and the actual amount received.
Unlike standard ERC20 tokens, where the recipient receives the exact amount sent, fee-on-transfer tokens reduce the transfer amount by a predetermined fee. This behavior disrupts the Boost protocol's assumptions about token balances and transfer outcomes, particularly within the ManagedBudget and incentive contracts.
// ManagedBudget.sol
// ...
function _transferFungible(address asset_, address to_, uint256 amount_) internal virtual nonReentrant {
// ...
// Transfer the asset to the recipient
if (asset_ == address(0)) {
SafeTransferLib.safeTransferETH(to_, amount_);
} else {
asset_.safeTransfer(to_, amount_); // Potential issue with fee-on-transfer tokens
}
emit Distributed(asset_, to_, amount_);
}
// ...
If asset represents a fee-on-transfer token like PAXG, the recipient (to) would receive less than amount_ due to the fee deduction during the safeTransfer. However, the transferFungible function operates under the assumption that amount is transferred in full, potentially leading to an inconsistency between the contract's internal accounting (e.g., the _distributedFungible mapping) and the actual token balances.
Impact
The unique behavior of fee-on-transfer tokens introduces the following concerns:
Inaccurate Incentive Distribution: When disbursing incentives using a fee-on-transfer token, the intended recipient would receive a reduced amount.
Accounting Discrepancies: The Boost contract's internal accounting, assuming standard ERC20 transfers, wouldn't accurately reflect the actual token balances, as it wouldn't account for the transfer fees.
Budget Shortfalls: Using fee-on-transfer tokens for incentive disbursement could lead to budget shortfalls over time, as the accumulated transfer fees might deplete the allocated funds.
Scenario
A user creates a Boost offering incentives in PAXG, a fee-on-transfer token.
A user, having successfully met the Boost's requirements, attempts to claim their PAXG incentive.
The claim function in the incentive contract interacts with the ManagedBudget to transfer the PAXG reward. During the safeTransfer call within _transferFungible, a fee is deducted from the transferred amount.
The user receives a lower PAXG amount than the intended reward specified in the Boost.
The ManagedBudget contract, unaware of the fee deduction, updates its internal state as if the entire reward amount was transferred, leading to a discrepancy.
Fix
After executing a transfer involving a fee-on-transfer token, immediately query the recipient's balance to determine the actual amount received.
Reconcile this received amount with the intended transfer amount, updating the Boost contract's internal accounting accordingly.
0xloophole
Medium
Insufficient Handling of Fee-on-Transfer Tokens in the Boost Protocol
Details
The Boost protocol, designed to support diverse incentive mechanisms using ERC20 tokens, faces challenges when handling "fee-on-transfer" tokens like PAXG. These tokens deduct a fee during transfers, causing discrepancies between the intended transfer amount and the actual amount received.
Unlike standard ERC20 tokens, where the recipient receives the exact amount sent, fee-on-transfer tokens reduce the transfer amount by a predetermined fee. This behavior disrupts the Boost protocol's assumptions about token balances and transfer outcomes, particularly within the ManagedBudget and incentive contracts.
Code Snippets
https://github.com/sherlock-audit/2024-06-boost-aa-wallet/blob/main/boost-protocol/packages/evm/contracts/budgets/ManagedBudget.sol#L296
If asset represents a fee-on-transfer token like PAXG, the recipient (to) would receive less than amount_ due to the fee deduction during the safeTransfer. However, the transferFungible function operates under the assumption that amount is transferred in full, potentially leading to an inconsistency between the contract's internal accounting (e.g., the _distributedFungible mapping) and the actual token balances.
Impact
The unique behavior of fee-on-transfer tokens introduces the following concerns:
Inaccurate Incentive Distribution: When disbursing incentives using a fee-on-transfer token, the intended recipient would receive a reduced amount.
Accounting Discrepancies: The Boost contract's internal accounting, assuming standard ERC20 transfers, wouldn't accurately reflect the actual token balances, as it wouldn't account for the transfer fees.
Budget Shortfalls: Using fee-on-transfer tokens for incentive disbursement could lead to budget shortfalls over time, as the accumulated transfer fees might deplete the allocated funds.
Scenario
Fix
After executing a transfer involving a fee-on-transfer token, immediately query the recipient's balance to determine the actual amount received.
Reconcile this received amount with the intended transfer amount, updating the Boost contract's internal accounting accordingly.