Christmas Dinner
First Flight #31
Beginner FriendlyFoundrySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

Internal visibility for state variables prevents user transparency

koinerdegen

Summary
The ChristmasDinner contract uses internal visibility for several key state variables, including participant status, Ether deposits, and token balances. As a result, users cannot access their information directly on-chain to verify their participation status, deposit amounts, or token balances. Making these state variables public or implementing getterfunctions would allow users to query their status and balances, improving transparency and user trust.

Vulnerability Details
Vulnerability Details

The following state variables in the contract have internal visibility:

mapping(address user => bool) participant;
mapping(address token => bool) whitelisted;
mapping(address user => uint256 amount) etherBalance;
mapping(address user => mapping(address token => uint256 balance)) balances;

Currently, users cannot query these values directly, as internal visibility restricts access to within the contract or derived contracts. Without transparency, users must rely on off-chain data or third-party services to track their balances and statuses, which increases the risk of misinformation or errors.

Impact

  1. Lack of transparency: Users cannot verify their own data on-chain, leading to reduced trust in the contract.

  2. Increased support workload: Users might frequently request information from the contract owner or developer team, adding unnecessary overhead.

  3. Reduced user experience: Lack of accessible data makes the contract less user-friendly and might deter potential users.

Tools Used

  • Solidity compiler version 0.8.27

  • Manual contract review

Recommendations
To improve transparency and user experience, the contract should expose the state variables as public or implement dedicated getter functions.

Option 1: Make variables public

Modify the visibility of the state variables as follows:

- mapping(address user => bool) participant;
- mapping(address token => bool) whitelisted;
- mapping(address user => uint256 amount) etherBalance;
- (address user => mapping(address token => uint256 balance)) balances;
​
+ mapping(address user => bool) public participant;
+ mapping(address token => bool) public whitelisted;
+ mapping(address user => uint256 amount) public etherBalance;
+ mapping(address user => mapping(address token => uint256 balance)) public balances;
​

This approach automatically generates getter functions for each variable, allowing users to query their status and balances on-chain directly.

Option 2: Add custom getter functions

Alternatively, implement explicit getter functions:

function isParticipant(address user) public view returns (bool) {
return participant[user];
}
​
function isTokenWhitelisted(address token) public view returns (bool) {
return whitelisted[token];
}
​
function getEtherBalance(address user) public view returns (uint256) {
return etherBalance[user];
}
​
function getTokenBalance(address user, address token) public view returns (uint256) {
return balances[user][token];
}

This approach provides more flexibility if you need additional logic or customization in the getter functions.

Recommendations Summary

  • Use the public visibility for the state variables to automatically generate getter functions.

  • Alternatively, implement explicit getter functions for more control and customization.

Exposing these variables improves user experience, transparency, and trust in the contract.

Updates

Lead Judging Commences

0xtimefliez Lead Judge 7 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
0xtimefliez Lead Judge 7 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

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