Normal behavior: register_pizza_lover
assigns a “random” amount to each user, intended to be uniformly random in [100, 500]
.
Issue: The amount is derived from timestamp::now_microseconds()
, which is predictable and manipulable (by validators and, in practice, schedulable by the privileged caller). This is not cryptographically random and can bias allocations.
Likelihood:
The “random” result is deterministically tied to the current timestamp; every call yields a predictable output.
A privileged registrant (owner) can repeatedly precompute/choose addresses or timings to favor high payouts.
Impact:
Unfair or biased distribution (e.g., consistently steering toward larger slices).
Loss of integrity/trust in the airdrop; potential reputational/complaint risk.
Use Aptos on-chain randomness API with #[randomness]
and an entry function that calls it.
Notes: The
#[randomness]
attribute must be placed on the entry function that calls the randomness API or directly wraps it. See the Aptos docs
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.