Blueprint (BLUEPRINT) security report
Radar AI scanned Blueprint on Ethereum. The verified source review found medium-severity centralized-control risks in reward reclamation and posting-fee management. Slither was not run.
The contract does not show a honeypot-style transfer restriction or owner mint capability. However, the owner can redirect reclaimable rewards by changing the reserve address, and the owner or operator can set the posting fee to any value, including zero or an excessively high fee.
Trust score: 68/100. Source verified: Yes. Chain: ethereum. Contract: 0x90a010338501d1bb7184a136cd3ce73653e71ff4.
This report was last modified on 2026-10-08 and contains 2 material findings.
medium finding: Owner can redirect reclaimed rewards through the reserve address
The owner can change the reserve address at any time. Rewards associated with an account can be marked by any caller when claimable rewards exist; after the 23-hour idle period, reclaim sends the account's pending rewards to the current reserve. This creates a privileged redirection path for rewards that are not claimed before expiry.
Evidence: setReserve(address reserve_) is restricted only by onlyOwner and updates the reserve variable. reclaim(address account) transfers pending rewards to reserve after markedAt[account] + IDLE_PERIOD, where IDLE_PERIOD is 23 hours. mark(address account) can be called by anyone when claimable(account) is nonzero.
Recommendation: Use a governance-controlled or immutable reserve where practical, document the idle-reclamation policy clearly, emit and monitor reserve changes, and consider requiring account authorization or a longer, user-visible claim grace period before reclaiming rewards.
medium finding: Posting fee is fully controlled by owner or operator
The owner or designated operator can set postFee to any uint256 value without a cap or timelock. Setting it to zero disables posting entirely, while setting it to a very large value can make posting economically impractical and burn substantial BLUEPRINT from callers who use the feature.
Evidence: setPostFee(uint256 fee) uses onlyOperator, and onlyOperator permits msg.sender == operator or owner(). post(bytes32 hash) reverts with PostingClosed when postFee is zero and otherwise burns exactly postFee from msg.sender via _burn(msg.sender, fee).
Recommendation: Add a maximum fee or bounded fee schedule, use governance or a timelock for changes, publish fee changes through monitoring, and consider separating feature activation from destructive fee changes.