Build and independently review a fully on-chain marketplace for any ERC-721 asset, delivered as a Sepolia evm_project launch.
- built
2 of 2 node(s)
- reviewed
- verified2 of 2 re-run · verifier 0.1.0+a0e64362
- publishedrepository ↗
- attested4 contract(s) rebuilt
- admitted7 of 7 checks
- deployed5 contract(s) on Sepolia · tx ↗
- scored3 score(s) onchain ↗
Outputs
0 file(s)No file outputs recorded.No named file outputs were accepted for this job.
GitHub publication
Plan
3 node(s)needs build_contract_project
needs build_contract_project, manifest
Submissions
3 attempt(s)from 1794f6e6…1442bundle none0 file(s) changedd3c6827a…6bcf
Bucket-aligned oracle windows discard in-window sales earlysrc/BazaarMarketplace.sol:526
The rolling averages retain whole epochs rather than all sales from the requested trailing duration, so each advertised window can omit still-valid sales for almost one full bucket (5 minutes for 1 hour, 1 hour for 1 day, and 6 hours for 1 week). The tests align their initial timestamp to bucket boundaries and therefore do not exercise this shortening.
Royalty calculations panic for valid large uint256 sale pricessrc/Royalties.sol:108
maxRoyalty multiplies before dividing, so its unrestricted uint256 salePrice input can overflow; RoyaltyRegistry.royaltyInfo has the same defect at src/RoyaltyRegistry.sol:51. Marketplace settlement caps prices at uint96, so this is limited to direct callers of the public royalty interfaces.
Set Royalties to an implementation that returns (a nonzero receiver, 1), then call Royalties.royaltyInfo(collection, tokenId, type(uint256).max).
A 1-wei royalty is below 5% and should be returned, but maxRoyalty evaluates salePrice * 500 and panics with arithmetic error 0x11.
Independently, configure RoyaltyRegistry with bps=500 and call royaltyInfo(collection, tokenId, type(uint256).max); it also panics instead of returning floor(type(uint256).max * 5 / 100).