BriVault
First Flight #52
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Impact: medium
Likelihood: medium
Invalid

Missing zero-address check for participationFeeAddress

b_juhir

Root + Impact

Description

  • The participationFeeAddress is intended to receive participation fees from each deposit. Under normal behavior, this address should always be a valid, non-zero address to ensure fees are correctly transferred.

However, the constructor of the BriVault contract does not validate whether _participationFeeAddress is the zero address. As a result, if it is mistakenly deployed with a zero address, all participation fees will be irrecoverably sent to the zero address, permanently locking user funds that were meant as fees.


constructor (
IERC20 _asset,
uint256 _participationFeeBsp,
uint256 _eventStartDate,
@> address _participationFeeAddress,
uint256 _minimumAmount,
uint256 _eventEndDate
) ERC4626 (_asset) ERC20("BriTechLabs", "BTT") Ownable(msg.sender) {
if (_participationFeeBsp > PARTICIPATIONFEEBSPMAX){
revert limiteExceede();
}
​
participationFeeBsp = _participationFeeBsp;
eventStartDate = _eventStartDate;
eventEndDate = _eventEndDate;
​
@> participationFeeAddress = _participationFeeAddress; // No zero address validation
​
minimumAmount = _minimumAmount;
_setWinner = false;
}
​

Risk

Likelihood: MEDIUM

  • Reason 1: This will occur whenever the contract is deployed with a zero address (e.g., misconfiguration during deployment).

Reason 2: The constructor does not enforce any validation, so deployment automation or human error could easily introduce this condition.

Impact: MEDIUM

  • Impact 1: All participation fees sent during deposits will be permanently lost.

  • Impact 2: Results in incorrect vault accounting and loss of funds intended for the fee receiver.

Proof of Concept

participationFeeAddress is set to address(0), the ERC20 transfer of the fee succeeds but effectively burns the tokens by sending them to the zero address. This leads to a permanent and silent loss of funds that the project owner cannot recover.

// Example scenario
BriVault vault = new BriVault(
IERC20(0xToken),
200, // 2% participation fee
block.timestamp + 1 days,
address(0), // <-- Zero address passed here
1e18,
block.timestamp + 10 days
);
​
// During deposit:
vault.deposit(100e18, user);
​
// Internally:
// fee = 2e18;
// IERC20(asset()).safeTransferFrom(msg.sender, participationFeeAddress, fee);
// --> 2 tokens are sent to address(0) and permanently lost.
​

Recommended Mitigation

Add an explicit check in the constructor to ensure that _participationFeeAddress is not the zero address before assigning it.

Adding this validation ensures that the contract cannot be deployed with an invalid or zero fee receiver. It prevents the accidental burning of participation fees and enforces safer deployment practices.

constructor (
IERC20 _asset,
uint256 _participationFeeBsp,
uint256 _eventStartDate,
address _participationFeeAddress,
uint256 _minimumAmount,
uint256 _eventEndDate
) ERC4626(_asset) ERC20("BriTechLabs", "BTT") Ownable(msg.sender) {
if (_participationFeeBsp > PARTICIPATIONFEEBSPMAX) {
revert limiteExceede();
}
​
+ if (_participationFeeAddress == address(0)) {
+ revert ZeroAddress();
+ }
​
participationFeeBsp = _participationFeeBsp;
eventStartDate = _eventStartDate;
eventEndDate = _eventEndDate;
participationFeeAddress = _participationFeeAddress;
minimumAmount = _minimumAmount;
_setWinner = false;
}
Updates

Appeal created

bube Lead Judge 19 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!