From the readme.md, the airdrop
contract should give each registered user a random slice size between 100–500 APT, but the get_random_slice function
uses the timestamp (timestamp::now_microseconds()) to generate a pseudo-random value for determining the random slice allocated to a user.
This timestamp-based randomness is predictable and manipulable, allowing the module’s owner to register users at specific timestamps to guarantee the maximum allocation (500 APT).
For example, the owner, who calls register_pizza_lover (which invokes get_random_slice), can time their transaction to ensure time % 401 == 400, resulting in random_val = 400 and random_amount = 500 for a chosen user. This undermines the fairness of the airdrop and could lead to abuse.
Moderate. Precise timing requires automation but is feasible in a testnet or low-traffic network. In a mainnet with multiple validators, the exploit is harder but still possible with validator collusion or repeated transaction submissions.
Users do not receive fair random allocations.
The contract owner can register addresses at carefully chosen timestamps to guarantee maximum slices (500 APT).
Validators can reorder or delay transactions to skew randomness outcomes.
Over time, this could drain the pool prematurely and break trust in the airdrop process.
Replace timestamp::now_microseconds()
with a built-in on-chain randomness module in Aptos:
The `get_random_slice` function should only be called by the owner via the `register_pizza_lover` function. Also, the `owner` is trusted and will not choose a specific time for a new user to register. Therefore, I disagree with the claim of most reports in this group that an attacker can manipulate the random number of pizza slices. But I agree with the root cause of the reports in this group, that the random distribution is not completely random.
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.