Expected behavior: Demand rate limiting should prevent large-scale spamming or griefing that artificially inflates revenue or manipulates reputation.
Actual behavior: The contract uses a per-address COOLDOWN but does not limit per-block, per-origin, or apply any dynamic throttling. An attacker can spin up many addresses and call trigger_demand() repeatedly to simulate massive demand.
Using only per-address cooldown is ineffective against Sybil attacks (many addresses controlled by one actor). This can be used to artificially inflate company revenue, reputation, or drain inventory.
Likelihood
High — creating multiple accounts is trivial.
Impact
1.Artificial revenue & reputation manipulation.
2.CompanyGame inventory depletion / degraded simulation integrity.
3.Potential denial-of-service on CompanyGame by many rapid sell_to_customer calls.
Deploys many tiny helper contracts whose msg.sender values are distinct on-chain.
Each helper calls trigger_demand() in its constructor and then self-destructs, returning leftover ETH to the deployer.
This simulates a Sybil attacker producing many callers in a single block/transaction to bypass per-address cooldown and flood the company with demand (inflate revenue, reputation, or deplete inventory).
Consider additional rate-limiting or anti-Sybil mechanisms:
1.Introduce per-block or global rate limits (e.g., max demands per block or per minute).
2.Require small registration cost or staking to be a customer.
3.Implement reputation-weighted demand (higher reputation customers have priority) and cap total demand per time window.
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.