Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: low
Invalid

Unused or Misleading `minter` Address

Overview

The veRAACToken contract declares:

address public minter;
...
function setMinter(address _minter) external override onlyOwner {
require(_minter != address(0), "Invalid minter address");
minter = _minter;
emit MinterSet(_minter);
}

However:

  1. No Usage for Minter:
    None of the minting paths (_mint(...) in lock(...), increase(...), extend(...)) check if msg.sender is minter or do any access control referencing minter.

  2. Anyone Can Mint via Lock Functions:
    A user simply calls lock(...) or increase(...), which unconditionally calls _mint(...). The contract never verifies that minter == msg.sender.

the minter field is effectively unused. Users might incorrectly believe that only the address stored in minter can mint tokens, but in practice the code ignores this field.

Attack / Demonstration

While this design does not create a direct exploit (because the entire logic for minting is already built into lock(...) and increase(...)), it misleads administrators and integrators:

  • False Security Assumption: Observers see minter and expect that only minter can trigger minting. In reality, any user can mint veRAAC simply by locking tokens.

  • Owner Setting Minter: The contract owner can call setMinter(someAddress), but this has no effect on who can actually mint.

Impact

Confusing or Misleading Implementation: Another developer or an auditor might assume minted tokens are restricted to minter, but the contract’s actual mint logic in lock(...)/increase(...) does not reference it.

Incomplete Role‐Based Control: If the protocol intended for “external” or “controlled” mints to be possible, that code is missing. If it intended for only the minter to do the locking/minting, the code never enforces that restriction.

Recommendations

Option A: Remove the minter concept entirely if the design is that any user can mint veRAAC by locking RAAC. This removes confusion and clarifies that locks are the only mint path.

Option B: Enforce Minter Only. If the intention was to restrict all mint calls:

function lock(...) external {
require(msg.sender == minter, "Only minter can lock and mint");
...
}

or

if (msg.sender != minter) revert NotMinter();

in _mint(...), etc. So that only minter can create or expand locked positions.

Either approach ensures the contract’s code and the existence of the minter field align with the desired security model.

Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!