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

Missing zero address checks in constructor

s3mvl4d

Description

  • The constructor should validate critical addresses (e.g., fee recipient) are non‑zero to ensure funds are not irrecoverably lost and to prevent misconfiguration at deployment time.

  • The BriVault constructor accepts _participationFeeAddress and stores it without validating it’s not the zero address. Any fees transferred to address(0) are burned, leading to permanent loss of funds.

/// briVault.sol (constructor excerpt)
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: Low

  • During deployment or upgrades, misconfiguration of _participationFeeAddress to address(0) can occur, especially in scripts or multi‑sig flows where parameters are templated or optional.

  • Audiences in CTF/contest settings often test zero‑address edge cases; this is a common oversight in constructors.

Impact: Low

  • Permanent loss of fees: Every deposit() call transfers the participation fee directly to participationFeeAddress. If it’s the zero address, those tokens are burned and unrecoverable.

  • Operational failure: Protocol revenue/accounting becomes inconsistent; fee‑recipient expectations (e.g., treasury) are not met.

Proof of Concept

// Pseudo-steps (no special mock needed):
// 1) Deploy BriVault with _participationFeeAddress = address(0).
// 2) User calls deposit(assets, receiver).
// 3) The line `IERC20(asset()).safeTransferFrom(msg.sender, participationFeeAddress, fee);`
// transfers `fee` to address(0), effectively burning tokens.
// 4) Repeat deposits → cumulative permanent loss equal to total fees charged.

Recommended Mitigation

  • Add an explicit non‑zero check in the constructor.

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();
}
+ require(address(_asset) != address(0), "asset=0");
+ require(_participationFeeAddress != address(0), "feeAddr=0");
​
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
Assigned finding tags:

Missing Constructor Validation

This is owner action and the owner is assumed to be trusted and to provide correct input arguments.

Support

FAQs

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

Give us feedback!