##Summary
The Treasury contract is vulnerable to over-allocation of funds, allowing an attacker (or even an honest mistake) to allocate more funds than available. This can lead to fund mismanagement, denial of service (DoS), or unintentional fund locking, affecting treasury operations.
##Vulnerability Details
##Root Cause
The contract does not properly track total allocated funds against the actual treasury balance. This means that it’s possible to allocate more funds than the contract holds, causing payment failures or fund mismanagement.
##Impact
Funds mismanagement: Some addresses may receive more than they should, while others get nothing.
Denial of Service (DoS): If over-allocations occur, legitimate payments might fail.
Potential exploits: A malicious actor could intentionally exploit this to disrupt treasury operations.
##Proof of Concept (PoC)
Here’s a simple test case demonstrating the issue:
##Testing the Vulnerability
Deposit 5 ETH into the contract.
Allocate 10 ETH to an address (even though the contract only has 5 ETH).
When the recipient tries to withdraw, the transaction fails due to insufficient funds.
##Security Analysis with Slither & Echidna
Slither Findings: Detects potential reentrancy risks and lack of balance checks.
Echidna Tests: Confirm that allocations can exceed available funds, leading to failures.
##Recommended mitigation(fixes)
Modify the allocateFunds() function to ensure total allocations never exceed the treasury balance.
##Solution 2: Introduce an Allocation Limit per User
Set a cap on individual allocations to prevent an address from being over-allocated.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.