Minting batch tokens erroneously burns ETH from caller
Summary
When minting batch tokens from the Edition contract, the FeeManager contract is called to collect the fees based on the amount of ETH sent by the caller. In the case of batch minting, referrer address is set to the zero address, indicating that only protocol and fee receiver should receive fees. However, a portion of the ETH sent by the caller is still sent to the referrer address, which is the zero address, effectively burning them.
function _splitProtocolFee(
IEdition edition_,
address asset_,
uint256 amount_,
address payer_,
address referrer_
) internal returns (uint256 referrerShare) {
// @audit this will be zero since referrer address is set to zero address
uint256 mintReferrerShare = getMintReferrerShare(amount_, referrer_);
// @audit this will be non-zero since `referrers[edition_]` is not set to the zero address during this call
uint256 collectionReferrerShare = getCollectionReferrerShare(amount_, referrers[edition_]);
referrerShare = mintReferrerShare + collectionReferrerShare;
_route(
Fee({asset: asset_, amount: amount_ - referrerShare}),
Target({target: protocolFeeReceiver, chainId: block.chainid}),
payer_
);
_route(
Fee({asset: asset_, amount: mintReferrerShare}),
Target({target: referrer_, chainId: block.chainid}),
payer_
);
//@audit target is set to the zero address with the amount collectionReferrerShare > 0
@> _route(
Fee({asset: asset_, amount: collectionReferrerShare}),
Target({target: referrer_, chainId: block.chainid}),
payer_
);
}
collectionReferrerShare > 0, since that amount is retrieved from referrers[edition_], which in this call is not set to address 0. collectionReferrerShare is sent to address 0 since we set target to referrer_, effectively burning it:
function _route(Fee memory fee_, Target memory feeReceiver_, address feePayer_) internal {
if (block.chainid != feeReceiver_.chainId) revert NotRoutable();
if (fee_.amount == 0) return;
// @audit feeReceiver_.target is the zero address in this case
@> _transfer(fee_.asset, fee_.amount, feePayer_, feeReceiver_.target);
}
cryptic
high
Minting batch tokens erroneously burns ETH from caller
Summary
When minting batch tokens from the
Edition
contract, theFeeManager
contract is called to collect the fees based on the amount of ETH sent by the caller. In the case of batch minting,referrer
address is set to the zero address, indicating that only protocol and fee receiver should receive fees. However, a portion of the ETH sent by the caller is still sent to the referrer address, which is the zero address, effectively burning them.Vulnerability Detail
Edition::mintBatch
#L277-297A call to
FeeManager::collectMintFee
is made with referrer address set to the zero address.FeeManager::collectMintFee
#L366-L410FeeManager::_splitProtocolFee
#L412-L441collectionReferrerShare
> 0, since that amount is retrieved fromreferrers[edition_]
, which in this call is not set to address 0.collectionReferrerShare
is sent to address 0 since we set target toreferrer_
, effectively burning it:FeeManager::_route
#L448-L454FeeManager::_transfer
#L461-L467Impact
Loss of funds due to erroneously burning ETH
Code Snippet
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/editions/Edition.sol#L277-L297
https://github.com/sherlock-audit/2024-04-titles/blob/main/wallflower-contract-v2/src/fees/FeeManager.sol#L412-L441
Tool used
Manual Review
Recommendation
Check if referrer address is set to the zero address prior to routing