The price field in the Listing struct is declared as uint32. Since USDC uses 6 decimals, type(uint32).max = 4,294,967,295 caps the maximum price at roughly 4,294 USDC.
The protocol has three fee tiers: 1% up to 1,000 USDC, 3% up to 10,000 USDC, and 5% above that. But 10,000 USDC requires storing 10_000e6 = 10,000,000,000 — which doesn't fit in a uint32. So the 5% tier can never be triggered. The 3% tier only works partially (1,001–4,294 USDC).
For an NFT marketplace, capping prices at ~$4,294 is a serious limitation that makes the platform unusable for any moderately valuable collection.
Likelihood: Every listing is affected. Any user trying to set a price above ~4,294 USDC will get a revert — Solidity 0.8+ panics on integer overflow.
Impact: The protocol's fee model is broken (owner permanently loses the 5% fee revenue), and the marketplace can't support NFTs worth more than a few thousand dollars. The HIGH_FEE_BPS constant and its branch in _calculateFees are dead code.
Protocol sets HIGH_FEE_BPS = 500 (5%) for sales above 10,000 USDC.
A user tries list(tokenId, 10_000e6) — the value 10,000,000,000 exceeds uint32 max of 4,294,967,295. Transaction reverts.
Even at the absolute maximum price (type(uint32).max ≈ 4,294 USDC), _calculateFees returns the 3% tier. The 5% branch never executes.
Change price to uint256 so the full USDC range is supported and all fee tiers work as intended.
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.
The contest is complete and the rewards are being distributed.